社区动态 on Apache Dubbo

Dubbo Java 3.1.4 正式发布

Thu, 01 Dec 2022 00:00:00 +0000

Dubbo 3.1.4 版本是目前 Dubbo 3 的最新稳定版本，我们建议所有的用户都升级到最新的稳定版本。

Dubbo 3.1.4

新特性

Dubbo QoS 支持指定白名单 IP 列表访问所有命令

Bugfix

修复在泛化调用时 Dubbo Metrics 采集方法名错误
修复使用 Zookeeper 作为元数据中心时，上报接口映射可能存在相互覆盖的问题
修复 timeout countdown 在 Triple 协议的支持
修复 timeout countdown 存在透传的问题
修复多注册中心请求时，由于没有可用的地址导致的 NPE 问题
修复 Mesh 模式下 Triple 获取 remoteApplicationName 为空的问题
修复 GraalVM Native Image 的支持
修复端口复用时无 SSL 连接导致的 NPE 异常
完善 JDK 编译器报错日志的输出格式
修复 MetadataReportConfig 部分配置时应用无法启动的问题
修复 dubbo.reference 作为默认参数在 3.x 版本中不生效的问题
完善 Zookeeper 连接失败的日志
修复 ReferenceConfig 中配置的 ClassLoader 可能被覆盖的问题
修复部分属性在应用级服务发现时被缓存在实例级的地址中导致方法级配置失效的问题
修复 Triple 协议 onError 异常的问题

FAQ

本次发布中有 3 个提交涉及异常日志 FAQ 的完善。关于错误码机制请参考官网错误码机制介绍一文。（https://cn.dubbo.apache.org/zh-cn/overview/java-sdk/reference-manual/faq/intro/）

聚焦稳定性，Dubbo Java 发版规划公布

Sat, 22 Oct 2022 00:00:00 +0000

Dubbo 简介

Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了 Java、Golang 等多语言 SDK 实现。使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力，利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩展，用户可以方便的实现流量拦截、选址的各种定制逻辑。

我应该如何选择版本？

对于这个问题，一直以来 Dubbo 都没有很好地去回答。究其原因保证所有版本的稳定性是一件非常有挑战的事情。比如在 Dubbo 2.7 的一些版本中，出现了一些前后不兼容的问题，给一些用户升级带来了困扰。为此，很多用户从保障稳定性的视角出发，选择了更保守的策略，即生产环境采用被采用最多的版本，此后就不再更新，避免升级过程中出现意外。

但是这种方式无疑是有问题的，一方面这将导致永远无法用上社区新的功能，得到技术演进的红利；另一方面，对于安全漏洞和带来不稳定因素的 bug 等已知问题如果不升级永远会存在，久而久之将给应用带来巨大的风险，很有可能导致严重的安全生产事故。

因此，为了更好地回答这个问题，Dubbo 制定了未来的版本迭代规划，明确版本的稳定性维护机制，提升开发者使用 Dubbo 的信心。

现状

在此前，Dubbo 总共维护了 2.6.x、2.7.x 以及 3.x 三个大版本，其中 2.7.x 为捐献进入 Apache 基金会之后的版本。

2.6.x 在去年已经宣布生命周期结束（EOL）了，而 2.7.x 累计维护了四年的时间了。这四年的时间里，2.7.x 版本经历了多次大的修改，如 2.7.3 版本中对 Nacos 的注册方式进行了修改、2.7.6 版本中添加了应用级服务发现、2.7.9 版本中对应用级服务发现进行大的重构等。

这些修改都对 2.7.x 版本的稳定性带来了巨大的风险隐患，导致 2.7.x 中很多版本或多或少存在不同的问题，用户无法选择一个最稳定的版本进行使用。

因此，我们希望在 3.x 版本中将这种不稳定的情况通过发版机制给收敛掉，提高 Dubbo 版本的稳定性。

未来总体规划

在接下来，Dubbo 将以每 6 个月为一个周期，对每个版本包括了新功能合入、稳定性维护以及安全漏洞修复三个大方向的内容。

新功能合入是指将 Dubbo 开发过程中所有新的特性、性能优化、破坏性修改都会被合入的行为。由于新功能是需要一段时间迭代稳定的，所以新功能的合入会给对应版本带来不稳定因素，因此只能在每个版本最开始的时候进行。

Dubbo Java 3.0.2 发版公告

Sun, 18 Jul 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 的稳定性的贡献。

Dubbo Java 3.1.3 正式发布

Mon, 18 Jul 2022 00:00:00 +0000

Dubbo 3.1.3

修改内容

修复本地调用的过程中 Filter 顺序异常的问题
支持导入协议配置项到 MetadataService
支持在发布 MetadataService 时自动选择可用端口
完善错误码内容
泛化调用下支持一致性哈希负载均衡
修复泛化调用时反序列化异常的问题
修复由于 JVM Methods 顺序不一致导致的应用级元数据无法复用的问题
默认关闭端口复用能力，修复 remoting 组建找不到 SPI 的问题
修复由于引用计数异常导致的 safe gard 问题
删除 Nacos 注册中心组建中使用的 guava 依赖
修复接口级使用 Nacos 注册中心时由于地址聚合导致的无法下线的问题
多个代码质量优化提交

新贡献者

@zhangzq7 在 #10847 中提交了第一个贡献
@akaakking 在 #10799 中提交了第一个贡献
@wxbty 在 #10921 中提交了第一个贡献
@haoxz11 在 #10937 中提交了第一个贡献

新贡献者

@weixsun 在 #10941 中提交了第一个贡献

未来的版本规划

3.0、3.1、3.2 有什么区别？未来会怎么发展？发版周期是怎么样的？更多的版本迭代规划也将在近期推出，欢迎关注 Apache Dubbo 官方公众号获取最新的信息。

Dubbo Java 3.2.0-beta.3 正式发布

Sun, 18 Dec 2022 00:00:00 +0000

Dubbo 3.2.0-beta.3 版本是目前 Dubbo 3 的最新特性版本，包括了如 Spring Boot 3、JDK 17、服务粒度的线程池隔离等新特性的支持，欢迎大家尝鲜使用。

Dubbo 3.2.0-beta.3

注：Dubbo 3.2.0-beta.3 的代码基础和 Dubbo 3.1.4 完全一致，因此在 Dubbo 3.1.4 中包括的所有修改内容，在 Dubbo 3.2.0-beta.3 中也同样存在，后续说明中对于重复的内容讲不再赘述。

新特性

支持使用 jackson 作为Dubbo 内部的 JSON 序列化方式
优化 Dubbo Logger 的选择逻辑，在存在多种日志框架的情况下会尝试读取其配置，选择一个有效的日志框架，解决在 SpringBoot 等场景下 Dubbo 日志不输出的问题。
Triple 协议支持客户端流控
支持发布 Dubbo Metrics 数据到 Spring Boot 的 Endpoints 上
支持可选关闭线程池满时的线程 Dump 以及支持配置 Dump 的结果输出路径
xDS 实现支持路由规则的解析
支持 Dubbo QoS 命令安全性分级，默认对外暴露存活检测的端口，支持 Kubernetes 的原生接入
支持基于 P2C 的自适应负载均衡

Bugfix

修复默认 Metadata 缓存未开启的问题
修复 Metrics 指标资源路径错误的问题
完善线程池隔离的配置，默认采用共享线程池，避免创建过多的线程
完善 prefer-serialization 的选择逻辑，提供向前兼容的能力
修复 Triple 协议传输时未携带版本号导致版本调用错误的问题
完善 GraalVM Native Image 的支持

性能优化

优化在连接数高时由于获取 channels 数量导致的资源占用问题

代码优化

本次发布中有 5 个提交涉及代码质量的优化。

Dubbo 3.2.0-beta.2 正式发布

Fri, 18 Nov 2022 00:00:00 +0000

Dubbo 3.2.0-beta.2

修改内容

切换到在用户线程序列化，提升协议性能
支持 Netty3 的端口复用
修复存在多个用户配置的 providedBy 时不生效的问题
支持 istio 的 first-party-jwt 能力
删除 fastjson 和 gson 的传递依赖
支持可选 appResponse 不透传的能力
切换到 Fastjson2 为默认序列化依赖
完善注册中心推送的日志
修复路由刷新时机早于服务目录刷新时机的问题
关闭地址推空保护
更新支持 GraalVM Native 的 SPI 生成代码
支持使用 plain text 模式传输 xds 通道
支持 Nacos 批量注册，修复多注册覆盖的问题
支持 Spring Framework 6 and Spring Boot 3
多个代码质量优化提交
前述 Dubbo 3.1.3 的所有修改内容

新贡献者

@weixsun 在 #10941 中提交了第一个贡献

未来的版本规划

Dubbo Java 2.7.14 发版公告

Mon, 18 May 2020 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

Apache Dubbo 3.3 全新发布：Triple X 领衔，开启微服务通信新时代

Wed, 11 Sep 2024 00:00:00 +0000

在 Apache Dubbo 突破 4w Star 之际，Apache Dubbo 团队正式宣布，Dubbo 3.3 正式发布！作为全球领先的开源微服务框架，Dubbo 一直致力于为开发者提供高性能、可扩展且灵活的分布式服务解决方案。此次发布的 Dubbo 3.3，通过 Triple X 的全新升级，突破了以往局限，实现了对南北向与东西向流量的全面支持，并提升了对云原生架构的友好性。

Dubbo 的基础介绍

Apache Dubbo 是一个高性能、轻量级的微服务框架，最初由 Java 开发，但现在已扩展支持 Go、Rust、Python 等多种语言，为全球企业构建跨语言、跨平台的分布式系统提供了强有力的支持。Dubbo 提供了丰富的服务治理能力，包括服务注册与发现、负载均衡、容错机制和调用链追踪，帮助开发者构建高效、灵活的微服务架构。

随着 Dubbo 逐渐演进，其通信性能、服务治理能力和跨语言兼容性得到了大幅提升，成为支持现代微服务架构的理想工具。

Triple X 全新升级背景

在 Dubbo 的早期应用中，虽然其在数据中心内部的服务互通中展现了卓越的性能，但随着技术演进和应用场景的扩展，原有架构逐渐暴露出了一些瓶颈。这些瓶颈在跨区域、跨云的环境中尤为明显，尤其是在 Web 框架与 RPC 框架之间的频繁切换中，开发复杂性和系统性能都受到了影响。

传统架构的痛点主要体现在：

局限于数据中心内的应用场景：在跨地域或跨云应用中，Dubbo 的传统架构缺乏对广域环境的原生支持，导致开发者需要在多种协议和框架中切换，增加了复杂性。
南北向与东西向流量的双重挑战：在现代微服务架构下，传统的 RPC 框架往往更侧重服务间（东西向）流量优化，而南北向通信的性能要求日益增加，对传统 Dubbo 架构提出了新的挑战。
云原生与跨语言互操作性要求：随着云原生技术的普及，系统需要对 HTTP 协议有更深层次的支持，并具备跨语言的通信能力，然而传统 Dubbo 在这一点上并未原生优化。

Triple X 的变革和突破： Triple X 的诞生，直接回应了这些痛点，它不仅延续了 Dubbo 一贯的高性能通信能力，还实现了与 gRPC 协议的全面兼容，通过支持 HTTP/1、HTTP/2、HTTP/3 等协议，为跨云、跨区域的广泛应用场景提供了更具灵活性和高效性的解决方案。

Triple X 核心能力概述

全面支持南北向与东西向流量：Triple X 无缝支持从客户端到服务器的南北向流量及服务间通信的东西向流量，并确保灵活转换，提升通信链路的整体效率。

Apache Dubbo 下一代云原生微服务挑战赛启动报名！五大赛题50万奖金池等你来战

Thu, 18 Jan 2024 00:00:00 +0000

本文带来本赛题详细解读，开放原子开源基金会官方报名渠道及更多详情请查看文章最后链接与二维码。

赛题解读

我们期待参赛团队在高性能 Triple(HTTP/3) 协议设计、完善的 Benchmark 验收体系、零信任解决方案、Service Mesh架构等方向持续探索，共同定义下一代云原生微服务体系，为开源社区和企业用户在性能、安全等方面带来收益。

本赛事一共包含五道赛题：

基于 HTTP/3 的高性能传输协议(Java)
自动化的 Dubbo 框架与协议性能基准 Benchmark 机制与平台(语言不限)
设计并实现一套零信任安全机制（含 Java/Golang SDK 适配与证书管理）
面向云原生的下一代微服务集群监测机制，涵盖Kubernetes、Nacos 等(Golang)
一种跨集群Kubernetes、传统VM微服务集群的互通方案与实现(Golang)

1 基于HTTP/3 的高性能传输协议(Java)

1.1 赛题背景与目标

本赛题的主要目标是将 Dubbo 中的 triple 协议适配到 HTTP/3 之上，兑现 triple 协议规范中的所有核心能力。

关于 Dubbo3 triple 协议使用的相关示例请参考（请注意阅读 README 中链接指向的其他相关示例）：https://github.com/apache/dubbo-samples/tree/master/1-basic，通过运行示例，可以了解当前 triple 协议的功能。

以下是 Triple 协议规范：https://cn.dubbo.apache.org/zh-cn/overview/reference/protocols/triple-spec/

1.2 赛题说明

请基于 Apache Dubbo Java 实现的 3.3 分支进行开发，代码仓库链接如下： https://github.com/apache/dubbo/tree/3.3

triple 协议相关实现源码：

开发者可根据自己的理解修改 Dubbo源码实现，比如在 remoting 层做 http3 适配，赛题实现不受限制，可以依赖如 Netty 等任意网络库或框架。

通过模板生成项目脚手架

Sun, 31 Dec 2023 00:00:00 +0000

Dubbo Initializer 可用来快速生成 Java 项目脚手架，帮助简化微服务项目搭建、基本配置、组件依赖管理等。

Initializer 仍在持续更新中，更多 Dubbo Feature 的支持将会陆续发布。

