什么是单体架构？

理解单体架构的一种方式，是观察这个术语在建筑领域的本意。在实体建筑设计中，“单体架构”指从巨型岩层中开凿而成的结构。其核心词“单体”的关联含义在于：它由完整岩体构成，形成完全均匀的建筑结构。多个相连的建筑可能均源自同一岩层，它们全都共享着相同的岩石基座。

这个类比可以很好地应用于软件工程的讨论。在这个背景下，单体架构执行不同的业务功能（即“建造不同的建筑”），这些功能各不相同，但共享同一个代码库（或岩石基底）。

几十年来，单体架构作为传统的软件模型一直主导着软件开发。然而，现在任何关于单体架构的讨论都必须考虑其重要替代方案：微服务，而微服务的使用正在日益增加。

在单体软件中，应用程序所需的所有代码都集中保存在一个位置。这为开发人员提供了额外的简化优势，因为系统仅接受一种格式的通信。系统无需承担从不同服务翻译通信的负担。这使得诸如 DevOps 等开发流程更易于执行。

单体应用程序通常包含以下组件：

• 客户端用户界面 (UI)：在此语境中，“客户端”指的是显示在用户计算设备上的内容。UI 管理用户所看到的内容，包括图像、文本以及通过 UI 屏幕传输的其他信息，例如与浏览器操作相关的信息。

• 数据库：单体架构使用关系型数据库管理系统 (RDMS)，该系统由多个表组成。

• 服务器端应用程序：服务器端应用程序以某种方式处理服务器资源，可访问服务器资源，如内存、CPU 和存储。

更深入地分析单体架构，我们可以看到它具有几个显著的优势：

• 应用程序开发更轻松：使用单一代码库构建的应用程序更易于开发。

• 部署简单：单体架构使用单个可执行文件或目录，这简化了部署过程。此外，单体架构更容易维护，因为它使用的组件更少。

• 调试方便：在单体架构中，测试和调试操作的工作量明显较小。这些端到端的测试操作可以通过集中日志系统来执行。

• 安全性提高：由于单体架构是封闭系统，其数据处理活动完全自成体系，因此能够更好地防护网络威胁。

在使用单体架构时，我们可以看到，其表面上的优势（高度稳定性）也可能被视为一种劣势：

• 对新技术的抵抗：由于单体应用通常高度耦合，将新技术集成到其中可能较为困难。事实上，通常情况下，需要对单体应用程序进行完全改造才能接受新增功能。

• 可扩展性降低：可扩展性是单体架构面临的最大挑战。即便所需的扩展量相对较小（例如调整单个功能），您仍可能需要有效地拆解系统并重新构建，以使其反映新的更改。这可能会非常耗时耗力。

微服务架构是一种云原生架构风格，其中一个应用程序由多个松散耦合的小型组件或服务组成。微服务应用程序拥有自己的技术栈（即一组协同工作的技术，用于完成特定任务）。

微服务提供的主要业务优势之一在于，系统可以轻松更新，以反映应用程序的新部分，而不会影响整个应用程序。这可以节省大量的时间和人力成本。

微服务架构的一个紧密替代方案是事件驱动架构 (EDA)，有时会与微服务结合使用。在 EDA 中，状态变化以事件的形式表示，并在系统中进行调度。EDA 提供松散耦合和实时处理，使其成为一个具有吸引力的选择。

微服务天生适合持续增长，并能够适应技术变革。它们带来的主要优势包括：

• 随需扩展：与单体架构相比，微服务提供了更高的可扩展性。由于各个服务被拆分为模块，向上扩展的指令可以同时传递给多个服务。此外，微服务更适合处理大型应用程序。

• 面向自动化：微服务使组织能够自动化持续集成/持续交付 (CI/CD) 流程。这使得代码更新可以按持续的计划进行开发。
  

• 独立运行：微服务架构将每个服务拆分为独立的运行单元。通过实现独立运行，一个服务的工作流程不会干扰其他服务的工作流程。

尽管微服务具有诸多优势，但其整体复杂性也导致了一些使用中产生的问题：

