“微服务架构是一种将单体应用程序开发为一套小型服务的方法。”——马丁 · 福勒。
首先，我们需要明白什么是单体架构。因此，我将向你展示如何修改它的域,，以便为微服务架构做好准备。最后，我将会简要地告诉你微服务架构的基础知识，并讨论其优缺点。
单体架构
每一种非垂直拆分的架构都是单体架构。软件设计中的垂直拆分意味着将应用程序划分为更多可部署的单元。这并不意味着单体架构不能水平划分。
单体这个词指的是软件的体系结构是由一个后端单元组成。我之所以说后端，是因为我认为单体架构可以在具有多个 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 分离的实体类的可视化结果。
微服务架构
微服务架构是因为微服务从而闻名。它是不断细分的单体。微服务将大型系统划分为较小的部分。
限界上下文帮助我们找到一个微服务的最佳大小。微服务应具有足够小的模型，以最大程度减少与外部世界的通信，而出于存在的原因，则应足够大。
微服务架构使项目具有独立性。该架构支持分离的开发团队、不同的操作系统、不同的编程语言以及不同的业务层架构，例如 [CQRS](https://levelup.gitconnected.com/3-cqrs-architectures-that-every-software-architect-should -know-a7f69aae8b6c)。
每一个微服务对外都有一个明确定义的接口，主要通过 HTTP 传输，并以 JSON 的形式实现，例如 REST API。对于微服务之间的通信，推荐的解决方案是通过 RabitMQ 或 Azure 服务总线 之类的消息平台。
如果没有适当的消息传递工具，那么微服务必须知道其他微服务的位置，并且这个位置是会被随意更改的。
总结
在大型应用程序中，微服务体系结构的开发成本曲线较好。小型应用程序无法从微服务中受益，因此应保持单体架构。
微服务会有分布式系统的成本，比如负载平衡和网络延迟。这些问题可以通过任务编排器很好的解决，例如 Kubernetes 和 Azure Service Fabric。
有了对以上这些内容的理解，接下来我推荐你去阅读 Pluralsight course from Mark Heath — Microservices Fundamentals。