几年前, Vladik Khononov 和他的团队决定开始使用微服务,但是几个月后他们发现自己陷入了巨大的混乱之中。他在最近于伦敦 Skills Matter 举行的 DDD eXchange 2018 会议上指出,造成这一现象的原因在于,他们只专注于采用酷炫的新技术,而没有关注更加基础的东西,比如模块化以及如何实现模块化。他们在 serverless 框架、平台和消息机制上投入了精力,但是在 思考如何将系统分解为微服务方面却思考很少,换句话说,也就是如何寻找边界并将不同的功能按照边界进行划分。
Khononov 是 Internovus 的 CTO,对他和他的团队来说,起始的信条就是服务越小,它就会越好。这直接导致他们构建了一个分布式单体结构(distributed monolith),在接下来的几年中,他们一直试图摆脱这些微小的服务并且评估了不同的分解策略。
限界上下文(Bounded context)
Khononov 指出通用语言(ubiquitous language)在领域驱动设计(Domain-Driven Design,DDD)中是基础实践,该实践的一种实现方式就是以领域专家的语言与他们进行对话。有时候,你会发现对于相同的业务概念,他们会有不同的心智模型,或者使用相同的术语描述不同的理念,如果这样的话,就预示着这些理念属于不同的限界上下文。从一开始,Khononov 和他的团队就使用这些方法来发现定义服务的边界,每个边界内都会成为一个服务。他指出,这些服务代表了很广泛的业务领域,有时候会导致一个限界上下文涵盖多个业务子域。
业务子域
下一步,他们使用这些业务子域作为边界,然后为每个业务子域创建一个服务。在 Khononov 的经验中,子域和服务之间建立一对一的关系是 DDD 社区非常常见的方式,但是他们并没有满足于此,而是继续努力实现更小的服务。
业务实体
深入研究子域,他们发现了业务实体和流程,然后他们将其抽取到单独的服务中。开始的时候,这种终极方式失败得很惨,但是 Khononov 指出在随后的项目中,它取得了更大的成功。
就这三种策略来说,Khononov 指出,使用限界上下文能够帮助他们找到最大的有效单体边界,然而,尽管它是一个可行的工作模型,但是他认为这种方式并没有很好地匹配微服务的理念。在业务子域和实体间选择的时候,他认为最好的分解等级依赖于正在构建的系统及其用例。他强调,微服务的理念实际上并不是关于单个服务内部如何实现的,而是关于服务之间如何交合和耦合的。
系统分解为微服务的阈值是由微服务所属的用例来定义的。
Khononov 还没有找到一种简单的方式来评估一个系统的设计,但是他相信现在已经有了足够多的启发式设计准则,帮助我们将系统分解为微服务。他认为最有用的几项包括:
- 始终分解至限界上下文等级。除非你有充分的理由,否则不要进一步分解。分布式系统有它们自己所面临的挑战。
- 核心子域是公司挣钱的区域。在进行分解时,确保获取领域的知识并具有恰当的子域。
- 购买或采用通用子域。它们已经解决了一些问题了,如果自己实现的话,是没有竞争优势的。
- 为了支持核心域,我们需要支持子域,但是这不会增加任何的竞争性优势。它们通常非常稳定和简单,在早期阶段就可以进行进一步的分解,直至使其成为实体服务。
- 采用一致性的需求,帮助我们寻找必须放到同一个服务中的函数或方法。
- 确保事件是显式和自描述的。考虑在一个服务中,使用私有事件作为实现细节,而将更为严格的公共事件作为服务的公开接口。
- 寻找按照相同频率进行变化的服务,它们可能能够进行合并以减低复杂性。
- 评估每个服务的接口。如果觉得服务范围太广的话,那么它可能能够拆分为更小的服务,主要站在集成方面,重新考虑评估边界以简化整个系统的设计。
Khononov 在总结中指出,随着系统中服务的平均规模变得越来越小,你将会从一个大泥球般的单体系统,通过限界上下文实现相对较大的服务,进而转化为微服务。但是,他强调,如果你继续让服务变得更小的话,那么最终将会形成一个分布式的大泥球。
实体服务有时被称为反模式,参见 Michael Nygard 和 Stefan Tilkov 的观点。
查看英文原文: Strategies for Decomposing a System into Microservices
评论