Dubbo

一、Dubbo是什么？

Dubbo是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。 Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

1.1 核心部分

其核心部分包含:

• 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
• 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
• 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

1.2 特性

• 面向接口代理的高性能RPC调用
  提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。
• 智能负载均衡
  内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。
• 服务自动注册与发现
  支持多种注册中心服务，服务实例上下线实时感知。
• 高度可扩展能力
  遵循微内核+插件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。
• 运行期流量调度
  内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。
• 可视化的服务治理与运维
  提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。

1.3 架构

模块注解：

• Provider: 暴露服务的服务提供方。
• Consumer: 调用远程服务的服务消费方。
• Registry: 服务注册与发现的注册中心。
• Monitor: 统计服务的调用次调和调用时间的监控中心。
• Container: 服务运行容器。

流程详解：

• 0 服务容器负责启动，加载，运行服务提供者（Standalone 容器）。
• 1 服务提供者在启动时，向注册中心注册自己提供的服务（Zookeeper/Redis）。
• 2 服务消费者在启动时，向注册中心订阅自己所需的服务。
• 3 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
• 4 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
• 5 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心（根据数据可以动态调整权重）。

1.4 一些问题

• Registry 严重依赖第三方组件（zookeeper 或者 redis），当这些组件出现问题时，服务调用很快就会中断。
• Dubbo 只支持 RPC 调用。使得服务提供方（抽象接口）与调用方在代码上产生了强依赖，服务提供者需要不断将包含抽象接口的 jar 包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错，并且以后发布部署会成很大问题（太强的依赖关系）。
• 另外，以后要兼容 .NET Core 服务，Dubbo RPC 本身不支持跨语言（可以用跨语言 RPC 框架解决，比如 Thrift、gRPC（重复封装了），或者自己再包一层 REST 服务，提供跨平台的服务调用实现，但相对麻烦很多）
• Dubbo 只是实现了服务治理，其他微服务框架并未包含，如果需要使用，需要结合第三方框架实现（比如分布式配置用淘宝的 Diamond、服务跟踪用京东的 Hydra，但使用相对麻烦些），开发成本较高，且风险较大。
• 社区更新不及时（虽然最近在疯狂更新），但也难免阿里以后又不更新了，就尴尬了。
• 主要是国内公司使用，但阿里内部使用 HSF，相对于 Spring Cloud，企业应用会差一些。

二、Dubbo能做什么？

• 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
• 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
• 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

REF

http://www.cnblogs.com/xishuai/archive/2018/04/13/dubbo-and-spring-cloud.html