本文由織雲平臺團隊發表於雲+社區專欄

背景

當下，業界越來越多公司在項目架構設計時，會采用微服務架構。微服務架構，可以讓我們的產品有更好的擴展性，更好的伸縮性；但同時也會帶來微服務的一系列問題，比如微服務接口怎樣規範管理？怎樣在多團隊協作中開放與復用？等等。

同時，業界也在逐漸的引入DevOps理念，來實現開發，測試，運維，運營更緊密的高效配合，提升產品叠代的效率，質量。

這裏，織雲API平臺將從“部門內微服務API開放復用”，“產品線API DevOps實踐”來分享騰訊社交網絡運營部踩過的坑和API平臺在“開放”，“DevOps”的理解及實踐。

1API開放與復用

部門長期運營，積累了很多優秀的系統/平臺，各個系統/平臺也很早的開放了自己的Open API 給其它團隊做二次開發和使用。

作為開放接口使用方：要集成A平臺的B服務時，你可能會遇到：

1. 找不到平臺開放接口文檔；
2. 從平臺官網下載的接口文檔好像未更新；
3. 接口文檔定義太簡單。看不懂；
4. 使用前，不清楚接口的質量現狀（成功率，耗時等）；
5. 出異常時，沒法快速界定問題的邊界。

作為開放接口提供方：你在運營上可能會遇到：

1. 接入方很多，長久下來，自己都不清楚調用方是哪些？
2. 最近我的接口調用量大增，不清楚這些調用是否合理？
3. 舊接口要下線，但仍有請求。不方便快速找到調用者。

2產品線API那些事兒

織雲，是騰訊SNG海量業務運維能力經驗沈澱出的產品，它采用微服務架構。在微服務的開發，測試，交付，運營中，我們遇到這樣子的問題：

• web工程師：版本叠代很緊，但是後臺同學的接口遲遲出不來，我的工作delay很久了

• 後臺工程師：版本叠代很緊，寫代碼的時間都沒有。哪來時間寫用例。但每次修改代碼，人工自測耗費很多時間。

• 兩位工程師：上次不是好說接口長xx樣子嗎？怎樣現在變成這樣子了？

• 質量工程師：這個叠代，織雲性能是否達標呢？看不見，摸不著，快慢主要憑感覺。

• 運維工程師：客戶反饋操作有異常。一個問題都轉幾手開發。我怎樣快速定位問題根源

• 客戶：你們的XX能力很好。我們想基於它們接口做二次開發。有開放接口嗎

織雲API平臺，就是這種大背景下應運而生。

API平臺簡介

• 定義

織雲API平臺，是一個以API服務管理和代理以基礎，賦能接口開發，測試，上線運營，下線管理於一體的API管理與開放平臺。

• 應用場景

• 功能介紹

1、織雲API平臺，實現了API統一規範管理與開放。 2、以服務代理為基礎，實現了安全認證，過載保護。 3、對於服務調用支持日誌查詢，數據畫像，異常告警，鏈路分析等功能。 4、可以基於API平臺實現基於織雲所有能力的定制開發的能力。

接口規範和接入成本

• 接口規範

屏蔽接口URI層級差異：

API平臺，統一采用三級結構，通過/平臺/服務/接口的層次來管理所有接入API，屏蔽實際接口URI的層級差異；

屏蔽接口響應結構差異：

API平臺，自動轉換接口響應結構，屏蔽實際接口的結構差異化。大大簡化了集成開發，特別是Web前端同學適配後臺接口的復雜度。

全局業務錯誤碼：

確保服務間的每個錯誤碼都是唯一能溯源的。

• 接入成本--零改造

API平臺在設計之前就考慮到用戶接入的成本。以上規範，API平臺都能自動屏蔽差異，自動轉換，自動生成。用戶接入零改造。

註冊API服務 — 示例

• 現成的API接口

現在我有一個容量的分析接口：查詢模塊容量持續高低負載數據接口。

url: http://capacity/load/sustained-load method: get 入參：type=1&m1id=468095&m2id=468095&m3id=468095&m4id=468095 出參： [ { "m1id": 1256, "m2id": 1256010, "day_cnt": 14, "m4id": 468095, "avg_load": 0.25, "type": 1, "model_cnt": 1, "m3id": 11120 } ]

