一、背景
随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，急需一个治理系统架构有条不紊的演进。
1、单一垂直架构（All in One）：
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化CRUD工作量的数据访问架构（ORM）是关键。
2、垂直应用架构（Vertical Application）：
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架（MVC）是关键。
3、分布式服务架构（Distributed Service）：
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
4、流动计算架构（Elastic Computing）：当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
二、需求
1、当网站变大后，不可避免的需要拆分应用进行服务化，以提高开发效率，调优性能，节省关键竞争资源等。
2、当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5 硬件负载均衡器的依赖，也能减少部分成本。
3、当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。
4、接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。
三、Dubbo是什么？
Dubbo是一个分布式服务框架，基于注册中心模式实现RPC远程服务调用，以及SOA服务治理方案。
四、Dubbo的设计思路
该框架具有极高的扩展性，采用微核+插件体系，并且文档齐全，方便二次开发，适应能力强。
五、Dubbo的依赖
JDK 1.5 以上，缺省依赖javassist、netty、spring等jar包，但不是必须依赖，通过配置Dubbo可不依赖任何第三方库运行。
六、为什么使用Dubbo？
1、提供了RPC调用和SOA治理；
2、开源
3、相对其他RPC框架，应用广泛，更加成熟。
其他RPC框架补充：
Thrift：开发团队是FaceBook，优点是支持多语言，缺点没有自带SOA；
Duddox：开发团队是当当，为Dubbo提供了一些新的功能，REST风格远程调用，Kryo/FST序列化等。
Motan：开发团队是微软，基于Java的轻量级RPC框架，相对Dubbo而言，没有那么多功能以及扩展实现。
七、Dubbo的性能
Dubbo通过长连接减少握手，通过NIO及线程池在单连接上并发拼包处理消息，通过二进制流压缩数据，比常规HTTP等短连接协议更快。在alibaba内部，每天可支撑2000+服务，30亿+访问量，最大单机支持大约1亿访问量。
八、与HSF（High Speed Framework）的对比
1、Dubbo比HSF的部署方式更轻量
HSF要求使用指定的JBoss等容器，还需要在JBoss等容器中加入jar包扩展，对用户侵入性较大，如果要运行在Weblogic或Websphere等其他容器上，需要自行扩展容器以兼容HSF的ClassLoader加载，而Bubbo没有任何要求，可运行在任何Java环境；
2、Dubbo比HSF扩展性更好，方便二次开发
一个框架不可能覆盖所有需求，Dubbo始终保持平等对待第三方理念，即所有功能，都可以在不修改Dubbo原生代码的情况下，在外围扩展，包括Dubbo自己内置的功能，也和第三方一样，是通过扩展的方式实现的，而HSF如果你要加功能或替换某部分实现是很困难的，比如支付宝和淘宝用的就是不同的HSF分支，因为加功能时改了核心代码，不得不拷一个分支单独发展，HSF现阶段就算开源出来，也很难复用，除非对架构重写。 一个框架不可能覆盖所有需求，Dubbo始终保持平等对待第三方理念，即所有功能，都可以在不修改Dubbo原生代码的情况下，在外围扩展，包括Dubbo自己内置的功能，也和第三方一样，是通过扩展的方式实现的，而HSF如果你要加功能或替换某部分实现是很困难的，比如支付宝和淘宝用的就是不同的HSF分支，因为加功能时改了核心代码，不得不拷一个分支单独发展，HSF现阶段就算开源出来，也很难复用，除非对架构重写。
3、HSF依赖较多内部系统
比如配置中心，通知中心，监控中心，单点登录等等，如果要开源还需要做很多剥离工作，而Dubbo为每个系统的集成都留出了扩展点，并已梳理干清所有依赖，同时为开源社区提供了替代方案，用户可以直接使用。
4、Dubbo比HSF的功能更多
除了ClassLoader隔离，Dubbo基本上是HSF的超集，Dubbo也支持更多协议，更多注册中心的集成，以适应更多的网站架构。
九、Dubbo的安全机制
Dubbo主要针对内部服务，对外的服务，阿里有开放平台来处理安全和流控，所以Dubbo在安全方面实现的功能较少，基本上只防君子不防小人，只防止误调用。
Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。
十、Dubbo的应用情况
在阿里内部，除淘系以外的其它阿里子公司，都在使用Dubbo，包括：中文主站，国际主站，AliExpress，阿里云，阿里金融，阿里学院，良无限，来往等等。
开源后，已被：去哪儿，京东，吉利汽车，方正证劵，海尔，焦点科技，中润四方，华新水泥，海康威视，等公司广泛使用，并不停的有新公司加入，社区讨论及贡献活跃，得到用户很高的评价。
十一、Dubbo的分布式事务和多语言支持
分布式事务可能暂不会支持，因为如果只是支持简单的XA/JTA两阶段提交事务，实用性并不强。用户可以自行实现业务补偿的事件，或更复杂的分布式事务，Dubbo有很多扩展点可以集成。
在多语言方面，Dubbo实现了C++版本，但在内部使用面极窄，没有得到很强的验证，并且C++开发资源紧张，没有精力准备C++开源事项。
十二、Dubbo采用的开源协议以及商业应用应注意事项
Dubbo采用Apache License 2.0开源协议，它是一个商业友好的协议，你可以免费用于非开源的商业软件中。
你可以对它进行改造和二次发布，只要求保留阿里的著作权，并在再发布时保留原始许可声明。
十三、核心功能
高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。
远程通讯：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及"请求-响应"模式的信息交换方式；
自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供者，使地址透明，使服务提供方可以平滑增加或减少机器；
集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
十四、架构
角色说明：
registry：服务注册与发现的注册中心
contrainer：服务运行容器
provider：暴露服务的服务提供方
consumer：调用远程服务的服务消费方
monitor：统计服务调用次数和调用时间的监控中心
调用关系：
0、start：服务容器负责启动，加载，运行服务提供者；
1、register：服务提供者在启动时，向注册中心注册自己提供的服务；
2、subscribe：服务消费者在启动时，想注册中心订阅自己所需服务；
3、notify：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者；
4、invoke：服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用；
5、conut：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
十五、特点
连通性
- 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小；
- 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示；
- 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销；
- 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销；
- 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外；
- 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者；
- 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表；
- 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。
健壮性
- 监控中心宕机不影响使用，只是丢失部分采样数据；
- 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务；
- 注册中心对等集群，任意一台宕机后，将自动切换到另一台；
- 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯；
- 服务提供者无状态，任意一台宕掉后，不影响使用；
- 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。
伸缩性
- 注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心；
- 服务提供者无状态，可动态增加机器部署实例，注册中心推送新的服务提供者信息给消费者。
升级性
- 当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力。
未来可能的架构：
Deployer：自动部署服务的的本地代理
Repository：仓库用于存储服务应用发布包
Scheduler：调度中心基于访问压力自动增减服务提供者
Admin：统一管理控制台
Registry：服务注册与发现的注册中心
Monitor：统计服务的调用次数和调用事件的监控中心
十六、优缺点
优点：
1、使用简单方便
2、统一的服务调用地址
3、能进行软负载均衡，降低对F5硬件负载均衡器的依赖，也能减少部分成本。
4、连通性
5、健壮性
6、伸缩性
7、升级性
缺点：
只支持Java语言
十七、Dubbo未来的发展计划
Dubbo的RPC框架已基本稳定，未来的重心会放在服务治理上，包括架构分析、监控统计、降级控制、流程协作等等。