重构助力业务腾飞：一个年增长率10倍的亿级电商平台的技术故事
引言
这篇文章，将聊一聊：在业绩年增10倍的狂飙式增长下（年GMV5亿到年50亿），一个累计超过百亿GMV的电商平台，是如何进行从0到1的技术重构实践的。
主要分享：
- 为什么要进行重构？
- 重构如何启动和实施？
- 在实践中，我们遇到了哪些挑战和坑点？
欢迎一起交流、探讨和学习。
系统重构后的核心指标数据
先来看一下数据，这是我们重构后，在系统核心指标上所取得的业务结果数据：
1.系统性能提升，助力业绩狂飙：平台最高支撑50万+同时在线用户的瞬时秒杀抢购，全链路系统性能高速提升，从5万QPS到最高32万QPS，从月GMV1亿+到突破10亿+大关。
2.系统架构改造，手枪换大炮：经过单体架构到微服务架构的改造，系统架构能力得以显著提升，技术团队不再受制于技术债务，技术问题不再拖累业务发展。
3.搭建业务中台，实现高效交付：通过搭建电商核心领域的业务中台，实现了小前台大中台的架构体系，从而提升了业务功能的高效交付能力。
4.技术能力开源，回馈开源社区：向全球顶级IT开源社区贡献了一个名为 L2Cache 的高并发场景下的分布式二级缓存框架，帮助解决缓存雪崩、缓存穿透、热点缓存等问题。取之开源，回之开源。迄今为止，已累积贡献了四个技术开源项目（Github仓库地址）。
https://github.com/weeget-tech/l2cache
扫描二维码关注公众号，回复： 15054120 查看本文章
一、背景
为什么要做重构?
2018年至2019年，在业务起步阶段，为了快速验证产品可行性，技术上选择了单体架构，满足了产品快速迭代上线的诉求。随着业务发展，各种新的功能越来越丰富，系统也变得越发庞大、臃肿、复杂，到处都是牵一发而动全身的代码。每当大促活动时，只能通过花钱对各种基础设施进行升配，才能勉强抗住瞬间流量对系统的冲击。
2020年初，疫情伊始，受疫情影响，进一步加速了线上购物趋势，云货优选的用户量和业务量呈爆发式增长。与此同时，系统面临的考验也越来越严峻，每逢大促系统必宕机，花钱升配都已无济于事，旧系统的底层架构设计极大地影响了业务的高速发展。
随着产研团队人员规模的不断扩大（最高峰时，团队人数近300人），多人协作效率问题开始凸显，例如代码分支和功能开发常常发生冲突。此外，单体架构的痛点也日益显著，技术已成为业务增长的最大瓶颈。
重构要解决哪些问题？
在重构前，当时系统所面临的状况，主要有以下几点：
1.产品交付效率低，线上经常出问题：产品交付效率低，常常发生延期事件。代码合并冲突、需求上线等待和线上慢SQL等问题时有发生，这导致“业务等待技术”的现象时常出现。而上线后，又经常发生技术性的“擦屁股”事件，各种产品功能Bug问题不断出现。
2.跨团队协作效率低，沟通成本高：受制于老旧的技术框架和历史架构设计的不足，当前难以满足在多个团队协同下，以高效的方式交付产品功能的要求。
3.代码有性能问题，系统经常宕机：由于代码业务逻辑的耦合程度高，这使得代码的可维护性和阅读性都非常差。一个小的错误可能会对整个系统造成致命的破坏，而且系统的性能也存在着极大的瓶颈问题，这种情况下，技术同学的信心受到了严重的打击。
4.技术债务重，越积越多：随着业务的高速增长，需求迭代速度加快，团队人员也在迅速扩张。然而，由于过去技术规范、技术框架、系统架构等历史问题的影响，团队积累了大量技术债务，难以应对快速变化的市场需求。
以上几个痛点，是单体架构系统发展到一定阶段后，所面临的典型问题，也是我们的核心突破点。
如何解决这些问题？
为彻底解决上述痛点问题，所以，最终我们选择了“重构”。
为什么选择整体重构，而不是局部优化？
当时，业务高速增长，技术问题不断浮现。我们发现，仅靠优化已有系统，无法从根本上解决问题。因此，我们做出了艰难的决策，选择了“重构”来应对这些痛点问题。
选择抛开历史包袱，重新出发，我们认为这是当时最好的选择。
接下来，我们将详细介绍重构的实践过程
二、系统重构的实践过程
当时业务正在狂飙式增长发展，但系统频繁宕机。既然决策已定，“重构”势在必行，那到底如何实现车在高速过程中不停车换轮胎呢？
这里分享一下我们在系统重构时实践过程，旨在帮助有类似重构需求的同学，特别是对重构的1号位技术负责人，希望能给大家提供一些思路参考。
下面我们将针对每一步进行详细介绍。
第一步：搭班子
定一名重构技术负责人
系统重构是一项非常重要的任务，首先，得有一名经验丰富、技术过硬的技术负责人来领导和指导整个过程。这是第一步，也是最为关键的一步。
为什么？因为系统重构的相关事项，均由他来做决策。
如选什么样的人？选什么样的技术？做什么？不做什么？如何做？等，这些决策都决定着系统重构的走向和成功率。
当时重构采取的决策是：新成立一个部门（架构部），新招聘部分人员。在职能上，与业务交付开发部门区分开，只专注于重构。
为什么要新成立一个部门？
1.现有团队中，较少人有中大型电商系统的完整重构经验。
2.现有团队成员，经历过较多的旧系统痛点，所以心有顾忌，无法彻底大刀阔斧，但新部门的人没有历史包袱。
3.在职能上区分开，且专注后，重构需求不会与业务需求产生优先级冲突，导致重构需求优先级滞后。
Tips：如果你也碰到了和我们一样的场景，重构势在必行的话，建议最好把“重构团队”，从原业务交付开发团队中剥离出来，聚焦、专注。
第二步：确定技术框架和规范
1.确定架构选型
为什么选择了“微服务架构”？
1.高可扩展性：微服务架构将整个系统拆分成多个小型服务，每个服务都是独立的，可以独立部署、独立扩容、独立维护，方便系统的水平扩展。
2.更高的可靠性和容错性：微服务架构下，一个服务的故障不会影响整个系统，只会影响到该服务的功能。因此，当某个服务出现故障时，不会导致整个系统崩溃，降低了系统的风险和损失。
3.更好的团队协作：每个服务都可以由不同的团队开发和维护，团队之间的耦合度降低，协作更加灵活高效。
4.更好的灵活性：微服务架构下，可以根据业务需求，随时新增、修改、删除服务，系统更具有灵活性。
2.确定技术栈、框架
从单体架构升级到微服务架构，技术选型是第一步，我们的选择是 Spring Cloud Alibaba。
为什么选择了 Spring Cloud Alibaba？
Spring Cloud Alibaba 是一个开源的、基于 Spring Cloud 的微服务解决方案，具体理由如下：
1.完善的微服务体系，拥有标准化结构：包括服务注册与发现、负载均衡、配置中心、分布式事务等。这些组件都可以快速地构建出稳定可靠的微服务系统。
2.高性能，稳定性好：Spring Cloud Alibaba 的底层技术采用了阿里巴巴的 Nacos 服务注册中心和 Sentinel 流量控制组件，这些组件具有出色的性能和稳定性，能够支持大规模的微服务应用场景。
3.广泛的生态系统，社区活跃度高：Spring Cloud Alibaba 的生态系统非常广泛，包括了许多常用的开源组件，如 Spring Boot、Dubbo、RocketMQ 等，这些组件能够与 Spring Cloud Alibaba 紧密集成，形成完整的微服务解决方案。
4.方便集成，易部署：Spring Cloud Alibaba 提供了一系列方便的工具和插件，可以方便地集成到已有的开发环境中，支持容器化部署和自动化运维，能够快速实现微服务的开发和部署。
综上所述，选择 Spring Cloud Alibaba 可以帮助我们更快速、更便捷地构建出稳定可靠的微服务系统，并且能够满足大规模应用场景的需求。
3.制定开发规范
在技术升级的过程中，制定开发规范是必要的一环，它是整个团队都遵循的开发准则和标准。它有助于确保代码的质量、可维护性和可扩展性，提高开发效率和降低维护成本。
以下是我们制定开发规范时的核心内容：
- 定义编码规范：包括接口规范、代码格式、命名规范、注释要求、框架规范、架构规范等。
- 制定代码审查流程：包括代码审查的频率、参与者、审查的内容等。
- 定义测试要求：包括测试类型、测试覆盖率、测试工具等。
- 定义文档要求：包括文档类型、文档内容、文档格式等。
- 制定版本控制流程：包括分支策略、版本号管理、提交信息格式、代码合并流程等。
- 制定部署流程：包括自动化构建、自动化部署等。
4.快速落地微服务框架
为了快速让微服务架构落地，我们提前通过了一个MVP的业务场景（搜索商品场景），把整体框架、技术规范、单元测试、集成测试、验收测试、接口契约测试，以及 DevOps 等的新研发流程全部跑通。
第三步：确定重构范围
重构范围的确定是非常关键的，在进行重构的过程中，它将直接影响到重构的成败，这涉及到重构复杂度、重构时长等。
因此，我们需要特别慎重地考虑重构范围是哪些，重构边界在哪里。
然而，我们却选择了挑战性最高的“核心主链路”，作为重构的第一个突破口。
这里的“核心主链路”，主要功能包含有：登录页，电商平台首页，商品列表页，商品详情页，优惠券使用流程，订单确认页，下单流程，支付流程，退款功能，购物车功能。
为什么选择了 “核心主链路” ？
- 团队信心问题：由于之前经历过重构失败的挫折，技术团队对于新一轮的重构缺乏信心。
- 业务增长的最大瓶颈：在业务高速增长过程中，频繁的系统宕机和技术问题，成为了业务增长的最大瓶颈。
- 重构的价值和意义：仅仅对一些小问题进行优化和改善，虽然可以在短期内实现一些小的突破，但是对于底层架构设计问题，这种方式的价值不是很大。
最终，为了展现技术团队的信心和决心，重振团队士气，我们选择了性能瓶颈最大、重构难度最高的“核心主链路”作为突破口。
这不仅是为了解决业务增长中的瓶颈问题，也是为了展示团队的实力和决心，向外界传递我们必胜的信念。
第四步：梳理原业务逻辑
为什么要梳理原业务逻辑？
1.每一家电商平台的产品业务玩法都有其独特之处，不存在一种适用于所有平台、完全相同的业务逻辑。
2.对于一个正在高速增长的业务来说，业务不能中断，更不能受到任何影响，要确保业务流程重构后的正确性。
3.这次重构的核心，主要在于底层架构的重新设计和搭建，而原业务逻辑是不变的。
因此，在新团队正式开始编写代码之前，先对原业务逻辑进行梳理和熟悉，是一个非常关键、重要且必要的步骤。
具体该如何进行梳理？
主要分享几个实用经验点：
1.建议核心业务安排2人共同梳理，以提高业务逻辑的理解准确性
针对特定业务，开发人员需要聚焦，并深入梳理具体的业务细节。在确定了重构范围为“核心主链路”后，例如：2人负责梳理【订单相关业务】，2人负责梳理【商品相关业务】。
为何安排2人？保证业务梳理的准确性。
这样的分工，不仅能够提高梳理效率，也能够做一次纠偏，更好地保证业务逻辑层面上的准确性。
2.建议最好要有一个产品同学加入团队，让团队拥有业务全局视角
产品经理的职责是聚焦全局业务，负责梳理整个产品的业务全貌，并与团队成员快速沟通，帮助团队了解全局业务。
从产品的角度出发，保证团队交付的结果符合业务期望。
3.梳理业务逻辑时，不是非得要阅读旧代码
非所有的业务逻辑都需要通过查看旧代码来了解。只要业务场景清晰，我们可以直接基于产品业务逻辑编写全新的代码，而不必被旧代码所束缚。
这种方式不会受到历史代码的引导和干扰，也能够更快地摆脱历史包袱。
第五步：新系统架构设计
系统架构规划设计
我们基于对现状的了解，和对未来的规划，将“核心主链路”划分为以下的电商基础领域，其中“用户域、订单域、商品域”，是本次重构的最核心领域范围。
整体系统架构图设计
第六步：确定重构目标
确定长期重构目标
长期目标是：通过系统重构来提高全平台的性能和可靠性，以确保平台能够支撑未来一年的业务发展。
确定短期的重构目标
在确定长期目标之后，则要以长期目标为基线，制定短期的重构目标，并制定项目计划，小步快跑。
短期目标是：系统不再宕机，业务不再中断，技术不再拖后腿。
第七步：重构计划落地
这是一个项目的管理过程，网上资料很多，这里不过多赘述。
主要分享几个实用经验点：
1.该知道的人都知道了吗？
这是最关键的一步，大部分的问题都出在“有人不知道”，也就是相关方对这件事情不知情，如改动范围或时间节奏。
这里指的相关方，首先是技术和流程上的相关方，还有业务部门和用户的相关方，以及公司管理层等。
2.脑子里排练过吗？
几乎所有的意外，都会跟准备不充分有关系，如果我们没有提前做好计划，或者某些环节被忽略、没有预留出足够的时间等等情况下，那就很有可能在整个项目推进的过程中出了问题。所以，尽可能在脑海中把整个计划过程演一遍。
比如项目要有明确的项目计划会，计划会列明每一步做什么，先后顺序和负责人，关键里程碑节点，需要的资源和支持，以及可能的异常情况和预案。
在项目风险管理方面，分享一句经验总结口诀：“目标统一，责任到人，承诺到位”，即目标大家都统一理解清晰了吗？每一项任务，是否都有了一位负责人？对每一个任务，负责人是否给出了承诺的完成时间？
3.万一出意外有退路吗？
凡事都应当往好的方向努力，往坏的方向打算。在充分准备的同时，也要准备好出现意外时的预案，比如回滚方案。
三、重构过程中踩过的坑
1.在重构下单流程的过程中，若业务迭代也涉及到下单流程，此时如何处理？
这是一个非常关键的决策过程，需要考虑到各种因素并做出权衡取舍。本质上，这是一个优先级的问题。在当时系统频繁宕机的紧急情况下，系统重构显然更为重要。
因此，我们制定了一项策略，即在重构过程中，暂停了所有下单流程相关的业务需求，以便优先保障重构工作的进行。
这种策略虽然可能会影响到一些业务方的需求，但是它确保了系统的稳定性和可靠性，为后续的业务发展奠定了基础。
此刻的“慢”，是为了未来的“快”。
2.测试过程中，暴露的历史问题，如何处理？
对于历史问题，我们的策略是：将军赶路不追小兔。除了致命问题外，其余问题在重构过程中一般不予处理。
一方面，时间和人力资源有限，如果处理所有历史问题，将会导致重构工作无法如期完成交付。另一方面，历史问题已经存在于线上系统中，而且并未造成致命后果，因此不必急于一时去处理。
因此，在重构过程中，需要聚焦于重构本身和处理关键问题，以确保重构的顺利进行。
3.上线过程中，如何平滑地切换到新系统？
需要注意几个关键点：
-
上线预演：在正式上线前，进行多次的模拟演练，包括环境准备、数据迁移、系统配置等所有步骤，以确保上线过程的顺利性和可重复性。
-
开关设计：在上线后，通过重构开关来切换到新系统，并做好随时切换到旧系统的准备。
-
回滚设计：在上线前，准备好回滚计划，以应对可能出现的上线问题。在上线后立即进行监控，一旦发现问题，立即执行回滚计划，确保系统稳定。
-
监控和日志：在上线前，准备好监控和日志系统，确保能够及时发现和解决上线问题。
-
预留冗余资源：在上线前，预留一定的冗余资源，如服务器、带宽、数据库连接数等，以确保系统上线后，在高并发和异常情况下仍能正常运行。
四、重构经验总结
团队维度
我们深刻理解到 “选择对的人，做对的事情，把事情做对” 这三个要素的重要性。
1.选择对的人，这是前提
要打胜仗，不仅仅取决于团队成员的能力，更重要的是成员之间的合作和默契。因此，要选择那些有能力、有合作意识、有共同目标的人。
比如，我们在选择架构部核心成员时，招聘的是技能过硬、经验丰富、责任感强、踏实肯干的人。
2.做对的事情，这是方向
如果事情本身不对，即使对的人也达不到你想要的结果。因为在错误的方向努力，只会离目标越来越远。
比如，我们在选择重构突破口时，选择的不是整体系统，或小打小闹的业务场景。
3.把事情做对，这是方法和结果
如果工作方法不正确，即使选对了人，做对了事，也还是达不到既定的目标。
比如，我们在确定重构范围时，采取“小步快跑”的策略，而不是一步到位。
再比如，我们在处理历史问题时，采取“将军赶路不住小兔”的策略，而不是眉毛胡子一把抓。
本质上，这三个要素都是在做选择，选择什么人、什么事、什么方法。所以，这三个要素缺一不可，任何一个要素缺失都很难做成事。
因此，在做选择时，需要特别注意：选择不是既要又要，而是聚焦。
选择不对，努力白费。
技术维度
系统重构，本质上是通过一系列重构手段，使系统从混乱变得有序。
混乱意味着复杂度高
复杂度高的特点是：难以理解、难以维护、易出故障，随着业务迭代，复杂度会增加。对于软件而言，复杂度可分为两个方面：业务复杂度和技术复杂度。尤其当两者混杂在一起时，复杂度和开发难度是递增的。
所以，在做架构设计时，难在哪？难在控制复杂度上。
虽然复杂难以化解，但是复杂可以被控制，复杂只要被控制就不可怕。所以，要提前确认清楚重构范围和边界。
如何有效控制复杂度？
分享几个设计原则：
- 隔离设计：清晰结构。基于关注点分离原则，隔离业务逻辑和技术实现，保证整个系统具有清晰的结构。
- 分而治之：控制规模。将庞大的系统分解为多个小的组成部分，可以更有效地解决问题空间中的细粒度问题。
- 抽象设计：响应变化。应对变化最好的方式是，将变化限定在可控的范围内，我们可以通过设计模式等抽象方法将不同维度和粒度的变化隔离开来。当变化发生时，只需作出最小的适应性改动即可。
在软件开发过程中，平时就要注重良好的设计和实现，以避免不必要的技术债，并且及时进行重构，保证系统的健康迭代。
最后
重构，从来都不只是一个技术活。
从0到1的系统重构，不仅仅是一次技术架构的升级，更是一次团队组织的自我重塑。
文档资料
技术破局，业绩狂飙十倍：亿级电商平台重构大揭秘（文章首发微信公众号：微革技术团队）
推荐阅读
系列分享
------------------------------------------------------
------------------------------------------------------
关于我（个人域名，更多我的信息）
期望和大家 一起学习，一起成长，共勉，O(∩_∩)O谢谢
如果你有任何建议，或想学习的知识，可与我一起讨论交流
欢迎交流问题，可加个人QQ 469580884，
或者，加我的群号 751925591，一起探讨交流问题
不讲虚的，只做实干家
Talk is cheap，show me the code