多雲和混合雲場景下的 API 管理：挑戰與選擇

作者張超，API7 Cloud 產品負責人，Apache APISIX PMC 成員。

原文連結

一、多雲和混合雲

如今微服務已經成為最流行的一種軟體架構，人們通過自己對業務的理解，和科學方法（比如領域驅動設計的理論）的加持將組織對外提供的產品拆分為一個個微服務，同時按照微服務的架構調整組織架構（逆康威定律）來開展業務的迭代。

以往組織習慣於自建資料中心來部署自家的產品，這些資料中心可能構建在買斷或者是租賃的機房中，組織需要對機房的裝置進行復雜的管理，包括交換機、伺服器、磁碟、機櫃等這些硬體設施，以及應對因為機房掉電、機櫃溫度過高、伺服器崩潰等帶來的故障。應對這些要問題往往會花費大量的人力財力，同時達不到很好的效果，使得自己產品的 SLA（服務等級約定）往往無法達到對客戶的承諾，從而造成賠償。

隨著雲的興起，人們越來越習慣於將自己的業務部署到公有云之上，公有云幫助使用者遮蔽了硬體的細節，工程師再也不用關心基礎設施的搭建和維護問題，而是可以把自己的精力盡可能得放到業務的部署、維護和開發之上。然而，除了享受雲帶來的便利以外，雲的興起和使用也給使用者帶來了其他的一些問題：

• 被“鎖定”，當深度使用了雲上某產品後，導致業務無法輕易遷移到其他的雲，或者是從雲上離開。這種情況特別發生在使用雲提供的 PaaS 或者 SaaS 產品，然後與自己的業務發生了強繫結。通常因為在選購產品時，業務正處於高速發展的階段，決策人往往忽略了使用雲產品所帶來的捆綁效應。
• 可用性問題，大家都懂得“不要把雞蛋放在一個籃子裡”的道理，然後在業務上升期時，組織考慮的是快速上線產品，佔據市場，對於基建的考慮往往是不足的，在這樣的情況下，如果發生雲某某區域機房掉電、光纜被挖斷等問題，就會對業務造成影響。 於是現在人們越來越習慣於同時使用多種公有云或者除了使用雲以外，額外再搭建私有云的方式，來規避上述提到的問題。這就是我們常說的“多雲”和“混合雲”。

“多雲”指的是同時使用多種公有云，將業務映象地、或者異構地部署到這些雲上，同時儘可能採用標準服務（避免廠商鎖定）。因為使用了多種雲，當某個雲出現不可用的情況下，它對業務的影響能夠被縮小，甚至通過 DNS 修改解析等方式，啟用備份的雲，從而確保業務的連續性。“混合雲”指的是組織除了使用了一個或者多個公有云以外，還擁有自建的私有云（或者資料中心），在此場景下，部分業務可能部署在私有云，其他的可能都已經上公有云，或者所有業務都在雲上，而私有云負責管理和監控。總之，在採用了“多雲”或者“混合雲”這樣的模式後，在提升服務可用性的同時，軟體部署方式的靈活性也大大提升。

然而，在應用“多雲”和“混合雲”後，如何高效、簡單的管理雲上的微服務，則變得更加棘手。這當中比較經典的要屬 API 的管理了，如今大量的微服務都選擇使用 API 這一方式來進行互動，當微服務部署之後，它們提供的 API 需要能夠被暴露到外部，以便和外部的呼叫方連線，從而提供服務。

二、多雲、混合雲場景下 API 管理的需求

我們知道對於管理微服務 API 而言，一款好的 API 閘道器是必不可少的，API 閘道器能夠安全、高效地將微服務 API 暴露出去，然而，採用“多雲“，“混合雲”這樣的模式後，對於 API 閘道器的需求不僅僅侷限在 API 閘道器自身的功能是否滿足業務的需求了，具體來說，我們需要考慮：

是否支援多叢集管理

正如前文所述，在採用“多雲”或者“混合雲”，後，每個雲或者私有資料中心所部署的業務可能存在著比較大的差異，因此使用者需要在這些雲上分別部署一套套的 API 閘道器叢集，且可想而知這些閘道器叢集的配置、證書、API 金鑰等可能不盡相同。如果使用者選擇使用的閘道器不支援多叢集的管理，可能會對 API 的管理造成很大的麻煩，尤其是在業務擴張期，API 閘道器叢集規模越來越大，數量越來越多的時候。

