一、目標

建設一個高效、易用且經濟實惠的API管理平臺，滿足API的創建、管理、測試、文檔管理和權限管理需求，并支持第三方API工具導入，以提升V平臺API使用效率和團隊協作效率。

二、現存問題：

• API測試覆蓋率低，只在接口研發完成時做少量本地測試。
• 由于業務邏輯變更，早期開發的接口可能報錯或失效。
• 代碼無法持續重構與演進，因為擔心影響業務邏輯。

三、需求分析

• 易用性： 快速生成或批量導入接口定義和入參定義，支持持續集成。
• 可擴展性： 接口入參可配置，可以自定義Header、Cookie信息。
• 測試報告： 支持自動化測試，生成測試報告，并能持續集成。
• 數據模擬（Mock）： 前端開發人員可以根據接口定義配置Mock Server進行并行開發。
• 持續集成： 開發人員合并代碼時，自動觸發接口測試，確保主流程不受影響。
• 個性化需求： 支持前置與后置代碼編寫，滿足不同團隊的個性化需求。
• 多系統一體化： 支持多個系統的API集成在一個平臺。

四、技術選型和對比分析

1、選擇標準

我們的需求，找到一款開源、廣泛使用、能無縫對接Swagger、smart-doc規范（不用手工定義一個個接口），支持自動化測試流程、對前端支持Mock數據的工具。

2、篩選

在當前API管理平臺的海量選擇中，一些有著廣大用戶群和良好口碑的平臺分外引人注目，例如Apifox、APIPost、Swagger、YAPI、Eolinker和EasyAPI等等。然而，考慮到開源認證與合規風險，我們必須對選擇進行審慎考慮。

對于國外的產品，由于可能存在的合規風險和其它問題，我們的選擇焦點僅集中在了最為老牌且知名的Swagger上，而其它的都被逐一排除。同時，如果產品采用了GNU AGPLv3和商業許可的雙重授權方式，我們也直接將其排除在選擇范圍之外，以避免后續可能的法律糾紛。

在經過這些篩選后，我們最終收集到了8款滿足條件的API管理平臺。在對這些平臺進行初步了解和簡單操作后，我們發現這些平臺不僅功能強大，同時也各有其獨特的特色和優勢。

但是，為了進一步提煉我們的選擇，并找到最適合我們需求的平臺，我們決定引入更多的篩選條件，并采用積分制進行評估。具體的評分標準如下：免費私有部署（5分）、團隊協作能力（0-3分）、工作流覆蓋能力（0-7分）、學習成本（1-2分）以及其它擴展功能（0-2分）。通過這種方式，我們期待能夠更精確、更有效地找到我們團隊的最佳選擇。

能否免費私有化部署是重要考量，直接給了5分。在此前提下，yapi和metersphere以17分并列第一。下面將著重介紹和比較這兩個平臺。

五、yapi介紹

yapi提供了比較方便的安裝部署方法，但是在nodejs和npm版本選擇上，有坑。用最新版本竟然不支持。當前用的nodejs是v13.14.0，npm是v6.14.4，整個系統都點了一遍，tag這個小功能還是有點小問題，不過tag我們暫時也不用，沒影響。期待后續版本解決吧。

1、主界面，UI體驗不錯。

2、系統信息，統計項夠用

3、項目主頁，包含接口列表、動態、數據管理、成員管理、設置、wiki。

4、接口能直接在web中調試，而且這個調試頁面的所有修改可以保存，并同步更新接口和對應用例（僅路徑）

5、測試集合，這里可以把指定接口或全部接口一鍵轉化成用例集。每個用例可以執行、克隆、斷言(僅自動化時生效)等。用例的編寫還是比較方便的。但是用例的管理上就比較弱了，只支持一層目錄。不過項目的分的細一些，影響也不大。整體使用感覺，非常類似于postman，上手應該沒難度。

6、mock，針對每個接口可以設置mock，可以設置多個期望，也支持腳本。無論前端還是測試，應該都可以快速上手使用。

可惜的是，頁面上無法生成類似于mock_client之類的本地運行的mock文件，后續我查查有沒有相關插件工具可以支持。

7、用例集里面，直接點擊開始測試，則頁面開始逐個執行用例。也支持”服務端測試“，就是在其它服務器執行這些用例。具體操作方法大家可自行體會。

一次只能執行一個用例集，不支持一次執行多個用例集。而且，沒有精美的測試報告。整體來說，接口測試相關功能，夠用的程度。后續查查有沒有相關插件工具，增強測試報告的能力。

8、導入導出，支持swagger、postman、json、HAR導入，其中postman格式非常可惜只支持V1版本的，當前較新版本的postman都只能導出V2和V2.1的json文件了。

導出，支持html、MD、swaggerjson、json，相信夠用了。

六、MeterSphere介紹