选择 Dubbo 版本

Initializer 将使用 dubbo-spring-boot-starter 创建 Spring Boot 项目，因此我们首先需要选择 Dubbo 与 Spring Boot 的版本。

录入项目基本信息

接下来，填入项目基本信息，包括项目坐标、项目名称、包名、JDK 版本等。

选择项目结构

有两种项目结构可共选择，分别是 单模块 和 多模块，在这个示例中我们选择 单模块。

单模块，所有组件代码存放在一个 module 中，特点是结构简单。
多模块，生成的项目有 API、Service 两个模块，其中 API 用于存放 Dubbo 服务定义，Service 用于存放服务实现或调用逻辑。通常多模块更有利于服务定义的单独管理与发布。

选择依赖组件

我们为模板默认选择如下几个依赖组件：

Dubbo 组件
- Java Interface
- 注册中心，zookeeper
- 协议 TCP
常用微服务组件
- Web
- Mybatis
- 模版引擎

基于以上选项，生成的项目将以 Zookeeper 为注册中心，以高性能 Dubbo2 TCP 协议为 RPC 通信协议，并且增加了 Web、Mybatis 等组件依赖和示例。

IntelliJ IDEA❤️Apache Dubbo，IDEA官方插件正式发布！

Mon, 23 Oct 2023 00:00:00 +0000

最受欢迎的 Java 集成开发环境 IntelliJ IDEA 与开源微服务框架 Apache Dubbo 社区强强合作，给广大微服务开发者带来了福音。与 IntelliJ IDEA 2023.2 版本一起，Jetbrains 官方发布了一款全新插件 - Apache Dubbo in Spring Framework。

这款插件可以帮助开发者解决 Dubbo 项目初始化问题，同时方便识别项目开发过程中的 Dubbo 服务及其依赖关系，基于 Apache Dubbo 的微服务开发将变得非常简单。

安装插件

在安装 Apache Dubbo 插件之前，请确保您使用的 IntelliJ IDEA 为 2023.2 及以上版本。

有两种方式可以完成 Apache Dubbo 插件的安装

方式一

使用浏览器打开插件 Apache Dubbo in Spring Framework 官方地址，在页面右上角，点击 “Install to IntelliJ IDEA 2023.2” 按钮即可完成插件安装。

方式二

打开 Preferences -> Plugins，输入 ‘Apache Dubbo’ 搜索插件，安装即可。

使用插件新建应用

插件安装完成，接下来，我们看一下如何使用插件创建和开发 Apache Dubbo 微服务应用。

Apache Dubbo 云原生可观测性的探索与实践

Sat, 07 Oct 2023 00:00:00 +0000

摘要：本文整理自平安壹钱包中间件资深工程师、Apache Dubbo committer宋小生在 Community Over Code 2023 大会上的分享。本篇内容主要分为五个部分：

一、可观测性建设
二、多维指标体系
三、链路追踪门面
四、日志管理分析
五、稳定性的实践

一、可观测性建设

首先介绍一下云原生升级的挑战。目前大部分公司里基本上都有CICD、OPS来帮助开发、测试、运维提升开发的效率与质量，也会有容器化来帮助提升产线运维的效率与质量。但在云原生时代，大规模容器的频繁变更会带来很多稳定性的问题。这些稳定性问题，包含了很多我们可以提前规避掉的已知的异常，也包含了很多我们无法避免的异常，比如网络故障、机器宕机等系统无法提前测出来的问题。

如果我们能提前发现这些问题，其实是可以规避掉很多风险的。所以我们通过可观测系统及时的感知到了这些问题，高效的分析异常，快速的恢复系统。因此可以判定，在云原生时代，可观测系统的建设是非常重要的。

Dubbo作为微服务RPG的框架，直接建设一个大而全的可观测性系统或者平台是不现实的，而且它的定位也不是很符合。可观测性系统更强调关联性，通过单维度或者多维度进行系统的观测与问题的诊断。

首先看一下可度量系统的健康状态的指标。Dubbo通过采集系统内部的Dubbo指标的同时，把指标内部的数据暴露给外部的监控系统。这些监控指标中间包含了很多的应用信息、主机信息、Dubbo服务标签信息等等。当我们发现问题的时候，可以通过这些标签信息关联到全链路系统。之后全链路系统可以做到请求级或者应用级的系统性能分析或者系统异常诊断。

Dubbo侧通过适配各大厂商门面的形式，只需进行非常简易的依赖就引入或者配置就可以直接把数据导出到各大全链路平台。无论企业使用哪个流行平台，在后期升级Dubbo后都可以直接把链路导出去。

另外，链路系统还包含全链路的Traceid或者局部的磁盘ID。通过全链路的ID，我们可以在链路系统直接跳转到日志平台。在日志平台里包含非常详细的日志上下文，这些日志上下文可以提供非常精确的异常问题诊断。

Dubbo也提供了非常详细的错误码机制和专家建议的形式，在官网上通过日志的形式可以直接通过错误码的形式直接导航到官网上的帮助文档。

二、多维指标体系

Dubbo在多维度指标体系实践的时候，我们主要从两个维度来看它。

第一个是纵向的维度。Dubbo指标在采集的时候有一个接入导出的流程。Dubbo为用户和开发者提供了简单易用的接入门面。接入后服务在运行过程中通过指标器进行指标的采集。Dubbo中提供了非常多的指标采集器，包括聚合和非聚合的指标采集等等。

然后采集的指标会通过变量值临时存储在内存里，之后会有部分指标（QPS等带有滑动窗口的最小值、最大值的聚合指标）进行聚合计算，最后这些指标会导出到外部系统。我们支持在Dubbo QPS服务质量中进行指标导出，或者把指标导出到Prometheus，或者http直接访问也可以进行指标的查询。

第二个是横向的维度。Dubbo指标采集覆盖了非常容易出现异常的地方。比如Dubbo 3提供了三大中心，包括注册中心、元数据中心、配置中心，存在外部网络交互的地方是非常容易出现问题的。

另外一个比较关键的是RPC电路上的采集，比如请求相应的时间、异常、nity网络、IO的指标等等。此外还有一些关于Dubbo线程池的指标采集。

前面说的是比较大面上的指标采集，具体Dubbo的采集需要哪些指标我们也调研了很多比较流行的方法论。

图中第一张图是谷歌SRE书的四大黄金指标。它是谷歌总结大规模的分布式服务监控总结出来的，它可以进行请求级别的服务质量的衡量，主要包含延迟、流量、错误以及饱和度。
图中第二张图是RED 方法。它更侧重于请求，从外部视角来查看服务的健康状态，主要包含速率、错误与持续时间。
图中第三张图是USE 方法。它更侧重于系统内部的资源使用情况，包含利用率、饱和度与错误。

可以看到，以上三个指标的方法论中都包含的指标是错误，错误也是每个开发者比较关注的。

然后我们进行了指标的系统完善。在Dubbo 3.2版本中，多维度指标体系已经完成，而且也在快速持续的版本迭代中。在这个版本中我们只需要引入一个快速集成的Spring Boot中的Starter包就可以实现指标的自动采集。之后我们通过Dubbo的QPS服务质量端口可以直接访问到。如果是本机可以通过浏览器，如果是服务器可以通过科尔命令访问52端口，后面加一个Metric路径，这样就可以看到非常详细的默认指标的导出。

可以看到这些指标有Dubbo前缀，类型是Dubbo的不同模块，比如消费者提供的请求级别，三大注册中心一起线程。

下面是Dubbo当前指标的行为，比如响应时间最后会加一些单位，这个格式参考的是Prometheus的官方格式。

多维度指标体系有些人可能会直接复用Spring Boot默认的manager管理端口，Dubbo也适配了一下Spring Boot Actuator的扩展。

操作和刚刚一样，只是引入Spring Boot Starter包。后面也无需做任何其他的配置，就可以在Spring端口里看到详细的指标了。包括Spring Boot内置的jvm指标、Dubbo指标等等。

指标体系接入之后，我们如果直接通过命令行访问只能看到一些瞬时的数据，但在监控指标体系我们其实更关注的是多维度的向量数据。如果我们把这些数据看作是一个点其实是比较难看出问题的，所以我们需要把这些数据存储起来，看作是一个实际化的向量数据。

Dubbo默认提供对Prometheus采集的介入。Prometheus作为指标存储与监控一体的监控系统，提供了很多的服务发现模型。比如我们直接把服务部署在K8s上，可以直接基于K8s标签的服务发现机制进行指标采集。如果公司有自建的cmdb系统，可以自己扩展http接口进行指标采集。此外,文件或者静态的服务发现机制只要能发现Dubbo服务的IP和服务接口，也可以进行指标采集。采集到的指标会自动存储在Prometheus的实际数据库里。

上图是我们通过Prometheus的查询框查询出来的响应时间的最新指标。

Prometheus的指标更侧重于存储与报警，如果我们想更直观的体现还需要接入Grafana。Grafana的目标是为企业提供简易接入的监控面板，上图是一个简易的全局大盘。

我们通过应用级别的筛选/机器IP维度的查询/服务接口的维度，查询服务的健康状态。可以看到，这些指标基本上都是基于前面总结的方法论实现的。比如QPS、请求数量、成功率、失败率、请求的时延等等。

此外，还有一些应用信息的指标，比如升级Dubbo 3时，想看到哪些应用已经升级到新的版本，就可以看到新的应用的版本号，也会有应用信息的实例IP分布，还有一些现成资源。

三、链路追踪门面

刚才说的指标比较抽象，它更利于帮助我们发现问题，接下来进行一些简单问题的诊断。微服务系统往往是多个系统之间有关联关系，所以服务之间的诊断更依赖于全链路系统。

全链路系统Dubbo，当时考虑使用Agent的方式，这种方式对于用户接入是非常方便的，在代理层直接注入一些指标采集的方式即可。如果用这种方式在企业里做全链路的覆盖是非常方便的，但如果Dubbo只做Dubbo的指标采集，风险会比较大。因为Agent接入后会进行字节码修改等不兼容的问题，有些时候很难在前期发现。

另外，Dubbo也调研了一些开源的链路追踪门面。Dubbo选择通过原生内置门面的形式，让专业的事情交给专业人做。Dubbo通过适配各大厂商的全链路追踪系统，快速适配接入的用户，只需增加少量的配置就可以实现链路数据的导出。

OpenSergo & Dubbo 微服务治理最佳实践

Sat, 07 Oct 2023 00:00:00 +0000

摘要：本文整理自阿里云 MSE 研发工程师何家欢的分享。本篇内容主要分为四个部分：

一、Why 微服务治理？
二、OpenSergo：服务治理控制面与标准规范
三、OpenSergo & Dubbo 最佳实践
四、OpenSergo 的未来之路

一、Why 微服务治理？

现代的微服务架构里，我们通过将系统分解成一系列的服务并通过远程过程调用联接在一起，在带来一些优势的同时也为我们带来了一些挑战。

如上图所示，可以看到一个词云，这些都是目前微服务架构在生产上所遇到的挑战。比如，最常见的流量激增的场景，近一年内AIGC突然爆火，相关网站/服务都存在过因为激增流量导致服务不可用的情况，可能会让我们错过一个最佳的增长窗口。

再比如缺乏容错机制，某视频网站的某个服务异常，随调用链扩散，导致全站入口不可用，影响千万用户，产生实质性的经济损失。这些生产故障频频发生，也是在提醒我们稳定性是用好微服务的重大挑战之一。

为了保障微服务的稳定性，我们就需要做一些架构的演进。

我们先看一下左侧的微服务3大件，这个大家已经很熟悉了，通过这三者的配合，我们的应用就能够正常使用了，但是距离生产可用其实还有很大一段距离，各个企业和社区为了消除这其中的gap都有一些探索和实践，比如Dubbo社区在Dubbo3中引入一系列诸如流量管理、高可用性的能力来保障微服务的稳定性，这些措施可以统称为微服务治理。

所以其实大家已经意识到，从把微服务跑起来到真的生产可用，微服务治理是必不可少的一环。但微服务治理要做些什么，如何去做其实都还比较模糊。

从软件生命周期的角度，我们可以把微服务治理分成三个域，开发态与测试态、变更态、运行态。

在这三个域中都面临着很多挑战，对于这些挑战大家也有着一些探索和实践，比如对于发布有损的问题，我们可以通过无损上下线来解决，变更的影响面通过灰度来控制，对于不确定流量使用流控、热点防护，不稳定调用使用熔断与隔离。

可以看到在各个域中都有一些成熟的方案和效果很好的实践。但是不管是阿里还是其他公司，在体系化落地微服务治理时都会遇到很多问题。

二、OpenSergo：服务治理控制面与标准规范

首先我们涉及的组件有很多，在微服务架构中，往往会涉及很多组件，它们需要有Dubbo这样的调用框架，nacos这样注册中心，snetinel、hystrix这样的稳定性中间件等等，因此也没办法进行统一治理，管控成本就非常高。

其次时概念不统一，比如在envoy中的隔离与 sentinel中的隔离完全不是一个意思，envoy的隔离是摘除不健康实例，sentinel的隔离是并发控制，这就会使开发者理解成本很高。

同时各个企业社区都有自己的最佳实践，这也就导致大家能力上是不对齐的，没有统一的标准。

还有配置不统一的问题相信大家都很有体感，比如sentinel、hystrix、istio都有熔断的能力，但是配置却各有差别，需要开发者分别学习，还要注意不混淆，不利于理解，也不利于统一管控。

可以发现由于这些问题，我们在落地体系化微服务治理时会有很大的阻力，我们需要的是一个统一的治理界面来让我们更好地做微服务治理，因此我们提出了OpenSergo这个项目。

而OpenSergo期望提出一套开放通用的、面向云原生架构的微服务治理解决方案及标准规范，来助力保障微服务高可用，上图的四个部分就是OpenSergo社区的愿景。

