一切的开始

单体架构

在最初，存在的是单体架构。它易于部署，也容易维持运行。我们只需要关注一个（或少数几个）组件即可。单体架构通常不会频繁部署。在一个发布周期结束时，开发团队会将一个打包好的应用交给运维团队。运维团队将其部署到少量服务器上，并持续监控其运行状态。如果部分服务器出现故障，运维团队则需手动将应用迁移到剩余的健康服务器上。

但这并非完美无缺。

很难甚至不可能对单体架构中的某个独立组件进行扩展。即使只是对应用中极小的部分进行修改，也需要进行一次完整的重新部署，且必须精心规划。此外，缺乏清晰的边界可能导致设计不够理想。

基于微服务的架构

随后，业界逐渐转向基于微服务的架构。起初，一个单一的应用被拆分为数十个小型服务，这些服务可以独立地进行扩展和部署，更加灵活。各团队获得了更大的自主权，能够自行部署和监控自己的服务，开发与运维团队也逐渐融合为统一的整体。

然而，这依然存在挑战。要让数十个、数百个甚至数千个服务稳定可靠地运行，绝非易事。

我们的第一个难题是：我们很可能无法为每个需要运行的应用或服务都配备专用的物理机器。这将带来巨大的成本，尤其是在需要冗余的情况下。因此，我们需要让多个应用共享同一台物理实例。但不同的应用有着不同的需求，每个应用可能依赖不同的库，甚至依赖同一库的不同版本。