将系统分解为微服务的策略是什么

今天就跟大家聊聊有关将系统分解为微服务的策略是什么，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

成都创新互联制作网站网页找三站合一网站制作公司,专注于网页设计,网站设计制作、成都网站设计,网站设计,企业网站搭建,网站开发,建网站业务,680元做网站,已为近1000家服务,成都创新互联网站建设将一如既往的为我们的客户提供最优质的网站建设、网络营销推广服务!

几年前，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在总结中指出，随着系统中服务的平均规模变得越来越小，你将会从一个大泥球般的单体系统，通过限界上下文实现相对较大的服务，进而转化为微服务。但是，他强调，如果你继续让服务变得更小的话，那么最终将会形成一个分布式的大泥球。

看完上述内容，你们对将系统分解为微服务的策略是什么有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联行业资讯频道，感谢大家的支持。