深入了解雲計算OpenAPI體系

作者 | 虛明

來源 | 阿裡技術公衆号

一 導讀

提到API從事技術的同學都十分熟悉，無論是在作業系統上開發軟體，還是打造分布式網絡服務，都離不開對各種API的調用。對應用程式開發人員來說，都會通過各種程式設計語言、系統調用和各種類庫、程式設計架構建構系統，為了提升開發效率和統一性，就出現了各種各樣的API标準，例如POSIX。這些标準的實作保障了應用程式可以不做過多修改就能運作在各種軟硬體平台上，大大促進了整個IT生态的發展。

然而就雲計算的API來看，目前并沒有類似POSIX這樣的API标準，基本上各大廠商各自為政。當然，有一些業界主流标準例如OAS獲得多數雲廠商的支援，但雲廠商本身的API卻往往由于曆史原因、技術路線原因百花齊放，例如AWS的OpenAPI屬于RPC風格，而Azure則是WebService風格，GCP則是基于gRPC為主流。技術方面的論述很多，本文更想從客戶體驗、研發效能的角度來闡述OpenAPI對雲計算整體競争力的重要性。

二 雲計算OpenAPI的特點

如果将阿裡雲飛天作業系統與傳統作業系統類比，那麼它也是由核心層、接口層、操作界面、業務應用組成，計算、存儲、網絡等核心産品構成了核心，API層承擔核心的管控和資料通信，各式各樣的控制界面則相當于作業系統的Terminal/Windows/mac OS UI，基于雲計算的各種行業應用則是跑在這個作業系統上的應用。

圖1 飛天作業系統

阿裡雲不同于傳統作業系統，OpenAPI自然也不同于其他業态的API體系，例如淘系、b2b的開放平台。業務開放平台輸出的是以業務資料為主的服務，目的是為了整合商業生态，而阿裡雲開放平台輸出的是雲作業系統的管控能力、資料操作能力和其他企業級能力。前者重心是服務商業模型，而後者重心是服務技術底座。是以，雲計算的OpenAPI體系要以服務技術開發者和企業場景為中心，保障技術體系的健全穩定，對外緊密對接行業技術體系（例如開源工具、三方廠商），對内促進衆多雲服務協同管理。

阿裡雲的OpenAPI有如下特點：

• 數量多：目前阿裡雲OpenAPI數量高達1萬多個，每天調用量上百億，分布在近300個産品上。
• 增速快：業務發展快，近年來每年數量的增速接近100%。
• API類型多：OpenAPI大體分為管控、資料兩類，管控類又分為RPC/ROA兩種形式，資料類又會分為資料流、檔案等具體類型，還有很多業務需要有自己的格式。
• 産品協同要求高：單個OpenAPI是不能滿足使用者要求的，場景化的使用者需求需要多個産品的多個OpenAPI組合才能服務，這對API編排、産品間API協同提出了更高的要求。例如在穩定性方面，一個産品的OpenAPI出問題有可能造成整個管控鍊路的雪崩。
• 企業能力需求強烈：OpenAPI主要是用來進行雲資源管理或資料傳輸的，操作對象都是使用者資産，除了正常的身份管理、權限管理外，對企業來說還要服務于運維、财務、法務、監管等部門，當涉及衆多的雲産品時對架構和底層設施的完備性、準确性、及時性要求很高。
• 與行業技術趨勢結合緊密：雲是全球化的，作為平台它要想服務好各種場景、人群就離不開與各種業界标準和技術體系相結合，雲計算與開源行業高度結合證明了我們做的技術不能閉門造車。
• 穩定性風險加大：商業開放平台的OpenAPI如果不穩定影響的可能隻是客戶側某個業務功能子產品或流程，但是雲OpenAPI出問題影響的可能是客戶底層技術系統，爆炸半徑會更大。
• 調用熱點集中：調用量分布基本符合二八原則，20%的雲産品承擔了80%的調用量，核心産品的體驗決定了使用者對阿裡雲的體感，保障客戶典型場景的運作至關重要。

上述特點決定了雲上的OpenAPI相比于傳統開放平台，要側重技術能力的建設，同時又要兼顧客戶企業級場景，才能做好體驗工作。

圖2 OpenAPI使用者需求層次

三 管理自動化是企業客戶的核心訴求

那麼雲計算客戶在OpenAPI領域核心體驗是什麼？以阿裡雲上某實際案例來分析，具體要點包括：

