【译】5 分钟内从单体架构迁移到微服务架构
“微服务架构是一种将单体应用程序开发为一套小型服务的方法。”——马丁 · 福勒。 首先，我们需要明白什么是单体架构。因此，我将向你展示如何修改它的域,，以便为微服务架构做好准备。最后，我将会简要地告诉你微服务架构的基础知识，并讨论其优缺点。 单体架构 每一种非垂直拆分的架构都是单体架构。软件设计中的垂直拆分意味着将应用程序划分为更多可部署的单元。这并不意味着单体架构不能水平划分。 单体这个词指的是软件的体系结构是由一个后端单元组成。我之所以说后端，是因为我认为单体架构可以在具有多个 UI（如 Web 和移动设备）的同时，仍然可以被看作为一个整体。 组件之间的通信主要通过方法的调用。 如果你的前端和后端是在物理上隔离的，但是它们仍然是一个整体，例如 API 和 Web 客户端。 除非你将后端划分为更多部署单元，否则在我看来你依旧是在使用单体架构。 单域模型 “域是计算机程序的目标主题领域。 形式上，它代表特定编程项目的目标主题。”—— 维基百科 用我的话说，域就是软件存在的原因和目的。我在 3 Domain-Centric Architectures Every Software Developer should Know 这篇文章中写了有关域的几个观点。 下图是一个将在线商城域可视化的结果。 Sales 和 Catalog 子域包含单个的 Product 实体。这种做法是不可取的，因为这将导致一个地方出现更多的问题。这违反了关注点分离原则。 强迫一个实体承担更多的责任，显然是不合理的。实体在这两种上下文中都包含未使用的属性。Sales 不需要知道产品的类别，并且对于 Catalog 来说，知道 Product 是如何将信息传递给客户并没有任何用处。 为了避免这个问题，我们需要找到 Sales 和 Catalog 上下文的边界来将它们分开。这就引出接下来要说的限界上下文。 限界上下文 限界上下文是上下文的边界，参考 [Idapwiki.com](https://ldapwiki.com/wiki/Bounded Context) 要指定限界上下文，我们需要识别出一个模型仍然有效的上下文范围。 我们可以通过对域中的每个实体问一个简单的问题来验证模型，即：这个实体对于哪个上下文有效？ 当一个实体对多个上下文有效时，那么它应该被划分到多个上下文中。每个实体都具有与上下文相对应的属性。这一步结束后，你的应用就准备好迁移到微服务架构了。 下图是从在线商城域中对 Product 分离的实体类的可视化结果。 微服务架构 微服务架构是因为微服务从而闻名。它是不断细分的单体。微服务将大型系统划分为较小的部分。...