腾讯织云API平台：结合DevOps理念的一次新实践

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

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

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

1. API的开放与复用

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

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

• 找不到平台开放接口文档；

• 从平台官网下载的接口文档好像未更新；

• 接口文档定义太简单。看不懂；

• 使用前，不清楚接口的质量现状（成功率，耗时等）；

• 出异常时，没法快速界定问题的边界。

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

• 接入方很多，长久下来，自己都不清楚调用方是哪些？

• 最近我的接口调用量大增，不清楚这些调用是否合理？

• 旧接口要下线，但仍有请求。不方便快速找到调用者。

2. 产品线API的那些事儿

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

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

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

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

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

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

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

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

API平台简介

• 定义

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

• 应用场景

• 功能介绍

1、织云API平台，实现了API统一规范管理与开放。

2、以服务代理为基础，实现了安全认证，过载保护。

3、对于服务调用支持日志查询，数据画像，异常告警，链路分析等功能。

4、可以基于API平台实现基于织云所有能力的定制开发的能力。

接口规范与接入成本

• 接口规范

屏蔽接口URI层级差异：

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

屏蔽接口响应结构差异：

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

全局业务错误码：

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

• 接入成本--零改造

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

注册API服务示例

• 现成的API接口

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

url: http://capacity/load/sustained-load

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中对应的服务名。

• 注册接口 - 基础信息

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

自动生成入出参：

在入参，出参示例部分，只须贴入：

入参：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结构等解析）

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

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

接口开放

• 查看开放API接口

列表页：

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

明细面：

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

自动生成接口文档

• 访问权限申请

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

全开放：

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

须审核：

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

场景一：接口开发－无中生有

应用前－出现的问题：

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

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

应用后－规范的工作流程，实现了并行开发：

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

1. 接口提供方，注册新接口到API平台；

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

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

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

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

场景二：接口测试－可视化用例+自动测试

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

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

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

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

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

场景三：质量运营

• 安全认证

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

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

• 过载保护

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

• 接口巡检

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

• 异常告警

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

• 异常告警案例

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

告警短信：

查看API日志：

发现：后台spp服务异常

跟进原因：

调用链路分析

应用场景

应用前－问题场景：

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

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

应用后－链路分析场景：

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

1.获取异常请求ID：

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

2.还原问题现场：

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

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

• API调用链路分析

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

1. 请求的调用链路;

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

利用API平台的调用树能力，我们可以：

1. 快速了解服务的调用关系，发现不合理调用；

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

3. 现场复原：不须再重现；避免重现不了问题的定位

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

• 案例一：发现不合理调用

(1) 问题现场

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

(2) 获取requestId

获取id, 输入查询

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

(4) 发现原因/问题

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

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

• 案例二：CMDB异常

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

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

场景四：数据画像

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

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

• 横向分析

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

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

• 纵向分析

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

• 性能优化案例

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

小结

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

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

作者介绍

黄伟俊：腾讯高级运维工程师，多年研发、运维工作经验。曾负责空间相册、优图等SNG社交平台类业务的运维规划与管理。现负责腾讯织云平台侧公共能力建设。

欢迎大家关注腾讯织云微信公众号（TencentCOC），第一时间获取更多运维技术实践干货哦~