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