Eolink 通过构建 API 全生命周期管理体系，实现降本增效

背景：API 让各行业进入全新的时代

API 相关行业最近几年很火，因为它的确解决了企业在数字化方面的一些问题。康威定律说，软件系统的架构是和企业的组织架构互相影响的。

现在随着企业内部分工越来越细，分布式的技术架构、微服务也成为大家的共识。而 API 成为链接和管理分布式系统的关键要素，来自 Linux 基金会的数据显示 70%~90% 的代码是由开源和第三方 API 来组成的，并且通过 API 产生的经济价值也变得非常巨大。

放眼全球会发现，类似的事情在海外互联网企业里其实都已经应用得很好了，也都纷纷推出 API 战略。

比如我们最近和一些车企交流，大家都提到现在希望用软件定义汽车，让系统更加智能，服务可以更快地响应消费者需求，因此就希望建立各种 API 管理平台，集中管理和组合各种现有的服务，让业务可以进行的更快一些。

类似的像开放政务、开放银行的概念也很火，本质上都是数据和服务的复用，而 API 在其中扮演着重要角色。

目标：API 全生命周期管理平台的建设目标

如果我们仔细研究，会发现 API 战略一般包含三个方面目标：增效、降本、增收。通过规范化的 API 管理提升研发效率、通过开放 API 提升企业内外部合作效率、通过跨部门协作实现更低的管理和运作成本，并且将数字资产包装成新的产品来增收。

为了实现这些目标，我们往往需要搭建一个 API 全生命周期管理平台。

API 全生命周期管理平台一般会包含什么内容呢？

从业务角度来看，API 全生命周期管理的目标就是推动业务可复用的增长。我们不仅要让开发变得更加简单，让我们 API 的管理变得更加规范，让测试的工作能够逐步自动化，让运维能够更加智能，并且让 API 能够成为一个平台上的服务，让后续业务团队可以快速自行取用。

从技术角度来看，如果我们把 API 涉及到的团队都列出来，或者按照研发上线流程列出来，就能够看到 API 管理其实是一个流程长，且内容复杂的系统性问题。

那么 API 全生命周期管理的挑战，其实就是如何通过产品将研发、测试、运维部门打通，并且高效地完成价值创造。

Eolink 其实也是一直在围绕这个目标努力，这里列出来的产品也是我们在过去几年不断完善的产品线，目前也都已经形成了标准化的产品了。

从一些行业的统计数据来看，会发现有 60% 以上的团队，将半数时间花在了围绕 API 相关的工作上面，现在随着企业对降本增效的进一步追求，企业开始考虑如何在 API 管理方面做得更好。

这里列举了一些常见的围绕研发和测试团队的 API 痛点，比如如何保障 API 的规范管理、高效进行跨团队协作、如何了解 API 的变更历史来进行更好的版本管理、如何更低成本地实现自动化测试，以及如何快速发布和使用 API。

Eolink 在过去每半年都会对用户做一次访谈，了解用户的一些痛点及需求的变化。

比如大部分的团队都会认为 API 管理是一个非常繁琐的事情，API 缺乏版本管理也导致微服务的治理很麻烦，毕竟不知道接口什么时候改了什么地方影响了什么关联服务。大家都想做自动化测试，但是传统方式写代码又不好维护等。

通过这些用户反馈，我们发现对于大多数企业来说，解决 API  管理和自动化测试问题，初期投入产出比最高，随着企业系统不断丰富，可以再逐步投入更多资源建设起 API 的全生命周期管理体系。

经验：API全生命周期管理在研发测试团队的最佳实践

因此我们先介绍一下解决 API 管理问题的基本思路，也就是 API 的研发管理以及自动化测试，将研发、测试团队甚至运维团队有机结合起来。

在业内，Eolink 首创提出了 DTDD 概念，即：文档与测试驱动开发，并被大量的企业和研发团队所借鉴和学习。这一概念是从我们和大量企业的实践中总结出来的——文档和测试驱动是关键的第一步，这能够高效的联动研发和测试团队。

比如奇安信集团会首先通过 Eolink 平台进行 API 的设计，然后从文档生成规范的框架代码，在 API 文档的基础上编写自动化测试用例，在产品新版本发布时经过我们进行全面自动化测试，确保产品的核心业务流程没有问题才可以继续验收。

和传统的方案相比，将API文档和测试关联起来的好处是，可以快速从文档生成代码和测试用例，并且 API 发生变化的时候也可以将内容同步到测试用例中，并且自动触发测试，自动化程度会更高。

其次是将 API 管理系统和网关、监控服务结合，可以更好地保障API质量和安全。

比如在 API 开发完毕，并且经过测试环境测试之后，接下来可以快速推送到网关上面，将 API 文档和网关上实际运行的 API 进行绑定，一方面可以起到资产管理的作用，另一方面可以了解到 API 的实际运行情况。结合 API 监控，可以在多地对 API 进行监测，及时发现 API 故障并且告警，减少业务损失。

