使用分布式服务是降低系统耦合性的另一个重要手段。如果说分布式消息队列通过消息对象分解系统耦合性，不同子系统处理同一个消息；那么分布式服务则通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。
为什么要使用分布式
如果不使用分布式，一个应用会聚合大量应用和服务组件，这个巨无霸应用系统会带来如下几点问题：
- 编译、部署困难
- 代码分支管理困难
- 数据库连接耗尽
- 新增业务困难
解决方案就是拆分，将模块独立部署，降低系统耦合性。可分为纵向拆分和横向拆分两种：
纵向
将一个大应用拆分为多个小应用，如果新增业务较为独立，那就直接将其设计部署为一个独立的 Web 应用系统横向
将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式访问，不需要依赖具体的模块代码，即可快速搭建一个应用系统，而模块内业务逻辑变化的时候，只要接口保持一致就不会影响业务程序和其他模块
大型网站分布式服务的需求与特点
负载均衡
失效转移
高效的远程通信
整合异构系统
由于历史发展和组织分割，网站服务可能会使用不同的语言开发并部署于不同的平台，分布式服务框架需要整合这些异构的系统对应用最小入侵
分布式服务需要渐进式的演化，甚至会出现反复，即使用了分布式服务后又退回到集中式部署，分布式服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署，也可分布式部署版本管理
分布式服务框架需要支持服务多版本发布，服务提供者先升级接口发布新版本的服务，并同时提供旧版本的服务供请求者调用，当请求者调用接口升级后才可以关闭旧版本服务实时监控
分布式服务框架
目前国内有较多成功实施案例的开源分布式服务框架是阿里巴巴的 Dubbo，下图是 Dubbo 的架构原理：
服务消费程序通过服务接口使用服务，而服务接口通过代理加载具体服务，具体服务可以是本地的代码模块，也可以是远程的服务，因此对应用较小入侵；应用程序需要调用服务接口，服务框架根据配置自动调用本地或远程实现。
服务框架客户端模块通过服务注册中心加载服务提供者列表（服务提供者启动后主动向服务注册中心注册自己可提供的服务接口列表），查找需要的服务接口，并根据配置的负载均衡策略将服务调用请求发送到某台服务提供者服务器。如果服务调用失败，客户端模块会自动从服务提供者列表选择一个可提供同样服务的另一台服务器重新请求服务，实现服务的自动失效转移，保证高可用服务。
