聊聊知乎订单体系搬迁

搬迁布景

别的一个要素是 Python 的 GIL 锁导致它无法发挥多核的优势，性能上遭到很大约束，在实际状况中遇到过屡次主线程被 hang 住导致的可用性毛病，所以坚决决计来搬迁掉旧体系。

前期预备

工欲善其事，必先利其器。

言语栈转型首要要明晰转型的三个开发流程，即 MRO (Migration, Reconstruction, Optimization)

搬迁便是把原言语代码照着抄一遍到新言语项目上，依照新言语的工程完结风格来做就能够。其间最忌掺杂代码优化和 bug 修正，会简单引起新的问题，添加验证代码的难度。
重构意图是进步项目代码的可保护性和可迭代性，让代码更高雅和易读懂，能够放到搬迁完结来做。
优化经过在模块依靠、调用联系、接口字段等方面的调整来下降项意图复杂性，进步合理性。

关于言语栈转型来说，搬迁流程是必定要做的，重构和优化怎样挑选，能够按模块区分功用拆成子使命来别离评价方案，参阅依据为现有模块假如一起优化或重构带来的直接纳益和直接纳益有多少。

收益：完结新旧言语栈的转化，体系保护性更好，模块鸿沟更明晰。
本钱：需求投入的人力本钱，搬迁进程中的并行开发本钱，使有更高价值的作业被堵塞的丢掉。
危险：引进新的 bug，添加测验的复杂性。

在危险可控的前提下，本钱与收益要相互权衡，一般会有两种方案可供参阅：第一种是确定需求，堆人力开发上线，一步到位；第二种则是小步快走，迭代上线，分批交给。

依据以上剖析，在本次转型进程中，人力本钱是一个更重要的要素，所以选用只搬迁的方案，来紧缩人力本钱，下降 bug 引进危险的一起也具有很好的可测验性。并且为了不堵塞事务需求，选用小步快走的方法分批交给，以最长两周作为一个迭代周期进行交给。

搬迁方案

在产品概况页阅览
生成订单进入收银台和用户付出
承认付出后订单交给
用户回到概况页消费内容
特定产品的七天无理由退款

其时订单体系支撑的功用还不多，事务模型和订单模型没有满足地笼统，收拾订单体系事务如下：

完结了订单模块的拆分后，新老体系怎样无缝切换？怎样做到事务无感？怎样确保买卖体系稳定性？出现毛病怎样及时止损？依据上面叙述的准则，将整个体系的搬迁区分红两个阶段，搬迁前后的数据存储和模型都不变。

接口验证

不管是在搬迁的哪个阶段，总需求调整订单接口，能够从订单操作视点分为读操作和写操作，需求针对读接口和写接口做不同的验证方案。

写操作能够经过白名单测验以及灰度放量的方法进行验证上线，将接口未预期反常输出到 IM 东西以得到及时呼应。首要的写操作相关接口有：

订单的创立接口。
订单绑定付出单的提交接口。
用户付出后回调承认接口。
用户建议退款接口。

下图展现的是 AB 途径的流量装备界面：

下图展现了部分买卖预警告诉音讯：

读操作往往随同在写操作中。咱们运用途径的录制回放功用进行接口的共同性查看，经过比照得出差异排查问题。首要的读操作接口有：

获取付出方法列表接口
获取订单付出履约状况接口
获取充值列表接口
批量查询用户新客状况接口

下图展现的是流量录制回放体系的数据大盘：

方针收拾

监控是咱们体系的『第三只眼』，能够及时反响体系的健康状况，及时宣布告警信息，并协助咱们在出现毛病时剖析问题和快速缩小排查规划。硬件、数据库、中间件的监控现已在途径层得到支撑，这儿只需求收拾出运用的监控方针。

日志监控：恳求日志、服务端的过错日志。
订单事务方针

下单量、成单量、掉单量
单量环比数据
初次履约反常量
补偿机制履约量
各告诉事情 P95 耗时
成功履约 P95 耗时
履约按时率/成功率

付出事务方针

付出途径履约推迟 P95
付出履约推迟 P95。

用户购买完好耗时 P95。

可用性确保

在整个交给的进程中，转型前后对 SLA 要供给共同的可用性确保，能够看看下面的几个衡量标准：

一般 3 个 9 的可用性全年宕机时刻约为 8.76 小时，不同体系不同用户规划关于体系可用性的要求不相同，边际事务的要求或许会低一些，可是关于中心链路场景 TPS 或许不高，可是有必要要求确保高可用等级。怎样确保或许进步服务的 SLA 是咱们接下来要讨论的内容，一般有下面两个影响要素：

