![頭圖.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1626138599858-87f62f95-4fa4-4f4d-a166-31ff0e040780.png#clientId=u1d2ac879-fa87-4&from=ui&id=u023d846a&margin=%5Bobject%20Object%5D&name=%E5%A4%B4%E5%9B%BE.png&originHeight=439&originWidth=960&originalType=binary&ratio=1&size=723327&status=done&style=none&taskId=u9e07347a-1ef0-48c0-9b70-c9d740ca145)
作者 ｜ 張添翼
來源 ｜ 爾達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。有人整理瞭如下這張表格：

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1623746847769-dc3d79d0-854a-456e-9380-2a6e6ba0c845.png#clientId=u8be59efb-61ac-4&from=paste&id=ue385136a&margin=%5Bobject%20Object%5D&name=image.png&originHeight=913&originWidth=1405&originalType=url&ratio=2&size=1247889&status=done&style=none&taskId=ud471b3f2-0b23-422b-af94-a7a197ddc71)

從表格中看到，這些 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 全生命週期管理魔力象限：

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1623746928029-f33d46ea-b083-4434-b9e4-06fcb5e9f55e.png#clientId=u8be59efb-61ac-4&from=paste&id=u573b72e7&margin=%5Bobject%20Object%5D&name=image.png&originHeight=580&originWidth=580&originalType=url&ratio=2&size=146520&status=done&style=none&taskId=u1144c060-78b7-4b1b-87d3-515cb7c6b7d)

如上圖所示，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](https://link.zhihu.com/?target=https%3A//github.com/kubernetes/ingress-nginx) 版本高於 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 是如何讓使用者做配置的吧。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/22499/1626076287060-ba1480e5-0a43-4bdc-ab4d-d469a7045c97.png#clientId=u8603efb4-9055-4&from=paste&height=731&id=u5de46e91&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1462&originWidth=2874&originalType=binary&ratio=1&size=635319&status=done&style=none&taskId=u04304066-03f6-43a7-a115-4223324e251&width=1437)

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} 。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1623747191165-0241ebfc-4fea-454b-bc81-c40566916b1e.png#clientId=u8be59efb-61ac-4&from=paste&id=u47fa2d74&margin=%5Bobject%20Object%5D&name=image.png&originHeight=681&originWidth=1440&originalType=url&ratio=2&size=215207&status=done&style=none&taskId=u93ee014e-ada8-4ca0-aab7-e27888f0f11)

然後再將指定域名的 URL 路由到這個微服務上，例如域名為 helloworld.erda.cloud，按照如下配置，當請求 helloworld.erda.cloud/api/example/assets/100 時，閘道器會將請求路徑改寫為 /api/assets/100 再轉發給後端微服務。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1623747210442-97900cbf-81ae-4b22-959f-ee5e3c797773.png#clientId=u8be59efb-61ac-4&from=paste&id=u0686c73b&margin=%5Bobject%20Object%5D&name=image.png&originHeight=731&originWidth=1440&originalType=url&ratio=2&size=229687&status=done&style=none&taskId=ua92ba648-a1fa-470c-805c-bee4e64b683)

這一功能是藉助於 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 外掛的呼叫憑證：

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1623747253675-118d5236-7165-474a-b370-2b84e7f2444b.png#clientId=u8be59efb-61ac-4&from=paste&id=u531ca3f2&margin=%5Bobject%20Object%5D&name=image.png&originHeight=668&originWidth=1440&originalType=url&ratio=2&size=228246&status=done&style=none&taskId=u92459c05-f30b-4a40-980f-6b551552701)

可以將整個域名或者域名下的特定路由，授權給不同的呼叫方：

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1623747264527-242c8905-277c-4cea-9f96-25b7f3f09318.png#clientId=u8be59efb-61ac-4&from=paste&id=ufa844051&margin=%5Bobject%20Object%5D&name=image.png&originHeight=667&originWidth=1440&originalType=url&ratio=2&size=197833&status=done&style=none&taskId=ufa0d5ea9-c764-4bbc-b290-12414bd2061)

API 的開放鑑權是企業做 API 管理的關鍵能力，Erda Cloud 希望能更好地滿足這部分需求，讓提供者更方便地開放 API；讓呼叫方能自主申請呼叫，自動獲取憑證和 SLA 配額限制；進而整體提升 API 管理的效率。Erda Cloud 基於此雲原生閘道器能力，推出了面向 API 全生命週期管理的產品。

# Erda Cloud API 管理產品
Erda Cloud API 管理產品由三個模組構成：API 設計中心、API 集市、API 訪問管理。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1623747275569-43ea4424-128d-411e-bb25-383c943bfa51.png#clientId=u8be59efb-61ac-4&from=paste&id=u5325f1cd&margin=%5Bobject%20Object%5D&name=image.png&originHeight=45&originWidth=388&originalType=url&ratio=2&size=9006&status=done&style=none&taskId=ub08be7ce-dce1-489e-ad46-3cc3deb62f2)

介面提供者在 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 檔案等，也都能輕鬆遷移上來。
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/332103/1626060195771-2885ae7f-5459-493b-9470-288cac38237a.png#clientId=u7c6e5771-cbaf-4&from=paste&id=uce3541fb&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1480&originWidth=2878&originalType=binary&ratio=1&size=656054&status=done&style=none&taskId=u13f6beff-7fa1-4126-9258-f092dfec6a0)

Erda API 設計中心將 API 文件託管到程式碼倉庫中，這一設計使得介面描述和介面實現程式碼關聯在一起。開發人員進入程式碼倉庫，選擇對應的程式碼分支，維護介面文件，可以很好地保持文件和新開發功能的同步。這樣的理念遵循了 GitOps 配置即程式碼的思想。