MS的部署非常簡單，一個sh腳本，執行后就等著就行了。這點做的不錯。部署完后增加了msctl這個運維命令，可以非常方便的啟動、關閉、查看整個MS系統。

1、主界面，顏值不錯。內容明顯多于yapi，而且明顯偏重于測試支撐。

2、接口測試這里，包含首頁、接口定義、接口自動化、測試報告。其中接口定義，是用來導入和維護api文檔的，路徑有點深啊。

3、界面略顯凌亂，控件有點錯位，其它頁面也有類似的情況。應該是分辨率的問題，大一些分辨率應該就行了。

對接口的維護、調試、mock，都具備，操作項簡單明了。前端開發、后端開發用起來上手快。

不過也沒法生成類似于mock_client的本地執行文件。也沒有插件支持。

4、每個api，都可以調試、mock、用例。而且Metersphere對用例的管理思路，跟yapi不一樣，它的每個用例都關聯到接口的，即每個接口下掛若干個用例，然后所有用例可以自由歸屬集合和場景。對于測試工作的支撐非常強大。

還有單獨的用例模塊，可以列表，也可以系統內直接畫腦圖

5、接口自動化測試，以”場景“為基礎，除了最簡單的依次執行所有用例，也可以通過配置各種控制器，模擬業務流。功能強于postman的參數傳遞邏輯。

6、ms有簡單但夠用的測試報告

7、可選1個或幾個測試用例，直接轉到性能測試模塊。ms安裝的時候自帶了jmeter，只要配置好資源池，這里就自動調用jmeter進行壓力測試。

8、還能進行UI測試和UI自動化測試，但這個是企業版功能，免費版無法使用。且這個導航無法去掉。有點小別扭了。

七、總結

Yapi和MeterSphere兩者都是優秀的API管理平臺，提供了強大的功能和良好的用戶體驗。初步看來，Yapi和MeterSphere的功能和性能似乎相差無幾。然而，當我們深入研究這兩個平臺的商業化策略、團隊規模、可替代功能、學習和維護成本、未來替換公司自有平臺難度、開發人員訪談和合規風險時，我們發現兩者的定位和復雜度是完全不同的。

在下面的內容中，我們將詳細分析每個維度的對比結果，以更好地理解這兩個平臺的差異，并找出最適合我們團隊的API管理平臺。

1. 定位和復雜度： 初步看起來，Yapi和MeterSphere的功能似乎差不多，但如果細致研究它們的商業化策略，會發現它們的定位和復雜度有著顯著的差異。Yapi注重API的管理和協作，它的用戶界面更加直觀，讓用戶能夠輕松地進行API管理。相比之下，MeterSphere則定位為一站式的企業級開放源代碼平臺，它更注重測試生命周期的全面覆蓋，其功能更為復雜和全面。
2. 團隊規模： 根據當前團隊的規模，選擇更合適的工具是非常重要的。Yapi由于其簡潔和直觀的界面，對于小型團隊來說更容易接受和使用。而MeterSphere的功能覆蓋度較廣，可能需要較大的團隊去進行管理和維護。
3. 可替代功能和學習維護成本： Yapi的功能比MeterSphere來得簡單，學習和維護成本相對較低。然而，MeterSphere作為一站式解決方案，提供了更多的可替代功能，可能需要更多的時間去學習和維護。
4. 未來替換公司自有平臺難度： 若考慮到未來可能會替換公司現有的API管理平臺，Yapi由于其簡潔的設計和較低的學習成本，將更容易為團隊接受。
5. 開發人員訪談： 經過與多個業務部門開發人員和集團其他業務人員的訪談，我們發現大多數開發人員更傾向于使用Yapi，他們認為Yapi更易于使用和管理。
6. 合規風險： Yapi是由國內團隊開發的國產軟件，采用Apache License 2.0，這是一種寬松且無傳染性的開源證書。許多國內大廠都在使用Yapi，而且我們也查閱了公司的技術貨架，發現Yapi被推薦使用。因此，Yapi無合規風險。

綜上所述，我們最終推薦使用Yapi作為我們中臺組的API管理平臺。此外，我們還了解到，集團的其他業務組也在使用Yapi。

注：經過安全漏洞掃描中，發現Yapi漏洞，可修復

具體修復方案如下：

• 關閉用戶注冊功能：在"config.json"添加"closeRegister:true"配置項： { "port": "*****", "closeRegister":true } 修改完成后，重啟 YApi 服務。
• 暫時關閉 mock 功能：（需要修改 YApi 代碼）； 在"config.json"中添加 "mock: false" ； 在"exts/yapi-plugin-andvanced-mock/server.js"中找到if (caseData && caseD ata.case_enable) {…}，在其上方添加if(!yapi.WEBCONFIG.mock) {return false;}。
• 檢查用戶列表，刪除惡意不明用戶；如果發現存在不明用戶創建的接口及 mock 腳本請及時上報信息安全管理部。