8分钟丨教你玩转 API

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~

本文由 织云平台团队发表于 云+社区专栏

img

背景

当下,业界越来越多公司在项目架构设计时,会采用微服务架构。微服务架构,可以让我们的产品有更好的扩展性,更好的伸缩性;但同时也会带来微服务的一系列问题,比如微服务接口怎样规范管理?怎样在多团队协作中开放与复用?等等。

同时,业界也在逐渐的引入DevOps理念,来实现开发,测试,运维,运营更紧密的高效配合,提升产品迭代的效率,质量。

这里,织云API平台将从“部门内微服务API开放复用”,“产品线API DevOps实践”来分享腾讯社交网络运营部踩过的坑和API平台在“开放”,“DevOps”的理解及实践。

1API开放与复用

部门长期运营,积累了很多优秀的系统/平台,各个系统/平台也很早的开放了自己的Open API 给其它团队做二次开发和使用。

作为开放接口使用方:要集成A平台的B服务时,你可能会遇到:

  1. 找不到平台开放接口文档;
  2. 从平台官网下载的接口文档好像未更新;
  3. 接口文档定义太简单。看不懂;
  4. 使用前,不清楚接口的质量现状(成功率,耗时等);
  5. 出异常时,没法快速界定问题的边界。

作为开放接口提供方:你在运营上可能会遇到:

  1. 接入方很多,长久下来,自己都不清楚调用方是哪些?
  2. 最近我的接口调用量大增,不清楚这些调用是否合理?
  3. 旧接口要下线,但仍有请求。不方便快速找到调用者。

2产品线API那些事儿

织云,是腾讯SNG海量业务运维能力经验沉淀出的产品,它采用微服务架构。在微服务的开发,测试,交付,运营中,我们遇到这样子的问题:

  • web工程师:版本迭代很紧,但是后台同学的接口迟迟出不来,我的工作delay很久了

img

  • 后台工程师:版本迭代很紧,写代码的时间都没有。哪来时间写用例。但每次修改代码,人工自测耗费很多时间。

img

  • 两位工程师:上次不是好说接口长xx样子吗?怎样现在变成这样子了?

img

  • 质量工程师:这个迭代,织云性能是否达标呢?看不见,摸不着,快慢主要凭感觉。

img

  • 运维工程师:客户反馈操作有异常。一个问题都转几手开发。我怎样快速定位问题根源

img

  • 客户:你们的XX能力很好。我们想基于它们接口做二次开发。有开放接口吗

img

织云API平台,就是这种大背景下应运而生。

API平台简介

  • 定义

织云API平台,是一个以API服务管理和代理以基础,赋能接口开发,测试,上线运营,下线管理于一体的API管理与开放平台。

  • 应用场景

img

  • 功能介绍

img

1、织云API平台,实现了API统一规范管理与开放。 2、以服务代理为基础,实现了安全认证,过载保护。 3、对于服务调用支持日志查询,数据画像,异常告警,链路分析等功能。 4、可以基于API平台实现基于织云所有能力的定制开发的能力。

接口规范和接入成本

  • 接口规范

img

屏蔽接口URI层级差异:

API平台,统一采用三级结构,通过/平台/服务/接口的层次来管理所有接入API,屏蔽实际接口URI的层级差异;

屏蔽接口响应结构差异:

API平台,自动转换接口响应结构,屏蔽实际接口的结构差异化。大大简化了集成开发,特别是Web前端同学适配后台接口的复杂度。

全局业务错误码:

确保服务间的每个错误码都是唯一能溯源的。

  • 接入成本--零改造

API平台在设计之前就考虑到用户接入的成本。以上规范,API平台都能自动屏蔽差异,自动转换,自动生成。用户接入零改造。

注册API服务 — 示例

  • 现成的API接口

现在我有一个容量的分析接口:查询模块容量持续高低负载数据接口。

url: http://capacity/load/sustaine... method: get 入参:type=1&m1id=468095&m2id=468095&m3id=468095&m4id=468095 出参: [ { "m1id": 1256, "m2id": 1256010, "day_cnt": 14, "m4id": 468095, "avg_load": 0.25, "type": 1, "model_cnt": 1, "m3id": 11120 } ]
  • 创建接口对应的平台,服务

