单片架构与微服务：哪种最适合您？

单体架构是传统的软件模型。微服务代表了后期的软件开发方式，但这并不意味着单体架构已经过时。

假设您刚开始为一家科技初创公司工作，并被指派为新公司实施 IT 计划。您面临一系列决策，但没有哪一项决策像选择单体架构或微服务架构那样基础且影响深远。软件架构的选择不应孤立进行，也不应在不了解组织当前及未来数据处理需求的情况下作出，因为无论选择哪种架构方式，都将深刻影响组织有效实现其业务目标的能力。

因此，这里的利害关系非常重大。而且因为您是新任命的 IT 总监，这对您个人而言也是一个重要的决策，如果您明智地选择，可能会为您带来前所未有的职业发展机会。

那么，您会选择哪一种？首先，让我们来了解您的选项。

如前所述，单体架构是传统的软件开发模型。在这种架构中，一个代码库承担多个功能（即业务功能）。计算机内核控制所有功能。在单体应用中，整个应用所需的所有代码都集中维护在一个中心位置。

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

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

• 数据库：单体架构使用关系型数据库管理系统 (RDBMS)，这是一种将数据组织成行和列的数据库类型。这些行和列形成一个表，其中的数据点相互关联。

• 服务器端应用：服务器端应用处理服务器资源，如内存、CPU 和存储。

使用单体架构具有许多优点：

• 简化应用程序开发：使用单一代码库构建的应用程序更容易开发，且开发速度更快。

• 部署基础：单体架构使用一个可执行文件或目录进行工作，这使得部署相对简单。由于组件较少，单体架构也更容易维护。

• 调试简单：测试和调试操作较少涉及单体架构。端到端测试操作由中央记录系统执行。

• 增强安全性：由于单体架构是一个封闭系统，因此其数据处理活动完全受控，并可免受网络威胁。

单片架构的使用也可能带来问题：

• 对新技术具有抵抗性：由于单体应用通常是高度耦合的，将新技术集成到其中可能比较困难。

• 可扩展性受限：即使所需的扩展量相对较小（例如调整单个功能），您可能也需要有效地拆解并重建系统以反映新的更改。这可能会非常耗时且劳动强度大。

另一种软件开发模型微服务，是一种云原生架构风格。在微服务架构中，应用程序基于多个松散耦合的独立组件或服务构建。微服务应用程序拥有自己的技术栈，即一组协同工作的技术集合，用于完成特定任务。

微服务的主要优势在于，系统可以轻松更新，以在应用程序中实现新的业务功能，而不会影响整个系统。这可以为时间和人力带来显著节省。

微服务的优势很多。它们能适应持续的业务增长和新的技术变革：

• 可扩展性提高：与单体架构相比，微服务在可扩展性方面表现出色。微服务架构中的各个服务被拆分为模块，可以通过单一指令同时向多个服务发送扩展请求。此外，微服务非常适合处理大型且复杂的应用程序。

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

• 独立运行：微服务架构将每个服务拆分为一个独立的操作单元。在这种独立运行模式下，一个微服务应用程序的 工作流程不会干扰其他微服务应用程序的工作流程。

微服务提供了明确的优势，但其复杂性确实会产生某些问题：

• 测试难：在微服务中，调试操作要等到应用程序的各个部分经过测试后才开始。包括检查依赖关系、缓存活动和数据访问。

• 潜在的安全风险：微服务系统内各个进程之间进行的数据交换使用应用程序编程接口 (API) 网关。API 网关可能会在身份验证和其他重要活动中造成安全漏洞。

• 延迟增加：微服务能够显著扩展应用程序，但这可能会带来额外的延迟和响应时间问题。每当系统向上扩展时，复杂性和传输的数据量都会增加，这可能会减慢处理速度。

在对单体架构和微服务架构进行正面比较之前，我们应该补充一些历史背景，以提供更广泛的背景信息。

在某种程度上，很难将单体架构的起源追溯到一个具体的日期；技术越复杂，越难精确确定该技术的确切诞生时间。单体架构也是如此，其开发大约始于 20 世纪中叶。

International Business Machines (IBM®) 是这一关键早期开发中的重要参与者。根据 DZone 投稿者 Pier-Jean Malandrino 的说法，“……像 IBM 这样的公司通过在 1960 和 1970 年代开发大型主机计算机，在早期软件架构的定义中起到了关键作用。”¹

单体架构并非完美，它们通常使用极其基础的编程语言编写，且设计初衷是供单台计算机读取。由于整个系统只存在于一台计算机中，所有计算机组件都是高度耦合的。扩展几乎不存在或极其有限，通常需要对整个系统进行重建。

另一方面，如果回顾来看单体架构显得原始，这部分原因在于它是最早出现的架构形式，早于其他任何软件架构系统。随着时间推移，它一直被证明是实用的，甚至是具有弹性的。单体架构在引入七十年后仍然被使用，这在一个通常唯一不变的就是不断变化的行业中，本身就说明了很多问题。

单体架构经久不衰，但它不再是唯一的选择，而且这种情况已经持续了一段时间。随着 1980 年代的推进，软件工程开始朝向模块化发展，并采用面向对象的编程语言。到了 1990 年代，分布式系统的舞台已经搭建完成，这些系统能够利用网络计算的最新进展。

这最终促成了微服务的发展，微服务在 2000 年代云计算和容器化技术兴起后得到广泛应用。微服务架构的创建是为了改进单体模型，使其适应快速扩展和去中心化系统。

