文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

在实现微服务架构中,被问到最多的一个问题是关于微服务的大小和粒度.微服务到底应该多小?一个软件应该被分成多个服务还是作为单独的整体构建?为了试着回答这些问题,我想出来了一些标准来帮助我做决定。

与其死守披萨一样大小的团队或单一职责的原则,不如保持实用并专注于这个设计决策可能的优缺点及考查一个特定的软件需要被拆分的原因。为了达到这点,我们需要把我们想要构建的系统的一部分建模为多个候选微服务:定义有界上下文,主体及围绕主体的服务功能。有了这个草图,我们就可以从各方面思考这种设计的益处和缺陷。

 

第 1 段(可获 1.83 积分)

分离变化方面

你希望某个新需求中的变化是独立于另一个的吗?通过分离变化,变化打破某些不变的事物风险将降低.通常,一个有界上下文中的变化是独立于其它上下文的.其中,微服务围绕业务功能进行组织这种方式是达成这种独立的关键因素.由于微服务提供了高级抽象,这些高级抽象对分离变化很有帮助.

分离静态服务

我们是将那些不经常变化的服务分离出来了吗?虽然某些需求经常变化,但其他可能就几乎不会改变,我们甚至可以把它们当作静态的微服务对待.这种静态微服务的例子有那些具有发邮件或SMS,文档或图片格式转换,本地化或者翻译等功能的服务.在大多数系统中,这些功能很少变化,而同时,主要业务功能可能快速变化.通过隔离静态功能,我们降低了破坏静态功能的风险并加强了必要的测试.

第 2 段(可获 1.94 积分)

分离业务关键服务

我们是否将分业务关键操作与非关键操作分离?在某些系统中,我们可以分离那些至关重要的功能并在它们不可用时停止系统.对网络商城来说,这种关键功能可以是购买功能,相比之下,推荐系统和心愿单就不是关键功能.业务关键操作必须尽可能地与非关键的功能分离开.这样才可以最小化非关键功能出问题影响关键操作的概率.对非常关键的功能单独地分离为微服务通常是一个好主意.

第 3 段(可获 1.18 积分)

内聚方面

单个微服务在运行期间是否完全独立于其他微服务?相互依赖是高内聚的标志,对不同微服务来说确是糟糕的候选方案.

团队配置方面

你希望这些微服务由不同的开发团队实现吗?微服务这种方式对分离各个团队的工作十分有利.

技术方面

各个微服务由不同的技术实现会更高效吗?微服务使得多语言实现成为可能,你可以使用不同的编程语言和框架.

第 4 段(可获 1.01 积分)

数据一致性和事务边界方面

你能接受微服务间的最终一致性吗?如果不能,那么这儿可能会有问题,因为分布式系统下的强一致性是一个复杂的话题.系统中有垮微服务的原子性业务操作吗?

非功能性需求方面

这些微服务有不同的性能和可用性需求?这个问题对那些小巧而简单的性能模型的微服务很容易处理,在这些模型中,关键操作被分离开并以最优化的方式实现.另一方面,每一次远程调用会带来延迟并增加失败的风险.依赖多个微服务的业务处理的可用性一般低于那些只依赖一个微服务的处理.

第 5 段(可获 1.53 积分)

安全性方面

是否微服务中的某个微服务处理了高敏感数据但另一个却没有?至少共同的安全机制原则告诉我们单独处理高敏感数据会更安全.

优先考虑对你的系统重要的问题.如果你对上述问题的答案大多数是“yes”,那么继续使用这些微服务选型是一个好主意.重新审视每个微服务选型,考虑下是否进一步的划分微服务是否有意义.微服务的粒度会决定你的选型是否是实用的.

 

 

第 6 段(可获 1.11 积分)

文章评论