单体应用将多个功能的用户界面和数据访问层整合到一个应用中。通常情况下，单体应用将作为单个代码库存在，由企业内的多个团队进行修改，并部署为一个单元（包含这些团队维护的所有功能）。
得益于其组件的紧密集成，单体应用通常更易于开发和部署。然而，随着应用范围的扩大和性能需求的增加，单体应用可能会变得难以维护和扩展。
单体应用架构示例
单体系统非常适合不太复杂的小型应用，这些应用无需快速扩展或定期维护。下面是一些通常采用单体系统的应用示例（尽管其新功能可能基于更加容器的基础架构）。
- 电子商务平台 — 单体应用在电子商务平台中很常见，因为在部署了基础架构（网店创建、订单处理、支付流程和客户服务）之后，便几乎无需更新架构。
- 内容管理系统 (CMS) — 此类应用完全由单体应用 (WordPress) 实现。部署后，CMS 应用提供以网页形式进行内容管理所需的所有功能。
- 银行系统 — 许多金融系统均构建为单体应用，因为入口点有限，因此更加安全。此外，在部署时，代码库包含消费者期望从网上银行体验中获得的所有功能：金融交易管理、支付处理和交易跟踪。
单体架构的优点
虽然单体架构的某些方面已经过时，但仍有许多用途和优势。
单体架构的一些优势包括：
- 简单 — 较之更复杂的架构（例如微服务架构），集中式架构可简化单体应用的开发、部署和维护。
- 更快的测试速度 — 通过将每个组件集成到一个程序中，单体应用可作为一个整体进行快速测试。与由多个较小组件（例如微服务）组成的架构不同，单体架构无需针对复杂的通信协议或多个代码仓库进行额外的测试。
- 安全防护 — 由于攻击者的入口点较少，因此单体架构通常更易于保护安全。与管理多个安全防护配置相比，在一个应用中执行安全防护协议也更容易。
- 成本 — 单体架构可作为一个单元进行部署，从而消除一些额外成本，包括部署和保护额外的通信协议、构建更多连接基础架构以及聘用经过更专业化技能学习和培训的员工。
单体架构的缺点
虽然单体架构具有其独特优势，但也可能引发一系列问题。
单体架构的一些缺点包括：
- 复杂性逐渐增加 — 随着时间的推移，越来越多的应用和功能可能会导致单体架构变得更大、更复杂，进而加剧相应的风险
- 缺乏可扩展性 — 当应用的一个功能或区域需要横向扩展时，整个大型应用（包括无需额外资源的子系统）必须进行扩展。这可能会导致扩展速度缓慢（因为部署需要更长的时间），也会造成成本增加（因为与微服务相比，每个实例都有更高的硬件需求）。
- 弹性 — 在单体架构中，所有应用组件都紧密关联，并从中央代码库运行。因此，如果其中一个出现故障，整个应用就会瘫痪。
- 完全重新部署 — 由于整个应用为单个代码库，因此每当更改或更新单个组件时，便需对单体架构进行完全重新部署。
- 技术堆栈 — 因为开发人员必须确保他们使用的任何工具或语言都适合单体架构，所以选择受到限制。此外，许多单体应用的编写方式与更高效的新技术（如云计算和容器化等）并不完全兼容。
- 开发速度较慢 — 当多个开发团队使用一个大型代码库时，需要特别注意接口和域边界，确保其得到妥善维护。有时，代码可能会引入复杂的耦合，致使跨团队依赖关系拖慢新功能的开发速度或关键问题的解决速度。
什么是微服务架构？
与单体架构相对的是微服务架构。微服务是一种软件架构方法，可利用多个小组件构建大型复杂应用。每个组件均可执行单个功能（例如身份验证、通知或支付流程），也可以作为单体架构中的捆绑组件。“微服务”（或“服务 [service]”）亦指小组件本身。
单体应用是紧密耦合型（意味着其组件互连），而微服务应用则为分布式（意味着其组件可以独立工作）。随着应用变得越来越大、越来越复杂，许多企业正探索如何摒弃单体架构或以微服务形式整合新应用。
NGINX 很高兴能为正在探究单体架构和微服务架构的用户提供更多的免费学习资源：
