前言: 本文介绍了饿了么交付中心由 Python 语言栈转换到 Java 语言栈大致过程,一来是对前段时间的工作做下总结,另外也是想通过此次总结为其他应用服务转型提供些借鉴。写的不好,欢迎板砖。
背景
准备
系统价值
内核分析
订单对接运力线模块 商户订单信息模块 部分金额计算模块
参与交付过程的主要角色有四个: 商户 订单 履约运力线 用户 交付提供的主要支撑能力有: 乎单交付能力 运单状态同步能力 运单信息透出能力 履约方式切换能力 运单状态广播触达下游能力等。 部分运单取消或异常管理。
设计
系统设计
系统架构
Api:处于业务框架中上游系统接入层,对外暴漏契约屏蔽细节,对内定义系统能力。 starter:启动项目 service:rpc服务暴漏 domain:核心业务能力实现,聚合层 infra:基础数据支撑能力层 extension:履约能力扩展层 tester:单元测试包
嗯,代码撸完了测完了,从调研到开发完成历时两个半月,代码仓库总行数约 4.7w 行,提交 1000 次左右,完成 63 个接口 +16 个消息消费入口转型迁移,共计测出 117+bug ,期间有喜有忧,奋战两点多是常态。职业生涯中浓重的一笔。此时尤记起与 超哥@邹超周 末代理联调于北 14 楼小黑屋之畔,和 明龙@张明龙 并肩作战对接服务接口,还有 晓波@俞晓波 凌晨一同压测观察总结问题第二天分析反馈提升优化,当然还有 杰哥@汤良杰 的用例设计全面不失细节、对 bug 常常究其根本,对代码 review 逻辑核对一丝不苟明察秋毫。凡此种种,历历在目。一起走来,真心感谢。 ------ 不由自主的感概
平稳过渡
上表格是业界服务高可用的几个级别的衡量标准,例如:服务可用性是 3 个 9 时,全年宕机时长约为 8.76 天的统计概率。另外,我们需要明确的是不同的系统,不同的场景以及不同的用户规模对系统可用性要求是不一样的。如:某些业务的支付链路场景可能 tps 不是很高,但是作为交易的核型链路必须得保证高级别的可用性。
you cant measure it,you cant fix it and improve it.
MTBF:Mean Time Between Failures,系统服务平均故障时间间隔。 MTTR:Mean Time To Recover,系统服务平均故障恢复时间时长。
快速响应,降低恢复时长
针对灰度梯度合理制定,根据业务特征,开始阶段我们选择了较冷门城市(订单量较低)进行了各个运力标品业务的逻辑验证。标品验证完后说明我们新迁移实现的逻辑和原系统具有一致性。随后我们拉取了当前订单城市分布,根据城市订单分布占比制定灰度梯度,由小到大逐步增加。 针对回切需要响应高效,我们应该有一个总的开关可以控制流量,回切应该是一键控制的。 针对排障快速定位,灰度单生命周期内的操作能在单应用内自闭合,不至于排障时还需要确认灰度单某个状态到底走的原系统服务还是新系统服务。另外我们还希望,写操作灰度和查询灰度能单独隔离开,等写数据完全一致的情况下我们再开启新数据新接口查的灰度,将风险控制到最低。
第一阶段 灰度写阶段,灰度策略:餐厅维度,城市维度小范围灰度,读流量以老服务为准,问题出现及时切掉灰度写流量,逻辑回滚至老服务。
第二阶段 灰度查询阶段,灰度标记流量以新服务为准,非灰度标记以老服务透出为准,灰度策略:各个查询接口按照百分比逐步增加灰度占比。
第三阶段 迁移阶段,完成读写灰度,原系统老服务只是代理的一层皮,接下来就是上游系统迁移到新服务,去掉对原原系统服务的依赖,迁移完成。
最大努力降低故障风险
1.发布控制
2.风险巡检
系统逻辑核对,多人多次code review。 变更发布前主干场景自动化用例全通过。 周期性压测。
3.多层次持续监控
部署机器,缓存集群,消息队列,数据库表等基础资源的基准监控。 业务曲线成功率,日同比,周同比,曲线波动比,及主要接口入口流量到下游出口流量转换率监控,业务系统成熟后还应对各个服务响应时间指标做监控等。 系统中很多情况下重试都是以异常中断为依据,这必然会对系统异常点带来较大的噪音。为此我们还需要细化各个中断异常的打点,排除不必要的干扰。
一致性问题
灰度数据需要双写新老交付系统库表,如何保证双侧底层数据的一致性? 底层数据一致不等于对外服务接口数据透出一致,双侧服务应用层面怎么保证数据的一致性? 订单阿波罗履约线和交付的上下游数据数据最终一致性怎么保证怎么验证?
针对底层数据比对:
比对应是准实时的,如只比对30分钟前的数据。 比对数据是基于时间可分段采样的,如只比对10分钟以内产生的数据。 为了方便控制,根据情况以上策略又可以是及时调节的。即准实时偏移量可调节,分段采样窗口大小可调节。
针对应用层数据比对:
代理层接收请求后,比对应是异步的,不影响接口响应耗时。 比对粒度要小,应细化到接口。 识别灰度数据,只做有效比对。
针对上下游数据最终一致性:
全量数据核对 主干链路最终一致性核对
未来
转型过程中为了在易测,可核对同时与python的“魔法”姿势斗争中找平衡,部分逻辑是"纯翻译"的,后期维护过程很痛苦,所以我们需要几次不小的重构来达到代码层面的和谐。 不断监控降噪,持续细化监控粒度,监控是服务稳定基石。 交付中心数据大盘建设,从数据层面量化观测我们的交付质量。数据驱动,数字运营从数据化思维优化我们的流程,提高我们的服务。
方法论沉淀
凡此以上,服务系统转型迁移归结于开发者理解与认知,项目的稳定实施归结于开发者套路方法运用。可以简单进一步提炼为以下方法论:
详细调研,客观问题及满足业务的系统是复杂的,详细调研做好准备是必须的。 持续监控,感知系统的质量是服务质量度量的第一步,不断持续的监控才能走的更稳。 稳步过渡,互联网系统服务高可用稳定不容商量。 问题发现根因解决,小的问题可能隐藏大的bug,认真对待究其根本,复盘->总结->提升。 归纳总结业务再认知。
对于每一位工程师,开发高并发大流量系统是挑战也是机遇。时刻保持进取学习心态,增强自身软素质。 分布式情况下,承认系统并非绝对100%可靠,每一个环节都要考虑“失败”了怎么办,不同的场景我们需要在AP和CP之间作出抉择。如双链路调用保证可靠,异步重试保证顺序最终一致等。 出了问题快速恢复是个永恒的话题,没有“怎么样“最快只有”这样”更快。精准定位立即恢复,如何将这个过程耗时降到更低值得深入思考。