最近在微服务架构的交流讨论中，客户除了聊微服务技术架构，往往更关注你的微服务模块的划分粒度。API接口的识别和定义，因此本文将重点介绍微服务架构实践中微服务模块的划分和服务识别。首先总结一下跨系统接口集成中服务的标识和定义方法，可以归纳为：1.基于流程架构和业务架构，从跨系统交互流程入手，分析业务交互接口点，识别关键点业务服务能力。2.基于数据架构和主数据建模分析，识别关键数据服务能力。3.基于技术架构和公共平台层技术组件的分析定义，以能力开放为原则，识别关键技术服务能力。因此，对于跨系统集成，服务标识和定义的思路比较清晰。那么传统方法中业务系统的划分和定义粒度是怎样的呢？在前面的企业架构分析中，我有提到通过跨系统交互过程的分析，找出最细粒度的业务功能模块和功能单元，然后自下而上聚合，以CRUD分析为main方法，多次迭代得到满足高内聚松耦合条件的最佳业务系统划分。没有精确的方法，但在这个总原则下有一个指导方法。微服务模块的划分微服务模块的划分并不是什么新鲜事，它是传统业务系统内部对业务功能组件的划分，但我要关注的重点是业务组件本身的粒度和大小。在还没有完全拆分成独立的微服务模块的时候，我们的业务系统可以拆分成20多个业务模块，因为数据库本身没有拆分，业务模块之间的调用都是内部API调用，所以不会感觉好像有什么不对劲。但是，如果将这20个业务模块完全拆分成独立的微服务模块，你会发现模块之间的紧耦合或者大量的交互集成接口会导致系统集成和交互关系相对复杂，后期难以管理。.这是我们之前经常强调的。在将传统的大型业务系统划分为微服务模块时，尽可能划分为6~8个模块比较合适。当自己的IT成熟度达到一定程度后，可以再细分的更细一些。同时，在划分微服务模块的时候，还要考虑到数据库本身的划分，即底层数据库也要划分，类似于我在讲私有云PaaS时讲到的数据库水平拆分.怎么拆？其实方法还是一样的。仍然需要对单个业务系统的内部流程进行分析，然后将其分解为具体的业务组件或功能，然后按照高内聚的原则进行聚合，保证微服务模块之间的交互最小化。同时，对于大家需要用到的基础数据模块，依然采用通用的下沉策略和思路。同时，一个有价值的参考方法是分析业务系统承载的主要业务流程是什么？然后分析这个业务流程可以横向划分多少个独立的阶段，然后把这些独立的阶段划分成稍微不同的微服务模块，划分完成后进行CRUD分析修正。微服务接口的识别和定义无论是传统的跨业务系统交互接口，还是微服务模块间交互API接口，我一直强调的一个重点是接口要保证粗粒度特性，实现业务规则和逻辑。凝聚力强。接口应该面向核心业务对象、领域对象或者业务规则能力的暴露，而不是微服务模块内部对数据库表CRUD操作的暴露。如果将数据库表CRUD操作暴露为RestAPI接口，微服务模块之间相互调用。一是耦合度增加，二是根本没有实现高内聚的基本要求。基于以上基本原则，我们在识别和定义微服务接口的时候，还是需要从业务流程出发，梳理和完成一个完整的业务流程，各个微服务模块之间存在哪些业务交互接口，然后识别这些接口之后即，将接口拆分或合并，最终形成微服务API接口。只有这样才能复用最终的微服务API接口。由于我们将基础数据管理分离成一个基础模块，基于数据能力开放和暴露的原则，可以将这些基础数据的能力以查询服务的形式暴露为独立的数据服务能力接口。需求仍然是域对象级别而不是数据库表级别。在开发实现各个微服务模块时，如果是基于领域驱动架构设计的思想，那么只需要完整定义微服务模块的领域对象，就可以将领域对象的能力以形式暴露出来API接口，它包括查询接口和导入或数据插入接口。其次，核心业务规则的实现可以独立暴露为接口服务。在之前的微服务架构咨询中，我曾经提到过，在多个微服务模块之上，可能还会有一个微服务能力组合层，实现类似的流程服务和复合服务类能力。如果是这样的话，那么***也是由一个独立的微服务模块来实现的。这个微服务模块本身可能并不对应具体的数据库，而是结合了底层微服务模块的服务能力，形成了一个新的Interface服务能力。在微服务架构的设计中，我们更注重数据的后续开发和落地而不落地。既然数据不落地，我们可以用开放能力的思想更好的识别和暴露接口。简而言之，您的站点上有哪些数据或业务对象，您管理哪些业务规则？经过粗粒度聚合后，这些可以被识别并定位为微服务API接口。
