企业应谨慎对待微服务架构

对于微服务架构我在前面很多文章里面已经都谈到过了。

微服务架构本质是 单个业务系统彻底的组件化（前端，逻辑层，数据库）解耦，同时相互之间通过轻量的服务接口和协议进行协同。这和很早就谈到的组件化架构思想是一致的，实现微服务架构后，你会看到没有传统业务系统的概念了，有的只是微服务模块或小应用。

微服务架构最近又炒的相当活，很多人会说SOA过时了，ESB过时了，甚至还有人用微服务架构去彻底的否定SOA和ESB，这些都是相当危险的信号。在我12，13年写企业私有云PaaS平台的一系列文章的时候，已经提出了业务能力组件化，组件服务化的微服务架构思想，但是实际应用实施效果并不太理想。

一个企业所涉及到的IT开发和架构能力以及企业本身的IT治理管控成熟度都将直接影响到微服务架构能否实施成功，要知道引入微服务架构后集成和后续运维等的复杂度都会成指数级增长。

简单举例来说，一个企业已经实施了5个业务系统，业务系统之间有10个接口。如果全部微服务化则可能设计到50个微服务模块，上100个接口和集成点。可想而知，在彻底实施微服务后，我们前期架构设计，后期集成和管控的复杂度增加10倍以上。

这种集成难度会远超大多数人想象，如果拿真实做的项目来说，如果谈业务系统只有3个，而到微服务模块级别则有接近60个，而实际涉及到的集成接口上1000个。我们做任何一个复杂端到端业务的联调基本就需要花2，3周甚至更长的时间。

互联网企业为何适合做微服务架构，其重要的一个原因就是互联网企业如电商平台，在进行了微服务化后各个模块之间耦合性很低，并不会有太多的集成和协同点。或者简单来说， 各个微服务模块更多的是向上面的PC端或APP端提供服务能力，而模块横向间接口协同很少。

正是在这种低耦合情况下，协同和集成相对来说容易。而转回到企业内部你会发现，在微服务模块化后，各个模块之间的集成点相当多，特别是业务系统拆分到模块或组件这一个级别后，很多原有内部的集成和依赖点全部暴露出来了，你都需要去很好的管理。由于这里面有大量的横向集成和协同点，因此导致的就是 微服务模块间的横向集成异常复杂，远超很多互联网应用，这是实际你会面临的问题。

企业信息化管理或业务系统的建设，根据企业自身IT管控能力和成熟度的发展必须要能够容忍灰度。就像一个企业招标建设了3个业务系统一样，刚开始一定关心的是三个系统能够运转起来支撑业务，同时三个业务间数据能够集成。你期望3个系统都安装统一的标准，框架，开发语言和组件化架构进行设计和交付，但是实际上却不可能，各个厂家标准和方法都不一样，厂家宣称的组件化设计而实际上内部模块仍然是强耦合在一起无法拆分。这些都是现实情况，需要容忍，即业务系统只要功能正常能和外面集成起来，其内部混乱一点我不太关心。

这和管理有时候是一样的道理，我们需要抓目标和过程，但是团队一大最上层领导就不可能管理到每个人。他更加关心的是下达给各个部门经理的目标能否很好完成，部门经理间协同上是否有问题。而各个部门经理管理的方法和流程容忍有差异，当企业的管理和治理水平不断成熟后我们再考虑如何更加精细化管理。

分而治之，一个事物能够分解到哪层？适合分解到哪层？是和你个人的能力和成熟度密切相关的。

一开始分解的粗，比如只分解到业务系统层面，刚开始就好管控，但是容忍了业务系统内部的一些杂乱无序。那么带来的问题就是当业务系统出现细粒度管控要求和能力扩展要求的时候，你会发现业务系统再要拆分为松耦合的组件并作到彻底的独立管理已经相当困难。这也是为何现在在企业内部也提微服务架构的原因。

企业IT成熟度不够而推行微服务架构，带来诸多的问题点，在下面一篇将详细分析常见问题。第3篇则讲企业微服务架构最好的切入点在哪里？