在這種情況下，一款支援多叢集管理的 API 閘道器產品 便能極大地降低管理員的管理成本。

1. 使用者擁有一個統一的控制檯，並且在該控制檯中可選擇當前需要配置和檢視的叢集，並且可以根據實際業務的部署情況，上線或者下線一個閘道器叢集。
2. 使用者可以控制檯上檢視所有這些 API 閘道器叢集的執行狀態，包括常見的 QPS、延遲、閘道器叢集 CPU 和記憶體佔用率等。

是否支援協作

由於業務的快速發展，少數幾個 API 閘道器管理員可能無法承擔起維護全部 API 閘道器叢集的重擔，同時考慮到大部分的閘道器配置，比如新增路由、為路由配置外掛等，可以由開發者自行處理，不需要全部由管理員經手。因此，是否支援“協作”對於管理來說，也變得重要起來。具體來說，管理員可以邀請組織內的其他成員加入到該 API 閘道器叢集的管理中，同時使用 RBAC 之類的策略為大家分配不同的許可權，比如為管理員設定 Organization Admin 的角色（可以執行任意操作），為普通開發者設定為 Service Admin 的角色（僅可維護少數幾個服務和路由），進而在實現協作的基礎上確保操作安全，並且在員工離職或者出現崗位變動時，及時回收賬號或者修改許可權。

試想如果不支援協作，那麼大概率一個組織內的成員會共享一個賬號，這種用法在初期可能具備一定的便利性，但是時間一長它的潛在危害就會暴露出來，比如某員工在離職後可能依然可以登入並進行配置，甚至一些不懷好意的員工可能會選擇刪除全部資料，這對於組織對外的產品和服務來說是災難性的。而且在進行復盤時，管理員甚至無法將具體的操作和具體某個成員關聯起來，因為大家共享同一賬號（即便是保有審計日誌的情況下）。

是否可執行在任何基礎設施上

隨著容器化和容器編排的技術越來越成熟，以往很多執行在虛擬機器之上的微服務都紛紛轉投了 Kubernetes 的懷抱，這就意味著，使用者可能會選擇使用 Kubernetes、傳統的虛擬機器、甚至是物理機（比如在自己的私有資料中心裡）。如果使用者選擇的 API 閘道器產品在功能上非常豐富，能夠滿足業務需求，但是又受限於底層基礎設施，或者缺乏成熟的安裝工具，這樣會讓使用者處於兩難的境地，要麼放棄使用，要麼自行進行二次開發從而使得該 API 閘道器獲得執行在某個基礎設施之上的能力。無論如何，這都會帶來使用上的成本。

三、選擇

結合上文所述，在“多雲”和“混合雲”的場景下，如何選擇 API 閘道器則變得極其重要，這裡列舉了幾種常見的選擇，使用者應該根據他們的實際場景和發展的考慮來進行分析。

不同雲不同方案

通常來說每一家公有云廠商都會提供其內建的 API 閘道器解決方案，使用者可以根據現有產品的開發規格對雲上的 API 閘道器方案進行選型。

優點如下：

1. 使用成本極低，無需部署，無需維護
2. 通常支援按需付費，早期使用可能只需要極低的費用

缺點是：

1. 往往不同雲的 API 閘道器使用方式相互不相容，完成同一種配置需要經歷不同的路徑
2. 各家的產品功能不對稱，比如 A 廠商可能支援 mTLS，而 B 廠商不支援
3. “混合雲”場景下，可能需要再選擇一款開源的或者商業化的 API 閘道器，部署在使用者自己的私有云上

採用該方案時，如果想要獲得一致的使用體驗，可能需要基於不同的解決方案進行產品化，開發一個配置同步產品，遮蔽底層的細節，這裡可能需要使用者自行進行調研，分析以及開發（但可能會遇到相容性問題，功能受限，只能使用幾個 API 閘道器產品的交集功能），且需要考慮同步失敗情況。

當然，使用者也可以選擇手動重複配置每一個雲上的 API 閘道器（如果可以忍受的話）。

使用開源解決方案

