什么是Monolith，即单片架构？
单个应用程序，我们称之为Monolith，是通过单个部署单元提供的应用程序。示例可以是作为单个WAR提供的应用程序，也可以是具有单个入口点的Node应用程序。
例：
让我们举个例子：一个经典的在线商店。我们的业务范围包括订单，项目，客户，运输和付款。提供的与服务交互的方式有：REST api和Web前端。
构建Monolith，所有这些东西都将在同一个工件中进行管理。我没有编写“相同的进程”，因为对于我们的工件的多个实例将运行以处理更高负载的情况，这不是真的。
请参阅下图中的示例，其中所有部件都在同一部署单元中：
优点：
Monolith的一大好处是它更容易实现。在Monolith中，您可以在开始考虑进程间通信之前快速开始实现业务逻辑。
另一件事是端到端（E2E）测试。在单片架构中，这些测试更容易执行，因为monolith带来了一切。
关于操作：Monolith 易于部署且易于扩展。对于部署，您可以使用脚本上传工件并启动应用程序。通过将Loadbalancer放在应用程序的多个实例之前来实现扩展。正如您所看到的，Monolith很容易操作。
在阅读了关于微服务的所有这些很酷的东西之后，让我们来看看不那么阳光的一面......
缺点：
巨石倾向于从其清洁状态退化为所谓的“大泥球”。简而言之，这是一个违反建筑规则的状态，随着时间的推移，组件一起成长。
这种退化减缓了开发过程 - 每一个未来的功能都将难以开发。由于组件在一起，所以它们也需要一起更换。创建新功能可能意味着触摸5个不同的地方，5个地方你必须编写测试，5个地方可能会对现有功能产生不必要的副作用。
之前我曾说过Monolith中的缩放很容易。它确实是 - 直到它不是。当只有系统的一个部分需要额外资源时，扩展可能会有问题。在单一体系结构中，您无法扩展系统的单个部分。
目前几乎没有任何隔离。模块中的问题或错误可能会减慢或降低整个应用程序。
构建Monolith通常会选择框架。从最初的选择中切换或更新可能很困难，因为它需要立即完成并且对于系统的所有部分。
什么是微服务，即微服务架构？
在微服务架构中，松散耦合的服务彼此交互以完成属于其业务能力的任务。
微服务几乎得名于服务小于整体环境的事实。微观更多的是关于削减业务能力而不仅仅是规模。
与Monolith相比，使用微服务，您可以拥有多个部署单元。每项服务都可以自行部署。
例：
我们来看看前面的例子：网上商店。
像以前一样，我们有了界限： 订单，商品，客户，运费和付款。
现在的区别是这些都有自己的服务和数据库。它们是松散耦合的，可能跨越其边界与不同的协议（例如REST，gRPC，消息传递）进行交互。
下图显示了与之前相同的示例，但已作为微服务进行了分解。我忽略了每个服务之间的沟通，因为这可能会使图表明显混乱，但我希望你仍然能够理解：
但这种变体的好处和缺点是什么？
优点：
这是比较容易让他们模块化。它在技术上是由单一服务之间的硬边界强制执行的。
在大公司中，不同的团队可以拥有不同的服务。这些服务可以在整个公司中重复使用。它还允许团队主要独立地处理他们的服务。无需协调团队之间的部署。随着团队数量的增加，更好地发展规模。
微服务更小，范围更小。因此，它们通常更容易理解和测试。
较小的尺寸在编译时，启动时间和执行测试所需的时间方面也有帮助。所有这些因素都有利于开发人员的工作效率，因为这意味着在开发的每个阶段等待的时间更少。
较短的启动时间和彼此独立部署微服务的可能性确实付入了CI / CD。与定期部署整体结构相比，它更加平滑。
每个微服务都不受其他服务中使用的技术的约束。我们到处都可以使用最合适的技术。可以快速重写旧服务以使用更新的技术。
与单片方法相比，具有更好的故障隔离。精心设计的分布式系统将在单个服务崩溃后继续存在。
缺点：
一切听起来都不错，但也有一些缺点需要考虑：
拥有分布式系统会带来自身的复杂性：
在分布式系统中，您必须处理部分故障，更难以处理的测试交互（E2E测试）以及实现服务之间交互的难度。
另一件需要考虑的事情是，在整体中交易更容易处理。这个问题的解决方案是Saga模式，这是一个很好的解决方案，但在实践中实施起来仍然比较麻烦。
让我们来看看操作方面的问题：
有一个操作开销，一堆微服务比一些单元巨型实例更难操作。
除了困难之外，微服务还需要比传统单块更多的硬件。有时微服务可以胜过单个整体，如果有部分需要将其扩展到极端。
影响多个服务的变化需要在多个团队之间进行协调，如果团队之前还没有任何联系，这可能会特别困难。
摘要
没有银子弹！一切都是权衡利弊。
首先，它取决于您的组织结构。你有6个团队将在一个产品上工作？微服务可能是一个很好的选择。
你有一个由3个开发者组成的团队？可能他们将很好地建造和维护巨石（参见：维基百科：康威定律）
其他因素是变化率和复杂性。高变化率和高复杂性都是将我的决定更多地转移到微服务架构的因素。
相比之下，当你不熟悉这个领域时，从Monolith开始可能真的很有用。只要帮自己一个忙，尽量保持模块化。如果您决定将Monolith切割成多种服务，这将简化方式。
如果你对一篇关于微服务体验的帖子更感兴趣 - 请随时阅读我的文章：微服务教我两年多了
via https://programmerfriend.com/monolith-vs-microservices/
