作者：fredalxin

地址：https://fredal.xin/build-api-...

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

整体架构

咱们的Api网关目前的架构如上所示，能够看到Api网关处于一个什么地位，往上承接所有的南北流量，往下会散发流量到微服务利用或者BFF聚合利用，在BFF规范化之前咱们依然将其视为一个一般微服务利用。

目前Api网关实现的性能包含申请散发、条件路由、Api治理、限流隔离、熔断降级、安全策略、监控报警以及调用链追踪等。

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

申请散发

申请的散发路由应该是一个网关最根本的性能，在绝大多数基于nginx开发的网关上，这部分性能通常基于动静更新代理的upstream。而在咱们的实现中，认为网关是一个只订阅不注册的微服务而已，区别是微服务利用发动rpc调用指定了调用服务，而网关接管申请散发只有url信息。这能够通过简略的革新来复用已有微服务框架的服务发现性能。

通过一系列url规范化口头后，咱们的url目前不同的利用都会采取不同的前缀，同时这个前缀信息会随着利用注册到注册核心。这样网关进行服务发现时会给不同的url前缀以及微服务利用构建不同的namespace对象，在进行申请匹配时候只需依据url前缀选取到对应的namespace即可匹配到对应微服务利用，后续就是现有微服务框架sdk的性能：路由、负载平衡直至实现整个调用。

这里还波及到另一个问题，网关抉择服务发现的利用是哪些？即我须要拉取哪些利用信息以构建namespace?咱们这里对服务发现对象进行了治理，用户可在管控平台上管制微服务利用在网关层的高低线，这会通过咱们的配置核心推送到网关并进行一次热更新，刷新内存缓存，这样就做到了申请散发服务的动静增减。

条件路由&灰度公布

条件路由意味着能够对具备特定内容(或者肯定流量比例)的申请进行筛选并散发到特定实例组上，是实现灰度公布、蓝绿公布、ABTest等性能的根底。

同样的，在基于nginx开发的网关中，个别是保护多套upstream列表，而后通过某种策略将不同申请代理到不同upstream。

在咱们的实现中，条件路由仍然是复用现有的微服务框架，防止反复造轮子。每个利用都能够依据一些规定创立一些分组，分组中有若干实例。在网关进行服务发现初始化时会给每个利用创立Invoker代理对象，Invoker内会依据不同的分组创立不同的Space空间，申请调用时会对这些Space空间进行规定匹配，从而决定是否路由到特定分组上。整个过程都是微服务框架实现的，没有额定的开发工作。

目前咱们反对依照特定内容或者流量比例两种形式进行申请起源规定的匹配，特定内容包含http申请的header、attribute等等。咱们目前的实例分组次要是依据"版本"这个标来辨别的，所以调配规定次要是反对"版本"维度，将来思考反对到k8s的pod label。

条件路由的性能联合devops平台公布治理能够很容易实现灰度公布。如下图所示咱们将用户id是100的申请散发到灰度版本上进行内部测试。

Api治理

Api网关为什么后面要有Api几个字，我感觉其中一个很重要的起因就是具备Api治理性能。当咱们的大部分利用还是裸连网关，而不是通过BFF聚合时，咱们有必要对每个api接口都进行治理，以辨别哪些是微服务间外部调用，哪些是裸露给前端/客户端调用。

实现上和之前的利用高低线相似，额定依赖了DB存储，用户在管控平台进行api公布等操作会先存储在DB中，随后通过配置核心pub/sub告诉到网关。咱们在namespace匹配前退出了一层filter以过滤删除/未上线的api，所以热更新该filter对象即可。

用户体验方面咱们也做了一些工作，包含：

  • 从微服务管控平台间接同步新增的api接口到网关管控平台，而无需手动增加。此外也反对多种格局的文件导入。(咱们的微服务注册模型会包含api信息等元数据)
  • 各个环境之间通过流转性能公布api，而无需反复增加
  • 对各个状态的筛选展现
  • 与devops平台配合，在利用公布流转时同步揭示进行api治理的公布流转。

