API 管理在云原生场景下的机遇与挑战

作者 ｜ 张添翼
来源 ｜ 尔达Erda公众号
​

云原生下的机遇和挑战

标准和生态的意义

自从 Kubernetes v1.0 于 2015 年 7 月 21 日发布，CNCF 组织随后建立以来，其后几年，Kubernetes 和 CNCF 都经历了如火如荼的发展。时至今日，Kubernetes 已经进入成熟期，云原生时代则刚刚开始。虽然说云原生不只是围绕着 Kubernetes 的生态，但无可质疑，Kubernetes 已经是云原生生态的基石。通过规范 API 和 CRD 标准，Kubernetes 已经建立起了一个云原生 PaaS 生态帝国，成为了 PaaS 领域的事实标准。
​

这一层事实标准，对企业交付有着巨大的意义。在 K8s 生态出现之前，类比于土木工程，连螺丝螺帽这样的东西都缺少统一的标准，而企业甲方如果只关注上层业务功能，很容易把万丈高台架构于浮沙之上，导致业务的倾覆。不夸张的说，在企业交付领域，真是“天不生 K8s，万古如长夜”。
​

以 API 管理中的 API 路由功能为例，如果不使用 K8s，企业可能会选择 F5/Nginx/HAProxy/Zuul 等各式网关软件，做对应的路由配置。有的软件提供了控制台 UI，有的可能是人肉脚本运维，缺乏标准，运维技能也无法沉淀，关键人员离职可能会带来灾难。K8s 把 API 路由的能力抽象为了 Ingress 资源，定义了标准，屏蔽了底层软件细节，通过 CNCF CKA 认证的人员都会具备 API 路由运维的能力。在 API 管理的领域，除了 API 路由，还有 API 流量治理策略，API 开放鉴权，以及调用量观测审计等环节，K8s 以及 Istio 等生态都给出了一些标准定义，虽然其中很多尚未成熟，但标准和生态的未来已经愈发清晰。Erda Cloud 一直坚定地走在这条道路上，为企业提供符合标准，值得信赖的 API 管理产品。
​

云原生网关各家争鸣

网关是构成 API 管理产品的关键一环。在云原生生态中，对于 K8s Ingress 标准，涌现出了众多不同的 Ingress Provider。有人整理了如下这张表格：
​
从表格中看到，这些 Ingress Provider 的底层网关实现有：Nginx，HAProxy，Envoy，Traefik，Skipper。
​

Kubernetes Nginx Ingress 作为官方实现，有最广大的用户生态群体，也是现在大规模生产部署使用最多的。在云原生生态出现之前，Nginx 就已经凭借高性能易扩展坐稳了 Web 2.0 时代网关第一的位置，具备很好的开发和运维生态，所以才会被 K8s 选中作为默认的 Ingress Provider，继而凭借着 Ingress，将生态进一步扩大。
​

HAProxy 跟 Nginx 的经历比较相似，都出现在 Web 2.0 刚兴起的时代，凭借高性能、极低的资源占用，占据了网关生态的一席之地。在和 K8s Ingress 结合之前，HAProxy 和 Nginx 在软件系统架构中扮演的更多是类似 ADC （Application delivery controller）接入层负载均衡的角色，即使采用了微服务架构，也不会直接负责微服务的流量暴露，通常是再增加一层微服务网关转发，如 Spring Cloud Gateway。因为微服务网关通常需要和微服务架构中的注册中心打通，实现服务发现，而这并不是 HAProxy 和 Nginx 的强项，在 Spring Cloud 微服务体系里，没有比 Spring Cloud Gateway 更佳的选择。但是 K8s 改变了这一切，它提供了 Ingress / Service / Endpoint 配套的服务发现机制，并且依托外置于代码的健康检查机制，可以实现无语言限制更通用的服务发现，扩展性也更强。这帮助 HAProxy 和 Nginx 将触手伸向了微服务治理领域。

其实早在 K8s 之前，已经有网关软件试图从传统的负载均衡领域扩展到微服务治理，Kong 就是此中翘楚。借助于 OpenResty，在依托 Nginx 高性能高可靠的基础上，能实现业务功能插件的快速开发。 所以 Kong 也实现了自己的服务发现和健康检查机制。

不过比较可惜的是，在 K8s 出现之后，独立的健康检查机制就比较鸡肋了，Kong Ingress 依然保留了这套鸡肋的机制，私以为不是一个明智的选择。而且 Kong Ingress 在路由策略配置这块，只支持自己的 Lua 插件生态，并不支持原生的 Nginx 配置指令，虽然 Kong 的插件生态已经很完善，但对于比如添加 HTTP 应答头这种一行 Nginx 配置指令就能搞定的事情，Kong 的插件未免有些低水平重复建设，冗杂且低效。不过，Kong 的插件生态丰富，尤其是认证和鉴权功能相当成熟，这也是 Erda Cloud 虽然没有选择 Kong Ingress，但仍然用 Kong 来实现部分 API 管理能力的主要原因。
​

一个软件的生命周期，如果跟架构生态发展的周期相契合，会迸发出耀眼的光芒。如果说 Kong 没有在最好的年纪遇上 K8s，“我生君未生，君生我已老”。Envoy 和 Istio 的相辅相成，可以称得上是一对完美 CP。Istio 将 Envoy 网关的能力从入口南北向管理拓展到了微服务之间的东西向流量管理，基于 xDS 协议的配置动态更新机制也优于 HAProxy 和 Nginx。不过 Envoy 的配置文件是用 json 描述的，自描述性比较差，所以像 Istio / Ambassador / Gloo 等都是对配置进行二次抽象，能更方便运维。虽然 Istio + Envoy 的未来想象空间是最大的，不过在基于配置抽象的网关能力覆盖度上，Gloo 是现在做的最好的，但跟 Nginx Ingress 相比还是有差距，尤其是类 ADC 部分的功能。网关能力的覆盖，跟生态需求的推动分不开，因为 Envoy 自身对配置的抽象程度不高，面向 Envoy 进行各自二次抽象的 Ingress Providers 又在一定程度上割裂了生态，要追上 Nginx Ingress 的生态，还有很长一段路要走。
​

Traefik 和 Sk