以企业架构为指导，SOA和微服务为核心思想进行微服务拆分

　　在前面我写过多篇关于企业架构规划，微服务架构规划方面的文章，今天再次讲下微服务架构规划对传统企业架构规划的优化和改进。
　　传统企业架构规划核心输出是什么？
　　对于传统企业架构规划，核心输出是最终的业务系统规划建设和演进路线设计，简单来说就是为了满足企业战略和业务目标，基于业务驱动IT，IT建设要和业务发展匹配的思路，你应该如何规划建设你的IT系统，基于什么样的优先级去建设，每个业务系统应该具备的核心模块和功能，数据究竟是如何的。业务系统之间本身的集成关系是如何的。
　　企业在拿到最终企业架构规划的输出后，一个是站在顶层对整个企业本身的业务架构，应用和数据架构有一个完整的认知，其次就是真正指导后续的规划建设。
　　但是传统企业架构规划存在两个关键问题没法解决。
　　传统的企业架构规划仍然是输出垂直烟囱式的业务系统。同时对于业务系统仍然是推荐类似总线式的方式进行集成。
　　也就是说传统企业架构思想里面类似平台+应用，业务组件化，组件服务化，能力组合等SOA和云计算的思想相当少。这已经无法适应当前云原生下的整体IT新架构模式。
　　新IT架构规划的核心是什么？
　　为配合企业数字化转型，传统IT架构本身也在转型，典型的就是我们常说的云原生，微服务，平台+应用，中台等核心思想。
　　从业务的视角看IT架构的一个关键点是在于对业务响应，对变化的敏捷响应能力。而从技术的角度新IT架构规划的重点是高可用性下的可灵活扩展性。在原来我谈得比较多的是成本，但是现在我将成本降为次要因素。
　　也就是说你只要把业务敏捷响应能力，弹性灵活扩展能力这两点做好，那么成本降低是自然可以达到的事情。但是如果你一开始就关注成本，那么很难基于目标架构进行优化改造。
　　新IT架构规划是一个刚开始成本上升，然后成本在逐步下降的过程。当成本不再作为第一考虑因素的时候，新IT架构规划核心可总结为：
　　在新IT架构下，业务流程和场景需求的满足都是能力API组合的结果，而能力本身是有一个个独立解耦的微服务组件进行提供。
　　因此新IT架构的核心将围绕两个方面来展开，一个就是常规的业务或流程梳理，将业务分解为一个个独立的业务活动或操作单元；其次就是划分微服务并识别各个微服务应该提供的API接口，将API接口能够通过组合或组装来满足能力需求。
　　简单来说理解的核心思想还是SOA和分层思想。不论是谈云原生技术平台，业务中台，平台+应用，领域建模中的领域服务等，核心仍然是这个SOA思想。
　　但是SOA思想还没有解决一个关键问题，即提供能力的各个微服务应该是如何拆分出来的，微服务拆分到哪种程度合适？
　　这个问题谁在回答？
　　实际仍然是传统的企业架构中业务架构，数据架构和应用架构规划思想在回答，也就是要基于传统的系统分析设计思路，不论是面向结构的CRUD分析，还是面向对象的领域分析和边界划分，最终要解决一个问题能力应该是多个松耦合的微服务提供出来的。
　　如果微服务一开始就没有拆分对，那么后面面对的是一系列的灾难。
　　拆微服务-三类要素的聚合
　　如何进行微服务拆分，我在前面也写过文章说明。今天再次谈还是想进一步阐述下最近思考的一些关键内容。
　　拆分微服务会涉及到三类核心的要素聚合和拆分，即API接口，业务功能和数据库表。当微服务拆分出来后，你可以看到这个微服务Owner哪些数据库表，实现哪些功能，对外提供哪些API接口服务能力都应该搞清楚。
　　那么这个时候这个微服务本身才算彻底拆分清楚。
　　业务驱动拆分
　　如上图，CRUD矩阵分析并不是进行业务功能聚类，而仅仅是辅助在业务功能聚合后对应的数据库表的聚类，即数据库表应该划分到哪个具体的微服务里面。
　　业务驱动拆分简单来说就是基于顶层业务流程分析快速地进行业务域划分，在业务域划分完成后对业务功能先进行聚合，然后在基于业务功能进行数据库表的聚合。端到端流程的阶段，High Level的一级或二级流程点往往都是关键的拆分点，可以快速地完成微服务边界的拆分。
　　比如我经常举例的供应链流程，基于端到端分析可以看到招投标，采购请购，采购订单下达，采购执行监控几个关键阶段，那么这些就是大的微服务划分点。当把采购请购划分为独立的微服务的时候，那么采购请购单等核心数据对象和表自然也会聚类到该功能模块。
　　在完成了业务功能和数据聚合后，再基于业务流程分析来看需要暴露哪些API接口服务能力给上层业务流程或前端应用使用。
　　注意在这种方式下核心业务流程中的核心活动往往都是由该微服务模块自己提供，但是扩展流或分支流程，规则等往往涉及到其它微服务模块提供API接口能力，比如采购订单提交的时候需要做预算检查，而预算检查能力由预算管理模块提供API接口。当将一二级流程分解到四级流程，分解出具体的业务操作，业务规则的时候，这些跨微服务调用的API接口服务自然也就是识别清楚。
　　数据驱动拆分
　　当我重新思考微服务拆分这个问题的时候，实际上我比较反对采用数据驱动的拆分。在业务驱动拆分下业务功能聚合后可以快速地确定数据的聚合，但是数据驱动的拆分当数据聚合后并不能解决业务功能聚合的问题。
　　比如按数据驱动拆分你很容易拆分出订单中心，用户中心，合同中心等关键微服务模块。也清楚这些中心里面应该Owner哪些数据库表，数据库DB之间的边界。
　　但是这个微服务的逻辑层应该提供哪些业务功能呢？
　　当使用数据库驱动的时候你只能回答清楚应该提供订单的CRUD操作的API接口服务，注意这些接口完全是数据服务，而非业务服务。仅仅是简单的数据库表能力的API接口暴露。这些不是通过业务流程分析处理的真正的业务功能或操作。
　　在我前面文章里面谈到先数据驱动拆分，拆分完成后暴露数据库能力的API接口服务，在这种思路下你会发现又会到了领域驱动设计里面的贫血层模型。即这种方式下领域层能力是缺失的，虽然有了数据库聚合和API聚合，但是关键的业务功能聚合没有了。
　　所以在这种方式下你会发现正在在做业务流程或业务功能实现的时候，还需要解决大量业务功能的聚合问题，基于业务功能提供大量的业务类API接口服务能力。
　　如上图，数据驱动下虽然构建了共性数据层提供数据服务能力，但是仍然无法解决共性业务能力服务层的构建问题。而真正的共性业务层能力仍然还是基于流程梳理分析的思路，只有把业务梳理清楚的，业务能力才能够识别和聚合。
　　简单总结
　　最后简单总结下前面谈到的内容。新IT架构规划的核心是SOA和微服务思想，SOA思想体现在业务流程或场景的实现是能力API的组合和组装，微服务思想体现在API能力应该是各个松耦合拆分后的微服务提供。
　　其次微服务拆分应该体现数据，业务功能和API接口三者的聚合。当前主流拆分方法包括了业务驱动拆分和数据驱动拆分，但是推荐方法仍然是基于流程的业务驱动拆分，通过业务拆分形成业务功能聚合，然后向下聚合数据库，向上识别和聚合API能力聚合。
　　数据驱动的拆分往往无法深入理解业务流程和业务场景，同时容易导致贫血的业务逻辑层或领域服务层，同时也很难保证最终识别和定义的API接口服务能够用于上层业务流程的组合和编排。