考慮到在不同雲使用不同方案的缺點，使用者也可以考慮使用開源的 API 閘道器解決方案（如 Apache APISIX, Kong, Tyk, Traefik 等），這樣的好處是，你可以在每個雲（包括私有資料中心）上使用同一種 API 閘道器，從而避免了不同解決方案之間的相容問題。且一個成熟，生態強大的開源的 API 閘道器可以幫助使用者解決很多場景的問題，即便不能覆蓋全部的場景，這些 API 閘道器通常也允許使用者通過多種不同的方式進行擴充套件，比如 Apache APISIX 允許使用者通過使用 Go、Java、Python、Lua、WASM 等語言和技術進行擴充套件。

然而這些開源 API 閘道器通常採用 Open Core 的開源策略，產品中的核心功能都開源了，但是面向企業級的管理能力，如視覺化控制檯、多叢集管理、審計、SSO 等功能往往是收費的（整合在它們的商業產品中），這就導致如果使用者不希望向他們付費，只能選擇自研一套管理平臺（也稱為閘道器的控制面）來管理這些 API 閘道器。這可能意味著使用者需要為此招聘一名全職的工程師負擔起這部分的開發工作。

購買企業級 API 閘道器 SaaS 服務

如果開源的 API 閘道器在功能上滿足需求，但是因為無法接受自研控制面的成本的話，使用者也可以考慮聯絡這些開源軟體的原廠（如 Apache APISIX 背後的原廠 API7.ai，Kong 背後的原廠 Kong inc，以及 Tyk 背後的原廠 Tyk inc 等），這些原廠往往會提供不同的企業級 API 閘道器產品和支援服務。尤其在“多雲”和“混合雲”的場景下，這些原廠相繼都發布了他們的 SaaS 產品。API 閘道器的 SaaS 產品往往聚焦在管理側，提供開箱即用的控制檯，而不關心 API 閘道器例項具體部署在哪裡（當然，某些 SaaS 服務也支援託管 API 閘道器例項，但這往往也會引入其他問題，比如代理 API 時的延遲）。

SaaS 服務通常會為每個租戶託管一個使用者獨享的閘道器控制面，然後將使用者部署的（或者 SaaS 服務託管的）閘道器例項進行連線（往往會使用 mTLS 等策略確保資料的安全性、隱私性），進而對它們進行管理。雖然購買 SaaS 服務需要花費一定的金錢，但是相比於招聘專職的工程師維護一個 API 閘道器和它的控制面，這些支出可能會更低。

當然，採購 SaaS 服務需要謹慎，使用者確認訂單前，應該從下面幾個方面對一個 SaaS 服務進行評估：

1. 這個 SaaS 服務是否能滿足現在以及未來一段時間的使用需求？
2. 這個 SaaS 服務廠商是否專業誠信？他們擁有哪些使用者案例？
3. 這個 SaaS 服務是否合規，符合 GDPR，擁有 SOC2 審計報告？
4. 這個 SaaS 服務是否有明確的 SLA 條款？
5. 這個 SaaS 服務是如何收費的？使用者是否可以預估未來一年或者幾年的支出？

完全自研

如果開源的 API 閘道器解決方案無法滿足使用者的實際場景，使用者可能選擇考慮完全自研專屬於他們的 API 閘道器產品，但這往往費時費力，且閘道器本身的穩定性也是一個重大問題。研發一個 API 閘道器雖然不像實現一個關係型資料庫或者瀏覽器那麼難，但也不是一朝一夕就可以完成的，因此完全自研可以認為是“最壞的策略”。往往只能作為最後的選擇。

四、總結

在雲原生的大環境下，在“多雲”和“混合雲” 的場景下進行 API 的管理將會成為每一個組織發展時將面臨的一個問題，甚至在沒有采用“多雲”和“混合雲”之前就應該開始未雨綢繆。 儘管本文給出了幾種不同的選擇，但是需要謹記的是，它們之中沒有“銀彈”，使用者應該根據業務的實際情況和發展方向選擇一個“目前看來最合適的方案”。

關於 API7.ai 與 APISIX

API7.ai 是一家提供 API 處理和分析的開源基礎軟體公司，於 2019 年開源了新一代雲原生 API 閘道器 -- APISIX 並捐贈給 Apache 軟體基金會。此後，API7.ai 一直積極投入支援 Apache APISIX 的開發、維護和社群運營。與千萬貢獻者、使用者、支持者一起做出世界級的開源專案，是 API7.ai 努力的目標。