MTBF (Mean Time Between Failures) 体系服务均匀毛病时刻距离
MTTR (Mean Time To Recover) 体系服务均匀毛病康复时长

MTTR 快速呼应

持续监控

感知体系稳定性的第一步便是监控，经过监控来反映体系的健康状况以及辅佐定位问题，监控有两个方向：

第一个方向是方针型监控，这儿监控是在体系代码中组织各种实时打点，上报数据后经过装备报表出现出来的。

根底设施供给的机器监控以及接口粒度的呼应稳定性监控。

物理资源监控，如 CPU、硬盘、内存、网络 IO 等。
中间件监控，音讯行列、缓存、Nginx 等。
服务接口，HTTP、RPC 接口等。
数据库监控，连接数、QPS、TPS、缓存命中率、主从推迟等。
事务数据层面的多维度监控，从客户端和服务端两个视点来区分。

从客户端视点来监控服务端的接口成功率，付出成功率等维度。

从服务端视点从单量骤变、环比改变、买卖各阶段耗时等维度持续监控。

以上两点依据公司的 statsd 组件进行事务打点，经过装备 Grafana 监控大盘实时展现体系的健康状况。

第二个方向是日志型监控，这首要依靠公司的 ELK 日志剖析途径和 Sentry 反常捕获途径。经过 Sentry 途径能够及时发现体系告警日志和新发生的反常，便于快速定位反常代码的发生方位。ELK 途径则能够将要害的日志具体记录下来以便于剖析发生的场景和复现问题，用来辅佐修正问题。

反常告警

依据以上实时监控数据装备反常告警方针，能够提早预知毛病危险，并及时宣布告警信息。可是到达什么阈值需求告警？对应的毛病等级是多少呢？

首要咱们要在买卖的黄金链路上拟定比较严厉的告警方针，从下单、提单、承认付出到履约发货的每个环节做好装备，装备的严峻程度顺次递加分为 Info、Warning、Critical。依照人员类别和告诉手法来举例阐明告警途径：

订单首要预警点如下：

中心接口反常
掉单率、成单率骤变
买卖各阶段耗时添加
用户付出后履约耗时添加
下单成功率过低

MTBF 下降毛病率

体系监控告警以及日志体系能够帮咱们快速的发现和定位问题，以及时止损。接下来说的质量进步则能够协助咱们下降毛病发生率以防止丢掉，首要从两个方向来阐明：

规范化的检验方案

① 开发完结包含逻辑功用和单元测验，优先确保单测行数覆盖率再去确保分支覆盖率。然后在联调测验环境中自测，经过后向 QA 同学提测。

② QA 同学能够在测验环境下一起进行功用检验和接口测验，测验经过后便布置到 Staging 环境。

③ 在 Staging 环境下进行功用检验并经过。

④ 灰度交给以及双读验证能够依据实际状况挑选性运用。

⑤ 上线后需求终究进行回归测验。

共同的编码规约以及多轮 CR 确保

只要经过明晰意图和流程并且遵从这个流程做，才干更快更好地交给有质量的代码。

共同性确保

而跨微服务的分布式事务，像付出、订单、会员三个微服务之间选用终究共同性，相似 TCC 形式的两阶段提交，订单经过大局发号器生成订单 ID，然后依据订单 ID 创立付出单，假如用户付出后订单会改变本身状况后告诉会员微服务，履约成功则事务完毕，履约失利则触发退款，假如用户未付出，那么订单体系将该订单以及付出单做关单处理。

对应共同性确保，咱们对订单接口做了两个方面的处理：

分布式锁

关于上游的付出音讯监听、付出 HTTP 回调、订单自动查询付出成果三个同步机制别离依据订单 ID 加锁后再处理，确保同步机制不会被并发处理。

接口幂等

加锁后对订单状况做了查看，处理过则呼应成功，不然处理后呼应成功，确保上游音讯不会被重复处理。

订单关于下流的履约，是经过订单 ID 作为幂等 key 来完结的，以确保同一个订单不会被重复履约，并且经过 ACK 机制确保履约后不会再重复调到下流。

其间分布式锁选用 etcd 锁，经过锁租约续期机制以及数据库仅有索引来进一步确保数据的共同性。

补偿形式，尽管咱们经过多种手法来确保了体系终究共同，可是分布式环境下会有许多的要素，如网络颤动、磁盘 IO、数据库反常等都或许导致咱们的处理中止。这时咱们有两种补偿机制来康复咱们的处理：

带赏罚机制的延时重试

