Apache Dubbo – 版本发布

Blog: 2.7.14 发版公告

Mon, 20 Sep 2021 00:00:00 +0000

变动项

为 ServiceDiscovery 增加动态配置中心的覆盖规则。（#8389）
修复当 mock 参数中包含 ‘:’ 或者 ‘=’ 符号时无法正常使用的问题。（#8379）
修复 zone 参数对 ZoneAwareClusterInvoker 配置无法生效的问题。（#8521）
为序列化白名单检查增加开关，默认为 true。（#8537）
修复当请求超时时序列化检查的空指针异常。（#8587）
修复 NetUtils.ignoreNetworkInterface 无法处理网卡中包含 ‘(’ 符号的问题。（#8629）
统一获取本地地址的方式。（#8679）
修复当重试参数为0，依旧会重试1次的问题。（#8743）
当清除未使用的 invoker 时，立即关闭客户端。（#8756）
修复 destroy 方法以及 doOverrideIfNecessary 中的异常。（#8683）
DefaultFuture.closeChannel 根据日志级别选择是否打印请求的详细数据。（#8778）
使用 MapUtils 替换 AttachmentsAdapter（#8772）

Maven依赖变化

netty4: 4.1.51.Final -> 4.1.66.Final
netty4_ssl: 2.0.39.Final -> 2.0.40.Final
http_client: 4.5.3 -> 4.5.13
jetty: 9.4.11.v20180605 -> 9.4.43.v20210629
apollo_client: 1.1.1 -> 1.8.0
tomcat_embed: 8.5.31-> 9.0.48
commons_io: 2.6 -> 2.7
curator: 5.0.0 -> 5.1.0
hessian_lite: 3.2.8 -> 3.2.11

Blog: 3.0.2.1 发版公告

Mon, 23 Aug 2021 00:00:00 +0000

这是 3.0.2 的错误修正版本。除了以下更改外，与版本 3.0.2 完全相同。

Bug 修复

修复 nacos group 在消费者端不生效的问题 (#8533)
修复请求超时时序列化检查的 NPE (#8547)
兼容使用 dubbo-all 时未导入 farbic-io 包的问题 (#8546)

Blog: 3.0.2 发版公告

Wed, 18 Aug 2021 00:00:00 +0000

新特性

支持通过 @DubboService 注解暴露泛化服务
元数据中心xml格式的配置支持 protocol 和 port 属性
兼容 curator5 以上的版本
点对点调用支持*通配符进行匹配, 一个提供者地址可对应多个接口
为应用级别的服务发现增加动态配置去进行规则覆盖
对提供者测的动态配置覆盖规则提供开关，可以使提供者无视动态配置，不重新暴露
支持 native image
提供取消执行 shutdown hook 的开关
支持 Kubernetes Mesh 的服务治理规则
Netty 连接支持 SSL 配置

Bug 修复

DubboBootStrap start 重复调用后，动态配置被覆盖
动态配置规则被删除后，依然生效
triple 协议在暴露时会抛出空指针异常
ConfigCenterConfig.setAddress 方法会覆盖掉 username 属性
DefaultFuture.closeChannel 会销毁掉消费端测的线程池
TripleClientHandler.writeRequest 抛出空指针异常
解析3.0迁移规则异常时会抛出空指针异常
Activated Extensions 的顺序性问题
URLAddress.parse 方法在解析 ipv6 地址时存在问题
用户自定义的参数在 properties 配置中不生效
同时使用 API 模式和 Spring 模式配置时属性，Config Id 存在覆盖问题
应用级别服务发现在启动时不生效
Nacos 注册中心无法动态感知提供者的数量变化
${dubbo.application} 在 xml 文件中无法被 spring 的 placeholder 规则给解析替换
获取实例参数的顺序问题，先去获取了实例级别参数，再去获取接口级别参数
当 DubboConfigBeanInitializer 不存在时，注册应用启动监听器会抛出异常
Mock 时参数中包含 ‘:’ 或者 ‘=’ 字符时，不生效
删除 Mesh 规则时空指针异常

优化

抓住 RemovalTask 的异常，保证信号量能够释放
通过唯一 service name 检查 ReferenceConfig/ServiceConfig 是否重复
优化生成随机数的性能
如果用户使用接口级别去做服务发现，不发布应用与接口的映射数据到元数据中心
使用 StringBuilder#append(Char) 提升性能
保证 GRPC 编译的类文件中接口的顺序
优化 reference bean 的占位符解析
MergeableClusterInvoker 中使用 CompletableFuture#get(long, TimeUnit) 去提升性能
内置服务 MetadataService 不延迟暴露
优化 ConfigBean 和 Bootstrap 的启动逻辑
优化 Config 检查是否重复的逻辑
使用 Ring 数据结构去进行注册通知
优化动态配置的初始化逻辑
ConfigManager 使用 ConcurrentHashMap 去移除锁逻辑，提升 equals 和 toString 性能
优化 MetadataInfo equals 方法以及 Instance Listener
优化异步 export/refer 逻辑
使用 TreeSet 数据结构保证应用级别服务发现时应用名称的顺序一致
RegistryNotifier 的第一个十次通知不延迟
dubbo-compile 编译使用新的格式生成 stub
Mesh 服务治理规则在动态配置中心的分组和其他规则分组统一，由 DEFAULT_GROUP 改成 dubbo
使用 nacos 用作注册中心时，可以在注册中心地址中使用参数来改变在 nacos 中的分组
计算 ServiceInfo 的 reversion 时，移除运行时参数，避免生成多个 reversion
Nacos 注册中心抛出异常时，将异常封装称 RpcException 抛出
禁止动态配置中心对一些权限参数进行动态修改
优化 Config Bean 的初始化流程，并兼容 spring 3.x/4.1.x
Bootstrap.start 方法可重入，暴露或引用新的服务
将 org.apache.dubbo 包中的类默认添加到白名单中
保证生成的 Config 的 Id 唯一，并检查 Config 是否之前存在
Javaassist 兼容改变 override 声明字段
重构解码时的检查逻辑，当找不到 path, version 对应的提供者是，抛出异常
当 ApplicationModel 为 null 时，兼容 adaptive extensions

代码质量提升

感谢以下提高 Apache Dubbo 的稳定性的贡献。

#8111, #8147, #8164, #8177, #8180, #8161, #8183, #8205, #8215, #8173, #8219, #8228, #8232, #8230, #8236, #8260, #8262, #8252, #8246, #8208, #8278, #8267, #8277, #8291, #8296, #8302, #8175, #8319, #8309, #8336, #8332, #8328, #8355, #8396, #8401, #8395, #8415, #8406, #8411, #8418, #8439, #8404, #8443

Maven依赖变化

移除依赖: org.eclipse.collections:eclipse-collections
移除依赖: com.google.guava:guava
jetty: 9.4.11.v20180605 -> 9.4.43.v20210629
apollo client: 1.1.1 -> 1.8.0
snakeyaml: 1.20 -> 1.29
tomcat embed: 8.5.31 -> 8.5.69
nacos client: 2.0.0 -> 2.0.2
swagger: 1.5.19 -> 1.5.24
hessian_lite: 3.2.8 -> 3.2.11

Blog: 3.0.1 发版公告

Fri, 02 Jul 2021 00:00:00 +0000

优化

重构服务自省映射关系，支持地址迁移时直接配置上游应用名
为 Spring 扫描添加缓存
优化配置覆盖逻辑
支持 Servlet 环境下控制 Dubbo 生命周期
添加 ServiceListener 用于监听 ServiceConfig
优化方法回调参数设置

Bug 修复

启用强制校验
更正多注册中心情况下，一个注册中心启动时无地址就销毁的逻辑
移除冗余的日志输出
忽略无效的 MetadataReportConfig
修复消费端启动时 NPE 的情况
修复若干和低版本兼容问题
修复若干应用级服务发现逻辑存在的问题
优化地址迁移规则，支持应用级地址重订阅
修复 MetadataInfo 存在 NPE 的情况
修复应用级注册到注册中心的实例信息被错误覆盖的问题

代码质量提升

感谢以下提高 Apache Dubbo 的稳定性的贡献。

#8043, #8044, #8048, #8071, #8119, #8132

Blog: dubbo-go 1.5.0

Thu, 14 Jan 2021 00:00:00 +0000

引语

计算机技术浪潮每 10 年都有一次技术颠覆，相关知识体系最迟每 5 年都会革新一次，大概每两年贬值一半，在应用服务通信框架领域亦然。凡是有长期生命的通信框架，大概有 5 年的成长期和 5 年的稳定成熟期。每个时代都有其匹配的应用通信框架，在 20 年前的 2G 时代，强跨语言跨平台而弱性能的 gRPC 是不会被采用的。

每个通信框架，不同的人从不同角度看出不同的结论：初学者看重易用易学，性能测评者注重性能，应用架构师考虑其维护成本，老板则考虑则综合成本。一个应用通信框架的性能固然重要，其稳定性和进化能力更重要，得到有效维护的框架可在长时间单位内降低其综合成本：学习成本、维护成本、升级成本和更换成本。

什么是 Dubbo-go？第一，它是 Dubbo 的 Go 语言版本，全面兼容 Dubbo 是其第一要义。第二，它是一个 Go 语言应用通信框架，会充分利用作为云原生时代第一语言—Go 语言的优势，扩展 dubbo 的能力。

2008 年诞生的 Dubbo 已有十多年历史，依靠阿里和其社区，历久弥新。2016 年发布的 Dubbo-go 也已进入第五个年头，如今全面兼容 Dubbo v2.7.x 的 Dubbo-go v1.5 终于发布了。

回首过往，Dubbo-go 已经具备如下能力：

互联互通：打通了 gRPC 和 Spring Cloud 生态；
可观测性：基于 OpenTracing 和 Prometheus，使得其在 Logging、Tracing 和 Metrics 方面有了长足进步；
云原生：Dubbo-go 实现了基于 Kubernetes API Server 为注册中心的通信能力，做到了升级成本最低。

毋庸讳言，相较于现有成绩，发展阶段的 Dubbo-go 对未来有更多的期待之处：

易用性：Dubbo-go 的入门成本并不低，把很多感兴趣者挡在了门外。但好消息是，随着 Dubbo-go 在阿里内部的逐步推开，阿里中间件团队对其进行了进一步的封装，经生产环境检验后会开放给社区使用。
云原生：目前的 Dubbo-go 的基于 kubernetes 的方案，从技术分层角度来看， Kubernetes API Server 终究是系统的运维态组件，不应该暴露给应用层，否则会造成 APIServer 自身通信压力过大，且系统整体风险很高：应用层使用不当，或者框架自身的流量方面的 bug，可能会把 APIServer 打垮，后果就是造成整体后端服务能力的瘫痪！所以应用层需要感知的是 kubernetes 提供给应用层的 Operator，不断进化的 Dubbo-go 计划在 v1.6 版本中发布 Dubbo-go Operator。

雄关漫道真如铁，而今迈步从头越。Dubbo-go 社区【钉钉群 23331795】与 Dubbo-go 同在。

应用维度注册模型

经过一段时间的努力之后，我们终于完成了应用维度的服务注册与发现。和原本已有的接口维度的注册模型比起来，新的注册模型有两个突出特点：

和主流的注册模型保持一致。目前的主流做法都是按照应用为基本单位来进行注册的，如Spring Cloud。在支持应用维度注册之后，对于接下来的云原生支持，奠定了基础；
大幅度减轻对注册中心的压力。在该模型之下，从注册中心的视角看过去，集群规模只和实例数量成正比，而不是现有的和服务数量成正比；

当然，我们在设计的时候就考虑到了用户的迁移成本。要迁移到新的注册模型，只需要将现有使用的注册中心换成新的 ServiceDiscoveryRegistry 就可以。

ServiceDiscoveryRegistry 是支持多种实现的。目前来说，我们支持：

nacos;
etcd;
zookeeper;

我们提倡新上线的业务尽量使用 nacos 和 etcd 这种更可靠稳定的注册中心。

Metadata Report 元数据中心

v1.5 版本在支持应用维度注册模型时，有很重要的一个问题需要解决，即接口维度的元数据存储。服务维度的注册模型和应用维度的注册模型，本质的区别是往注册中心注册的数据维度的不一致。虽然我们在应用维度注册模型中，将接口维度的数据从注册中心中剔除了，但是在rpc的框架中，一个 consumer 要想真正找到想要调用的服务地址，就必须得到 provider 端开放的服务信息。这部分数据，在 v1.5 版本中，我们将它们存储到了元数据中心中。

元数据中心，是一个接口定义。泛指一块存储区域，可以对接口级别的元数据进行存储、读取，provider 端调用存储，consumer 端调用读取。元数据中心中的数据需要保持准确性、实时性。

目前元数据中心，有两个父类（Go 中没有继承，此处说的父子类，单纯指子类对父类的组合关系）实现，一个是 local 实现，一个是 remote 实现。local 实现是将 provider 的内存作为虚拟元数据中心，remote 实现是指依赖 ZooKeeper、etcd、nacos 等注册中心作为元数据中心。目前 remote 有 zookeeper、nacos、etcd 和 consul 的子类实现。即用户可以将元数据信息，通过以上的第三方注册中心进行数据存储和分发。

Invocation 接口支持 attribute 属性

invocation 结构中新增 attribute 属性支持，用于流程内部的属性存储。和 attachment 不同点在于，attachment会从 consumer 传递到 provider，但 attribute 属性不会。

k8s注册中心

在 v1.5 版本之前，k8s 注册中心的实现是通过直接使用 k8s client 中Pod对象的 List&&Watch 接口。在本次迭代中引入了 k8s informer。这样做的原因在于两点，首先一定的程度上来讲 dubbo-go 的 k8s 注册中心也是一个 k8s controller，使用 informer 的模式更加 k8s native。更重要的是社区计划后续向 CRD+Operator 的模式演进，informer 模式是对后续的演进的探索。除了这个铺垫之外，本次迭代还对跨 namespace 的服务发现做了支持。再有就是为了减少对 kube-apiserver List&&Watch 的压力，对 provider 和 consumer 的行为进行了区分，provider 不再进行 Watch 而仅对 kube-apiserver 进行写操作。

优化路由模型

在 1.5 版本之前，Router 模型中属性是包含：优先级与路由属性，Router Chain 只包含路由属性。从中能识别出其实 Router Chain 也是一种特殊 Router。1.5 版本之后，使 Router 更抽象，分离出其优先级属性，新增 Priority Router、Chain 继承 Router 使其变为特殊的 Router，使关系上看起来更加清晰。如下图：

回顾与展望

Dubbo-go 处于一个比较稳定成熟的状态。目前新版本正处于往云原生方向的尝试，应用服务维度注册是首先推出的功能，这是一个和之前模型完全不一样的新注册模型。该版本是我们朝云原生迈进新一步的关键版本。除此之外，包含在该版本也有一些之前提到的优化。

下一个版本 v1.5.1，虽然仍是以兼容 Dubbo 2.7.x 为主要任务，但在分布式能力的增强上，也是我们关注的重点。

在分布式事务方面，有一个重要的基于 Seata 扩展实现。通过增加过滤器，在服务端接收 xid 并结合 seata-golang¹ 达到支持分布式事务的目的。从而使 Dubbo-go 在分布式场景下，让用户有更多的选择，能适应更多的个性化场景。

与此同时，在传输链路安全性上，TLS 安全传输链路是该版本重要功能之一。通过提供统一入口，未来能引入更多的与传输链路安全性相关的功能，适应用户不一样的使用场景。

注册中心模型上，支持多注册中心集群负载均衡。业务部署假设是双注册中心（图 1 ），从原来双注册中心中所有 Provider 一起选址。优化成选址时的多了一层注册中心集群间的负载均衡（图 2 ）。

（图 1 ）

（图 2 ）

以前的 dubbo-go RPC 层直接复用了 getty 框架的 RPC[²(https://github.com/AlexStocks/getty/tree/feature/rpc)]，未能实现协议和应用通信地址的隔离。阿里中间件展图同学重构了 dubbo-go RPC 层，实现了连接复用：可以实现 consumer 与 provider 端的同一个 TCP 连接上进行多协议通信。相关 PR 业已合并，会在 dubbo-go v1.5.1 中发布。

目前下一个版本正在紧锣密鼓的开发中，具体规划及任务清单³ ，都已经在 Github 上体现。

Blog: dubbo-go 1.5.1

Thu, 14 Jan 2021 00:00:00 +0000

近期我们发布了 dubbo-go v1.5.1，虽然是 v1.5 的一个子版本，但相比于 v1.5.0，社区还是投入了很大人力添加了如下重大改进。

1 应用维度注册模型

在新模型 release 后，我们发现 Provider 每个 URL 发布元数据都会注册 ServiceInstance，影响性能需要优化。

我们的优化方案是：

去除 ServiceDiscoveryRegistry 中注册 ServiceInstance 的代码，在 config_loader 中的loadProviderConfig 方法的最后注册 ServiceInstance

具体步骤：

获取所有注册的 Registry，过滤出 ServiceDiscoveryRegistry，拿取所有 ServiceDiscovery。
创建 ServiceInstance。
每个 ServiceDiscovery 注册 ServiceInstance。

保证 Provider 在注册成功之后，才暴露元数据信息。

2 支持基于 Seata 的事务

基于 Seata 扩展实现。通过增加过滤器，在服务端接收 xid 并结合 seata-golang 达到支持分布式事务的目的。从而使 Dubbo-go 在分布式场景下，让用户有更多的选择，能适应更多的个性化场景。

我们在 dubbo-samples 中给出了事务测试用例。

3 多注册中心集群负载均衡

对于多注册中心订阅的场景，选址时的多了一层注册中心集群间的负载均衡：

在 Cluster Invoker 这一级，我们支持的选址策略有：

指定优先级
同 zone 优先
权重轮询

4 传输链路安全性

该版本在传输链路的安全性上做了尝试，对于内置的 Dubbo getty Server 提供了基于 TLS 的安全链路传输机制。

为尽可能保证应用启动的灵活性，TLS Cert 的指定通过配置文件方式，具体请参见 Dubbo-go 配置读取规则与 TLS 示例：

5 路由功能增强

本次路由功能重点支持了动态标签路由和应用/服务级条件路由。

5.1 动态标签路由

标签路由通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景的能力基础。

标签主要是指对 Provider 端应用实例的分组，目前有两种方式可以完成实例分组，分别是动态规则打标和静态规则打标，其中动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。

5.1.1 动态规则打标

可随时在服务治理控制台下发标签归组规则

# governance-tagrouter-provider应用增加了两个标签分组tag1和tag2
# tag1包含一个实例 127.0.0.1:20880
# tag2包含一个实例 127.0.0.1:20881
---
 force: false
 runtime: true
 enabled: true
 key: governance-tagrouter-provider
 tags:
 - name: tag1
 addresses: ["127.0.0.1:20880"]
 - name: tag2
 addresses: ["127.0.0.1:20881"]
 ...

5.1.2 静态规则打标

可以在 server 配置文件的 tag 字段里设置

services:
 "UserProvider":
 registry: "hangzhouzk"
 protocol : "dubbo"
 interface : "com.ikurento.user.UserProvider"
 loadbalance: "random"
 warmup: "100"
 tag: "beijing"
 cluster: "failover"
 methods:
 - name: "GetUser"
 retries: 1
 loadbalance: "random"

consumer 添加 tag 至 attachment 即可

ctx := context.Background()
attachment := make(map[string]string)
attachment["dubbo.tag"] = "beijing"
ctx = context.WithValue(ctx, constant.AttachmentKey, attachment)
err := userProvider.GetUser(ctx, []interface{}{"A001"}, user)

请求标签的作用域为每一次 invocation，使用 attachment 来传递请求标签，注意保存在 attachment 中的值将会在一次完整的远程调用中持续传递，得益于这样的特性，我们只需要在起始调用时，通过一行代码的设置，达到标签的持续传递。

5.1.3 规则详解

格式

Key明确规则体作用到哪个应用。必填。
enabled=true 当前路由规则是否生效，可不填，缺省生效。
force=false 当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为 false。
runtime=false 是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，必须设为 true，需要注意设置会影响调用的性能，可不填，缺省为 false。
priority=1 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
tags 定义具体的标签分组内容，可定义任意n（n>=1）个标签并为每个标签指定实例列表。必填
- name，标签名称
addresses，当前标签包含的实例列表

降级约定

dubbo.tag=tag1 时优先选择标记了 tag=tag1 的 provider。若集群中不存在与请求标记对应的服务，默认将降级请求 tag 为空的 provider；如果要改变这种默认行为，即找不到匹配 tag1 的 provider 返回异常，需设置dubbo.force.tag=true。
dubbo.tag 未设置时，只会匹配 tag 为空的 provider。即使集群中存在可用的服务，若 tag 不匹配也就无法调用，这与约定 1 不同，携带标签的请求可以降级访问到无标签的服务，但不携带标签/携带其他种类标签的请求永远无法访问到其他标签的服务。

5.2 应用/服务级条件路由

您可以在路由规则配置中配置多个条件路由及其粒度

Sample:

# dubbo router yaml configure file
routerRules:
 - scope: application
 key: BDTService
 priority: 1
 enable: false
 force: true
 conditions : ["host = 192.168.199.208 => host = 192.168.199.208 "]
 - scope: service
 key: com.ikurento.user.UserProvider
 priority: 1
 force: true
 conditions : ["host = 192.168.199.208 => host = 192.168.199.208 "]

5.2.1 规则详解

各字段含义

scope表示路由规则的作用粒度，scope的取值会决定key的取值。必填。
- service 服务粒度
application 应用粒度
Key明确规则体作用在哪个服务或应用。必填。
- scope=service时，key取值为[{group}/]{service}[:{version}]的组合
scope=application时，key取值为application名称
enabled=true 当前路由规则是否生效，可不填，缺省生效。
force=false 当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为 false。
runtime=false 是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，必须设为 true，需要注意设置会影响调用的性能，可不填，缺省为 false。
priority=1 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
conditions 定义具体的路由规则内容。必填。

6 回顾与展望

下一个版本 v1.5.2，本次的关注重点以通信模型改进为主，除此之外，与 2.7.x 的兼容性、易用性及质量保证也是本次关注的信息。

在服务发现，会支持更加多的方式，如：文件、Consul。从而使 Dubbo-go 在服务发现场景下，让用户有更多的选择，能适应更多的个性化场景。

另外 易用性及质量保证，主要关注的是 samples 与自动化构建部分。可降低用户上手 Dubbo-go 的难度，提高代码质量。

目前下一个版本正在紧锣密鼓的开发中，具体规划及任务清单¹ ，都已经在 Github 上体现。

https://github.com/apache/dubbo-go/projects/10 ↩︎

Blog: dubbo-go-hessian2 v1.6.0

Thu, 14 Jan 2021 00:00:00 +0000

1. 增加缓存优化

dubbo-go-hessian2 在解析数据的数据大量使用到了 struct 的结构信息，这部分信息可以缓存起来反复利用，使得性能提升了一倍。优化过程记录可以详细阅读《记一次对 dubbo-go-hessian2 的性能优化》.

对应 pr #179，作者 micln。

2. string 解析性能优化

由于 hessian （ dubbo 序列化协议，下称：hessian ）对 string 的定义是16 bit 的 unicode 的 UTF-8 表示形式，字符长度表示是16 bit 的字符数。这是仅针对 java 制定的规范，java 中一个字符是16 bit，对应到 UTF-16. hessian 库也是对每一个字符进行转码序列化。但 golang 里面字符是和 UTF-8 对应的，dubbo-go-hessian2 里面的 rune 是 32bit，和 unicode一一映射。对于 U+10000 ~ U+10FFFF 的字符，需按照 UTF16 的规范，将字符转换为 2 个字节的代理字符，再做转换，才能和 java 的序列化方式对应起来。

原来不管是编码还是解析都是一个字符一个字符处理，特别是解析的时候，从流里面一个字节一个字节读取并组装成 rune，然后再转换为 string，这样效率特别低。我们的优化方案是，批次读取字节流到 buffer 中，对 buffer 进行解析转为 UTF-8 数组，并统计字符数量。其中需要对代理对字符将其转换为标准 UTF-8 子节数组。如果统计的字符数量不足，再进一步读取流种的数据进行解析。通过此方式提升一倍的解析效率。

对应 pr #188，作者 zonghaishang。

3. 解析忽略不存在的字段

hessian 库在解析数据的时候，对于一个 class 字段，如果不存在，则直接忽略掉。但 v1.6.0 版本之前 dubbo-go-hessian2 解析数据，如果遇到不存在的字段，会返回 error。从 v1.6.0 开始，与 hessian 一样，忽略不存在的字段。因为这是一个特性的变更，所以升级的同学一定要注意了。

对应 pr #201，作者 micln & fangyincheng。

4. 解决浮点数精度丢失问题

在对 float32 类型进行序列化时，我们一律强制转换为 float64 再进行序列化操作。由于浮点数的精度问题，在这个转换过程中可能出现小数点后出现多余的尾数，例如 (float32)99.8–>(float64)99.80000305175781。

1.6.0 版本对 float32 的序列化进行了优化：

如果小数尾数小于 3 位，根据 hessian2 协议序列化为 double 32-bit 格式
否则先转换为 string 类型，再转换为 float64 类型，这样做可以避免由于浮点数精度问题产生多余的尾数，最后对 float64 进行序列化。

虽然对 float32 类型进行了优化，但是依然建议使用浮点数的时候优先使用 float64 类型。

对应 pr #196，作者 willson-chen。

5. 解决 attachment 空值丢失问题

dubbo 请求中包含 attachment 信息，之前如果 attachment 里面含有如 "key1":""，这种 value 为空的情况，解析出来的结果会直接丢失这个属性 key1 ，v1.6.0 修复了此问题，现在解析出来的 attachment 会正确解析出空 value 的属性。

对应 pr #191，作者 champly。

6. 支持 ‘继承’ 和忽略冗余字段

由于 go 没有继承的概念，所以在之前的版本，Java 父类的字段不被 dubbo-go-hessian2 所支持。新版本中，dubbo-go-hessian2 将Java来自父类的字段用匿名结构体对应，如：

type Dog struct {
 Animal
 Gender string
 DogName string `hessian:"-"`
}

同时，就像 json 编码中通过 immediately 可以在序列化中忽略该字段，同理，通过 hessian:"-" 用户也可以让冗余字段不参与 hessian 序列化。

对应pr #154，作者 micln

Blog: dubbo-go-hessian2 v1.7.0

Thu, 14 Jan 2021 00:00:00 +0000

Dubbo-go-hessian2 v1.7.0已发布，详见 https://github.com/apache/dubbo-go-hessian2/releases/tag/v1.7.0，以下对这次更新内容进行详细整理。

另外v1.6.3 将 attachment 类型由 map[string]stiring 改为map[string]interface{} 导致版本不兼容问题，这部分已还原，后续的计划是将dubbo协议的request/response对象整体迁移到dubbogo项目中进行迭代修改， hessian2中将不再改动到request/response对象。

1. New Features

1.1 add GetStackTrace method into Throwabler and its implements. #207

go语言client请求java语言服务时，如果java语言抛出了异常，异常对应的堆栈信息是被保存在StackTraceElement中。

这个异常信息在日志中最好能被打印出来，以方便客户端排查问题，所以在Throwabler和对应子类中增加了StackTraceElement的获取。

注：其实还有一种更好的方法，所有的具体的异常类型都包含java_exception/exception.go的Throwable struct。这样只需要在Throwable中增加GetStackTrace方法就可以了。但是这种方式需要更多的测试验证，改动的逻辑相对会复杂一些。但是代码会更整洁。这里先不用这种方法。

1.2 catch user defined exceptions. #208

golang中增加一个java中Exception对象的序列化输出方法：

func JavaException() []byte {
 e := hessian.NewEncoder()
 exception := java_exception.NewException("java_exception")
 e.Encode(exception)
 return e.Buffer()
}

在output/output.go 提供调用入口:添加如下函数初始化声明

func init() {
 funcMap["JavaException"] = testfuncs.JavaException
}

java代码中增加调用go方法序列化结果:

说明: Assert.assertEquals 不能直接比较Exception对象是否相等

 /**
 * test java java.lang.Exception object and go java_exception Exception struct
 */
 @Test
 public void testException() {
 Exception exception = new Exception("java_exception");
 Object javaException = GoTestUtil.readGoObject("JavaException");
 if (javaException instanceof Exception) {
 Assert.assertEquals(exception.getMessage(), ((Exception) javaException).getMessage());
 }
 }

1.3 support java8 time object. #212, #221

golang中增加一个java8对象的序列化输出方法：

// test java8 java.time.Year
func Java8TimeYear() []byte {
 e := hessian.NewEncoder()
 year := java8_time.Year{Year: 2020}
 e.Encode(year)
 return e.Buffer()
}
// test java8 java.time.LocalDate
func Java8LocalDate() []byte {
 e := hessian.NewEncoder()
 date := java8_time.LocalDate{Year: 2020, Month: 9, Day: 12}
 e.Encode(date)
 return e.Buffer()
}

在output/output.go 提供调用入口:添加函数初始化声明

func init() {
 funcMap["Java8TimeYear"] = testfuncs.Java8TimeYear
 funcMap["Java8LocalDate"] = testfuncs.Java8LocalDate
}

java代码中增加调用go方法序列化结果:

/**
 * test java8 java.time.* object and go java8_time/* struct
 */
@Test
public void testJava8Year() {
 Year year = Year.of(2020);
 Assert.assertEquals(year
 , GoTestUtil.readGoObject("Java8TimeYear"));
 LocalDate localDate = LocalDate.of(2020, 9, 12);
 Assert.assertEquals(localDate, GoTestUtil.readGoObject("Java8LocalDate"));
}

1.4 support test golang encoding data in java. #213

为了更好的测试验证hessian库，原来已经支持在golang中测试java的序列化数据，现在增加在java中测试golang的序列化数据，实现双向测试验证。

golang中增加序列化输出方法:

func HelloWorldString() []byte {
 e := hessian.NewEncoder()
 e.Encode("hello world")
 return e.Buffer()
}

将该方法注册到output/output.go中

 // add all output func here
 func init() {
 funcMap["HelloWorldString"] = testfuncs.HelloWorldString
}

output/output.go 提供调用入口:

func main() {
 flag.Parse()
 if *funcName == "" {
 _, _ = fmt.Fprintln(os.Stderr, "func name required")
 os.Exit(1)
 }
 f, exist := funcMap[*funcName]
 if !exist {
 _, _ = fmt.Fprintln(os.Stderr, "func name not exist: ", *funcName)
 os.Exit(1)
 }
 defer func() {
 if err := recover(); err != nil {
 _, _ = fmt.Fprintln(os.Stderr, "error: ", err)
 os.Exit(1)
 }
 }()
 if _, err := os.Stdout.Write(f()); err != nil {
 _, _ = fmt.Fprintln(os.Stderr, "call error: ", err)
 os.Exit(1)
 }
 os.Exit(0)
}

java代码中增加调用go方法序列化结果:

public class GoTestUtil {
 public static Object readGoObject(String func) {
 System.out.println("read go data: " + func);
 try {
 Process process = Runtime.getRuntime()
 .exec("go run output/output.go -func_name=" + func,
 null,
 new File(".."));
 int exitValue = process.waitFor();
 if (exitValue != 0) {
 Assert.fail(readString(process.getErrorStream()));
 return null;
 }
 InputStream is = process.getInputStream();
 Hessian2Input input = new Hessian2Input(is);
 return input.readObject();
 } catch (Exception e) {
 e.printStackTrace();
 return null;
 }
 }
 private static String readString(InputStream in) throws IOException {
 StringBuilder out = new StringBuilder();
 InputStreamReader reader = new InputStreamReader(in, StandardCharsets.UTF_8);
 char[] buffer = new char[4096];
 int bytesRead;
 while ((bytesRead = reader.read(buffer)) != -1) {
 out.append(buffer, 0, bytesRead);
 }
 return out.toString();
 }
}

增加java测试代码:

@Test
public void testHelloWordString() {
 Assert.assertEquals("hello world"
 , GoTestUtil.readGoObject("HelloWorldString"));
}

1.5 support java.sql.Time & java.sql.Date. #219

增加了 java 类 java.sql.Time, java.sql.Date 支持，分别对应到hessian.Time 和 hessian.Date，详见 https://github.com/apache/dubbo-go-hessian2/pull/219/files。

2. Enhancement

2.1 Export function EncNull. #225

开放 hessian.EncNull 方法，以便用户特定情况下使用。

3. Bugfixes

3.1 fix enum encode error in request. #203

原来在 dubbo request 对象中没有判断 enum 类型的情况，此pr增加了判断是不是POJOEnum类型。详见 https://github.com/apache/dubbo-go-hessian2/pull/203/files

3.2 fix []byte field decoding issue. #216

v1.7.0 之前如果 struct中包含[]byte字段时无法反序列化, 报错“error list tag: 0x29”，主要原因是被当做list进行处理，对于这种情况应该按照binary数据进行处理即可。

type Circular struct {
 Num int
 Previous *Circular
 Next *Circular
 ResponseDataBytes []byte // <----
}
func (Circular) JavaClassName() string {
 return "com.company.Circular"
}

3.3 fix decoding error for map in map. #229

v1.7.0 之前嵌套map无法正确解析，主要原因是对应的map对象被当做一个数据类型却未被自动加到类引用列表中，而嵌套map类信息是同一类型的引用，去类引用列表找，找不到就报错了。解决这个问题的方法就是遇到map类对象，也将其加入到类引用列表中即可。问题详细参考 #119.

3.4 fix fields name mismatch in Duration class. #234

这个 PR 解决了Duration对象中字段错误定义，原来是"second/nano"，应该是"seconds/nanos"。

同时改善了测试验证数据。之前使用0作为int字段的测试数据，这是不准确的，因为int类型默认值就是0.

Blog: dubbo-go 1.4.0

Tue, 12 Jan 2021 00:00:00 +0000

得益于社区活跃的支持，2020 年 3 月 25 日我们发布了一个让人兴奋的版本——dubbo-go v1.4.0。除了继续支持已有的 Dubbo 的一些特性外， dubbo-go 开始了一些自己的创新尝试。

这个版本，最大的意义在于，做了一些支持云原生的准备工作。比如说，社区在探讨了很久的 k8s 落地之后，终于拿出来了使用 k8s 作为注册中心的解决方案。

其次一个比较大的改进是–我们在可观测性上也迈出了重要的一步。在这之前，dubbo-go只提供了日志这么一个单一手段，内部的信息比较不透明，这个版本将有很大的改善。

最后一个令人心动的改进是，我们支持了 REST 协议。

1. K8s 注册中心

dubbo-go 注册中心的本质为K/V型的数据存储。当前版本实现了以 Endpoint 为维度在 k8s API Server 进行服务注册和发现的方案【下文简称 Endpoint 方案】，架构图如下。

Endpoint 方案，首先将每个 dubbo-go 进程自身服务信息序列化后，通过 Kubernetes 提供的 Patch 的接口写入在自身 Pod 对象的 Annotation 中。其次，通过 Kubernetes 的 Watch 接口观察集群中本 Namespace 内带有某些固定lable [见上图] Pod 的Annotation 信息的更新，处理服务健康检查、服务上下线等情况并实时更新本地缓存。整体流程仅使用 Kubernetes 原生 API 完成将 Kubernetes 作为注册中心的功能特性。

这个方案非常简洁，不需要实现额外的第三方模块，也不需要对 Dubbo 业务作出改动，仅仅把 k8s 当做部署平台，依赖其容器管理能力，没有使用其 label selector 和 service 等服务治理特性。如果站在 k8s Operator 的角度来看，Operator 方案的优点即 Endpoint 方案的缺点，Endpoint 方案无法使用 k8s 的健康检查能力，亦没有使用 k8s service 的事件监听能力，每个 consumer 冗余监听一些不必要监听的事件，当 Endpoint 过多时会加大 API Server 的网络压力。

目前 dubbo-go 社区其实已经有了 operator 版本注册中心的技术方案，后续版本【计划版本是 v1.6】的 dubbo-go 会给出其实现。相比当前实现，operator 方案开发和线上维护成本当然上升很多。二者如同硬币的两面，社区会让两种方式会共存，以满足不同 level 的使用者。

注意: 因 Pod 被调度而 IP 发生变化时，当前版本的 configuration 以及 router config 模块暂时无法动态更新。这有待于我们进一步解决。

参考范例¹.

2. tracing 和 metric

可观测性是微服务重要的一环，也是我们1.4版本着力支持的部分。在1.4版本中，我们主要在 tracing 和 metric 两个方向提供了支持。

为了支持 tracing 和 metric，关键的一点是支持context在整个调用过程中传递。为此我们解决了context跨端传递的问题。目前用户可以在接口中声明 context 并且设置值，dubbo-go 在底层完成 context 内容从 client 传递到 server 的任务。

在 metric 方面，dubbo-go 开始支持 Prometheus 采集数据了。目前支持 Prometheus中的 Histogram 和 Summary。用户也可以通过扩展 Reporter 接口来自定义数据采集。

在 tracing 方面，目前 dubbo-go 的设计是采用 opentracing 作为统一的 API，在该 API 的基础上，通过在 client 和 server 之中传递 context，从而将整个链路串起来。用户可以采用任何支持 opentracing API 的监控框架来作为实现，例如 zipkin，jaeger 等。

3. rest协议支持

Dubbo 生态的应用与其他生态的应用互联互通，一直是 dubbo-go 社区追求的目标。dubbo-go v1.3 版本已经实现了 dubbo-go 与 grpc 生态应用的互联互通，若想与其他生态如 Spring 生态互联互通，借助 rest 协议无疑是一个很好的技术手段。

Rest 协议是一个很强大并且社区呼声很高的特性，它能够有效解决 open API，前端通信，异构系统通信等问题。比如，如果你的公司里面有一些陈年代码是通过 http 接口来提供服务的，那么使用我们的 rest 协议就可以无缝集成了。

通过在 dubbo-go 中发布 RESTful 的接口的应用可以调用任意的 RESTful 的接口，也可以被任何客户端以 http 的形式调用，框架图如下：

在设计过程中，考虑到不同的公司内部使用的 web 框架并不相同，所以我们允许用户扩展自己 rest server （ web 框架在 dubbo-go的封装）的实现，当然，与 rest server 相关的，诸如 filter 等，都可以在自己的 rest server 实现内部扩展。

4. 路由功能增强

路由规则在发起一次 RPC 调用前起到过滤目标服务器地址的作用，过滤后的地址列表，将作为消费端最终发起 RPC 调用的备选地址。v1.4 版本的 dubbo-go 实现了 Condition Router 和 Health Instance First Router，将在后面版本中陆续给出诸如 Tag Router 等剩余 Router 的实现。

4.1 条件路由

条件路由，是 dubbo-go 中第一个支持的路由规则，允许用户通过配置文件及远端配置中心管理路由规则。

与之相似的一个概念是 dubbo-go 里面的 group 概念，但是条件路由提供了更加细粒度的控制手段和更加丰富的表达语义。比较典型的使用场景是黑白名单设置，灰度以及测试等。

参考范例²。

4.2 健康实例优先路由

在 RPC 调用中，我们希望尽可能地将请求命中到那些处理能力快、处于健康状态的实例，该路由的功能就是通过某种策略断定某个实例不健康，并将其排除在候选调用列表，优先调用那些健康的实例。这里的"健康"可以是我们自己定义的状态，默认实现即当错误比例到达某一个阈值时或者请求活跃数大于上限则认为其不健康，允许用户扩展健康检测策略。

在我们服务治理里面，核心的问题其实就在于如何判断一个实例是否可用。无论是负载均衡、

熔断还是限流，都是对这个问题的解答。所以，这个 feature 是一个很好的尝试。因为我们接下来计划提供的特性，基于规则的限流以及动态限流，都是要解决“如何断定一个实例是否可用”这么一个问题。

所以欢迎大家使用这个特性，并向社区反馈各自设定的健康指标。这对我们接下来的工作会有很大的帮助。

5. hessian 协议增强

相较于 dubbo 的 Java 语言以及其他多语言版本，dubbo-go 社区比较自豪的地方之一就是：无论底层网络引擎还是原生使用的 hessian2 协议，以及整体服务治理框架，都由 dubbo-go 社区从零开发并维护。v1.4 版本的 dubbo-go 对 hessian2 协议又带来了诸多新 feature。

5.1 支持 dubbo 协议的 attachments

在 dubbo-go中，attachments 机制用于传递业务参数之外的附加信息，是在客户端和服务端之间传递非业务参数信息的重要方式。

hessian 编码协议将之编码在 body 内容的后面进行传输，dubbo-go-hessian2 之前并不支持读/写 attachments，在多个使用方【如蚂蚁金服】的要求下，dubbo-go-hessian2 以兼容已有的使用方式为前提，支持了 attachments 的读/写。

Request 和 Response 的 struct 中定义了 attachments 的 map，当需要使用 attachments，需要由使用方构造这两种类型的参数或者返回对象。否则，将无法在hessian的传输流中获取和写入attachments。

另外，利用 dubbo-go 调用链中传输 context 的功能，用户已经可以在服务方法中通过 context 添加 attachments了。

5.2 支持忽略非注册 pojo 的解析方式

由于 hessian 编码协议与 Java 的类型高度耦合，在 golang 的实现中会相对比较麻烦，需要有指明的对应类型。dubbo-go-hessian2 的实现方式是：定义 POJO 接口，要求实现 JavaClassName 方法来供程序获取 Java 对应的类名。这导致了接收到包含未注册类的请求时，将会无法解析而报错，这个问题以前是无法解决的。

但是，有一些使用场景如网关或者 service mesh 的 sidecar，需要在不关心 Java 类的具体定义的情况下，像 http读取 header 信息一样仅仅读取 dubbo 请求的附加信息，将 dubbo/dubbo-go 请求转发。通过该 feature，网关/sidecar 并不关注请求的具体内容，可以在解析请求的数据流时跳过无法解析的具体类型，直接读取 attachments 的内容。

该实现通过在 Decoder 中添加的 skip 字段，对每一个 object 做出特殊处理。

5.3 支持 java.math.BigInteger 和 java.math.BigDecimal

在 Java 服务中，java.math.BigInteger 和 java.math.BigDecimal 是被频繁使用的数字类型，hessian 库将它们映射为 github.com/dubbogo/gost/math/big 下的对应类型。

5.4 支持 ‘继承’ 和忽略冗余字段

type Dog struct {
 Animal
 Gender string
 DogName string `hessian:"-"`
}

同时，就像 json 编码中通过 immediately 可以在序列化中忽略该字段，同理，通过 hessian:"-" 用户也可以让冗余字段不参与 hessian 序列化。

目前，上述四个特性已被某 Go 版本的 sidecar 集成到其商业版本中提供商业服务。

6. Nacos 配置中心

配置中心是现代微服务架构里面的核心组件，现在 dubbo-go 提供了对配置中心的支持。

Nacos 作为一个易于构建云原生应用的动态服务发现、配置管理和服务管理平台，在该版本终于作为配置中心而得到了支持。

参考范例³.

7. 接口级签名认证

Dubbo 鉴权认证是为了避免敏感接口被匿名用户调用而在 SDK 层面提供的额外保障。用户可以在接口级别进行定义是否允许匿名调用，并对调用方进行验签操作，对于验签不通过的消费端，禁止调用。

如上图，总体实现基于 AK/SK 机制，应用通过 HTTPS 通信，启动时向鉴权服务拉取，定期更新。且允许用户自定义获取 AK/SK 的源，在 RPC 层面保障安全性。

8. 回顾与展望

目前 dubbo-go 已经到了一个比较稳定成熟的状态。在接下来的版本里面，我们将集中精力在云原生上。下一个版本，我们将首先实现应用维度的服务注册，这是一个和现有注册模型完全不同的新的注册模型。也是我们朝着云原生努力的一个关键版本。

在可观测性上，我们计划在整个 dubbo-go 的框架内，引入更多的埋点，收集更加多的内部状态。这需要实际生产环境用户的使用反馈，从而知道该如何埋点，收集何种数据。

在限流和熔断上，可以进一步扩展。当下的限流算法，是一种静态的算法–限流参数并没有实时根据当前服务器的状态来推断是否应该限流，它可能仅仅是用户的经验值。其缺点在于，用户难以把握应该如何配置，例如 TPS 究竟应该设置在多大。所以计划引入一种基于规则的限流和熔断。这种基于规则的限流和熔断，将允许用户设置一些系统状态的状态，如 CPU 使用率，磁盘 IO，网络 IO 等。当系统状态符合用户规则时，将触发熔断。

目前这些规划的任务清单⁴，都已经放入在 dubbo-go 项目的 issue 里面，欢迎感兴趣的朋友认领参与开发。dubbo-go 社区在 钉钉群 23331795 欢迎你的加入。

Blog: 2.7.5 功能解析

Mon, 18 May 2020 00:00:00 +0000

近日，备受瞩目的 Dubbo 2.7.5 版本正式发布，在 2.7.5 版本中，Dubbo 引入了很多新的特性、对现有的很多功能做了增强、同时在性能上也有了非常大的提升，这个版本无论对 Dubbo 社区亦或是开发者来说，都将是一个里程碑式的版本。

应用粒度服务注册【beta】
HTTP/2 (gRPC) 协议支持
Protobuf 支持
性能优化，调用链路性能提升 30%
支持 TLS 安全传输链路
优化的消费端线程模型
新增更适应多集群部署场景的负载均衡策略
全新的应用开发 API （兼容老版本应用）【beta】
其他一些功能增强与 bugfix

首先，从服务发现上，新版本突破以往基于接口粒度的模型，引入了全新的基于应用粒度的服务发现机制 - 服务自省，虽然该机制当前仍处于 beta 阶段，但对于 Dubbo 向整个微服务云原生体系靠齐，都打下了非常好的基础；得益于紧凑的协议设计和代码实现上的优化，Dubbo 一直以来都具有较好的性能表现，在 2.7.5 版本中，性能上有了进一步的提升，根据来自官方维护团队的压测，新版本在调用链路上性能提升达到 30%；云原生微服务时代，多语言需求变得越来越普遍，协议的通用性和穿透性对于构建打通前后端的整套微服务体系也变得非常关键，Dubbo 通过实现 gRPC 协议实现了对 HTTP/2 协议的支持，同时增加了与 Protobuf 的结合。

1. 应用粒度服务注册【beta】

从 Java 实现版本的角度来说，Dubbo 是一个面向接口代理的服务开发框架，服务定义、服务发布以及服务引用都是基于接口，服务治理层面包括服务发现、各种规则定义也都是基于接口定义的，基于接口可以说是 Dubbo 的一大优势，比如向开发者屏蔽了远程调用细节、治理粒度更精细等。但基于接口的服务定义同时也存在一些问题，如服务，与业界通用的微服务体系等。

针对以上问题，2.7.5 版本引入了一种新的服务定义/治理机制：服务自省，简单来说这是一种基于应用粒度的服务治理方案。一个实例只向注册中心注册一条记录，彻底解决服务推送性能瓶颈，同时由于这样的模型与主流微服务体系如 SpringCloud、K8S 等天然是对等的，因此为 Dubbo 解决和此类异构体系间的互联互通清除了障碍。有兴趣进一步了解 Dubbo 服务自省机制如何解决异构微服务体系互联互通问题的，可具体参考我们之前的文章解析《Dubbo 如何成为联通异构微服务体系的最佳服务开发框架》。

以下是服务自省机制的基本工作原理图。

要了解更多关于服务自省工作原理的细节，请参与官方文档及后续文章。

服务自省与当前已有的机制之间可以说是互补的关系，Dubbo 框架会继续保持接口粒度的服务治理的优势，实现接口和应用两个粒度互为补充的局面，兼顾性能、灵活性和通用性，力争使 Dubbo 成为微服务开发的最佳框架。

2. HTTP/2 (gRPC) 协议支持

Dubbo RPC 协议是构建在 TCP 之上，这有很多优势也有一些缺点，缺点比如通用性、协议穿透性不强，对多语言实现不够友好等。HTTP/2 由于其标准 HTTP 协议的属性，无疑将具有更好的通用性，现在或将来在各层网络设备上肯定都会得到很好的支持，gRPC 之所以选在 HTTP/2 作为传输层载体很大程度上也是因为这个因素。当前 gRPC 在云原生、Mesh 等体系下的认可度和采用度逐步提升，俨然有成为 RPC 协议传输标准的趋势，Dubbo 和 gRPC 在协议层面是对等竞争的，但是在框架实现上却各有侧重，Dubbo 无疑有更丰富的服务开发和治理体验。

Dubbo 支持 gRPC 协议带来的直观好处有：

正式支持基于 HTTP/2 的远程通信，在协议通用性和穿透性上进一步提升。
支持跨进程的 Stream 流式通信，支持 Reactive 风格的 RPC 编程。
解决了 gRPC 框架难以直接用于微服务开发的问题，将其纳入 Dubbo 的服务治理体系。
为联通组织内部已有的 gRPC 或多语言体系提供支持。

2.7.5 版本开始，gRPC (HTTP/2) 成为 Dubbo 协议体系中的一等公民，对于有需求的开发者完全可以在 Dubbo 开发的微服务体系中启用 gRPC 协议，而不必束缚在 Dubbo 协议自身上，关于这点我们在《Dubbo 如何成为联通异构微服务体系的最佳服务开发框架》一文中也有类似的观点表述。

关于 Dubbo 中如何开发 grpc (HTTP/2) 服务的细节，请参考文章《Dubbo 在跨语言与协议穿透性等方面的探索》，关于如何开启 TLS 和使用 Reactive RPC 编程，请参见示例。另外，Dubbo 的 go 版本目前同样也提供了对 gRPC 协议对等的支持，具体请关注 dubbogo 社区的发版计划。

3. Protobuf 支持

支持 Protobuf 更多的是从解决 Dubbo 跨语言易用性的角度考虑的。

跨语言的服务开发涉及到多个方面，从服务定义、RPC 协议到序列化协议都要做到语言中立，同时还针对每种语言有对应的 SDK 实现。虽然得益于社区的贡献，现在 Dubbo 在多语言 SDK 实现上逐步有了起色，已经提供了包括 Java, Go, PHP, C#, Python, NodeJs, C 等版本的客户端或全量实现版本，但在以上提到的跨语言友好性方面，以上三点还是有很多可改进之处。

协议上 2.7.5 版本支持了 gRPC，而关于服务定义与序列化，Protobuf 则提供了很好的解决方案。

服务定义。当前 Dubbo 的服务定义和具体的编程语言绑定，没有提供一种语言中立的服务描述格式，比如 Java 就是定义 Interface 接口，到了其他语言又得重新以另外的格式定义一遍。因此 Dubbo 通过支持 Protobuf 实现了语言中立的服务定义。
序列化。Dubbo 当前支持的序列化包括 Json、Hessian2、Kryo、FST、Java 等，而这其中支持跨语言的只有 Json、Hessian2，通用的 Json 有固有的性能问题，而 Hessian2 无论在效率还是多语言 SDK 方面都有所欠缺。为此，Dubbo 通过支持 Protobuf 序列化来提供更高效、易用的跨语言序列化方案。

日后，不论我们使用什么语言版本来开发 Dubbo 服务，都可以直接使用 IDL 定义如下服务，具体请参见示例

syntax = "proto3";

option java_multiple_files = true;
option java_package = "org.apache.dubbo.demo";
option java_outer_classname = "DemoServiceProto";
option objc_class_prefix = "DEMOSRV";

package demoservice;

// The demo service definition.
service DemoService {
 rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
 string name = 1;
}

// The response message containing the greetings
message HelloReply {
 string message = 1;
}

4. 性能优化

4.1 调用链路优化

2.7.5 版本对整个调用链路做了全面的优化，根据压测结果显示，总体 QPS 性能提升将近 30%，同时也减少了调用过程中的内存分配开销。其中一个值得提及的设计点是 2.7.5 引入了 Servicerepository 的概念，在服务注册阶段提前生成 ServiceDescriptor 和 MethodDescriptor，以减少 RPC 调用阶段计算 Service 元信息带来的资源消耗。

4.2 消费端线程池模型优化

对 2.7.5 版本之前的 Dubbo 应用，尤其是一些消费端应用，当面临需要消费大量服务且并发数比较大的大流量场景时（典型如网关类场景），经常会出现消费端线程数分配过多的问题，具体问题讨论可参见以下 issue ：

https://github.com/apache/dubbo/issues/2013

改进后的消费端线程池模型，通过复用业务端被阻塞的线程，很好的解决了这个问题。

老的线程池模型

我们重点关注 Consumer 部分：

业务线程发出请求，拿到一个 Future 实例。
业务线程紧接着调用 future.get 阻塞等待业务结果返回。
当业务数据返回后，交由独立的 Consumer 端线程池进行反序列化等处理，并调用 future.set 将反序列化后的业务结果置回。
业务线程拿到结果直接返回

2.7.5 版本引入的线程池模型

业务线程发出请求，拿到一个 Future 实例。
在调用 future.get() 之前，先调用 ThreadlessExecutor.wait()，wait 会使业务线程在一个阻塞队列上等待，直到队列中被加入元素。
当业务数据返回后，生成一个 Runnable Task 并放入 ThreadlessExecutor 队列
业务线程将 Task 取出并在本线程中执行：反序列化业务数据并 set 到 Future。
业务线程拿到结果直接返回

这样，相比于老的线程池模型，由业务线程自己负责监测并解析返回结果，免去了额外的消费端线程池开销。

关于性能优化，在接下来的版本中将会持续推进，主要从以下两个方面入手：

RPC 调用链路。目前能看到的点包括：进一步减少执行链路的内存分配、在保证协议兼容性的前提下提高协议传输效率、提高 Filter、Router 等计算效率。
服务治理链路。进一步减少地址推送、服务治理规则推送等造成的内存、cpu 资源消耗。

5. TLS 安全传输链路

2.7.5 版本在传输链路的安全性上做了很多工作，对于内置的 Dubbo Netty Server 和新引入的 gRPC 协议都提供了基于 TLS 的安全链路传输机制。

TLS 的配置都有统一的入口，如下所示：

Provider 端

SslConfig sslConfig = new SslConfig();
sslConfig.setServerKeyCertChainPath("path to cert");
sslConfig.setServerPrivateKeyPath(args[1]);
// 如果开启双向 cert 认证
if (mutualTls) {
 sslConfig.setServerTrustCertCollectionPath(args[2]);
}

ProtocolConfig protocolConfig = new ProtocolConfig("dubbo/grpc");
protocolConfig.setSslEnabled(true);

Consumer 端

if (!mutualTls) {}
 sslConfig.setClientTrustCertCollectionPath(args[0]);
} else {
 sslConfig.setClientTrustCertCollectionPath(args[0]);
 sslConfig.setClientKeyCertChainPath(args[1]);
 sslConfig.setClientPrivateKeyPath(args[2]);
}

为尽可能保证应用启动的灵活性，TLS Cert 的指定还能通过 -D 参数或环境变量等方式来在启动阶段根据部署环境动态指定，具体请参见 Dubbo 配置读取规则与 TLS 示例

Dubbo 配置读取规则：/zh/docs/user/configuration/configuration-load-process.html

TLS 示例：https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-ssl

如果要使用的是 gRPC 协议，在开启 TLS 时会使用到协议协商机制，因此必须使用支持 ALPN 机制的 Provider，推荐使用的是 netty-tcnative，具体可参见 gRPC Java 社区的总结： https://github.com/grpc/grpc-java/blob/master/SECURITY.md

在服务调用的安全性上，Dubbo 在后续的版本中会持续投入，其中服务发现/调用的鉴权机制预计在接下来的版本中就会和大家见面。

6. Bootstrap API【beta】

在上面讲《服务自省》时，我们提到了 Dubbo 面向接口的设计，面向接口编程、面向接口做服务发现和服务治理。在引入应用粒度服务发现的同时，2.7.5 版本对编程入口也做了优化，在兼容老版本 API 的同时，新增了新的面向应用的编程接口 - DubboBootstrap。

以面向 Dubbo API 编程为例，以前我们要这么写：

ServiceConfig<GreetingsService> service1 = new ServiceConfig<>();
service1.setApplication(new ApplicationConfig("first-dubbo-provider"));
service1.setRegistry(new RegistryConfig("zookeeper://" + zookeeperHost + ":2181"));
service1.export();

ServiceConfig<GreetingsService> service2 = new ServiceConfig<>();
service2.setApplication(new ApplicationConfig("first-dubbo-provider"));
service2.setRegistry(new RegistryConfig("zookeeper://" + zookeeperHost + ":2181"));
service2.export();

......

ApplicationConfig、RegistryConfig、ProtocolConfig 等全局性的配置要在每个服务上去配置；并且从 Dubbo 框架的角度，由于缺少一个统一的 Server 入口，一些实例级别的配置如 ShutdownHook、ApplicationListener、应用级服务治理组件等都缺少一个加载驱动点。

在引入 DubboBootstrap 后，新的编程模型变得更简单，并且也为解决了缺少实例级启动入口的问题

ProtocolConfig protocolConfig = new ProtocolConfig("grpc");
protocolConfig.setSslEnabled(true);

SslConfig sslConfig = new SslConfig();
sslConfig.setXxxCert(...);

DubboBootstrap bootstrap = DubboBootstrap.getInstance();
bootstrap.application(new ApplicationConfig("ssl-provider"))
 .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
 .protocol(protocolConfig)
 .ssl(sslConfig);

ServiceConfig<GreetingsService> service1 = new ServiceConfig<>();
ServiceConfig<GreetingsService> service2 = new ServiceConfig<>();

bootstrap.service(service1).service(service2);
bootstrap.start();

7. 多注册中心集群负载均衡

对于多注册中心订阅的场景，选址时的多了一层注册中心集群间的负载均衡：

在 Cluster Invoker 这一级，我们支持的选址策略有（2.7.5+ 版本，具体使用请参见文档）：

指定优先级

<!-- 来自 preferred=“true” 注册中心的地址将被优先选择，只有该中心无可用地址时才 Fallback 到其他注册中心 -->
<dubbo:registry address="zookeeper://${zookeeper.address1}" preferred="true" />

同 zone 优先

<!-- 选址时会和流量中的 zone key 做匹配，流量会优先派发到相同 zone 的地址 -->
<dubbo:registry address="zookeeper://${zookeeper.address1}" zone="beijing" />

权重轮询

<!-- 来自北京和上海集群的地址，将以 10:1 的比例来分配流量 -->
<dubbo:registry id="beijing" address="zookeeper://${zookeeper.address1}" weight=”100“ />
<dubbo:registry id="shanghai" address="zookeeper://${zookeeper.address2}" weight=”10“ />

默认，stick to 任意可用

关于多注册中心订阅模型，Dubbo 同时也提供了 Multi-Registry 合并的解决思路，欢迎参与到以下 PR 的讨论中: https://github.com/apache/dubbo/issues/5399

8. 其他功能增强

新增地址变更事件通知接口，方便业务侧感知地址变化
新增外围配置加载入口，方便开发者在启动阶段定制服务启动参数
config 模块重构
parameters 扩展配置增强
其他一些 Bugfix

从 Dubbo 框架自身的角度来说，2.7.5 版本也做了很多的重构与优化（比如说 config 模块的重构），这些改动对于使用者来说并无感知的，但是从优化整个 Dubbo 代码内部结构的角度来说，这些改动对后续的功能开发与新机制的引入是一个很好的铺垫。

9. 总结与展望

在后续的版本中，Dubbo 会持续快速的优化与迭代，主要从以下几个方面发力：

继续探索服务自省成为 Dubbo 主推的服务治理模型。
对于企业用户关心的微服务解决方案场景，会持续推进框架的演进，包括当前正在开发的配置、服务鉴权机制、熔断等功能。后续还会尝试联合社区推动周边配套设施如网关、治理平台 Admin 等的建设，非常期待社区能踊跃参与到此部分的建设中。
性能优化上。主要从两个方面着手，一是调用链路的持续优化，同时继续探索新的更通用的 RPC 协议；另一方面是在服务治理推送机制上的优化，以进一步提高 Dubbo 在大规模服务地址推送场景下的表现。
云原生方向。接下来的版本将重点探索，1. 如何更好的支持 Dubbo 在 Kubernetes 上的部署和服务治理；2. 对于混合部署的场景，如传统 VM 和 K8S 体系混合部署、SDK Dubbo 与 Mesh 混合部署的场景，如何提供更好的支持以实现混部场景的长期共存或迁移。