提醒是付费专栏但是在知识星球里是免费的。这不是一份产品经理写的功能需求文档。商品系统的重构需求来自技术团队触发原因是一次大促事故。重构的范围不只是商品系统而是公司所有核心系统从PHP到Java的整体迁移。后续的每一个技术方案都要回到这份文档里找依据。文档概要项目内容系统名称C端商品系统需求类型技术重构非业务功能需求需求发起方CTO发起技术委员会推动重构目标将商品系统从PHP迁移到Java重建数据模型和缓存体系涉及团队重构部商品/库存组、数据架构、基础架构、业务架构、QA需求背景业务现状公司是一家几亿用户规模的互联网公司业务覆盖多个C端渠道。当时所有核心系统都是PHP实现的商品、库存、订单、支付、用户、营销全部是PHP。商品系统是公司最底层的基础数据服务。首页、搜索、商详页、购物车、下单、收藏夹、推荐几乎所有面向C端用户的业务系统都从商品系统读取数据。平时流量就不小一到大促商品域的流量在整个公司排第一。PHP时期的商品系统日常流量下能用瓶颈已经很明显了。触发事件某一年的大促活动系统直接瘫痪了。不是某个接口响应慢、某个页面打不开是核心交易链路整体不可用持续了半个多小时。用户打开APP什么都干不了不能浏览商品不能下单不能支付。公司为这场大促投了大量广告费做预热和推广。活动还没开始多久系统就挂了。CEO说了一句话公司花了那么多广告费来做这场大促结果没取得预期的效果。这次事故的直接后果大促期间的预期营收目标没有达成大量用户涌入后遇到系统不可用用户体验严重受损运营团队此后对大规模活动持谨慎态度不敢轻易放量技术团队事后复盘确认PHP系统在架构层面已经无法承载当前的业务规模重构决策那场事故之后CTO做了一个决定用Java重构公司所有核心系统。这不是修修补补式的优化是一次彻底的技术革命。CTO成立了一个专门的重构部门50号人从业界挖了不少在高并发、大数据量场景下有实战经验的技术专家。各路架构师全部上场数据架构师负责新的数据模型设计业务架构师负责业务领域的拆分和梳理基础架构师负责中间件和基础设施的选型与搭建。新的业务需求基本暂停了所有技术资源集中在重构上。从立项到核心系统全部切换到Java耗时差不多一年。重构全景公司整体的「电商」业务从技术视角可以划分为三条线。选购线。用户浏览、搜索、查看商品详情、收藏的完整链路。商品系统和库存系统是这条线的核心。下单支付线。用户从购物车发起下单、选择支付方式、完成支付的完整链路。订单系统和支付系统是这条线的核心。用户营销会员线。用户注册、登录、会员等级、积分、优惠券、营销活动等。用户系统和营销系统是这条线的核心。三条线不是完全独立的。下单需要读取商品数据名称、价格、库存营销活动需要关联商品信息。商品系统作为基础数据源被其他两条线的多个系统依赖。我当时在重构部负责选购线中的商品系统和库存系统的重构。这个专栏聚焦商品系统库存系统的重构不在范围内。商品系统的重构范围商品数据模型重新设计从PHP的宽表迁移到EAV模型C端商品读服务全量重写多级缓存体系建设OHC堆外缓存 Redis中央缓存读接口API重新设计十几亿条商品数据的迁移灰度上线和数据质检商品系统的业务职责在讲技术问题之前先把商品系统在业务上干的事情说清楚。商品系统管理的是公司所有在售商品的基础数据。这些数据对C端用户是只读的由运营人员在后台维护。C端用户通过各种入口浏览和查询商品信息不会修改数据。调用方开篇词里提过商品系统被公司几乎所有C端业务系统依赖。具体的调用方和各自需要的数据调用方需要的数据调用特征首页商品名称、图片、价格高频集中在少数热门商品搜索分类、标签、名称、价格中频查询条件多变商详页全量商品信息基础属性 销售属性 价格 库存状态高频单品查询购物车名称、图片、价格、库存状态中频批量查询下单价格、库存、商品状态低频对一致性要求最高收藏夹名称、图片、价格低频大促期间会突增推荐分类、标签、销售属性中频批量查询不同调用方需要的字段差异很大。这个特征直接影响了后面读接口的API设计方式。数据类型商品系统管理的数据分三类。基础信息。商品名称、描述、图片、分类、品牌。创建后很少修改。销售属性。运营会频繁新增的字段是否爆款、是否支持某种折扣、是否在特定频道展示、适用人群标签。这类属性的特点是数量不固定运营每隔一段时间就会提需求要加新的属性。价格与状态。价格、上下架状态、可售渠道。修改频率中等对一致性要求高。流量特征商品系统的流量模式是读多写少。C端用户只读不写写操作来自运营后台量很小。读流量有两个特征。日常流量持续且不低。不像秒杀系统有明确的时间窗口商品数据的读取是全天候的。任何时候用户打开APP、浏览商品、搜索都在读商品数据。大促期间出现明显的流量脉冲。用户提前收藏商品活动一开始从收藏夹涌入商品详情页短时间内集中读取同一批商品。开篇词里提过的峰值数据32台机器上的70万并发读请求。现有PHP系统的问题重构不是因为PHP这个语言有问题是因为当时的PHP系统在那个业务规模下已经到了瓶颈。性能瓶颈PHP-FPM的每个请求由一个独立的Worker进程处理进程之间不共享内存。高并发场景下能开多少Worker进程直接决定了并发处理能力的上限。进程数到一定程度后操作系统在进程切换上的开销会明显增加吞吐量反而下降。当时的商品系统在日常流量下已经需要大量机器来撑。大促时流量翻几十倍靠加机器已经不现实了。缓存能力受限PHP进程之间内存不共享这一点影响很大。Java应用可以在JVM层面做本地缓存商品数据加载到内存后同一个JVM里的所有请求都能直接读取不需要走网络。PHP做不到每个请求要么从数据库读要么走Redis这类外部缓存。商品数据体量有好几个G。全部走Redis网络开销在高并发下会成为瓶颈。Java可以用OHC这类堆外缓存把热数据放在本机内存里极大减少对外部缓存的依赖。PHP没有对等的技术方案。数据模型僵化PHP时期的商品表是传统的宽表结构。每新增一个销售属性需要DDL改表结构加一列。表结构改动意味着走发版流程协调DBA审核SQL、选择低峰期执行、验证线上数据。运营新增属性的需求很频繁加一个字段的周期如果是一周一个月要加三四次这个流程的效率问题就暴露出来了。团队结构公司的技术团队以Java工程师为主PHP工程师的招聘难度越来越大。核心系统用PHP意味着一个很小的人才池在维护一个很关键的系统人员风险很高。重构目标技术指标维度PHP时期重构目标单机并发处理能力几百QPS几万QPS大促峰值支撑扛不住靠堆机器32台机器扛住70万并发读本地缓存无进程间内存不共享OHC堆外缓存G级别数据量新增销售属性DDL改表走发版流程数据库加一行记录不需要发版读接口灵活性全量返回或定制接口按需返回调用方声明需要哪些字段架构目标读写分离。C端读服务和运营后台写服务分开部署读服务可以独立扩容不受写操作影响。多级缓存。OHC堆外缓存作为一级缓存Redis作为中央缓存MySQL作为数据源。三层之间的加载、更新、失效策略要形成一套完整的体系。流量隔离。大促流量和日常流量走不同的处理通道互不影响。平滑迁移。不能停服务直接割接。需要双写、灰度、回滚的完整机制保证迁移过程中线上业务不受影响。核心技术需求这一章把重构需要解决的关键技术问题列出来。每个问题在专栏后续的文章里会有完整的设计和实现这里只做概述。数据模型EAV传统宽表模式下每个销售属性是表里的一列。商品表有几十列甚至上百列大部分在某个具体商品上是空值。每加一个新属性就要DDL。重构后采用EAV模型Entity-Attribute-Value。每个属性是表里的一行记录而不是一列。记录里包含属性名称、属性类型、属性值等元数据信息。新增属性只需要插入一条记录不需要改表结构。EAV的代价是查询和代码层面的复杂度增加。查一个商品的完整信息需要聚合多行属性记录。参数校验不能靠字段类型硬编码要先读属性的元数据再做校验。缓存体系商品数据量大G级别读频率高日常持续加上大促脉冲对缓存体系的要求比一般系统高很多。本地缓存OHC。商品数据放JVM堆内会严重影响GC停顿。OHC把数据存在JVM堆外的直接内存中不参与垃圾回收扫描。需要自己处理序列化和反序列化每种商品数据类型有独立的Loader。中央缓存Redis。本地缓存未命中的请求走Redis。需要设计Key命名规则、过期策略、大Value拆分方案、防穿透和防击穿机制、热Key处理。预热与更新。本地缓存的预热策略、过期后的更新方式、运营修改数据后各层缓存的一致性处理。读接口设计商品系统被七八个业务系统调用每个调用方需要的字段不同。需要一种API设计方式让调用方声明自己需要哪些数据字段系统按需组装和返回。避免每个调用方定制一个接口导致接口数量爆炸也避免一个全量接口把大量无用数据传给调用方。高并发支撑数据库一主多从。读请求分散到多个从库。写操作走主库后主从之间存在同步延迟。运营刚修改了商品信息C端用户可能读到旧数据。主从延迟的处理需要专门的方案。大促流量隔离。大促开始的瞬间收藏夹的流量涌入商品详情页集中在少数热门商品上。如果和正常浏览走同一条链路正常请求会被挤压。需要在流量层面做隔离。数据迁移商品数据量在十几亿级别。旧表是PHP的宽表结构新表是EAV模型表结构完全不同。迁移要解决几个问题新旧表的字段映射关系双写方案迁移期间新老系统同时写保证数据一致十几亿数据的全量迁移不能影响线上服务灰度切换按比例把流量从旧系统切到新系统回滚方案灰度过程中发现问题能快速回退数据质检迁移完成后验证数据的完整性和准确性约束条件约束说明不能停服迁移和切换全程在线进行用户无感知数据零丢失十几亿条数据迁移后一条都不能少可回滚灰度过程中任何阶段发现问题能在分钟级别回退到旧系统新需求暂停重构期间不做新业务需求避免新老系统同时改造跨团队协调所有依赖商品数据的业务系统需要配合接入新接口验收标准性能指标标准大促峰值支撑32台机器扛住70万并发读请求P99响应时间读接口 ≤ 10ms缓存命中场景缓存命中率本地缓存 Redis整体命中率 ≥ 99%数据指标标准迁移完整性十几亿条数据零丢失双写期间一致性新旧系统数据对账差异为零灰度回滚时间≤ 5分钟稳定性指标标准系统可用性≥ 99.99%大促流量隔离大促期间对正常浏览请求零影响主从延迟处理运营修改后C端最迟1秒内读到最新数据风险评估风险项影响程度发生概率应对措施数据迁移过程中数据丢失高低全量对账加增量校验发现差异立即补偿双写导致新老系统数据不一致高中定时对账任务异常数据自动告警灰度切换后新系统性能不达标高中灰度比例从1%开始逐步放量每个阶段充分观察EAV模型查询性能不如宽表中中用缓存体系弥补热数据走本地缓存数据库查询频率极低OHC序列化反序列化的CPU开销中低提前做性能测试选择高效的序列化方案调用方切换新接口出现兼容性问题中中提供详细的接口文档安排专人对接每个调用方重构周期过长导致业务需求积压中高核心模块分批交付优先完成读服务切换术语表术语定义EAVEntity-Attribute-Value实体-属性-值。一种数据模型每个属性存储为表中的一行记录而非一列。适用于属性数量不固定、需要频繁新增的场景OHCOff-Heap Cache堆外缓存。将数据存储在JVM堆外的直接内存中不参与垃圾回收Loader缓存加载器。负责从数据源加载数据并写入缓存。商品系统中每种数据类型有独立的Loader双写迁移期间的数据写入策略。一次写操作同时写入新旧两套系统保证两边数据一致灰度按比例将线上流量从旧系统逐步切换到新系统的过程数据质检迁移完成后对比新旧系统数据、确认完全一致的验证过程宽表传统的数据库表设计方式所有字段作为列。属性固定时适用频繁加列时效率低小结技术重构和新建系统有一个根本区别新建系统的约束少方案可以自由发挥重构是在不影响存量业务的前提下替换底层实现约束条件决定了方案的复杂度上限。不能停服、数据不能丢、要能回滚、调用方无感切换这些约束叠加在一起技术方案的复杂度远超从零开始建一个新系统。这份文档把重构的背景、范围、目标、约束和验收标准写清楚了。后面的技术方案设计每一个选择都能在这份文档里找到对应的依据。EAV模型对应的是运营频繁新增属性的需求OHC堆外缓存对应的是商品数据量大到堆内放不下的现实流量隔离对应的是大促流量会冲击正常浏览的问题。技术方案不是凭空设计的它是从需求和约束条件里推导出来的。所有的代码都可以在知识星球里获取。这个专栏在星球里是免费的也可以接受无限次的咨询。后续新写的所有付费专栏在知识星球里都是免费的。我的星球是老码头的技术浮生录专栏发布在知乎欢迎订阅我的知乎名是:SamDeepThinking