微服务的价值其实远超出 IT的认知

讲真，微服务诞生确实是从 IT 视角出发的。把单体架构拆散成为更小粒度，独立性更强的部分，从而获得灵活性、可扩展性、可维护性，再依靠虚拟化技术实现水平扩展实现弹性性能，好处多多。

也许是因为我和我的团队采用微服务架构的目的从一开始就是解决业务问题而不是IT问题，因此我们从一开始就有着不同的视角。经历了几年的持续演进、思考和实践，我们对微服务架构的理解越来越超出 IT 视角。甚至，上一段中的那些 IT视角的 所谓『好处』在我们看来只是一种『理所当然』的存在，它本就应该是那个样子，没什么好值得宣扬的，更不值得去特殊设计。

在我们看来，微服务的真正价值就隐藏在它的名字当中——服务。服务显然是面向使用者的，没有使用者就没有服务存在的必要和价值。因此，定义一个微服务必须先搞清楚它服务的对象，使用的场景，要从使用者角度出发而不是从 IT 角度出发。有许多微服务设计理念和方法从 IT 角度列举了很多原则，比如高内聚低耦合，比如独立性……可这些原则本就是系统设计的基本原则，不论是否采用微服务架构，这些原则都适用。同时，这些原则可以在一个成熟的微服务开发框架下由框架底层技术性的实现。那么，这些原则对如何划分和设计微服务又有何意义？

当把眼光从 IT 视角移出来，问微服务架构能为客户带来什么业务价值时，我们需要面对这些业务视角的问题：

如何让 IT 系统与业务需求高度匹配？

如何让 IT 系统升级速度跟上甚至引领业务变更的步伐？

如何让 IT 系统既支持标准化管理，又支持个性化创新？

如何让 IT 系统既能够像搭积木一样随需应变，又能保证不管怎么搭，业务始终集成，数据始终标准一致？

如何让 IT 系统不论跨多少个项目、分多少个产品线、分多少个团队，历经多阶段多年的持续研发演进，始终保持一致的架构、一致的技术和一致的设计？

如何让 IT 系统永无重复建设，一次构建到处复用？

如何让 IT 系统建设越做越快，越做越稳定，越做成本越低？

……

正是因为需要回答上面一系列微服务的应用价值问题，我们有着独特的视角，我们的微服务开发平台GiSP的设计上，也就诞生了很多独特的设计。比如：

模型驱动的微服务架构：用模型描述业务，以模型标准化实现设计的标准化。通过解析业务模型自动生成微服务源代码，通过代码生成器的持续演进达到『一次设计，按需实现』的目的。也就是说，当架构和技术变化时，需要改进的只是代码生成器，与业务无关；当业务变化时，需要改进的只是业务模型，与技术无关。因此不管技术如何变化，有多少个团队参与，业务设计始终标准，而技术则可以持续改进。

功能与关系的分离：功能表示一个微服务能做什么，关系包括一个微服务与数据的关系、与其它微服务的集成关系……所谓的耦合性其实来自于关系而不是功能；而集成一体化的业务来自于关系而不是功能。不管关系只管功能的微服务得以完全解耦，所谓的关系则交由模型去解释，而模型不是代码，因而可以动态解析。

全域数据模型：微服务保持独立性，但数据模型始终保持全域共享、唯一和集成。微服务因为独立，业务场景因此可以像积木一样按需组装；数据模型因为全域共享，数据因此可以始终保持唯一和一致。那些声称微服务之间要保持数据独立性的说法，相信我，那只是从 IT 架构的视角出发，这些经验只是基于互联网的场景化应用而不是大型企业信息系统的集成一体化。

设计与实现的实时一致：设计是模型驱动的，模型设计是零代码的。因此可以由懂业务但不会写代码的产品经理、业务专家来设计业务；源代码是根据模型生成的，开发只是在生成的源代码的特定位置做填空题，填入业务逻辑的实现代码。业务变更导致模型变更，模型变更将重新生成源代码。因此最终实现始终与业务设计保持一致。回想一下之前厚比南山的设计文档与实现代码之间能保持多少一致性。

……

还有很多非常独特但都是脱胎于实践，直面现实问题的特性，例如：

多微服务情况下数据修改的唯一入口机制；

永远不变的静态数据机制；

跨项目、跨团队、跨组织的共享机制；

以微服务为

粒度

的继承与扩展机制；

从业务无关、领域标准到个性化定制的三层扩展机制；

微服务的组装机制；

……

很多很多，后续的up 再一一详解这些特性吧。

这将会是很长的一个系列。我会持续的把我这十多年在企业数字化过程中思考、架构、方法和技术，以及我团队所研发的企业数字化中台构建平台发布出来。相信对业界是有着重要的借鉴意义的。

如果您对企业中台架构、企业数字化转型和产业互联网感兴趣，请关注我并期待后续更新。