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

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

单体架构

分布式架构

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

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

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

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

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

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

网络可靠。

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

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

延迟为零

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

带宽是无限的

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

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

网络是安全的

由于使用了虚拟专用网络（VPN）、安全网络和可信网络等，大多数软件人员往往忽视了这个谬论。但是网络并不安全，在切换到分布式架构时，安全性变得更加具有挑战性。威胁和攻击的表面积增加了一个数量级。

拓扑永远不会改变。

这个谬误指的是整个网络拓扑结构，包括整个网络中使用的所有路由器、集线器、交换机、防火墙、网络和设备。不要假设拓扑是固定的并且永远不会改变。事实上，它是会发生变化的，而且变化是常态。

只有一个管理员

在分布式架构中，从来没有单一的管理员。架构师需要与多个管理员合作和沟通，以维护整个生态系统的健康。由于单一部署单元的特性，单体架构风格不需要这种程度的沟通或协作。

传输成本为零

这里的传输成本不是指延迟，而是指与进行单个REST调用相关的实际成本。与单体架构相比，分布式架构在硬件、服务器、网关、防火墙、新子网、代理等方面的成本要高得多。

网络是同质的

网络并不只由一个网络硬件供应商构成。而且，并非所有这些异构的硬件供应商之间都能很好地协同工作。这反过来会影响网络的可靠性、延迟以及对带宽的假设。