7月 Eolink 受邀参加 QECon 2023 全球软件质量&效能大会（北京站）。Eolink CEO 刘昊臻，发表了主题为「AI 与智能化 API 治理的探索实践」的演讲，分享 Eolink 在 API 全生命周期中治理实践与 AI 结合的探索。
Eolink 作为国内 API 全生命周期解决方案的领军者，通过其独创的 DTDD（文档与测试驱动开发 ） 和 API First 理念，致力于打造一站式、智能化的 API 全生命周期解决方案，帮助企业提升研发效能，降低运维成本。本次演讲，围绕 API 全生命周期，从 API 治理的价值、治理体系、实践经验等方面，分享了 Eolink 在 API 治理的最佳实践，以及结合「AI+API」技术的革新应用。
之前我在公司里面主要负责产研和相关的技术管理的工作，在 2016年我发现随着微服架构和数据开放的趋势到来，API 的整个综合管理成本开始变得越来越大，并且围绕着 API 的全生命周期有非常多可以优化提效的点。
因此，我和团队在 2016年做了国内第一款结合 API 的设计、开发、测试等功能的 API 开源产品，后面逐步演化为我们现在的公司-Eolink。在过去的几年里面，我们一直致力于在国内推广 API first 理念，帮助企业和开发者更好的去利用 API 。
如今越来越多的企业开始关注 API 的治理等工作，因为很多公司现在能够做的基础建设，以及围绕着代码建设的 Devops 平台能力基本已经建设完成了，下一步就是更细的 API 以及数据的治理，希望能进一步的提升产研的效率以及产品的质量，甚至进行数据的变现。
API 治理为业务带来的价值
目前，API 在企业中扮演的角色越来越重要。首先是 API 的数量相比以前有了爆发式的增长，现在随便一个公司内部拥有上千个 API 是非常常见的。
IBM 调查报告显示，API 经济全球市场规模超过2.2万亿美元。开发API项目的公司数量预计将保持100％的同比增长。
Gartner 研究报告指出，API 生命周期管理市场2019年同比增长36％，超过17亿美元，其成为应用程序基础结构和中间件市场中增长最快的部分。
艾瑞咨询《2020年中国人工智能API经济白皮书》提出，2019年人工智能API开放平台市场规模达104.1亿且正处于高速增长期，预计到2024年市场规模有望达到579.9亿。
其次是围绕着数量庞大的 API 又有着广泛的开放需求，不仅是对内部开放，还经常需要对外部合作伙伴或者是用户进行开放。
API 数量： DevOps、前后端分离的研发模式带动 API 数量大幅增长；
API 开放： 微服务架构改造带来大量 API 管理及开放需求；
API 安全： 数据安全、服务治理等诉求推动 API 管理成为 IT 系统的基础设施；
API 经济： 开放式企业、开放银行等行业领先实践推动 API 经济兴起。
要保证这些开放 API 的安全就变得非常重要，并且还要思考如何挖掘其中的经济潜力，让 API 成为业务增长的驱动力。
来自 Linux 基金会的数据显示 70~90% 的代码是由开源和第三方 API 来组成的，并且通过 API 产生的经济价值也变得非常巨大，许多政府和企业开始考虑将数据和服务进一步开放，因此就有了开放政务、开放银行、企业开放平台等概念。为了更好地发挥 API 的作用，许多公司开始将 API 纳入到 devops 的流程，希望通过这样的方式来加速 API 的生产以及利用。
下图很好地展示了 API 在整个 devops 的过程中包含哪一些阶段，从最开始的设计到开发测试，安全保障以及管理，以及对外暴露之后的可发现，可接入，可消费和可观测。
我们签约的证券公司都希望将内部的 API 进行规范化的治理，包括最基础的 API 资产的集中管理，并进行自动化的测试，然后将测试好的 API 快速发布到网关，再通过一些审批手段去控制调用方，或者将开放的 API 暴露给消费者，让他们能够更快的接入，从管理后台中了解到每个租户、每个 API 的使用情况。
小规模团队：提升 API 研发、测试效率
不同的团队规模和业务规模，对于 API 治理的需求也不太一样，比如对于 100人以下，或者 API 在 1000以内的小规模团队来说，最关注的是如何将 API 作为一个标准化的步骤来接入到现有的 devops 流水线中，提高围绕 API 的开发测试的效率。
比如，通过 IDE 的插件将代码注解或者是代码直接生成 API 文档，通过平台来生成接口的单元测试用例，并且能够组合成自动化的测试流程，方便每一次迭代的时候进行冒烟测试以及版本升级后的回归测试。同时，在不断的迭代中，管理 API 不同版本之间的差异，并且把报告同步到团队中。API 作为 devops 中的一个环节，可以补充现有的研发效能体系，并且进一步的提升产品的质量。
大规模团队：贯穿从开发到上线的 API 治理
对于更大规模的团队来说，单纯的 API 管理和测试无法满足复杂系统和架构的 API 治理需求，此时范围就会延伸到运维，并且将内外部的调用方管理，以及公司内部的协作流程也结合进来。
比如，在开发之前的接口设计阶段，就会进行更详细的接口评审，并且通过一些功能来约束 API 的设计规范，或者找出不符合设计规范的 API。
在开发阶段和代码仓库结合，通过自定义的代码模板，将 API 的设计统一转换为标准的开发框架，然后在此基础上再进行后续的开发。
在运维阶段，将已经测试好的 API 和网关结合，实现从开发环境到生产环境的发布。当然，这个过程中还有可能涉及到一些流程审批，避免因为发布不规范导致的 API 不可用。在生产环境还需要对 API 的运行情况进行监控，了解 API 的调用情况以及异常告警，并且将所有的消息都和内部系统进行打通，实现自动化的协作。
围绕着 API 的治理工作，其实并不比代码的管理要简单，是一个跨团队长流程的的系统性问题。
API 治理完整体系的理想形态
API 要治理，实际上要解决的是四大核心问题：
1. API 作为一种核心的数字资产，要如何进行有效的管理并提升可观测性？
像很多团队以前都是把 API 的资产管理在各种的零碎文档里，甚至有一些老旧的业务系统，连有什么 API 都不清楚。
因此，有效管理的第一个标准就是可持续，其次就是能完整的记录 API 的资产信息来提升可观测性。
2. API 贯穿开发测试和运维等多个环节，我们要如何去把不同的团队和现有的工作流加以优化，并提升它的迭代效率？
针对这个问题，我们在业内提出了dtdd，也就是文档和测试驱动 API 开发的专利实践，通过标准化的工具和流程来解决API迭代效率的问题。
3. API 作为核心的业务中间层，怎么样提升质量和安全性？
比如，通过自动化的测试以及 AI 的方式来提升测试的效率和覆盖率，或者通过网管等中间件对 API 进行安全控制。
4. API 是否可以作为一种商品进行商业化？
这个问题每个公司的情况不一样，是更偏公司战略和业务方向的，比如现在的 AI，是一个很好商业化的 API 商品。
Eolink 从 2017年开始研究如何解决这些问题，并且针对性的设计和开发了一系列的 API 工具平台。包括 API 快速生产、研发管理、自动化测试、网关、监控、开放平台等，实现对 API 的全生命周期覆盖。
如果把 API 全生命周期和 devops 进行结合，就可以得到如图所示的 API Devops 工作流。在这个流程中，API 的每个环节都有对应的工作项，并不断推动 API 以更易用、更规范、更安全的方向发展。
API 治理的实践经验参考
API 治理是一个跨团队长流程和深需求的挑战，一般我们会把治理的目标拆分成多个核心问题，并逐个解决，而最简单的拆分方式，就是按照 API 的生命周期划分成多个阶段，找到各个阶段中目前存在的问题并通过工具来解决。
我们将过去几年在客户中实践的经验整理成了一个 API 治理成熟度的模型，根据这个模型中的三层次，六阶段来分别判断，目前团队内部对于 API 的成熟度处在哪一个级别，以及可能存在什么问题。
从最佳实践来讲，我们服务的客户可以分为以下四种：
- 基于文档与测试驱动，并联动前后端测试团队，持续管理 API 资产并且提升 API 的研发效能。
- 将 API的自动化测试逐渐加强并集成到流水线中，实现随时测试以及持续测试。
- 将 API 的开发和上线环节打通，实现 API 的快速发布，并通过网关等产品进一步管理 API 的流量，提升 API 的性能，安全和稳定性。
- 将 API 的管理和监控、链路追踪等产品结合，实现线上故障的及时发现和告警，并增强 API 的可观测性。
实际的 API 治理操作流程
1. 设计和管理
在设计阶段，制定接口的文档规范，并且建立一个层次清晰的接口仓库，方便后续的管理，测试和发布工作。一般来说，会根据产品应用和服务等级别对API进行分组管理，如果公司更大一些，可能还会在此基础上有部门子公司等组织结构的层级。
然后会制定一系列的API开发规范，比如不同的项目可能存在不一样的开发规范，但在同一个项目内或者一个服务内的API应该是尽可能保持设计统计，方便后续的对接和维护。
同时，为了方便管理，一般也会通过Eolink Apikit将分布在不同工具中的零散的API文档、测试用例、数据结构等内容管理起来，减少后续沟通过程中的信息不对称。
- 开发阶段
一般会基于代码仓库来搭建自动化的流程，解决前后端接口开发和调试的问题。比如从代码注解里面动态生成接口文档，或者是从接口文档反向生成代码。当有了一篇文档就可以设计或者是生成一系列的单元测试用例和 Mock API。这个时候，前后端和测试团队实际上已经开始异步的协作，大家都围绕着 API 文档来工作。
因此，就会出现API和档在团队内部分享的需求，当 API 的设计有疑问或者在测试过程中发现缺陷等问题时，也可以通过评论等方式对 API 标注。
3. 在构建阶段
这个时候代码会上传到仓库，然后触发我们的平台，对整个项目进行快照，也就是创建一个版本。版本管理的作用非常大，我们经常需要对比不同版本之间的接口差距，或者是对某个版本的接口进行回归测试。如果发现接口的设计有问题，还可能需要进行回滚。
4. 自动化测试阶段
测试团队在日常工作中不断地根据测试场景来设计自动化用例，将多个接口串联成测试流程，并且在平台内管理好测试的数据，这样当版本提交时就可以触发对应的自动化测试，并且把报告发送到指定的位置，这整个流程下来就把接口的开发与测试给关联了起来，让测试可以随时进行。
5. 发布阶段
通过将 API 管理和网关进行结合，可以把 API 配置快速推送到不同环境的网关，减少因为导入导出配置或人工操作失误等原因带来的发布问题。
实际上一般在网关还会做最终的发布确认，或者是接入内部的开发平台来进行发布前的审批。后续网关会对 API 进行线上生命周期管理，比如对 API 进行负载均衡，用户健全，攻击防护等工作。
到这里，API 从设计到发布的流程就基本结束了。
在实际的 API 治理的过程中会有非常多的需求，我们整理了一张图，详细的标注了在研发和测试阶段各个目标下可能涉及的一些需求点，方便大家参考。
API 开源生态：覆盖开发测试与运维场景
为了进一步降低 API 产品的使用门槛，我们将过去几年在 API 行业的一些实践经验进行了总结并重新设计开发了两款开源产品，分别是开源的 API 管理测试工具 Postcat、开源的高性能 API 网关 Apinto，这两款产品结合可以覆盖大部分基础的 API 开发测试和运维的场景。
Postcat 定位为面向未来的下一代 API 开发工具。在 Postcat 上，我们可以去管理 API 文档，创建各种 API 测试用例。由于是插件架构，我们可以通过第三方插件和现有的产品结合，或者增强 Postcat 的功能来实现无限的拓展性。未来，我们还会逐步结合 AI 的能力，未来期望让 API 的设计，开发和测试在 Postcat 上面实现全智能化。
Postcat Github ：https://github.com/Postcatlab/postcat
Apinto 是我们基于 go 语言，全自研并开源了一个支持多集群管理的超高性能 API 网关，可以帮助大家解决 API 流量管理中的性能、安全和稳定性问题。
值得一提的，Apinto 的性能非常优秀，在一台八核 8g 的普通服务器上，转发性能接近 7w qps，比 nginx 要高 100%，比 kong 高 70%，并且在高并发的情况下，还拥有更低的延迟和错误率。
Apinto 还自带了 UI 的控制台，让整个部署使用和维护的门槛都降到最低。
并且也采用了和 Postcat 类似的插件架构，这意味着产品里几乎所有功能都可以通过插件的方式来扩展。无论是进行二次开发，还是集成到公司内部，都会更加方便。
Apinto GitHub：https://github.com/eolinker/apinto
首个「AI+API」的产品化探索
1. 通过自然语言描述需求，AI 生成 API 文档、API 代码
我们从去年开始研究产品和 AI 之间结合的可能性，其中第一个结合点就是通过自然语言来描述需求，然后由 AI 来生成 API 的设计，并通过平台来生成后续的框架代码。
比如，我们可以在产品中描述要设计一个什么样的 API，或者需要设计一个什么样的系统，然后 AI 会生成对应的 API 文档，并且我们可以在平台中二次编辑并保存。
如果觉得生成内容不符合预期，还可以继续完善描述，让 AI 生成更准确的 API 设计。生成好了之后，可以通过我们平台来生成各种语言的框架代码，并在此基础上继续开发。通过这样的方式，可以快速批量的创建 API 并减少一部分的人工操作。
2. AI+API 生成单元测试用例
根据 API 的文档来生成单元测试的用例，这个场景比刚才的要复杂一些，首先需要分析 API 的含义和使用场景，然后根据 API 文档里的参数描述来分析出 API 可能的单元测试用例有哪一些，并且生成对应的测试数据。
生产出来的测试用例可以一键进行回归测试，或者通过 OpenAPI 的方式对接到流水线里面，在每一次迭代完成之后都触发回归测试。
3. AI+API 生成自动化测试流程
通过 API 的文档来判断 API 的关联关系，对 API 进行分组排序并实现数据关联，从而生成测试的流程。
上述的三个功能目前在进行小范围的用户内测，内测过程中，我们也发现了一些问题要改进。比如通用大模型 AI 由于缺少高质量的 API 的训练数据，没有办法完全理解 API 的使用场景，尤其是一些专业领域的 API，或者是基于内部需求而设计的 API，导致生成出来的 API 单元测试的用例覆盖不全，或者生产出来的正确率比较低，目前我们内测发现正确率在 30% 左右，后期依然需要一些人工进行修正。
另外就是在线的大模型，可能会有一些数据合规的风险，虽然测试用例的数据并不敏感，但不同行业的保密要求不一样，有一些可能没有办法连接外网，因此如果能够在规模稍小一点的离线模型上实现这个需求，使用场景会更广一些。我们预计在第四季度会有正式的功能发布，并且到时候也会逐步同步到开源产品里面。
