你为什么会不懂微服务架构中的微服务网关模式呢？

微服务网关在微服务架构中作为HTTP请求的统一调用入口&＃xff0c;用来屏蔽和隔离内部服务实现细节&＃xff0c;保护、增强和控制对微服务的访问&＃xff0c;实现了服务之间调用关系的松散耦合&＃xff0c;增强了服务的可重用性。此外还可以将安全、灰度、熔断等公共组件和切面功能放置到网关节点&＃xff0c;实现系统的关注点分离。

在微服务架构中&＃xff0c;一个大应用被拆分为多个小的服务系统&＃xff0c;这些小的系统根据领域划分独立完成某项功能&＃xff0c;也就是说这些小系统可以拥有自己的数据库、框架甚至语言等。这些小系统通常通过REST API风格的接口供浏览器、H5、Android、iOS及第三方应用程序调用。

例如&＃xff0c;我们把商品应用拆分为四个独立的子服务&＃xff1a;商品目录服务、订单服务、付款服务、库存服务。商品目录服务使用gRPC方式对外暴露接口&＃xff0c;订单和付款服务采用REST方式&＃xff0c;而库存服务使用Dubbo方式&＃xff0c;客户进入商品页面后需要同时使用多个微服务查询当前订单的详情。

客户端直连服务端模式

下图是客户端直连服务端模式。如果客户端想查看商品目录、订单、付款、库存这些服务&＃xff0c;需要分别向这些服务的URL地址发送请求&＃xff0c;然后客户端需要根据各服务端返回的响应完成聚合。

这种模式的缺点是明显的&＃xff1a;

● 效率低下。客户端如果需要一个一键下单的功能&＃xff0c;可能会涉及与多个微服务的接口交互&＃xff0c;需要先查看商品库存、然后完成订单、最后付款。当客户端API接口粒度与后端API接口粒度不匹配时&＃xff0c;浏览器需要来回多次访问请求&＃xff0c;才能完成操作。

而浏览器与后端的微服务是通过WAN公网通信的&＃xff0c;这样带来的一个问题就是带宽的浪费。

● 协议适配问题。在这个实例中我们发现&＃xff0c;商品目录服务采用了gRPC通信协议&＃xff0c;订单、付款服务采用了REST方式的HTTP。库存服务可能是一个遗留系统&＃xff0c;采用了Dubbo框架&＃xff0c;对外暴露的是Dubbo的RPC接口。在这种情况下&＃xff0c;客户端如果想实现对不同接口的访问和对接&＃xff0c;需要分别适配不同的技术栈&＃xff0c;这本身也给前端工作带来了复杂性和非Web协议的不友好性。应用对外暴露的接口最好使用对Web友好、对防火墙友好的HTTP或者SOAP。应用内部之间的调用可以采用RPC这样的远程方法。

● 耦合性强。这种模式的另一个重大缺陷就是客户端与服务端存在接口层面的依赖&＃xff0c;服务端的技术栈和接口变化都会对调用方产生极大的影响。随着时间的推移&＃xff0c;这种依赖将束缚服务的调用方与提供方的迭代和演进&＃xff0c;这给微服务架构下的服务划分及重构都带来了难度。

● 可替代性下降。例如&＃xff0c;当前端调用方需要从浏览器迁移到移动端时&＃xff0c;在浏览器上使用的对接技术&＃xff08;Javascript对接gRPC、Javascript对接Dubbo&＃xff09;将无法迁移到移动端。

正因为客户端直连服务端模式存在如此多的问题&＃xff0c;所以在微服务架构中我们很少直接通过客户端与服务端通信。我们知道&＃xff0c;在软件开发领域有一句名言&＃xff1a;任何软件工程遇到的复杂问题都可以通过增加一个中间层来解决。下面我们看看微服务网关是如何解决这个问题的。

API网关模式

API网关模式通过在客户端和服务端之间增加一个中间层&＃xff0c;使得客户端可以在一次请求中向多个服务获取数据&＃xff0c;请求数的减少也会直接改善用户体验。如下图所示是API网关的使用图示。

