大型网站为什么要使用分布式服务

1、业务拆分

大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成不同的产品线，如大型购物交易网站就会将首页、商铺、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责。

具体到技术上，也会根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间可以通过一个超链接建立关系（在首页上的导航链接每个都指向不同的应用地址），也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统，如图。



2、分布式服务

随着业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难。由于所有应用要和所有数据库系统连接，在数万台服务器规模的网站中，这些连接的数目是服务器规模的平方，导致存数据库接资源不足，拒绝服务。

既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些公用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作，如图。



3、网站扩展性

扩展性是指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。设计网站可扩展架构的核心思想是模块化，并在此基础上，降低模块间的耦合性，提供模块的复用性。模块通过分布式部署，独立的模块部署在独立的服务器上（集群）从物理上分离模块之间的耦合关系。模块分布式部署以后具体聚合方式主要有分布式消息队列和分布式服务。

利用分布式消息队列降低系统耦合性

如果模块之间不存在直接调用，那么新增模块或者修改模块对其他模块影响最小，这样系统的可扩展性无疑更好一些。

事件驱动框架：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作，典型的架构就是生产者消费者模式。在大型网站架构中，具体实现手段很多，最常用的就是分布式消息队列，如下图所示：



消息队列利用发布-订阅模式工作，消息发送者发布消息，一个或者多个消息接收者订阅消息。

由于消息发送者不需要等待消息接受者处理数据就可以返回，系统具有更好的响应延迟；同时，在网站访问高峰，消息可以暂时存储在消息队列中等待处理，减轻数据库等后端存储的负载压力。

目前开源的和商业的分布式消息队列产品有很多，比较著名的有Apache ActiveMQ等，如下是分布式消息队列的架构原理：



利用分布式服务打造可复用的业务平台

使用分布式服务是降低系统耦合性的另一个重要手段。如果说分布式消息队列通过消息对象分解系统耦合性，不同子系统处理同一个消息；那么分布式服务则通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。

大型网站分布式服务的需求与特点：

负载均衡

失效转移

高效的远程通信

整合异构系统

对应用最小入侵

版本管理

实时监控

目前国内有较多成功实施案例的开源分布式服务框架是阿里巴巴的Dubbo，下图是Dubbo的架构原理。



服务消费程序通过服务接口使用服务，而服务接口通过代理加载具体服务，具体服务可以是本地的代码模块，也可以是远程的服务，因此对应用较小入侵；应用程序需要调用服务接口，服务框架根据配置自动调用本地或远程实现。

服务框架客户端模块通过服务注册中心加载服务提供者列表（服务提供者启动后主动向服务注册中心注册自己可提供的服务接口列表），查找需要的服务接口，并根据配置的负载均衡策略将服务调用请求发送到某台服务提供者服务器。如果服务调用失败，客户端模块会自动从服务提供者列表选择一个可提供同样服务的另一台服务器重新请求服务，实现服务的自动失效转移，保证高可用服务。