共计 11285 个字符，预计需要花费 29 分钟才能阅读完成。
作者 | 张添翼
起源 | 尔达 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 和 Skipper 等基于 Golang 的后起之秀，也不容忽视，尽管用户生态群体比不上老前辈们，但有着很好的开发者生态，这也得益于 Golang 这门让解决并发和 IO 变得如此简略的语言。投合开发者也有两面性，比方因为有 GC 存在，要在大量并发连贯和申请之下，放弃现实的内存占用状况，难度会变的很大，为了达到 C/C++ 网关的性能，会在肯定水平上减少代码设计的复杂度，从而变得不再简略可依赖。
云原生网关各家争鸣，起因是没有哪一家的产品能齐全笼罩用户的需要，从类 ADC 到微服务发现，再到鉴权认证等更贴近业务的 API 治理域。Erda Cloud 的云原生 API 治理解决方案也是采纳了 Nginx Ingress + Kong 的两层架构。不过置信随着规范的倒退，网关边界的拓展，将来肯定会呈现既能齐全满足底层网络运维需要，又能很好地扩大撑持下层业务策略的单层全栈网关软件，且肯定是面向云原生架构的。
API 治理产品的鱼与熊掌
2010 年前后，Apigee 和 MuleSoft 的 API 治理产品前后脚呈现了，并且给出了 API 全生命周期治理这一概念，旨在买通从设计开发到测试部署，再到对外开放集成，最终实现 API 货币化的全流程。到现在，如 Gartner 等咨询机构，也把 API 全生命周期治理当作企业数字化的要害一环，每年都会产出剖析报告，为企业提供咨询服务。下图是 2020 年的 Gartner API 全生命周期治理魔力象限：
如上图所示，Apigee 和 MuleSoft 因为先发劣势，牢牢占据着领导者象限的高位。能够看到 Kong 也位于领导者象限，甚至在策略层面当先于 Apigee 和 MuleSoft，这很大水平上是因为 Kong 丰盛的业务插件生态，以及 Kong Ingress 等云原生的设计，当先于老牌的 API 治理产品。不过跟 MuleSoft 等成熟的 API 治理 SaaS 产品比起来，Kong 在产品化上并没有亮眼的体现。
现有的比拟成熟的 API 治理 SaaS 产品，都有本人实现的 API 网关作为内核。但不同于云原生 Ingress 网关，这些 API 网关并不间接路由到 K8s 服务上，而是架构在整个业务零碎之上，做利用零碎层面的 API 治理。这也意味着，一旦抉择这类 SaaS 产品，就必须要承受网络上多一层转发的开销，而且可能是逾越公网，要承当额定的 TLS 加密传输开销，这可能会在网络传输上减少数十到数百毫秒的延时。
Erda Cloud 提供的全生命周期的 API 治理产品，既利用了 Kong 成熟的 API 治理插件生态，同时又联合 Nginx Ingress 能更快更不便地直连云原生利用，让用户不用在延时开销和 API 治理能力之间做鱼和熊掌的抉择。这是 Erda Cloud 的云原生 API 治理产品与市面上其余产品最大的区别。
Erda Cloud 云原生网关
架构简介
联合性能覆盖面，用户生态和企业生产实践规模的考量，Erda Cloud 的网关产品抉择了优先适配 Nginx Ingress 来作为 K8s Ingress Provider。Erda Cloud 能够托管用户自建（或应用云厂商 K8s 服务）的 K8s 集群，只有集群内装置的 Nginx Ingress Controller 版本高于 0.25，即可间接应用 Erda Cloud 云原生网关产品。
Erda Cloud 将 Kong 作为一个扩大组件，当用户有 API 凋谢鉴权等业务层面 API 治理的需要时，能够抉择装置此扩大。用户在 Erda Cloud 上配置对应域名 /API 的性能需要，Kong 会主动接管对应的 Ingress，再二次路由到对应的 K8s Service 上。基于 Unix domain socket/eBPF sockmap 等伎俩，能够将 Nginx Ingress 转发到 Kong 的延时降到忽略不计。
当然，减少一层代理转发，必定会带来额定的资源占用，是这套架构的不足之处。然而领有云原生的 Ingress Provider 让用户平滑接入这样的益处，具备从类 ADC 性能到业务层 API 治理性能这样全笼罩的能力，以及用户能够自主治理哪些流量经 Kong 转发此类灵便的设计，这个 trade off 还是很值得做的。
扬 Ingress Annotation 之长
Nginx Ingress 能够基于 Ingress Annotation 实现弱小的流量治理性能，例如要对申请速率进行限度的性能：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-example-host
annotations:
# 每个 IP 每秒能够拜访 5 次
nginx.ingress.kubernetes.io/limit-rps: 5
# 为计算限速漏桶算法的 burst size，和 limit-rps 的相乘系数
nginx.ingress.kubernetes.io/limit-burst-multiplier: 5
# 配合 limit-window 示意全局限速 100 次每秒（须要依赖 memcached）nginx.ingress.kubernetes.io/global-rate-limit: 100
nginx.ingress.kubernetes.io/global-rate-limit-window: 1s
# 限度发送给后端服务的发送速率为 1MB 每秒
nginx.ingress.kubernetes.io/limit-rate: 1024
# 发送给后端服务的前 10MB 数据不进行限速
nginx.ingress.kubernetes.io/limit-rate-after: 10240
spec:
rules:
- host: "foo.bar.com"
http:
paths:
- path: "/bar"
backend:
service:
name: bar
port:
number: 80
申请限速是 Ingress Annotation 能力的冰山一角，这简略的配置形式，是很多其余网关无法比拟的，例如应用 Istio Ingress Gateway 的时候，得通过简单的 EnvoyFillter 配置来实现。相比之下 Gloo 做了一些配置上的简化，但也把这部分性能放到了商业化版本中，开源版本并不提供。
Erda Cloud 进一步强化了 Ingress Annotation 的能力。仍以限度申请速率为例，Nginx Ingress 提供的全局流量限速，须要依赖外置的 memcached 来进行多个 Nginx Ingress 实例之间的同步。Erda Cloud 能够实现对 Nginx Ingress 实例个数的感知，自动更新限速的配置。比方在 Erda Cloud 的网关策略配置了 100 次每秒的申请限度，并且以后 Nginx Ingress 实例个数为 2，则理论在 Ingress 中做的限速配置是 50 次每秒。不止于此，Erda Cloud 还升高了用户做此类配置时的心智老本。相熟 Nginx 的人应该晓得，申请速率限度是基于漏桶算法实现的，burst size 是实现去峰填谷的要害，如果 burst 大小为 0，偶发的申请距离过段也会被回绝拜访。然而一般的用户可能并不理解这一机制，对于 Nginx Ingress 的 nginx.ingress.kubernetes.io/limit-burst-multiplier 配置项也会很困扰。
上面来看一下：Erda Cloud 是如何让用户做配置的吧。
Erda Cloud 的网关配置将限流的 burst 配置代替为了最大额定延时的配置，这基于一个简略的算式：
Burst Size = 最大额定延时 (秒) * 最大吞吐 (申请 / 秒)
所谓最大额定延时，解释起来就简略很多：当申请速率超过限定速率时，进行去峰填谷，为以后申请附加额定延时，如果须要附加的延时超过限定的最大额定延时，则间接回绝拜访。
Nginx Ingress 并没有提供现成的 Annotation 反对这种 local 模式的全局速率限度，但仍然能够基于 snippet Annotation 来自定义 Nginx 的配置：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-example-host
annotations:
# 会在对应的 server{} 下增加以下 nginx 配置片段
nginx.ingress.kubernetes.io/server-snippet: |
###ERDA-AUTO-CONFIG###
location @server-guard-65feeb {
more_set_headers 'Content-Type: text/plain; charset=utf-8';
return 429 "System is busy, please try it later.";
}
###ERDA-AUTO-CONFIG###
# 会在对应的 location{} 下增加以下 nginx 配置片段
nginx.ingress.kubernetes.io/configuration-snippet: |
###ERDA-AUTO-CONFIG###
limit_req zone=server-guard-65feeb burst=5;
limit_req_status 581;
error_page 581 = @server-guard-65feeb;
###ERDA-AUTO-CONFIG###
spec:
rules:
- host: "foo.bar.com"
http:
paths:
- path: "/bar"
backend:
service:
name: bar
port:
number: 80
这段 Nginx 配置原理是，当拒绝请求时，先外部返回一个 581 状态码，通过 error_page 跳转到自定义的 named location，而后在 named location 内返回用户配置的回绝状态码和回绝应答 body。
因为 limit_req_zone 指令只能配置在 Nginx 的 http block 内，所以 Erda Cloud 除了更新对应的 Ingress Annotation，还须要更新对应的 Configmap nginx-configuration :
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-configuration
namespace: kube-system
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
data:
http-snippet: |
###ERDA-AUTO-CONFIG###
limit_req_zone 1 zone=server-guard-65feeb:1m rate=100r/s;
###ERDA-AUTO-CONFIG###
这些，Erda Cloud 生成的配置会被 ###ERDA-AUTO-CONFIG### 正文块包起来，在这些正文块之外，用户依然能够增加自定义的配置项，并不会受 Erda Cloud 配置的影响。
基于这个例子，想必大家曾经见识到了 Nginx 和 Ingress 联合起来的威力，基于 snippet 片段，能够将 Nginx 原生配置的能力，在 Ingress 上施展得酣畅淋漓。这也是云原生的魅力，将 Nginx 配置运维晋升到了一个全新的档次，更好地解耦、更好地适配微服务架构。Erda Cloud 则更进一步，通过产品化封装，让这些配置对研发运维人员的心智老本要求降到更低。
取 Kong 之长补 Ingress 之短
Nginx Ingress 尽管依靠于 K8s Service 能够实现微服务发现和路由，但因为无奈反对 HTTP Method 级别的路由管制，在微服务 API 治理上的能力是欠缺的。比方某服务只心愿将一个特定的 API GET /api/assets/{assetID} 对外裸露，基于 Nginx Ingress 的路由机制是无奈实现的。在 Erda Cloud 的云原生网关上，则能够很容易实现这个需要。
首先，在微服务 API 治理中给对应的服务增加要裸露的 API，如下图只裸露了一个 API GET /api/assets/{assetID}。
而后再将指定域名的 URL 路由到这个微服务上，例如域名为 helloworld.erda.cloud，依照如下配置，当申请 helloworld.erda.cloud/api/example/assets/100 时，网关会将申请门路改写为 /api/assets/100 再转发给后端微服务。
这一性能是借助于 Kong 实现的。当用户创立微服务 API 时，会将微服务和 Kong 的 Route/Service 关联起来；当用户在特定域名上配置路由时，会创立一个转发到 Kong 的 Ingress：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /c517f0f2/api/assets$1
nginx.ingress.kubernetes.io/upstream-vhost: dev.gateway.inner
nginx.ingress.kubernetes.io/use-regex: "true"
name: erda-route-ed71b6-6de9f1
namespace: addon-kong-pb8210
spec:
rules:
- host: helloworld.erda.cloud
http:
paths:
- backend:
service:
name: kong
port:
number: 8000
path: /api/example/assets(.*)
pathType: ImplementationSpecific
借助于 Kong 的能力，还补足了 Nginx Ingress 在认证鉴权能力上的欠缺，Kong 提供了丰盛的 AuthN 插件，Erda Cloud 次要应用了 OAuth2、Key Auth、HMAC Auth 这三个插件，能够在 Erda Cloud 中对立地治理各调用方对不同 AuthN 插件的调用凭证：
能够将整个域名或者域名下的特定路由，受权给不同的调用方：
API 的凋谢鉴权是企业做 API 治理的要害能力，Erda Cloud 心愿能更好地满足这部分需要，让提供者更不便地凋谢 API；让调用方能自主申请调用，主动获取凭证和 SLA 配额限度；进而整体晋升 API 治理的效率。Erda Cloud 基于此云原生网关能力，推出了面向 API 全生命周期治理的产品。
Erda Cloud API 治理产品
Erda Cloud API 治理产品由三个模块形成：API 设计核心、API 集市、API 拜访治理。
接口提供者在 API 设计核心进行接口设计，而后公布到 API 集市；接口调用方在 API 集市中寻找接口，申请调用凭证和 SLA 配额；接口提供者或者管理人员，在 API 拜访治理中受权调用方拜访，同时能够审计剖析来自各个调用方的申请流量。
API 设计核心
市面上一些 API 设计产品，会要求用户充沛理解 swagger 2.0/openapi 3.0 协定，要逐字地敲出一篇文档；另一些产品尽管反对以比拟敌对的形式设计 API，但没有采纳标准协议，其输入的文档失去了通用性。
Erda Cloud API 设计核心基于可视化的编辑形式，通过直观而敌对的交互界面，用户无需理解任何 REST API 标准规范，也无需具备任何对于 API 描述语言的常识，就能够轻松编写出一份具备业余程度的 API 文档。同时采纳 openapi 3.0 协定规范，任何时候都能够交付、迁出文档，一次设计，随处应用；在其余平台托管的 API 文档、代码中生成的 swagger 文件等，也都能轻松迁徙上来。
Erda API 设计核心将 API 文档托管到代码仓库中，这一设计使得接口形容和接口实现代码关联在一起。开发人员进入代码仓库，抉择对应的代码分支，保护接口文档，能够很好地放弃文档和新开发性能的同步。这样的理念遵循了 GitOps 配置即代码的思维。
文档托管到仓库中，还意味着能够基于分支进行文档合作。不同用户编写同一篇文档时，只有从源分支切出新的分支，在新的分支上编辑文档，而后再进行分支的合并。同一服务不同接口的负责人，随时能够设计本人负责的接口，又随时合并回去，不会相互影响和阻塞。
API 集市
API 集市是 API 的门户，用来公布、归档、公开以及调试 API。API 提供者将设计好的文档公布到集市，以便后续治理、监控。API 使用者在 API 集市查阅、摸索、调试、订阅 API。集市是 API 所有者和使用者实现“交易”的中央。
API 集市应用了语义化版本机制来实现 API 文档的版本治理。版本号格局形如 major.minor.patch，其中：
- major 为主版本号，主版本号的变动通常示意产生了重大变更或不向下兼容的变更。
- minor 是次版本号，次版本号的变动通常示意减少了新个性，仍向下兼容。
- patch 是订正号，订正号的变动通常示意对现有版本作较小的、部分的修改。
除了语义化版本号外，还有一个称为“版本名称”的版本标记，它个别是有自解释性的单词或短语，示意以后文档版本的命名。版本名称与语义化版本号中的 major 是惟一对应的，版本名称能够视作是主版本号 major 的别名。比方 macOS 的某个版本号 Big Sur 11.2.2，其中“Big Sur”是操作系统的版本名，“11”是该版本名对应的主版本号，2.2 别离是次版本号和订正号。这样版本化治理的益处是，将 API 文档的增长与应用程序的增长厚此薄彼，能够从 API 的角度扫视应用程序的性能。版本号解释了服务更迭间的兼容性和依赖关系，不论是所有者还是使用者，都能依据版本号语义清晰地理解服务的变更状况。
API 资源能够关联到 Erda Cloud 上具体的服务实例地址。通过这样的关联，API 提供方能够进一步实现 API 的拜访治理，调用方也就能够在 API 集市中申请调用并测试接口。
API 拜访治理
API 拜访治理是指在向内部凋谢接口时，对被调用的 API 进行治理、爱护和审计。向外凋谢 API 时，往往须要甄别、束缚以及审计客户端行为，此时就要为 API 资源创立拜访治理。拜访治理的具体伎俩是客户端认证鉴权和 SLA 配额治理。
API 提供者在集市中将 API 资源与 Erda Cloud 上具体的服务实例地址关联之后，再为 API 资源创立拜访治理，调用者就能够在 API 集市中申请调用该 API；提供者收到调用申请后进行审批，为客户端设置 SLA 配额；获批的客户端取得拜访资质，就能够从内部拜访接口了。尔后，调用方还能够在拜访治理中切换 API 版本，将申请转发到不同版本对应的服务实例上，从而在客户不感知的状况下进行 API 版本的降级或回滚。
API 拜访治理的性能都是基于 Erda 云原生网关产品的能力实现的，相比间接应用网关的配置能力，应用 API 拜访治理简化了很多 —— 用户仅仅跟 API 打交道。
调用量审计剖析
API 提供方治理客户端和 SLA 配额
调用方申请 API
API 全生命周期治理最佳实际
基于 Erda Cloud 的 API 治理产品，能够实现 API 全生命周期治理的最佳实际。如下图所示，能够别离从 API 的提供者和调用方两个视角来看对待。
从 API 提供者的视角来看：首先须要追随服务性能变更，及时更新 API 设计核心的文档，因为文档也基于代码仓库治理，能够通过 code review 的形式确保 API 文档的及时同步。在开发联调阶段，API 提供者能够将 API 文档公布到集市，依赖此接口的其余模块性能就能够并行开发。如果有 API 对外开放的需要，API 提供者就为对应的 API 资源设置拜访治理性能，在拜访治理控制台能够实时观测内部的调用流量。
从 API 调用方的视角来看：如果是测试工程师，应该基于开发人员提供的 API 文档，进行自动化接口测试用例的设计，而不是保护一份测试专用的接口文档。如果是内部集成方，通过 API 集市去发现所需的性能接口，申请调用胜利后，应该在 API 集市进行简略的接口拜访测试，确认性能合乎预期；而后依据 API 文档进行集成模块的代码编写、部署；最初能够在“我的拜访”中查看调用流量。
软件在本人的生命周期里一直迭代变动，API 也是一样。无论 API 提供者还是调用方，都要器重 API 迭代的影响。提供方要严格遵循 API 集市的语义化版本机制，当呈现 Breaking Change 时，应该为新的 Major 版本创立独立的拜访治理入口，并将旧版本标记弃用，疏导调用方应用新的版本；调用方应该及时关注订阅告诉，理解所应用 API 文档的最新版本状况。
Erda Cloud 的 DevOps 性能提供了云原生场景下 CI/CD 能力，应该把 API 治理也视作 CI/CD 的一部分。能够应用 Erda Cloud 的自动化测试平台，对接 API 集市，在 CI 流程中退出自动化接口测试；能够应用 Erda 的流水线扩大，在 CD 流程后主动公布 API 版本，并主动关联上服务的 K8s Service 地址。
Erda Cloud 为企业基于云原生进行零碎架构提供了一站式服务，Erda Cloud 的 API 治理亦是在云原生的土壤上天然成长出的产品。API 全生命周期治理作为企业数字化的要害一环，企业如果采纳云原生的架构，肯定要抉择与之符合的 API 治理产品，否则可能导致适配老本的减少和管理效率的低下。
欢送从咱们的官网 erda.cloud 理解更多对于 Erda Cloud 产品的最新资讯。也欢送关注咱们的 Github repo，咱们的代码曾经全副开源，期待你的 star ~~~
欢送参加开源
Erda 作为开源的一站式云原生 PaaS 平台，具备 DevOps、微服务观测治理、多云治理以及快数据治理等平台级能力。点击下方链接即可参加开源 ，和泛滥开发者一起探讨、交换，共建开源社区。 欢送大家关注、奉献代码和 Star！
- Erda Github 地址：https://github.com/erda-project/erda
- Erda Cloud 官网：https://www.erda.cloud/