• 测试复杂：在微服务架构中，只有应用的各个组件全部通过测试后，调试工作方能启动。这包括检查依赖关系、缓存操作和数据访问。每个部分都必须正常运行，而且所有部分必须协同工作。

• 安全问题：微服务系统内各种进程之间发生的通信需要使用 API 网关。这可能会在身份验证和其他重要进程方面造成安全漏洞。

• 延迟增加：微服务在应用程序扩展方面表现尤为出色，但这种能力也带来了额外的延迟和滞后。每一个扩展细节都会增加系统的复杂性和数据量，从而可能减慢处理速度。

微服务的出现使软件开发演变成了微服务架构与传统单体架构之间的“双雄争霸”。

乍一看，微服务似乎是更优的架构，因为它是后期发展起来的。然而，这种假设显得目光短浅。仍然有许多计算场景从单体架构模型的简洁性中获益。

此外，这两种软件架构各有优劣，组织在选择其中一种系统之前，应认真评估两者，并考虑其预期的应用程序开发需求。

在具体对比方面，单体架构与微服务在多个关键方面存在差异：

• 结构：单体应用程序作为一个整体构建，而微服务架构则采用不同的方法，由一组可部署的、较小且独立运行的服务组成。

• 创建：由于整体设计更为简单，单体系统比基于微服务架构的系统更易于构建。微服务架构需要使用更复杂的设计来规划和构建。

• 复杂性：随着系统复杂性的增加，它越适合采用微服务架构模型，因为微服务提供了一个动态的编程基础，能够支持未来添加其他功能和新特性。

• 可扩展性：微服务架构基于定义明确的独立服务，这些服务易于被划分为模块化形式，松散耦合，并可通过 API 相互通信。而单体架构由于核心结构厚重、软件高度耦合，其适应性较差。

• 调试：调试过程（或使用软件检测代码问题）是负责任运维的重要环节。虽然有人可能认为这是微服务的明显优势，但实际情况恰恰相反。调试在更直观的环境中效果更好，而这正是单体架构所提供的。

• 上市时间：上市时间是商业领域的一个关键指标，用于衡量产品从制造到进入分销渠道的速度。单体应用程序仅使用一个代码库，这使开发人员无需整合来自多个服务的软件，从而缩短了上市时间。

• 业务能力：无论哪种架构，在组织初次使用时都可能足够有效。挑战出现在业务增长阶段，当企业发展出需要更大运营规模的需求时。这时，微服务真正体现了其价值，因为它提供的扩展方式比单体架构更多。

了解何时使用某种架构风格至关重要，同时也要根据实际需求选择最合适的系统。以下是单体系统的最佳使用场景：

• 初创企业:初创企业需要快速开展业务，同时也需节约宝贵的启动资金。出于这些原因，单体架构模型对于新公司来说非常合适。单体系统易于学习、使用快速且成本低廉，而转向微服务架构可能会耗费大量时间和资金。

• 基础项目：单体架构非常适合处理应用程序或原型开发，前提是所开发的应用或原型本身较为简单。这得益于使用单一代码库的便利。软件可以在无需整合来自不同来源的数据的情况下完整开发，从而更易于使用。

微服务适用于许多项目，包括最复杂的应用程序：

• 电子商务：电子商务在相对短的时间内取得了显著发展，广泛重塑了无数零售商的销售策略，使它们摆脱了与实体店销售运营相关的大量建筑成本。2023 年电子商务销售市场达到令人瞩目的 5.8 万亿美元，这一增长得益于像 Amazon (AWS) 这样无处不在、市场敏锐的零售商。¹

• 娱乐平台：在运营国际娱乐平台时，必须能够承受轻负载和重负载。2009 年，流媒体巨头 Netflix 将其系统从单体架构迁移到基于云的微服务架构。Netflix 的后端现在包含来自 Apache、Cassandra、Chukka、Gluster、Hadoop、Hive、JavaTM、MySQL 的应用程序，并提供充足的负载均衡支持。

• 专家团队：如前所述，微服务不如单体架构易用。他们需要具备成熟技能的从业人员。此外，由于运营的整体复杂性，微服务架构通常需要多个技术人员的支持。因此，配备齐全的专业团队非常适合从事微服务架构及微服务应用程序开发工作。