那么，API管理平台中需要包含的一些核心能力有哪些？

首先，一个好的文档是成功的开始。

我们做了一个图形化的 API设  计界面，支持HTTP、Websocket、TCP、UDP 以及 Dubbo 等协议，让我们可以通过模板以及数据结构来快速创建 API 文档。

文档里面会记录详细的参数、说明、示例等信息，并且自动生成 Mock 。如果之前用过 Swagger 和 Postman 的也可以直接导入数据，或者绑定代码仓库，让我们从注解中扫描生成文档。

为了让生成文档更方便一点，我们还做了 IDE 插件，可以直接鼠标右键生成 API 文档，目前支持 Java，未来也会考虑支持更多语言。

有了详细的 API 文档，接下来我们就可以像代码一样对 API 进行版本管理，比如每次 API 修改了哪里，字段的增删改查都可以标注出来。并且配合自动通知，比如通过邮件、飞书、企微、钉钉或者其他方式通知相关人员，让 API 的变更通知更加及时。

而且为了解决 API 在团队间共享的问题，我们还加入了分享链接，可以设置密码和分享范围，直接把文档链接发出去就可以让其他成员查看或者测试。有些情况下我们还希望对文档进行归档或者发给外部人员，这时候直接导出为离线文件，比如 PDF、Word、Excel 或者 HTML 都会更加安全。

通过以上的一些功能，我们就可以基本解决 API 信息在团队之间的共享问题。

在整个 API 的迭代过程中，测试是一个非常高频且刚需的需求，当我们把 a 篇文档给管理好之后，我们希望能够让程序自动帮我们生成接口的测试页面。

因为在 postman 或者是其他的测试工具里面去构造 json 等数据是比较麻烦，只能够直接写一个完整的 json 字符串，所以我们做了一个 json 数据的图形化编辑器，让新手也可以在界面上直接编写 json 和 XML 的请求数据。

相信大家在测试过程中也经常需要对数据加解密或者生成随机数据，为了解决这个需求，我们还做了一个叫做数据构造器的功能，让开发和测试的同学可以在界面上直接对数据进行处理，比如做 MD5、SHA 加解密、截取字符串或计算长度等。还可以随机生成各种类型的数据，比如说像身份证，手机号，邮编等等。

为了让测试好的接口和数据能够直接用在代码里面，我们还做了代码的生成，可以直接从测试用例来生成各种语言的代码，直接复制粘贴就可以用在项目里面。

用例管理

帮我们做完测试，往往还希望把这些测试的数据给保存成测试用例，方便我们下一次测试的时候能够快速调用，因此，我们在产品里面也集成了测试用例的管理，除了保存测试用例之外，还可以在测试用例里面设置断言规则，让系统自动判断返回结果。

下次当我们在进行回归测试的时候，就可以直接一键批量测试完所有的用例，并且看到接口在各种条件下是否产生异常，可以极大的提升测试的效率。

Mock

那么如何基于API文档做前后端对接呢？

这里就少不了要用到 Mock API。

Eolink 可以自动根据API文档来生成 Mock API，比如API文档里面标注了有几种返回结果，系统会自动针对每种返回结果都生成一个对应的 Mock API。

如果觉得系统自动生成的Mock比较简单，我们还可以手动创建更强的Mock，比如根据不同的请求参数触发不同的结果，通过编写Javascript来处理请求和返回数据，还支持MockJS等工具来快速生成数据，基本可以模拟各类API的情况。

API文档结合Mock，让Mock API的使用更加简单，配合API版本管理和变更通知，也让前后端的工作流程自然结合到了一起。

自动化测试

解决了前后端协作，接下来就是让测试工作也能自动化起来，在这里我们也做了一些新尝试。

比如有了 API 文档，我们会根据文档中对 API 的定义来排列组合，自动生成各种情况的测试用例，比如边界值、异常类型、参数缺失等情况。

而且可以在界面上直接编排测试流程，比如注册、登录、下订单、查物流、退出登录等一系列流程，里面涉及参数传递、数据处理、数据库查询、结果校验等工作，都可以在界面上完成。

测试报告

当我们设计好测试流程，下一步就是考虑怎么样能够让他自动的执行？在了解了许多用户的使用场景之后，我们在产品里面加入了定时以及触发式两种方式来执行自动化测试，比如说我希望每天凌晨的两点钟，对关键业务或者是前一天提交的代码进行完整的测试，或者是每一次代码提交的时候都能够通过 jenkins 或者是 gitlab 之类的产品来调用我们的接口，触发相应模块的自动化测试。

测试完成之后，我们还需要一个地方来统一管理所有的测试报告，报告里面需要展示测试的成功率，耗时，错误的用例列表以及错误的原因等，一个好的测试报告，可以帮助我们快速排查错误，减少非常多的不必要沟通。