• 客戶希望全部的流程都是能夠自動化的，從代碼送出到伺服器部署全部通過自動化工具進行。
• 許多客戶希望使用混合雲體系，雲上雲下兩部分結合，業務系統與雲平台緊密內建。
• 客戶系統中大量使用多種開源軟體，例如git/Jfrog/Terraform等，希望能夠整合形成完整的自動化流程。

總結起來客戶的核心訴求是：客戶業務系統要能夠與雲平台高度自動化地內建。不僅是客戶，雲廠商經常強調彈性、自愈等概念，其背後也是高度自動化的架構在支撐。

要做到高度自動化地內建，對OpenAPI體系是全方位的要求。對比一下POSIX，一套标準的、完備的、品質良好的API能夠促進各作業系統之間的相容性，確定上層應用的開發移植成本最低。而對于雲計算，這樣的規範應該在哪幾個方面來滿足客戶的需求呢，實踐中我們總結如下：

• 風格一緻性：POSIX API的風格基本是一緻的，例如檔案處理API，其核心錯誤碼都是一緻的。一緻的風格、術語、錯誤、操作模式，可以讓應用程式開發者降低了解成本，提升效率。而如果不同産品API設計風格不一緻，使用者了解成本很高，使用不便，就會對雲平台專業性産生質疑。例如，目前阿裡雲的OpenAPI就存在專業術語在不同産品中描述不一樣，同樣的資源資訊各産品屬性和資料不一緻，分頁API的形式不一緻，甚至大小寫命名也不一樣的問題。
• 功能完整性：功能完整其實不難了解，但是如何定義功能完整性一直有争議，一個雲産品是開放10個API就夠了，還是開放100個才夠？有點見仁見智，況且産品也是在一直演進的。POSIX檔案處理涵蓋了一套标準的檔案處理API，包括create/close/dup/dup2/fcntl/flock/fsync/lseek/mkstemp/open/read/sync/write等 API，所有關于檔案操作可能的API都存在了，這樣使用者才能精細控制檔案。是以對于雲上資源，由于客戶需要對其進行全生命周期自動化管理，那麼客戶視角的所有管理動作都應該被開放。在實踐中一般用實體關系模型去設計一組互相配合的API，不可随意零散處理。

• 服務有效性：實踐中最大的問題是不同團隊對于API SLA的标準不一樣。例如在可用性上有些産品要求99.99%，有些産品覺得99%也能接受。極端的例子，如果某些OpenAPI隻能允許一個并發，這樣的OpenAPI對使用者來說是沒有服務品質可言的，自動化也會因為各種異常被終止。同時，如果必須某些限制，例如限流，ToB場景下是要告知客戶的，否則用戶端将不知道如何去優化自己的調用頻率。

• 配套體系健全性：客戶體驗是客戶從知曉到使用産品的心理感受的全過程。Linux/Mac上的開發體驗很優秀是因為配套的工具鍊很成熟，具備完整的體系。雲上客戶基于OpenAPI開發時也應該能夠擷取專業的、詳細的工具支援和技術支援，就像visual studio要有MSDN，java開發要能夠有IDE，任何語言都需要debug工具一樣。像SDK、文檔、調試工具是必備産品，同時諸如代碼示例、API調用可視化等功能也是非常有價值的。

除此之外，雲計算内部系統也需要通過API實作高度自動化。一些典型的場景例如專有雲部署、新region擴建、單産品擴容，如果不能夠自動化部署，對公司整體人效是不利的，更重要的是實施時間會拉長，客戶體驗也會變差。

要解決上述問題，主要難點在于如何統一标準、如何建立全面的配套平台體系、如何衡量服務品質、如何持續推動服務達标以及如何考察客戶體驗。

四 雲計算需要面向資源程式設計

Linux/UNIX世界中，有個著名的說法： 萬物皆可檔案化。那麼雲上的萬物能否資源化呢？

阿裡雲對外的OpenAPI都是基于HTTP協定，restful規範有提出基于資源設計的理念。 而實際工作中，能堅持這樣的原則的API卻不多。經常會碰到的疑問是“什麼樣的東西應該定義為資源？”“我的API沒有資源化設計不也工作的挺好？”“我設計的時候有資源概念，但是客戶沒這需求啊？”。

然而，客戶的困惑卻是真實存在的：

• 想自建一個資源管理系統，阿裡雲上怎麼能知道我擁有的所有資源清單？
• 那如果通過OpenAPI擷取，怎麼能知道這個API對應的是什麼資源，資源能做什麼操作，資源與資源之間有什麼關系呢？
• 不同的産品在同一個資源類型情況下，怎麼傳回的屬性不一樣啊？
• 想查詢不同産品若幹資源的組合狀态，目前一個個寫代碼太麻煩了，有什麼好辦法麼？
• 自己去理那麼多API對應的資源類型工作量太大了，能不能說說阿裡雲自己是怎麼做的？