文件託管到倉庫中，還意味著可以基於分支進行文件協作。不同使用者編寫同一篇文件時，只要從源分支切出新的分支，在新的分支上編輯文件，然後再進行分支的合併。同一服務不同介面的負責人，隨時可以設計自己負責的介面，又隨時合併回去，不會相互影響和阻塞。

## API 集市
API 集市是 API 的門戶，用來發布、歸檔、公開以及除錯 API。API 提供者將設計好的文件釋出到集市，以便後續管理、監控。API 使用者在 API 集市查閱、探索、除錯、訂閱 API。集市是 API 所有者和使用者完成“交易”的地方。
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/332103/1626061681108-1dcf193f-16e3-4858-a3ef-ca241b979f26.png#clientId=u7c6e5771-cbaf-4&from=paste&height=1280&id=u7f9a0c11&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1280&originWidth=2557&originalType=binary&ratio=1&size=406074&status=done&style=none&taskId=u5009db69-b203-4677-9709-e60f6b88017&width=2557)

API 集市使用了[語義化版本](https://link.zhihu.com/?target=https%3A//semver.org/lang/zh-CN/)機制來實現 API 文件的版本管理。版本號格式形如 major.minor.patch ，其中：

- major 為主版本號，主版本號的變化通常表示發生了重大變更或不向下相容的變更。
- minor 是次版本號，次版本號的變化通常表示增加了新特性，仍向下相容。
- patch 是修訂號，修訂號的變化通常表示對現有版本作較小的、區域性的修正。

除了語義化版本號外，還有一個稱為“版本名稱”的版本標記，它一般是有自解釋性的單詞或短語，表示當前文件版本的命名。版本名稱與語義化版本號中的 major 是唯一對應的，版本名稱可以視作是主版本號 major 的別名。比如 macOS 的某個版本號 Big Sur 11.2.2 ，其中“Big Sur” 是作業系統的版本名，“11”是該版本名對應的主版本號，2.2 分別是次版本號和修訂號。這樣版本化管理的好處是，將 API 文件的增長與應用程式的增長一視同仁，可以從 API 的角度審視應用程式的功能。版本號解釋了服務更迭間的相容性和依賴關係，不管是所有者還是使用者，都能根據版本號語義清晰地瞭解服務的變更情況。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/332103/1626061938232-6363a1b1-8e93-48c9-b892-635ec51af517.png#clientId=u7c6e5771-cbaf-4&from=paste&height=1334&id=u82119a40&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1334&originWidth=2559&originalType=binary&ratio=1&size=354412&status=done&style=none&taskId=u987f1a4c-3f04-485d-8ecb-a1d8c852d32&width=2559)

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 打交道。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/332103/1626074029086-1f4ea12e-70b1-475e-82a9-b663dd4bda19.png#clientId=u7c6e5771-cbaf-4&from=paste&height=1586&id=uc1e719cd&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1586&originWidth=2876&originalType=binary&ratio=1&size=1000723&status=done&style=none&taskId=u6c4676d5-1b04-4abc-b926-e7827334882&width=2876)呼叫量審計分析

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/332103/1626074074577-4259ffc2-ac09-4652-ac4c-afc5081715ec.png#clientId=u7c6e5771-cbaf-4&from=paste&height=1588&id=uc8ec4c46&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1588&originWidth=2878&originalType=binary&ratio=1&size=814813&status=done&style=none&taskId=u89de5e0c-ce2d-4b4a-b70c-b86389ff752&width=2878)API 提供方管理客戶端和 SLA 配額
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/332103/1626068690435-2758150e-406c-4da8-8440-57172b4400e0.png#clientId=u7c6e5771-cbaf-4&from=paste&height=1584&id=u5071f99b&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1584&originWidth=2878&originalType=binary&ratio=1&size=804891&status=done&style=none&taskId=ua036bbf7-37e7-4717-9ea4-4b33064009f&width=2878)呼叫方申請 API
## API 全生命週期管理最佳實踐
基於 Erda Cloud 的 API 管理產品，可以實現 API 全生命週期管理的最佳實踐。如下圖所示，可以分別從 API 的提供者和呼叫方兩個視角來看看待。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1623747385663-1adb842d-d47a-4242-aa32-67d417782aaa.png#clientId=u8be59efb-61ac-4&from=paste&id=uaa12405f&margin=%5Bobject%20Object%5D&name=image.png&originHeight=223&originWidth=535&originalType=url&ratio=2&size=43816&status=done&style=none&taskId=ufce34d19-3931-4c8d-8914-0993a3dcb51)

**從 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](https://link.zhihu.com/?target=https%3A//www.erda.cloud/) 瞭解更多關於 Erda Cloud 產品的最新資訊。也歡迎關注我們的 [Github repo](https://link.zhihu.com/?target=https%3A//github.com/erda-project/erda)，我們的程式碼已經全部開源，期待你的 star ~~~

# 歡迎參與開源
Erda 作為開源的一站式雲原生 PaaS 平臺，具備 DevOps、微服務觀測治理、多雲管理以及快資料治理等平臺級能力。**點選下方連結即可參與開源**，和眾多開發者一起探討、交流，共建開源社群。**歡迎大家關注、貢獻程式碼和 Star！**
****

- **Erda Github 地址：**[_https://github.com/erda-project/erda_](https://github.com/erda-project/erda)
- **Erda Cloud 官網：**[_https://www.erda.cloud/_](https://www.erda.cloud/)

API 管理在雲原生場景下的機遇與挑戰

相關文章