限流隔离/熔断降级

Api网关作为南北流量的惟一入口，个别具备较高并发度，以及流量复杂性。所以对入口流量进行整治治理是很有必要的。

咱们的限流隔离/熔断降级均基于稳定性平台与配置核心实现，稳定性平台是咱们基于Sentinel二次开发的。整个构造如下图所示：

稳定性相干的性能次要包含限流隔离以及熔断降级。限流隔离次要是作用在流入方向服务端测的流量管制，其中限流次要是管制qps，隔离次要是管制并发数。熔断降级则是作用在流出方向客户端测的流量管制，能够配置在肯定错误率状况下进行熔断，并配合降级数据疾速返回。

以上规定均能够通过稳定性平台配置，而后由配置核心散发到api网关，再进行热更新刷新内存缓存。每次申请时sentinel sdk都会帮咱们做好数据统计并判断是否合乎规定，同时被限流隔离、熔断降级的流量都会通过相干sdk(基于prometheus)裸露metrics数据给监控平台，以便咱们随时察看到流量管制程度。

安全策略

时常咱们会遇见一些异样流量，典型的就是歹意爬虫，所以欠缺一些根底的安全策略是必要的。

整个安全策略的构造如上所示。用户能够在网关管控平台手动进行规定配置，经由配置核心下发到api网关的securityControl进行热更新。在申请来长期由securityControl判断是否合乎规定，被封禁的流量同样裸露metrics数据给监控平台供咱们随时查看。

此外，手动配置封禁规定在某些场景可能比拟低效。咱们同时还会将网关日志实时采集至大数据分析平台，经剖析后如果判断某个ip或者用户存在异常情况，会主动配置安全策略规定至网关管控平台，同时触发一个报警揭示业务owner。

在安全策略指标方面，咱们目前反对包含依据客户端IP、用户ID、其余http header/attribute等。策略行为方面目前反对疾速失败以及验证码，后者用户会在前端被跳转到一个人机验证码的页面。

监控报警/调用链追踪

与其余微服务利用一样，咱们的api网关也有欠缺的监控报警、调用链追踪、日志查问等性能。这里监控次要指的是查问metrics信息，调用链次要指查问tracing信息，日志顾名思义就是logging，三者是监控畛域很典型的信息了：

报警这块除了针对metrics信息/谬误日志的报警，还能够反对主机层面的报警。

得意于监控平台以及调用链埋点sdk，api网关简直不须要革新老本即可接入。整体构造如下所示，api网关内嵌了metrics sdk裸露metrics信息到endpoint供监控核心拉取，tracing sdk负责埋点打印tracing日志，tracing日志和业务日志均会通过日志采集器输出监控核心解决。在监控平台上，用户能够查问调用链、监控、日志信息，api网关产生的主机异样或者业务异样也会报警给owner。

这里值得一提的是，当网关调用后端微服务利用产生异样时，例如超时、连接池耗尽等，这些谬误产生在客户端即api网关，所以触发的报警也会报给api网关的owner。然而api网关仅仅作为一个转发服务，其超时很大水平是因为后端微服务rt过高，所以报警应该同时报给后端微服务owner，为此咱们开发了双端告警，一份告警会同时发送给客户端和服务端单方。

一些总结

当然api网关还有许多没有开展说的

  • 咱们还反对websocket协定，本次没有具体说
  • 在多云部署环境下，网关承载了一个多云流量调度服务的角色。

以及将来能够优化的中央

  • 首先是咱们的高并发能力并未怎么通过理论验证，因为tob商业模式公司没有太多高并发的场景。
  • 思考引入规定引擎来应酬各种下发的规定，包含安全策略、稳定性、路由规定等。
  • 安全策略思考会反对更多一些，例如IP网段，及反对各种逻辑与或非

近期热文举荐：

1.1,000+ 道 Java面试题及答案整顿(2021最新版)

2.终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！

3.阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！

5.《Java开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！