面對客戶的需求，我們需要回答幾個問題：

• 什麼是資源？哪些資源應該被管理？無需管理的服務是否也要被定義為資源？
• 阿裡雲到底有哪些資源類型，統一的清單在哪裡？能不能通過OpenAPI自動化擷取？
• 這些資源類型的屬性是怎樣的？能做什麼操作？對應的API是什麼？資源有哪些狀态？資源與資源之間的關系是什麼？能不能保證資源都是一緻的？
• 用什麼方法能夠面向資源程式設計減少開發成本？

對于雲計算場景，如果沒有資源模型，内部研發效率也會受到影響。原因是企業客戶不同于個人客戶，相對成熟的企業都對人、财、物、權、法的監管需求強烈，面對内部管理、盈利、監管限制等挑戰，一套成熟的IT治理體系對資源概念的依賴是極高的，如阿裡雲的RAM/ActionTrail/Config/RD/ResourceManager等。沒有資源模型，這些産品就要各自定義資源，分别找雲産品溝通，實施落地進度和品質也不能保證一緻。開源軟體也一樣，例如terraform就是面向資源的。甚至很多平台服務如賬單，也需要資源的概念才能更好地管理。

圖3 資源生産者和消費者

如果能夠統一資源模型，就相當于客戶和阿裡雲在有一套面向對象的Java類或者資料庫表，凡是依賴該資源模型的産品都将從中受益，了解更容易，溝通上保持一緻性，研發上可以提供統一的技術方案提高效率。

是以，面向資源程式設計的API設計，對于客戶和雲平台自身都是非常重要的，如果前期不考慮，後期會付出更大的成本，必将影響阿裡雲整體服務品質。

五 雲計算需要沉澱統一的OpenAPI/資源中繼資料

中繼資料是關于資料的資料，它描述的是資料組織、資料域及其關系的資訊。中繼資料平台并不是新鮮事物，比如在大資料領域就有很多應用。由于阿裡雲有數百個産品，上萬個OpenAPI，是以資源的數量也必定是龐大的，這時候就有必要有一個統一的平台來管理資源資訊。而資源隻是一種抽象，背後還需要依賴 OpenAPI的中繼資料，兩者結合才能對外提供完整的服務。

那麼統一OpenAPI/資源中繼資料能帶來哪些價值呢：

1.促進産品體驗一緻性：阿裡雲各個産品線獨立發展，但是會面臨此資源非彼資源的尴尬境地，每個産品都有自己的認識，非常不利于統一客戶體驗。

2.提升溝通效率：統一的模型就像一個标準的資料庫schema，能夠讓相關的業務方都能夠在一個語境中溝通。

3.提升研發效率：結構化的标準模型，能夠讓程式代替人來處理模式化的資料；以Terraform為例，有了資源中繼資料，可以直接編寫自動化腳本生成terraform子產品，将雲産品的接入效率提升了50%左右，過程中就節省了go語言研發資源和聯調成本。

圖4 基于API中繼資料無代碼自動化生成

4.提升業務品質持續保障：軟體研發有個痛點是雲産品初次釋出後，如果随着業務疊代，如何保障過往的功能正确性。以阿裡雲的RAM産品為例，如果我們能夠将資源中繼資料、API通路日志、RAM的Policy與雲産品實際鑒權日志放在一起，通過對比中繼資料聲明内容與實際發生的動作，就可以檢查雲産品的鑒權行為是否符合預期。相比于人治，基于資料和代碼的自動化平台檢查機制會更高效、更準确。

5.更多的業務場景賦能：Azure有一個産品叫Resource Graph Explorer，它能夠按照資源次元管理平台上所有的資源，跨地域也不是問題，有點類似于windows的資料總管。完善的中繼資料管理，将使得這類産品的研發變得可能。可能有人會有疑問，沒有中繼資料就不能做嗎？理論上可以，但是一定是事倍功半，因為它需要與各産品反複協調溝通，成本極高，而不是用一套平台來承載着标準化的生産流程，且不好複用，不可同日而語。

是以統一的阿裡雲OpenAPI/資源中繼資料管理，對内價值是許多圍繞資源的業務開發都将變得更加輕松，甚至無代碼化，提升業務效能，對外客戶将能得到與内部一緻的業務模型，提升使用者體驗，更加友善地內建。

六 OpenAPI體驗是雲客戶的核心體驗之一

