一起玩转微服务（7）——单一职责

单一职责

单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则

单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小

设计原则很重要的一点就是简单，单一职责，也就是我们经常所说的专人干专事。

一个单元（一个类、函数或者微服务）应该有且只有一个职责。无论如何，一个微服务不应该包含多于一个的职责。职责单一的后果之一就是职责单位（微服务，类，接口，函数）的数量剧增。据说Amazon,Netflix这些采用微服务架构的网站一个小功能就会调用几十上百个微服务。但是相较于每个函数都是多个业务逻辑或职责功能的混合体的情况，维护成本还是低很多的。 SRP中的“单一职责”是个比较模糊的概念。对于函数，它可能指单一的功能，不涉及复杂逻辑；但对于类或者接口，它可能是指对单一对象的操作，也可能是指对该对象单一属性的操作。总而言之，单一职责原则就是为了让代码逻辑更加清晰，可维护性更好，定位问题更快的一种设计原则。

什么是高内聚低耦合？

这犀利的措辞一看就是来自开发界的术语。高内聚是说一个功能模块最好仅完成一个独立的子功能并且完成的很好。低耦合是指模块与模块之间尽量独立／联系少／接口简单。

这个原则出现的背景是为了让程序“可复用／可扩展／够灵活／可维护”。干过一阵子产品的人对这几个词应该都不陌生。对于程序设计者来说，这几个词是十分重要的，不亚于产品经理口中的“用户体验”（原则or挡箭牌）。

优点

单一职责的优点如下:

•类的复杂性降低，实现什么职责都有清晰明确的定义。•可读性提高，复杂性降低。•可维护性提高，可读性提高。•变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

记得在三字经里边有这样一段 教之道，贵以专（出自三字经） 说的就是无论学习还是构建团队，最重要的是专才，而不是全才。就好比一个足球队，如果都是前锋或者都是后卫，那么这样的球队一定不能出成绩，反而是将各个位置上的人进行统一协调，根据分工不同，共同协作，形成1+1>2的效果，那么这样的团队就非常容易出成绩。

有很多公司为了赶进度，经常会招聘一些所谓的全能型人才，但是这种人往往专业的程度不够，当遇到某些棘手的问题的时候，往往不能够非常快速的解决问题。从而导致最终交付的质量较差。

单一职责的目的

实施单一职责的目的如下：

•以类来隔离需求功能点，这样当一个点的需求发生变化的时候，不会影响别的类的逻辑，这个和设计模式中的开闭原则类似，对于扩展持开放态度，对于修改持关闭态度。•是一个原子模块级的粒度，至于原子的粒度到底是什么样的，应该因业务而异，设计的过程中同时考虑业务的扩展，所以这就要求在设计的过程中，必须有业务专家共同参与，共同规避风险。•粒度小，灵活，复用性强，方便更高一级别的抽象。

每个微服务单独运行在独立的进程中，能够实现松耦合，并且独立部署。

如何做

分3步：

1.把一个具体的问题抽象成一类问题；

2.根据用户体验流程划分功能模块；

3.针对每个功能设计封闭的解决方案。

最佳实践

在实际工作中，有一个经常会用到的设计模式，DAO模式，又叫数据访问对象，里面定义了数据库中表的增、删、改、查操作，按照单一职责原则，为什么不把增、删、改、查分别定义成四种接口？这是因为数据库的表操作，基本上就是这四种类型，不可能变化，所以没有必要分开定义，反而经常变化的是数据库的表结构，表结构一变，这四种操作都要跟着变。所以通常我们会针对一张表实现一个DAO，一张表就代表一种类型的职责。