OpenSergo社区会基于业界微服务治理场景与实践抽象成规范，通过这种方式去解决前面提到的概念、配置、能力不统一的问题，并用统一的管控面去承载，降低使用和维护成本。

同时在纵向上，我们针对链路上的每一环进行抽象，覆盖完整的场景，在横向上，无论是Java生态，Go生态或是其他语言，无论是传统微服务还是Mesh架构，都会纳入到这套统一的体系中。

但是OpenSergo作为一个开放标准，仅凭借阿里是不够的，所以我们联合了多家公司以及社区比如bilibili、中国移动、字节跳动的cloudwego社区等，共同建设这套开放标准，希望能够真正解决微服务稳定性的风险。

接下来简单介绍一下OpenSergo的架构体系，前面也介绍了OpenSergo社区会基于场景抽象出OpenSergo的Spec，但这只是第一步，为了承载这些标准规范我们就需要一个控制面，社区在一开始的演进中选择从0开始开发一个控制面来做治理规则的管控、监听与下发。

但是随着社区的演进，我们发现基于Istion去扩展，成本更低，也能够复用更多的能力，因此在后续的演进中我们会选择结合Istio扩展控制面与决策中心实现治理规则统一管控、治理策略预计算。

在有了控制面后我们还需要数据面来进行具体治理能力的实现，它可以是像sentinel这样的中间件，也可以是框架本身。控制面与数据面之间的通讯在初始的架构中是基于grpc构建的链路，但在确定了后续演进方向会基于istio扩展后，社区选择拥抱xds，尽可能服用它的链路，对于一些无法承载的我们再使用自身的grpc链路。

前面也提到社区控制面的后续演进是基于Istio扩展的，Istio本身也有一些流量治能力，并有着一定的普及度。但是Istio主要关注流量管理，让流量到达该去的地方而不是微服务治理治理，所以在微服务稳定性的场景下，Istio所提供的这些能力是不足以满足我们的需求的。

因此我们在Istio的基础上，基于微服务稳定性的一些场景，比如前面提到的变更态稳定性、运行时稳定性去抽象、制定了满足需求的规范标准，希望能够更加贴合微服务场景。所以整体上我们在微服务治理领域会是Istio的超集，而不是互斥关系。

接下来我们一起看一下OpenSergo的标准规范是如何解决前面所提到的这些场景。

首先我们聊一下流量路由，它的主要作用是将符合一定特征的流量路由到指定的workload上，一般大家会用这种能力来实现灰度、同AZ路由等方案。

基于 Istio VirtualService/DestinationRule 的格式社区定义了流量路由spec，但我们在调研以及实践的过程中发现，它并不能很好的满足微服务场景下的需求。所以为了更贴近微服务的场景去扩展去做了扩展。比如我们增加了路由失败后的处理逻辑，这在微服务架构中是很常见的需求。

又由于Istio主要关注的是HTTP请求，它的CRD不能够很好地承载像Dubbo这样的RPC调用，所以我们为此增加了更多RPC模型的支持。后续我们也会探索与社区标准结合的方案，使我们的Spec更加通用与标准。

前面所提到的灰度，在阿里集团内部数年的安全生产实践中，与可监控、可回滚一起被定义为安全变更的三板斧，其中灰度是控制变更影响面，保障变更稳定性的必不可少的能力。

为了实现灰度，我们通常有几种方案，第一种是物理隔离，我们通过部署两套一样的环境来实现灰度，但是这种方案的部署和维护成本都很高。

为了提高资源利用率，便产生了第二种方案，流量灰度。我们不部署独立的环境，而是在流量的每一跳进行流量的特征匹配，并且由此决定去往灰度实例还是base实例，这种方案相较与前者更加灵活高效，可以通过前面提到的流量路由能力来实现。但是需要我们在每一跳都配置路由规则，相对比较繁琐。

并且由于有些信息在后续链路是获取不到的，比如uid，导致这个方案的实施有一定的困难。于是便产生了第三种方案，全链路灰度，我们通过在流量入口处进行流量匹配并打上标签，标签会自动沿着调用链路透传，后续链路根据标签来进行路由。通过这种方式，我们就能够更简洁地去定义灰度。Opensergo针对这种场景抽象了对应的CRD。

我们将这个CRD称之为TrafficLane也就是泳道，我觉得还是比较形象的，大家看一下上边的图片，橙色的是正常的流量走向，灰色的是灰度流量的走向，就像是将一个池子分成了多个泳道。

泳道的CRD有三个部分组成，也比较好理解，首先我们需要去匹配灰度流量，所以就要去定义匹配的条件，然后定义为这些流量打上什么标签，最后再定义这个标签以什么方式去透传。

通过这样的CRD我们就定义了一条灰度泳道。但是如果只是定义是不足以实现全路灰度的，我们还需要借助OpenSergo体系全链路全方位框架的一个支持，才能让标签在这些框架中自动的透传，这些框架也能通过标签进行路由。其中流量染色和标签透传会借助标准的trcae体系去实现，比如OT。

上图右侧是一个CRD的例子，大家可以简单看一下。

接下来我们一起看一下运行态稳定性的场景。

我们主要提两个场景，第一个是流量激增的场景，比如双十一的秒杀活动，一开始流量是稳定的情况下，系统也处于稳态。但是当流量激增的时候，系统就会开始往不稳定的方向发展，异常调用也会激增，最后就会变成不可用的状态。对于这类场景，我们可以用流量控制的能力拒绝超出容量的请求，或是通过流量平滑的能力削峰填谷，让流量处于比较平稳的状态，避免服务的不可用。

第二个是不稳定调用导致服务不可用的场景，比如我们调用一些第三方服务经常会出现不稳定的情况，这里的不稳定主要指异常或是慢调用。以dubbo为例，当服务提供方出现慢调用的时候，会导致服务消费方的线程堆积，影响到其他的正常调用甚至是整个服务的稳定性，并且这种风险会沿着调用链反向传递、扩散最终影响整个系统的稳定性。这时我们可以通过并发控制或是熔断保护来限制慢调用对资源的占用，保障系统的整体稳定性。

针对前面提到的这些场景，OpenSergo也制定了相关的CRD。在业界的实践中sentinel是一个成熟的流量防护方案，在阿里内部积累了大量的流量防护相关的场景和实践，2018年开源依赖在业界进一步丰富了这些积累，我们从这些积累中抽象出了一套流量防护的规范标准。

Seata 微服务架构下的一站式分布式事务解决方案

Sat, 07 Oct 2023 00:00:00 +0000

摘要：本文整理自阿里云分布式事务产品负责人、Seata 开源项目创始人、微服务开源治理负责人季敏的分享。本篇内容主要分为三个部分：

一、微服务架构下数据一致性的挑战
二、分布式事务Seata的架构演进
三、如何基于Seata扩展RPC和数据库

一、微服务架构下数据一致性的挑战

在2019年，我们基于Dubbo Ecosystem Meetup，收集了2000多份关于"在微服务架构，哪些核心问题是开发者最关注的？“的调研问卷。最终分布式事务占比最大，有54%。

但在Seata出现之前，大家都说分布式事务能避就避，因为消息最终一致性去解释了问题。但Seata开源之后，这些问题都迎刃而解。比如无损上下限，到底是说服务的可用性还是其他的。对于我来说，我觉得它最终关注的是数据的问题。因为无论前端的业务怎么去交互，最终都会沉淀到数据。如果业务的数据不一致，前面是什么架构，都意义不太大，所以我认为数据是企业的核心资产。

那么到底哪些场景会遇到分布式事务的问题呢？

第一个场景，在拆分成微服务架构之后，不同的服务可能由不同的团队负责上下游的协调联动。比如C服务发布的时候，并不会通知A服务和B服务，这个时候就会遇到上下线带来的数据一致性的问题。

第二个场景，不可靠、不稳定的基础设施，会导致网络或者个别主机的宕机。

第三个场景，timeup是分布式架构里比较难解的状态，因为一旦出现服务调用的timeup，这个服务的业务逻辑到底是执行了，还是没有执行timeup的服务怎么实现数据的密度，都是比较尖锐的问题。

第四个场景，业务里除了会涉及到数据库，还会涉及第三方的组件。比如缓存、Redis，我们的库存会先经过Redis这样的组件，那么如何实现它的一致性也是个问题。

第五个场景，我们在上下游做业务的时候，你传给我一些参数，但这些参数本身可能是非法的。那么我就需要把你的下服务也回关掉，而不是只有我这一个服务去做拒绝。

所以分布式事务的场景主要包括了跨库、跨服务、资源的多样性。异常上主要包括业务异常、系统异常。

那么分布式事务是不是微服务架构独有的问题呢？其实不是，它在单体应用里也有类似的问题，只不过在微服务架构里它的问题更凸显。

在单体架构下存在哪些分布事务的场景呢？比如一个单体应用要去修改多个数据库或者多模块的，整体而言，单体数据库它完成的是ServerSission下边的一个本地事务。只要跨了这个本地事务，其他的都是分布式事务，即使微服务都去修改同一个数据库。这样其实你的数据库的本身也不是能反序列化传递到另外一个服务的，这些问题都会涉及到分布式事物的问题。

整体看起来，分布式事物涉及到了分布式架构和单体架构中非常广泛的应用。

市面上的分布式事务方案有以下六类：

XA模式，它的问题是吞吐量和性能要差一点，在一致性上是最高水准。
TCC模式和SAGA模式，可以归结为是一个业务层面的分布式事务，因为他不会拦截数据。比如TCC模式可能有cc接口，至于这个接口怎么回滚，怎么正向的，在框架层面完全不用管。这可能是你里边逻辑本身不是对等的，也不是框架已经参与的，所以更多的是把接口暴露给了业务实现。
消息最终一致性，它最大的优点是实现异步化的解耦，结合消息的削峰填补的特点。但它本身存在着一些问题，对消息来说，他更多的是做一个单项的通知。这个通知可能对于一些消息消费来说，即使业务失败了，它也没法去回滚。

比如现金红包的业务，我首先要将红包转到我的账户，然后再从我的账户转到我的银行卡。可能消息消费的时候我这个账户已经注销掉了，那么你的消息消费就会一直处在失败的状态。对于这类问题，不可能再把上游消息的发送给关掉，所以它更多的是单项通知的场景。

定时任务补偿，它的学习成本低，但实践成本高。尤其是微服务的链路有多翘的节点，需要业务逻辑写的非常周全。
AT模式，它综合了一致性性能，主要的特点是简单无侵入，强一致，学习成本低。缺点是需要遵守一定的开发规约，并且它不是对所有的SQL类型都支持，它有一定限制。从业务场景上来说适应的是一个通用的场景，但它并不适应于热点数据类型的高并发场景，比如SKU的库存的部件。因为在这个模式它有一个应用层的分支锁，需要对相同的数据做一个排队的等待。

二、分布式事务Seata的架构演进

Seata在阿里内部的代号叫TXC，在蚂蚁叫DTX。它起源于集团的五彩石项目，五彩石的项目是当初集团内在做去IOE，从单体架构引进到分布式架构。在分布式架构必然会涉及到很多的中间价，TXC承担的主要的角色做服务一致性的保证。

我们和集团内的三大件都做了深度的集成，包括服务调用框架HSF，也就是对外开源的Dubbo；数据库有分库分表的TDDL组件；异步消息的MetaQ组件。在集团内也有广泛的使用，日均百亿级别调用，标准3节点集群吞吐达近10w TPS。

我们的SLA会分为几个SLA，一个是可用性的SLA服务，另外一个是性能的SLA服务。因为对于分配事物来说，除了要保证一致性，也要保证性能的吞吐量。所以我们规定比如每一次的RT额外的开销不能超过XX。目前能达到毫秒级的事务处理，能保证在稳定性上全年无故障。

最开始我们在做分布式事务实现的时候，我们也去考虑我们的分布式事务应该是在哪层面去实现？

从应用架构的视角，分为这么几层，一个是最上层的应用开发框架，可能每一套公司都有自己的开发框架，比如像ddt的开发框架或者club的体系等等。再下一层是服务调用框架，类似于Apache Dubbo主要承担，也在国内使用的非常广泛。再下一层是数据中间件，这层主要包括ORM框架、事务、同步、对账。再下一层是跟数据库连接，这一层类似于JDBC、Java去连数据库。

我们去做了一个简单的对比，到底是在哪层实现分布式事务，是在DB层、数据中间件层还是应用框架层？

在应用框架层，它去实现一致性相对来说比较弱，因为你会掺杂很多复杂的、不可控的因素，会把服务调用的因素给牵扯进去。比如服务调用的超时，这就是为什么我们现在有的像TCC模式它会有一些密等、放悬挂那些问题。都是因为融入了RPC的因素，持续的不确性导致的一些问题。

在数据中间件层，它的一致性比应用框架要好一些，它主要的问题是他不是在DB层实现的，所以我是有办法绕过中间件直接去修改DB的，这时候就会存在事物并发时序的问题。最好的一致性是在DB层去实现数据一致性，但这一层数据一致性主要是数据库的厂商，但是也是参差不齐。比如Msever，他在5.7.7版本才把差异完善起来，在之前的版本它对差异回滚一直是有问题的。

但它只能局限在数据库的scope，如果我要去更大的scope，从应用架构层可能要跨服务，跨服务这一层它就管不了，只能管我自己数据库。所以他最终还是需要有一个第三方的去协调跨服务的数据一致性。最终我们把这一层AT差异模式是把它做到了数据库中间件这层，JDBC server这层我们做到了应用开发框架这层。

所以它不仅实现了一整套的集团生产体系，还包括了我们对分布式事务编程模型的定义，运维安全。因为要涉及到数据，会有数据的敏感以及性能和观测高可用等等。

在理论模型上我们当时还是比较匮乏的，我们做了一些对差异以及Spring事物模型的延展。我们延展了已有的模型，而不是新造一条。这于开发者来说，学习成本会更低。

