8分鐘丨教你玩轉 API

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

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

背景

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

同時，業界也在逐漸的引入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管理與開放平臺。

• 應用場景

• 功能介紹

一、織雲API平臺，實現了API統一規範管理與開放。 二、以服務代理爲基礎，實現了安全認證，過載保護。 三、對於服務調用支持日誌查詢，數據畫像，異常告警，鏈路分析等功能。 四、能夠基於API平臺實現基於織雲全部能力的定製開發的能力。

接口規範和接入成本

• 接口規範

屏蔽接口URI層級差別：

API平臺，統一採用三級結構，經過/平臺/服務/接口的層次來管理全部接入API，屏蔽實際接口URI的層級差別；

屏蔽接口響應結構差別：

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

全局業務錯誤碼：

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

• 接入成本--零改造

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

註冊API服務 — 示例

• 現成的API接口

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

url: http://capacity/load/sustaine... 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 送你一份技術課程大禮包！

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