歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
背景
當下，業界越來越多公司在專案架構設計時，會採用微服務架構。微服務架構，可以讓我們的產品有更好的擴充套件性，更好的伸縮性；但同時也會帶來微服務的一系列問題，比如微服務介面怎樣規範管理？怎樣在多團隊協作中開放與複用？等等。
同時，業界也在逐漸的引入DevOps理念，來實現開發，測試，運維，運營更緊密的高效配合，提升產品迭代的效率，質量。
這裡，織雲API平臺將從“部門內微服務API開放複用”，“產品線API DevOps實踐”來分享騰訊社交網路運營部踩過的坑和API平臺在“開放”，“DevOps”的理解及實踐。
1API開放與複用
部門長期運營，積累了很多優秀的系統/平臺，各個系統/平臺也很早的開放了自己的Open API 給其它團隊做二次開發和使用。
作為開放介面使用方：要整合A平臺的B服務時，你可能會遇到：
- 找不到平臺開放介面文件；
- 從平臺官網下載的介面文件好像未更新；
- 介面文件定義太簡單。看不懂；
- 使用前，不清楚介面的質量現狀（成功率，耗時等）；
- 出異常時，沒法快速界定問題的邊界。
作為開放介面提供方：你在運營上可能會遇到：
- 接入方很多，長久下來，自己都不清楚呼叫方是哪些？
- 最近我的介面呼叫量大增，不清楚這些呼叫是否合理？
- 舊介面要下線，但仍有請求。不方便快速找到呼叫者。
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平臺簡單的介紹和分享，拋磚引玉，希望大家都能打造好自己的微服務管理與開放平臺。共勉！
· 分 · 割 · 線 · 啦 ·
織雲企業版預約體驗
問答
相關閱讀
此文已由作者授權騰訊雲+社群釋出，更多原文請點選
搜尋關注公眾號「雲加社群」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！
海量技術實踐經驗，盡在雲加社群！