咱们不生产数据，咱们只是数据的搬运工。
背景
- 现有零碎操作日志都扩散在各个域的零碎中，而且没有造成标准的零碎。导致排查线上问题全是去日志零碎各种搜，效率很低。
- 咱们针对零碎调用链路有trace串联，跨域查问题很爽。然而咱们对单据纬度没有trace串联，单据流转对于咱们来说是黑盒。
- 开发人员对本人的性能线上状况不分明，比方：每天卖家发货量多少？不分明；成功率多少？不分明；均匀响应多少？不分明；针对以后量，咱们是不是须要做一些优化？其实有时候并不是不去关注，只是没有一个很直观的零碎去很直观的出现进去。
- 为了解决上述问题，交易轨迹零碎就应运而生了。
实现思路
怎么去埋数据？
1. 计划一：手动埋点（不举荐）
对现有零碎侵入性较高，而且埋点对系统稳定性有肯定的影响，不到万不得已不举荐。然而咱们提供了这项性能。反对三种接入形式，feign、dubbo和rocketmq。
2. 计划二：日志荡涤（举荐）
怎么对现有零碎不革新，利用现有的资源去寻找事件action？咱们发现access.log能够完满的利用起来。然而有一些超时工作和mq触发的工作没有access.log，现阶段须要思考其余形式接入。后续咱们思考提供公共工具，将mq和超时工作触发的动作，写入access.log并提供全套的荡涤入库套件。
3. 计划三：binlog（不举荐）
为什么不举荐，因为binlog拉取不到入参出参，对排查问题没有太大的作用。然而有一点劣势很显著，咱们能够追踪前后两次的表更。比方：批改地址（A地址->B地址）
怎么去数据荡涤？
1. 性能独立
和业务零碎隔离，独立一套零碎去做数据荡涤
2. 实时失效
利用groovy脚本做荡涤逻辑，脚本写好后保留实时失效。
3. 数据扩大
日志外面的数据不满足埋点需要，咱们提供了dubbo和feign的扩大，能够去业务零碎查问数据
4. 批量操作反对
批量操作会波及到多个单号的流转，脚本默认返回List，对多个单号进行埋点，反对一次解析，多条数据落库
5. 奴才单号反对
（同理批量操作）
6. 日志太简单？解析吃力？
针对日志剖析，咱们提供的公共的数据获取工具，间接调用办法即可
例子（寄售申请）：
package com.shizhuang.duapp.trade.script.biz.deposit.jsimport com.alibaba.fastjson.JSONArrayimport com.alibaba.fastjson.JSONObjectimport com.google.common.collect.Listsimport com.shizhuang.duapp.trade.cycle.api.resultdata.BizResultimport com.shizhuang.duapp.trade.cycle.api.script.AccessLogToBizResultBaseScriptimport com.shizhuang.duapp.trade.cycle.api.sourcedata.AccessLogDataimport com.shizhuang.duapp.trade.cycle.api.util.AccessLogUtils/** * @program: trade-cycle-center * * @author: 小猪佩奇* * @create: 2020-11-20 17:08 * */class ConsignApplyCreate2BizResult extends AccessLogToBizResultBaseScript { List<BizResult> parse(AccessLogData accessLogData) { // 响应后果 String responseData = accessLogData.getResponseData() // 执行工夫 String takeTime = accessLogData.getTakeTime() // http 返回code码 String httpStatus = accessLogData.getHttpStatus() // 获取uid String uid = AccessLogUtils.getUid(accessLogData) List<String> applyNoList = this.analyzeApplyItemNo(responseData); List<BizResult> bizResultList = Lists.newArrayList(); for (applyItemNo in applyNoList) { BizResult result = new BizResult() result.setOperatorId(uid) result.setOperationBizNo(applyItemNo) result.setOperationTime(accessLogData.getOperationTime()) result.setOperationSubType("app寄售申请") result.setOperationTrace(accessLogData.getOperationTrace()) result.setOperationCostTime(Long.valueOf(takeTime)) result.setOperationResult("200" == httpStatus ? 0 : 1) //result.setOperationExtend() result.setOperationDetailReq(accessLogData.getPayload()) result.setOperationDetailResp(accessLogData.getResponseData()) bizResultList.add(result); } return bizResultList; } /** * 剖析单号 * @param responseData * @return */ List<String> analyzeApplyItemNo(String responseData) { List<String> list = Lists.newArrayList() JSONObject jsonObject = JSONObject.parseObject(responseData) JSONObject data = jsonObject.getJSONObject("data") JSONObject applyProduct = data.getJSONObject("applyProduct") if (Objects.isNull(applyProduct)) { return list } JSONArray applyItems = applyProduct.getJSONArray("applyItems") if (Objects.nonNull(applyItems)) { for (Object applyItem : applyItems) { JSONObject parseObject = JSONObject.parseObject(applyItem.toString()) String applyItemNo = parseObject.getString("applyItemNo"); list.add(applyItemNo); } } return list }}怎么去做数据出现？
1. 单据纬度
存放单交易轨迹
客服工单轨迹
查问时段段内，单据的流转轨迹（反对跨域跨零碎展现）。依据起源数据和后果数据，排查问题本源。如需查看具体日志，能够依据traceId去日志零碎去查看具体trace日志。
2. 人纬度
统计时间段内用户的操作行为，不便排查某个时间段内用户的操作。
怎么自定义图形化？
TDengine时序数据库存储的存储的数据都是带有工夫戳的，且自身很好地反对工夫维度的聚合，正好能够联合grafana对操作日志中的数据进行剖析，展现各类业务运行的状况。
零碎接入
access log形式接入
- 下载脚本我的项目，编写脚本代码
- 新增事件脚本类，将脚本代码配置到交易轨迹零碎
- 增加路由规定，关联事件和脚本
rocketMq形式接入
mq接入形式和rpc形式雷同，各业务零碎把数据封装好，通过硬编码的形式将数据发送到mq，轨迹零碎订阅音讯进行数据荡涤并长久化。有时候获取事件不是很不便，通过mq的形式接入也未尝不是一种好的形式。
扩大
- 在存储上咱们反对跨度一年的轨迹查问，在存储上曾经做过优化，接入方能够不思考存储问题。
- 在和财务零碎、客服零碎的对接中。咱们发现还有更多的方向去扩大性能，不仅仅是局限于交易轨迹。
- 财务零碎须要记录和第三方交互的申请报文，排查问题的时候间接通过单号疾速查问第三方报文。
- 客服零碎须要记录客服会话的生命周期，通过会话id能够直观的查看会话链路。并且能够通过客服id能够疾速统计客服的接入量统计。
- 后续会增强图形化的性能和繁难数据分析的能力
- 实践上咱们只提供了一种存储能力，标准了数据存储的格局。具体怎么应用，应用方能够自定义。
- 最初打个广告，欢送大家接入。
文/得物技术 Ambition