建设微服务API网关的一些实践( 二 )


实现上和之前的应用上下线类似 , 额外依赖了DB存储 , 用户在管控平台进行api发布等操作会先存储在DB中 , 随后通过配置中心pub/sub通知到网关 。我们在namespace匹配前加入了一层filter以过滤删除/未上线的api , 所以热更新该filter对象即可 。

建设微服务API网关的一些实践

文章插图
 
用户体验方面我们也做了一些工作 , 包括:
  • 从微服务管控平台直接同步新增的api接口到网关管控平台 , 而无需手动添加 。此外也支持多种格式的文件导入 。(我们的微服务注册模型会包括api信息等元数据)
  • 各个环境之间通过流转功能发布api , 而无需重复添加
  • 对各个状态的筛选展示
  • 与devops平台配合 , 在应用发布流转时同步提醒进行api管理的发布流转 。

建设微服务API网关的一些实践

文章插图
 
限流隔离/熔断降级Api网关作为南北流量的唯一入口 , 一般具有较高并发度 , 以及流量复杂性 。所以对入口流量进行整治管理是很有必要的 。
我们的限流隔离/熔断降级均基于稳定性平台与配置中心实现 , 稳定性平台是我们基于Sentinel二次开发的 。整个结构如下图所示:
建设微服务API网关的一些实践

文章插图
 
稳定性相关的功能主要包括限流隔离以及熔断降级 。限流隔离主要是作用在流入方向服务端测的流量控制 , 其中限流主要是控制qps , 隔离主要是控制并发数 。熔断降级则是作用在流出方向客户端测的流量控制 , 可以配置在一定错误率情况下进行熔断 , 并配合降级数据快速返回 。
以上规则均可以通过稳定性平台配置 , 然后由配置中心分发到api网关 , 再进行热更新刷新内存缓存 。每次请求时sentinel sdk都会帮我们做好数据统计并判断是否符合规则 , 同时被限流隔离、熔断降级的流量都会通过相关sdk(基于prometheus)暴露metrics数据给监控平台 , 以便我们随时观察到流量控制水平 。
安全策略时常我们会遇见一些异常流量 , 典型的就是恶意爬虫 , 所以完善一些基础的安全策略是必要的 。
建设微服务API网关的一些实践

文章插图
 
整个安全策略的结构如上所示 。用户可以在网关管控平台手动进行规则配置 , 经由配置中心下发到api网关的securityControl进行热更新 。在请求来临时由securityControl判断是否符合规则 , 被封禁的流量同样暴露metrics数据给监控平台供我们随时查看 。
此外 , 手动配置封禁规则在某些场景可能比较低效 。我们同时还会将网关日志实时采集至大数据分析平台 , 经分析后如果判断某个ip或者用户存在异常情况 , 会自动配置安全策略规则至网关管控平台 , 同时触发一个报警提醒业务owner 。
在安全策略目标方面 , 我们目前支持包括根据客户端IP、用户ID、其余http header/attribute等 。策略行为方面目前支持快速失败以及验证码 , 后者用户会在前端被跳转到一个人机验证码的页面 。
监控报警/调用链追踪与其他微服务应用一样 , 我们的api网关也有完善的监控报警、调用链追踪、日志查询等功能 。这里监控主要指的是查询metrics信息 , 调用链主要指查询tracing信息 , 日志顾名思义就是logging , 三者是监控领域很典型的信息了:
建设微服务API网关的一些实践

文章插图
 
报警这块除了针对metrics信息/错误日志的报警 , 还可以支持主机层面的报警 。
得益于监控平台以及调用链埋点sdk , api网关几乎不需要改造成本即可接入 。整体结构如下所示 , api网关内嵌了metrics sdk暴露metrics信息到endpoint供监控中心拉取 , tracing sdk负责埋点打印tracing日志 , tracing日志和业务日志均会通过日志采集器输入监控中心处理 。在监控平台上 , 用户可以查询调用链、监控、日志信息 , api网关发生的主机异常或者业务异常也会报警给owner 。
建设微服务API网关的一些实践

文章插图
 
这里值得一提的是 , 当网关调用后端微服务应用发生异常时 , 例如超时、连接池耗尽等 , 这些错误发生在客户端即api网关 , 所以触发的报警只会报给api网关的owner 。但是api网关仅仅作为一个转发服务 , 其超时很大程度是因为后端微服务rt过高 , 所以报警应该同时报给后端微服务owner , 为此我们开发了双端告警 , 一份告警会同时发送给客户端和服务端双方 。


推荐阅读