Eolink: 数字化企业连接世界的第一接口｜开发者说

原创 团队版免费 ONES

Eolink 的创业方向是一次无心插柳。

在 Eolink 创办之前，创始人刘昊臻先后参与了技术外包、在线医疗、O2O 电商等创业项目，但是觉得不太符合自己的期望。

2015 年底，刘昊臻想更好地管理团队内部的 API，但市面上的产品并不能满足需求，于是，他决定做个产品来解决 API 协作问题。没想到，这个产品不仅解决了自己的麻烦，还可以解决所有 IT 团队遇到的有关 API 的共同难题。

接着，刘昊臻将这 API 管理产品开源出来，在得到许多用户的认可后，他成立了 Eolink，公司的产品逐步发展为一个定位于企业级的 API 全生命周期平台，通过标准化的产品为中大型客户提供 API 快速生成、API 研发管理和团队协作、自动化测试、微服务网关、API 监控以及 API 开放与交易服务。

API 全生命周期平台

IT 界有个康威定律：设计系统的架构受制于产生这些设计的组织的沟通结构。在早期开发软件，由于软件的系统复杂度不高，所有代码通常被封装成一个整体，这种架构叫做单体应用。这种软件架构是高度集成的，就像那时候的软件企业一般什么东西都自己做，也很少用第三方开源代码或者 API。

后来随着软件产品形态的发展（包括 PC 客户端转向 Web、手机端）、开源的发展、以及人们对软件开发效率的追求，企业开始用开源代码或者第三方 API 代替边缘的代码。这时候出现了前后端分离、DevOps 的风潮，并出现了第一批 API 管理的工具，比如 Swagger、Postman 等，目标都是解决 API 的文档管理和 API 快速测试的问题。

现在，随着云原生的概念普及，和微服务架构改造的风潮，越来越多的企业大量使用了开源组件、第三方的 API，甚至底层的核心技术几乎都是来自于开源组件和第三方 API，比如声网就给大量做直播的企业提供了直播相关的 API。Linux 基金会的数据显示，70-90% 的代码是由开源代码和第三方 API 来组成的。

因此，软件的开发变得越来越「乐高化」，也就是说开发者可以很快地通过开源组件及第三方 API 来拼凑出一个产品，而这时候的企业组织也变得更加零散。

基于这些考虑，Eolink 在 2016 年做了两个判断：

第一点，API 会爆发式增长，由此会带来一系列的研发、测试、运维等问题。就像是你有 100 行代码的时候，你可以不做任何事情，但你有 1,000 行代码的时候，就必须由 Git 来帮你管理代码。

第二点，越来越多的企业会开放 API，由此会带来开放、推广、销售、品牌、运营等问题。比如谁能找到你的 API，开发者怎么知道哪些 API 更好或更适合自己，企业怎么运营自己的开发者社区等。

所以，Eolink 希望把 API 的全生命周期都串联管理起来，所谓「API 全生命周期」包含了三个层面——设计、实施和管理，而这三个层面又细分为 API 的设计、研发、测试、部署发布、运维监控、版本管理和下线。

其他的同类产品一般来说只覆盖其中一个层面，要么就是设计（设计、测试）、要么就是实施（部署发布、运维监控）、要么就是管理（版本管理和下线）。Eolink 的产品则是比较全面，覆盖了整个 API 全生命周期。

其中，Eolink 的核心产品是 API 文档管理、API 自动化测试、API 监控、API 网关、API 开放平台、API 交易。

ONES：你们怎么理解 API 在软件研发中的价值？怎么定义 Eolink 在此过程中的角色？

梁顺安：

在 API 领域，我们看到有几个大的推动力在促进 API 行业的快速发展。

首先是技术变革的推动力。由于公有云等技术的发展，让软件逐步拆解为微服务架构，而拆分微服务的过程中就会产生大量的 API，围绕着 API 的管理需求也就快速成长起来。

最后是企业服务交付方式改变的推动力。因为 API 是一个数据和服务的标准载体，几乎所有的互联网服务都通过 API 的方式来传输和交易，因此 API 是有强资产属性的，随着越来越多的企业使用 API，并且通过 API 提供服务，这样明确的商业供求关系也推动了 API 行业在未来相当长时间的持续增长。

陈景范：

从这个意义上来说，API 是企业的一笔资产，而 Eolink 就是协助企业管理好 API 这笔资产的平台。尤其是进入「万物互联」的时代后，API 就是企业与世界互联的第一接口。

ONES：你们自己在技术开发上遇到过哪些困难？如何克服这些困难？

梁顺安：

我们最大的困难一直都是喜欢做创新的事情，而创新本来就是极高风险的。

国内许多人创业做产品是看海外有什么成熟的模式和产品就搬到国内，而我们在 2016 年做 API 全生命周期时，国外其实也都还没有成熟的概念和产品，纯粹是基于我们对用户需求和市场趋势的判断来做，因此当时最难的是摸着石头过河，每天通过和用户聊天来收集需求、设计产品和商业模式。

到了 2017 年我们想做一个零代码的 API 自动化测试，当时市面上的产品基本都是需要写代码来做自动化的，即使是 Postman 也是在这两年才推出了流程测试。相当于我们又再一次做一些别人没怎么做过的事情，但我们相信这种冒险对用户是有好处的，所以花了大量时间来设计产品，最终做了国内第一个零代码的 API 自动化测试。后面有许多 API 产品都参考了我们的设计，从某种意义上来说，我们也是推动了整个行业的发展。

