讲真，微服务降生确实是从 IT 视角出发的。把单体架构拆散成为更小粒度，独立性更强的部门，从而获得灵活性、可扩展性、可维护性，再依靠虚拟化技术实现水平扩展实现弹性性能，利益多多。也许是因为我和我的团队接纳微服务架构的目的从一开始就是解决业务问题而不是IT问题，因此我们从一开始就有着差别的视角。

履历了几年的连续演进、思考和实践，我们对微服务架构的明白越来越超出 IT 视角。甚至，上一段中的那些 IT视角的 所谓『利益』在我们看来只是一种『天经地义』的存在，它本就应该是谁人样子，没什么好值得宣扬的，更不值得去特殊设计。在我们看来，微服务的真正价值就隐藏在它的名字当中——服务。

服务显然是面向使用者的，没有使用者就没有服务存在的须要和价值。因此，界说一个微服务必须先搞清楚它服务的工具，使用的场景，要从使用者角度出发而不是从 IT 角度出发。有许多微服务设计理念和方法从 IT 角度枚举了许多原则，好比高内聚低耦合，好比独立性……可这些原则本就是系统设计的基本原则，岂论是否接纳微服务架构，这些原则都适用。同时，这些原则可以在一个成熟的微服务开发框架下由框架底层技术性的实现。

那么，这些原则对如何划分和设计微服务又有何意义？当把眼光从 IT 视角移出来，问微服务架构能为客户带来什么业务价值时，我们需要面临这些业务视角的问题：如何让 IT 系统与业务需求高度匹配？如何让 IT 系统升级速度跟上甚至引领业务变换的程序？如何让 IT 系统既支持尺度化治理，又支持个性化创新？如何让 IT 系统既能够像搭积木一样随需应变，又能保证不管怎么搭，业务始终集成，数据始终尺度一致？如何让 IT 系统岂论跨几多个项目、分几多个产物线、分几多个团队，历经多阶段多年的连续研发演进，始终保持一致的架构、一致的技术和一致的设计？如何让 IT 系统永无重复建设，一次构建随处复用？如何让 IT 系统建设越做越快，越做越稳定，越做成本越低？……正是因为需要回覆上面一系列微服务的应用价值问题，我们有着奇特的视角，我们的微服务开发平台GiSP的设计上，也就降生了许多奇特的设计。好比：模型驱动的微服务架构：用模型形貌业务，以模型尺度化实现设计的尺度化。通过剖析业务模型自动生成微服务源代码，通过代码生成器的连续演进到达『一次设计，按需实现』的目的。

也就是说，当架构和技术变化时，需要革新的只是代码生成器，与业务无关；当业务变化时，需要革新的只是业务模型，与技术无关。因此不管技术如何变化，有几多个团队到场，业务设计始终尺度，而技术则可以连续革新。功效与关系的分散：功效表现一个微服务能做什么，关系包罗一个微服务与数据的关系、与其它微服务的集成关系……所谓的耦合性其实来自于关系而不是功效；而集成一体化的业务来自于关系而不是功效。

不管关系只管功效的微服务得以完全解耦，所谓的关系则交由模型去解释，而模型不是代码，因而可以动态剖析。全域数据模型：微服务保持独立性，但数据模型始终保持全域共享、唯一和集成。微服务因为独立，业务场景因此可以像积木一样按需组装；数据模型因为全域共享，数据因此可以始终保持唯一和一致。那些声称微服务之间要保持数据独立性的说法，相信我，那只是从 IT 架构的视角出发，这些履历只是基于互联网的场景化应用而不是大型企业信息系统的集成一体化。

设计与实现的实时一致：设计是模型驱动的，模型设计是零代码的。因此可以由懂业务但不会写代码的产物司理、业务专家来设计业务；源代码是凭据模型生成的，开发只是在生成的源代码的特定位置做填空题，填入业务逻辑的实现代码。业务变换导致模型变换，模型变换将重新生成源代码。

因此最终实现始终与业务设计保持一致。追念一下之前厚比南山的设计文档与实现代码之间能保持几多一致性。

……另有许多很是奇特但都是脱胎于实践，直面现实问题的特性，例如：多微服务情况下数据修改的唯一入口机制；永远稳定的静态数据机制；跨项目、跨团队、跨组织的共享机制；以微服务为粒度的继续与扩展机制；从业务无关、领域尺度到个性化定制的三层扩展机制；微服务的组装机制；……许多许多，后续的up 再一一详解这些特性吧。这将会是很长的一个系列。我会连续的把我这十多年在企业数字化历程中思考、架构、方法和技术，以及我团队所研发的企业数字化中台构建平台公布出来。相信对业界是有着重要的借鉴意义的。

如果您对企业中台架构、企业数字化转型和工业互联网感兴趣，请关注我并期待后续更新。点击『相识更多』可以注册试用文章所述的平台。

本文来源：hth官网下载，华体会体育最新登录-www.163guke.com