Dubbo系列1:介绍和基本工作流程

1.Dubbo与Spring Cloud的关系

在早期的时候，Dubbo 和 Spring Cloud 是两个隔离的生态，因此经常讨论的一个话题就是Java 微服务框架选型（Dubbo 和 Spring Cloud？）。而现在 Spring Cloud Alibaba Dubbo 的出现，将 Dubbo 融合到 Spring Cloud 中，取代 Feign + Ribbon，提供更好的服务治理能力与更优的性能。
由于 Dubbo Spring Cloud 构建在原生的 Spring Cloud 之上，其服务治理方面的能力可认为是 Spring Cloud Plus， 不仅完全覆盖 Spring Cloud 原生特性，而且提供更为稳定和成熟的实现，特性比对如下表所示：

Spring Cloud Alibaba Dubbo 比较重要的特性，是使用 Spring Cloud 定义的应用级别的注册模型，将 Dubbo 服务注册到 Spring Cloud 编程模型的注册中心。如此，Spring Cloud Alibaba Dubbo 又将 Feign 和 RestTemplate 进一步增强，实现对 Spring Cloud Alibaba Dubbo 服务的调用。最终如下图所示：

2.Dubbo的特征总结

Dubbo着眼于解决如下几个最基本的问题：
高性能、 透明的RPC调用。 只要涉及服务之间的通信， RPC就必不可少。 Dubbo可以让开发者像调用本地的方法一样调用远程服务， 而不需要显式在代码中指定是远程调用。 整个过程对上层开发者透明， Dubbo会自动完成后续的所有操作， 例如： 负载均衡、 路由、 协议转换、 序列化等。 开发者只需要接收对应的调用结果即可。
服务的自动注册与发现。 当服务越来越多时， 服务URL配置管理变得非常困难， 服务的注册和发现已经不可能由人工管理。 此时需要一个服务注册中心， 动态地注册和发现服务， 使服务的位置透明。 Dubbo适配了多种注册中心， 服务消费方（消费者）可以通过订阅注册中心， 及时地知道其他服务提供者的信息， 全程无须人工干预，这又包含以下几个方面。
自动负载与容错。 当服务越来越多时,F5硬件负载均衡器的单点压力也越来越大。Dubbo提供了完整的集群容错机制， 可以实现软件层面的负载均衡， 以此降低硬件的压力。 Dubbo还提供了调用失败的各种容错机制， 如Failover、 Failfast、 结果集合并等。
动态流量调度。 在应用运行时， 某些服务节点可能因为硬件原因需要减少负载；或者某些节点需要人工手动下线； 又或者需要实现单元化的调用、 灰度功能。
提供了管理控制台， 用户可以在界面上动态地调整每个服务的权重、 路由规则、 禁用/启用， 实现运行时的流量调度。
依赖分析与调用统计。 当应用规模进一步提升,服务间的依赖关系变得错综复杂，甚至分不清哪个应用要在哪个应用之前启动， 架构师都不能完整地描述应用的架构关系。 服务的调用量越来越大， 服务的容量问题就暴露出来， 这个服务需要多少机器支撑？ 什么时候该加机器？ Dubbo可以接入三方APM做分布式链路追踪与性能分析， 或者使用己有的独立监控中心来监控接口的调用次数及耗时， 用户可以根据这些数据反推出系统容量。

3.Dubbo的基本工作过程

不管用什么组件，当我们使用rpc调用服务的大致过程都是一样的：

对于Dubbo，主要工作过程是：

Provider启动时会向注册中心把自己的元数据注册上去（比如服务IP和端口等），Consumer在启动时从注册中心订阅（第一次订阅会拉取全量数据） 服务提供方的元数据， 注册中心中发生数据变更会推送给订阅的Consumero在获取服务元数据后， Consumer可以发起RPC调用， 在RPC调用前后会向监控中心上报统计信息（比如并发数和调用的接口） 。