共计 4559 个字符，预计需要花费 12 分钟才能阅读完成。
欢迎大家前往腾讯云 + 社区，获取更多腾讯海量技术实践干货哦~
本文由织云平台团队发表于云 + 社区专栏
背景
当下，业界越来越多公司在项目架构设计时，会采用微服务架构。微服务架构，可以让我们的产品有更好的扩展性，更好的伸缩性；但同时也会带来微服务的一系列问题，比如微服务接口怎样规范管理？怎样在多团队协作中开放与复用？等等。
同时，业界也在逐渐的引入 DevOps 理念，来实现开发，测试，运维，运营更紧密的高效配合，提升产品迭代的效率，质量。
这里，织云 API 平台将从“部门内微服务 API 开放复用”，“产品线 API DevOps 实践”来分享腾讯社交网络运营部踩过的坑和 API 平台在“开放”，“DevOps”的理解及实践。
1API 开放与复用
部门长期运营，积累了很多优秀的系统 / 平台，各个系统 / 平台也很早的开放了自己的 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/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 中对应的服务名。
注册接口 – 基础信息
注册接口 – 定义请求示例
自动生成入出参：
在入参，出参示例部分，只须贴入：
入参：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 平台简单的介绍和分享，抛砖引玉，希望大家都能打造好自己的微服务管理与开放平台。共勉！
· 分 · 割 · 线 · 啦 ·
织云企业版预约体验
织云社区版 V1.2 下载
问答无法从 API 获取数据？相关阅读模型剖析 | 如何解决业务运维的四大难题？混合云管理问题，你解决了么？Pick 一下，工具上线前运维必备原则【每日课程推荐】机器学习实战！快速入门在线广告业务及 CTR 相应知识
