Eolink 高级前端开发工程师、Eoapi PM & 开发的秦一,和大家分享 API 全生命周期有关的产品以及理念,希望使用通俗易懂的例子,让大家快速地了解:
1. 用户是谁
2. 产品能为用户提供什么价值
一、API 是什么?
API 中文全称是应用编程接口,从纯技术的角度去描述 API,就会说 API 是一种在软件系统间通信的方式。这时候我们就会用 HTTP API、Websocket API 去描述它。
我们先来看看和 API 有关的趋势,先看以下三个数据。
![](http://data.eolinker.com/course/e2ErjUA417ab7c4ba1c315bb40672ca229ab7007f0991e9)
这些数据都表明, API 行业正在飞速发展。
二、推动行业发展的因素
经过这几年我们的观察和思考,会发现推动 API 行业发展的因素有两个,科技的进步和数字化转型。
首先说说科技的进步,随着公有云基础设施的不断完善、微服务架构的普及让系统不断拆分,API 数量呈现爆发式增长。
微服务是一种通过多个小型服务组合来构建单个应用的架构风格。听起来有些技术,所以我拿现实中设计产品作为例子。
![](http://data.eolinker.com/course/hMEVKYDc1574868f491a8b8fa3e6bc8bdba69bba01cc973)
如果所有功能都加到同一个产品上,功能越来越多,每个功能满足多种用户的需求越来越难。
![](http://data.eolinker.com/course/XqDLVDid2f0322244ae0cd1f9bf97adf67a07eb2c7f9386)
慢慢地用户多了起来,我们疯狂迭代,功能也多了起来。
最后产品变得更灵活了,加功能也方便,也能满足不同用户的需求。
![](http://data.eolinker.com/course/AtaXnP417be8f78eb1e71f14832b3162800a0cafa80c3ba)
而微服务就是通过多个小型服务组合来构建单个应用,拆成小的服务后,系统的服务复杂度是不是低了,可以自己管自己了,也可以在每个服务用不同的语言,让不同的团队负责不同的服务等等。
那微服务和 API 有什么关系呢?
我们知道,所有服务都在一个应用里面的叫单体架构。
当它里面的每个业务逻辑都被分解为一个微服务,就变成了微服务架构。通常情况下,这些客户端并不能直接访问后台微服务,而是通过 API 网关来传递请求。
![](http://data.eolinker.com/course/bIdiQvPaa19488d870ff957843bb4ff43569d074cd6bf9e)
单体架构通过 API 网关来传递请求
这些微服务间沟通交流的方式就是 API。
![](http://data.eolinker.com/course/aGbJ4uM6121e3391641e479a3e4973b32025ab464f793ee)
推动行业发展的第二个因素是数字化转型。
近年来数据的价值被逐步发现,企业和政府都在追求数字化转型,从我们国家政策就可以看出来,习主席说要以数字化转型驱动变革。
所以在这些背景下,越来越多的场景需要通过 API 进行数据的传递和交换,通过 API 发挥出数据最大的潜能。
三、API 是产品
其实这几年来,行业对 API 的理解已经发生了许多的变化。
实际上我们平时常说的 API 指的是 API 背后提供的服务或数据,例如短信接口、天气接口。
![](http://data.eolinker.com/course/KY2nspT9da72d4a8155469c24102ed61060ec191e831cbb)
跳出技术的思维去看,API 正在从一个技术工具转变为数字资产。
![](http://data.eolinker.com/course/gqabb7Zc6c6bc9480f726ff500d1bdc9db09216b1003e63)
原本我们通过代码和 API 来创造软件,现在则是要创造更多 API ,API 从生产资料变成了劳动的产品。
![](http://data.eolinker.com/course/1SmN4du379698a2c87a7a829082abcc325bafbe9e864a8f)
一款产品是为了解决什么问题而生的,首先要了解:用户是谁?
四、用户是谁
我们产品的真正使用者是那些和 API 打交道的人,也就是是研发团队。角色可能是:
五、用户日常工作流程
用户日常工作和流程是什么?
产品经理提出功能需求,说这个产品要设计成什么样子,然后开发接到需求之后,开始根据需求开发,开发完后提交测试,测试完了进行迭代,然后产品验收后让运维人员发布上线。
![](http://data.eolinker.com/course/9srrLwQ46f8db54537f4efa5919cb6ff117771a95c36fb0)
六、全生命周期产品
实际上 API 贯穿了整个产品交付的流程,近年来越来越多公司开始关注 API 的连接价值,将更多的研发精力投入到围绕 API 的工作中。
所以我们想帮助这些团队把 API 管理得更好,制作了 API 全生命周期产品,主要包括四大块:
![](http://data.eolinker.com/course/E2dXqnec5cc6e82247d723f8cb02376fb40d73da60e4bcb)
API&产品&人
我们的产品如何帮助人去管理各个生命周期里面的 API 呢?
先分享两个理念,第一个是文档驱动开发。
![](http://data.eolinker.com/course/ctekUXfbe61b233425522d38a8ccb6d743aa90c12f1703b)
文档驱动开发指的是在开发之前先把文档写好再进行开发,能够帮你提前思考,这就好比我们在做题之前需要先了解清楚题目要求,否则不审题就下笔很容易导致最后返工。
除此之外还能方便协作,就像造车,车不是你一个人造的,造车身的人如果提前能告诉造底盘的人轮子要多大,造底盘的就不用等他了,效率多高。
而测试驱动开发指的是在开发之前先把测试方案/用例写好,要求开发人员开发的代码能够顺利通过测试,如果测试不通过则持续进行改进。
这就好比我们考试前会先了解考试通过的标准,没有标准乱答一通肯定没有好结果。
![](http://data.eolinker.com/course/eVkM2wb315faee55f07e4939d64a7caf7b4e5ac639df910)
而通过以上两种开发方式进行结合后就是 Eolink API 研发管理平台的设计理念:文档与测试驱动开发(DTDD)。
![](http://data.eolinker.com/course/U7RdBYhd457fa6b11ae0eb5d5191b90299b0ad0fe943174)
在我们平台怎么践行上面的理念呢?
如果不用我们平台,流程可能是:
后端先开发 API,开发完后写了文档告诉前端,前端等文档好了之后再对接,最后提交给测试。
![](http://data.eolinker.com/course/43HSnHy69cf3ab567aaa7f0a58ad64ddaa612b171a3ba6b)
再来看看用了我们平台之后的流程,很多流程都可以提前到开发阶段了发现没有?串行直接变并行,这效率不提高才怪!
![](http://data.eolinker.com/course/uwttAale389581aba8d62adf38cd7f6befd8ce6e3822fc7)
在我们平台几乎所有的协作工作都是围绕着 API 文档进行的,所以开发流程就变成了后端先设计好文档,然后动手去开发 API。
前端对页面进行开发,光写页面肯定不够的,还得通过 API 拿数据对接页面,前端可以使用平台上的 Mock 功能先对接,后端好了之后就可以直接提交给测试。
测试人员在开发阶段也没有闲着,文档出来之后他们就可以去准备测试用例了,等联调完后直接一键回归测试。
上线之后,某些关键业务比如说登陆、购买功能挂了的话对产品影响会很大,所以要对这些 API 进行监控 — — 按照一定频率发起请求。
![](http://data.eolinker.com/course/vg3IZmF5bc42bb631564c7aa3b09c19a823c214eaf0dcda)
例如我就使用我们的 API 监控去监控线上的某个关键功能,如果挂了他就会给相关人员发邮件,提醒他们赶紧去处理事故。
![](http://data.eolinker.com/course/35XdDgP03c932662b50e6b9599d106ec2dfa8513c21a291)
在 API 生命周期的运维阶段还有一个产品,那就是 API 网关。
前面提到过,一般微服务架构的系统都会需要 API 网关,这是为什么呢?
我还是拿产品设计当例子,虽然说我们拆分了极速版和标准版,但是是不是里面有一些基础功能肯定是一样的,如果每个产品都实现一遍,成本是不是很高?那怎么办?
有人就提出,这样吧,以后每次开发前,都要给产品老大看一下,如果有相同的需求,他来调度资源。
![](http://data.eolinker.com/course/bbiAFrZ76ab210fea5a3634336be85142e4d91b9caea3c8)
过滤需求
API 网关就是就是像产品老大这样的人,无论你想访问哪个服务,都先来到网关这,网关再帮你转发,网关就是微服务的代言人。
![](http://data.eolinker.com/course/Snst2eCf9231d3e59975e7a55eb1432f99cc9394034dd31)
一般网关会做什么呢?
– 负载均衡。
这是客户端向服务端发起请求的示例,这时候只有一个 API 请求,网络十分顺畅。
![](http://data.eolinker.com/course/Aja5j5zf67e3be015d731486a2c73df2731b20969697c48)
随着上线的人越来越多,向服务器请求的客户端也越来越多,就像 12306 高峰期抢票,访问的人越多,服务越容易挂掉,它容量就这么大,怎么办?
![](http://data.eolinker.com/course/yIXAnV36275161d371bc9bb3cc597f2e68b2634d1b47ee1)
微服务架构有个特性就是可以横向拓展,那这时候我们横向拓展多一台服务器,再让网关帮我们统一分配请求,这样就将负载均分到了不同的服务器,以求平衡,这就是所谓的负载均衡。
![](http://data.eolinker.com/course/smDvyCP173d6524f28b71971443a47711a66b8e1124bec7)
除此之外,API 网关还可以做统一的身份验证,不符合身份验证的请求挡回去,以及加入黑白名单和限速等等防止资源滥用。
讲完了研发运维阶段的产品,我们来看看 API 开放和交易的产品,有两个,API 开放平台和 APISpace。
用户可以在企业内部将 API 开放给其他团队用,也可以作为产品例如短信接口售卖给外部的人。
![](http://data.eolinker.com/course/cT86Wua06e1c54790385dba0ac8398cefe4d5525336b9ab)
七、为用户提供什么价值
最后,我们希望能够通过:
![](http://data.eolinker.com/course/Iju9Yiz49254871f5ffb0973e0042fa37401cb3b64414ca)
提供一站式的 API 管理产品提升企业 API 研发管理效率,解决企业内部服务间 API 管理、测试、性能和安全的问题。
建立统一的 API 交易平台,帮助企业对外提供 API 服务,打造 API 经济,帮助全球开发者查找、开放、购买、测试及使用 API 。
最终达到我们的使命:
![](http://data.eolinker.com/course/B1IxGbA55a4ef5a3a463838806d6a73be5119b9af06dd9e)