一、背景
1.评价业务介绍
在电商平台中，评价业务是指用户在完成交易或体验服务后，对商品、门店、骑手、履约服务等对象发表的文字、图片、视频等内容反馈，并由平台进行审核、排序、分发与展示的全链路能力。
评价不仅是用户决策的重要参考------优质评价可显著提升商品交易转化率，更是平台构建信任生态、优化供给侧质量、驱动算法推荐的核心数据资产。以商详页为例，评价位于大家评楼层位置，日均承载百亿级流量，是整个链路中高并发、高可用要求极高的关键业务模块。
2.十五年"祖传"系统的痛点
评价中台系统已随着业务发展了 15 年，经过这么多年的需求迭代后代码复杂度极高，总计一百多万行代码，腐化的非常严重，代码纵横交错，新人上手学习成本极高，需求研发效率很低，无法满足业务需求快速交付的目标。
另外，系统历史债务积重难返，运维成本巨大，研发质量无法保障，特别是每年 618 和双 11 的大促备战要花费非常多的人力和时间来加固保障，QA 面对屎山堆叠的代码也是力不从心，经常遇到有评估不到的边缘逻辑，测试用例难以覆盖全面，线上 bug 问题时有发生。
陆续听到很多同学反馈评价中台的上述问题，于是花了一段时间来分析工程架构，想进一步明确评价中台的架构到底出了什么问题，对业务发展的影响是什么，对技术团队的影响是什么，总之先要论证重构到底需要解决什么问题。
3.重构要解决什么问题
3.1 无法满足业务需求，无法支撑业务多元发展
从业务发展来看，评价系统建设初期基于 B2C 的体系建立的商品评价系统，是一种比较定制化的架构设计，这在初期业务简单，对评价系统的要求就是支撑 B2C 商品评价的需求，确实能快速实现业务需求的落地。但随着业务发展至今，业务需要能够支持对外卖门店、骑手、汽车、药师等多种目标对象类型的评价，而过去的架构是基于商品 sku 评价的抽象，缺乏通用领域模型的扩展性设计，已无法承载多元化的业务评价诉求，产研面对非商品评价的需求要么是投入工时巨高的研发成本导致交付周期长，要么是让业务方先自行孵化解决无法复用中台能力。
总之，随着公司 O2O 本地生活、汽车、健康、七鲜等多元业务发展起来后，老的评价中台架构设计上缺乏灵活扩展性和复用性，无法很好的支撑这些业务方的发展。
3.2 产研测整体交付效率低下，需求交付吞吐量产能低
原本的评价中台系统已经迭代了 15 年之久，期间也没做过大的重构优化，导致多个工程、多个代码仓库，形成了一百多万行的代码量，而且这些代码是缺乏分层标准的，工程里充斥着大量的面条似的业务逻辑，缺乏面向对象的领域设计，基本上都是面向过程的事务脚本，层与层之间互相耦合穿透，大量的代码盘根错节、纵横交错在一起，单类几万行甚至十几万行代码普遍存在于各个工程中，形成了一座又一座的"屎山"。
与之带来的问题就是：一个需求来了研发先要花费一周评估代码在哪修改、如何修改，QA 也要花费一周时间看代码逻辑画流程图。总之，研发和测试给出整体技术方案和测试方案的时间成本很高，很多需求无法在双周迭代周期中完成，越来越多的需求必须通过跨版本周期才能实现上线。
3.3 线上问题频发，系统的稳定性差、运维成本高
3.3.1 系统稳定性差、问题多
评价是电商平台里的一个必备模块，用户通过阅读优质评价内容帮助平台提升交易转化率，在商详页面里有评价的楼层以及评价列表页，而商详又是整个黄流里 QPS 最高的系统，这样也会给评价中台带来非常高的并发请求，所以平台对评价系统的稳定性 SLA 要求很高。
但由于历史架构问题危如累卵，技术债务负担重，导致高可用方面不够稳定。举个例子：老架构评价缺乏领域能力抽象，对外发布了上百个 JSF 接口，数量多就导致了不好维护，而且有些接口年久失修没有很好的高可用设计，缺乏幂等、容错的能力，导致在一些业务场景下很容易出现数据不一致的问题，另外服务之间的依赖耦合不合理，会出现多个服务之间循环依赖的现象，发布上线的时候会出现服务抖动报错，影响系统整体的正确率。
3.3.2 研发运维成本高
评价的数据量规模有百亿级，因为评价信息无论对商家还是用户而言都是一种资产，用户发布后的评价是需要长期保存的，平台是不能随意对用户评价进行删除和归档的，哪怕用户是 2016 年发布的评价也仍需要保留至今。所以本质上评价是一个主数据超长生命周期的业务。
面对百亿级规模的大数据，老架构的在线存储部分维护了几十个数据存储集群，依赖了几十种类型的中间件，因为烟囱式的建设模式，数据库的表也达到百个以上。而离线存储部分，总计约上百个 FDM 大数据表、上千个字段，数量爆炸，命名混乱，字段冗余、不一致，导致使用方理解、接入成本巨高，评价一线研发日常答疑、查问题的 oncall 成本也更是居高不下。
此外，评价中台由于工程拆分细又多，且代码量大，导致单次发布构建和部署成本在五个小时左右，每次需求上线需要单独排期 2~3 天的时间来单独进行上线操作，研发发布到凌晨后半夜是常态。总之，一线研发平时要维护大量的存储集群和不同类型的中间件，需求发布时长居高不下，运维成本和工作压力都很大，技术团队的幸福感很低。
二、方案
1.重构范式选择
基于以上目标，我们需要思考如何重构才能实现跨越式的架构代际跃迁，参考行业里重构的案例比较多，一般范式主流有三种：
对于评价中台而言，存储架构的问题已经刻不容缓，应用架构层面也是雷坑无数，所以和老板、架构同学达成共识后决定采用方案三，做一次彻彻底底的大重构，把上层工程代码和下层存储架构都重构掉，彻底解决历史包袱痛点，建设评价的二代架构，实现跨越式的代际跃迁，锚定重构目标收益价值的最大化。
2.重构的战略设计
既然是彻底的重构，我们决定应用行业里比较成熟的方法论------DDD 领域驱动设计。在战略设计层面，按照如下方法进行抽象设计。
2.1 归纳评价业务场景用例，沉淀领域知识
技术与产品、业务专家一起开展事件风暴，充分共识评价业务的核心流程、业务规则、业务模型，提炼领域知识，归纳场景用例。
事件风暴是领域驱动设计（DDD）中一种高强度、协作式的研讨会方法，核心是要解决以下几个问题：
•打破沟通壁垒：强制业务专家和开发人员使用同一种语言（领域事件）进行交流，避免"各说各话"。
•快速探索复杂领域：在短时间内，将模糊、复杂的业务需求梳理成一个清晰的、可视化的流程模型。
•发现聚合、限界上下文：通过分析事件的触发命令和涉及的领域模型，自然地识别出 DDD 中的核心构建块。
•对齐团队认知：确保所有参与者（产品、业务、开发、测试）对业务流程的理解是一致的，这是后续成功设计和开发的基础。
2.2 抽象评价全局核心业务流程，聚焦不同阶段的业务目标和诉求，划分问题空间
第一阶段（橙色背景）：
评价官注册：评价官账号创建入口。
评价官成长：评价官能力或等级提升路径。
评价官权益：评价官可享受的福利或权限。
第二阶段（粉色背景）：
生产评价：评价官或用户创建生产评价。
加工素材：对于评价进行润色，增加图片、晒单视频等。
发布评价：对编辑好的评价进行发布。
第三阶段（绿色背景）：
内容理解：对发布的评价进行语义或信息解析。
审核：内容安全与质量审查。
标注特征：提取内容的关键标签或属性。
圈池/聚合：将内容按类别聚合和圈选。
第四阶段（黄色背景）：
分发推荐：基于算法向用户推荐优质评价内容，并在商详、点评等多个场域进行分发。
第五阶段（蓝色背景）：
浏览体验：用户查看推荐内容的环节。
互动：用户对内容的评论、点赞等互动行为，最终流向"加购"，进入交易阶段。
第六阶段（紫色背景）：
加购：用户将商品加入购物车。
结算：用户支付订单。
订单：生成交易订单。
第七阶段（蓝绿色背景）：
履约：商品或服务的交付。
对账：交易资金核对。
权益奖励：根据评价官贡献发放奖励，最终流程结束。
2.3 厘清领域边界，划分限界上下文
根据 2.2 的问题空间划分结果，我们进行领域的识别和分解：
评价域内部的子域划分确保边界清晰，每个子域的业务目标和技术目标清晰且独立。
子域最终划分为：创作者、生产、处置、推荐、消费、转化、收益七大子域，但对于评价业务而言架构上需要 tradeoff，推荐域和转化域更多是依赖外部算法、交易部门的领域能力，评价自身这块的业务逻辑非常薄不是工程重点，因此剩余的五个子域才是本次重构的核心建设范畴。
2.4 根据子域限界上下文关系，定义微服务分层标准
微服务架构分层标准：
2.4.1 BFF 服务层
即 BFF 服务，职责：对外提供 Http 接口，负责信息聚合、裁剪、适配。
举例：pc 端展示信息多（需要额外信息，聚合）、app 展示信息少（裁剪掉不必要的信息），APP 版本控制、AB 实验（端侧适配逻辑）。
注意：BFF 的划分原则是按照 "业务域下展示端" 维度来划分的，例如 评价 pc-bff、评价 app-bff、评价小程序-bff。
2.4.2 领域服务层
即领域服务，职责：对外提供 RPC 接口，提供该领域的企业级业务能力，目标是实现领域逻辑的高内聚，对上层多个业务方提供复用能力。
3.重构的战术设计
在战术设计上更多是指具体的代码怎么写、数据存储架构怎么落、重构前后逻辑怎么保证一致性、海量的数据怎么做到安全迁移到新存储等等这些具体方案，由于篇幅有限，我下面重点介绍一下应用架构设计和数据存储架构设计。
3.1 应用架构设计
对于应用架构，行业里有很多流行的架构，例如 DDD 四层架构、洋葱架构、六边形架构等等，但这些都是架构的指导思想，缺乏一套具体的应用框架去落地，而开源的 COLA 框架是近些年践行以上思想的一款脚手架，我们借鉴了 COLA 里面的一些值得学习的优秀思想，但也放弃了一些不太吻合我们诉求的设计，结合内容业务和团队的实际情况，构建出了内容域的应用架构脚手架------云梯架构。
云梯架构，我们抽象定义出了"LPD 架构原则"，所谓 LPD 原则是指"Layer、Package、Domain"三个单词，表示分层、分包、分域的架构原则，旨在能够让重构后的工程代码通过技术框架去约束开发人员，尽量控制延缓后续代码迭代导致的工程腐化，通过这一套框架级的约束让重构后的代码能够真正实现高内聚、低耦合的架构目标。
云梯架构对 pojo 进行了精简，减少不必要的对象定义，缩减各种类型对象互相来来回回转换带来的繁琐和开发成本，对分层之间的依赖要求也做了一定的改良。
3.1.1 Layer ------ 划分四层架构
1）适配层（Adapter Layer）：负责对前端展示（APP、小程序、H5、PC 端）的路由和适配，对于传统 B/S 系统而言，adapter 就相当于 MVC 中的 controller；
2）应用层（Application Layer）：主要负责获取输入，组装上下文，参数校验，调用领域层做业务处理，如果需要的话，发送消息通知等。层次是开放的，应用层也可以绕过领域层，直接访问基础实施层；
3）领域层（Domain Layer）：主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Domain Entity）的方法对 App 层提供业务实体和业务逻辑计算。领域是应用的核心，不依赖任何其他层次；
4）基础实施层（Infrastructure Layer）：主要负责技术细节问题的处理，比如数据库的 CRUD、搜索引擎、文件系统、分布式服务的 RPC 等。此外，领域防腐的重任也落在这里，外部依赖需要通过 gateway 的转义处理，才能被上面的 Domain 层使用。
3.1.2 Package ------ 按功能精细分包，降低认知成本
分层是属于大粒度的职责划分，太粗，我们有必要往下再 down 一层，细化到包结构的粒度，才能更好的指导我们的工作。
还是拿一堆玩具举例子，分层类似于拿来了一个架子，分包类似于在每一层架子上又放置了多个收纳盒。所谓的内聚，就是把功能类似的玩具放在一个盒子里，这样可以让应用结构清晰，极大的降低系统的认知成本和维护成本。
云梯架构定义的分包标准如下，需要注意的是 Adapter 层其实是可选的，里面封装的是 http 请求的处理器，对于纯 RPC 的 JSF 服务是不需要的。
3.1.3 Domain ------ 顶层按领域划分，实现高内聚
除了分层和分包之外，我们代码里也会引用其他域的类和方法，而且对于域内也会切分成更小的三级域，这样做的好处是让领域内的代码逻辑更加内聚，域与域之间的耦合变低，那么顶层包结构应该是按照领域划分，让领域内聚。
也就是说，我们需要综合考虑分层、分领域以及功能分包这三个维度，这样最后呈现出来的就是先按层切分，再按域切分，最后按功能包切分，这样的规则会让工程的代码结构非常清晰，做需求评估代码逻辑的时候可以快速锁定具体的位置，告别之前在屎山堆叠的代码里查找逻辑的痛苦。
3.1.4 防腐层的设计
对于外部的具体依赖我们通过防腐层做隔离，对数据库、ES、JIMDB、上游 RPC 访问等等外部依赖全部统一使用 Gateway 接口来实现业务领域和外部依赖的解耦，其实现方式如下图所示，主要是在 Domain 层定义 Gateway 接口，然后在 Infrastructure 提供 Gateway 接口的实现类，这里的重点是使用了 DIP 依赖倒置原则，DIP 可以使 Domain 层不依赖 Infrastructure 层，这样可以让 Domain 层的业务逻辑保持足够的纯粹性，不去耦合任何技术实现细节，Domain 层代码不会感知 MySQL、ES、JimDB 这些技术中间的存在，那么后续就可以很容易的替换其他技术组件，由于不会影响 Domain 层的代码逻辑，所以可以很轻松地实现技术组件的升级更换，实现业务逻辑与技术实现的分离。
3.2 数据存储架构设计
评价老架构在业务 15 年的发展过程中，一直使用读写相同的模型结构，写的业务扩展性、读的技术稳定性要求揉杂在一起相互影响，导致在开发、运维过程中均会因为数据结构产生效率、质量的问题。例如，一个需求需要增加 DB 字段，但因为数据量大、流量高，白天容易导致性能问题，研发需要熬夜 2-3 天才能把数据库的字段添加完，效率非常低，需求改动成本非常高。
面对以上问题，我们重新设计了在线存储架构和离线存储架构，下面简单介绍：
3.2.1 在线存储架构设计
CQRS 架构 ------ 读写模型分离
通过读写分离（CQRS）实现查询（消费链路）和命令（生产链路）的分离，C 端高并发流量利用 JIMDB、JIMKV 视图模型数据扛量，B 端低 QPS 流量场景使用 ES 视图模型数据，评价生产链路主数据落 JED 数据库，与 MQ、Flink 等处理组件协同聚合处理转化为视图数据，满足高并发查询与业务灵活扩展的双重诉求。
数据库物理表和模型结构的彻底重构
老的评价数据库表有上百张，这么多的原因是老表是烟囱式的设计，都是 case by case 的定制化，初评、追评、晒单、安装、满意度的评价等等都是独立的表，没有任何的抽象，而且表和表之间会存在数据冗余，又没有做到很好的一致性保证，导致很多冗余字段不一致，导致系统 bug 比较多，难以维护。
回溯本文开始提到的背景和重构目标，需要能够支撑多元化的业务发展诉求，目标做到提升评价系统的灵活扩展性和复用性，因此我们从架构设计理念上必须从过去的"面向数据驱动开发"转变为"面向领域驱动开发"，杜绝以往面向数据库建模的 case by case 的定制化开发思想。
评价即是指评定事物的价值，评定需要有主体也就是"谁"来进行评价，事物即评价的对象也就是客体，而价值即为如何评判这个事物的价值描述，故此来看，评价可以总结为"评价方(谁)对评价对象(客体)，使用多种方式(文字、图片、视频、星级等)进行评判描述。"
而评价凭证是指是否拥有评价的资格，比如，用户购买了一双鞋子那么就会给用户下发评价的资格，即凭证。
所以最终我们抽象出一个可以灵活扩展、通用性强的评价领域模型，如下所示。
那么对于存储架构的设计，我们以应用架构的评价领域模型作为基准，推导物理表抽象为面向领域建模，划分出凭证表、评价表、审核表等等，在表 Schema 的定义中定义了基础信息字段和扩展信息字段，扩展信息字段采用了易于扩展的 JSON 格式，方便后续灵活调整，但最重要的改变是将以前散落在多张表里的烟囱信息全部改为聚合到评价主表里，汇聚了评价的主体（谁发布评价）、客体（对什么对象评价）、评价内容（文字、图、视频等）等全局上下文信息，这样研发和 QA 同学可以很轻松的通过一张表理解业务的核心要素，减少了数据层面的梳理和评估成本，也更容易去扩展调整。
3.2.2 离线存储架构设计
重构前离线数仓架构：
GDM 数据资产仅覆盖商品评价场景，对于订单、安装、凭证等其他评价场景数据仅有 FDM 模型，所以外部业务方只能通过 FDM 获取离线数据。
对于大量依赖 FDM 的平台而言存在以下几个痛点：
a、维护成本高：抽取自生产系统的 FDM 表几十个、包括字段几千个，命名多混乱，数据多冗余、不一致，下游理解、接入难度较大，评价业务研发答疑、查问题成本较高；
b、下游重复建设：几百个下游直接消费 FDM 表数据，获取的数据质量参差不齐，数据口径不统一，且存在不同下游的重复加工问题；
c、受重构影响大：若评价系统存储模型进行重构，例如 MySQL 迁移 JED、表字段拆分到不同的表，几百个下游可能都要修改读表逻辑，全局工作量很大。
解决方案
我们在本次重构时与数据资产部的数仓团队充分交流拉通重构目标，确定新离线存储架构方案为统一 GDM 模型，同时这也是数仓团队技术上的 OKR 目标，所以大家的目标一致，收敛下游能感知到表、字段，避免冗余、不一致、重复计算。
重构后离线数仓架构 --- 统一 GDM 模型的架构
依据 5W2H 数据资产建设标准，抽象设计评价域的 GDM 资产模型。针对涉及场景较多的评价数据，通过业务过程进行细化分类，具体按照评价业务场景分别对应生产以下八个 GDM 模型：商品评价（涵盖用户评价与 AIGC 评价）、评价晒单、门店评价、安装评价、订单评价、追加评价、评价回复、主站评价数。另外，我们也对 FDM 表进行了一定的合并和精简，极大减少了 FDM 表的数量。
可以很清晰地看到新架构里所有的业务方不再直接依赖 FDM 表，改为依赖 GDM 表模型，通过引入 GDM 模型层实现了业务方与 FDM 模型表的彻底解耦，这样带来的好处是数据源表结构、字段类型的变更导致的 FDM 调整再也不会影响到业务方，做需求不需要再拉外部业务方评估影响，这样评价中台自身就可以完全独立闭环支撑业务需求的交付，而且通过聚合 GDM 模型，也极大减少了 Hive 表的数量，维护成本显著下降，从而整体上提升了离线链路需求的研发交付效率。
三、重构的一些难点与挑战
1. 重构前后存储层数据一致性如何保证
这次重构是把数据库存储层做了全面的重构，数据库的改动我们知道是比较难，但是实际做下来感觉是严重超出了我们的预判。非常有挑战的难点概括如下：
a、数据规模大： 评价的历史数据规模有百亿级，对于这么大量级的数据进行迁移、数据校验、数据订正都是非常耗时耗力的，刷一次百亿数据的时间大概需要 3-4 天，遇到 bug 问题后还需要 fix 后再重复去刷数，时间成本极高。
b、数据不能丢： 评价的数据不同于订单、商品等主数据，因为订单可能过了 3 年后可能用户就不会再查看了，商品下架后也不会展示分发了，但是评价的数据生命周期是非常长的，它作为一种信息资产需要永久保存，哪怕用户 10 年前发布的评价也是不能丢弃的，需要一直保存，评价数、好评率这些指标会影响商品推荐的权重，也会影响商品的转化率，所以面对这种业务特点就要求数据迁移要能够保证数据不能有任何的丢失和错乱。
c、数据 diff 问题定位难： 如何高效、准确地判定数据是否一致，定位根因并完成修复，是一项极具挑战性的任务。最直接的思路是自行编写 Java 代码，通过多线程并发遍历全量数据进行比对、分析和修复。然而，这种方案不仅时间成本高、机器资源消耗大，造成老库读写压力变高，会对老数据库的稳定性造成较大影响，因此不可取。
以上问题比较复杂，对于数据自然分为存量历史数据和增量新数据，我们对于存量和增量采取了不同的解决方案，具体如下：
1.1 存量的数据一致性保障我们选择了大数据处理方案
将 JED、ES 等系统的数据同步到离线数仓（Hive 表），借助 Spark 进行数据加工和聚合，生成对比数据。通过对比报表和本地分析工具，我们能够快速分析出 diff 的具体原因。如果属于迁移或生产代码 bug，则修正代码并对问题数据进行重迁移；如果不是问题，则优化比对规则，降低误报噪音。通过这一流程，diff 数量持续收敛，直到数据全部对齐为止。
1.2 增量的数据一致性保障我们选择了监听数据库 Binlog 对比的方案
•升级对比切流工具，针对写接口，由并行改为串行，在老系统写入失败时，不再调用新系统写接口
•整理老系统数据库表比对范围及每个表字段新老映射关系
•订阅 Binlog 增量消息，每个表的 Binlog 触发一个检测修复的责任链，链上每个节点通过调用新老系统接口实现同构（如 MySQL 到 MySQL）和异构（如 MySQL 到 ES、Cache 等）数据源的实时一致性比对校验，每个节点可单独设置对比延迟时间。
2. 重构前后的业务逻辑一致性如何保证
重构后你敢不敢切量？如果敢切量就证明有办法能够证明重构后的业务逻辑和重构前是一致的。
理想很丰满，现实很骨感，实际情况是：
重构过程中很多同学反馈读了大量历史屎山代码后非常的崩溃，原来的评价代码有 15 年之久，代码量有一百多万行，而且熟悉历史代码逻辑的研发同学早已离职，那么就会有非常多的代码逻辑是难以让人理解清楚的。面对这种问题，研发往往只能根据自己的判断去编写新的代码逻辑，但是往往最大的 gap 就在这里------新代码逻辑会遗漏老逻辑规则。
这也是很多重构项目都会面临的难题，如何保证重构后的代码逻辑与之前的逻辑是一致的，大家想到最多的就是利用流量回放和 diff 进行逻辑一致性的验证。但是，理想很丰满，现实很骨感，我们做了线上的流量 diff 后发现存在大量的不一致 case，这个比例非常高。
举个例子：获取评价列表的接口，我们抽样 0.1%进行流量 diff，那 1 天下来对比流量里会有十几万次的流量是对比不一致的，但无奈的是一名研发每天能够排查清楚的不一致 case 最多也就几十个，何时才能把十几万不一致的 case 全部排查清楚呢？ 有的同学可能会说可以把抽象比例继续调低至 0.001%，这样虽然降低了整体的对比基数，但会担心抽样率太低导致无法覆盖所有业务场景，置信度不足。
这个问题让团队陷入了一段迷茫期，一时间大家不知道该如何解决，也不知道何时能够把问题都查清楚，项目进度也陷入了停滞状态。为了解决这个问题，我和团队架构师想了很多方案，也调研了公司内外团队的一些方案，最终我们采用了如下解决方案：
面对海量 DIFF 的快速收敛，单纯依赖人工是完全不可行的。必须构建一套涵盖观测指标、问题分析、高效运作与风险控制的流程化、体系化能力，以支撑一套系统化、产品化的解决方案。
2.1 建立对比指标体系
在评价系统中，主要以技术指标为核心，业务指标为辅助，构建全面的评估体系，用于衡量 DIFF 的收敛情况。
2.2 系统化问题分析与优先级排序
对海量 diff case 进行聚类统计，看类别总体占比分布进行系统性分析，不是 case by case 排查，按问题影响范围和严重程度进行排序，从大到小、逐项解决，推动问题逐步收敛。
这里强调一下：对不一致 case 的聚类统计非常重要，我们随机抽查 50 个不一致的 case，发现 80%的原因都是存储层的数据本身不一致导致的，只有 20%的 case 是由于工程代码逻辑导致的。所以，我们的作战策略做了非常大的转变：从海量的不一致 case 排查工作转为去定向解决存储层的数据一致性问题。经过数据层一致性的大量校验和订正，最终使得流量 diff 不一致的比例下降了 80%，进而突破了这个难题。
2.3 快速验证与指标收敛确认
在问题修复后，在本地进行流量回放进行快速验证，确认技术指标是否已达到收敛标准，确保系统稳定性与一致性。
2.4 灰度切流条件评估与执行
当技术指标与业务指标均满足切流条件后，方可进行灰度切流，逐步将流量切换至新系统，降低风险并保障业务平稳过渡。
综合以上四步不断重复观测指标------修复问题------修复验证------观测指标收敛 这样的正向循环，最终技术指标和业务指标都达到可切量的标准，然后才会启动线上切量灰度。
另外，和大家分享一个认知：流量的 diff 一致率很有可能是无法达到 100%，因为老架构可能存在历史 bug、对比时序时差问题等原因就会导致无法实现 100%一致，有些接口可能到 80%就已经到天花板了，所以一味地追求 100%是无法实现的，这个时候就需要转变作战策略，除了关注技术指标的一致率，还要关注业务指标的情况，下面就分别简单介绍这 2 类指标主要关注什么。
2.4.1 技术指标
技术指标接口一致率面板：主要展示日期、业务 ID、读写标签、调用量、失败量、成功率等。
聚类分析
主要包含日期、业务 ID、不一致字段、问题分类、失败数量、失败数总占比、失败数总占比变化率、失败数占比、失败数占比变化率，问题分类如下
2.4.2 业务指标
对于评价业务而言，重点关注的业务指标包括：
a、评价数（总数、差评数）
•100 以内新老系统需准确对齐，保证最终一致性；
•100 以上，可接受新老系统有差异， 包括
1）数据差异在 10 以内。
2）差异不会导致评价数模糊化规则分档有变化（如 199 和 201，对应的模糊化分档是 100+，200+）。
b、好评率， 新老系统需保证前台展示上准确对齐，即可以有实际小数点后差异，但按照取整规则处理后需保证一致。
c、业务核心指标： 商详订单转化率， 评价楼层优质曝光率，评价列表加购率等，可通过试金石分流实验来观测。
在不断修复 bug 后观察以上技术指标和业务指标的一致率变化，针对不一致的 case 进行聚类分析后再去修复和观察指标，循环往复，这个过程持续的时间会比较长，是一个不断收敛问题的过程，最终从指标上看技术、业务指标均可控，达到可切流的条件后就可以开启线上的正式切量了。
3. 如何做好组织保障和人员分工
组织保障是为重构项目创造一个稳定、支持性的环境，确保项目有足够的资源、权威和流程来应对挑战。
3.1 明确战略意图与统一思想
3.1.1 为什么重构
必须让所有相关方（从 C2 到一线开发）清晰地理解重构的根本原因：是为了提升开发效率和质量、支撑未来业务发展、降低技术成本和稳定性风险。
3.1.2 获得领导的支持
深度重构这个工程是超级复杂的，研发和测试的工时成本会非常高，所以事前一定要和领导充分沟通拉齐认知，确保领导在这个事情上的想法与团队是一致的，这样可为项目扫清障碍、提供资源，并在项目遇到阻力时能够给予支持，领导需要持续向整个组织传达重构的战略重要性。
3.1.3 明确重构的目标
重构有大有小，可以简单做亦可以做的很彻底，到底怎么做取决于想要达到的目标，所以重构之前一定要明确最终希望达成什么效果，具象到研发效率提升多少、需求吞吐产能提升多少、系统的稳定性提升到什么水位等等，只有带着明确的目标才能进一步明确重构的方式和范围，显然评价的重构目标是非常明确的，与之带来的就是非常具有挑战性，我们锚定了最大的收益目标，就要接受彻底重构带来的技术挑战和困难。
3.2 建立专属的组织和流程机制
复杂的重构项目需要专门的组织结构来负责。
3.2.1 明确核心角色
项目负责人：是重构项目的一号位，为整个项目的成败负责。
架构师：负责技术选型、架构决策和技术方案评审。
核心项目成员：全程参与重构项目的关键人员，一般是架构师、业务研发骨干、QA 骨干、SRE 骨干的混编。
产品：代表业务方，确保重构后的系统功能与业务需求一致，并管理重构过程中可能产生的需求变更。
项目 pmo：负责整体计划、进度、风险管理和跨部门协调。
3.2.2 组建重构专项团队
组建一个专职团队负责核心重构工作，避免让开发人员一边做业务需求一边做重构，让研发专心聚焦重构工作，保证重构的进度。
工作模式：可以采用"先做重构后追需求"模式，即重构开始时先对代码打个 tag 分支，然后重构期间专心攻克老代码的翻新和解决问题，待重构基本大体完成状态时再去追齐过往遗漏落下的业务需求，等全部落下的需求追齐后就可以进行流量 diff 和数据 diff，评价重构就是采用的这种工作模式。
3.2.3 制定流程规范
我们在重构之前召开了项目的启动会，明确项目的主 R、项目成员，清晰的明确好大家的分工。
明确各职能团队接口人：成员来自各个相关架构师团队、业务研发团队、测试团队、运维团队的接口人。
透明的沟通机制：定期同步会：每日站会（核心团队）、每周同步会（跨职能组）、每月复盘会（全员对阶段性问题复盘改进）。
风险与依赖管理：建立风险登记册，持续识别和管理技术风险、资源风险、业务依赖风险，明确每个风险的负责人和应对策略。
3.3 重视组织温度与关怀
大型重构项目是技术上的攻坚，更是对团队心力与韧性的长期考验。项目周期动辄半年以上，时间紧、任务重加班也是在所难免，期间伴随着高频度的技术攻关、深夜发布和问题应急，团队成员持续处于高压状态。若只关注进度与代码，而忽略"人"的状态与感受，极易导致士气低落、人员倦怠甚至流失，最终危及项目本身。
其实，在这方面我们做的也不够好，我也反思总结了后续应该如何改进。在此，建议大家聚焦以下三点：
3.3.1 提供实质性支持，为工作有效减负
•明确反对持续疲劳作战，在攻坚后主动安排调休，保障团队可持续战斗力，杜绝持续性疲劳作战，认可"休息也是生产力"。
•后勤保障升级：协调公司资源，保障加班期间的餐饮、交通与必要物资供应，解决后顾之忧。
3.3.2 营造心理安全感，让压力有出口
•在站会、复盘会中，不仅同步进度，更鼓励坦诚沟通工作中的挫折与困惑，建立"对事不对人"的讨论文化。
•管理者通过定期 1 对 1 沟通，主动关注成员负荷与心态，成为团队情绪的"减压阀"，确保压力能被及时觉察和疏导。
3.3.3 建立成长激励链路，让付出被看见
•即时、公开地认可具体贡献（如突破性方案、高质量代码），并通过阶段性庆祝仪式，持续注入成就感。
•将项目挑战转化为个人财富，明确参与此类复杂重构对能力成长的长期价值，并支持成员将经验沉淀为技术文章或分享，助力其职业发展。
总之，复杂大型重构项目的组织保障，本质上是一个系统工程，远比预期想象复杂得多。
•组织保障是"上层建筑"，它决定了项目能否在一个被理解、被支持、资源充足的环境下进行。
•人员分工是"执行引擎"，它确保了每个参与者都知道自己的角色和目标，能够高效协同。
将两者有机结合，才能将重构从一场高风险、高不确定性的"豪赌"，转变为一个可控、可预测、可成功交付的工程项目。
四、经验和沉淀
重构方法论总结：五"要"原则
1. 技术复杂度要控制
在基于方案定制完善后，可定制更为细化的里程碑，并且按照数据层、代码层独立拆分，优先完成数据层重构，避免数据层和代码层同时重构，采取控制变量法，控制技术复杂度。
补充：本次评价重构是上层代码和下层存储一起重构的，实践下来难度非常大，周期也很长，过程非常的曲折。所以，非必要的情况下建议还是一层一层地渐进式重构更稳妥。
2. 里程碑要可验证
在代码层重构上，可按照业务模块、渠道等功能链路以可验证、可交付为前提进行里程碑的拆分，做到能够逐步交付一些重构成果，积小胜为大胜，不断提升大家的信心。
3. 前置梳理要充分
建议前期投入更多的时间进行逻辑的梳理和方案的产出，不仅梳理出核心业务流程，可使用工具来产出所有数据层的字段结构，并梳理出调用链路的详细字段，防止遗漏逻辑和功能点，也可前置捋清楚废弃功能、代码逻辑、数据表，避免重构无用的模块。
4. 人力资源要固化
按照重构项目领域和功能拆分出固化人力和主 R，大型的项目建议不光按照领域拆分领域主 R，还需要按照功能拆分功能模块主 R，使功能主 R 具备整体链路视角，并保证领域主 R 可 cover 功能主 R 的职责，确保每个功能保持至少 2 人熟悉，并且可指导新人快速介入，这样对于人员临时调换和介入可降低熟悉和理解成本。
5. 阶段性问题要复盘
复杂度较高且问题不明朗时，随时进行阶段性复盘，无需准备复杂材料，主要以近期问题讨论和解决思路为主，及时拉齐问题认知和调整目标、解决方案。
五、收益效果
以上和大家聊了很多重构过程中的方案和思考，本次重构后拿到的实际收益效果超出预期目标，效率方面新架构下需求吞吐量产能提升至老架构的 2.5 倍，工程代码量降低了 80%多；稳定性方面 25 年双 11 大促期间新架构线上运行平稳。
六、结语
"扶摇"之名，取自《庄子·逍遥游》："抟扶摇而上者九万里"。
我们深知，重构不是终点，而是新起点。 愿这份 15 年系统的涅槃重生之路，能为你照亮前方的重构征途。