Api网关在微服务架构中不可或缺的一环

地址：

随着近年来微服务的流行，API网关已经成为微服务架构中不可或缺的一部分。 一方面作为对外服务的唯一入口，另一方面提取了很多应用的公共功能。

整体结构

目前我们Api网关的架构如上图。 您可以看到 Api 网关在哪里。 它向上处理所有南北向流量，向下将流量分发到微服务应用程序或 BFF 聚合应用程序。 在 BFF 标准化之前，我们仍然会将其视为普通的微服务应用。

Api网关目前实现的功能包括请求分发、条件路由、Api管理、限流隔离、断路器降级、安全策略、监控报警、调用链跟踪等。

我们的Api网关是基于开发的，整个流程是异步响应式的，可以实现单机高并发。 基于减少重复劳动的理念，Api网关的大部分功能都是结合现有平台来实现的。

包括基于微服务框架的请求分发和条件路由、基于稳定性平台的限流隔离、断路器降级、基于监控平台的监控报警等，以及基于大数据分析平台的安全策略等。注册中心和配置中心分别负责下发核心服务注册信息和第三方配置信息。

请求分配

请求分发路由应该是网关最基本的功能。 在大多数基于nginx开发的网关上，这部分功能通常是基于动态更新代理的。 在我们的实现中，网关被认为是一个只订阅但不注册的微服务。 不同之处在于，微服务应用发起rpc调用并指定调用服务，而网关接收请求并仅分发url信息。 这样通过简单的修改就可以复用现有微服务框架的服务发现功能。

经过一系列的URL标准化动作，现在我们的URL将会针对不同的应用使用不同的前缀，并且这个前缀信息会和应用一起注册到注册中心。 这样，网关在进行服务发现时，就会针对不同的URL前缀和微服务应用构建不同的对象。 在进行请求匹配时，只需要根据URL前缀选择对应的微服务应用来匹配对应的微服务应用，然后再匹配现有的微服务。 框架sdk的功能：路由、负载均衡直到整个调用完成。

这里又涉及到一个问题，网关选择服务发现有哪些应用？ 也就是说，我需要拉取哪些应用程序信息来构建？ 我们在这里管理服务发现对象。 用户可以在管控平台上对网关层的线上线下微服务应用进行控制。 这将通过我们的配置中心推送到网关并进行处理。 热更新刷新内存缓存，从而实现请求分发服务的动态增减。

条件路由&灰度发布

条件路由是指可以过滤特定内容（或一定流量比例）的请求并将其分发到特定的实例组。 是实现灰度发布、蓝绿发布等功能的基础。

同样，基于nginx开发的网关中，一般都会维护多组列表，然后通过一定的策略将不同的请求代理到不同的目的地。

在我们的实现中，条件路由仍然重用现有的微服务框架，以避免重新发明轮子。 每个应用程序可以按照一定的规则创建一些组，组内有多个实例。 网关在进行服务发现初始化时，会为每个应用创建一个代理对象，并根据不同的组创建不同的Space。 当请求被调用时，这些Space会通过规则进行匹配，以确定是否路由到特定的组。 整个流程由微服务框架完成，无需额外的开发工作。

目前我们支持根据特定内容或流量比例匹配请求源规则。 具体内容包括http请求等。我们目前的实例组主要是根据“版本”标签来区分的，所以分配规则主要支持“版本”维度。 未来我们会考虑支持k8s pod标签。

条件路由功能结合平台发布管理，可以轻松实现灰度发布。 如下图所示，我们将用户ID为100的请求分发到灰度版本进行内测。

API管理

为什么Api网关前面有Api字样？ 我认为重要原因之一就是它具有Api管理功能。 当我们大部分应用还是裸网关而不是通过BFF聚合的时候，我们就需要对每个API接口进行管理，区分哪些是微服务之间的内部调用，哪些是暴露给前端/客户端调用。

实现方式与之前的在线和离线应用类似，但额外依赖于数据库存储。 用户在管控平台上的api发布等操作都会先存储在DB中，然后通过配置中心pub/sub通知给网关。 我们在匹配之前添加了一个层来过滤已删除/不在线的API，因此只需热更新对象即可。

我们在用户体验方面也做了一些工作，包括：

限流隔离/保险丝退化

Api网关作为南北流量的唯一入口，一般并发量较高，流量复杂度较高。 因此，有必要对入口流量进行调控和管理。

我们的限流隔离/熔断器降级是基于稳定性平台和配置中心。 稳定平台是基于我们二次开发的。 整个结构如下图所示：

稳定性相关功能主要包括限流隔离和熔断器降级。 限流和隔离主要用于控制服务器端测量的流入方向的流量。 限流主要用于控制qps，隔离主要用于控制并发数。 熔断和降级是在客户端对流出方向进行的流量控制。 断路器可以配置为在一定错误率下执行断路器，并可用于快速返回降级的数据。

上述规则可以通过稳定性平台进行配置，然后由配置中心分发到API网关，然后进行热更新刷新内存缓存。 SDK会帮助我们对每个请求进行统计，判断是否符合规则。 同时，被限流、熔断、降级隔离的流量会通过相关的SDK（基于）暴露到监控平台，以便我们随时观察流量管制的程度。

安全策略

我们时不时会遇到一些异常流量，通常是恶意爬虫，因此有必要改进一些基本的安全策略。

整个安全策略的结构如上所示。 用户可以在网关管控平台手动配置规则，并通过配置中心发送到api网关进行热更新。 当请求到来时，判断是否符合规则。 被封堵的流量也将数据暴露给监控平台，供我们随时查看。

另外，在某些场景下，手动配置禁止规则可能效率较低。 我们还将实时收集网关日志到大数据分析平台。 经过分析，如果确定某个IP或用户存在异常，则会自动将安全策略规则配置到网关管控平台，并触发警报提醒企业主。

在安全策略目标方面，我们目前支持包括客户端IP、用户ID、其他http/等。 在策略行为方面，目前支持快速失败和验证码。 在后者中，用户将被重定向到前端的人机验证码页面。

监控报警/呼叫链跟踪

和其他微服务应用一样，我们的API网关也具备完善的监控报警、调用链跟踪、日志查询等功能。 这里的监控主要指查询信息，调用链主要指查询信息，而日志顾名思义，是监控领域非常典型的信息：

除了信息/错误日志的警报之外，警报部分还可以支持主机级别的警报。

得益于监控平台和调用链埋点SDK，API网关几乎无需修改成本即可接入。 整体结构如下。 api网关嵌入SDK暴露信息供监控中心拉取。 SDK负责打印日志。 日志和业务日志将通过日志采集器输入到监控中心进行处理。 在监控平台上，用户可以查询调用链、监控、日志信息。 API网关发生主机异常或业务异常也会向业主发出警报。

这里值得一提的是，当网关调用后端微服务应用出现异常时，比如超时、连接池耗尽等，这些错误发生在客户端，也就是api网关，所以触发的报警还将报告给 api 网关的所有者。 。

但api网关仅起到转发服务的作用，其超时很大程度上是由于后端微服务rt过高造成的。 因此，该报警应同时报告给后端微服务负责人。 为此，我们开发了双端警报器。 警报将同时发送到客户端和服务器。

一些总结

当然，关于api网关还有很多东西没有讨论。

以及未来可以优化的地方：

 
长按二维码
关注我吧