此外，我们还做了一些定义，包括怎么定义一致性，是定义多节点的一致性，还是业务应用架构数据的一致性，以及这套架构里的角色模型设计的事物动作和隔离。

什么是分布式事务的模型定义？举个例子，我去做银行转账的时候，我给你转100块钱，恰好这个时候出现了网络超时，那么这100块钱到底有没有扣。如果不确定就可能出现资损的问题，甚至可能影响企业的商誉。

我们都在谈分布式架构，但从整个应用的视角，并不是所有东西都是分布式的。比如我们从一个应用的架构的层面去看数据库，包括今天称之为分布数据库。从整个应用层面，它我们看它是一个集成式的数据的存储。它的内部实现可能是分布式的，包括分布式的链路数据。

因为在分布式的应用架构里，每个业务的节点都只掌握了部分的信息。如果做一些问题的排查，必然需要一个集成式的东西。对于分布式事务它的核心工作是做分布式协调，所以他要掌握全局的信息。

这就是为什么我们有了Transaction Coordinator。对他来说，他要有一个上帝视角，充当第三方的协调器。而真正做事的是Resource Manager，你可以认为它是数据库的灵魂，我们需要把它作为Pro。

真正随着业务应用去做事务的动作是Transaction Manager，它会随着业务的执行链路进行，到底直接事务的边界是怎么样的，以及分布式事务的动作是怎么样的。

2019年1月Seata开始开源了，我们主打的特点特色是AT 模式，因为是组装，我们从0.1版本就把AT模式给开源出去了。0.4版本我们纳入了TCC的模式，因为AT模式它需要适配不同的数据库。而在现有阶段我们不能满足对所有数据库的支持以及缓存资源，这就需要应用TCC模式去做补充。你可以用TCC模式做一些我们没实现的数据库以及缓存的结构。

在0.9版本，我们纳入Saga的事务模式，它主要解决长事务方解决方案。比如一个事务非常长，且还有微服务的编排工作。在1.1版本，我们纳入了XA的事务模式，因为有的客户已经应用了Seata的AT模式，但他还有一些老的特别事务。他希望应用Seata统一的一套解决方案，解决不同业务常用的分支事务，所以我们把XA的事务模式也纳入进来了。

最终从整个架构上来说，我们是打造了一站式的分布式事务的解决方案。针对不同的业务场景，Seata都能做事务。如上图所示，目前市面上没有一只分布事务的模式，能解决不同业务场景的问题。主要强调几个问题，分布式事务可能有同步的分布式事物，有异步的分布式事务，以及对分布式事务的一致性的要求也不高。有强一致性，最终一致性，弱一致性。

另外，对于事物执行时间的长短也有要求。比如有长事务、短事务以及性能吞吐量等等。所以我们纳入了现在的四种事务模式，它们从改造成本、性能隔离性上各有所长，这里就不展开介绍了。

三、如何基于Seata扩展RPC和数据库

首先看一下Seata开源社区这几年的发展。目前Seata已经具备了AT、TCC、Saga、XA四种事务模式，而且对于市面上主流的关系数据库，RPC框架做了广泛的支持，同时被许多第三方社区做了主动和被动集成。已经和三十多个社区做了集成，这些集成都放在我们的扩展机制里边。

目前多语言体系也做起来了，除了最开始的Java，Go语言支持的也非常成熟，欢迎大家去使用我们的Go版本，给我们提更多宝贵的建议。另外，我们还建建设了多语言版本，包括PHP、Python等等。

目前 Seata 开源产品已被上千家企业在业务系统中应用，金融企业纷纷试点。我们都知道金融类的业务对分布式事务是强需求，而且它的业务场景非常严苛。像中信银行、光大银行、农行我们也做了一些社区上的合作，改造一些他们的核心账务系统，用Seata保证他们账务体系的数据一致性。

基于 Triple 实现 Web 移动端后端全面打通

Sat, 07 Oct 2023 00:00:00 +0000

摘要：本文整理自陌陌研发工程师、Apache Dubbo PMC陈有为在 Community Over Code 2023 大会上的分享，本篇内容主要分为四个部分：

一、RPC 协议开发微服务
二、全新升级的 Triple 协议
三、Triple 协议开发微服务
四、Dubbo 为 Triple 协议带来治理能力

一、RPC 协议开发微服务

在我们正常开发微服务的时候，传统RPC服务可能在最底层。上层可能是浏览器、移动端、外界的服务器、自己的测试、curl等等。我们可能会通过Tomcat这种外部服务器去组装我们的RPC层，也就是BFF。或者我们没有BFF，我们的RPC就是对外提供服务。但因为浏览器要访问，所以我们需要有一个网关，比如说Apisix或者ShenYu等HTTP网关。

上图展示的是我们的流程，但是存在一些问题。

如果我们的服务是非常轻的，我们只需要一个转发层，我们是不是很麻烦。无论是配网关还是起一个webserver去转发，肯定都很麻烦。

此外，RPC服务大部分都是基于二进制的，而二进制正常在本地是没法测试的。因此我们的公司内都可能就会开发一种后台或者中间的Process让我们去测试。但这个的前提是你至少得把它部署到测试环境，所以还是没法在本地测试。

总体来说，这两个问题的易用性比较低，且开发成本相对较高，因为要做一些重复劳动。

二、全新升级的 Triple 协议

基于上边的两个问题，我们来介绍一下Triple协议。

先来说一下上一代协议，它产出的原因是什么。我们应该都知道Dubbo原来是Dubbo协议，它是基于tcp的，它有一个包。因为它的包的设计，导致了网关无法做一些特殊规则判断、过滤等操作。但也不是绝对的，如果你愿意牺牲性能把包完全解出来，组装回去再透传还是可以做到的，但一般大家都不太能接受。

所以我们就在想能不能把原数据和真正的包分开。现在我们有现成的HTTP，又有一个业界主流的gRPC，所以我们的目标就是兼容gRPC。因为gRPC目前都是用IDL，而IDL有一个问题，尤其在Java侧。因为大家都是写一些接口，定义一些包去实现，这样就会非常麻烦。Go侧就还好，因为大家已经习惯了这种开发模式。

所以我们开发了Triple协议，首先它兼容了gRPC，所以我们能实现和gRPC的完全互通。其次，我们兼容了自己定义接口的方法。虽然会损失一定的性能，但提升了一些易用性。而且RPC一般不是业务的瓶颈，大多数瓶颈还是在DB。

但还有个问题，虽然我们兼容了gRPC，但gRPC是基于TPC的，所以如果前端或者其他第三方系统只有HTTP，它还是接受不了我们的系统。

基于此，我们想推出一个全新的Triple协议。为了解决上述的所有问题，我们参考了gRPC、gRPC Web、通用HTTP等多种协议，做到浏览器访问，支持Streaming，还支持同时运行在 HTTP/1、HTTP/2 协议上。因为目前HTTP/3还没有大规模推广，未来也会支持HTTP/3。

最终的设计实现是完全基于HTTP的，且对人类、开发调试友好。我们可以通过简单的浏览器访问或者curl访问，尤其是对unary RPC。此外，我们和gRPC是完全互通的，用HTTP的业务不用担心兼容性的问题，也不用担心签协议的问题。为了稳定性，我们只会采用业界流行的网络库，比如Java的netty、Go的基础的net包。

虽然Triple协议和gRPC协议都基于HTTP，但gRPC是基于HTTP/2的，而Triple是基于HTTP/1和HTTP/2的。

我们在进入gRPC的同时，我们为了易用性扩展了一些功能。比如请求里我们支持application Json，curl访问，此外上一版的协议，为了支持传统定义接口的方式，我们有一个二次序列化的过程。我们想在这里通过一个特殊的tag来决定我们的body的结构，解决二次序列化的问题。同时这个东西是可以扩展的，理论上HTTP的所有future我们在Triple协议上都可以实现，也可以拓展。

用了Triple协议之后，我们的开发流程也发生了改变。如果你不需要进行组装，或者没有外层的代理，可能你的接入流程就是从外部的请求浏览器、对方的服务器、curl、自己测试等直接到了server。

和其他的gRPC的通信也是没有问题的，流程就相当于少了一层。对于大多数用户，如果你不需要这个场景，其实是有很大的好处。

Triple协议因为最开始兼容gRPC，那个时候只基于HTTP/2，HTTP/2有Streaming的能力，所以它天然支持Streaming。但这里比较特殊的是，我们新版的协议在HTTP/1也支持了Stream，但仅支持了Server Stream。也就是客户端发一个，服务端发好几个回去，这个HTTP/1的Server Push实现的。

Client Stream和Bi Stream就没什么可说的了。但有一个特别的是，在Java侧没有Bi Stream，从编码上就没有，但从实现上是有的。

三、Triple 协议开发微服务

目前Triple协议比较灵活的支持两种定义方式，分别是IDL定义和直接定义。直接定义支持同步、异步、手写。还有比较极端一点的，比如在自己定义接口的时候用IDL生成probuff的类，我们不定义它的service，只用它的接口也是没问题的，它会自动识别接口使用pb还是不使用pb。

Server就是把它的务实现一下。上图是一个例子，我就直接拿了API的组装方式，真正的业务上可能是注解或者XML的方式。

因为我们支持了HTTP这个标准的协议，理论上我们的测试就会变得很简单。

因为我们支持gRPC，所以我们可以用gRPC curl去调用我们的服务。但前提是你得有反射服务，然后手动开启一下，它不是默认开启的。然后它就可以通过反射拿到接口的源数据，通过Json转成pb格式发过去。或者我们直接用Application Json的方式直接调过去。这里有一点比较特别的是在HTTP/1下我们也可以用Sream。

启动速度提升10倍：Apache Dubbo 静态化 GraalVM Native Image 深度解析

Sat, 07 Oct 2023 00:00:00 +0000

摘要：本文整理自杭州有赞科技有限公司中间件技术专家、Apache Dubbo PMC华钟明在 Community Over Code 2023 大会上的分享。本篇内容主要分为五个部分：

一、GraalVM 直面Java应用在云时代的挑战
二、Dubbo 享受 AOT 带来的技术红利
三、Dubbo Native Image 的实践和示例
四、Dubbo 集成 Native Image 的原理和思考
五、Dubbo 在 Native Image 技术的未来规划

一、GraalVM 直面Java应用在云时代的挑战

云计算时代比较显著的特点包括：

基于云计算的基础设施，Java应用能够在云计算的基础设施上快速、轻松、高效的做到弹性。
基于容器化技术，系统资源切分的更加细，资源的利用率也更高了。
基于云计算的开发平台，让应用部署的更加容易，更加敏捷。

那么在云计算时代，Java应用存在哪些问题呢？

冷启动速度较慢。
应用预热时间过长，无法立即达到性能峰值。
内存、CPU等系统资源占用高。
Java构建的应用程序繁重，执行还需要具备JDK环境。

在Serverless场景上，Java的问题会尤为突出，因为Serverless不仅能简化开发场景和开发体验，还能做到极致的弹性，甚至是秒级的弹性。

上图是Datalog统计的Fast和AWS两个产品。Java语言虽然更流行，但相较于Python和Node.JS，它的占比还是比较低的。Java本身在Serverless层面，比如在做容器的调度、镜像的下载的时候，启动时间、冷启动的时间、预热时间等等，都会影响Serverless场景下它弹性扩容的时间。

下面介绍一下GraalVM，它是可以把Java应用提前编译到独立的二进制包内，这些二进制包相对于跑在JVM上它可以更小，更快的启动，不需要预热就能够达到极限的峰值，还可以减少内存和CPU的占比。

可以看到它的介绍和Java语言的应用所涉及到的问题都一一对应。GraalVM应该算是JDK的"超集"，除了包含完整的JDK发行版本外，还有GraalVM Compiler、Native image、Truffle等，甚至还涉及到多语言汇编的能力。

总结一下，GraalVM本身涉及两部分，JIT和AOT。

JIT，是在编译后的class文件、字节码文件，它会在运行时把它翻译成机器码。
AOT，它和JIT的区别是，它在编译期就能把字节码直接转化为机器码，无需在运行时再去处理。所以它的CPU和内存会相对更低。

上图左侧是一张Java生命周期的全景图。可以看到，它从JVM的启动，再到Java的main函数的启动，再到Java的应用预热，再到它的稳定期，最后到达效果，这是Java完整的生命周期的呈现。

而AOT的区别在于，它没有红色的VM。另外，JIT相对于AOT而言是没有的，也没有浅绿色的解释器。所以AOT对于JIT来说，只有内加载，GC以及它能够瞬间达到应用的稳定期。

根据右侧的图可以看出：

AOT的启动耗时相对较低，内存损耗和它打出来的二进制包相对较小。
JIT因为有及时编译的效果，所以现在极限的分值比AOT要好，比如它的极限吞吐量比AOT好。

二、Dubbo 享受 AOT 带来的技术红利

多产物形态

我们在编码之后，Soft Code的产物形态新增了。

第一种是我们传统认知上的Jar包形态，比如mvn、clean、package。第二种是Docker Image，它能轻松的帮我们直接打到镜像里面去，不用写dockerfile等文件。第三种是我们集成GraalVM后新产生的一种Native可执行文件的形态。这种形态无需JDK的环境就能启动，它能像GO一样把二进制文件直接启动。

启动耗时大幅降低

手把手教你部署Dubbo应用到Kubernetes – Apache Dubbo Kubernetes 最佳实践

Sat, 07 Oct 2023 00:00:00 +0000

精进云原生 – Dubbo Kubernetes 最佳实践

摘要：本文整理自阿里云研发工程师、Apache Dubbo PMC江河清的分享。本篇内容主要分为六个部分：

一、使用 Dubbo Starter 初始化项目
二、开发微服务之协议选型
三、基于 Kubernetes 快速初始化环境
四、快速部署应用到 Kubernetes 集群中
五、云原生微服务可观测最佳实践
六、在 Kubernetes 中管理微服务应用

