深入理解云計算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/資源元數據能帶來哪些價值呢：
- 促進產品體驗一致性：阿里云各個產品線獨立發展，但是會面臨此資源非彼資源的尷尬境地，每個產品都有自己的認識，非常不利于統一客戶體驗。
- 提升溝通效率：統一的模型就像一個標準的數據庫schema，能夠讓相關的業務方都能夠在一個語境中溝通。
- 提升研發效率：結構化的標準模型，能夠讓程序代替人來處理模式化的數據;以Terraform為例，有了資源元數據，可以直接編寫自動化腳本生成terraform模塊，將云產品的接入效率提升了50%左右，過程中就節省了Go語言研發資源和聯調成本。
圖4 基于API元數據無代碼自動化生成
提升業務質量持續保障：軟件研發有個痛點是云產品初次發布后，如果隨著業務迭代，如何保障過往的功能正確性。以阿里云的RAM產品為例，如果我們能夠將資源元數據、API訪問日志、RAM的Policy與云產品實際鑒權日志放在一起，通過對比元數據聲明內容與實際發生的動作，就可以檢查云產品的鑒權行為是否符合預期。相比于人治，基于數據和代碼的自動化平臺檢查機制會更高效、更準確。
更多的業務場景賦能：Azure有一個產品叫Resource Graph Explorer，它能夠按照資源維度管理平臺上所有的資源，跨地域也不是問題，有點類似于Windows的資源管理器。完善的元數據管理，將使得這類產品的研發變得可能。可能有人會有疑問：沒有元數據就不能做嗎?理論上可以，但是一定是事倍功半，因為它需要與各產品反復協調溝通，成本極高，而不是用一套平臺來承載著標準化的生產流程，且不好復用，不可同日而語。
所以統一的阿里云OpenAPI/資源元數據管理，對內價值是許多圍繞資源的業務開發都將變得更加輕松，甚至無代碼化，提升業務效能，對外客戶將能得到與內部一致的業務模型，提升用戶體驗，更加方便地集成。
六 OpenAPI體驗是云客戶的核心體驗之一
云操作系統想服務好客戶，經過優良設計的API是必需品，否則用戶很難快速高效地基于API層來開發和部署應用服務，會對商業競爭力造成嚴重影響，一個各種理念能力都是頂級但卻難以管理的操作系統誰愿意使用呢?
- OpenAPI是云產品的服務契約。云平臺不但要保障服務質量，而且一旦上線下線極難，產品很難冒風險去強行關閉某個API，不兼容變更也不行，等同于違約，有可能造成客戶業務系統的崩潰，隨后就是法律風險、輿情風險和客戶流失。
- OpenAPI的成熟度很重要。客戶在使用云服務的時候貨比三家，除了價格、穩定、功能等因素外，是否能夠快速、方便地與客戶業務系統集成是重要競爭因素，阿里云接觸過許多大客戶都在API成熟度上有明確要求。
- 良好的開發體驗和豐富的服務生態或將成為云廠商的核心競爭力。Windows靠視窗系統的體驗代差霸占消費級操作系統市場，Linux/Unix在windows環伺下靠企業級開發能力占據企業級市場，macOS的良好開發體驗又在windows一統天下的局面下殺出一條血路，都說明最終制勝必須圍繞客戶體驗展開。當各廠商在核心服務能力上隨著時間的推移逐漸同質化之后，差異化競爭力就在于價格、體驗、服務了，而現在國外競對在體驗上的優勢也是多年沉淀下來的護城河，不投入時間和資源來沉淀是不可能比肩的。
- 客戶視角在云計算場景下尤為重要。其邏輯不是我們有什么接口可以開放，而是客戶需要我們開放什么接口。功能接口開放度不足可能會導致客戶的生產流程中斷，嚴重影響客戶的信心。
- 符合行業規范的API更容易兼容業界技術工具和合作伙伴，更容易為社區所接受。比如現在應該很難出現一個不支持POSIX標準的操作系統了，不兼容就意味著沒有市場。草率設計的API會導致業務難以和外部生態協作，如果又必須合作會對內部研發資源造成壓力，從而影響業務發展速度和商業競爭力。
- OpenAPI不僅僅是API的問題，配套的服務體系必須完善。看看Linux系統上的開發，并不是有個系統調用函數就OK了，需要文檔/代碼示例/各種調試工具，由此還衍生許多IDE工具。在阿里云上這種全鏈路服務還比較薄弱，客戶碰到問題要么反復提工單對公司服務資源造成很大壓力，要么客戶對服務不滿意，用腳投票影響阿里云口碑，損害公司長期競爭力。
因此，OpenAPI不止是技術問題，也是產品問題，是產品體驗的重要組成部分，需要慎重對待。
七 OpenAPI客戶體驗需要強大的體系支撐
那么OpenAPI的客戶體驗能不能被度量?阿里云開放平臺剛開始發力OpenAPI時面臨的最大問題是：客戶和內部都有人吐槽阿里云API不好用，都是點狀問題拋出和客戶需求驅動，沒有一個體系化的方法來衡量客戶體驗指標，且不能規模化解決問題。
阿里云的 OpenAPI數量1萬多個，點狀的、模糊的反饋對解決全局問題沒有幫助，且用戶其實是對具體產品有概念，但針對OpenAPI概念性卻不強，調研主觀偏差更大。
阿里云的OpenAPI體驗是一個全鏈路問題，如下圖：
圖5 典型OpenAPI用戶使用路徑
長長的鏈路，任何一個環節沒做好都有可能導致用戶體驗不好;而且反饋的信息也是五花八門，難以抽取有效信息。因此有幾個核心問題需要依次解決：
- 什么樣的客戶聲音是清晰明確的?
- 如何能夠拿到這些客戶聲音，有哪些渠道?
- 如何處理這些聲音，如何清洗分類，如何定位根因，分析是哪個環節的問題?
- 如何建立總體和細分量化指標，進而針對性治理，形成閉環?
- 如何推動及運營?
- 最終如何檢驗治理效果?
我們的做法是這樣的：
1 Step1 量化
- 要有具體用戶問題： 能夠反映客戶具體問題的信息，過去主流是靠工單，但是工單反饋的用戶只是冰山一角，更多的信息沒有被看到。電話、釘群信息、網站反饋等內容也應該被納入進來，這些信息加起來就是一個個具體的問題，很多問題匯集在一起就形成了很有價值的大數據集，可以給數據化治理奠定數據基礎。
- 獲取數據：我們嘗試聯系工單系統、內部平臺、釘群等渠道，需要拉通各個平臺的數據。
- 數據清洗：客戶、工單數據是非結構化數據，需要自然語言處理方面的技術，阿里云開放平臺與達摩院合作，通過對特定目標分類輸入關鍵詞、打標簽等方式訓練AI，由AI對大量的數據進行自動化抽取、歸類、量化，對客戶聲音和根因進行較好的分類和量化。
- 業務價值：通過根因分析得出客戶主要問題分類后，針對性地優化升級產品，以問題的單位用戶工單量為效果指標，來檢驗產品改進效果。有些問題是從趨勢中發現的，需要升級產品，例如客戶抱怨找不到SDK或API，我們就要優化API搜索。有些問題是已知內部問題，例如API可用性問題，就制定機制去督促業務改進。
- 改進效果衡量：首先要有具體指標，目前主要還是工單降量。但是我們覺得還不夠，因為工單只是冰山一角，數量不夠多，也不夠細節，流轉周期也長。所以我們也嘗試收口OpenAPI開發者門戶，一方面標準化產品體驗，另一方面直接觸達終端客戶拿到最詳細的反饋。比如，客戶的反饋能夠詳細到：當某個API的頁碼設定為0會導致功能異常、文檔細節不對、必填非必填描述不對這樣的精準問題。
通過上述動作，我們能夠自動化分析出OpenAPI用戶的主要痛點，并建立數字化趨勢圖去跟蹤。
2 Step 2：治理
- 有法可依：制定了《阿里云OpenAPI規范》，目前已經迭代到1.3版，涵蓋設計風格、服務質量、資源規范、域名規范、文檔規范等子項，在標準層面統一大家認知。
- 執法必嚴：想要讓規范落地只有文本不行，必須有配套的平臺機制。
- 收口阿里云所有API管理，從提升研發效率和全生命周期體系化管理的角度持續提升API管理平臺的核心能力。
- 將規范的審查規則沉淀到規則引擎中，用戶在開發API的時候自動化掃描檢查問題，不通過就打回。對于無法自動化約束的規范，建立審核流程和管理層審批流程，提高不合規問題的生產成本，不斷提升自動化審核比例。
- 針對API的質量進行數字化治理，通過質量分量化評估各個BU各個產品API質量，定期同步督促改進。
- 違法必究：聯合阿里云用戶體驗部門一起推動問題改進，并通過檢查用戶側工單降量情況來驗證效果。
上述能力，都沉淀在內部管理平臺上，內部云產品可以一站式管理API及流程化參與API治理過程。
3 Step3 產品化
目標是收口外部用戶的產品體驗。以前OpenAPI的各項功能是分散割裂的，后續我們將所有與OpenAPI相關的功能集成正在一個產品中，即OpenAPI開發者門戶 ，除了通過集中的產品建設提升用戶體驗外，還針對使用鏈路增加了troubleshooting、搜索、codesample等模塊。
通過以上三步，我們整體OpenAPI體驗治理大圖如下：
圖6 用戶體驗管理閉環示意圖
通過這套體系運轉中發現的問題，都會通過API管理平臺和API開發者門戶的功能上不斷的完善，去逐步提升用戶體驗，從2020年的工單情況看，有比較明顯的下降。
八 總結
阿里云是個龐大的分布式操作系統，OpenAPI相當于用戶層操作內核層的重要通道，保障它的穩定、功能、性能、體驗關系到客戶的核心體驗，關系到公司形象和生態拓展，也關系到內部產品質量和研發效率。接入層必須做深、做厚、做強才能讓內外部客戶被服務好。從團隊兩年的實踐來看，數字化、體系化的做好基礎建設才能做好OpenAPI體驗。本文就云上OpenAPI的幾個重要概念進行論述，希望能拋磚引玉，引起大家對OpenAPI體系價值的興趣和關注。
參考文獻：
https://apiacademy.co/2015/04/api-design-202-architectural-layers/
https://www.itread01.com/articles/1475911242.html
https://azure.microsoft.com/zh-cn/features/resource-graph/
https://maryamalshamsi98.wordpress.com/2014/05/21/linux-file-system-2/