首先&＃xff0c;在使用API网关模式后&＃xff0c;API网关对外屏蔽了服务的内部细节 &＃xff0c; 通 过 一 个 粗 粒 度 的 URL 可 以 实 现 一 键 下 单 服 务 &＃xff0c;如/product/order&＃xff1a;xxx。客户端对于网关的请求没有来回多轮请求&＃xff0c;你只需要对网关下发一个请求&＃xff0c;网关对外屏蔽调用多个内部微服务请求的操作细节。当完成所有服务请求后&＃xff0c;网关将各个响应进行聚合再返回给客户端&＃xff0c;减少了外网请求和响应的交互次数&＃xff0c;提高了交互的效率。由于能够对返回数据进行灵活处理&＃xff0c;API网关减少了请求往返次数&＃xff0c;从而简化了客户端的调用&＃xff0c;也提高了访问服务的性能。

其次&＃xff0c;假设每个系统使用的协议不同&＃xff0c;那么系统之间的调用或者数据传输就存在协议转换&＃xff0c;API网关可以通过内置的协议转换引擎实现多种协议的适配和转换&＃xff0c;将对外的请求统一在HTTP-REST的协议规范下。常用的处理机制通过泛化调用的方式实现协议之间的转化。实际上就是将不同的协议转换成通用协议&＃xff0c;然后将通用协议转化成本地系统能够识别的协议。这一转化工作通常由API网关完成。

第三&＃xff0c;API网关实现客户端和服务端调用关系和部署环境的解耦&＃xff0c;它向客户端隐藏了应用划分的微服务的部署版本。尽管微服务架构支持客户端直接与微服务交互&＃xff0c;但当需要交互的微服务数量较多时&＃xff0c;解耦就成为单体迈向微服务的必要工作。对于演进式架构&＃xff0c;一个服务可能同时存在多个版本&＃xff0c;对于A/B测试的场景&＃xff0c;通过在URL中增加版本号&＃xff08;例如/path/version1/xxxx&＃xff09;&＃xff0c;或者在HTTP-Head中增加版本参数的方式&＃xff0c;网关可以根据负载策略进行请求流量调节。客户端可以灵活地选择在不同场景使用不同版本的后端服务。

在微服务架构的网络拓扑中&＃xff0c;微服务网关是一个处于应用程序和服务&＃xff08;提供REST API接口服务&＃xff09;之间的中间件系统&＃xff0c;它可以用来完成管理授权、访问控制和流量限制等。REST API接口服务对调用者透明&＃xff0c;隐藏在API网关后面的业务系统可以专注于创建和构建业务逻辑&＃xff0c;服务调用者和服务提供者通过网关实现了解耦。

当然&＃xff0c;API网关作为一个高可用组件&＃xff0c;也增加了系统的复杂性和瓶颈点。我们很容易将微服务架构的API网关与SOA分布式架构的ESB系统联系起来。ESB作为服务总线也可以实现协议转换、解耦服务提供方和服务调用方&＃xff0c;ESB还有重量级的服务编排等和业务逻辑关联比较强的特性&＃xff0c;所以我们有必要说明一下API网关和ESB的区别。API网关和ESB的比较ESB 是 在 应 用 服 务 化 的 早 期 、 伴 随 着 EAI &＃xff08; EnterpriseApplication Integration&＃xff0c;企业应用集成&＃xff09;和SOA的理念而产生的。

它产生之初&＃xff0c;是一个解决服务集成问题的服务中间件。同时&＃xff0c;ESB所处理的服务是企业级的服务&＃xff0c;服务粒度比较粗&＃xff0c;它践行的是“共享”的架构模式。它的主要功能包括服务的调解和路由、消息增强、消息转换和协议转换&＃xff0c;这是它必须具备的也是具有强大优势的地方&＃xff0c;消息队列的处理、大数据的传输更是它的强项。总之&＃xff0c;ESB是一种集中式的服务总线方式&＃xff0c;可以以最小的代价把竖井式架构的应用改造成面向服务的架构。但由于通过ESB暴露出来的服务以紧耦合的方式固化在竖井应用中&＃xff0c;其服务的柔性比较差&＃xff0c;服务更改的代价比较大&＃xff0c;导致ESB暴露的服务可能无法快速适应需求的变化。

API网关是伴随着微服务的广泛使用而产生和发展的&＃xff0c;API网关是为了协调单体应用拆分后的众多微服务而产生的。

API网关主要完成微服务集成、服务路由、灰度发布、流量控制等非业务属性公共功能&＃xff0c;对于业务属性比较强的服务调配编排、消息增强转换、业务规则管理等功能就不是微服务网关要考虑的事情&＃xff0c;而是由微服务自行处理。而微服务应用下各个微服务之间的异步数据传输依旧需要单独的消息处理软件用发布订阅机制来进行处理&＃xff0c;比如使用Kafka、RabbitMQ等消息中间件。

