3、企业级Web应用系统架构详解

企业级Web应用系统架构详解

1. 缓慢增长的网站架构

网站最初往往由单个开发者和一行代码起步。如图1 - 1所示，一个简单的Rails应用连接到数据库，在迎来首位用户之前，开发者可能会花费大量时间在此配置上开发应用。

当网站准备上线时，有一些问题需要考虑。图1 - 2展示了相同的配置，但在应用层实现了冗余，在数据库层实现了故障转移。应用有两个副本，这样当一台机器出现故障时，另一台仍能处理传入的流量。同样，若数据库机器出现硬件故障，一个稍有延迟的副本可以迅速上线。

即便应用和数据库机器的资源几乎未被充分利用，冗余和故障转移仍是不错的选择。此时，这些考虑并非旨在管理负载，而是确保Web应用的可用性。重新配置机器、加载软件和数据可能会导致长时间的停机，在此期间，用户可能会转向竞争对手的网站，并对网站的可靠性产生负面印象。

有了这样的配置和良好的部署策略，在以封装服务或异步进程的形式增加系统复杂性之前，应用层和数据层仍有许多工作可做。根据Web应用的功能集，这可能就是所需的全部。此时，已经满足了许多定义“企业级”的标准。

在企业内部，也需要进行水平扩展。一个代码库中能容纳的工程师数量是有限的，就像厨房里即使只有一位主厨，副厨的操作空间也是有限的。

为解决人力扩展问题，常见的方法是将大型应用拆分为多个小的服务，每个服务负责企业内的特定功能。软件的拆分通常会遵循组织边界，以便各个团队能完全掌控系统的一部分。

每个服务都有自己的完整堆栈，类似于图1 - 2中的传统网站堆栈。不同之处在于，服务只负责构成整个网站职责的一小部分，通常是一组特定的、相关的功能。有时，将所有数据库访问抽象到服务背后是可行且可取的，前端网站