雲作業系統想服務好客戶，經過優良設計的API是必需品，否則使用者很難快速高效地基于API層來開發和部署應用服務，會對商業競争力造成嚴重影響，一個各種理念能力都是頂級但卻難以管理的作業系統誰願意使用呢？

1. OpenAPI是雲産品的服務契約。雲平台不但要保障服務品質，而且一旦上線下線極難，産品很難冒風險去強行關閉某個API，不相容變更也不行，等同于違約，有可能造成客戶業務系統的崩潰，随後就是法律風險、輿情風險和客戶流失。
2. OpenAPI的成熟度很重要。客戶在使用雲服務的時候貨比三家，除了價格、穩定、功能等因素外，是否能夠快速、友善地與客戶業務系統內建是重要競争因素，阿裡雲接觸過許多大客戶都在API成熟度上有明确要求。
3. 良好的開發體驗和豐富的服務生态或将成為雲廠商的核心競争力。Windows靠視窗系統的體驗代差霸占消費級作業系統市場，Linux/Unix在windows環伺下靠企業級開發能力占據企業級市場，macOS的良好開發體驗又在windows一統天下的局面下殺出一條血路，都說明最終制勝必須圍繞客戶體驗展開。當各廠商在核心服務能力上随着時間的推移逐漸同質化之後，差異化競争力就在于價格、體驗、服務了，而現在國外競對在體驗上的優勢也是多年沉澱下來的護城河，不投入時間和資源來沉澱是不可能比肩的。
4. 客戶視角在雲計算場景下尤為重要。其邏輯不是我們有什麼接口可以開放，而是客戶需要我們開放什麼接口。功能接口開放度不足可能會導緻客戶的生産流程中斷，嚴重影響客戶的信心。
5. 符合行業規範的API更容易相容業界技術工具和合作夥伴，更容易為社群所接受。比如現在應該很難出現一個不支援POSIX标準的作業系統了，不相容就意味着沒有市場。草率設計的API會導緻業務難以和外部生态協作，如果又必須合作會對内部研發資源造成壓力，進而影響業務發展速度和商業競争力。
6. OpenAPI不僅僅是API的問題，配套的服務體系必須完善。看看Linux系統上的開發，并不是有個系統調用函數就OK了，需要文檔/代碼示例/各種調試工具，由此還衍生許多IDE工具。在阿裡雲上這種全鍊路服務還比較薄弱，客戶碰到問題要麼反複提工單對公司服務資源造成很大壓力，要麼服務不滿意客戶用腳投票影響阿裡雲口碑，損害公司長期競争力。

是以，OpenAPI不止是技術問題，也是産品問題，是産品體驗的重要組成部分，需要慎重對待。

七 OpenAPI客戶體驗需要強大的體系支撐

那麼OpenAPI的客戶體驗能不能被度量？阿裡雲開放平台剛開始發力OpenAPI時面臨的最大問題是：客戶和内部都有人吐槽阿裡雲API不好用，都是點狀問題抛出和客戶需求驅動，沒有一個體系化的方法來衡量客戶體驗名額，且不能規模化解決問題。

阿裡雲的 OpenAPI數量1萬多個，點狀的、模糊的回報對解決全局問題沒有幫助，且使用者其實是對具體産品有概念，但針對OpenAPI概念性不強調研主觀偏差更大。

阿裡雲的OpenAPI體驗是一個全鍊路問題，如下圖：

圖5 典型OpenAPI使用者使用路徑

長長的鍊路，任何一個環節沒做好都有可能導緻使用者體驗不好，回報的資訊也是五花八門，難以抽取有效資訊。是以有幾個核心問題需要依次解決：

1. 什麼樣的客戶聲音是清晰明确的？
2. 如何能夠拿到這些客戶聲音，有哪些管道？
3. 如何處理這些聲音，如何清洗分類，如何定位根因，分析是哪個環節的問題？
4. 如何建立總體和細分量化名額，進而針對性治理，形成閉環？
5. 如何推動及營運？
6. 最終如何檢驗治理效果？

我們的做法是這樣的：

1 Step1 量化