上图是从 Istio 借鉴的一个demo，它包含了四个组件，分别是Product Page、Reviews、Details、Ratings，它就是一个全链路的串联，实现了整体的微服务架构，它的功能可以实现我们简单的调用。

一、使用 Dubbo Starter 初始化项目

首先介绍一下Starter的功能。对于很多开发来说，在Java体系下创建出新的应用，无外乎就是用IDE创建一个新的项目，或者用maven的artifact，或者基于Spring的Initializer。

上图使我们基于Spring的Initializer建立了我们自己的初始化项目的工程。我们点击最上面的网址就能直接看到这个页面了，你需要输入对应的group和artifact。然后选择你希望用到的组件，比如Nacos、Prometheus的组件等等。

除此之外，我们在IDE里提供了一个Dubbo的插件。这个插件可以通过上图的方式进行安装，或者如果你的仓库里已经用到了Dubbo的配置，它会提示你可以直接安装。安装完成后在右边就会有一个对应的初始化的项目了。

上图是一个示例，它在这里建立了一个Dubbo的项目，然后你需要在这里选中所需要的组件信息，最后点击创建，之后它就会帮你在本地直接创建出一个全新的项目，然后你就可以在这个模版上开发了。

二、开发微服务之协议选型

我们会用到最新的Triple协议，它整体支持兼容gRPC、HTTP/1、HTTP/2。

这里主要想和大家分享的点是，我们基于curl访问的能力，比如POSTMAN、HttpClient都是支持的。

下面来看一下我们的项目，这是刚才建立的一个项目，我现在把应用启动起来，配置一些注册中心的地址，这就是一个标准的Spring的启动的流程。这里定义了一个接口，这个接口返回了一个"hello"的内容信息。然后我用一个简单的命令，就可以直接返回我的hello world的结果了。这样对我们本身的测试来说有很大的帮助，也就是本地启动之后，就可以直接测试接口。

三、基于 Kubernetes 快速初始化环境

假设我们已经把前面四个应用的代码全部开发完成了，接下来我要把它部署到K8s环境上。部署之前有一个非常重要的步骤，需要先初始化环境。比如Nacos、ZK、Skywalking、Zipkin、Prometheus等组件，我们都需要将它们安装上去，因为它们是应用前置依赖的各种组件。这些组件的安装流程都很复杂，那么我们如何简化这个流程呢？

Dubbo提供了一个命令，这个命令可以一键帮你在K8s体系下拉起上图左边的所有组件。

这里有一个简单的例子，拉起来之后，它会把所有的组件都会帮你拉起来。这里埋一个点，这里的Prometheus我们后面还会继续使用。整个Nacos的地址，Zookeeper的地址都会直接提供给你。

这也是一个的例子。执行一个简单的命令，然后本地会把kubectl的配置都准备好，它就会自动的帮你把组件都创建起来。也就是我们一键就可以获取到所有service的部署。

四、快速部署应用到 Kubernetes 集群中

部署应用有三个重要的点，分别是应用容器化、无状态部署、生命周期对齐。

首先介绍一下应用容器化。想要将应用容器化，首先需要建一个dockerfile，引入一个jdk的包，把启动命令和启动脚本拉进去。然后还要写一个Java的编译的脚本，把Java编译的jar包结果拉进去。这个过程非常复杂，所以我们可以用一下Jib的插件。这个插件是maven的一个plugin，我只需要把这些配进去，指定成我的Image就足够了。

可以看到，我只需要把我的pom里添加一个对应的配置项依赖，通过一键maven的编译模式，它就可以在maven打包的过程中帮你构建完镜像，然后直接推送到远端仓库。这一切都只需要这一个命令就可以完成，而且一次性配置之后，未来你所有的镜像更新都可以自动化的去做，不需要再去写繁琐的dockerfile。

其次介绍一下无状态部署。刚才我们把镜像打出来了，这只是第一步，紧接着我们要让镜像run起来。我们可以基于K8s的deployment的模式，它是从K8s的官网上直接拉下来的。拉下来之后我们可以指定对应的应用名、镜像信息等等，这是K8s无法绕过去的，相对于说它需要配置这样的一个demo，当然也会有云厂商平台提供一个可视化的界面给你，它的底层配置的就是这样的一个yarml。

这是一个简单的例子，把deployment配置完之后，指定了刚才的镜像。同时我声明了一个service，这个service非常重要，它后面会作为from_end应用入口的配置，但它是一个Ingress网关。可以看到apply镜像之后，我们就可以在K8s体系上把这个环境run起来了。

这里做一个简单的测试，我引入一个curl的容器，同样我们可以用刚才curl的命令访问我新部署好的容器节点，可以看到它返回了hello world的数据信息。

政采云基于Dubbo的混合云数据跨网实践

Sat, 07 Oct 2023 00:00:00 +0000

摘要：本文整理自政采云资深开发工程师王晓彬的分享。本篇内容主要分为四个部分：

一、项目背景
二、为什么叫高速公路
三、修路实践
四、未来规划

一、项目背景

我们有一个云岛业务叫政采云，它是政府的购物网站，类似于淘宝。政府采购会在政采云上做企业采购、政府采购的业务。

云岛中的"云"是指我们的云平台，云平台是我们公司自己部署的一套购物网站，它对应的是一套微服务框架。而"岛"是指，比如安徽或者山西它们都有自己的局域网，如果我们在它们那里也部署一套这个框架，就叫"岛"。我们的云主要是给浙江省和相关的区划用的。

我们的云和岛之间存在数据传输的问题，举个例子，比如我现在收到一个政府的公告，而这个公告肯定是全国性的。所以我可能会在云平台的管理平台上去录公告，再把它推送出去，这个时候云和岛之间就存在了一些数据的跨网。

云岛网络

对我们云平台来说，这个局域网是我们公司内部完全可控的。比如你要开个端口，很快就能开起来。导端它可能是局域网或者是私有网络，比如我们之前做了一个浙商银行的项目，它是完全隔离的一个岛。他们的安全策略和开端口的东西都是他们自己定义的，这就是我们云岛的业务结构。

混合云岛网络

上图是大概的数据链路图。云平台下面有分支机构、分公司，它们会对应一套业务的系统。政务云是我刚才说的省级（安徽省）或者市级（无锡市）对应的区块，隔离的政务云。私有部署是银行、国企、军队、政企等典型的混合云的网络架构。

混合云岛网络的特点

我们混合云网络架构的特点包括：

平台的一致性。我们部署在公有云、云平台、政务云、私有云上的那一套的代码是一样的。我们把一套代码部署在不同的地方就变成了多个平台。
网络连接与能力复用。我们会依赖一些第三方的能力，比如短信，但私有云上它的网络管控比较严，所以和第三方互通端口或者网络的流程就会比较复杂。这个时候我们希望去复用我们云平台的能力，这个时候他们之间又有一些数据的交互。
跨域访问迁移。
统一的平台管理。像我刚才举的例子，如果要发公告，我们希望可以在一个平台上就可以管理起来。而不是浙江发一条，安徽发一条，那样维护的成本也会比较高。

政企网络痛点

很多公司都会和政府打交道，政企网络有以下几个特点：

网络复杂。比如银行的网络，它们的安全性和内部的东西很复杂，流程的开通也比较多，需要你要经常去跑，跑完了之后发现有新的问题，又要去跑。

安全要求高。比如在开通端口的时候，我们需要去传数据，如果里面的那些序列化的协议不符合它们的规范，它们就会拿掉。这个时候给我们的业务其实是超时的，或者是那种通用的异常。而我们并不知道发生了什么，这就会带来未知的风险。

业务驱动运维。我们有了业务才会去部署，才会去做事情。我们就会多次、重复的投入，这就会导致人力、时间成本会比较高，私有部署的时候会更多。

现有方案

基于以上的痛点，我们做了两个方案。

第一个方案，基于Dubbo Filter的单向方案。这个方案的历史比较久一些，它有两个特点。

第一个特点，单向传输。它是从"岛"到"云"只有一个方向，它基于Dubbo Filter的原因是，我们公司内部的微服务都是通过Dubbo来调用的，所以我们是强依赖的来Dubbo的。所以做数据跨网的方案肯定会基于Dubbo的特性来做。

第二个特点，在本地部署业务的provider过滤器是运维上的负担。当导端需要把数据同步给云端的时候，也就是从岛端的业务Web传输到云端的业务provider。这个时候我必须在导端也部署一套业务的provider才可以。部署它的原因是它要拦截这个请求，然后把这个请求转发给部署在云平台的Dubbo网关。

但这个时候就会给我们带来负担。如果导端本来就有数据的入库就还好，因为provider本来就存在，但一些业务只是做跨网用的，没有本地的入库，那么这个时候业务的provider就是多余的了。

第二个方案，网状点对点方案。因为岛和岛之间需要网络互通，所以就会单独开通这个点和你需要传输的点之间的端口。开通之后我们就可以调用了，调用的形式可以用Dubbo。

这个方案有一个很明显的缺陷，线特别多，所以点和点之间开通的复杂度也很高，对后面的扩展可能也非常不利。

以上方案存在的问题包括单向传输、白名单开通成本高、平台维护成本高、公共功能的缺失。

基于以上的问题，我们做了一个新的方案，叫高速公路。

二、为什么叫高速公路

为什么叫告诉公路呢？主要因为我们想要达到的效果是：

只建一次，可复用。比如北京到上海的高速公路，它只要够宽，一条就够了。如果你是从上海到北京或者从杭州到北京，是可以复用的，不用单独再修建一条。

隧道机制。因为高速公路修建的地方不一定都在平原，可能会在河、海、山等等附近。如果我们在高速公路下面搭建一条隧道，这个时候对于司机来说就是无感的。我们的目的是一样的，如果你觉得政企网络很复杂，那么我们就帮你把它屏蔽掉，这样你也是无感的了。

考虑传输性能。如果每个业务部门都自己搭建一套传输链路，那么传输性能只要能承载自己的业务就够了，因为不一定要给别人用，或者给别人用了也是小范围的。但如果搭建的是一条可复用的链路，就必须考虑传输的性能了。

三、修路实践

接下来介绍一下我们在修建高速公路的时候遇到的一些问题以及具体的做法。我们在客户端接入上遇到了以下问题：

第一个问题，强依赖Dubbo。

第二个问题，透明传输，不改变使用Dubbo的方式。也就是我不需要自己写一些注解代替Dubbo，或者写一些API调用Dubbo。因为写了之后，一些新人可能并不能理解或者不能习惯，也不知道里面有什么坑。所以我们用原始的Dubbo来做可能会对用户更加无感。

第三个问题，接入灵活，支持多种形态。虽然我们强依赖Dubbo必须支持Dubbo，但我们也需要支持其他的形式，比如HTTP。但在接入之前，我们需要考虑接入灵活性的问题。

下面我们先介绍一下Dubbo的方式。Dubbo的客观接入主要有以下三种方式：

第一种，注解方式。使用@DubboReference提供的通用parameters参数，设置路由目标，可以达到方法粒度的路由。路由信息写在中间parameters那里，parameters是Dubbo给我们提供的通用参数的传递。

如果是正常的，我写了这个信息，Dubbo是不做任何处理的，因为这个东西对它来说没有含义。但因为你引入了高速公路的SDK，所以在你写了这个东西之后，我们就会去解析，拦截Dubbo的请求，把parameters里的参数抓起来做一些路由处理，这种形式其实没有改变Dubbo的使用方式。

第二种，配置中心指定。比如我们用的是阿波罗的配置中心，它完全可以把接入方式替换掉，parameters的信息在配置中心配置也可以，只要SDK可以支持就好。这种方式其实代码是完全侵入的，就是跟跨网之前和跨网之后没有任何区别。但最后发现我们的业务并不喜欢这种方式，首先因为阿波罗大家不喜欢用，其次不好理解。如果是一个新人看这个代码，他就会认为是在调本地的接口。

第三种，线程指定。当你在线程里指定了路由信息，下面再去调用的时候，这次调用就会走你的路由。如果再调用一次，它就会调回本地。因为基于线程的形式，在Dubbo的扩展里，它会在调用完成之后把线程信息清理掉。所以需要注意一下，如果你想多次调用，就需要写多次。如果不想写多次，你可以用上面这种方式，你只要在当前的been里，都是路由到上海。

接下来介绍一下高速公路的架构，刚才介绍点对点的方式，它的缺点是开通白名单比较复杂。现在我们的高速公路架构是一个新型的架构，所以它开通白名单的复杂度会低一点。

如上图所示，比如最左边的节点是上海，最上边的节点是安徽，我想从安徽到上海，这个时候中心网关就需要开通一个白名单。开完之后，这条链路就可以直接过去了。可以看到一共就六条线，所以它的复杂度也就下来了。

18:30上图是高速公路里最核心的架构图。

比如山西集群的APP1调APP2的时候，我想去调上海APP2，如果你什么都不做，它默认调的就是山西集群的APP2。如果你在APP调用的时候加了一些路由信息，放在山西集群APP1里的SDK就会把它的流量切走，切到山西集群的Dubbo网关。

之后Dubbo网关会通过HTTP的协议走统一网关，再通过HTTP的协议到上海集群的Dubbo网关。在这里会把路由信息拿到，包括调用的Service、方法、版本号、参数等等。然后通过泛化的形式调上海集群的APP1，最后返回，完成这次跨网的调用。

那么为什么要有Dubbo Proxy这个角色呢？为什么不直接从APP1切到统一网关？少一个步骤不好么？涉及到的原因有以下三点：

CoC Asia 2023 大会精彩回顾

Fri, 25 Aug 2023 00:00:00 +0000

以下包含本期演讲的完成文字稿内容与现场精彩瞬间，更多 ppt、视频录像可关注 “apachedubbo” 微信公众号获取。

Apache Dubbo 社区骨干成员及 Apache Board Member, Justin Mclean 合影

Apache Dubbo 社区骨干与 Apache Member 交流合影

