搞懂数字货币打卡签连接图，运维排查不再抓瞎
做数字货币项目这几年，打卡签到功能看着简单，真出问题时才发现背后的连接图比想象中复杂得多。一张画得清楚的打卡签连接图，能让你在凌晨三点收到报警时，三秒钟定位到是哪个环节断了，而不是满世界抓瞎。
整套签到系统的节点其实就四五个：用户端App或Web页面、API网关、签到服务微服务、Redis缓存层、主数据库。连接图要画清楚的是它们之间的调用关系和端口，比如网关到签到服务走的是gRPC，签到服务写Redis用的是6379端口，落库走的是MySQL 3306。少了任何一个标注，排查时就会在"到底走的哪条路"上浪费二十分钟。
一次打卡的数据流是这样的：用户点签到，请求打到网关做鉴权和限流，网关把有效请求转给签到服务，服务先查Redis看这个钱包地址今天有没有签过，没签过就生成签到记录写入MySQL，同时更新连签天数。这条链路上任何一环超时都会导致前端转圈，而大多数"打卡失败"的工单，问题就卡在Redis和MySQL之间的连接池打满。
实际维护中我发现连接图最容易画错的地方是异步回调那条线。签到成功后要推奖励到用户的资金账户搞懂数字货币打卡签连接图，运维排查不再抓瞎，这步走的是消息队列，不是同步调用。很多新人画连接图时会把这条线画成直连，结果一做压测就把资金服务打挂了。
我现在的习惯是把连接图做成活的，每次改完架构就更新一版数字货币打卡签连接图，标上当前用的协议版本和超时参数。上次流量峰值，就靠这张图五分钟找到了是网关到Redis的keepalive超时设得太短，改个配置就恢复了。
