HTTP流量接入 on Apache Dubbo

前端 http 流量接入 Dubbo 后端微服务体系的基础架构

Mon, 01 Jan 0001 00:00:00 +0000

不论你开发的是什么样的产品（电子商城、管理系统、手机 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 请求。

通过网关将 http 流量接入 Dubbo 后端服务

Mon, 01 Jan 0001 00:00:00 +0000

由于 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: dubbo
 port: 20880
 ext-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 网关都可以非常容易接入，操作非常简洁明了。

通过网关将 http 流量接入 Dubbo 后端服务

Mon, 01 Jan 0001 00:00:00 +0000

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

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

接下来我们就看一下，对于前端 HTTP 流量而言，如何通过一些通用的网关产品快速接入后端的 triple 微服务体系。

注意

使用 triple 协议后，不再需要泛化调用、http -> dubbo 协议转换等步骤，任何主流的网关设备都可以通过 http 流量直接访问后端 triple 协议服务。具体参见发布 REST 风格的服务

原生 HTTP 接入

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

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

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