Eolink 产品示意图

从 2018 年开始，我们一直在尝试覆盖 API 全生命周期的各个阶段，推出一个一站式的 API 平台，并且在此基础上做成标准化产品。在经过两年的打磨之后，我们在 2020 年推出了国内第一个标准化的 API 开放平台。

陈景范：

另一个难点就是 IT 团队永恒的话题——人效的问题，怎么样能更快速地给客户提供价值。

我们主要还是使用一些常规的管理手段，譬如 OKR，这里最令人头大的问题是怎么本土化，做一个符合公司的 OKR，另外就是通过一些技术工具来提高我们自己的人效。

我们现在在做的一个很重要的事情就是怎么结合我们自己的产品将研发侧的 DevOps 做得更好，譬如刚刚说的 API 文档和自动化测试都有共同的特点，就是快。我们内部搞了不少 Beta 版本的工具用于自动生成 API 文档和测试用例，来实现降本增效。

还有一个重点地方就是使用 ONES 做项目管理。整个软件工程的研发都围绕着 ONES 来做管理，让研发过程更井然有序，更加合理安排人力资源的问题。

ONES：万物互联时代的 API 管理将如何演化？贵公司将在其中扮演怎样的角色？

陈景范：

现阶段大部分公司内部的 API 管理状态，基本上都是单点管理。所谓单点管理就是每个部门都只管理自己产生的 API，其他部门、甚至部门对自己所拥有的 API 信息明细是不大清楚的，这就会导致很多额外的沟通成本、管理成本、协调成本。

解决这个问题首先就要有一个 API 平台，也就是说，要能一次性处理 API 的信息有关问题，以及 API 协调问题，让部门内部的沟通、管理、协调成本降低。这还只是部门内部的麻烦，跨部门其实也有这种困扰，只要将 API 平台从部门平台提升到公司平台就能解决跨部门的成本问题。解决了公司内部的问题后其实还有一个互联网领域的问题，譬如不同的部门、子公司之间其实不单只可以考虑部门、子公司之间的 API，还可以考虑公司外部的 API 消费使用。

这个过程就是 API 如何平台化，主要涉及到三个层面：第一层面是部门内部的 API 平台，第二层面是公司内部的 API 平台，第三层面是万维网的 API 平台，我们公司的战略方向其实就是将这三个层面都做好，这期间会将整个 API 生态给串连起来。

ONES：你们的产品助力企业客户数字化生态建设，那么，你们自己是怎样打造生态的？

陈景范：

API 生态存在一些不确定性，从 API 资产维度来说，现在有些科技公司的产品就是一个一个的 API，譬如一些直播 API 和语音 API 等等，这些已确定的 API 资产能构建一个很好的消费者 API 生态。未来，这些 API 产品越多，这个生态就越大，我们的产品价值也会越大。当然，我们相信未来肯定会有越来越多的 API 产品，多到像电商产品那样，同类型的产品会有多个牌子供大家选择。

关于超越 API 这个事情，首先我们未来的战略方向关键点是在于 API 平台以及 API 生态这两个关键点上。

我们还可以跟一些公司构建互为生态的关系，例如 ONES。我们两家公司的产品，一个是覆盖 API 全生命周期，一个是覆盖研发管理的全生命周期。在用户价值、兼容国产硬件以及系统、产品推广、销售线索方面，我们基本上都是研发团队不可或缺的工具平台，这一方面就说明了我们的客户群体应该是高度重合的，彼此有不少互相借鉴学习的地方。

ONES：Eolink 的目标是为了提升企业客户的研发效率，那么 Eolink 是怎么提升自己的研发效能的？

梁顺安：

我们以前用过国外的研发管理工具，在使用的过程中，不仅我们，很多开发团队都觉得那些工具并不符合自己的管理流程。我们往往需要在这些工具上做二次开发，其实用起来的难度是不小的。可以说，这样的管理工具算不上效率工具。这样，我们只好寻找其他研发管理工具。

因为我们跟 ONES 有共同的企业客户，在业务上也有互为生态的关系，所以，后来我们在自己的研发管理中也开始使用 ONES。

在选择 ONES 之前，其实我们调研过很多这方面的产品，最终推动我们做决定的原因主要有两点，一是 ONES 功能齐全，覆盖研发管理全生命周期确实不是浪得虚名的（产品矩阵真的很丰富），二是 ONES 的功能上手相对简单。

必须承认的是，ONES 更贴合我们自己的研发环境，符合我们日常的管理流程和习惯。打个比方，倘若我想在国外的研发管理软件的 SQL 做缺陷查询聚合，那么我需要手动写一些类似编程的字段语句。但 ONES 是不需要这么麻烦的，因为它本身已经集成了相关的生成器，有关的图表也是可以直接用的。当涉及 DevOps、私有云部署，以及一些工具集成等方面，ONES 也比国外的同类工具更好用。另外，如果我们想要找客服，那么我们在白天是可以找到 ONES 的客服的，但因为时差的原因，国外的客服在我们的白天里是找不到的。

用了 ONES 之后，需求管理、项目管理和缺陷管理都更加有条不紊，项目数据也更容易跟踪和统计。