基于资产配置业务场景下的全链路监控平台

每年夏秋交错之时总会非常的忙碌，也许是因为久违的那一丝丝凉意秋风，也许是……今年的年度规划来的稍早了一些……

和往年一样，在这个季节里，也是各大盛会聚集的时刻，就在刚刚过去的 CNUTCon 中，亲身感受了圈内运维伙伴们的热情洋溢，除此之外，我也在互金专场中为大家分享下好买财富在全链路监控上的那些事

未来已来

无论是《终结者系列》中那些震撼的场景，还是 AlphaGo 击败人类的那一刻画面，相信没有人会怀疑人类已进入了智能时代

那么，智能化资产配置是啥意思？

利用 AI 技术，将投资金额分散在不同理财中，从而最终达到预期收益的方式

好买已在今年发布了 基于智能投顾业务场景的机器人：

• 测试风险偏好

• 选择资产配置（定制化）

• 买入与卖出再平衡

• 波动平衡

• 观点平衡

• 拉杆平衡

既然未来已来，咱们运维，该如何面对？

我们为什么需要全链路监控？

从去年开始，为了应对互联网特性的与日俱增，我们将策略调整为「快速交付」与「快速排障」，并针对其开展全维度的执行

某某大神说过： “梦想总是伟大的，现实总是残酷的”

先来说说「快速交付」：

老板：怎么才能快？

运维：松耦合

老板：怎么才能把现在的系统变为松耦合？

运维：拆！拆！拆！

老板：最终，耦合是越来越松了，系统数量却越来越多了，当然链路也就随之加长了，怎么办？

运维：………………老板，你好懂

甚至最后变成……

某某大神又说过： “不能给业务带来价值的技术都是耍流氓，快了，老出问题有毛用”

再来说说「快速排障」：

随着系统越来越多，链路越来越长，当故障出现的时候，那么多系统，谁有能力一眼看出究竟是哪个系统在捣鬼？

靠人品？还是拼技术？

这套全链路监控的实现原理是什么？

和大多数公司一样，所谓的全链路监控，无非就是「基于网络调用日志的分布式跟踪系统」罢了

在与其他公司交流中，发现大多数公司都采用 ELK 来进行日志收集与分析，由于 “历史性” 原因，我们选择自研收集器与分析引擎，整体架构可分为「五个层次+四个模块」：

日志结构与如何埋点：

UUID 含义是通用唯一识别码 (Universally Unique Identifier)，整个链路的 TraceId 都是围绕 UUID 展开的

来一张 Log Sample：

这套全链路监控的长啥样？

下面是系统的部分截图与注释说明：

展望未来，还有很长的路要走……

从年初的第一个版本上线至今，无论在「快速交付」或在「快速排障」中，都极大地提升了效率

无论从金融的视角，还是从互联网的视角，大部分系统的发展都是从一个坑跳到另外一个坑，然后再把原来的坑填满，填着填着，架构就这样奇妙的产生了

在第二个版本研发过程中，会对以上四点进行增能：

血缘分析：从错误点推导全链路，并分析出导致本错误点的原因

调用还原：增加快照功能，支持上一节点的调用回放功能

容量评估：暂定位日志存储容量的评估（本功能未考虑清晰）

原因定位：目前只能定位到某个接口失败或错误，并将错误与异常的信息打印出来，本功能将支持失败归因，后期将考虑自动修复

全自研的 PaaS 运维平台

其实，实现这些功能也好，迈向 FT 也罢，所谓平台化，是一种体系，也是一种目标，好买在 DevOps 的路程中只能称得上刚刚起步，但是梦想必须要远大，万一成功了？那不是挺好玩吗？

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/6z0i-nFUnJe8fKWK8NAstA