消失好久了。

消失的这段时间，自我感觉成长颇丰。

由当初懵懂的校招生，到现在的开平虚拟号技术 owner 以及重点项目 core committer。

感谢 mt 的指导和 ld 的栽培，去年也拿下了团队的高绩效，同时也是我的分布式存储梦破碎的一年。

虚拟号方面，主要是扩量计划和降明文率。技术上做了多轮优化以承接每日亿级的数据增量，ES通话数据的膨胀也推动我使用 分库分表 + Hbase 的方案。业务上与多方团队比如履约、物流、风控等多个团队合作以降低各个地方透出明文的概率。比较恶心的是短信业务，数据量大且单表存储，起初因为产品各种花里胡哨的配置而没有使用延时队列的方案，并且考虑丢消息的风险以及重试方案不够灵活，导致线上包括慢查询、DB压力高等在内的各种问题，最终我使用 任务分片 + 游标式推进id + 状态机 + 批处理 的方案较好解决了各种问题。

在 HTAP 不够流行的团队，数据分片和按时归档是最好的解药。MySQL shard、ElasticSearch route、Hbase rowkey 三板斧，承接当前的互联网流量绝对是没问题的。B端可以用 mallId 分片，C端可以用 userId 分片，但是 A端 就比较头痛了，往往查询条件复杂，而且无法分片，每次查询都要到多个节点上进行读扩散，考虑到业务流量较低以及成本问题，一般就只能限制数据保存时间了。

重点项目，因为保密暂不透露业务信息，我主要参与 商品池、搜推业务 和 交易链路 的开发，该说不说开发比写 Hive SQL 舒服。商品池有个增量 GMV 测算的需求，让我花了两周刷了几亿的商品标，吐血ing。

因为虚拟号链路长且代码深的痛点，年末做了服务重构的方案，主要按照中台功能单一职责拆分的原则，拆分出了六个板块：决策引擎、绑定引擎、报备引擎、查询引擎、短信引擎、通话引擎，每个引擎的侧重点不同，比如决策引擎注重的是各种策略的扩展性和最终决策，绑定引擎管理虚拟号的生命周期，查询引擎关注接口性能和吞吐量，报备引擎作为明文透出申请入口辅助B端市场，短信引擎作为离线服务侧重消费者体验，通话引擎需要和较多算法接口对接。介于当下分身乏力，重构完成&上线是遥遥无期了。

基础架构型业务，或者叫作业务中台，从一开始船帆就不该迷失方向，掌舵者应绝对强有力，知道什么该做什么不该做，否则耦合了业务方的其他诉求，后续将变得极难维护，很多乱七芭蕉需求最终也会牵扯到我们头上。

极少做梦，但昨晚梦到她了。

在疫情期间封闭的欢乐港湾的摩天轮旁，在文和友步行街的各色小吃烟火里，在前海公园席地而坐的草坪上，在盐田海滨栈道的落日余晖下，面对纯粹的她，我皆按捺冲动，深藏情愫。

昔日计划过的告白，被我置于稳定且可控的未来。

挺想她的，ke，一定会再见的！