一、目標(biāo)

建設(shè)一個高效、易用且經(jīng)濟實惠的API管理平臺，滿足API的創(chuàng)建、管理、測試、文檔管理和權(quán)限管理需求，并支持第三方API工具導(dǎo)入，以提升V平臺API使用效率和團隊協(xié)作效率。

二、現(xiàn)存問題：

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

三、需求分析

• 易用性： 快速生成或批量導(dǎo)入接口定義和入?yún)⒍x，支持持續(xù)集成。
• 可擴展性： 接口入?yún)⒖膳渲茫梢宰远xHeader、Cookie信息。
• 測試報告： 支持自動化測試，生成測試報告，并能持續(xù)集成。
• 數(shù)據(jù)模擬（Mock）： 前端開發(fā)人員可以根據(jù)接口定義配置Mock Server進行并行開發(fā)。
• 持續(xù)集成： 開發(fā)人員合并代碼時，自動觸發(fā)接口測試，確保主流程不受影響。
• 個性化需求： 支持前置與后置代碼編寫，滿足不同團隊的個性化需求。
• 多系統(tǒng)一體化： 支持多個系統(tǒng)的API集成在一個平臺。

四、技術(shù)選型和對比分析

1、選擇標(biāo)準(zhǔn)

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

2、篩選

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

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

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

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

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

五、yapi介紹

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

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

2、系統(tǒng)信息，統(tǒng)計項夠用

3、項目主頁，包含接口列表、動態(tài)、數(shù)據(jù)管理、成員管理、設(shè)置、wiki。

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

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

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

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

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

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

8、導(dǎo)入導(dǎo)出，支持swagger、postman、json、HAR導(dǎo)入，其中postman格式非?？上е恢С諺1版本的，當(dāng)前較新版本的postman都只能導(dǎo)出V2和V2.1的json文件了。

導(dǎo)出，支持html、MD、swaggerjson、json，相信夠用了。

六、MeterSphere介紹

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

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

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

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

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

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

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

還有單獨的用例模塊，可以列表，也可以系統(tǒng)內(nèi)直接畫腦圖

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

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

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

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

七、總結(jié)

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

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

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

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

注：經(jīng)過安全漏洞掃描中，發(fā)現(xiàn)Yapi漏洞，可修復(fù)

具體修復(fù)方案如下：

• 關(guān)閉用戶注冊功能：在"config.json"添加"closeRegister:true"配置項： { "port": "*****", "closeRegister":true } 修改完成后，重啟 YApi 服務(wù)。
• 暫時關(guān)閉 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;}。
• 檢查用戶列表，刪除惡意不明用戶；如果發(fā)現(xiàn)存在不明用戶創(chuàng)建的接口及 mock 腳本請及時上報信息安全管理部。