华钟明，Apache Dubbo PMC Member，杭州有赞科技有限公司中间件技术专家，《Apache Dubbo 静态化 GraalVM Native Image 解决方案与实践》

宋小生，Apache Dubbo Committer，平安壹钱包中间件资深工程师，《Apache Dubbo 云原生可观测性探索与实践》

Dubbo 微服务专题论坛 - 8月19日北京ApacheCon大会不见不散

Mon, 07 Aug 2023 00:00:00 +0000

Dubbo 微服务专题论坛将于8月19日下午在北京丽亭华苑酒店举行，作为本次 CommunityOverCode Asia 2023（原 ApacheCon Asia）大会上的重磅议题，我们将以 Apache Dubbo 为中心展开，给大家带来开源微服务技术方向发展、云原生微服务选型、企业实践分享等精彩内容！

打开官网购票链接，输入 cocasia 优惠码可八折购票！

作为 Apache 软件基金会（ASF）的官方全球系列大会，每年的 CommunityOverCode Asia 都吸引着来自全球各个层次的参与者、社区共同探索 “明天的技术”。8 月 18 日至 20 日，即将强势来袭的 CommunityOverCode Asia 2023 上，大家可以近距离感受来自 Apache 项目的最新发展和新兴创新。

GLCC x Apache Dubbo编程夏令营报名启动

Wed, 05 Jul 2023 00:00:00 +0000

背景介绍

GitLink编程夏令营（GLCC），是在CCF中国计算机学会指导下，由CCF开源发展委员会（CCF ODC）举办的面向全国高校学生的暑期编程活动。活动将覆盖近千所高校，并联合各大开源基金会、开源企业、开源社区、开源专家，旨在鼓励青年学生通过参加真实的开源软件开发，提升自身技术能力，为开源社区输送优秀人才。为青年学生提供开放友好的交流平台，希望进一步推动国内开源社区的繁荣发展。

报名方式

此次报名仅限 GLCC “无奖金项目”。具体请在此查看 项目详情与报名方式。

Apache Dubbo 项目报名截止日期：2023-07-30

如有更多问题，请扫描官方公众号咨询：

Apache Dubbo 开源之夏 2023，贡献社区赢取 12000 奖金

Mon, 15 May 2023 00:00:00 +0000

欢迎在校同学们参与Apache Dubbo开源之夏，社区导师手把手让你的代码被社会广泛复用，来赚取最高12000奖金，可推荐入职/实习你心意公司，又拿钱又成长又有价值，你还等什么呢？报名马上截止，快来参与Apache Dubbo开源之夏。

OSPP 开源之夏是什么？

开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进优秀开源软件社区的蓬勃发展，培养和发掘更多优秀的开发者。活动联合国内外各大开源社区，针对重要开源软件的开发与维护提供项目任务，并面向全球高校学生开放报名。学生可在本活动中自主选择感兴趣的项目任务进行申请，并在中选后获得该开源项目资深维护者（社区导师）亲自指导的机会，完成项目并贡献给社区后，参与学生还将获得开源之夏活动奖金和结项证书。

Apache Dubbo 项目简介

Apache Dubbo 是国内最具影响力的开源软件项目之一，由阿里巴巴贡献开源，是支撑阿里双十一百万集群、万亿次服务调用的核心框架，目前 Dubbo 已捐献给享誉世界的 Apache 软件基金会 (ASF)。

参与Apache Dubbo开源之夏条件

本活动面向年满 18 周岁在校学生。
暑期即将毕业的学生，只要在申请时学生证处在有效期内，就可以提交申请。
海外学生可提供录取通知书、学生卡、在读证明等文件用于证明学生身份。

参与Apache Dubbo开源之夏，你能获得什么？

**【你的代码被社会广泛复用】**你的代码可能会运行在上万家企业核心业务逻辑中，帮助企业解决问题。
**【赢得最高12000奖金】**奖金总额根据项目难度分为进阶 12000 元、基础 8000 元（注：奖金数额为税前人民币金额）
**【社区核心人员辅导快速成长】**只要你报名被选中，每个题目的导师会精心手把手教你融入社区，帮助你完成题目的设计以及最终的落地。
**【推荐入职/实习】**在本次编程之夏项目中表现优秀同学，可推荐入职/实习你心意的公司工作。
**【额外获得社区礼包】**所有参与本次编程之夏项目的同学，均可获得Apache Dubbo社区大礼包。

百分百有奖品拿哦，现在唯一的问题是时间不多了，赶紧上车报名，截止报名时间是6月4日，6个核心题目，快点来报名参与Apache Dubbo编程之夏吧。

课题&报名方式

点开Apache Dubbo开源之夏的链接选择你喜欢的题目：

具体流程请参考学生指南。

精进云原生 - Dubbo 3.2 正式发布

Sat, 15 Apr 2023 00:00:00 +0000

背景介绍

Rest 协议支持

1. Why Rest？

随着移动互联网的普及，越来越多的应用程序需要与不同的系统进行集成。而这些系统可能使用不同的通信协议，这就需要应用程序能够灵活地适应各种协议。Rest 协议正是一种非常灵活的协议，它使用 HTTP 进行通信，可以与几乎任何系统进行集成。

在过去，RPC框架通常使用二进制协议进行通信，这种协议非常高效，但不够灵活。相比之下，Rest协议使用HTTP进行通信，更方便与其他系统集成，也更容易与现代化的Web和移动应用程序集成。

除了灵活性，Rest协议还具有易读性和易用性。使用Rest协议，开发人员可以使用通用的HTTP工具（例如cURL或Postman）测试和调试服务，而不需要特定的工具。此外，由于Rest协议使用标准的HTTP方法（例如GET、POST、PUT和DELETE），因此开发人员可以更容易地理解和使用服务。

2. How To？

在之前的 Dubbo 版本中，也提供了 Rest 协议的支持，但存在以下问题：

仅支持 JAX-RS 注解域，相较于采用度更高的 Spring Web 注解，复杂度更高
需要依赖众多外部组件，如 Resteasy、tomcat、jetty 等，才能正常工作，极大地增加了使用成本。

因此，在 Dubbo 3.2 版本中，我们引入了 Spring Web 注解域的支持以及 Rest 协议的原生支持，无需依赖任何外部组件。

最直观的区别是，如果你升级到了 Dubbo 3.2，通过 Spring Web 发布的服务也可以直接通过 Dubbo 来发布。这一切只需要将 @Controller 注解改成 @DubboService 注解即可。

此外，对于原来使用 Spring Boot 或者 Spring Cloud 作为服务拆分的用户，也可以基于本功能平滑地迁移到 Dubbo 上来，以极低的成本获得 Dubbo 强大的能力。

2022 年度总结与 2023 新年规划

Thu, 23 Feb 2023 00:00:00 +0000

2022 年度总结

1 Dubbo 开源 12 周年

50k+ star，30k fork，1000+ Contributor

2 Dubbo3 里程碑

实现规模化生产检验

阿里巴巴核心微服务集群实现从 HSF 到 Dubbo3 的全面升级，顺利支撑双十一、双十二万亿级服务调用

发力多语言生态

具备生产可用条件

Java、Go

从孵化走向成熟

Rust、Node.js、Python

3 核心技术

应用级服务发现 HTTP/2 协议流量管控升级可观测性自适应负载均衡 Proxyless Mesh Spring Boot3 & Spring6

4 新晋 Committers&PMC

本年度社区共发展 Committer 13 位，PMC 4 位

2023 新年规划

官网与文档体验全面提升
Go、Node.js、Rust 等多语言体系建设
全面提升整体可观测性
Dubbo Admin 一站式服务运维管控平台
Dubbo Mesh 走向成熟
提升 HTTP 开发体验，补全 Web 互通
打造 gRPC over Dubbo 最佳实践
完善的认证鉴权体系

一文帮你快速了解 Dubbo 核心能力

Thu, 23 Feb 2023 00:00:00 +0000

Dubbo 简介

一句话定义

Apache Dubbo 是一款微服务开发框架，它帮助解决微服务开发中的通信问题，同时为构建企业级微服务的提供服务治理能力，Dubbo 不绑定编程语言，我们的目标是为所有主流语言提供对等的微服务开发体验。

基本架构

Dubbo 从架构图上分为数据面和控制面。在数据面，使用 Dubbo 开发的微服务进程间基于 RPC 协议通信。DubboAdmin 控制面作为服务治理的抽象入口，由一系列可选的服务治理组件构成，负责 Dubbo集群的服务发现、流量管控策略、可视化监测。

行业应用

Dubbo 设计用于解决阿里巴巴内部大规模微服务集群实践难题，当前已被广泛应用于几乎所有行业的微服务实践中。

以阿里巴巴为例，在 2021 年，阿里巴巴基于内部多年 HSF 框架实践积累，面向云原生架构设计了下一代微服务框架 Dubbo3，用于解决性能、治理升级、服务网格等一系列问题；截止目前，阿里巴巴已全面完成从 HSF到 Dubbo3 的迁移，核心业务都跑在开源 Dubbo3 之上。

Dubbo 到底提供了哪些核心能力？

提供微服务抽象与框架

首先，Dubbo 作为服务开发框架解决了业务应用中微服务定义、暴露、通信与治理的问题，为业务应用开发定义了一套微服务编程范式。具体来说，Dubbo 为业务应用提供了微服务开发API、RPC 协议、服务治理三大核心能力，让开发者真正的专注业务逻辑开发。

Dubbo 不是应用框架的替代者，它可以很好的工作在每种语言的主流编程框架之上，以 Java 为例，Dubbo 可以很好的与 Spring 协作，并在此基础上提供服务定义、微服务编程、服务发现、负载均衡、流量管控等能力。

提供灵活的通信协议切换能力

在通信方面，Dubbo 区别于其他 RPC 框架的是它不绑定特定协议，你可以在底层选用 HTTP./2、TCP、gRPC、REST、Hessian 等任意通信协议，同时享受统一的 API、以及对等的服务治理能力。

一切皆可扩展

Dubbo 的另一个优势在于其可扩展性设计，从流量管控、协议编码、诊断调优、再到服务治理，你都可以去扩展，满足企业级微服务开发与运维的所有诉求。

丰富的生态

基于扩展能力 Dubbo 官方提供了丰富的生态适配，涵盖了所有主流的开源微服务组件。

服务网格

Dubbo 在 Proxyless Mesh 模式下的探索与改进

Thu, 02 Feb 2023 00:00:00 +0000

一、背景

随着 Docker 和 Kubernetes 的出现，一个庞大的单体应用可以被拆分成多个独立部署的微服务，并被打包运行于对应的容器中。不同应用之间相互通信，以共同完成某一功能模块。微服务架构与容器化部署带来的好处是显而易见的，它降低了服务间的耦合性，利于开发和维护，能更有效地利用计算资源。当然，微服务架构也存在相应的缺点：

强依赖于 SDK，业务模块与治理模块耦合较为严重。除了相关依赖，往往还需要在业务代码中嵌入SDK代码或配置。
统一治理难。每次框架升级都需要修改 SDK 版本，并重新进行回归测试，确认功能正常后再对每一台机器重新部署上线。不同服务引用的 SDK 版本不统一、能力参差不齐，增大了统一治理的难度。
缺少一套统一解决方案。目前市场不存在一整套功能完善、无死角的微服务治理与解决方案。在实际生产环境往往还需要引入多个治理组件来完成像灰度发布、故障注入等功能。

为解决这些痛点，Service Mesh诞生了。以经典的 Sidecar 模式为例，它通过在业务 Pod 中注入 Sidecar 容器，对代理流量实施治理和管控，将框架的治理能力下层到 Sidecar 容器中，与业务系统解耦，从而轻松实现多语言、多协议的统一流量管控、监控等需求。通过剥离SDK能力并拆解为独立进程，从而解决了强依赖于SDK的问题，从而使开发人员可以更加专注于业务本身，实现了基础框架能力的下沉，如下图所示（源自dubbo官网）：

经典的 Sidecar Mesh 部署架构有很多优势，如减少SDK耦合、业务侵入小等，但增加了一层代理，也带来了一些额外的问题，比如:

Sidecar 代理会损耗一部分性能，当网络结构层级比较复杂时尤其明显，对性能要求很高的业务造成了一定的困扰。
架构更加复杂，对运维人员要求高。
对部署环境有一定的要求，需要其能支持 Sidecar 代理的运行。

为解决这些痛点，Proxyless Service Mesh 模式诞生了。传统服务网格通过代理的方式拦截所有的业务网络流量，代理需要感知到控制平面下发的配置资源，从而按照要求控制网络流量的走向。以istio为例，Proxyless 模式是指应用直接与负责控制平面的 istiod 进程通信，istiod 进程通过监听并获取 Kubernetes 的资源，例如 Service、Endpoint 等，并将这些资源统一通过 xDS 协议下发到不同的 RPC 框架，由 RPC 框架进行请求转发，从而实现服务发现和服务治理等能力。 Dubbo 社区是国内最早开始对 Proxyless Service Mesh 模式进行探索的社区，这是由于相比于 Service Mesh，Proxyless 模式落地成本较低，对于中小企业来说是一个较好的选择。Dubbo 在 3.1 版本中通过对 xDS 协议进行解析，新增了对 Proxyless 的支持。xDS 是一类发现服务的总称，应用通过 xDS API 可以动态获取 Listener(监听器)、Route(路由)、Cluster(集群)、Endpoint(集群成员) 以及 Secret(证书)配置。

Dubbo 3.1.5、3.2.0-beta.4 正式发布

Mon, 30 Jan 2023 00:00:00 +0000

Dubbo 3.1.5 版本是目前 Dubbo 3 的最新稳定版本，我们建议所有的用户都升级到最新的稳定版本。Dubbo 3.2.0-beta.4 版本是目前 Dubbo 3 的最新特性版本，包括了如 Spring Boot 3、JDK 17、服务粒度的线程池隔离等新特性的支持，欢迎大家尝鲜使用。

Dubbo 3.1.5

新特性

