关于api:AI-与智能化-API-治理的探索实践

1次阅读

共计 6033 个字符，预计需要花费 16 分钟才能阅读完成。

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 是十分常见的。

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 治理的需要也不太一样，比方对于 100 人以下，或者 API 在 1000 以内的小规模团队来说，最关注的是如何将 API 作为一个标准化的步骤来接入到现有的 devops 流水线中，进步围绕 API 的开发测试的效率。

比方，通过 IDE 的插件将代码注解或者是代码间接生成 API 文档，通过平台来生成接口的单元测试用例，并且可能组合成自动化的测试流程，不便每一次迭代的时候进行冒烟测试以及版本升级后的回归测试。同时，在一直的迭代中，治理 API 不同版本之间的差别，并且把报告同步到团队中。API 作为 devops 中的一个环节，能够补充现有的研发效力体系，并且进一步的晋升产品的品质。

对于更大规模的团队来说，单纯的 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 的可观测性。

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 治理测试工具 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

【Eolink AI 新性能三大能力高清视频】：
https://www.bilibili.com/video/BV1sj411S7j4/?spm_id_from=333….

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% 左右，前期仍然须要一些人工进行修改。

另外就是在线的大模型，可能会有一些数据合规的危险，尽管测试用例的数据并不敏感，但不同行业的窃密要求不一样，有一些可能没有方法连贯外网，因而如果可能在规模稍小一点的离线模型上实现这个需要，应用场景会更广一些。咱们预计在第四季度会有正式的性能公布，并且到时候也会逐渐同步到开源产品外面。

感兴趣的小伙伴，欢送关注咱们 Eolink

正文完