微服务之服务拆分策略-技术圈

通常可以根据以下两种策略实现微服务的架构拆分，其一是根据业务能力进行服务拆分，其二是根据领域模型进行服务拆分。

根据服务能力进行业务拆分

参考Chris的业务拆分定义可以看出，首先要识别业务能力，再根据业务能力定义服务。这里的服务其实可以理解为API或者服务网关。

拆分后的微服务应该具备以下几点特性：

架构必须稳定，能够有效支撑系统变更
高内聚：服务必须具有凝聚力，应实现一小组高度相关的功能。

服务必须符合共同封闭原则，一起变更的事物应打包在一起以确保每次变更仅影响一项服务。
低耦合：服务必须是松散耦合的，每个服务都是封装其实现的API。可以在不影响客户的情况下更改实现

服务具备较高的可测性
每项服务应该足够轻小，可以支持一个敏捷小组开发（6-10人）。

跨团队持续交付：拥有一项或多项服务的每个团队都必须是自治的。一个团队必须能够与其他团队进行最少的协作来开发和部署他们的服务。

以支付交易清算业务为例：

根据子域进行服务拆分

子域是领域的一部分，领域是DDD中用来描述应用程序问题域的一个术语。领域驱动为每一个子域定义单独的领域模型。识别子域的方式跟识别业务能力一样：分析业务并识别业务的不同专业领域，分析产出的子域定义结果也会跟业务能力非常接近。DDD把领域模型的边界称为边界上下文（bounded context），边界上下文包括实现这个模型的代码集合。当使用微服务架构时，每一个边界上下文对应一个或者一组服务。即，我们可以通过DDD的方式定义子域，并把子域对应为每个服务，这样就完成了微服务架构的设计。

还是以支付清算系统为例：

真实的情况是上述拆成的每个子域里面都会对应一组服务，其实还可以按照实时交易和批处理交易拆分两个域，每个域下面在按照功能维度拆成多个子域，每个子域下面一般都会对应一组服务。可以简单的想下，日常开发中一个6-10的敏捷开发小组，都不会只维护一个应用服务的，只要能控制住这个小组内的变更不会超出自己负责的子域，影响到其他子域就可以。

拆分的指导原则

微服务的拆分没有标准的答案但是可以根据行业经验或者一些设计模式作为指导原则。

单一职责原则（Single Responsibility Principle）：改变一个类应该只有一个理由。

我们在设计微服务架构时应该遵循SRP原则，设计小的、内聚的、仅仅含有单一职责的服务。这会缩小服务的大小提升它的稳定性。

闭包原则（Common Closure Principle）：在包中包含的所有类应该是对同类变化的一个集合，也就是说，如果对包做出修改，需要调整的类应该都在这个包之内。

在微服务架构下采用CCP原则，这样我们能够把根据同样原因进行变化的服务放在一个组件内。这样就可以控制服务的数量，当需求发生变化时，变更和部署也更加容易。理想情况下，一个变更只影响一个团队和一个服务。CCP是解决分布式单体这种可怕的反模式的法宝。