如今，在 2020 年代，软件开发可基于单体架构或微服务架构进行。根据我们对技术变革的预期，最初的想法可能是认为较新出现的技术更优，在某些情况下，这确实是如此。

然而，做出这种一概而论的判断是危险的，主要原因在于这根本不真实。仍有许多计算场景能够从单体架构模型的简洁性中受益。

两种软件架构各有优缺点，公司在采用其中一种系统之前，需要仔细评估这两种类型，并考虑其预期的应用程序开发需求。

从关键操作阶段的角度来看，单体架构和微服务架构有何不同？

• 创建：两种架构形式的关键差异从一开始就显现，在系统概念设计阶段即可察觉。单体系统由于采用较为基础的设计，构建起来更为简单。微服务则复杂得多，需要更多的规划才能实施。

• 结构：单体架构被设计和构建为一个整体单元。微服务架构则强调模块化的理念，通过使用一组较小、可部署的应用程序来实现独立服务的运行。

• 复杂性：系统越复杂，越适合采用微服务架构。模块化的微服务能够很好地支持新功能和新技术，这些通常伴随着系统复杂性的增加。

• 增长：单体架构和微服务架构在初期使用时都可能有效。但随着增长，一切都会改变，尤其是当组织意识到很快将超出其初始系统时。在这种情况下，公司需要更大的操作平台，而微服务能够提供这种能力，因为它比单体架构拥有更多的操作扩展方式。

• 上市时间：这一关键指标在商业中起着至关重要的作用，用于衡量从生产产品到将其投放到分销渠道所需的时间。单体架构在这一方面优于微服务架构。由于仅使用单一代码库，开发人员可以避免整合来自不同来源的软件所需的额外时间和劳动。

• 可扩展性：微服务架构基于可模块化分割的独立服务，并通过使用 API 实现的松耦合和互通性而受益。另一方面，单体架构由于核心结构厚重且软件高度耦合，其整体适应性较差。

• 调试：调试是使用软件检测和定位代码问题，并随后修复这些问题的过程。单体架构在调试方面表现更好，因为它更简单、直观。微服务架构的调试则要慢得多，过程更复杂且劳动强度更大。

无论是使用单体架构还是微服务架构，都可以实现近乎无限的用例。以下是一些最为常见的用例。

• 初创企业：刚起步的公司需要两样东西：灵活性和启动资金（而且都需要充足）。单体架构是初创企业启动的最佳方式。此外，它可以由精简的开发团队以经济高效的方式构建，不会给这些小团队带来过高的学习曲线。

• 基础项目：使用单一代码库在便利性方面具有显著优势，尤其是对于范围较为简单的项目。当软件可以在开发过程中无需整合来自多个来源的数据时，这对组织来说是一个利好。

• 娱乐平台：运营一个国际娱乐平台需要具备应对不断变化的工作负载的能力，无论需求是轻量级还是高负载。以 Netflix 为例，这家流媒体巨头从单体架构转向了基于云的微服务架构。新的 Netflix 后端配备了大量的负载均衡支持，从而帮助其优化工作负载。

• 电子商务：电子商务依赖微服务架构，以无缝的用户体验让电子市场的魔力得以实现。像亚马逊 (AWS) 这样的雄心勃勃的零售商通过提供更便利的服务和更快速的配送来推动销售，因此不难理解为什么 2023 年的电子商务销售额超过了 5.8 万亿美元。²

• 最艰难的工作：微服务的持续使用通常需要受过培训的 DevOps 团队具备实施和管理技能，以创建该架构框架所需的特定服务。在遇到复杂的应用程序时，这些技能尤其有用。

如果在没有充分考虑最重要因素（即您的科技初创公司的特定需求）的情况下独立完成单体架构或微服务架构的全规模实施设计，那么这一实施注定会出现偏差。

作为 IT 总监，这是在规划软件基础设施决策时最关键的工作。了解何时使用某种架构风格至关重要，同样也需要根据实际需求判断最适合的系统。

自我分析练习非常有价值，因为您的工作不仅是为组织选择最优的架构系统，还需要准确预测公司在未来数月甚至数年内可能需要的架构系统。在某种程度上，您实际上是在承担预测未来的任务。

因此，尽管单体架构可能看起来非常适合您的初创公司，但您需要预测未来的增长情况。如果预计会有大规模扩张，提前投资微服务架构可能更为明智。有许多变量需要考虑：

• 业务逻辑应用：正如计算机逻辑决定了计算机能够或不能完成的操作一样，业务逻辑基于业务规则，这些规则决定了企业如何能够或不能运行。从技术角度来看，这转化为定义信息在数据库与用户界面之间传递方式的算法。

• 前端开发：在软件架构前端规划的早期阶段，您就需要确定采用哪种架构方法，因为每种方法都有其独特的结构。在单体架构中，前端应用表现为一个大型代码库，包含所有应用程序代码。而在微服务前端应用中，可以同时运行多个独立操作的微服务。

• 容错性：另一个必须考虑的因素是预期需要的容错能力。容错性是一个非常棘手的问题，因为如果系统中某个组件出现故障，可能会导致整个应用程序崩溃。单体架构的组件之间缺乏隔离，这可能加剧容错能力的不足，并导致长时间的停机。

• 预期变更率：在单体架构和微服务架构之间的选择，不仅仅是软件架构的问题。实际上，这是在两种业务思维模式之间做出选择：一种只是希望尽快投入运营，另一种则坚持实现实质性的业务增长。业务增长可能较为复杂，但微服务架构的特性，如更快的开发周期和增强的可扩展性，能够很好地支持这一目标。