• 創建接口對應的平臺，服務

操作相似。如創建服務：

其中的英文縮寫，將是最終API url中對應的服務名。

• 註冊接口 - 基礎信息

• 註冊接口 - 定義請求示例

自動生成入出參：

在入參，出參示例部分，只須貼入：

入參：type=1&m1id=468095&m2id=468095&m3id=468095&m4id=468095， 出參： [ { "m1id": 1256, "m2id": 1256010, "day_cnt": 14, "m4id": 468095, "avg_load": 0.25, "type": 1, "model_cnt": 1, "m3id": 11120 } ]

API平臺會自動幫我們解析結構（當前支持key/value, json結構等解析）

用戶，只須錄入字段是否必填，以及中文說明即可。

• 註冊接口 - 定義接口返回碼

接口開放

• 查看開放API接口

列表頁：

在API平臺註冊接口後，可以在API平臺列表中查詢每個開放接口：

明細面：

在明細面，可以查看接口詳情。以及自動生成的調用示例。

自動生成接口文檔

• 訪問權限申請

API平臺的接口開放模式暫時有兩種：全開放，須審核。

全開放：

用戶須在API平臺應用組進行登記註冊，API平臺會分配一個唯一的apikey給到用戶。對於全開放的接口，用戶訪問時，只須header帶上apikey即可。

須審核：

對於一些敏感數據接口，用戶訪問前，須進行權限申請，將請求所在的業務模塊與當前接口進行綁定。API平臺只允許目標業務模塊下的IP訪問目標接口。

場景一：接口開發－無中生有

應用前－出現的問題：

1.開發耦合：項目叠代剛啟動，經常會出現後臺開發間，前後端開發間接口相互依賴，導致工作相互delay。

2.相互“扯皮”：開發間當面對齊接口，經常出現今天說“一套”，實際輸出“一套”。沒有接口落地及佐證的地方。

應用後－規範的工作流程，實現了並行開發：

有了API平臺，大家的工作流程規範是這樣：

\1. 接口提供方，註冊新接口到API平臺；

\2. 提供方與接口使用方通過API平臺對齊接口，達成兩方最終接口；

\3. 使用方使用API平臺提供的偽接口進行功能開發及聯調；（不再阻塞）

\4. 接口提供方嚴格按最終接口參數實現真實接口。

\5. 接口提供方將測試接口錄入API平臺，模式從“偽接口”切換成“測試”，接口使用方可以“無感知”的切換成真實接口服務中去。不需要額外聯調。

場景二：接口測試－可視化用例+自動測試

“ 寫代碼的時間都沒有。哪來時間寫用例。但每次修改代碼，人工自測耗費很多時間。” 這種現象其實在開發中很普遍。

有沒有一種模式，可以讓開發不用寫代碼就能快速實現接口單元測試用例？甚至讓不寫代碼的測試同學來幫開發實現測試用例？

API平臺，提供了可視化用例在線編輯：用戶只須錄入預設值，即可生成用例。一鍵執行用例，查看測試結果。

API平臺也實現了依賴第三方環境API的接口本地化測試。

關於API平臺測試能力這一部分，後面我們再專門單獨做介紹。

場景三：質量運營

• 安全認證

分配apikey: 所有API訪問，須在API平臺註冊，由平臺分配唯一的apikey。用戶每次請求須帶上apikey方可訪問；

限制開放源：對於敏感API接口，接口使用方須在API平臺登記請求來源業務模塊，經審核後，方可訪問。

• 過載保護

每個接口可以自定義訪問頻率。API平臺可以對接口進行限頻保護。

• 接口巡檢

API平臺可對線上服務接口進行自定義的主動探測與巡檢。在用戶察覺問題前發現問題與修復問題。

• 異常告警

若API服務出現異常，API平臺會主動通知接口使用方與提供方。

• 異常告警案例

CMDB下發配置（16:30,17:30灰度），未切走流量，導致接口請求小部分異常。

告警短信：

查看API日誌：

發現：後臺spp服務異常

跟進原因：

• 調用鏈路分析
• 應用場景

應用前－問題場景：

