系统架构设计实战：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 脚本请及时上报信息安全管理部。