单体 V/s 分布式架构，你看明白了吗？

在软件领域，存在多种架构风格可供选择，我们需要关注不同架构风格带来的风险。选择符合业务需求的架构风格是一个长期迭代的过程。

架构风格可以分为两大主要类型：单体架构（将所有代码部署在一个单元中）和分布式架构（通过远程访问协议连接多个部署单元）。它们又可以进一步细分为以下多个子架构风格，如下所示。

单体架构

后期我将上述每种架构风格写一个独立的博客。这篇将专注于对架构风格的更广泛分类，并试图了解在使用这些架构时涉及的优缺点。

当从零开始进行软件开发时，通常会首先采用单体架构风格。这可能是默认选择或意外选择，因为在初始阶段，架构师很难对适当的架构风格做出决策。对于小型、简单的应用程序或网站，这种架构风格是一个不错的选择。

这种风格支持的分层机制是技术和领域级别的。以下是在此风格中使用的不同分区：

随着应用程序的增长，可维护性、敏捷性、可测试性和可部署性等特性会受到不利影响。第二个要注意的因素是架构下沉反(sinkhole_ ani)模式，当请求在各层之间以简单的透传处理方式进行传递，而在每个层内部没有执行任何业务逻辑时，这种反模式会出现。

分布式架构风格虽然在性能、可扩展性、可部署性和可用性方面比单体架构风格强大得多，但是为了实现这种强大性能，也存在一些需要权衡的考虑。

在本节中，我们将讨论与分布式架构风格相关的谬论。

网络可靠。

不能假设网络总是可靠的(最近的电信信号事件)。众所周知，网络随着技术的发展变得更加可靠，但网络仍然普遍不可靠。考虑下图

服务B可能完全正常，但由于网络问题，服务A无法与其建立联系。或者更糟糕的是，服务A向服务B发送了一个处理请求，由于网络问题，没有收到响应。系统越依赖网络，就越有可能变得不可靠。

延迟为零

在讨论网络变得更快的观点时，往往会忽视这个谬论。但是考虑一种情况，即在单体架构中，层与层之间的调用在本地进行，延迟只有纳秒级，但在切换到分布式架构后，本地调用变为远程调用，延迟增加到毫秒级。下面的图表中进行了解释。

带宽是无限的

当使用单体架构风格时，这个谬论并不成立，因为组件之间的大部分调用都是本地方法调用。但是，当系统分布在远程位置并需要通过REST调用进行通信时，情况就会发生变化。

请参考下面的图表，其中服务A依赖于服务B来满足用户请求。对于单个请求，这可能是一种不错的体验。但是考虑到有数千个并发请求针对同一个查询，这将导致网络变慢，间接消耗带宽，增加调用之间的延迟。