操作相似。如创建服务:

其中的英文缩写,将是最终API url中对应的服务名。

img

  • 注册接口 - 基础信息

img

  • 注册接口 - 定义请求示例

自动生成入出参:

在入参,出参示例部分,只须贴入:

入参:type=1&m1id=468095&m2id=468095&m3id=468095&m4id=468095, 出参: [ { "m1id": 1256, "m2id": 1256010, "day_cnt": 14, "m4id": 468095, "avg_load": 0.25, "type": 1, "model_cnt": 1, "m3id": 11120 } ]

API平台会自动帮我们解析结构(当前支持key/value, json结构等解析)

用户,只须录入字段是否必填,以及中文说明即可。

img

img

  • 注册接口 - 定义接口返回码

img

接口开放

  • 查看开放API接口

列表页:

在API平台注册接口后,可以在API平台列表中查询每个开放接口:

img

明细面:

在明细面,可以查看接口详情。以及自动生成的调用示例。

img

img

img

自动生成接口文档

img

  • 访问权限申请

API平台的接口开放模式暂时有两种:全开放,须审核。

全开放:

用户须在API平台应用组进行登记注册,API平台会分配一个唯一的apikey给到用户。对于全开放的接口,用户访问时,只须header带上apikey即可。

img

img

须审核:

对于一些敏感数据接口,用户访问前,须进行权限申请,将请求所在的业务模块与当前接口进行绑定。API平台只允许目标业务模块下的IP访问目标接口。

场景一:接口开发-无中生有

应用前-出现的问题:

1.开发耦合:项目迭代刚启动,经常会出现后台开发间,前后端开发间接口相互依赖,导致工作相互delay。

2.相互“扯皮”:开发间当面对齐接口,经常出现今天说“一套”,实际输出“一套”。没有接口落地及佐证的地方。

应用后-规范的工作流程,实现了并行开发:

有了API平台,大家的工作流程规范是这样:

1. 接口提供方,注册新接口到API平台;

2. 提供方与接口使用方通过API平台对齐接口,达成两方最终接口;

3. 使用方使用API平台提供的伪接口进行功能开发及联调;(不再阻塞)

4. 接口提供方严格按最终接口参数实现真实接口。

5. 接口提供方将测试接口录入API平台,模式从“伪接口”切换成“测试”,接口使用方可以“无感知”的切换成真实接口服务中去。不需要额外联调。

img

场景二:接口测试-可视化用例+自动测试

“ 写代码的时间都没有。哪来时间写用例。但每次修改代码,人工自测耗费很多时间。” 这种现象其实在开发中很普遍。

有没有一种模式,可以让开发不用写代码就能快速实现接口单元测试用例?甚至让不写代码的测试同学来帮开发实现测试用例?

API平台,提供了可视化用例在线编辑:用户只须录入预设值,即可生成用例。一键执行用例,查看测试结果。

API平台也实现了依赖第三方环境API的接口本地化测试。

关于API平台测试能力这一部分,后面我们再专门单独做介绍。

场景三:质量运营

  • 安全认证

分配apikey: 所有API访问,须在API平台注册,由平台分配唯一的apikey。用户每次请求须带上apikey方可访问;

限制开放源:对于敏感API接口,接口使用方须在API平台登记请求来源业务模块,经审核后,方可访问。

  • 过载保护

每个接口可以自定义访问频率。API平台可以对接口进行限频保护。

  • 接口巡检

API平台可对线上服务接口进行自定义的主动探测与巡检。在用户察觉问题前发现问题与修复问题。

  • 异常告警

若API服务出现异常,API平台会主动通知接口使用方与提供方。

img

  • 异常告警案例

CMDB下发配置(16:30,17:30灰度),未切走流量,导致接口请求小部分异常。

告警短信:

img

查看API日志:

发现:后台spp服务异常

img

跟进原因:

img

  • 调用链路分析
  • 应用场景

应用前-问题场景:

A业务页面提示xx保存失败-->A业务开发卷入排查(重现问题+分析)-->发现是公共B服务异常--> B开发卷入相似分析--> 发现是平台服务C异常--> 卷入C开发相似分析--> 确认是redis服务异常。

这种问题,如果发生在客户环境,会有ABC三个开发同学要:申请登录客户环境(有时很繁琐很费时)--> 排查--> 内部反馈,流转问题单。有时排查分析时间还没有前后协调时间耗费得多。

应用后-链路分析场景:

API平台调用链路分析能力,方便不懂业务的运维同学,一键在线查看整个调用链,直达问题根节点:

1.获取异常请求ID:

前端页面或后台服务出现异常时,定位者可以从页面或日志中获取调用请求的ID,

2.还原问题现场:

根据请求ID,在API平台获取调用链,快速全方位的还原现场数据:链路中每个请求的入参,出参,耗时,返回码,异常日志等。

告别登机子查日志-重试重现问题-大量开发介入-问题修复效率低慢的问题。

img

  • API调用链路分析

API平台根据起始请求,将接口间调用关系生成一棵调用树.我们可以一目了然的看到:

1.请求的调用链路;

2.每一层调用现场:服务调用方,服务提供方,接口返回码,耗时, 入参,出参, 异常日志(若有异常)

利用API平台的调用树能力,我们可以:

1、快速了解服务的调用关系,发现不合理调用;

2、帮助售后快速定位问题;减少开发介入频率;

3、现场复原:不须再重现;避免重现不了问题的定位

4、web可视化分析:减少上机子查日志的次数。提升定位效率。

  • 案例一:发现不合理调用
(1)问题现场

devtest环境,执行工具市场工具异常.

img

(2)获取requestId

获取id, 输入查询

img

img

(3)重现调用树+问题现场

img

img

img

(4)发现原因/问题

结论一(问题原因):命令通道接口-判断设备连通性:发现设备不可通。

img

img

结论二:通过调用链,发现工具市场存在重复调用cmdb接口问题。工具市场下个迭代修复。

img

  • 案例二:CMDB异常

(1)问题现场:执行工具市场时,只提示CMDB异常。但不知道原因。

img

(2)查看API平台调用树:不需求上机子查日志啦。可见原因是DB连接异常。

img

img

场景四:数据画像

API平台有实时日志查询、实时数据画像、性能分析等数据画像能力。这里,针对成功率,耗时做下介绍:

对于运营者来说,我们很关心线上接口的成功率,耗时,这样将直接影响服务质量,用户体验。

  • 横向分析

查看接口成功率分布及趋势 & 查看接口耗时分布及趋势。

平均成功率,平均耗时,会在“平均数据”下掩盖了一些细微的问题。API平台画像,会采用分段模式,下钻一层看问题。

img

img

  • 纵向分析

以“天+接口”纬度查看明细数据:

img

img

  • 性能优化案例

刚接入API平台时,织云自动化服务,共有39个接口有调用记录。其中29个接口(66.7%)不达标(接口耗时超过500ms)。经开发性能后,慢接口大幅减少。

img

img

小结

织云API平台,是结合我们部门“接口开放”,“接口生产”需求、痛点和DevOps理念的一次新探索,新实践。在传统API网关的能力基础上,拓展到更多API周期阶段,实现API的DevOps赋能与管理。

以上是API平台简单的介绍和分享,抛砖引玉,希望大家都能打造好自己的微服务管理与开放平台。共勉!

· 分 · 割 · 线 · 啦 ·

织云企业版预约体验

img

织云社区版 V1.2下载

img

问答
无法从API获取数据?
相关阅读
模型剖析 | 如何解决业务运维的四大难题?
混合云管理问题,你解决了么?
Pick一下,工具上线前运维必备原则
【每日课程推荐】机器学习实战!快速入门在线广告业务及CTR相应知识

此文已由作者授权腾讯云+社区发布,更多原文请点击

搜索关注公众号「云加社区」,第一时间获取技术干货,关注后回复1024 送你一份技术课程大礼包!

海量技术实践经验,尽在云加社区

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值