在软件领域，存在多种架构风格可供选择，我们需要关注不同架构风格带来的风险。选择符合业务需求的架构风格是一个长期迭代的过程。
架构风格可以分为两大主要类型：单体架构（将所有代码部署在一个单元中）和分布式架构（通过远程访问协议连接多个部署单元）。它们又可以进一步细分为以下多个子架构风格，如下所示。
单体架构
- 分层架构
- 流水线架构
- 微内核架构
分布式架构
- 基于服务的架构
- 事件驱动架构
- 空间驱动架构
- 面向服务的架构
- 微服务架构
后期我将上述每种架构风格写一个独立的博客。这篇将专注于对架构风格的更广泛分类，并试图了解在使用这些架构时涉及的优缺点。
单体架构
当从零开始进行软件开发时，通常会首先采用单体架构风格。这可能是默认选择或意外选择，因为在初始阶段，架构师很难对适当的架构风格做出决策。对于小型、简单的应用程序或网站，这种架构风格是一个不错的选择。
这种风格支持的分层机制是技术和领域级别的。以下是在此风格中使用的不同分区：
- 展示层 - 负责用户界面和处理用户输入。
- 业务逻辑 - 执行应用程序的核心业务逻辑。
- 数据库访问 - 负责访问数据库的数据访问对象。
- 应用程序集成 - 与其他服务进行集成（例如通过消息传递或REST API）
为什么要使用这种风格？
- 小型应用程序的不错选择。
- 在项目初期非常方便使用。
- 适用于预算紧张和时间有限的情况。
- 大多数开发人员和架构师都相当简单和熟悉。
- 成本较低，对于架构师在分析业务需求和要求时还不确定使用哪种风格时是一个不错的选择。
为什么不使用这种风格？
随着应用程序的增长，可维护性、敏捷性、可测试性和可部署性等特性会受到不利影响。第二个要注意的因素是架构下沉反(sinkhole_ ani)模式，当请求在各层之间以简单的透传处理方式进行传递，而在每个层内部没有执行任何业务逻辑时，这种反模式会出现。
分布式架构
分布式架构风格虽然在性能、可扩展性、可部署性和可用性方面比单体架构风格强大得多，但是为了实现这种强大性能，也存在一些需要权衡的考虑。
在本节中，我们将讨论与分布式架构风格相关的谬论。
谬论：
网络可靠。
不能假设网络总是可靠的(最近的电信信号事件)。众所周知，网络随着技术的发展变得更加可靠，但网络仍然普遍不可靠。考虑下图
服务B可能完全正常，但由于网络问题，服务A无法与其建立联系。或者更糟糕的是，服务A向服务B发送了一个处理请求，由于网络问题，没有收到响应。系统越依赖网络，就越有可能变得不可靠。
延迟为零
在讨论网络变得更快的观点时，往往会忽视这个谬论。但是考虑一种情况，即在单体架构中，层与层之间的调用在本地进行，延迟只有纳秒级，但在切换到分布式架构后，本地调用变为远程调用，延迟增加到毫秒级。下面的图表中进行了解释。
带宽是无限的
当使用单体架构风格时，这个谬论并不成立，因为组件之间的大部分调用都是本地方法调用。但是，当系统分布在远程位置并需要通过REST调用进行通信时，情况就会发生变化。
请参考下面的图表，其中服务A依赖于服务B来满足用户请求。对于单个请求，这可能是一种不错的体验。但是考虑到有数千个并发请求针对同一个查询，这将导致网络变慢，间接消耗带宽，增加调用之间的延迟。
网络是安全的
由于使用了虚拟专用网络（VPN）、安全网络和可信网络等，大多数软件人员往往忽视了这个谬论。但是网络并不安全，在切换到分布式架构时，安全性变得更加具有挑战性。威胁和攻击的表面积增加了一个数量级。
拓扑永远不会改变。
这个谬误指的是整个网络拓扑结构，包括整个网络中使用的所有路由器、集线器、交换机、防火墙、网络和设备。不要假设拓扑是固定的并且永远不会改变。事实上，它是会发生变化的，而且变化是常态。
只有一个管理员
在分布式架构中，从来没有单一的管理员。架构师需要与多个管理员合作和沟通，以维护整个生态系统的健康。由于单一部署单元的特性，单体架构风格不需要这种程度的沟通或协作。
传输成本为零
这里的传输成本不是指延迟，而是指与进行单个REST调用相关的实际成本。与单体架构相比，分布式架构在硬件、服务器、网关、防火墙、新子网、代理等方面的成本要高得多。
网络是同质的
网络并不只由一个网络硬件供应商构成。而且，并非所有这些异构的硬件供应商之间都能很好地协同工作。这反过来会影响网络的可靠性、延迟以及对带宽的假设。
