企业微服务架构切入点

企业在自身IT成熟度还没有达到一定水平的时候，应该谨慎对待微服务架构，其核心原因就是由于架构微服务化后会导致开发，集成，乃至后期的运维管控的复杂度呈指数级提升。即使企业本身有组件化和服务化的思想，但是也没有能够彻底构建微服务架构的能力。

    正如很多企业连基础主数据都没有管理，也没有建设集成的研发，生产相关的PLM，MES，CIM等核心系统，就开始谈要一步迈入工业4.0和智能制造是一样的道理。任何事情都要考虑从简单到复杂，通过迭代的方式逐步演进。下面就简单分析下企业实施微服务架构可行的一些切入点。

1. 共性技术服务能力下沉建设

   企业在刚开始规划建设，或者建设到一定阶段后，都会涉及到一下基础性的共性技术需求，类似消息管理，日志管理，文件存储，共性的小应用组件（论坛，通讯录，文档在线阅读）等。
   
   这些共性能力既可以是技术服务，也可以是共性小应用程序，其最大的特点就是这些组件本身横向交互相当少，而更多的是将自己的能力向上提供暴露和集成。因此这类场景采用微服务架构方式来独立构建并部署是合适的，这类模块的上线和集成可以最大限度的减少对已有横向业务的影响。
   
   要发现这类需求，企业应该有一个统一的需求受理和分析组，对各个业务部门或业务系统提交的需求同意进行分析，抽取出共性需求，然后再考虑是否通过微服务方式统一建设。
   

2. 基础平台层能力先行

   企业在实施微服务架构的时候，一定要意识到对于4A+流程引擎这两个能力需要提取进行平台化和微服务模块化。因为这两个基础能力往往是任何一个业务微服务模块能够运转起来的基础。正是由于这两个基础能力的平台化，我们在构建新的微服务模块的时候，才能够将重心完全放在只关注业务实现上。
   

3. 新增模块移出

   如果企业已经实施了采购系统而且已经上线运行多年，那么在对采购系统出现大的模块级需求的时候（例如需求在采购需求中增加招投标的功能），那么这种模块需求就可以考虑移出采购系统，通过微服务架构的方式独立构建，在构建完成后在和采购管理系统集成。
   
   对于一个新增模块是否能移出，重点还是要考虑该模块和已有的遗留业务系统间的耦合性和集成度。耦合度越小，越容易单独构建并后期集成。从这个角度来看对于哪些在原有业务系统中上游业务最适合移出，例如招投标模块构建只是需要将合格供应商和采购物料清单信息传递到采购系统，而并不需要从已有的采购系统返回任何信息。
   
   新增模块移出并进行微服务化往往是对遗留系统影响最小的方案。在微服务架构在企业内部逐步实施成熟后再考虑更多的模块或组件从已有系统中移出。
   

4. 大变更下模块移出

   企业在接收到新的变更需求处理时，当已有业务系统的某一个模块出现重大变更时（比如变更内容和范围超过了模块本身30%-50%），在这种情况下可以考虑将变更模块移出并进行微服务架构的改造。
   
   要清楚在模块大变更情况下，即使按原有模块开发和处理，也会带来巨大的模块开发和集成，联调和实施工作量，还还不如和企业微服务架构演进策略一起处理。两次对业务的大影响变成一次影响，虽然增加了复杂度，但是实际上是降低了整体工作量和后期迁移难度。
   
   企业实施微服务架构不应该是将遗留系统彻底推翻并全新建设，而是应该采用3+4迭代进行的渐进式实施策略。