在科技领域，趋势变化的速度快得难以跟上。引人注目的术语会在聚光灯下闪耀一至两年，然后被归类为过时的技术。昨天的热门趋势将成为明天被遗忘的时尚。
微服务是近年来一直受到关注的趋势。自 2016 年以来一直被宣传为下一个大事件，但现在技术博客都在发布文章，质疑微服务是否已经死了。 即使是亚马逊这样的世界最大的微服务提供商之一，亚马逊 Prime 也已经回归到了单体架构。
与一些更为耸人听闻的标题所暗示的相反，微服务并没有完全死去。它们只是在不断演变，因为显而易见的是，微服务并不是所有问题的答案。考虑到这一点，让我们深入了解一些围绕微服务的不断发展的术语。我们将重点定义微服务、宏服务和单体架构，以帮助您决定哪种架构风格是下一个项目的最佳选择。
什么是微服务？
微服务：Microservices
理解微服务、宏服务和单体架构之间的差异最简单、最直接的方法是先简要解释每种架构。让我们从最明显的开始：什么是微服务？简而言之，微服务是专门提供特定功能的小型组件。它们通常是解耦的，并设计为在项目和应用程序之间重用。
亚马逊的微服务是微服务实施中最著名且广泛使用的例子之一。它们是亚马逊去中心化和分布式软件策略的一个组成部分。亚马逊的微服务可用于从缓存到存储对象再到构建数据库的各个方面。 如果您正在寻找一个功能齐全、强大的微服务环境的示例，几乎可以做任何事情，那么亚马逊对微服务的定义值得一看。
Airbnb 对微服务的使用是微服务在分布式平台上如何使用的另一个很好的例子。 Netflix、Uber、Etsy 和 SoundCloud 也在内部正确使用和实践了微服务架构。 微服务允许每个组件都能够扩展，同时也更容易维护，因为每个组件可以由更小的工程团队管理。
微服务的优点
- 部署速度更快
- 多个团队可以在同一个组件上工作
- 可扩展
- 可在多个应用程序中重复使用
微服务的缺点
- 成本可能较高
- 增加了处理时间
- 需要 API 管理（和零信任策略）
- 监控可能会复杂化
- 版本控制在多个团队使用同一微服务时可能会变得复杂
单体架构是什么？
单体架构：Monolith
单体架构，也称为“单体”，在近年来也是一个热门话题。然而，实际上，单体架构只是传统归一化软件设计模型的另一个名称。单体也可以被描述为“自包含”，其中每个函数或组件都紧密耦合，而不是微服务架构的模块化开发。
单体架构的例子很多，因为大多数自包含的软件和应用程序都是单体架构。电子商务应用程序可能是单体架构的一个示例，因为每个组件都与同一代码库和后端交互。传统软件，如文字处理器和金融应用程序，也经常是单体架构。
单体架构的优点
- 比基于微服务的架构具有更好的吞吐量
- 更容易测试和调试
- 只需跟踪一个代码库，日志记录更简单
- 比微服务更容易配置和监控
- 部署更简单，因为只需要下载一个包到服务器
单体架构的缺点
- 代码库可能难以理解
- 修改速度较慢且更难掌控
- 更改可能导致意想不到的下游影响
- 编译时间更长
- 加载时间更长
什么是宏服务？
宏服务：Macroservices
如果您熟悉技术，您大概已经听说过微服务和单体架构。但宏服务是相对新兴的技术理念，所以它的趋势性还不如前者那么明显。这种情况很可能会改变，因为宏服务或许可以在微服务和单体架构之间取得平衡。
SystemSoft Technologies 将宏服务描述为“大型或笨重的微服务，服务来自SOA（面向服务的架构）或部分单体”。 Even Financial 更广泛地描述了宏服为“几个大型、松散耦合的服务”。 简单来说，它们是非常大或复杂的微服务，或者它们是简化和精简的单体。然而，它们不仅仅是这样，因为这三种架构风格之间仍然存在一些关键差异。
在 Even Financial 的 PPT 中，他们阐述了他们对宏服务的使用方法和使用宏服务的理念。 Even Financial 对宏服务的采用旨在作为从单体架构过渡到微服务的桥梁。在他们的示例中，他们建议每个团队决定他们将需要的服务，比如操作目录或处理图像。他们建议使用宏服务，一旦架构设置完成，然后可以将其转换为微服务。
软件架构师 Mehmet Ozkaya 通过一个方便的示意图详细解释了软件架构的演变。
宏服务架构介于单体和纳米服务之间。来源：Mehmet Ozkaya.
在这个宏服务的示例中（他们也将其称为“模块化单体”），您可以看到每个宏服务都像独立的微服务一样运行。但是它们共享一些资源，其中个别服务连接到共享的数据库。
宏服务的优点
- 比微服务更容易监控
- 在多个功能之间共享数据
- 比单体架构松散耦合
- 像微服务一样模块化
- 更容易升级
宏服务的缺点
- 比微服务更紧密耦合
- 部署速度比微服务更慢
- 可能会引起安全问题
- 仍然可能遇到性能问题
- 有时可能是一个中间步骤，而不是一个完整的解决方案
微服务、宏服务和单体架构的区别
区分微服务、宏服务和单体架构可能很困难，因为这三种架构风格之间存在很多重叠。例如，单体架构仍然可以采用类似微服务的基础设施。或者，随着每个微服务组件的角色变得更加复杂，它可能会采用更多的单体设计。
简而言之，微服务旨在实现一个目的，通常通过类似 HTTP 的协议进行。另一方面，单体架构更像是传统软件，这有一些优点，特别是在金融货币化领域。 但单体也有缺点，与由小型、更易管理的模块组成的架构不同，单体要求每个人都在同一个代码库上工作。这意味着一个简单的错误可能会产生无法预料的影响。
宏服务具有微服务的大部分优点，同时一定程度上避免了困扰单体架构的一些问题。宏服务行为上类似于传统的单体架构，但更可定制，因为它实际上是一系列统一在一个 UI 下的模块。
宏服务和微服务之间的主要区别之一是，宏服务与其他宏服务或单体应用共享数据存储。它们通常还提供对多个数据对象和处理过程的访问，这有助于避免一些常见于微服务的延迟问题。
对微服务、宏服务和单体架构的最终思考
无论您最终决定采用哪种架构风格，都应该记住其这些。如果您正在处理一个单体代码库，应将微服务和宏服务放在心中，以帮助控制功能不要失控。 宏服务可以被认为是将遗留的单体解决方案转变为基于微服务的应用程序的有用步骤。一旦单体被转换为宏服务，就更容易将每个组件转换为微服务。
无论您决定采用哪种架构风格，有一点是肯定的。合理的设计和传统的编程原则将比任何时髦的趋势或闪亮的花招更有助于您的开发。
本文整理至 What’s the Difference: Microservice, Macroservice, Monolith，作者 J. Simpson