理解微服务的单一职责原则的优缺点
近来看到好多有关微服务的文章提到,“单一职责”原则是微服务的基本原则之一。“单一职责”原则其实本就是面向对象设计与编程的基本原则之一。我们先看看面向对象原则中对SRP原则的权威解释:单一职责原则(single responsibility principle ) There should never be more than one reason for a clas
近来看到好多有关微服务的文章提到,“单一职责”原则是微服务的基本原则之一。
“单一职责”原则其实本就是面向对象设计与编程的基本原则之一。
我们先看看面向对象原则中对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分析相结合,找出最有价值的那个单一职责,进行合理、适度的领域、子领域、有界上下文分解,才能更好的应对复杂的业务、不断变化的业务。
更多推荐
所有评论(0)