1. 背景
API网关API网关
NginxSSLNginxAPI网关API
API网关
1.1. 容器化支持
云原生友好,架构要变得轻巧,便于容器化。
1.2. 灰度发布
相比较于传统发布,灰度发布可以在入口处可以设置对新功能的请求流量可按照定义分配,从而在一定时间内在试用过程中,发现和解决问题,从而使得产品在大面积推广过程中更加成熟。
1.3. 统一身份鉴权
OAuth
OpenID Relying PartyOAuthOkta
1.4. 可观测
承接集群流量,就需要掌握每个接入站点的流量分布情况;以及每个API接口的处理时长;响应的状态,再细分的话可以观察到业务响应异常的分布情况;监控往来的短信业务与邮件业务,统一处理告警规则与策略,最终汇聚为统一的网关业务看板。对接 Prometheus、Zipkin、Skywalking 等统计、监控组件;
1.5. 协议代理和转换
gRPCHTTPgRPCHTTPgRPC
API网关ServerlessAPI网关NginxIstioEnvoy
2. 如何设计微服务网关
上述是一些对微服务网关的认识,在有了明确目标和需要解决的问题,后面就是针对性选择响应技术,这里大致提供六个关键性因素,供参考。
2.1. 高性能
作为集群流量入口,性能首先要保证的,包括吞吐量和延迟,二者是衡量一个高性能网关的关键要素。所以性能自然要求越高越好,要满足对性能要求最苛刻的那一个业务方的需求。
还有一点,所谓高性能,不一定是吞吐量和延迟达到某个固定标准,很多时候只要满足业务方的实际需求就是高性能网关,在此之前,没有必要过早优化。很多时候,网关的开销只有几毫秒,而业务本身开销几十毫秒,瓶颈不在网关。
2.2. 稳定性
网关稳定性的保证是一个同高性能一样重要问题,一般除软件的质量之外,更多的还是要依赖流程的控制以及针对性的技术方案,比如灰度发布、金丝雀发布之类的。但是总体来说,就是要经历实际生产上大规模、多场景的的业务考验和流量验证。
2.3. 丰富治理能力
API管理
2.4. 可扩展性
可扩展性可扩展性
可扩展性
2.5. 可观察
可观察性在微服务架构当中非常重要。因为业务不再是单体,为排障监控带来了新的复杂度,所以需要可观察性的支持。
- 辅助排障:日志指标也会包含业务的一些特征情况,可以帮助业务方快速定位出问题所在。
- 观察趋势:最后,作为流量统一入口,网关的可观察性可以让用户了解到集群内的流量现状、趋势,并且形成长效的监控告警系统,提前发现问题。
- 自证清白:实践得来的一个经验是,一旦集群内流量产生了一些业务层面的波动,作为入口的微服务网关几乎总是第一个被怀疑的对象。明确的可观察数据比如说日志、指标可以有说服力的证明网关的清白;
2.6. 可视化管理
路由配置服务管理监控审计
- 简化操作:通过平台产品的封装,简化网关的操作流程和配置过程,隐藏或者减少底层技术的复杂性,降低 API 网关的使用门槛。
- 实现约束:实现约束,通过产品的封装和合理的提示,降低在使用 API 网关的过程中,用户犯错的风险,让用户以一种更加正确的姿势使用网关。
- 监控报警可视化。
3. 常见主流API网关
API网关APISaaS
3.1. 平台锁定
API网关
3.2. 无法二次开发
一般的大中型企业都会有自己独特的需求,需要定制开发,这时候你就只能依靠厂商,而不能自己动手去做二次开发。
平台锁定无法二次开发API网关KongApigeeakana
4. 如何选型
API网关API网关
5. 主流API网关对比
| API 网关 | Kong | APISIX | Trk | Apigee | AWS | Aliyun |
|---|---|---|---|---|---|---|
| 部署模式 | 单机和集群 | 单机和集群 | 单机和集群 | 不支持单机 | PaaS | PaaS |
| 数据存储 | Postgres、Cassandra | etcd | Redis | Postgres、Cassandra、Zookeeper | PaaS | PaaS |
| 是否开源 | Apache 2.0 协议 | Apache 2.0 协议 | MPL 协议 | 否 | 否 | 否 |
| 核心技术 | Nginx+Lua | Nginx+Lua | Golang | 未知 | 未知 | 未知 |
| 私有部署 | 是 | 是 | 是 | 否 | 否 | 否 |
| 自定义插件 | 是 | 是 | 是 | 否 | 否 | 否 |
| 社区活跃度 | 高 | 高 | 高 | 中 | 低 | 低 |
| 对接外部 IdP | 否 | 是 | 否 | 是 | 是 | 否 |
| 支持yaml | 是 | 是 | 否 | 否 | 否 | 否 |
6. 鸣谢
APISIX