几年前，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的观点。

原文地址：http://www.infoq.com/cn/news/2018/07/decomposing-system-microservices

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com