【译】5 分钟内从单体架构迁移到微服务架构

• 原文地址：From Monolith to Microservices in 5 Minutes
• 原文做者：Daniel Rusnok
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：YueYong
• 校对者：zenblo，NieZhuZhu

5 分钟内从单体架构迁移到微服务架构

“微服务架构是一种将单体应用程序开发为一套小型服务的方法。”——马丁 · 福勒。

首先，咱们须要明白什么是单体架构。而后我将向你展现如何修改它的域，以便为微服务架构作好准备。最后，我将会简要地告诉你微服务架构的基础知识，并讨论其优缺点。

单体架构

每一种非垂直拆分的架构都是单体架构。软件设计中的垂直拆分意味着将应用程序划分为更多可部署的单元。这并不意味着单体架构不能水平划分。

单体这个词指的是软件的体系结构是由一个后端单元组成。我之因此说后端，是由于我认为单体架构能够在具备多个 UI（如 Web 和移动设备）的同时，仍然能够被看做为一个总体。

组件之间的通讯主要经过方法的调用。若是你的前端和后端是在物理上隔离的，可是它们仍然是一个总体，例如 API 和 Web 客户端。

除非你将后端划分为更多部署单元，不然在我看来你依旧是在使用单体架构。

单域模型

“域是计算机程序的目标主题领域。形式上，它表明特定编程项目的目标主题。”—— 维基百科

用个人话说，域就是软件存在的缘由和目的。我在 3 Domain-Centric Architectures Every Software Developer should Know 这篇文章中写了有关域的几个观点。

下图是一个将在线商城域可视化的结果。

Sales 和 Catalog 子域包含单个的 Product 实体。这种作法是不可取的，由于这将致使一个地方出现更多的问题。这违反了关注点分离原则。

强迫一个实体承担更多的责任，显然是不合理的。实体在这两种上下文中都包含未使用的属性。Sales 不须要知道产品的类别，而且对于 Catalog 来讲，知道 Product 是如何将信息传递给客户并无任何用处。

为了不这个问题，咱们须要找到 Sales 和 Catalog 上下文的边界来将它们分开。这就引出接下来要说的限界上下文。

限界上下文

限界上下文是上下文的边界，参考 Idapwiki.com

要指定限界上下文，咱们须要识别出一个模型仍然有效的上下文范围。

咱们能够经过对域中的每一个实体问一个简单的问题来验证模型，即：这个实体对于哪一个上下文有效？

当一个实体对多个上下文有效时，那么它应该被划分到多个上下文中。每一个实体都具备与上下文相对应的属性。这一步结束后，你的应用就准备好迁移到微服务架构了。

下图是从在线商城域中对 Product 分离的实体类的可视化结果。

微服务架构

微服务架构是由于微服务从而闻名。它是不断细分的单体。微服务将大型系统划分为较小的部分。

限界上下文帮助咱们找到一个微服务的最佳大小。微服务的模型应当尽量小，以最大程度减小与外部世界的通讯；但也不能过于小而失去存在的必要性。

微服务架构使项目具备独立性。该架构支持分离的开发团队、不一样的操做系统、不一样的编程语言以及不一样的业务层架构，例如 [CQRS](levelup.gitconnected.com/3-cqrs-arch… -know-a7f69aae8b6c)。

每个微服务对外都有一个明肯定义的接口，主要经过 HTTP 传输，并以 JSON 的形式实现，例如 REST API。对于微服务之间的通讯，推荐的解决方案是经过 RabitMQ 或 Azure 服务总线 之类的消息平台。

若是没有适当的消息传递工具，那么微服务必须知道其余微服务的位置，而且这个位置是会被随意更改的。

总结

在大型应用程序中，微服务体系结构的开发成本曲线较好。小型应用程序没法从微服务中受益，所以应保持单体架构。

微服务会有分布式系统的成本，好比负载平衡和网络延迟。这些问题经过任务编排器能够很好的解决，常见的有 Kubernetes 和 Azure Service Fabric。

有了对以上这些内容的理解，接下来我推荐你去阅读 Pluralsight course from Mark Heath — Microservices Fundamentals。

参考

• Martin Fowler’s blog post about microservices.
• Martin Fowler’s blog post about Bounded Context.
• Pluralsight course Clean architecture patterns, practices, and principles.

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。