当前位置：首页 > news >正文

Dubbo3 服务原生支持 http 访问，兼具高性能与易用性

news 2025/7/9 0:24:40

作者：刘军

作为一款 rpc 框架，Dubbo 的优势是后端服务的高性能的通信、面向接口的易用性，而它带来的弊端则是 rpc 接口的测试与前端流量接入成本较高，我们需要专门的工具或协议转换才能实现后端服务调用。这个现状在 Dubbo3 中得到了彻底解决，Dubbo 3.3 版本的最新 triple 协议，在持续提供高性能通信、面向接口易用性的同时，支持 http application/json 格式访问，大幅简化了开发测试、入口流量接入成本。

curl \--header "Content-Type: application/json" \--data '["Dubbo"]' \http://localhost:50051/com.example.demo.dubbo.api.DemoService/sayHello/

本文我们就以网关 http 流量接入为例，围绕这个新特性升级展开讲解。

实现 http 接入后端 dubbo 微服务

不论你开发的是什么样的产品（电子商城、管理系统、手机 app 等），绝大多数下产品的流量入口都会是 http，用户可能通过浏览器、手机移动设备、桌面软件等来访问产品。在这种情况下，如何将后端开发的 Dubbo 微服务集群接入前端访问设备就成为一个需要解决的问题，其实也就是 http 与 rpc 之间的转换与连接问题。

总的来说，有中心化和去中心化两种架构模式。其中，中心化接入模式更具通用性，对后端 rpc 协议、前端网关没有太多特殊要求，但保证中心化应用的性能、稳定性是一个较大的挑战；去中心化模式由于不需要维护入口应用，因此可适应更大流量、更大规模的集群。

中心化接入方式

中心化接入方式的架构图如下：

在后端服务与前端设备之间有一层网关，负责流量过滤、路由、限流等流量管理工作。
在后端集群中有一个连接 http 与 dubbo 服务的 “统一微服务入口应用”（通常也叫做 BFF，即 Backend for Frontend）。

BFF 应用通常可以使用 Spring Web 等常用框架开发，应用发布一系列的 http 服务，接收网关或前端设备流量，同时负责按需发起 dubbo 调用。

dubbo、triple 协议都支持这种接入架构。另外，在配置 BFF 应用调用 dubbo 服务时，可以使用普通的 dubbo 配置方式，也可以使用泛化调用等方式：

配置接入 dubbo 协议时，使用泛化调用的优势是可以避免对服务二进制包的依赖，实现配置动态生效的效果。
配置接入 triple 协议时，可以使用 http 调用方式，同样可避免对服务二进制包的依赖，实现配置动态生效的效果。

去中心化接入方式

与中心化架构相比，此方式并没有太大的差异，唯一的区别在于不需要额外的 BFF 应用，我们可以在网关直接调用后端 dubbo 服务。

但这种方式对网关有特别要求。如果后端是 dubbo 协议的话，则要求网关具备 http -> dubbo 协议转换的能力，但你会在接下来的文档中发现，我们可以通过多协议发布绕过协议转换，让网关直接通过 http 访问后端服务；如果后端是 triple 协议，就会更简单了，因为 triple 协议支持 application/json 格式的 http 请求。

使用不同的 rpc 协议也会影响架构选择，triple 协议由于原生支持 HTTP 访问，因此对两种架构方式都可以无差别支持，并且接入原理上也会更简单直接。而 dubbo 协议作为 Dubbo2 时代主推的协议，由于是基于 tcp 的二进制协议，因此在接入方式上存在一些不同。

我们将在接下来的两篇文档中介绍 dubbo、triple 两种协议的具体前端流量接入方式，文档同样适用于中心化、去中心化架构。

不同 rpc 协议接入示例详解

dubbo 协议接入方式

由于 dubbo 协议是基于 TCP 的二进制私有协议，因此更适合作为后端微服务间的高效 RPC 通信协议，这也导致 dubbo 协议对于前端流量接入不是很友好。在 Dubbo 框架中，有两种方式可以帮助开发者解决这个问题：

多协议发布【推荐】 ，为 dubbo 协议服务暴露 rest 风格的 http 协议访问方式，这种模式架构上会变得非常简单，通用的网关产品即可支持。
通过网关实现 http->dubbo 协议转换，这种方式需要将 http 协议转换为后端服务能识别的 dubbo 协议，要求网关必须支持 dubbo 协议。

