深入微服务 API 网关之架构实践篇

[导读]- 前言 - 随着这些年微服务的流行，API网关已经成为微服务架构中不可或缺的一环。一方面它承担着服务对外的唯一门户，一方面它提取了许多应用的共性功能。- 整体架构 - 我们的Api网关目前的架构如上所示，可以看到Api网关处于一个什么位置，往上承接所有的南北流量...

- 前言 -

随着这些年微服务的流行，API网关已经成为微服务架构中不可或缺的一环。一方面它承担着服务对外的唯一门户，一方面它提取了许多应用的共性功能。

- 整体架构 -

我们的Api网关目前的架构如上所示，可以看到Api网关处于一个什么位置，往上承接所有的南北流量，往下会分发流量到微服务应用或者BFF聚合应用，在BFF规范化之前我们仍然将其视为一个普通微服务应用。
目前Api网关实现的功能包括请求分发、条件路由、Api管理、限流隔离、熔断降级、安全策略、监控报警以及调用链追踪等。
深入微服务 API 网关之架构实践篇

我们的Api网关基于RxNetty开发，整个流程是异步响应式的，可以达到较高的单机并发。基于少造轮子的理念，Api网关的大部分功能都是结合现有平台实现。包括请求分发、条件路由基于微服务框架，限流隔离、熔断降级基于稳定性平台，监控报警基于监控平台等，安全策略基于大数据分析平台等。注册中心与配置中心则分别负责服务注册核心信息与第三方配置信息的下发。

- 请求分发 -

请求的分发路由应该是一个网关最基本的功能，在绝大多数基于nginx开发的网关上，这部分功能通常基于动态更新代理的upstream。而在我们的实现中，认为网关是一个只订阅不注册的微服务而已，区别是微服务应用发起rpc调用指定了调用服务，而网关接收请求分发只有url信息。
这可以通过简单的改造来复用已有微服务框架的服务发现功能。
经过一系列url规范化行动后，我们的url目前不同的应用都会采取不同的前缀，同时这个前缀信息会随着应用注册到注册中心。
这样网关进行服务发现时会给不同的url前缀以及微服务应用构建不同的namespace对象，在进行请求匹配时候只需根据url前缀选取到对应的namespace即可匹配到对应微服务应用，后续就是现有微服务框架sdk的功能：路由、负载均衡直至完成整个调用。
深入微服务 API 网关之架构实践篇

这里还涉及到另一个问题，网关选择服务发现的应用是哪些？即我需要拉取哪些应用信息以构建namespace？
我们这里对服务发现对象进行了管理，用户可在管控平台上控制微服务应用在网关层的上下线，这会通过我们的配置中心推送到网关并进行一次热更新，刷新内存缓存，这样就做到了请求分发服务的动态增减。深入微服务 API 网关之架构实践篇

- 条件路由

欲知详情，请下载word文档下载文档