为何要用 Dubbo？
随着服务化的进一步发展，服务愈来愈多，服务之间的调用和依赖关系也愈来愈复杂，诞生了面向服务的架构体系(SOA)，也所以衍生出了一系列相应的技术，如对服务提供、服务调用、链接处理、通讯协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。就这样为分布式系统的服务治理框架就出现了，Dubbo 也就这样产生了。java
Dubbo 的总体架构设计有哪些分层?
•接口服务层（Service）：该层与业务逻辑相关，根据 provider 和 consumer 的业务设计对应的接口和实现•配置层（Config）：对外配置接口，以 ServiceConfig 和 ReferenceConfig 为中心•服务代理层（Proxy）：服务接口透明代理，生成服务的客户端 Stub 和 服务端的 Skeleton，以 ServiceProxy 为中心，扩展接口为 ProxyFactory•服务注册层（Registry）：封装服务地址的注册和发现，以服务 URL 为中心，扩展接口为 RegistryFactory、Registry、RegistryService•路由层（Cluster）：封装多个提供者的路由和负载均衡，并桥接注册中心，以Invoker 为中心，扩展接口为 Cluster、Directory、Router 和 LoadBlancce•监控层（Monitor）：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory、Monitor 和 MonitorService•远程调用层（Protocal）：封装 RPC 调用，以 Invocation 和 Result 为中心，扩展接口为 Protocal、Invoker 和 Exporter•信息交换层（Exchange）：封装请求响应模式，同步转异步。以 Request 和Response 为中心，扩展接口为 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer•网络传输层（Transport）：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel、Transporter、Client、Server 和 Codec•数据序列化层（Serialize）：可复用的一些工具，扩展接口为 Serialization、ObjectInput、ObjectOutput 和 ThreadPoolspring
Dubbo 用到哪些设计模式？
Dubbo 框架在初始化和通讯过程当中使用了多种设计模式，可灵活控制类加载、权限控制等功能。apache
工厂模式
Provider 在 export 服务时，会调用 ServiceConfig 的 export 方法。ServiceConfig中有个字段：设计模式
private static final Protocol protocol =ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
复制代码Dubbo 里有不少这种代码。这也是一种工厂模式，只是实现类的获取采用了 JDKSPI 的机制。这么实现的优势是可扩展性强，想要扩展实现，只须要在 classpath下增长个文件就能够了，代码零侵入。另外，像上面的 Adaptive 实现，能够作到调用时动态决定调用哪一个实现，可是因为这种实现采用了动态代理，会形成代码调试比较麻烦，须要分析出实际调用的实现类。springboot
装饰器模式
Dubbo 在启动和调用阶段都大量使用了装饰器模式。以 Provider 提供的调用链为例，具体的调用链代码是在 ProtocolFilterWrapper 的 buildInvokerChain 完成的，具体是将注解中含有 group=provider 的 Filter 实现，按照 order 排序，最后的调用顺序是：微信
EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter ->ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter ->ExceptionFilter
复制代码更确切地说，这里是装饰器和责任链模式的混合使用。例如，EchoFilter 的做用是判断是不是回声测试请求，是的话直接返回内容，这是一种责任链的体现。而像ClassLoaderFilter 则只是在主功能上添加了功能，更改当前线程的 ClassLoader，这是典型的装饰器模式。网络
观察者模式
Dubbo 的 Provider 启动时，须要与注册中心交互，先注册本身的服务，再订阅本身的服务，订阅时，采用了观察者模式，开启一个 listener。注册中心会每 5 秒定时检查是否有服务更新，若是有更新，向该服务的提供者发送一个 notify 消息，provider 接受到 notify 消息后，运行 NotifyListener 的 notify 方法，执行监听器方法。架构
动态代理模式
Dubbo 扩展 JDK SPI 的类 ExtensionLoader 的 Adaptive 实现是典型的动态代理实现。Dubbo 须要灵活地控制实现类，即在调用阶段动态地根据参数决定调用哪一个实现类，因此采用先生成代理类的方法，可以作到灵活的调用。生成代理类的代码是 ExtensionLoader 的 createAdaptiveExtensionClassCode 方法。代理类主要逻辑是，获取 URL 参数中指定参数的值做为获取实现类的 key。app
dubbo与spring cloud
dubbo 如今归到 apache 旗下管理。开了新的维护，对 springboot 也作了适配更新。负载均衡
可能提及来Dubbo，不少人都不陌生，这毕竟是一款从2012年就开始开源的Java RPC框架，中间因为各类各样的缘由中止更新4年半的时间，中间只发过一个小版本修了一个小bug，甚至你们都觉得这个项目已经死掉了，居然又在2017年9月份恢复了更新，不可谓不神奇。
网络上不少人都拿Dubbo和Spring Cloud作对比，可能在你们的心目中，这两个框架是能够画上等号的吧，后来在网络上有一个很是流行的表格，比较详细的对比了 Spring Cloud 和 Dubbo ，表格以下：
以上列举了一些核心部件，固然这里须要申明一点，Dubbo对于上表中总结为“无”的组件不表明不能实现，而只是Dubbo框架自身不提供，须要另外整合以实现对应的功能，这样看起来确实Dubbo更像是Spring Cloud的一个子集。
Dubbo 在国内拥有着巨大的用户群，你们但愿在使用 Dubbo 的同时享受 Spring Cloud 的生态，出现各类各样的整合方案，可是由于服务中心的不一样，各类整合方案并非那么天然，直到 Spring Cloud Alibaba 这个项目出现，由官方提供了 Nacos 服务注册中心后，才将这个问题完美的解决。而且提供了 Dubbo 和 Spring Cloud 整合的方案，命名为：Dubbo Spring Cloud 。
Dubbo Spring Cloud 概述
Dubbo Spring Cloud 构建在原生的 Spring Cloud 之上，其服务治理方面的能力可认为是 Spring Cloud Plus， 不只彻底覆盖 Spring Cloud 原生特性，并且提供更为稳定和成熟的实现，特性比对以下表所示：
以上对比表格摘自Dubbo Spring Cloud官方文档。
并且Dubbo Spring Cloud 基于 Dubbo Spring Boot 2.7.1 和 Spring Cloud 2.x 开发，不管开发人员是 Dubbo 用户仍是 Spring Cloud 用户， 都能轻松地驾驭，并以接近“零”成本的代价使应用向上迁移。Dubbo Spring Cloud 致力于简化云原生开发成本，以达成提升研发效能以及提高应用性能等目的。
Dubbo Spring Cloud 主要特性
•面向接口代理的高性能RPC调用：提供高性能的基于代理的远程调用能力，服务以接口为粒度，屏蔽了远程调用底层细节。•智能负载均衡：内置多种负载均衡策略，智能感知下游节点健康情况，显著减小调用延迟，提升系统吞吐量。•服务自动注册与发现：支持多种注册中心服务，服务实例上下线实时感知。•高度可扩展能力：遵循微内核+插件的设计原则，全部核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。•运行期流量调度：内置条件、脚本等路由策略，经过配置不一样的路由规则，轻松实现灰度发布，同机房优先等功能。•可视化的服务治理与运维：提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。
Spring Cloud 为何须要RPC
在Spring Cloud构建的微服务系统中，大多数的开发者使用都是官方提供的Feign组件来进行内部服务通讯，这种声明式的HTTP客户端使用起来很是的简洁、方便、优雅，可是有一点，在使用Feign消费服务的时候，相比较Dubbo这种RPC框架而言，性能堪忧。
虽然说在微服务架构中，会讲按照业务划分的微服务独立部署，而且运行在各自的进程中。微服务之间的通讯更加倾向于使用HTTP这种简答的通讯机制，大多数状况都会使用REST API。这种通讯方式很是的简洁高效，而且和开发平台、语言无关，可是一般状况下，HTTP并不会开启KeepAlive功能，即当前链接为短链接，短链接的缺点是每次请求都须要创建TCP链接，这使得其效率变的至关低下。
对外部提供REST API服务是一件很是好的事情，可是若是内部调用也是使用HTTP调用方式，就会显得显得性能低下，Spring Cloud默认使用的Feign组件进行内部服务调用就是使用的HTTP协议进行调用，这时，咱们若是内部服务使用RPC调用，对外使用REST API，将会是一个很是不错的选择，恰巧，Dubbo Spring Cloud给了咱们这种选择的实现方式。
dubbo or spring cloud
dubbo彻底能够和springcloud共存，架构图以下所示（图片来源自技术交流群）。因此说用springcloud并不表明项目多么先进，用dubbo也并不就表示项目是落后的。微服务是如此庞大且复杂的工程，复杂到即便springcloud也不能cover住每个环节，并且，springcloud已有的一些方案作的并不理想，甚至都达不到生产标准。咱们要作的就是针对每个技术环节，结合本身的业务特色，千万不要仅局限在springcloud体系，从而选择出最有利于本身项目的开源产品。
本文分享自微信公众号 - soft张三丰（aguzhangsanfeng）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。