本文将近期阅读的 API 网关相关的资料做下整理记录.
选择 Kong 作为 API 网关: https://www.itcodemonkey.com/article/5980.html
这篇文章将为什么需要 API 网关, 以及为什么可以选择开源 Kong 网关做为 API 网关都做了较为详细的说明, 是对 Kong 网关比较系统性的介绍的一篇文章.
在微服务架构之下, 服务被拆的非常零散, 降低了耦合度的同时也给服务的统一管理增加了难度. 如上图左所示, 在旧的服务治理体系之下, 鉴权, 限流, 日志, 监控等通用功能需要在每个服务中单独实现, 这使得系统维护者没有一个全局的视图来统一管理这些功能. API 网关致力于解决的问题便是为微服务纳管这些通用的功能, 在此基础上提高系统的可扩展性.
Kong 的插件机制是其高可扩展性的根源, Kong 可以很方便地为路由和服务提供各种插件, 网关所需要的基本特性, Kong 都如数支持:
云原生: 与平台无关, Kong 可以从裸机运行到 Kubernetes
动态路由: Kong 的背后是 OpenResty+Lua, 所以从 OpenResty 继承了动态路由的特性
熔断
健康检查
日志: 可以记录通过 Kong 的 HTTP,TCP,UDP 请求和响应.
鉴权: 权限控制, IP 黑白名单, 同样是 OpenResty 的特性
SSL: Setup a Specific SSL Certificate for an underlying service or API.
监控: Kong 提供了实时监控插件
认证: 如数支持 HMAC, JWT, Basic, OAuth2.0 等常用协议
限流
REST API: 通过 REST API 进行配置管理, 从繁琐的配置文件中解放
可用性: 天然支持分布式
高性能: 背靠非阻塞通信的 nginx, 性能自不用说
插件机制: 提供众多开箱即用的插件, 且有易于扩展的自定义插件接口, 可以使用 Lua 自行开发插件
有赞团队的 API 网关实践: https://tech.youzan.com/api-gateway-in-practice/
有赞 API 网关目前承载着微商城, 零售, 微小店, 餐饮, 美业, AppSDK, 部分 PC, 三方开发者等多个业务的调用, 每天有着亿级别的流量.
在这篇文章中提到的网关核心设计部分相关内容可以参考
异步特性: 我们使用 Jetty 容器来部署应用, 并开启 Servlet3.0 的异步特性, 由于网关业务本身就是调用大量业务接口, 因此 IO 操作会比较频繁, 使用该特性能较大提升网关整体并发能力及吞吐量.
缓存: 为了进一步提升网关的性能, 我们增加了一层分布式缓存(借用 Codis 实现), 将一些不经常变更的 API 元数据缓存下来, 这样不仅减少了应用和 DB 的交互次数, 还加快了读取效率.
链式处理: 在设计网关的时候, 我们采用责任链模式来实现网关的核心处理流程, 将每个处理逻辑看成一个 Pipe, 每个 Pipe 按照预先设定的顺序先后执行
平滑限流: 消除了简单计数器限流带来的短时间内流量不均的问题. 目前网关支持 IP, 店铺, API, 应用 ID 和三方 ID 等多个维度的限流, 也支持各维度的自由组合限流.
熔断降级: 使用 Hystrix 进行熔断降级处理. Hystrix 支持线程池和信号量 2 种模式的隔离方案, 内部也开发了一个基于 Hystrix 的服务熔断平台
预警监控: 实时地从 Kafka 消费 API 调用日志, 如果发现某个 API 的 RT 或者错误次数超过配置的报警阈值, 则会立即触发报警
浅聊 API 网关 :
这篇文章比较基础, 重点是对当前主流的 API 网关有一个详细的功能性对比. 同时对 API 网关设计的时候需要考虑的关键点, 例如性能, 高可用性, 扩展性, 服务发现, 缓存等也做了详细的说明和分析.
不管是由于 APIs 的普及, 还是作为微服务架构中的一员, 实现 API 网关是很重要的. 在具备对请求做决策判断后的转发, 协议转换, 路由等基本功能外还需要有良好可扩展性. 在功能实现时要尽可能的跟业务层解耦. 作为一个高可用, 伸缩性强的组件, 优缺点并存, 但相对其带来的功能这些缺点是可以容忍的.
企业级 API 网关设计:
这篇文章是对企业级 API 网关设计必须系统化的产生, 从 API 网关的概述, API 网关所起的作用, 当前主流的 API 网关功能对比分析, API 网关的高可用性设计多方面进行了阐述.
网关层作为客户端与服务端的一层挡板, 主要起到了三大类作用:
1. 隔离作用: 作为企业系统边界, 隔离外网系统与内网系统.
2. 解耦作用: 通过解耦, 使得微服务系统的各方能够独立, 自由, 高效, 灵活地调整.
3. 脚手架作用: 提供了一个地点, 方便通过扩展机制对请求进行一系列加工和处理.
API 网关作为对外提供服务的入口, 就像企业服务的大门. 一方面, 要有足够的能力, 应对大量的对外访问, 另一方面, 还要给对内的服务提供一定的安全保障. 除此之外, 企业提供的 API 服务多种多样, API 网关要能够对这些 API 的全生命周期进行便捷的管理, 例如服务发布, 调整, 下架, 计费, 监控等.
企业 API 网关在功能设计上主要应该考虑如下内容:
API 生命周期管理功能: 覆盖 API 的定义, 测试, 发布的整个生命周期管理.
API 开发和使用支持功能:
安全防护功能: API 请求到达网关需要经过严格的身份认证, 权限认证, 才能到达后端服务.
流量控制功能 :API 调用次数, 异常, 分级. 流控粒度: 分钟, 小时, 天.
请求管理功能 : 可根据配置进行参数类型, 参数值 (范围, 枚举, 正则, JSON Schema) 的校验
监控告警功能: 提供实时, 可视化的 API 监控, 包括: 调用量, 调用方式, 响应时间, 错误率.
API 交易功能: 提供 API 交易市场, 计量计费, Quota 控制, 运营售卖等需求.
顺着这篇文章, 我们参考了另外一篇谈如何设计高并发下 API 网关的一篇文章, 重点对并发模型, SEDA 基于事件的并发架构进行了阐述.
地址: https://mp.weixin.qq.com/s?__biz=MzI5MDEzMzg5Nw==&mid=412734308&idx=1&sn=f1c1bd5e22e2ae7dedf4b788a625e814&scene=21#wechat_redirect
传统的并发编程模型主要有两种: 一种是 Thread-based concurrency, 另一种是 Event-driven concurrency. 总结下两种模式的特点如下:
基于线程的并发: 每个任务一线程直线式的编程使用资源高昂, context 切换代价高, 竞争锁昂贵, 太多线程可能导致吞吐量下降, 响应时间暴涨;
基于事件的并发: 单线程处理事件的每个并发流实现为一个有限状态机应用直接控制并发负载增加的时候, 吞吐量饱和响应时间线性增长.
SEDA 架构是目前云计算, 微服务时代下一种优秀的消息处理架构, 而且历经考验, 稳定可靠. SEDA 架构的核心思想: 把一个请求处理过程分成几个 Stage, 每个 Stage 可由不同的微服务进行处理, 不同资源消耗的 Stage 使用不同数量的线程来处理, 微服务之间采用异步通讯的模式.
小豹 API 网关: http://www.xbgateway.com/architecture.html
这个是最近在网上查找 API 网关相关资料的时候搜索到的一个商用的 API 网关, 从产品介绍材料来看, 我们前面谈过的网关的核心功能基本上全部包括, 而且相当来说也比较完善. 同时提供了一个较方便的 API 网关的治理管控平台, 可以方便的对 API 注册接入和运行全生命周期, 方便对安全, 流控, 日志各方面进行灵活管控.
下面我们看下网站对 API 网关架构特点的一些说明:
基于 Netty NIO 的响应式架构 ; 分布式缓存基于 Redis; 数据库基于 MySQL, 分布式配置基于 ZooKeeper
API 配置缓存 , 运行时不依赖 DB, 配置更新后自动通知各网关节点;
支持自定义组件, 动态加载 , 在不中断网关服务的情况下重新加载配置和运行组件;
API 服务连续异常后自动熔断和自我恢复 , 访问异常, 超时处理;
网关核心运行过程不写磁盘 IO , 避免磁盘 IO 性能影响网关吞吐量;
Docker 容器化支持 , 拆分网关, 管理服务, 第三方中间件依赖等镜像, 便于灵活扩容.
企业微服务 API 开发: http://www.restcloud.cn/restcloud/mycms/index.html
RestCloud API 网关是完全自主研发的面向企业级的 API 网关, 一且以简单, 易用, 轻量级为目标进行研发, 同时兼顾作为企业级的服务总线可以替换企业原有的 ESB 产品, RestCloud 是集 ESB 和 API 网关于一体的企业级网关产品. 这个不仅仅提供了 API 网关, 也提供了微服务快速开发平台, API 服务治理平台, DaaS 等相关组件.
来源: http://www.tuicool.com/articles/zeaYn2q