7、模块化单体架构：构建可维护应用的有效方案

模块化单体架构：构建可维护应用的有效方案

1. 从“大泥球”到模块化的转变

在软件开发领域，曾出现过一个包含系统大部分领域逻辑的单一 C++ 类，它被戏称为“大泥球”。这个类拥有超过 5000 个方法和 50 多万行代码，每个使用它的应用都必须引入这个庞大的类及其所有依赖，这使得代码的更改和维护变得异常困难。PayPal 的核心功能就包含在这样的类中，因此对其进行重构变得至关重要。

2007 年和 2008 年，团队花费时间将这个类拆分，并以更模块化的方式重新组织代码。这为后来向完全分布式架构（本质上是微服务架构）的转变奠定了基础。他们在所有方面都使用 REST，采用了更多样化的开发方法（例如，某些模块使用 Node.js），最终将系统重构为一组微服务。如今，他们拥有超过 2500 个微服务和 750 个对外发布的 API。

2. 应用维护与架构设计的重要性

许多应用在部署到生产环境之前就失败了，但那些成功部署的应用往往会长期使用。很多为满足即时需求而快速开发的应用，多年后仍在使用。企业在开发出原型后，可能会决定将其投入生产。将应用描述为遗留系统，实际上是承认它仍然有用。由于有用的应用会长期使用，因此大部分开发工作不是用于初始开发，而是用于维护。

应用越容易维护和演进，对企业就越有价值。它不仅能提供有用的功能，而且开发者可以高效地修复和扩展这些功能，使应用在需求和环境变化时更有价值。一个不需要修复漏洞和添加新功能的应用，往往是没有人使用的应用。因此，应用不仅要设计成能提供所需的用户功能，还要易于维护。

当应用以“大泥球”形式开始时，一旦证明其可行，维护和演进就会成为问题。复杂的代码和相互依赖关系会导致修复一个问题时破