1月16日,Google DevFest 2021 广州国际嘉年华 在开发者们的掌声中顺利落幕。本次活动集合了 Eolink CEO 刘昊臻也做出了精彩的分享。
我们这次也为错过活动的同学们准备了 Eolink 演讲部分的图文版本,主题是《研发团队如何围绕 API 进行高效协作》,一起来回顾一下吧!
点击页尾阅读全文,即可获取完整版演讲 PPT。
- 简述
- 重新认识 API
- API 开发的痛点与协作理论
- Eolink 开源计划
![](https://data.eolink.com/2022-08-01/1659334844-285945-640-2.jpg)
Hello 大家好,我是 Eolink CEO 刘昊臻,目前在 Eolink 负责产品和战略相关的工作。
Eolink 是一家专门为开发者提供各类 API 生产力工具的公司,也是目前国内最大的在线 API 研发管理平台,从 2017 年至今累计为超过 5 万家企业提供 API 管理、测试等服务,同时也是国内最大的企业级 API 管理平台。
今天的话题是研发团队如何围绕 API 进行高效协作,和大家分享一下 API 行业的一些发展现状,以及目前行业内普遍遇到的一些 API 管理问题以及解决方案。
| 为什么围绕 API ,API 有这么重要么?
在此我们得问一个问题:为什么围绕 API 进行团队协作,API 有这么重要么?为了解决这个问题,我们可能得重新认识一下 API 。
2017年投资人问我:API 是什么?用来做什么的?
我说:API 是企业对外输出数据和服务的标准方式,对于企业来说是重要的数字资产,现在有大量的公司通过 API 对外提供标准化的服务等等。
但是他没听懂,于是我说 API 是系统之间用来对接的桥梁,可以理解为是一种技术工具,帮你把不同的系统、服务、数据对接起来。
他说明白了,原来 API 是一个工具。
到了2021年,我遇到另一位投资人,他问我为什么到处都是 API 和 API 相关的产品?
我说了类似的话:API 是企业对外输出数据和服务的标准方式,对于企业来说是重要的数字资产,现在有大量的公司通过 API 对外提供标准化的服务……现在上到政务、银行,下到小而美的 SaaS 公司都在使用 API 拓宽自己的业务边界。
这一次,投资人说他明白了,因为 API 是数字资产,而且很标准化。
这几年来,行业对 API 的理解其实已经发生了许多的变化,从纯技术的角度来看,其实 API 这个概念太简单,我们每天随手写都可能写几个,几乎每个技术分享都会提到使用了某某底层 API 来实现功能。但如果从业务和市场的角度来看,目前绝大部分的 SaaS 公司都提供了非常丰富的第三方 API ,目前海外增长最迅速的软件公司都和 API 相关。
所以 API 是什么?如果跳出技术的思维去看,事情会变得有趣许多。我们可以看几个数据。
![](https://data.eolink.com/2022-08-01/1659335072-183889-640-3.jpg)
首先是 IT 团队整体花在 API 相关工作上的时间超过了 50%,比如设计 API 、开发 API 、测试、对接、维护等等。如果仔细想想会发现 API 贯穿了整个研发团队的工作流程;
其次是全球可统计的外部 API 数量在 2014 年已经突破100亿个,这不包括企业内部和系统内部调用的 API;
IBM 认为全球 API 经济规模在 2018 年已经突破 2.2 万亿美元,而中国作为农业大国,同年的农业总产值约 1 万亿美元,也就是相当于两倍的中国农业总产值。
经过这几年我们的观察和思考,会发现 API 行业发展有几大推动力,首先是公有云基础设施的不断完善、微服务架构的普及让系统不断拆分,API 数量呈现爆发式增长,其次是团队围绕 API 工作的分工与协作越来越多,然后是越来越多企业使用第三方 API 和开放 API 。
![](https://data.eolink.com/2022-08-01/1659335215-990559-640-4.jpg)
因此目前我们再看 API 是什么,其实 API 正在从一个技术工具转变为数字资产。原本我们通过代码和 API 来创造软件,现在则是要创造更多 API ,API 从生产资料变成了劳动的产品。
因此越来越多公司开始关注 API 的连接价值,将更多的研发精力投入到围绕 API 的工作中,由此才引发了我们今天讨论的话题,如何帮助这些团队把 API 开发协作做得更好一点。
| API 开发协作的痛点与解决理论
接下来我们看一下 API 开发协作的痛点和我们的一些理论经验。
首先,我们依然要问几个小问题:
你知道自己开发的 API 被谁(系统)调用了么?
你知道你调用的 API 在什么时候、被谁、改动了什么地方么?
你会花时间编写完善的 API 测试用例吗?如果 API 发生了变化,测试用例会自动更新吗?
自动化的 API 测试是不是很难坚持实施?如何跟着开发的进度,快速做回归测试?
这些问题其实并不是多么深奥的技术问题,而是团队协作过程中的工程问题。
![](https://data.eolink.com/2022-08-01/1659335590-470100-640-5.jpg)
我们过去经常对用户进行调研。以上是我们从 2017 - 2021 年做的调研中,发现的一些国内的研发团队经常遇到的问题。比如 API 文档管理很繁琐,开发不想写文档但是没有文档又不好和其他人协作,过一段时间自己都忘了这个 API 当时怎么设计的;或者 API 版本是混乱的,不知道 API 在什么时候被什么人改了什么地方。这些小问题组合起来就让团队里所有围绕 API 工作的相关人员陷入反复的沟通中。
对于测试团队而言,则是 API 测试的维护成本偏高。因为 API 文档变更不及时,就算变更了也不会直接影响测试用例,所以用例往往是旧的,更不用谈自动化测试了。
| Eolink 服务的理论基础:文档与测试驱动开发
![](https://data.eolink.com/2022-08-01/1659335645-935872-640-6.jpg)
文档驱动开发指的是在开发之前先把文档写好,明确功能需求、入参出参定义、异常情况处理等之后再进行开发。这就好比我们在做题之前需要先了解清楚题目要求,否则不审题就下笔很容易导致最后返工。
而测试驱动开发指的是在开发之前先把测试方案/用例写好,要求开发人员开发的代码能够顺利通过测试,如果测试不通过则持续进行改进。这就好比我们考试前会先了解考试通过的标准,没有标准乱答一通肯定没有好结果。
而通过以上两种开发方式进行结合后就是 Eolink API 研发管理平台 的设计理念:文档与测试驱动开发(DTDD)。
简单地说就是:
![](https://data.eolink.com/2022-08-01/1659335764-48121-640-7.jpg)
因此,在 Eolink API 研发管理平台中,几乎所有的协作工作都是围绕着 API 文档进行的,当您创建了 API 文档之后,您可以随时查看 API 的改动情况、根据 API 文档发起 API 测试、编写 API 测试用例、创建 Mock API 、进行 API 自动化测试等。
基于以上的理论,我们从17年开始设计 Eolink 这个产品,希望能帮助研发团队解决协作的问题。这是目前市面上其他类似的或者模仿 Eolink 的产品所不具备的理论基础。
![](https://data.eolink.com/2022-08-01/1659335809-511233-640-8.jpg)
从 API 的设计、生成、管理等,到 API 的测试、自动化测试、定时测试等,Eolink 都为研发团队提供了完整且强大的 API 服务能力。
![](https://data.eolink.com/2022-08-01/1659335843-116987-640-9.jpg)
![](https://data.eolink.com/2022-08-01/1659335857-511824-640-10.jpg)
在以往的协作方式中,测试人员工作往往排在最后进行,无法参与项目讨论,无法进行快速大范围回归测试,甚至无法按时完成测试导致项目延期。但这本质上不是测试团队或者研发团队的问题,而是目前的整个工作流程还有许多尚未改进的地方,流程不够自动化。
在 Eolink API 研发管理平台中,由于协作是基于 API 文档进行的,当后端开发人员将 API 文档写好之后,测试人员就可以马上介入,在 API 文档的基础上编写测试用例,让测试工作前移。
当 API 开发完成之后,测试人员可以一键将 API 的测试用例全部测完,并且得到详细的测试报告。后端开发只需要看到测试结果就能够知道自己的 API 是否满足测试需求,如果有异常则可针对性改进。
当 API 发生改变后,测试人员只需要一键即可进行 API 回归测试,真正解放劳动力。
通过上述方式,后端和测试人员可以进行更紧密地沟通,让测试驱动开发完成。
![](https://data.eolink.com/2022-08-01/1659336564-716815-640-11.jpg)
![](https://data.eolink.com/2022-08-01/1659336571-996862-640-12.jpg)
![](https://data.eolink.com/2022-08-01/1659336577-652994-640-13.jpg)
而当我们实现了这些功能之后,我们再重新回顾一下刚才看到的API协作流程图,一切似乎就变得清晰了起来,团队协作围绕清晰的 API 文档来同步工作,互相之间的等待和摩擦变少,整体的团队效率就变高了。
![](https://data.eolink.com/2022-08-01/1659336618-364713-640-14.jpg)
然而讲了这么多,API 的问题其实也只被解决了一部分,当我们从上帝视角来看 API 的生命周期,就会发现这其实是个流程比较长、涉及到跨岗位跨部门协作的系统性问题。
除了刚才提到的研发和测试,后续还有运维和开放等场景的问题需要解决,比如你如何管理发布上线的 API 流量,你如何保障 API 的安全和稳定性,你如何知道 API 当前的访问情况等等。
但这个篇幅就比较多了,我们可以留个念想,欢迎感兴趣的朋友直接访问我们的 Eolink 官网 www.eolink.com 作进一步了解,我们提供了强大且免费的产品供大家使用,各位可以直接注册且不限制人数的使用。
| Eolink 开源计划
借着这个机会,我们也很高兴和大家聊聊产品的开源计划,我们打算把两个核心产品逐步开源,让更多开发者和企业都能使用到我们的产品,并且促进 API 生态的发展。
![](https://data.eolink.com/2022-08-01/1659336698-176261-640-15.jpg)
第一个是我们会把目前的 API 管理的核心模块开源,提供高效的 API 管理和测试功能,并且后续可以通过自定义插件来扩展功能。我们把这个项目命名为 EOAPI ,也就是 Easy & Open API ,这也是我们 2016 年做的开源产品的名字,这算是一种对产品和社区的回归。
EOAPI 从 21 年第四季度起立项开发,目前我们正在进行内测以及合规检查,预计最快会在 2 月底正式发布。后续我们会不断扩展第三方模块并且组建模块市场,让社区的开发者都能一起参与进来。
![](https://data.eolink.com/2022-08-01/1659336769-702929-640-16.jpg)
第二个是把我们的商业API网关彻底重构之后开源,我们把它叫做 Apinto ,这个名字是由 API 和 Into 两个单词组合而成,意味着 API 的入口。
这是一个完全由 Golang 编写的高性能微服务网关,在相同环境下最高可比Nginx、Kong 等开源产品提高50%的访问性能,并且拥有极低的使用和部署门槛。和 EOAPI 一样,Apinto 也是一个插件系统,可以自由编写插件来扩展功能。
![](https://data.eolink.com/2022-08-01/1659336842-163697-640-17.jpg)
Apinto 已经在 Github 上开放了源代码,如果大家觉得挺有意思欢迎大家 star 三连,最近我们在完善官网和文档以及插件市场,预计Q2会发布官方的UI控制台,方便通过界面来更好地使用它。
![](https://data.eolink.com/2022-08-01/1659336885-232359-640-18.jpg)
【若二维码失效,可公众号回复“进群”】最后,欢迎所有感兴趣的小伙伴微信扫码加入我们的开源产品交流群,左边是 EOAPI —— API 管理和测试工具的,右边是 Apinto —— API 网关。我和我们团队的工程师都在里面,期待和大家交流。
以上就是今天的分享内容,谢谢大家,也谢谢所有 GDG 的工作人员和主协办单位。