微服务 API 网关建设，实践经验分享！
共 3990字，需浏览 8分钟
·
2021-07-02 12:05
作者：fredalxin
地址：https://fredal.xin/build-api-gateway
随着这些年微服务的流行，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。
条件路由的功能结合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数据给监控平台，以便我们随时观察到流量控制水平。
安全策略
时常我们会遇见一些异常流量，典型的就是恶意爬虫，所以完善一些基础的安全策略是必要的。
在安全策略目标方面，我们目前支持包括根据客户端IP、用户ID、其余http header/attribute等。策略行为方面目前支持快速失败以及验证码，后者用户会在前端被跳转到一个人机验证码的页面。
监控报警/调用链追踪
报警这块除了针对metrics信息/错误日志的报警，还可以支持主机层面的报警。
得意于监控平台以及调用链埋点sdk，api网关几乎不需要改造成本即可接入。整体结构如下所示，api网关内嵌了metrics sdk暴露metrics信息到endpoint供监控中心拉取，tracing sdk负责埋点打印tracing日志，tracing日志和业务日志均会通过日志采集器输入监控中心处理。在监控平台上，用户可以查询调用链、监控、日志信息，api网关发生的主机异常或者业务异常也会报警给owner。
这里值得一提的是，当网关调用后端微服务应用发生异常时，例如超时、连接池耗尽等，这些错误发生在客户端即api网关，所以触发的报警也会报给api网关的owner。
但是api网关仅仅作为一个转发服务，其超时很大程度是因为后端微服务rt过高，所以报警应该同时报给后端微服务owner，为此我们开发了双端告警，一份告警会同时发送给客户端和服务端双方。
一些总结
当然api网关还有许多没有展开说的
以及未来可以优化的地方：
首先是我们的高并发能力并未怎么经过实际验证，由于tob商业模式公司没有太多高并发的场景。 考虑引入规则引擎来应付各种下发的规则，包括安全策略、稳定性、路由规则等。 安全策略考虑会支持更多一些，例如IP网段，及支持各种逻辑与或非
正文结束
1.不认命，从10年流水线工人，到谷歌上班的程序媛，一位湖南妹子的励志故事
5.37岁程序员被裁，120天没找到工作，无奈去小公司，结果懵了...
一个人学习、工作很迷茫？
点击「阅读原文」加入我们的小圈子！