同时发布 http、dubbo 协议

如果我们能让一个服务同时发布 dubbo、http 协议，这样后端调用是基于高效的 dubbo 二进制协议，同时浏览器、web服务等前端设施也可以用 http 协议访问到相同的服务。好消息是，Dubbo 框架支持为同一个服务发布多个协议，并且支持客户端通过同一个端口以不同的协议访问服务，如下所示：

为了实现同时发布 dubbo、http 协议，我们只需要在配置文件中增加一行配置即可：

dubbo:protocol:dubbo: dubboport: 20880ext-protocol: tri

增加 ext-protocol: tri 配置后，进程就可以在 20880 端口上提供 http 服务了，这点我们从之前的 triple 协议中有过具体了解了，启用应用后就可以在 20880 端口访问：

curl \--header "Content-Type: application/json" \--data '["Dubbo"]' \http://localhost:20880/org.apache.dubbo.protocol.multiple.demo.DemoService/sayHello

此时，网关就可以直接以 http 方式接入后端 dubbo 服务，任何 http 网关都可以非常容易接入，操作非常简洁明了。

另外，关于 dubbo、triple 多协议发布的完整示例源码和讲解可参见 apache/dubbo-samples 示例仓库。

如果你对 /org.apache.dubbo.protocol.multiple.demo.DemoService/sayHello 格式的前端访问路径不满意，可以选择发布 rest 风格的 http 接口，我们只需要在接口上增加注解即可（目前支持 Spring Web、JAX-RS 两种注解）。如下所示，假设我们已经有一个名为 DemoService 的 dubbo 服务，只需要增加以下注解：

@RestController
@RequestMapping("/triple")
public interface DemoService {@GetMapping(value = "/demo")String sayHello();
}

这样，就能发布同时支持 dubbo、rest 两种协议的服务，对于 http 网关接入更为简单便捷，唯一成本是需要改造接口增加注解。

为 dubbo 协议服务增加了 http 访问方式之后，就可以很容易的将 dubbo 服务接入网关了。

http 转 dubbo 协议

如果您使用的是 Dubbo 3.3.x 版本，在决定考虑此方案之前，我们强烈推荐您仔细评估本文前一节的多协议发布方案。除非您因为某些特殊原因真的无法接受多协议发布带来的应用改造成本（实际上只是改一行配置而已），否则这个方案应该作为第二选择。

如果要从网关接入后端 dubbo 服务，则前端的 HTTP 流量要经过一层 http -> dubbo 的协议转换才能实现正常调用。

如上图所示，从浏览器、手机或者 Web 服务器发送的 HTTP 请求，经过网关进行 http 到 dubbo 协议转换，网关最终转发 dubbo 协议到后端微服务集群。因此，我们需要一个支持 dubbo 协议转换的网关，来帮助实现协议转发，以下是该架构下网关需要实现的几个关键点：

协议转换，支持 http 到 dubbo 的协议转换，包括参数映射。
自动地址发现，支持 Nacos、Zookeeper、Kubernetes 等主流注册中心，动态感知后端 dubbo 实例变化。
结合 dubbo 协议的路由，如在发起 dubbo 协议调用时，支持按照特定规则地址筛选、传递附加参数到 dubbo 后端服务。

目前市面上支持 dubbo 协议接入、且对以上三点提供比较完善支持的开源网关产品众多，包括大家 Higress、Apache APISIX、Apache Shenyu 等。接下来，让我们通过一些示例来了解网关产品搭配 Dubbo 的具体使用方法吧：

Higress
Apache APISIX
Apache Shenyu

triple 协议接入方式

在官网 triple 协议规范中我们曾详细介绍了 triple 对于浏览器、网关的友好性设计，其中非常重要的一点是 triple 同时支持跑在 HTTP/1、HTTP/2 上：

在后端服务之间使用高效的 triple 二进制协议。
对于前端接入层，则支持所有标准 HTTP 工具如 cURL 等以标准 application/json 格式请求后端服务。

接下来我们就看一下，对于前端 HTTP 流量而言，如何通过一些通用的网关产品快速接入后端的 triple 微服务体系。相比于上一节介绍的 dubbo 协议，使用 triple 协议后，不再需要泛化调用、http -> dubbo 协议转换等步骤，任何主流的网关设备都可以通过 http 流量直接访问后端 triple 协议服务。

