現在的互聯網行業已經不是大魚喫小魚的時代了，而是快魚喫慢魚的時代，具體來講就是從用戶需求轉化成企業服務的能力，其中研發效能的高低對用戶需求轉化速率起到了至關重要的作用，而API服務的研發效能是當中非常重要的一環。
隨着公司的發展，研發人員越來越多，公司產品多元化，模塊複雜度不斷提升，API的研發效能也成爲了決定公司研發能力的關鍵因素之一，同時對API研發管理，研發效率也有了新的挑戰：
挑戰
- 接口協議同步不及時：API接口定義多是文檔化管理，文檔更新往往不及時，當接口協議發生變化時，無法及時同步給前端、測試等團隊。
- 自動化水平低：測試用例一般通過Excel、Xmind等維護，需要手工測試，每次迴歸測試都需要人工手動執行測試用例，大大佔用測試資源。
- 聯調週期長：每次聯調可能涉及多個模塊，幾個研發團隊協作，一方出現問題，就會卡住整個流程，拖慢聯調進度。
- 提測質量無法保證：研發自測不充分，冒煙測試用例執行情況無法量化，導致提測質量參差不齊，
- 性能壓測：性能測試門檻高，壓測機器碎片化無法統一管理，缺乏專業的性能分析。
願景
我們希望能夠研發一個API管理平臺，可以滿足以下的需求：
- 接口協議更新能夠及時同步。
- 減少前端、後端、測試等團隊間的依賴。
- 提升接口自動化水平。
- 有專業的壓測平臺。
破局
對比了市面上已有的接口管理平臺，我們發現YApi可以說是最好用、功能最完善的API接口管理平臺了。
YApi原生已經支持以下功能：
- 可視化接口管理
- 數據mock
- 自動化接口測試
- 數據導入（各種，包括swagger、har、postman、json、命令行）
- 權限管理
- 支持本地化部署
- 支持插件
- 支持二次開發
我們決定基於YApi進行二次開發，滿足內部的定製化需求，演進出公司內部的GTest接口管理平臺。目前，圍繞着接口管理和效能提升，已經開發了以下平臺：
- GTest(API管理平臺)：基於YApi1.3.22版本演進，支持內部RPC協議、接口定義優化、支持集羣模式、Chrome插件功能擴展等功能，目前已經完全自主迭代。
- 壓測平臺：基於Gatling開發，支持內部RPC協議壓測、動態隨機參數、返回值斷言等。結合GTest，選擇壓測模式，讓壓測像接口調用一樣便捷。
- GDetector(API監控平臺)：支持Ping、Telnet、Http等協議的監測，對接口返回值進行斷言，可配置定時規則和告警規則，結合GTest測試集合也支持流程級別的監測。
- GDevops(CICD平臺)：只需簡單配置即可進行代碼質量監測、規範控制，自動化構建鏡像和K8S部署。
依託目前的GTest接口管理平臺，對比一下過去和現在的接口開發流程：
案例
下面舉兩個例子來說下有了GTest平臺之後發生的變化：
研發提測質量：
之前規定研發提測前，需要開發把測試提供的冒煙用例執行一遍，但是這種方式無法保證測試用例的執行情況，也沒有數據化的校驗結果，比較主觀。
依託GTest平臺，在幾乎不需要人工參與的情況下，根據接口定義的字段規則、字段是否必須等自動生成接口測試用例集合，開發一鍵即可接口驗證，並生成詳細的測試報告。對於開發提測的版本，自動化執行冒煙測試集合，減少測試人員的參與，提測質量數據化展示，一目瞭然。
API業務監控：
之前每個業務上線，都需要業務方自行開發撥測系統用於監控服務的運行情況，各個業務方實現標準不統一，撥測系統本身的穩定性等很難保證。
依託API監控平臺，提供標準的定時監測功能、告警功能等，還可以直接複用GTest平臺的測試集合進行流程監控。隨着監控用例的完善，未來還可以評估線上故障的影響範圍，服務恢復情況等。
經驗
API研發效能的提升不是一蹴而就的，是一個不斷迭代和推進的過程。中間會涉及到前端、後端、測試、運維等多方面的人員。也會有基於技術的問題，基於流程的問題。下面是我們在推進API研發效能提升的一些經驗總結：
-
引入流程
可能很多人聽到流程的概念，都會想到繁文縟節、效率低下等字眼。但是對於像GTest這樣作爲多方人員協作的平臺，無規矩，難成方圓。一個人能把平臺使用好不代表一幫人可以把平臺使用好。所以必須制定好流程。
比如 接口開發流程：在接口開發之前，必須制定好詳細的接口協議。這樣後端開發人員根據接口協議進行開發，前端人員根據接口協議調用Mock服務，測試人員根據接口協議編寫測試用例，三方人員並行工作，不用相互依賴，阻塞自己的工作進度。
比如 冒煙測試流程：測試人員應該在開發人員提測之前，在GTest上面編寫好冒煙測試集合。這樣開發人員在GDevops平臺提測打包時，會自動打包，部署服務到K8S，自動化執行冒煙測試集合，測試通過會自動發送提測郵件。
-
小範圍試用
對於制定的規範、標準、新功能等先找一兩個團隊進行小範圍試用。小步快跑，快速驗證合理性、可行性。而且真正的應用到實際場景中，才能發現制定的標準示範合理，規範能否應用起來，新功能能否滿足真實的場景。小範圍的試用也方便與使用團隊的深入交流，如果直接推廣到整個公司，反而會引入穩定性、規範普及、場景未完全覆蓋等問題，疲於奔命，無法聚焦，還會留下難用的印象。
-
制定標準
對於GTest平臺，多方人員共同協作，維護着整個公司業務的API接口，那麼怎麼管理人員，管理API等也變成一個問題。只有制定相關的標準，才能井然有序的運行。
比如：API接口需要按照
分組項目分類接口這樣的層級來維護，不然接口雜亂無章很難找到。比如：接口協議需要定義字段
是否必須默認值長度大小限制規則，這樣API Mock環節，測試用例編寫才能根據定義的協議來完成。
展望
API研發效能提升涉及的面非常廣，有技術能力上的，也有管理規範上的。對於整個API研發生命週期，每個環節的提升，都會帶來API研發效能提升。未來，我們還有很長的路要走，比如 API自動生成平臺，API開放交易平臺等。
歡迎一起學習交流，關注微信公衆號：咻咻ing