微服务的最初目的不是功能的重用&＃xff0c;而是适合小团队自主开发&＃xff0c;达到敏捷开发、敏捷发布的目的&＃xff0c;以缩短软件上市周期&＃xff0c;所以它强调独立。而API网关作为单一入口&＃xff0c;通过请求适配整合后台微服务体系&＃xff0c;面向各种客户端提供统一服务请求。

API网关的一个问题就是中心化的架构问题&＃xff0c;我们需要考虑不同的前端、不同的业务团队&＃xff0c;可能对网关存在隔离性的需求&＃xff0c;在发布、部署、可用性方面&＃xff0c;如何设计一个去中心化的网关系统也是实施微服务架构需要考虑的。

BFF网关模式

BFF全称是Backends For Frontends&＃xff08;服务于前端的后端&＃xff09;。BFF是指在设计API时为不同的设备提供不同的API接口&＃xff0c;虽然它们可能实现相同的功能&＃xff0c;但因为不同设备的特殊性&＃xff0c;需要区别处理。如下图所示是BFF网关模式的示例。

客户端都不直接访问服务端的公共接口&＃xff0c;而是调用BFF层提供的接口&＃xff0c;BFF层再调用基层的公共服务。不同的客户端拥有不同的BFF层&＃xff0c;它们为客户端提供定制化的API接口。我们可以认为BFF是一种适配服务&＃xff0c;将后端的微服务进行适配&＃xff08;主要包括聚合裁剪和格式适配等&＃xff09;&＃xff0c;向无线设备暴露友好和统一的API&＃xff0c;方便无线设备访问后端服务。

采用BFF网关模式能够满足因不同客户端特殊的交互引起的对新接口的要求&＃xff0c;所以一开始就会针对相应的设备设计好对应的接口。从职责分配上来说&＃xff0c;BFF网关模式每一层的功能更加清晰&＃xff0c;网关&＃xff08;一般由独立框架团队负责运维&＃xff09;专注跨横切面&＃xff08;Cross-Cutting Concerns&＃xff09;的功能&＃xff0c;使用相同的技术栈和公共类库&＃xff1b;而BFF层主要是适配层&＃xff0c;BFF层的开发人员可以更加专注于业务逻辑。

通过客户端→网关层→BFF层→微服务层的划分&＃xff0c;整个微服务架构层次清晰、职责分明&＃xff0c;它是一种灵活的能够支持业务不断创新的演进式架构。

微网关模式

虽然BFF网关模式在某种程度上实现了不同组件功能之间的解耦&＃xff0c;但是它主要是前端类别的去中心化和适配。BFF网关模式适用于对不同客户端&＃xff08;前端技术类别&＃xff09;类型的解耦。然而&＃xff0c;对于不同业务类型或者不同团队网关服务提供者来说&＃xff0c;BFF网关模式还是存在相互影响、相互耦合的情况。微网关&＃xff08;MicroGateway&＃xff09;模式可以理解为去中心化的网关模式&＃xff0c;微服务架构的一个重要特性就是去中心化。我们可以从业务的维度进一步划分网关系统&＃xff0c;在软件设计层面增加一个“网关组”的抽象概念&＃xff0c;一个网关组对应一个独立的业务领域。网关组的概念也契合了微服务架构中的一些理念&＃xff1a;业务系统依赖微服务网关提供清晰明确的服务边界&＃xff0c;业务系统通过微服务网关对外暴露业务的标准服务接口。

在部署方式上&＃xff0c;充分利用并结合了容器自动化的技术&＃xff0c;在解决最后一公里的问题上&＃xff0c;将网关以云端容器资源的方式交付给不同的业务方&＃xff0c;通过共享网关SDK部署包的方式将网关的服务下沉到容器中实现和执行&＃xff0c;从而在时间和空间上做到了弹性和灵活交付。使用网关的具有不同权限的用户可以同时维护各自所属网关组下的网关节点。下图展示的是去中心化的微网关模式。

目前Service Mesh使用的也是去中心化的网关模式&＃xff0c;将数据平面和控制平面解耦&＃xff0c;是区别于应用层和通信层的一种云原生上下文。边车模式&＃xff08;SideCar Pattern&＃xff09;本质上也是一种去中心化的微服务的管理方式。在本书的进阶篇中&＃xff0c;我们会更详尽地介绍微网关、边车模式、Service Mesh的演进过程和微服务的发展趋势。