系统架构设计实战：API管理平台选型

作者：MobotStone 2023-07-05 00:36:38开发 架构 初步看起来，系统型Yapi和MeterSphere的架构功能似乎差不多，但如果细致研究它们的设计实战商业化策略，会发现它们的理平定位和复杂度有着显著的差异。Yapi注重API的台选管理和协作，它的系统型用户界面更加直观，让用户能够轻松地进行API管理。架构

一、设计实战目标

建设一个高效、理平易用且经济实惠的台选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分）。通过这种方式，我们期待能够更精确、更有效地找到我们团队的最佳选择。

api管理平台

私有 <5>

调试 <1>

mock<1>

项目管理<1>

团队协作<3>

测试用例<2>

自动化测试<1>

性能测试<1>

复杂度<2>

代码生成<1>

扩展工具<1>

定位<1>

综合分

wiki

是

无

无

无

无

无

无

无

简单

无

无

开发

7

postman

是

是

支持

类同

无

强

支持

无

普通

支持

无

测试

13

apifox

收费

是

支持

支持

强

强

支持

支持

普通

支持

支持

团队

14

apipost

收费

是

支持

支持

强

强

支持

无

普通

支持

支持

团队

13

swagger

是

是

支持

支持

普通

弱

无

无

普通

支持

无

开发

12

yapi

是

是

支持

支持

较强

较强

支持

无

普通

支持

支持

团队

17

eolinker

收费

是

支持

支持

强

强

支持

支持

普通

支持

支持

团队

14

metersphere

是

是

支持

类同

强

强

支持

支持

普通

支持

无

测试

17

rap

是

是

支持

支持

普通

无

无

无

简单

支持

无

开发

12

easyapi

是

是

支持

类同

普通

无

无

无

简单

无

无

开发

11

能否免费私有化部署是重要考量，直接给了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的功能和性能似乎相差无几。然而，当我们深入研究这两个平台的商业化策略、团队规模、可替代功能、学习和维护成本、未来替换公司自有平台难度、开发人员访谈和合规风险时，我们发现两者的定位和复杂度是完全不同的。

对比项	yapi	Metersphere
商业版本	无	有
免费版本	有，无限制	有，有限制
部署	无难度	无难度，且一键部署
数据导入	支持丰富	支持丰富
数据导出	支持丰富	只有自有格式和swagger
开发用	完全够用	完全够用
自动生成文档	支持，无侵入	不支持
前端用	够用，简单	够用，简单，但路径有点深
测试用	够用，简单	非常强大，但有收费功能
项目管理	够用，简单	能支撑大项目，操作稍多
人员管理	扁平化	三级权限，划分细致
学习难度	简单，基本顾名思义	普通，需要文档支持
维护难度	简单	简单，但路径有点深
报表统计	少	丰富
消息管理	少	丰富
流程覆盖	后端+前端+测试	后端+前端+测试，偏测试
扩展工具	少	无

在下面的内容中，我们将详细分析每个维度的对比结果，以更好地理解这两个平台的差异，并找出最适合我们团队的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 脚本请及时上报信息安全管理部。

责任编辑：武晓燕 来源： 今日头条 系统架构设计

(责任编辑：知识)