而且和 mock 一样，测试用例也是有可能发生改变的，那怎么样能够把这些 API 变更自动同步到测试用例里面呢？我们做了几种方案之后，最终决定做一个功能，可以一键将最新的 API 文档同步到测试用例里面，比如说文档添加或者删除了某些字段，那么用例里面也相应的增加或减少这些字段。

这样就可以进一步降低 API 自动化测试的学习和维护门槛，让一个实习生也能快速掌握 API 自动化测试。

新的尝试

当然这还不够，我们尝试将流程图也加入到自动化测试中，让我们可以真正地拖拉拽生成测试流程，并且支持循环、分支等判断条件。更进一步的，我们在目前尝试结合AI的功能，让系统可以自动生成测试流程和测试数据，真正减少 90% 的自动化测试工作。

案例：应用案例与成果介绍

现在 Eolink 提供线上 SaaS 和私有化部署两种产品。和国内外的竞品相比，Eolink 是国内第一家提供 API 全生命周期管理解决方案的公司，Eolink 的产品深度也更深，比如业内的 API 管理工具往往只支持 HTTP、Websocket 等基础的协议，而 Eolink 支持 HTTP、Websocket、Webservice、TCP、UDP、gRPC、HSF、Dubbo 等多种协议，在 Mock、测试用例等方面也是全协议都覆盖了。Eolink 在国内首创的零代码自动化测试也帮助众多用户从繁琐的测试工作中摆脱出来。

接下来我拿某个金融行业的客户作为例子，看一下围绕 API 的团队协作以及自动化测试能够如何提升研发效能以及产品质量。

我们在 2020 年收到某银行的科技部邀请，希望我们能够帮助建设开放银行业务，其中很重要的一部分就是 AAPI的研发测试一体化平台，因为 API 是开放银行的核心，所以他们希望能够借此机会构建银行的接口管理规范体系，加速 API 开发与测试工作，为后续的开放银行业务打好基础。

而且熟悉银行的朋友应该都知道，银行内部往往有数量众多的供应商提供系统服务，而且许多系统的存在时间非常长，可能已经运行了十几年。因此不同的供应商、系统的 API 怎么做统一管理就是一个非常大的问题。

在了解情况之后，我们提出了文档和测试驱动的理念，建议通过一个统一的平台来规范的管理银行内部所有的 API 信息，并且围绕 API 信息进行协作，联动前端、后端和测试人员，构建更加敏捷的团队。并且这个 API 平台还可以通过 OpenAPI 与其他系统对接，强化 DevOps 能力。

首先是我们通过平台来实现 API 的变更和订阅的管理。

值得特别关注的是，这里我们还对接了银行内部的版本发布平台，每次版本的迭代，或者是每个接口的变更，都可以设置版本号，当发布的时候就可以直接通知到接口的使用方，或者叫订阅方。

在产品内部，我们还维护了一套 API 的订阅关系，项目之间如果需要互相使用接口，则需要通过平台提前订阅，审核通过之后才能看到或者测试、对接相应的 API，这样也提高了接口调用的规范性和安全性。

其次是我们取代了低效的 Excel 表格来管理 API 信息，之前银行内部有接近 200 套系统，上万个接口，这些接口存储在大大小小的不同的 Excel 表格里面，发布的时候需要通过 FTP 将表格上传到 esb 系统的特定目录才能完成发布，整个过程非常的麻烦，而且之前的接口变更是通过邮件和线下口头沟通的方式，导致效率低下。

现在通过统一的 API 平台来存储 API 信息，并且将 API 快速发布到 esb 就可以完成接口的版本更新，让整个过程更加简单，更加自动化。

总体而言，一个规范的 API 管理产品，能够为团队带来巨大的效能改善。

首先是统一 API 管理，纳入管理的 API 超 1W，覆盖率 90%+

其次 API 相关项目发版时间减少 80%，从几天到几小时，API 自动化测试时间也减少 80%，30 分钟自动跑完上千用例 而且 API 自动化测试维护成本降低 50%，零代码自动化更容易推行。

而且让我们感到骄傲的是，我们和这个银行客户共创的这些实践经验，也帮助这个银行客户获得了当年的金融科技创新奖。

开源计划与 To do List

借着这个机会，我们也很高兴和大家聊聊产品的开源计划，让更多开发者和企业都能使用到我们的产品，并且促进 API 生态的发展。

目前我们正在把 API 管理和测试的核心模块开源，我们把这个项目命名为 Eoapi ，也就是 Easy & Open API，它能提供高效的 API 管理和测试功能，并且可以通过自定义插件来扩展功能。

和现在市面上的 API 管理或者测试工具相比，Eoapi 的插件系统可以让社区在产品上实现各种各样的附加功能，如果你想将管理好的 API 信息快速导出为一种你们自定义的格式，或者接入一些 API 安全测试工具，都可以通过插件来快速实现。