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

本文讲述前端 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 请求。

总结

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

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

最后修改 September 13, 2024: Refactor website structure (#2860) (1a4b998f54b)