原生 HTTP 接入

如上图所示，从浏览器、手机或 Web 服务器过来的 HTTP 请求，网关可直接以 application/json 格式转发给后端 Dubbo 服务，后端服务之间则继续走 triple 二进制协议。由于进出网关的都是标准的 HTTP 流量，网关不需要做任何的私有协议转换工作，不需要任何定制化逻辑，只需专注于流量路由等职责即可。

在真正的生产环境下，唯一需要网关解决的只剩下地址发现问题，即如何动态感知后端 triple 服务的实例变化？ 好消息是，目前几款主流的开源网关产品如 Apache APISIX、Higress 等普遍支持以 Nacos、Zookeeper、Kubernetes 作为 upstream 数据源。

以下我们以 Higress + Nacos + Dubbo 的典型用法为例，详细说明整套机制的工作流程。

启动示例应用

本示例完整源码请参见 apache/dubbo-samples 中的 dubbo-samples-gateway-higress-triple 示例。

该示例中定义并发布了一个定义为 org.apache.dubbo.samples.gateway.api.DemoService 的 triple 服务：

public interface DemoService {String sayHello(String name);
}

接下来，我们演示如何启动 Dubbo 服务，并使用 Higress 网关转发请求到后端服务。

接入 Higress 网关

接下来，我们具体演示 Higress 网关接入应用的具体步骤。包括部署 Dubbo 应用、Nacos 注册中心、Higress 网关等。

安装 Higress 和 Nacos

以下示例部署在 Kubernetes 环境，因此请确保您已经连接到一个可用 Kubernetes 集群。

安装 Higress，参考 Higress 安装部署文档
安装 Nacos，运行

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/2-advanced/dubbo-samples-gateway/dubbo-samples-gateway-higress/dubbo-samples-gateway-higress-triple/deploy/nacos/Nacos.yaml

启动 Dubbo 应用

将以上示例应用打包为 docker image 后（这里我们使用官方示例提前打包好的镜像），以标准 Kubernetes Deployment 形式启动应用：

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/2-advanced/dubbo-samples-gateway/dubbo-samples-gateway-higress/dubbo-samples-gateway-higress-triple/deploy/provider/Deployment.yaml

具体的部署文件定义如下：

apiVersion: apps/v1
kind: Deployment
metadata:name: gateway-higress-triple-providernamespace: defaultlabels:app: gateway-higress-triple-provider
spec:replicas: 1selector:matchLabels:app: gateway-higress-triple-providertemplate:metadata:labels:app: gateway-higress-triple-providerspec:containers:-   name: gateway-higress-triple-providerimage: docker.io/allenyi/higress-triple:2.0.0imagePullPolicy: IfNotPresentports:# 与容器暴露的端口一致- containerPort: 50052env:# 配置Nacos注册中心地址，对应Dubbo服务配置中的${nacos.address:127.0.0.1}- name: NACOS_ADDRESSvalue: nacos-server.default.svc.cluster.local

通过 Higress 转发请求到 Dubbo 服务

Higress 可以通过 McpBridge 来对接 Nacos 作为服务来源，在 K8s 集群中 apply 以下资源来配置 McpBridge：

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/2-advanced/dubbo-samples-gateway/dubbo-samples-gateway-higress/dubbo-samples-gateway-higress-triple/deploy/mcp/mcpbridge.yaml

以上安装的 McpBridge 资源的具体定义如下：

apiVersion: networking.higress.io/v1
kind: McpBridge
metadata:name: nacos-service-resourcenamespace: higress-system
spec:registries:- domain: nacos-server.default.svc.cluster.localnacosGroups:- DEFAULT_GROUPname: nacos-service-resourceport: 8848type: nacos2

更多详细配置参考 Higress McpBridge 配置说明。

接下来我们创建如下 Ingress，从而创建一条指向 Dubbo 服务的 HTTP 路由：

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/2-advanced/dubbo-samples-gateway/dubbo-samples-gateway-higress/dubbo-samples-gateway-higress-triple/deploy/ingress/Ingress.yaml

这样，path 前缀为 /org.apache.dubbo.samples.gateway.api.DemoService 的请求就会被路由到我们刚刚创建的 Dubbo 服务上。

