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

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

我们先看看面向对象原则中对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分析相结合,找出最有价值的那个单一职责,进行合理、适度的领域、子领域、有界上下文分解,才能更好的应对复杂的业务、不断变化的业务。




Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