tapd数据本地化管理
背景
存在问题
解决思路
方案
带来的问题
解决
总结
背景
在转转的产品研发体系中，tapd用来管理需求，bug，任务的流程和生命周期。在devops流中，多项操作都需要和tapd打交道，如：拉起分支-关联需求，部署测试和部署线上后改变需求的状态。这些操作都需要通过tapd提供的api进行通信。
可以说tapd和转转的整个研发管理流程是紧密贴合的。tapd服务的波动都会给转转的devops流程带来一定的影响。在日常的使用中，我们发现如下问题。
存在问题
便捷问题：跨公司的http数据调用，响应相对慢，但是可以满足日常需要，但很难进行有效的数据分析。 安全问题：多个业务方都在读写TAPD的数据，导致用户名密码在多个系统中被应用，存在一定的泄露风险。 可用性问题：多个业务方都在读写TAPD的数据，部分业务异常过多调用，会导致tapd整体限流，排查困难，影响一些关键业务。
解决思路
对于多业务线访问tapd带来的一系列问题我们主要通过增加代理转发tapd接口的方式，统一通过我们服务对tapd进行访问，如下图所示：
我们能否将数据存储到本地？查询的操作直接查询本地库，能更方便的查询tapd的数据，用于统计tapd相关的数据也会更便捷，还能减少对tapd的接口的调用，
那么，多业务线查询TAPD数据时除上图的方式外还可通过我们自己的库表得到，如下图所示：
方案
利用TAPD提供的变更通知的能力，通过webhook可以订阅需求，bug、task等变更消息。将tapd的数据存储到本地。
这样一来，访问远程变成了本地的接口访问，访问更快，更少，提升系统性能和响应速度。
需求、任务、BUG以及对应变更数据入库，流程图如下:
tapd通过webhook通知到我们服务。 服务发送MQ，服务tapd_data_api监听发送过来的消息。 根据消息的eventType分别对需求、bug、任务信息以及对应变更信息进行入库。
带来的问题
新的场景下如何做限流？ 如何保证数据的一致性？如何感知数据同步异常？ 对于不能通过webhook感知变化的数如何处理？
解决
若tapd出现限流，会在触发限流后的接下来的5分钟内拒绝所有流量。为了保证tapd服务可用，需要在限流之前主动拒绝一部分流量，使得我们对Tapd的请求保持在可控范围内。为此我们开发了一个限流器，对易造成限流的tapd接口进行限流，限流器如下如所示：
例如需要对需求变更历史的查询进行限流一秒最多请求3次，具体用法如下：
创建一个注解Ratelimiter，用于标识需要限流的方法，参数分别为key（需要限流模块标识）、limit（单位时间限制通过请求数）、expireTime（过期时间） 哪个接口需要限流，就在对应的调用方法上添加@Ratelimiter，然后配置相关参数即可
2.多业务线请求tapd原生接口时，将使用限流器进行请求流量控制，如下图所示：
3.由于TAPD变更历史接口的限流阈值为10条每秒，在入库时查询TAPD过程中很容易触发限流，对此，具体处理如下：
由于变更历史会比较频繁，将变更的tapd信息存储到Redis队列中 异步执行队列，添加变更记录到数据库 引入且限流器RateLimiter对变更历史接口的查询进行限流处理 若触发限流我们会将数据入队,然后由消费线程进行排队消费，直到限流解除
4.数据更新异常我们将会通过企业微信发送消息告警，说明消息入库异常 了，当收到消息提醒后，我们会对该时段的数据通过进行补偿，以保证数据的一致性。
5.对于非webhook能够发送的数据我们将通过每天晚上，采用用定时任务的方式进行同步，例如，TAPD项目信息、TAPD各项目需求工作流状态中英文名对应信息、用户项目关系等数据。
总结
通过代理和数据本地化的策略，提高了接口性能、彻底解决接口限流排查困难和稳定性问题。
在多业务混用的情况下，有效的保证了主要服务的数据稳定性，也为后续度量建立提供了数据基础。
关于作者
周海霞，转转工程效率组内成员，主要负责公司内部devops平台的相关开发及维护。
想了解更多转转公司的业务实践，点击关注下方的公众号吧！