1. 要有具體使用者問題： 能夠反映客戶具體問題的資訊過去主流是靠工單，但是工單回報的使用者隻是冰山一角，更多的資訊沒有被看到。電話、釘群資訊、網站回報等内容也應該被納入進來，這些資訊加起來就是一個個具體的問題，很多問題彙集在一起就形成了很有價值的大資料集，可以給資料化治理奠定資料基礎。
2. 擷取資料：我們嘗試聯系工單系統、内部平台、釘群等管道，需要拉通各個平台的資料。
3. 資料清洗：客戶、工單資料是非結構化資料，需要自然語言處理方面的技術，阿裡雲開放平台與達摩院合作，通過對特定目标分類輸入關鍵詞、打标簽等方式訓練AI，由AI對大量的資料進行自動化抽取、歸類、量化，對客戶聲音和根因進行較好的分類和量化。
4. 業務價值：通過根因分析得出客戶主要問題分類後，針對性地優化更新産品，以問題的機關使用者工單量為效果名額，來檢驗産品改進效果。有些問題是從趨勢中發現的，需要更新産品，例如客戶抱怨找不到SDK或API，我們就要優化API搜尋。有些問題是已知内部問題，例如API可用性問題，就制定機制去督促業務改進。
5. 改進效果衡量：首先要有具體名額，目前主要還是工單降量。但是我們覺得還不夠，因為工單隻是冰山一角，數量不夠多，也不夠細節，流轉周期也長。是以我們也嘗試收口OpenAPI開發者門戶，一方面标準化産品體驗，另一方面直接觸達終端客戶拿到最詳細的回報。比如，客戶的回報能夠詳細到當某個API的頁碼設定為0會導緻功能異常，文檔細節不對，必填非必填描述不對這樣的精準問題。

通過上述動作，我們能夠自動化分析出OpenAPI使用者的主要痛點，并建立數字化趨勢圖去跟蹤。

2 Step 2：治理

1. 有法可依：制定了《阿裡雲OpenAPI規範》，目前已經疊代到1.3版，涵蓋設計風格、服務品質、資源規範、域名規範、文檔規範等子項，在标準層面統一大家認知。
2. 執法必嚴：想要讓規範落地隻有文本不行，必須有配套的平台機制。
   • 收口阿裡雲所有API管理，從提升研發效率和全生命周期體系化管理的角度持續提升API管理平台的核心能力。
   • 将規範的審查規則沉澱到規則引擎中，使用者在開發API的時候自動化掃描檢查問題，不通過就打回。對于無法自動化限制的規範，建立稽核流程和管理層審批流程，提高不合規問題的生産成本，不斷提升自動化稽核比例。
   • 針對API的品質進行數字化治理，通過品質分量化評估各個BU各個産品API品質，定期同步督促改進。
3. 違法必究：聯合阿裡雲使用者體驗部門一起推動問題改進，并通過檢查使用者側工單降量情況來驗證效果。

上述能力，都沉澱在内部管理平台上，内部雲産品可以一站式管理API及流程化參與API治理過程。

3 Step3 産品化

目标是收口外部使用者的産品體驗。以前OpenAPI的各項功能是分散割裂的，FY21我們将所有與OpenAPI相關的功能內建正在一個産品中，即過OpenAPI開發者門戶 ，除了通過集中的産品建設提升使用者體驗外，還針對使用鍊路增加了troubleshooting、搜尋、codesample等子產品。

通過以上三步，我們整體OpenAPI體驗治理大圖如下：

圖6 使用者體驗管理閉環示意圖

通過這套體系運轉中發現的問題，都會通過API管理平台和API開發者門戶的功能上不斷的完善，去逐漸提升使用者體驗，從2020年的工單情況看，有比較明顯的下降。

八 總結

阿裡雲是個龐大的分布式作業系統，OpenAPI相當于使用者層操作核心層的重要通道，保障它的穩定、功能、性能、體驗關系到客戶的核心體驗，關系到公司形象和生态拓展，也關系到内部産品品質和研發效率，接入層必須做深、做厚、做強才能讓内外部客戶被服務好。從團隊兩年的實踐來看，數字化、體系化的做好基礎建設才能做好OpenAPI體驗。本文就雲上OpenAPI的幾個重要概念進行論述，希望能抛磚引玉，引起大家對OpenAPI體系價值的興趣和關注。

參考文獻：

1. https://apiacademy.co/2015/04/api-design-202-architectural-layers/
2. https://www.itread01.com/articles/1475911242.html
3. https://azure.microsoft.com/zh-cn/features/resource-graph/
4. https://maryamalshamsi98.wordpress.com/2014/05/21/linux-file-system-2/

存量應用快速遷移

本課程您将學習到如何快速将存量的應用遷移到雲開發平台，通過幾種常見的應用架構遷移的方法，讓存量應用快速實作雲原生架構的改造。1. Egg、Express、KOA等Node應用的遷移；2. SpringBoot、SpringMVC等Java應用遷移；3. PHP應用遷移；4. Python應用遷移；5. Midway一體化應用遷移。

點選這裡

，檢視課程詳情～