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 呢?
先分享两个理念,第一个是文档驱动开发。
文档驱动开发指的是在开发之前先把文档写好再进行开发,能够帮你提前思考,这就好比我们在做题之前需要先了解清楚题目要求,否则不审题就下笔很容易导致最后返工。
除此之外还能方便协作,就像造车,车不是你一个人造的,造车身的人如果提前能告诉造底盘的人轮子要多大,造底盘的就不用等他了,效率多高。
而测试驱动开发指的是在开发之前先把测试方案/用例写好,要求开发人员开发的代码能够顺利通过测试,如果测试不通过则持续进行改进。
这就好比我们考试前会先了解考试通过的标准,没有标准乱答一通肯定没有好结果。
而通过以上两种开发方式进行结合后就是 Eolink API 研发管理平台的设计理念:文档与测试驱动开发(DTDD)。
在我们平台怎么践行上面的理念呢?
如果不用我们平台,流程可能是:
后端先开发 API,开发完后写了文档告诉前端,前端等文档好了之后再对接,最后提交给测试。
再来看看用了我们平台之后的流程,很多流程都可以提前到开发阶段了发现没有?串行直接变并行,这效率不提高才怪!
在我们平台几乎所有的协作工作都是围绕着 API 文档进行的,所以开发流程就变成了后端先设计好文档,然后动手去开发 API。
前端对页面进行开发,光写页面肯定不够的,还得通过 API 拿数据对接页面,前端可以使用平台上的 Mock 功能先对接,后端好了之后就可以直接提交给测试。
测试人员在开发阶段也没有闲着,文档出来之后他们就可以去准备测试用例了,等联调完后直接一键回归测试。
上线之后,某些关键业务比如说登陆、购买功能挂了的话对产品影响会很大,所以要对这些 API 进行监控 — — 按照一定频率发起请求。
例如我就使用我们的 API 监控去监控线上的某个关键功能,如果挂了他就会给相关人员发邮件,提醒他们赶紧去处理事故。
在 API 生命周期的运维阶段还有一个产品,那就是 API 网关。
前面提到过,一般微服务架构的系统都会需要 API 网关,这是为什么呢?
我还是拿产品设计当例子,虽然说我们拆分了极速版和标准版,但是是不是里面有一些基础功能肯定是一样的,如果每个产品都实现一遍,成本是不是很高?那怎么办?
有人就提出,这样吧,以后每次开发前,都要给产品老大看一下,如果有相同的需求,他来调度资源。
过滤需求
API 网关就是就是像产品老大这样的人,无论你想访问哪个服务,都先来到网关这,网关再帮你转发,网关就是微服务的代言人。
一般网关会做什么呢?
– 负载均衡。
这是客户端向服务端发起请求的示例,这时候只有一个 API 请求,网络十分顺畅。
随着上线的人越来越多,向服务器请求的客户端也越来越多,就像 12306 高峰期抢票,访问的人越多,服务越容易挂掉,它容量就这么大,怎么办?
微服务架构有个特性就是可以横向拓展,那这时候我们横向拓展多一台服务器,再让网关帮我们统一分配请求,这样就将负载均分到了不同的服务器,以求平衡,这就是所谓的负载均衡。
除此之外,API 网关还可以做统一的身份验证,不符合身份验证的请求挡回去,以及加入黑白名单和限速等等防止资源滥用。
讲完了研发运维阶段的产品,我们来看看 API 开放和交易的产品,有两个,API 开放平台和 APISpace。
用户可以在企业内部将 API 开放给其他团队用,也可以作为产品例如短信接口售卖给外部的人。
七、为用户提供什么价值
最后,我们希望能够通过:
提供一站式的 API 管理产品提升企业 API 研发管理效率,解决企业内部服务间 API 管理、测试、性能和安全的问题。
建立统一的 API 交易平台,帮助企业对外提供 API 服务,打造 API 经济,帮助全球开发者查找、开放、购买、测试及使用 API 。
最终达到我们的使命: