服务治理，也称为SOA治理，是指用来管理SOA的采用和实现的过程。以下是在2006年时IBM对于服务治理要点的总结：
服务定义（服务的范围、接口和边界）
服务部署生命周期（各个生命周期阶段）
服务版本治理（包括兼容性）
服务迁移（启用和退役）
服务注册中心（依赖关系）
服务消息模型（规范数据模型）
服务监视（进行问题确定）
服务所有权（企业组织）
服务测试（重复测试）
服务安全（包括可接受的保护范围）
限于当时的技术发展水平，广大软件设计与开发人员对于SOA和服务治理的技术认知还主要停留在Web Service和ESB总线等技术和规范上，并没有真正在软件开发中得以充分落地。
Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。
作为一个分布式服务框架，以及SOA治理方案，Dubbo其功能主要包括：高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与服务降级等。Dubbo最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。
Dubbo包含远程通讯、集群容错和自动发现三个核心部分。提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。同时具备软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
下图来自Dubbo官网，描述了服务注册中心、服务提供方、服务消费方、服务监控中心之间的调用关系，具体如下图所示：
节点角色说明：
| 节点 | 角色说明 |
| Provider | 暴露服务的服务提供方。 |
| Consumer | 调用远程服务的服务消费方。 |
| Registry | 服务注册与发现的注册中心。 |
| Monitor | 统计服务的调用次数和调用时间的监控中心。 |
调用关系说明：
服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
各层说明：
Config配置层：对外配置接口，以ServiceConfig、ReferenceConfig为中心，可以直接初始化配置类，也可以通过Spring解析配置生成配置类。
Proxy服务代理层：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
Registry注册中心层：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry、RegistryService。
Cluster路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router、LoadBalance。
Monitor监控层：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor、MonitorService。
Protocol远程调用层：封将RPC调用，以Invocation、Result为中心，扩展接口为Protocol、Invoker、Exporter。
Exchange信息交换层：封装请求响应模式，同步转异步，以Request、Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient、ExchangeServer。
Transport网络传输层：抽象MINA和Netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server、Codec。
Serialize数据序列化层：可复用的一些工具，扩展接口为Serialization、ObjectInput、ObjectOutput、ThreadPool。
各模块说明：
dubbo-common公共逻辑模块：包括Util类和通用模型。
dubbo-remoting远程通讯模块：相当于Dubbo协议的实现，如果RPC用 RMI协议则不需要使用此包。
dubbo-rpc远程调用模块：抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
dubbo-cluster集群模块：将多个服务提供方伪装为一个提供方，包括：负载均衡、容错、路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
dubbo-registry注册中心模块：基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
dubbo-monitor监控模块：统计服务调用次数、调用时间的、调用链跟踪的服务。
dubbo-config配置模块：是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细节。
dubbo-container容器模块：是一个Standlone的容器，以简单的Main加载Spring启动，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。
Dubbo协议（默认协议）
Hessian协议
HTTP协议
RMI协议
WebService协议
Thrift协议
Memcached协议
Redis协议
Multicast注册中心不需要启动任何中心节点，只要广播地址一样，就可以互相发现。组播受网络结构限制，只适合小规模应用或开发阶段使用。组播地址段：224.0.0.0 - 239.255.255.255。
2、ZooKeeper注册中心（推荐）：
ZooKeeper是Apacahe子项目，是一个树型的目录服务，支持变更推送，适合作为Dubbo服务的注册中心，可用于生产环境。
对上图流程说明如下：
服务提供者（Provider）启动时，向/dubbo/com.foo.BarService/providers目录下写入URL。
服务消费者（Consumer）启动时，订阅/dubbo/com.foo.BarService/providers目录下的URL，向/dubbo/com.foo.BarService/consumers目录下写入自己的URL。
监控中心（Monitor）启动时，订阅/dubbo/com.foo.BarService目录下的所有提供者和消费者URL。
阿里内部并没有采用Redis做为注册中心，而是使用自己实现的基于数据库的注册中心，即：Redis注册中心并没有在阿里内部长时间运行的可靠性保障，此Redis桥接实现只为开源版本提供，其可靠性依赖于Redis本身的可靠性。
4、Simple注册中心：
Simple注册中心本身就是一个普通的Dubbo服务，可以减少第三方依赖，使整体通讯方式一致。只是简单实现，不支持集群，可作为自定义注册中心的参考，但不适合直接用于生产环境。
Mina
Netty（默认）
Grizzly
参考链接：
http://dubbo.io
https://github.com/alibaba/dubbo
http://shiyanjun.cn/archives/325.html
http://mp.weixin.qq.com/s/eVYx-tUIMYtAk5wP-qkdkw
2月1日正式开课，还有最后3个名额，点击阅读原文链接即可报名。