2023年2月 晋升答辩(2b-3a)
专业职级晋升评审
答辩人：谢世杰
部门：研发管理办公室/交付工具组
日期：2023-3
个人简介
2020年11月-2021年12月，校招实习生
2021年12月-至今，正式职员
独立负责：
- API管理平台，自动解析接口的接口管理平台
- Sentry平台，开源的日志上报监控平台
- UPM平台，为KDEV、测试服务化等做权限管理的平台
新参与：代码扫描平台
主要工作及成果
一、API管理平台
现状一：
研发手工编写接口，存在接口编写的误差，导致前后端在联调阶段频繁重新定义接口，耗时耗力，严重时后端研发修改接口定义之后没有及时通知前端从而导致线上事故。快手内部缺少一个这样的平台，它至少具备
- 用户低成本接入，能够自动生成接口文档。
- 能够及时让相关接口人感知接口变化
我们调研了内部的接口平台：openapi、kapi、api-center，均没有自动生成接口的能力和接口变化的感知能力。
打法思路
（1）从0到1构建API管理平台，建成的API管理提供了以下的能力：
● 打通git和pipeline
● 获取编译产物并自动解析接口
● 进行接口diff产出报告并Kim通知
● 自动化构建mock和测试数据
● 用户0成本接入
（2）建成之后流程如下
后端研发同学完成编码，push代码到gitlab并执行流水线，API管理的解析服务会收到通知并拉起编译产物进行接口元信息解析，解析完成并自动生成接口文档之后，一方面，会把信息同步到API管理界面提供MOCK、case用户、交互等基本能力。另一方面会跟之前版本的接口进行diff，如果存在diff会通过kim发送diff报告到制定的前端接口人，那前端研发同学就会修改制定的代码。
建立起以自动解析接口文档为核心的接口管理平台
现状二：
在从0到1建成API管理平台之后，目前还存在：
（1）后端研发同学定义部署RPC接口，前端研发同学定义并请求HTTP接口，导致前后端研发同学整体开发联通流程割裂。
（2）KDEV、KEEP、KFC三端联调没有统一的平台去规范定义和度量【联调】阶段。
打法思路
（1）从1到多推广API管理平台，提供多端联通解决方案，具体建设如下：
● 第一步：将apicenter的rpc接口同步到api管理平台之上，让前端可以复用api管理的mock、测试、代理能力
● 第二步：将平台的接口与teamid建立关联，使三端研发流平台能够通过teamid关联自动解析的接口
● 第三步：建立接口状态变更触发team状态翻转的能力，使三端能够通过接口来标记联调阶段并度量联调时长
最终结果：建立起以API管理为核心的联调体系
（2）建成之后流程如下
首先，将API-Center的RPC接口同步到API管理平台并将其改造为HTTP接口方便前段研发同学开发测试联调，然后建立teamId与API管理http接口的关联关系。至此将API管理、API-center平台与kdev、kfc、keep三端等平台打通。前后端研发同学隔离的联通流程得以打通，可以关联接口并改变接口状态从而翻转接口关联的team状态，复用API管理的基础能力。规范了联调流程并度量联通时长。
现状三：
KAT、流量录制等平台以及主站、用户增长等业务线依赖RPC解析的接口数据做打标度量和接口覆盖率统计等能力，但是RPC解析成功率低(29%)，无法为业务方提供准确全面的RPC接口。
打法思路
重构API管理的RPC解析服务
第1步、分析当前rpc解析qdox框架，发现如下问题
● 已不再维护，部分解析方式会异常
● 只解析java文件，若打包配置只有class则无法解析
第2步、将qdox解析框架改为动态反射，复用spring的LuanchedURLclassloader，带来如下问题
- 文件句柄泄露
- 频繁oom
第3步、使用MAT分析dump文件
通过分析oom产生的dump文件发现JarFile引用被大量持有导致内存耗尽和文件句柄泄漏
第4步、查看源码分析jarFile引用被持有的原因
JarFile都被spring的classloader所引用，加载器会在spring的生命周期中一直存在，清理底层是实现了Object.finalize() 方法，finalize()方法并不会立刻清除，而是先加入F-Queue中，然后由一个低优先级的Finalizer线程去清理F-Queue队列，在高并发场景队列一直堆积最终造成内存耗尽。
第5步、重写classloader，功能如下
● 加载rpc的spring boot和spring mvc两种类型的jar
● 快速清理过期jar
● 自动准确索引runner依赖的sdk
第6步、建立服务监控、日志、降级等体系
● sentry：监控平台
● grafana：数据大盘
● redis：流量控制、全局参数缓存、幂等性
● kconf：全局开关、快速降级
● 天问日志：日志平台，快速定位问题
解析成功率从29%提升至99%
项目成果
- 从0到1搭建API管理平台，并主R其开发、运维和升级
- 平台与git和pipeline打通，用户0成本接入解析流程并自动生成接口文档
- 自动解析接口1500w+，人工接口4w+，git仓库模块3700+，服务电商、商业化、主站、基础技术、支付、效率工程等多个部门
- rpc解析能力升级优化，解析成功率从29%提升到99%
- 多端接口文档统一管理，规范联调流程，度量联调时长
- 建设接口优先级和服务等级的一致性校验等能力，为主站、电商、商业化等业务方提供全量接口统计和度量
二、Sentry平台
背景和现状
Sentry是一个实时日志监控、记录和聚合平台。
- 现状一：单点问题。 pgsql和rabbitMq都是单物理机部署，一旦实例挂掉，整体服务将不可用
- 现状二：前端上报不稳定。依赖sdk下载稳定性差，sourceMap上传不稳定
- 现状三：通知手段单一。仅支持Kim通知，未与oncall报警平台打通
- 现状四：海外环境不支持sentry。
打法思路
打法一：通过增加冷备解决数据单点问题
为pgsql和rabbitMQ搭建冷备，后台线程同步数据，并写了探活脚本，当发生故障时，切换数据库源，即可正常使用。
打法二：同步kcdn和迁移ceph，解决前端上报不稳定
前端上传组件从官网下载迁移到内部kcdn下载，并优化其下载逻辑，sourceMap上传的方式从ceph在线集群迁移为离线集群
打法三：与oncall报警平台打通，解决报警单一
独立开发了一个sentry的插件并集成到sentry平台上，接受报警信息并给kafka发送消息，开发consumer去消费kafka消息，处理并聚合消息然后发送到oncall报警平台，完全兼容sentry的报警过滤参数和规则，用户只需勾选插件即可接口，成本低
项目成果
- 接手公司级监控项目sentry平台，并独立负责其开发、运维和升级
- 前端上报优化，组件下载优化，ceph数据迁移，稳定性提升至99.95%
- 交接sentry时，平台用户3100+， 项目数2000+，日均异常上报5000w+
- 迁移pgsql和rabbitMQ中间件并增加冷备，提升物理机的管控和维护能力，解决数据单点问题
- 打通sentry与oncall报警平台，促进报警的整合；通过复用oncall平台的统计和回执能力，提升问题的接手率，提高问题定位效率。
- 参与海外sentry的部署搭建，为海外业务方提供sentry报警能力
思考规划
能力建设完成之后，我开始思考平台在为前后端提供接口文档定义以及联调还能做什么？
思考如下：
黄色部分是新增功能
基础能力建设
● 代码生成服务并自动提交MR：通过接口元信息自动生成ts接口定义，解决前端工程师的痛点
● python等语言自动解析：支持更多语言的接口自动生成
● 接口覆盖率：统计全公司的接口数据，查看各个业务线接口的覆盖率
合作共建
● 健康度检查：与代码扫描深度合作，静态扫描+动态解析，支持更加细粒度的健康度检查
● staging发布：配合流水线，作为staging部署的一个入口，方便前后端测试验证
● 提测卡点：对比接口diff，如果存在接口diff则无法进行体测的准入和准出
● 自动测试：跟测试服务化和kat平台合作，复用已有的接口出入参定义，升级测试case，生产接口测试报告
成长总结
知识宽度：
加入快手以来，负责的项目让我见识到更多方向，拓宽了自己的知识面。在遇到问题时，能够使用不同的工具和方式方法相对独立的去解决问题。
业务沟通能力：
独立负责oncall时期，积极的沟通协商去解决问题，能够更快速的理解和更明晰的沟通，减少沟通成本，提升工作效率 。
owner意识：
项目切换时能够快速进入状态，独立承担sentry和API管理相关工作。意识驱动行为，通过自驱的方式去承担项目职责并与各方业务线进行沟通。
工具/方法论的突破：
更熟悉使用ER图、UML类图、流程图等领域模型的设计。 有意识建立监控体系和日志体系去预防和发现问题。降级策略，重要服务要有一键降级的能力。代码更具“设计感”