一位阿里架构师的分享——谈谈微服务架构

微服务架构有两个关键特征，其一是原单体应用必须拆分为纵向完全独立的微服务模块，其二是微服务模块间通过轻量的Http Rest接口进行交互。对于是否进行了容器化部署和资源管理，以及是否和DevOps集成只是一些增值的内容而不是必须项。

微服务架构本质仍然是彻底和组件化和模块化，如果这点没有做到，即使使用了类似SpringCloud等各种微服务框架，仍然不能算做微服务架构。就正如原来我们实施SOA的时候，很多人的概念就是只要用了WS服务，就是SOA架构，而没有了解SOA架构本身值得真正核心在哪里。

当前微服务架构方法论是一种趋势，在互联网领域也有大量最佳实践可以参考，那么在企业内的系统是否适合采用微服务架构来做？估计很多企业都在思考这个问题。但是我们看到也有很多自有研发能力强的企业已经开始实施微服务架构转型，包括微服务架构+容器化+DevOps形成了一套完整的实践。

那么企业内的系统是否适合微服务架构？

1. 企业内部面向客户偏运营的系统： 这个本身就类似互联网电商平台，由于运营前端需要更加灵活的响应市场和业务需求，是相对时候采用微服务架构的。对于这种场景参考互联网，更加重要的是构建完整的中台模型，提供中台数据服务和业务服务能力。

2. 企业内偏流程类的业务系统： 这类业务系统如ITSM运维流程管理，OA系统等，这类业务系统的特点就是底层数据模型相对简单，而且耦合度低，这样带来的最大好处就是底层的数据库容易进行拆分。而是跨库调用很少，对于需要处理的分布式事务场景也少。在这种模式下比较适合使用微服务架构，特别是把原来的大业务系统拆分为多个独立的微服务模块。

3. 类似ERP系统，OSS域的资源管理系统： 对于这类系统的核心特点就是底层数据模型复杂，同时业务处理规则和逻辑也复杂。即使简单的库存事务处理，凭证处理，订单接收等都可能涉及到多个业务模块间的操作和协同，对于类似MRP更是涉及到提取大量数据进行运算和操作。这类业务的核心特点就是底层数据库很难进行拆分，即使拆分了也是大量的交叉调用，同时由于业务本身性质要求需要保证强事务一致性，如果进行了数据库拆分将很难真正保证这一点。因此对于这类应用要彻底的微服务架构化是相对困难的。

那么对于这类应用如何做？实际上当前我们看到的企业建设业务系统的方法很多就可以参考，比如对于商用ERP系统本身不可能拆分，但是可以构建大量外围的小业务系统，类似SRM，采购管理，招投标，报账，资产管理等。只是对于大型集团型企业，这些小系统本身也演变成了局部复杂逻辑的大系统。

微服务架构实施重点不是在于微服务开发框架和开发技术，而是在于前期微服务架构咨询规划，即微服务模块的拆分，每个微服务模块提供的微服务API接口服务的识别和定义。

当前大部分的企业IT部门是不具备实施微服务架构的能力，正如很多企业连瀑布模型都没有做好，就开始实施敏捷方法论是一个道理。对于微服务架构的建设和实施，不仅仅是建设期的问题，更加重要的后续如何管控和运维，一个微服务架构在容器化后最终部署可能涉及到上百个节点，这些节点如何进行监控和管理，如何查找性能问题，如何追踪服务链，这些都是必须要解决的问题。否则企业即使建设上去了微服务架构也无法运维。