理解微服务的单一职责原则的优缺点

近来看到好多有关微服务的文章提到，“单一职责”原则是微服务的基本原则之一。

“单一职责”原则其实本就是面向对象设计与编程的基本原则之一。

我们先看看面向对象原则中对SRP原则的权威解释：

单一职责原则(single responsibility principle )

      There should never be more than one reason for a class to change.

      所谓单一职责原则，就是对一个类而言，应该仅有一个引起它变化的原因。换句话说，一个类的功能要单一，只做与它相关的事情。在类的设计过程中要按职责进行设计，彼此保持正交，互不干涉。

什么是职责？

      在SRP 中，职责定义为“变化的原因”。如果你能够想到多于一个的动机去改变一个类，那么该类就具有多于一个的职责。

为什么要采用单一职责原则？

      因为每一个职责都是变化的一个轴线，当需求变化时，该变化会反映为类的职责的变化。如果一个类承担了多于一个的职责，那么就意味着引起它的变化的原因会有多个。如果一个类承担的职责过多，那么就等同于把这些职责耦合在了一起。一个职责的变化可能会抑制到该类完成其他职责的能力，这样的耦合会导致脆弱的设计。当变化发生时，设计会受到意想不到的破坏。单一职责原则正是实现高内聚低耦合需要遵守的一个原则。

       注意： 单一职责原则简单而直观，但在实际应用中很难实现。只有变化的轴线仅当实际发生时才具有真正的意义。如果没有预兆，那么去应用SRP或者其他任何的原则都是不明智的。

可以看到，“单一职责”的目的如下：

1、以类来隔离需求功能点，这样当一个点的需求发生小的变化的时候，不会影响别的类的逻辑

2、是一个原子模块级的粒度，易修改，易废弃

3、粒度小，灵活，复用性强，易聚合组装为更高一级的业务对象

那么微服务如果也遵守这个原则，当然也会具备以上目标和优点。

但是我们反思一下，“单一职责”是否适用于微服务？

首先，一个系统上线后，有bug的修改，但是还有需求变更，而对于需求变更，有原业务范围的，有新增业务的，甚至有业务流程的重构。

二、如果单一职责微服务的粒度很细，对应到一个领域对象，如果只是一个小bug的修改，很方便。但如果这个领域对象会参与多个业务功能、流程，那么随便一个需求变化，或者一个多点的bug修正，可能导致多个微服务要跟着改，那么这几个微服务之间的依赖就很重，虽然微服务化了，虽然单一职责了，但最小的需求变化都会影响到多个微服务，微服务之间的依赖必然导致组织、测试、开发、上线的依赖，影响持续交付，因此这种粒度是不合理的，虽然复用度很高，但应对业务变化的效果不好。

三、如果单一职责并不对应一个微服务，只是对应一个适度自包含的微服务中的一个业务功能点，那么会产生什么样的效果呢？可能是一个三、四级流程节点的需求变更，只需要修改一个微服务就可以了，持续交付不受影响，但可能会出现重复的逻辑，因为一个领域对象不可能只存在于一个微服务有界上下文中，那其实这个领域对象的单一职责功能，不变的部分，可以下沉为微服务的公共组件Jar包，由不同微服务引用就可以了。

四、什么样的单一领域对象的单一职责微服务才是有价值的？就是不断有业务变化，能够维持业务持久性，有业务生命力的领域对象；或者与别的功能点相比，调用频率非常高；或者其数据量存量大，数据增速快，T级甚至是P级的，那么就很有价值独立为一个微服务，实现独立的随需而变、独立演进、个性化的弹性伸缩。

所以，我们在进行业务规划、需求分析的时候，要能够分析、预测出需求变化的点在哪里？高并发的点在哪些？数据增长的位置在哪里？与DDD分析相结合，找出最有价值的那个单一职责，进行合理、适度的领域、子领域、有界上下文分解，才能更好的应对复杂的业务、不断变化的业务。