微服务架构中的服务边界与服务识别 - 好文

前言

在我们进行微服务架构设计和改造过程中，一个不可避免的问题是如何确定服务边界、如何进行服务识别，微服务的划分粒度究竟如何确认。我们可能会听到，服务既不能太大，也不能太小，当然这是一个笼统的概念。那么，问题来了，究竟多大是大，多小是小。

比如，以下原则是否可行？

*
一个微服务应该包含N行代码

*
将系统中每一个功能都定义为一个服务

另外，考虑一个问题：如果服务划分太细，会出现什么问题？

*
服务爆炸

*
服务交叉引用

*
代码过度耦合

所以，接下来，我们将讨论在微服务架构设计中，如何进行服务定义与划分。

良好设计的服务包含的五个特征

一个设计良好的服务应包含以下五个特征：

特征一：服务不与其他服务共享数据库

举个例子：如果你定义了一个微服务后台需要访问某个表，与此同时存在别的多个服务也需要访问同一个表，那么这就意味着你的数据库就是一个耦合数据源。一个良好设计的服务应只包含特定的独有的数据库表，并且不与其他服务共享。

我们在开发新服务时一个主要基本原则是，它们不应该跨越数据库边界。每个服务都应该依赖于它自己的底层数据存储集，在这样的前提下，我们才可以进行集中访问控制，审计日志记录，缓存逻辑。

特征二：服务应包含尽可能少的数据库表

正如我们之前所提及，微服务的理想大小是足够小，但不能无限小。每个服务的数据库表数量也是如此。

特征三：一个服务要么包含完整的业务含义，要么是放之四海皆通用的公共服务。

我们通常会通过定义服务的输入输出来确定服务边界，比如：服务既可以是一个开放的API，也可以是一个处理进程（处理文件并进行数据存储，比如我们常见的日志处理服务），把握好这一点，你才有可能设计良好的服务。

特征四：一个良好的服务应首先确保其数据可用性。

在设计微服务时，我们需要考虑系统中哪些服务将依赖于这个新服务，假如服务宕机导致数据不可用会对系统产生哪些影响。考虑到这一点，我们就可以适当地为该服务设计数据备份和恢复系统。

特征五：在一个业务系统中，一个服务只能是并且唯一的可信来源。

举个例子，当我们从电子商务网站订购东西时，会生成一个订单ID。其他服务可以使用此订单ID查询订单服务，以获得关于订单的完整信息，基于发布/订阅的理念，在服务之间传递的数据应该只能是订单ID，而不是订单本身的属性信息，只有订单服务拥有完整的订单信息，并且只有订单服务是特定订单信息的唯一可信来源。

更大组织的服务设计考量

对于更大的组织，整个团队都可以专注于拥有某个特定服务，在确定服务边界时，需要考虑组织机构因素。另外，还有两个需要注意的问题：独立的发布计划和不同的正常运行时间的重要性。实际实践中，比较成功的做法是，微服务的实现要么是基于软件设计原则，比如基于
领域驱动设计 <https://en.wikipedia.org/wiki/Domain-driven_design>
或者是面向服务架构设计，要么是基于可以很好的反映组织架构的设计原则。

比如，对于支付团队来说，他们可以支付服务或信用卡验证服务，这就是他们向外界提供的服务，这其实与软件无关，这就是从组织架构的角度来讲，他们作为一个业务部门可以向外界提供的所有服务。

说到团队，这就涉及到一个著名的“两个披萨原则
<http://wiki.mbalib.com/wiki/%E4%B8%A4%E4%B8%AA%E6%8A%AB%E8%90%A8%E5%8E%9F%E5%88%99>
”：即团队大小不宜超过两个披萨可以供给的人数

如何确认一个服务是否太小或者没有正确定义

这里有几个指标可以来判断：

*
服务之间是否过度依赖：如果两个服务在不断地相互调用，那么这就是过度耦合，将他们整合到一起或许是一个更好的选择。

*
如果单独定义、设置服务所花费的精力和代价远远大于其带来的好处和便利，那么你就需要考虑你所定义的这个服务是否过小。

https://buttercms.com/books/microservices-for-startups/microservice-boundaries-5-characteristics-to-guide-your-design

<https://buttercms.com/books/microservices-for-startups/microservice-boundaries-5-characteristics-to-guide-your-design>

热门工具换一换