共计 3588 个字符，预计需要花费 9 分钟才能阅读完成。
作者：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 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
