前言
学习dubbo有一段时间了，今天我们来对Dubbo的技术进行一次总结，我们之前学过了Dubbo框架的整体架构，服务提供者发布注册原理，Dubbo的SPI机制，服务消费者订阅原理，服务调用原理,Dubbo线程池模型，Dubbo负载均衡机制，Dubbo服务容错机制等，下面是Dubbo知识体系脑图。
从上图看出Dubbo涉及的技术点非常多，这些技术点其实在大部分的分布式中间件中都有体现，比如mq,redis,mysql,分布式定时任务，Dubbo框架其实和很多中间件的原理类似，比如Rocketmq,Rocketmq其实本质上是两次rpc通信，它同样涉及到远程通信，负载均衡，线程池，服务容错机制等等技术，因此学习Dubbo对于我们技术人来说还是很有意义的。
做完总结，我们看一看Dubbo常见的几个问题点。
一、如何理解Dubbo框架？
Apache Dubbo 是一款高性能、轻量级的开源Java RPC框架，它提供了六大核心能力：
1、面向接口的远程方法调用，
2、智能容错和负载均衡，
3、以及服务自动注册和发现。
4、高度可扩展能力（自研spi机制）
5、运行期流量调度（内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能）
6、可视化的服务治理与运维。
二、支持哪些负载均衡算法
1、加权随机
2、加权轮训
3、最少活跃数
4、一致性hash
三、Dubbo是否支持大数据对象传输，如何处理？
Dubbo 的设计目的是为了满足高并发小数据量的 rpc 调用，在大数据量下的性能表现并不好，建议使用 rmi 或 http 协议。
当dubbo服务提供层向消费层传输大数据容量的对象时，会受到Dubbo的限制，报类似如下异常：
com.alibaba.dubbo.remoting.transport.AbstractCodec.checkPayload() java.io.IOException: Data length too large: 11557050, max payload: 8388608（默认只支持8M）
dubbo传输大数据对象两种解决方案
1、修改提供方的dubbo配置，在dubbo.properties 中增加如下配置，修改dubbo传输数据大小。
dubbo.protocol.dubbo.payload=11557050（默认为8M，即8388608）
2、引入第三方大数据存储介质，比如mongodb,分布式文件服务oss等。服务提供者存储数据到这些介质中，在服务消费方拿到唯一地址，再从第三方介质服务中获取数据。
Dubbo3.0的新特性
最后,Dubbo的3.0版本已经发布一年了，Dubbo3.0相比于2.0+的版本有比较大的改动，Dubbo3.0有哪些关键新特性呢？
1、支持应用级服务发现
我们知道dubbo2.0+的版本dubbo都是按接口的维度来实现服务注册发现，dubbo3.0开始支持应用级服务发现，这个功能其实和spring cloud就非常融入了，spring cloud是最先有面向应用的服务注册发现机制的，这也为dubbo接入spring cloud打下铺垫。应用级服务发现最大的好处在于它可以减轻注册中心的压力，因为相比于面向接口的服务注册发现，注册中心可以存储更少的元数据，减轻注册中心推送存储压力，消费者端地址计算压力递减。 进一步提升了 Dubbo3 在大规模集群实践中的性能与稳定性。
2、新的rpc协议Triple
它是基于 HTTP/2 上构建的 RPC 协议，完全兼容 gRPC，并在此基础上扩展出了更丰富的语义。
3、更好的开发云原生应用
Dubbo3 构建的业务应用可直接部署在 VM、Container、Kubernetes 等平台，Dubbo3 很好的解决了 Dubbo 服务与调度平台之间的生命周期对齐，Dubbo 服务发现地址 与容器平台绑定的问题。
