分布式服务

分布式服务通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。

拆分可以分为纵向拆分和横向拆分两种。

• 纵向拆分：

  将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统。

• 横向拆分：

  将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务，不需要依赖具体的模块代码，即可快速搭建一个应用系统，而模块内业务逻辑变化的时候，只要接口保持一致就不会影响业务程序和其他模块。

纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离，使其成为独立的Web应用。而对于横向拆分，不但需要识别可复用的业务，设计服务接口，规范服务依赖关系，还需要一个完善的分布式服务管理框架。

Web Service

在Web Service中存在三种角色，三种角色的交互组成了一个完整的应用：

• 服务提供者通过WSDL（Web Services Description Language，Web服务描述语言）向注册中心（Service Broker）描述自身提供的服务接口属性

• 注册中心使用UDDI（Universal Description,Discovery,and Integration，统一描述、发现和集成）发布服务提供者提供的服务

• 服务请求者从注册中心检索到服务信息后，通过SOAP（Simple Object Access Protocol，简单对象访问协议）和服务提供者通信，使用相关服务。

Web Service虽然有成熟的技术规范和产品实现，并在企业应用领域有许多成功的案例，但也有如下固有的缺点：

1. 臃肿的注册与发现机制。

2. 低效的XML序列化手段。

3. 开销相对较高的HTTP远程通信。

4. 复杂的部署与维护手段。

这些问题导致Web Service难以满足大型网站对系统高性能、高可用、易部署、易维护的要求。

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

对于大型网站，除了Web Service所提供的服务注册与发现，服务调用等标准功能，还需要分布式服务框架能够支持如下特性：

• 负载均衡

  对热门服务，比如登录服务或者商品服务，访问量非常大，服务需要部署在一个集群上。分布式服务框架要能够支持服务请求者使用可配置的负载均衡算法访问服务，使服务提供者集群实现负载均衡。

• 失效转移

  对于大型网站的分布式服务而言，即使是很少访问的简单服务，也需要集群部署，分布式服务框架需要支持服务提供者的失效转移机制，当某个服务实例不可用，就将访问切换到其他服务实例上，以实现服务整体高可用。

• 高效的远程通信

  对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段，服务调用会成为整个系统性能的瓶颈。

• 整合异构系统

  由于历史发展和组织分割，网站服务可能会使用不同的语言开发并部署于不同的平台，分布式服务框架需要整合这些异构的系统。

• 对应用最少侵入

  服务模块本身需要既可集中式部署，也可分布式部署。

• 版本管理

  分布式服务框架需要支持服务多版本发布，服务提供者先升级接口发布新版本的服务，并同时提供旧版本的服务供请求者调用，当请求者调用接口升级后才可以关闭旧版本服务。

• 实时监控

  对于网站应用而言，没有监控的服务是不可能实现高可用的。分布式服务框架还需要监控服务提供者和调用者的各项指标，提供运维和运营支持。

开源框架Dubbo

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

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

Dubbo的远程服务通信模块支持多种通信协议和数据序列化协议，使用NIO通信框架，具有较高的网络通信性能。