A業務頁面提示xx保存失敗-->A業務開發卷入排查（重現問題+分析）-->發現是公共B服務異常--> B開發卷入相似分析--> 發現是平臺服務C異常--> 卷入C開發相似分析--> 確認是redis服務異常。

這種問題，如果發生在客戶環境，會有ABC三個開發同學要：申請登錄客戶環境（有時很繁瑣很費時）--> 排查--> 內部反饋，流轉問題單。有時排查分析時間還沒有前後協調時間耗費得多。

應用後－鏈路分析場景：

API平臺調用鏈路分析能力，方便不懂業務的運維同學，一鍵在線查看整個調用鏈，直達問題根節點：

1.獲取異常請求ID：

前端頁面或後臺服務出現異常時，定位者可以從頁面或日誌中獲取調用請求的ID，

2.還原問題現場：

根據請求ID，在API平臺獲取調用鏈，快速全方位的還原現場數據：鏈路中每個請求的入參，出參，耗時，返回碼，異常日誌等。

告別登機子查日誌－重試重現問題－大量開發介入－問題修復效率低慢的問題。

• API調用鏈路分析

API平臺根據起始請求，將接口間調用關系生成一棵調用樹.我們可以一目了然的看到:

1.請求的調用鏈路;

2.每一層調用現場：服務調用方,服務提供方,接口返回碼,耗時, 入參,出參, 異常日誌(若有異常)

利用API平臺的調用樹能力，我們可以：

１、快速了解服務的調用關系，發現不合理調用；

２、幫助售後快速定位問題；減少開發介入頻率；

３、現場復原：不須再重現；避免重現不了問題的定位

４、web可視化分析：減少上機子查日誌的次數。提升定位效率。

• 案例一：發現不合理調用

(1)問題現場

devtest環境,執行工具市場工具異常.

(2)獲取requestId

獲取id, 輸入查詢

(3)重現調用樹+問題現場

(4)發現原因/問題

結論一(問題原因)：命令通道接口-判斷設備連通性：發現設備不可通。

結論二：通過調用鏈，發現工具市場存在重復調用cmdb接口問題。工具市場下個叠代修復。

• 案例二：CMDB異常

(1)問題現場：執行工具市場時，只提示CMDB異常。但不知道原因。

(2)查看API平臺調用樹：不需求上機子查日誌啦。可見原因是DB連接異常。

場景四：數據畫像

API平臺有實時日誌查詢、實時數據畫像、性能分析等數據畫像能力。這裏，針對成功率，耗時做下介紹：

對於運營者來說，我們很關心線上接口的成功率，耗時，這樣將直接影響服務質量，用戶體驗。

• 橫向分析

查看接口成功率分布及趨勢 & 查看接口耗時分布及趨勢。

平均成功率，平均耗時，會在“平均數據”下掩蓋了一些細微的問題。API平臺畫像，會采用分段模式，下鉆一層看問題。

• 縱向分析

以“天+接口”緯度查看明細數據：

• 性能優化案例

剛接入API平臺時，織雲自動化服務，共有39個接口有調用記錄。其中29個接口（66.7%）不達標（接口耗時超過500ms）。經開發性能後，慢接口大幅減少。

小結

織雲API平臺，是結合我們部門“接口開放”，“接口生產”需求、痛點和DevOps理念的一次新探索，新實踐。在傳統API網關的能力基礎上，拓展到更多API周期階段，實現API的DevOps賦能與管理。

以上是API平臺簡單的介紹和分享，拋磚引玉，希望大家都能打造好自己的微服務管理與開放平臺。共勉！

· 分 · 割 · 線 · 啦 ·

織雲企業版預約體驗

織雲社區版 V1.2下載

問答
無法從API獲取數據？
相關閱讀
模型剖析 | 如何解決業務運維的四大難題？
混合雲管理問題，你解決了麽？
Pick一下，工具上線前運維必備原則
【每日課程推薦】機器學習實戰！快速入門在線廣告業務及CTR相應知識

此文已由作者授權騰訊雲+社區發布，更多原文請點擊

搜索關註公眾號「雲加社區」，第一時間獲取技術幹貨，關註後回復1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社區！

8分鐘丨教你玩轉 API