Dubbo QoS 支持记录请求的记录，便于进行审计
支持在服务映射失败以后定时进行重试，降低由于元数据中心抖动带来的影响
支持在初始化 Nacos Client 的时候进行健康检查，如果失败则在一定次数限制下进行重试，降低由于 Nacos 性能问题带来的稳定性影响
支持序列化类检查机制，默认开启日志告警模式

Bugfix

修复资源加载器的日志级别
修复 Dubbo 配置类对 Scope Model 进行懒加载，避免触发非预期的默认模块初始化
修复 ReferenceConfig 中获取 ClassLoader 的逻辑
修复 Metadata Service 在获取订阅服务列表时出现 NPE 的问题
修复对接 Spring Cloud Rest 模式的时候 Metadata 配置覆盖的问题
修复 Spring 懒加载时可能出现死锁的问题
修复端口重复的无效日志
修复 Active Limit Filter 不生效的问题
修复服务映射时 Nacos CAS 检查写入无效的问题
修复 Zookeeper 注册中心对接的应用级服务发现在服务发布的时候出现单节点服务找不到的问题
修复服务映射在冲突以后未等待导致的冲突率高的问题
修复应用级服务发现下节点更新失败的问题
修复应用级配置覆盖不生效的问题
修复在应用级地址刷新之后原 Revision 的元数据无法获取的问题
修复 Zookeeper 注册中心在应用级服务发现下退订阅后无法重订阅的问题
兼容 Nacos 在频繁刷新时最终一致性错误的问题
关闭 Nacos 本地缓存获取的开关
修复 Triple 传递大写 Attachment 无效的问题
修复 Triple 处理特定类反序列化错误的问题
修复 Protobuf 依赖不存在时抛出非预期异常的问题
修复 CountDown 功能无效的问题
修复 Triple 在反序列化时类加载器未切换的问题

FAQ

本次发布中有 5 个提交涉及异常日志 FAQ 的完善。关于错误码机制请参考官网错误码机制介绍一文。

Dubbo Java 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)

Dubbo Java 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

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 同在。

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 一样，忽略不存在的字段。因为这是一个特性的变更，所以升级的同学一定要注意了。

都已经十岁的 Apache Dubbo，还能再乘风破浪吗？

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

纵观中国开源历史，你真的没法找到第二个像 Dubbo 一样自带争议和讨论热度的开源项目。

一方面，2011 年，它的开源填补了当时生产环境使用的 RPC 框架的空白，一发布就被广泛采用；另一方面，它经历了停止维护、重启维护后捐献给 Apache 基金会、接着又以顶级项目的身份毕业。

面对多疑的开发者，在云原生时代，Apache Dubbo 将如何延续当前光芒？

今年是 Dubbo 从 Apache 基金会毕业的一周年，同时也是推进 Dubbo 3.0，即全面拥抱云原生的重要一年。开源中国与 Apaceh Dubbo 共同策划**【Dubbo 云原生之路】**系列文章，和大家一起回顾 Apache Dubbo 社区的发展。系列文章主要涵盖 Dubbo 技术解读、社区、应用案例解析三大部分，之后每周都会和大家见面。

在【阿里巴巴云原生公众号】留言说出与 Apache Dubbo 的故事，点赞排名前十的同学可领取 Dubbo 送出的专属奖品杯子一只；另外由Apache Dubbo PMC @Chickenlj 随机抽取一名幸运读者，赠送价值 260 元护眼灯一台。下周三开奖。

作者简介

刘军，花名陆龟，GitHub 账号 Chickenlj，Apache Dubbo PMC，项目核心开发，见证了 Dubbo 重启开源，到从 Apache 基金会毕业的整个过程。现任职阿里云云原生应用平台团队，参与服务框架、微服务相关工作，目前主要在推动 Dubbo 3.0 - Dubbo 云原生。

系列开篇：3.0 全面铺开、ASF 毕业一周年

从 2019 年到现在，在 Dubbo 毕业的这一年时间里，Dubbo 社区和产品都取得长足进步，同时 Dubbo 云原生版本 - Dubbo 3.0 的开发工作也已经全面铺开。

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 回顾与展望

Mon, 11 Jan 2021 00:00:00 +0000

Dubbo 是阿里于 2011 年开源的一款高性能 RPC 框架，在 Java 生态中具有不小的影响力。2019年5月21日，Dubbo 从 Apache 软件基金会毕业，成为 Apache 顶级项目。目前，毕业后的 Dubbo 项目的生态中已经正式官宣引入了 Go 语言，发布了 Dubbogo 项目。本文即是对 Dubbogo 这一项目的完整回顾与真实展望。由蚂蚁金服中间件技术专家于雨和携程基础中台研发部工程师方银城合作完成。

一 Dubbogo 整体框架

先介绍一下 dubbogo 的缘起，先看下面这幅图：

最右边的 service0 和 service1 是 Dubbo 的服务端，左边的 gateway 是网关，HTTP 请求从网关进来，必须转化成 Dubbo 的协议才能到后面的服务，所以中间加了一层proxy 完成相关功能。基本上每个 service 都需要一个 proxy 去转化协议和请求，所以这个时候 dubbogo 的项目需求就出来了。最初的实现就是以 Dubbo 的 Go 版本作为目标，实现与 Java 版本 Dubbo 的互调。

Dubbogo 目标

然后这个图是 dubbogo 的现在达到的目标：用一份 Go 客户端的代码能够在没有任何代理和其他中间件的情况下直接调用其他语言端，主要是Java 服务端的服务和 Go 服务端的服务，而 Go 作为服务端的时候，Java 客户端也可以直接调用 Go 服务端的服务。

Dubbo Java 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 成为微服务开发的最佳框架。

从 2019 到 2020，Apache Dubbo 年度回顾与总结

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

非常感谢大家对 Dubbo 社区的关注，通过这篇文章我们将：总结过去一年 Dubbo 社区取得的成绩，包括社区和框架演进两个方面；展望未来 Dubbo 社区和框架的新的规划（roadmap）。社区建设是推动 Dubbo 健康持续发展的一个非常重要的环节，我们需要与社区保持良性的互动、有活跃的贡献者、有积极的富有建设性的讨论，而整个 Dubbo 社区过去一年在这方面都做的不错；在框架演进上，我们主要发布了 2.7.0 - 2.7.5 共 6 个特性版本，功能层面涵盖编程模型、协议、服务治理、性能优化等多个方面；除了已经发布的功能外，我们在 Dubbo 3.0 协议、服务自省和云原生等方向上也做了深入的探索，对这些方向的支持将是 Dubbo 接下来的重要工作方向，希望能通过这篇文章将其中更详细的思考和计划同步给大家。

社区回顾

回顾 Dubbo 社区过去一年的发展，其中一个重要的节点就是 2019 年 5 月从 Apache 孵化毕业。成为第二个由 Alibaba 捐献后从 Apache 毕业的项目，我有幸参与到了从重启开源、进入 Apache 孵化到毕业的整个过程，社区在此过程中做了大量的工作，包括邮件列表建设、代码规范检查、文档和代码国际化、issue/pr 处理等，这些一方面是 Apache 社区要求的工作，同时也为推动 Dubbo 的发展起到了正面的作用。

在从 Apache 毕业之后，Dubbo 相关的项目也进行了迁移，都迁移到了 Apache 组织之下：

Dubbo 社区的项目总共有 24 个之多，维护如此多的项目，并不是单纯靠几个活跃的开发者就能做到的，而是靠整个社区努力的结果。我总结了过去一年提名的所有 Committer/PMC，总过有 27 人获得提名（23 名 committer、4 名 PMC），通过下方的饼状图可以看出，只有不到 20% 的贡献者是来自于 Alibaba，而 80% 以上是来自各个不同组织的开发者或爱好者。这样的 Committer 分布，是加入 Apache 带给 Dubbo 社区的一个最重要的变化之一：Dubbo 项目是属于整个社区的，反映的是不同组织不同开发者的共同诉求，它的发展不是由一个公司控制或决定的，而是由社区共同讨论后决定的。如果你对参与到 Dubbo 社区感兴趣，都可以参与到 Dubbo 发展的讨论、决策和 coding 中来，也非常期待各位能成为下一个 Committer。

遇见Dubbo

Sat, 26 Jan 2019 00:00:00 +0000

我是一个有Dubbo情节的程序员。

Dubbo以不同方式，陪伴了我时间不长的整个代码生涯。不久前，通过社区投票，我被选举为Committer。当时我在朋友圈发了一句话，也是贯穿我从开始使用Dubbo、研究Dubbo、贡献Dubbo到最后成为Committer的全过程，一直为我提供内心无与伦比愉悦的源泉：成长这种事，能看见脚印特别幸福。

今天来个回忆杀，把我和Dubbo的那些事拿出来说说。

小白

我知道Dubbo，是在我大三翘课出去实习的时候，那个时候是无知的，我眼里最牛的人就是能熟练使用各种配置，精通SSH框架的人。就是在那种情况下，我外出实习，遇到了一群影响我至今的人。当时也是机缘巧合，我们进行了两个非常小的模块的服务化改造。那时的团队除了我们老大，全是一群新兵蛋子，老大指哪我们打哪。老大说，就用Dubbo吧，从那时候开始，我才知道，哦！原来还有一种东西叫做RPC，还有个阿里巴巴的RPC框架叫Dubbo。

苦于当时非常有限的水平和高强度的工作，我和Dubbo的缘分也就停留在一面之缘的程度——要说认识谈不上，说不认识也牵强。

Contributor

我在二维火任职的一年算是我Dubbo生涯里承上启下的一年。二维火当时自己维护了一个Dubbo的分支，有一群对Dubbo非常了解的人。那时候，工作结束搞Dubbo，周六加班研究Dubbo。看源码，看不懂就debug一下，debug也不明白就问，问人，问google，里外折腾了个遍。

后来毕业加入网易云音乐。大概是今年五月份的时候，我发现了一个Dubbo的小bug，并且给Dubbo提交了pull request。在第一次被merge之后，非常受鼓舞，这才有了后续的故事。后来，回看这第一次提交，真的算是我和Dubbo的一个拐点，拐弯之后，我才逐渐走上一条成为Committer的路。

可能很多人看到这里要望而却步了，这也是做开源给很多人留下的固有的印象——是不是没发现BUG就不能提交pull request，不能做贡献？其实完全不是的，这里给大家敲黑板划重点：其实很多贡献者的第一次贡献，贡献的并非代码，而是文档修改或者单元测试。相比于BUG或者新的Feature，单测和文档上的修复门槛就比较低了。

我自己的方法论就是：先尝试增加单元测试，写单测的时候顺手debug+看代码。或者多看文档，了解框架的同时，发现错别字、语意不明或者文档上的链接干脆点不开的情况，直接提交PR到对应的仓库。

万事开头难。第一次被merge代码，你就可以成为一个Contributor了。Contributor很多，但是Committer很少，下面继续说怎么从一个Contributor成长为独当一面的Committer。

Committer

做开源和写代码一样，都不是一朝一夕的事情，而是量变促成质变的过程。这是一个没捷径可走的过程，欲带皇冠必承其重。身后的Dubbo功底自不必多说，这个部分主要是想跟大家说一下除了钻研和热爱之外，其他需要注意的地方。

首先是多提交高质量PR。任何一个PR都会被review，代码中的问题，思路上的偏差，都会被指正。提交PR是一个反复琢磨的过程。PR的质量不能简单的归结于新增了多少行代码，高质量的PR一定是经过缜密思考的，为什么删除代码，新增的代码有什么意义，修改之后有什么效果等等。希望大家更加重视质量而非数量，眼光放长远，相信你的收获一定会非常大！

第二个就是，我们需要培养一种思维方式——Apache Way。一句话概括就是社区重于代码。Apache是一个注重社区的的开源组织，其行为方式相比于目前我们的开发方式，还是有所不同，这里我举一个Apache Way的例子，用以说明传统方式相较于Apache Way的区别在哪里，这里假设我想为Dubbo开发一个功能A。

Old Way：

功能设计：做一个设计文档（根据功能大小而定），大概划定需要修改或新增的类，大体设计接口等。
开发代码。
提交PR。
Review & Merge

可以看到，我们整个过程中，真正与社区交互的只有最后一步。

Apache Way：

功能设计：发送邮件至mailing list并且提交ISSUE，与社区成员共同探讨，产出一个设计文档（根据功能大小而定），大概划定需要修改或新增的类，大体设计接口等。然后再次发送邮件并且回复ISSUE，通知社区设计文档定稿或者方案确定。
开发代码：发送邮件至社区，通知社区成员我即将投入开发功能A，如需帮助，可以同时说明需要协助。
提交PR：发送邮件并且回复ISSUE，提醒社区开发结束，贴上PR地址以通知社区review代码。
Review + Merge后，发送邮件并且关闭ISSUE，通知社区功能A的开发功能告一段落。

可以看到，Apache Way就是在整个开发过程中，不断地与社区交互，最大发挥社区的功能，汲取众人之力，这才是所谓社区以及所谓开源的含义。

结尾

Dubbo目前还在孵化阶段，整个Dubbo社区还不完善，我们也在跟着Dubbo一起成长，我们非常希望更多的Dubbo爱好者深度参与到Dubbo中，为你的代码生涯树一个里程碑。

相信过程，收获结果；天道酬勤，功不唐捐！

第五届Dubbo开发者沙龙在杭州成功举办

Mon, 10 Dec 2018 00:00:00 +0000

第五届Dubbo开发者沙龙在杭州成功举办，

分享嘉宾

李鼎: 如何参与Dubbo开源社区 slides
曹胜利: Dubbo 2.7新特性介绍及演示 slides
陶杨: Dubbo在考拉的应用实践 slides
小马哥: Dubbo+Nacos服务治理重新实现 slides
赵奕豪: Sentinel:分布式服务的流量防卫兵 slides
陈志轩: 当Dubbo遇上Arthas:排查问题的实践 slides

