【干货】3分钟了解 API 全生命周期

Eolink 高级前端开发工程师、Eoapi PM & 开发的秦一，和大家分享 API 全生命周期有关的产品以及理念，希望使用通俗易懂的例子，让大家快速地了解：

1. 用户是谁

2. 产品能为用户提供什么价值

API 是什么？

API 中文全称是应用编程接口，从纯技术的角度去描述 API，就会说API 是一种在软件系统间通信的方式。这时候我们就会用 HTTP API、Websocket API 去描述它。

我们先来看看和 API 有关的趋势，先看以下三个数据。

这些数据都表明， API 行业正在飞速发展。

推动行业发展的因素

经过这几年我们的观察和思考，会发现推动 API 行业发展的因素有两个，科技的进步和数字化转型。

首先说说科技的进步，随着公有云基础设施的不断完善、微服务架构的普及让系统不断拆分，API 数量呈现爆发式增长。

• 微服务

微服务是一种通过多个小型服务组合来构建单个应用的架构风格。听起来有些技术，所以我拿现实中设计产品作为例子。

如果所有功能都加到同一个产品上，功能越来越多，每个功能满足多种用户的需求越来越难。

慢慢地用户多了起来，我们疯狂迭代，功能也多了起来。

最后产品变得更灵活了，加功能也方便，也能满足不同用户的需求。

而微服务就是通过多个小型服务组合来构建单个应用，拆成小的服务后，系统的服务复杂度是不是低了，可以自己管自己了，也可以在每个服务用不同的语言，让不同的团队负责不同的服务等等。

那微服务和 API 有什么关系呢？

我们知道，所有服务都在一个应用里面的叫单体架构。

当它里面的每个业务逻辑都被分解为一个微服务，就变成了微服务架构。通常情况下，这些客户端并不能直接访问后台微服务，而是通过 API 网关来传递请求。

单体架构通过 API 网关来传递请求

这些微服务间沟通交流的方式就是 API。

• 数字化转型

推动行业发展的第二个因素是数字化转型。

近年来数据的价值被逐步发现，企业和政府都在追求数字化转型，从我们国家政策就可以看出来，习主席说要以数字化转型驱动变革。

所以在这些背景下，越来越多的场景需要通过 API 进行数据的传递和交换，通过 API 发挥出数据最大的潜能。

API 是产品

其实这几年来，行业对 API 的理解已经发生了许多的变化。

实际上我们平时常说的 API 指的是 API 背后提供的服务或数据，例如短信接口、天气接口。

跳出技术的思维去看，API 正在从一个技术工具转变为数字资产。

原本我们通过代码和 API 来创造软件，现在则是要创造更多 API ，API 从生产资料变成了劳动的产品。

一款产品是为了解决什么问题而生的，首先要了解：用户是谁？

用户是谁

我们产品的真正使用者是那些和 API 打交道的人，也就是是研发团队。角色可能是：

• 开发人员：前端、后端

• 测试

• 运维

用户日常工作流程

用户日常工作和流程是什么？

产品经理提出功能需求，说这个产品要设计成什么样子，然后开发接到需求之后，开始根据需求开发，开发完后提交测试，测试完了进行迭代，然后产品验收后让运维人员发布上线。

全生命周期产品

实际上 API 贯穿了整个产品交付的流程，近年来越来越多公司开始关注 API 的连接价值，将更多的研发精力投入到围绕 API 的工作中。

所以我们想帮助这些团队把 API 管理得更好，制作了 API 全生命周期产品，主要包括四大块：

• 开发

• 测试

• 运维

• 开放

API&产品&人

我们的产品如何帮助人去管理各个生命周期里面的 API 呢？

• API 研发管理&自动化测试

先分享两个理念，第一个是文档驱动开发。

文档驱动开发指的是在开发之前先把文档写好再进行开发，能够帮你提前思考，这就好比我们在做题之前需要先了解清楚题目要求，否则不审题就下笔很容易导致最后返工。

除此之外还能方便协作，就像造车，车不是你一个人造的，造车身的人如果提前能告诉造底盘的人轮子要多大，造底盘的就不用等他了，效率多高。

而测试驱动开发指的是在开发之前先把测试方案/用例写好，要求开发人员开发的代码能够顺利通过测试，如果测试不通过则持续进行改进。

这就好比我们考试前会先了解考试通过的标准，没有标准乱答一通肯定没有好结果。

而通过以上两种开发方式进行结合后就是 Eolink API 研发管理平台的设计理念：文档与测试驱动开发（DTDD）。

在我们平台怎么践行上面的理念呢？

如果不用我们平台，流程可能是：

后端先开发 API，开发完后写了文档告诉前端，前端等文档好了之后再对接，最后提交给测试。

再来看看用了我们平台之后的流程，很多流程都可以提前到开发阶段了发现没有？串行直接变并行，这效率不提高才怪！

在我们平台几乎所有的协作工作都是围绕着 API 文档进行的，所以开发流程就变成了后端先设计好文档，然后动手去开发 API。

前端对页面进行开发，光写页面肯定不够的，还得通过 API 拿数据对接页面，前端可以使用平台上的 Mock 功能先对接，后端好了之后就可以直接提交给测试。

测试人员在开发阶段也没有闲着，文档出来之后他们就可以去准备测试用例了，等联调完后直接一键回归测试。

• API 监控

上线之后，某些关键业务比如说登陆、购买功能挂了的话对产品影响会很大，所以要对这些 API 进行监控 — — 按照一定频率发起请求。

例如我就使用我们的 API 监控去监控线上的某个关键功能，如果挂了他就会给相关人员发邮件，提醒他们赶紧去处理事故。

• API 网关

在 API 生命周期的运维阶段还有一个产品，那就是 API 网关。

前面提到过，一般微服务架构的系统都会需要 API 网关，这是为什么呢？

我还是拿产品设计当例子，虽然说我们拆分了极速版和标准版，但是是不是里面有一些基础功能肯定是一样的，如果每个产品都实现一遍，成本是不是很高？那怎么办？

有人就提出，这样吧，以后每次开发前，都要给产品老大看一下，如果有相同的需求，他来调度资源。

过滤需求

API 网关就是就是像产品老大这样的人，无论你想访问哪个服务，都先来到网关这，网关再帮你转发，网关就是微服务的代言人。

一般网关会做什么呢？– 负载均衡。

这是客户端向服务端发起请求的示例，这时候只有一个 API 请求，网络十分顺畅。

随着上线的人越来越多，向服务器请求的客户端也越来越多，就像 12306 高峰期抢票，访问的人越多，服务越容易挂掉，它容量就这么大，怎么办？

微服务架构有个特性就是可以横向拓展，那这时候我们横向拓展多一台服务器，再让网关帮我们统一分配请求，这样就将负载均分到了不同的服务器，以求平衡，这就是所谓的负载均衡。

除此之外，API 网关还可以做统一的身份验证，不符合身份验证的请求挡回去，以及加入黑白名单和限速等等防止资源滥用。

• API 开放平台 & APISpace

讲完了研发运维阶段的产品，我们来看看 API 开放和交易的产品，有两个，API 开放平台和 APISpace。

用户可以在企业内部将 API 开放给其他团队用，也可以作为产品例如短信接口售卖给外部的人。

为用户提供什么价值

最后，我们希望能够通过：

提供一站式的 API 管理产品提升企业 API 研发管理效率，解决企业内部服务间 API 管理、测试、性能和安全的问题。

建立统一的 API 交易平台，帮助企业对外提供 API 服务，打造 API 经济，帮助全球开发者查找、开放、购买、测试及使用 API 。

最终达到我们的使命：

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。