假如告诉中止，或许未收到下流的 ACK 呼应，则能够将使命放到推迟行列进行有限次的重试，重试距离逐次递加。终究一次处理失利报警人工处理。

守时使命兜底

为了防止以上机制都失效，咱们的兜底方案是守时扫描反常中止的订单再进行处理。假如处理仍然失利则报警人工处理。

过后总结

方针回忆

方针一：共同技能栈，下降项目保护本钱。方针成果是下线旧订单体系。

方针二：简化下单流程，下降端接入本钱。方针成果是后端共同接口，端上整合 SDK。

履行方案

搬迁的履行一共分红了三个大阶段：

第一阶段是搬迁逻辑，行将客户端建议的 HTTP 恳求转发到 RPC 接口，再由新体系履行。第一阶段做到一切的新功用需求都在新体系上开发，旧体系只需求日常保护。

第三阶段是旧 HTTP 接口搬迁，由新体系承载一切端的恳求，供给相同标准的 HTTP 接口，终究经过修正 NGINX 装备完结接口搬迁。第三阶段搬迁完结后旧体系终究完结了下线。

履行成果

到此文编撰时刻，言语栈现已 100% 搬迁到新的体系上，旧体系现已彻底下线，总计下线 12 个体系服务， 32 个对外 HTTP 接口，21 个 RPC 接口，15 个后台 HTTP 接口。

依据 halo 方针，搬迁前后接口 P95 耗时均匀削减约 40%，硬件资源耗费削减约 20%。依据压测成果比较，搬迁后支撑的事务容量添加约 10 倍。

体系搬迁完结仅仅取得了阶段性的成功，接下来体系还需求经过一些小手术来消除病灶，首要是以下几点：

不断细化监控粒度，优化告警装备，持续进步服务的稳定性。
关于 Python 的硬翻译还需求不断重构和优化，这儿学习 DDD 规划思想。
完善监控大盘，经过数据驱动来运营优化咱们的流程。
项目复盘总结以及事务遍及宣讲，进步人员关于事务细节的认知。

问题收拾

搬迁总是不能一往无前的，其间遇到了许多奇奇怪怪的问题，为此头发是真没少掉。

问题 1：搬迁了一半新需求来了，又没有人力补上来怎样办？

搬迁后再做重构和优化进程，其实很大一部分考量是由于人力不足啊，并且现状也不允许确定需求。那么只能写两遍了，优先支撑需求，后边再搬迁。假如人力足够能够挑选一个小组保护新的体系一个小组保护旧的体系。

问题 2：我分明恳求了，可日志怎样便是不出来呢？

不要置疑途径的问题，要先从本身找问题。总结两个原因吧，一个是新旧体系的搬迁点太涣散导致灰度欠好操控，另一个是灰度开关忘掉操作了，导致流量没有成功导到新体系上。这儿要注意一个点便是在搬迁进程中要尽或许的快速交给上线。

问题 3：公司 Java 根底服务不行完善，许多根底途径没有支撑怎样办?

所以自研了分布式推迟行列、分布式守时使命等组件，这儿就不打开聊了。

问题 4：怎样确保搬迁进程中两个体系数据的共同性？

首要咱们前面讲到的是体系代码搬迁，而数据存储不变，也便是说两个体系处理的数据会存在竞赛，处理的方法是在处理时加上分布式锁，一起接口的处理也是要幂等的。这样即便在上下流体系做数据同步的时分也能防止竞赛，确保数据的共同性。

就用户付出后付出成果同步到订单体系这一机制来说，选用推拉的机制。

① 用户付出后订单自动轮询付出成果，则是在自动拉取数据。

② 付出体系宣布 MQ 音讯被订单体系监听到，这是被迫推送。

③ 付出成功后触发的订单体系 HTTP 回调机制，这也是被迫推送。

以上三种机制结合运用使得咱们体系数据共同性有一个比较高的确保。咱们要知道，一个体系绝非 100% 牢靠，作为买卖付出的中心链路，需求有多条机制确保数据的共同性。

问题 5：用户付出后没有收到会员权益是怎样回事？

在买卖进程中，订单、付出、会员是三个独立的服务，假如订单丢掉了付出的音讯或许会员丢掉了订单的音讯都会导致用户收不到会员权益。上一个问题中现已讲到终究共同性同步机制，或许由于中间件或许网络毛病导致音讯无法同步，这时能够再添加一个补偿机制，经过守时使命扫描未完结的订单，自动查看付出状况后去会员事务履约，这是兜底战略，可确保数据的终究共同。

事务沉积

从接纳项目到现在也是对订单体系从懵懂到逐步加深了解的一个进程，关于当时买卖的事务和事务架构也有了一个了解。