如何准备Apache Release

Sun, 02 Sep 2018 00:00:00 +0000

理解Apache发布的内容和流程

总的来说，Source Release是Apache关注的重点，也是发布的必须内容；而Binary Release是可选项，Dubbo可以选择是否发布二进制包到Apache仓库或者发布到Maven中央仓库。

请参考以下链接，找到更多关于ASF的发布指南:

本地构建环境准备

主要包括签名工具、Maven仓库认证相关准备

安装GPG

详细文档请参见这里, Mac OS下配置如下

$ brew install gpg
$ gpg --version #检查版本，应该为2.x

用gpg生成key

根据提示，生成key

$ gpg --full-gen-key
gpg (GnuPG) 2.0.12; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
 (1) RSA and RSA (default)
 (2) DSA and Elgamal
 (3) DSA (sign only)
 (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
 0 = key does not expire
 <n> = key expires in n days
 <n>w = key expires in n weeks
 <n>m = key expires in n months
 <n>y = key expires in n years
Key is valid for? (0) 
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Robert Burrell Donkin
Email address: rdonkin@apache.org
Comment: CODE SIGNING KEY
You selected this USER-ID:
 "Robert Burrell Donkin (CODE SIGNING KEY) <rdonkin@apache.org>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key. # 填入密码，以后打包过程中会经常用到

查看key id

$ gpg --list-keys
pub rsa4096/28681CB1 2018-04-26 # 28681CB1就是key id
uid [ultimate] liujun (apache-dubbo) <liujun@apache.org>
sub rsa4096/D3D6984B 2018-04-26

# 通过key id发送public key到keyserver
$ gpg --keyserver pgpkeys.mit.edu --send-key 28681CB1
# 其中，pgpkeys.mit.edu为随意挑选的keyserver，keyserver列表为：https://sks-keyservers.net/status/，为相互之间是自动同步的，选任意一个都可以。

如果有多个public key，设置默认key。修改~/.gnupg/gpg.conf

第四届Dubbo开发者沙龙于8月26日在成都举行

Sun, 26 Aug 2018 00:00:00 +0000

用户深度沟通交流

8.26上午10:00-12:00，邀请到货车帮，云图金控，前BBD，飞鱼星四家公司开源爱好者及重度用户参与面对面交流；据参与者反馈，解答了对Dubbo的诸多疑惑，特别是如何参与贡献社区，以及捐献代码所带来的价值点。希望后面可以更加深入参与Dubbo社区及活动中。

meetup活动信息

本次活动依旧爆满，总报名人数976，现场用户350+，直播PV 13207。

报名信息

Aliware Open Source•成都站-Apache Dubbo开发者沙龙于8月26日(周日)在成都高新区天府五街200号菁蓉国际广场8号楼2楼会议厅举办，技术GG们的思想盛宴，干货与福利一个都不会少。

报名链接：http://www.huodongxing.com/event/7453091088400

第三届Dubbo开发者沙龙在深圳成功举办

Mon, 30 Jul 2018 00:00:00 +0000

第三届Dubbo开发者沙龙在深圳成功举办，超过2000位开发者报名，现场参与人数700+，通过阿里云天池、云栖社区、大咖说引导线上直播观看次数17000+

分享嘉宾

陈志轩: Dubbo开源现状和2.7规划
康彬: 乐信集团的微服务化之路
林佳梁: Sentinel——企业用户的全方位流量哨兵

第二届Dubbo开发者沙龙在上海成功举办

Sat, 23 Jun 2018 00:00:00 +0000

第二届Dubbo开发者沙龙在上海成功举办，超过700位开发者报名，现场参与人数300+，通过阿里云天池、云栖社区、大咖说引导线上直播观看次数10000+

分享嘉宾及PPT:

朱勇: Dubbo开源现状与未来规划 (中文) slides
小马哥: Dubbo Cloud Native 之路的实践与思考 (中文) slides
郭平: Nacos - 贡献Dubbo生态，阿里巴巴注册中心和配置中心开源计划 (中文) slides
潘志伟: Dubbo在互金行业的应用场景 (中文) slides

首届Dubbo开发者沙龙在北京成功举办

Sat, 12 May 2018 00:00:00 +0000

首届Dubbo开发者沙龙在北京成功举办, 超过400位开发者参加。这是一个很好的开始！

分享嘉宾及主体如下：

罗毅: Dubbo 的现状现状与未来规划 PDF
刘军: 第四届阿里中间件性能挑战赛 PDF
陈志轩: 通过 Dubbo 和 Spring-boot 快速构建微服务 PDF
王欣: Dubbo 和微店的服务化实践历程分享 PDF

ApacheCon NA 大会议程公布

Wed, 02 May 2018 00:00:00 +0000

罗毅/刘军将在蒙特利尔举办的 ApacheCon 大会上进行题为"Introducing Apache Dubbo(Incubating): What is Dubbo and How it Works"的演讲。请点击此处查看大会议程，并在此处中进行注册。

谷歌编程之夏会议上2018个项目被宣布

Wed, 25 Apr 2018 00:00:00 +0000

谷歌编程之夏会议上2018个项目被宣布, Raghu Reddy 的项目"Apache Dubbo 扩展串行协议支持" 被接受! 祝贺他!

在DockerHub发布Dubbo Admin镜像

Mon, 23 Apr 2018 00:00:00 +0000

Dubbo Admin是Dubbo的服务治理中心，提供了大量日常运维所需的服务治理、配置管理等功能。

Dubbo Admin同时包含了前端代码和后端代码，如果用户需要自己下载源码并编译打包，需要花费一定时间。特别是对于一些希望快速调研和试用Dubbo Admin的用户，这种流程的体验并不是很好。

Docker是一个开源的应用容器引擎，让开发者可以打包应用以及依赖包到一个可移植的镜像中，社区对于提供Dubbo Admin镜像的呼声较高。 Docker官方维护了一个公共仓库DockerHub，该仓库还有很多国内镜像，访问速度快，将Dubbo Admin镜像发布到DockerHub是一个较好的选择。

DockerHub账号申请

要在DockerHub上发布镜像，自然需要对应的账号。而DockerHub有两种常见账号，一种是面向个人的，一种是面向组织的。Apache在DockerHub上有一个组织账号¹。自然我们首选是发布在组织账号下。

DockerHub对于组织账号的管理是基于组的，也就是一个组织账号下有多个组，每个组有不同的成员，而一个组可以管理一个或者多个镜像。

所以要做的第一步就是申请权限，这个需要提一个issue给Apache Infrastructure团队，申请DockerHub的镜像仓库和组权限。目前镜像和组已经申请好了，只需要申请组的权限就行了，可以参考之前的申请²。

申请完权限以后使用Apache账号登陆应该就可以看到对应的镜像和配置选项了。

添加新的构建规则

发布镜像到DockerHub有两种办法，一种是本地构建好镜像以后远程push到DockerHub，另外一种是提供Dockerfile并借助DockerHub提供的构建功能直接在DockerHub构建。后者明显操作性和便捷性要好很多，目前Dubbo Admin的镜像也是这样构建发布的。

当Dubbo Admin有新版本发布以后，需要在项目的docker目录新增一个Dockerfile文件，可以参考目前0.1.0版本的Dockerfile³，其中的配置根据具体的版本可能有细微差别，但是大致上是一致的。

在添加了Dockerfile之后，进入DockerHub对应的管理界面新增Build Rules

根据实际情况填写即可。这里需要注意两点：

latest 版本要和最新的版本配置一致
不要勾选Autobuild

勾选Autobuild会导致每次git提交都会触发自动构建，但是由于Dubbo Admin不提供snapshot的Docker镜像，所以只有发布新版本的时候才需要构建发布。

修改以后点Save，然后手动触发构建即可。

总结

总的来说DockerHub上发布镜像的步骤并不复杂，如果已经申请过权限的话，操作起来是很流畅的。

另外DockerHub的构建是需要排队的，有时候会遇到长时间没有开始构建的情况，需要耐心等待。

Dubbo路线图在QCon Beijing 2018上公布

Sun, 22 Apr 2018 00:00:00 +0000

罗毅在Qcon Beijing 2018上进行了Dubbo开源现状及未来规划的主题演讲。详细内容请查看幻灯片。

如何参与贡献Dubbo社区

Sun, 11 Mar 2018 00:00:00 +0000

前言

本文首次分享是在Apache Dubbo成都meetup上，这个话题是第一次在meetup上讲，不是我们没有更好的话题，相反，我们认为这个话题非常重要，甚至建议这个话题以后每次meetup都要讲。

Dubbo的发展历史大家应该并不陌生了，这里我还是简单回顾一下。Dubbo于2011年在github开源，后面几年由于一些原因停止了维护，直接去年7月份阿里重启维护，并于2018年2月16日捐献给Apache。

为什么会选择捐献给Apache，主要是为了打消社区对Dubbo未来发展的顾虑，给Dubbo用户足够的信心；Apache认为社区大于代码，非常注重多样性，强调一个项目需要有多个公司和个人贡献者参与，现在Dubbo的发展完全是按The Apache Way社区化的方式来运作的。

Apache的诞生

说到Apache，大家都非常熟悉了，它是全球目前最大的软件基金；Apache的很多项目我们都用过，比如Maven、Log4j、Tomcat等，但有一个项目要特别强调的，那就是 Apache httpd server，这是Apache的第一个项目。

Apache软件基金会正式创建于1999年，主要是为公众提供有用的免费软件，并为软件开发者社区提供支持和服务；它的创建者是一个自称为Apache组织的群体；

早在1995年，这个组织就存在了，他们聚集在一起，在美国伊利诺伊大学超级计算机应用程序国家中心开发的NCSA HTTPd服务器的基础上开发与维护了一个叫Apache的HTTP服务器。

最早NCSA HTTPd服务器是一个叫Rob McCool的人开发的，但是后来慢慢失去了兴趣，导致这个功能强大又好用的服务器没人维护；于是一些爱好者和用户就自发开始维护起来，并不断改善功能、发布版本；为了更好进行沟通，一哥们就创建了一个邮件组，并把维护工作高效组织起来，且自称是Apache组织，并把这个软件叫Apache 服务器。

这也是为什么Apache的所有的项目到今天为止依然以邮件列表作为沟通的主要方式。

关于Apache的命名来源，从北美当地的一支叫Apache的印第安部落名称而来，这支部落以高超的军事素养和超人的忍耐力著称，19世纪后半期对侵占他们领土的入侵者进行了反抗；为了对这支部落表示敬仰，就取了这个名字；但这里还流传着一个小故事，说是在NCSA HTTPd基础上，大家都通过打补丁不断在修改这个软件，被戏称为A Patchy Server，和Apache Server读音很像。

随着后来商业需求扩大，围绕Apache HTTP服务器的项目越来越多，后来越来越多的项目启动，也有很多外部组织捐献项目；为了让这些外部项目能顺利进入到Apache基金会，2002年创建了Incubator（孵化）项目。可以看到，经过10多年的发展，到2010年，75个顶级项目，30个孵化项目，每天2697封讨论邮件；2018年这个数据进一步增长，194个顶级项目，54个孵化项目，3255个committers；其中中国人主导的项目，有RocketMQ，WeeX，ECharts，Skywalking等。

Dubbo正在成为Apache顶级项目的路上——Apache孵化项目中。

回顾一下Apache这些历史和数据，我们不难发现几个关键词：兴趣、参与、邮件；这些就是我们后面要重点介绍的The Apache Way。

ASF组织架构

我们知道每个组织都有它自己的架构，ASF同样也不例外；那Apache的组织架构是什么样的呢？它有什么独特的地方吗？这里特别要强调的是Project Management Committees，即 PMC，每个项目从孵化阶段开始就会有PMC，主要负责保证开源项目的社区活动都能运转良好，这里运转的机制就是The Apache Way。

图中，Board就是负责整个基金会符合章程的运作。Board我们一般很少能接触到，接触更多的是PMC以及下面的这几层。

参与Apache项目社区活动的人，一般分为以下几类：

直接用户：在座的都是Dubbo的用户，可能部分现在还不是，但将来肯定会是
贡献者：部分用户在使用Dubbo过程中，遇到问题，自己通过分析调试找到解决方案，并提交给Dubbo官方，最终被接受，这些用户就是Dubbo的贡献者
提交者：贡献多了，经过PMC的提议和投票，就会成为Committer；Committer即意味着正式加入Apache，拥有个人Apache帐号以及相应项目的写权限
PMC：Committer再往上走就是PMC，这个必须由现有PMC成员提名

个人在社区的成长，就像我们在公司晋升一样，一步一步往上走。

本文的目的就是告诉大家，从User到Contributor没有大家想像的那么难，从Contributor到Committer也不是不可能；只要大家拥有一颗开源的心，找到自己感兴趣的项目，并持续投入，付出肯定会有回报。

The Apache Way

就像你加入一家公司需要了解这家公司的文化一样，参与Apache开源项目之前，同样我们需要需要了解ASF的文化，这个文化就称为The Apache Way。

这里想特别强调以下几点：

社区胜于代码：把项目构建出来这不是开源，去构建社区才是真正的开源；对社区而言，一切都是围绕代码而生，无代码则社区不复存在；在代码之上，则是如何做事、如何待人、如何决策的理念体现；一个健康的社区远比优秀的代码重要——如果代码奇烂无比，社区可以重写，但社区有了毛病，代码最终也会付之东流；
公开透明与共识决策：If it doesn't happen on email, it doesn't happen. 所有的决定，不管是技术feature、发展方向，还是版本发布等，都应该被公开讨论，而形式就是邮件列表，这些讨论过程和结论都会被永久存档；而讨论的过程，就是大家自由发表意见的过程，但最终大家要投票，比较民主的做法；
任人唯贤：Those that have proven they can do, get to do more. 特别强调一点，贡献绝不仅仅是代码，贡献可以是很多方面，接下来我们结合Dubbo来讲，大家如何参与并贡献；