业务层扩展的问题

接下来我们来思考业务层的扩展问题。

首先要解决如何快速扩充业务服务器。如果业务服务器的运行环境和程序不会频繁更新，可以基于已有的业务服务器制作主机映像，当需要扩容时，直接基于映像创建新的主机，挂接到LB后端就可以马上对外服务了。

此时你还可以使用AutoScaling功能自动化这一过程，即当到达某种触发条件，如LB并发数、响应延迟达到多少后，自动触发主机的扩容。当触发条件不满足时，可以回收资源。

当然如果你的业务服务器的环境或程序需要频繁更新，不适合做成固定模版。此时可以自己搭建自动化部署（如Puppet Application /Application Ansible）实现业务自动扩容（使用QingCloud的开放API接口可以轻松实现）。

此外你还需要保证业务服务器是无状态的，因为每次LB请求的后端可能不同，不能假设上一次请求和这一次请求落在同一台业务服务器上。如果服务器需要保存用户访问的session信息，可将其下放到缓存或数据库中存储。

随着产品功能越来越丰富，你会发现原有单一的业务项目越来越庞大，各种功能逻辑交织在一起，当一个功能出现故障，可以引发全局不可用。此时你需要考虑将单一的业务项目分拆成多个独立子服务。子服务之间可以基于消息的通信，亦或基于RPC的通信方式。

子服务的调用可分为需同步处理和可异步处理两类。你应该尽量异步化所有不需要马上返回结果的请求。对于可异步处理的请求，我们通过引入消息队列，为请求产生的数据做缓冲，请求的接收者（队列消费者）可根据队列中任务的数量做水平扩容。消息队列的选择有很多，例如Redis, RabbitMQ, ActiveMQ, Kafka, QingCloud平台上目前已经提供分布式、可分区、多副本的消息队列服务，具有高吞吐量、低延迟等特点，用户可以方便的集成到自己的系统中。

如今数据分析对于企业越来越至关重要，业务服务器在处理请求的过程中，可以将原始数据通过队列，源源不断地导入大数据处理系统。用户可以根据需求方便的创建、使用和扩容QingCloud大数据分布式处理平台的Spark和Hadoop服务。

通过拆分子服务，使得我们有能力在某项子服务发生故障时，尽可能降低对于全局的影响，提高系统整体的可用性。另外，对于处理压力比较大的子服务，我们还可以进行独立的水平扩容。操作方式和前面讲到的业务服务器扩容相似，QingCloud内网LB服务也可以在这里发挥作用。

改造后的架构如图3所示。

图3