以上 apply 安装的具体资源定义如下：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:annotations:higress.io/destination: gateway-higress-triple-provider.DEFAULT-GROUP.public.nacosname: demonamespace: default #与应用部署namespace保持一致
spec:ingressClassName: higressrules:- http:paths:- backend:resource:apiGroup: networking.higress.iokind: McpBridgename: defaultpath: /org.apache.dubbo.samples.gateway.api.DemoServicepathType: Prefix

注意这里通过注解 higress.io/destination 指定路由最终要转发到的目标服务：gateway-higress-triple-provider，gateway-higress-triple-provider 为刚刚启动 Dubbo 服务的应用名（这里依赖 Dubbo3 默认注册的应用粒度地址列表）。对于 Nacos 来源的服务，这里的目标服务格式为：“服务名称.服务分组.命名空间ID.nacos”，注意这里需要遵循 DNS 域名格式，因此服务分组中的下划线’_‘被转换成了横杠’-'。命名空间未指定时，这里默认值为"public"。

更多流量治理相关配置参考官网《Ingress Annotation 配置说明》和《通过 Ingress Annotation 实现高阶流量治理》。

请求验证

通过 cURL 访问 Higress，可以实现对 triple 后端服务的调用：

$ curl "localhost/org.apache.dubbo.samples.gateway.api.DemoService/sayHello?name=HigressTriple""Hello HigressTriple"

这里要运行 kubectl port-forward service/higress-gateway -n higress-system 80:80 443:443 将集群内的 Higress 暴露出来才可访问。

/org.apache.dubbo.samples.gateway.api.DemoService/sayHello/ 这种根据 Java 路径名与方法直接暴露的访问路径，虽然可以很容易调通，但对于前端来说并不友好。接下来我们一起看一下如何发布 REST 风格的 HTTP 服务。

REST 风格接口

在前面的示例中，如类似 http://127.0.0.1:9080/triple/demo/hello 会是更符合前端使用的访问方式，要做到这一点，我们可以通过在 Higress 等网关配置 uri rewrite 重写，实现前端 /triple/demo/hello 到后端 /org.apache.dubbo.samples.gateway.api.DemoService/sayHello/ 的映射。

除了配置网关 rewrite 重新规则之外，Dubbo 框架还为 triple 服务暴露 REST 风格的 HTTP 访问路径提供了内置支持，具体使用方式取决于你使用的是基于 “protobuf 的服务定义模式”，还是基于 “java 接口的服务定义模式”：

Java 接口模式（大部分 dubbo java 用户选择），通过直接为 java 接口增加注解可以同时发布 REST 风格服务，目前支持 Spring Web 与 JAX-RS 两套注解标准。
Protobuf 模式，通过使用 grpc-gateway 可发布 REST 风格服务。

为服务定义增加注解

通过为 Java 接口增加以下任意一种注解，即可发布 triple 二进制、REST 风格的服务。这样配置之后，对于同一个服务，你既可以使用标准二进制 triple 格式访问服务，也可以使用 REST HTTP 方式以 JSON 格式访问服务。

Spring Web 风格注解：

@RequestMapping("/triple/demo")
public interface DemoService {@RequestMapping(method = RequestMethod.GET, value = "/hello")String sayHello(@RequestParam("name") String name);}

在之前的示例 apache/dubbo-samples/tree/master/2-advanced/dubbo-samples-gateway/dubbo-samples-gateway-higress/dubbo-samples-gateway-higress-triple 中已经启用，可查看源码了解实际用法。

这时我们的路由前缀配置如下，Nacos 地址配置与之前保持一致，path 前缀改为访问更为友好的 /triple/demo：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:annotations:higress.io/destination: gateway-higress-triple-provider.DEFAULT-GROUP.public.nacosname: demonamespace: default
spec:ingressClassName: higressrules:- http:paths:- backend:resource:apiGroup: networking.higress.iokind: McpBridgename: defaultpath: /triple/demopathType: Prefix

可以使用 /triple/demo/hello 访问服务：

$ curl "localhost/triple/demo/hello?name=HigressTriple""Hello HigressTriple"

总结

本文展示了 Dubbo3 triple 协议是如何简化从协议规范与实现上简化开发测试、入口流量接入成本的，同时提供高性能通信、面向接口的易用性编码。关于 Dubbo 3.3.0 正式版本，请持续关注社区最新动态。

本文相关参考链接请访问：https://dubbo.apache.org