静态化到全动态化：架构演进的真正驱动力是需求变化的速度

京东商品详情页架构经历了四代演进，每一次演进都不是为了追求更高的技术指标，而是被”业务需求变化的速度”倒逼出来的。架构1.0（IIS+C#+SqlServer直接查库、扛不住加memcached）在需求变化慢的早期阶段够用，问题是依赖服务抖动会直接传导成性能抖动。架构2.0引入按商品维度生成整页静态HTML（MQ通知变更→Worker生成HTML→rsync同步→Nginx输出），解决了直接查库的问题，但代价是任何一个跨商品的公共维度（比如分类、面包屑）变了，所有相关商品都要整页重刷，而且rsync会随商品数量增长成为瓶颈，页面需求变更也只能靠JS硬改。架构2.1把”生成整页”改成”按维度生成HTML片段、用Nginx SSI合并输出”，并用商品尾号路由分散容量压力，缓解了2.0的部分问题，但换来的是碎片文件暴增（导致rsync无法用、甚至要半夜删文件）、机械盘做SSI合并在高并发下性能差、模板变更要数天才能刷完数亿商品。最终架构3.0彻底放弃”预先生成静态页面”这个思路，转向全动态渲染：把数据异构为原子化数据存入JIMDB，按维度聚合后由Nginx+Lua实时取数据渲染模板输出——这一代要解决的已经不是”扛不扛得住流量”，而是”业务方要垂直化、模块化、个性化、AB测试的需求能不能被快速响应”。这四代演进共同揭示的规律是：静态化方案的每一次改良（缩小重刷范围、分片路由）都只能延缓”重刷代价”这个根本矛盾，无法根除它；真正的解法是承认”预先生成、按需失效”这条路线本身和”需求快速多变”这个业务现实是结构性冲突的，必须转向”数据预先备好、渲染实时发生”的动态化架构。

结构图：

flowchart TB
    A["架构1.0：直接查库+memcached\n痛点：依赖服务抖动直接传导"] --> B["架构2.0：整页静态化(MQ+Worker+rsync+Nginx)\n痛点：任一公共维度变更需全量重刷\nrsync随商品量增长成瓶颈"]
    B --> C["架构2.1：按维度生成HTML片段+SSI合并\n尾号路由分散容量\n痛点：碎片文件暴增导致rsync失效\n机械盘SSI合并高并发性能差\n模板变更需数天刷完数亿商品"]
    C --> D["架构3.0：全动态化\n数据异构(原子化)→聚合→JIMDB存储\nNginx+Lua实时渲染\n目标：快速响应垂直化/模块化/个性化/AB测试需求"]