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

本文讲述前端 http 流量接入后端 Dubbo 微服务的的基本架构,包括移动端、浏览器、桌面应用、异构的微服务体系等。

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

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

中心化接入方式

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

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

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

去中心化接入方式

与中心化架构相比,此方式并没有太大的差异,唯一的区别在于不需要额外的 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) (1a4b998f54)