电商大促活动核心策略「场景电商平台」
今天给大家普及一下电商大促活动核心策略「场景电商平台」相关知识，最近很多在问电商大促活动核心策略「场景电商平台」，希望能帮助到您。
采访嘉宾 | 金思宇、陈贞宝、胡强忠
大型电商系统并非一开始就具有完整设计的高可用特性，而是随着用户的不断增加与业务的快速增长逐步演进与完善的。当前高可用架构体系是互联网企业系统架构的基础要求，随着公司的业务发展，尤其是对于电商平台，每次发生稳定性故障带来的影响越来越大，提供稳定的服务，保证系统的高可用已经变成了整个技术团队需要面对的挑战。
基于此，我们深度采访了得物技术团队核心成员，探索他们在高可用架构上的实践、演进，深入了解大促备战是如何进行的，异地多活体系是如何建设的，全链路压测是怎么实践的等过程。
得物高可用架构演进和大多数互联网公司一样，得物目前也是采用主流的微服务架构来应对高可用的挑战。同样的，得物也是从大单体演进而来，经历了涵盖服务规划、服务拆分与合并、存储拆分等过程的微服务构建，集成并自研了基础开发框架及其脚手架、微服务通讯框架、微服务治理体系、微服务生命周期管理平台、微服务支撑基础设施、微服务安全设施，从大单体架构逐步演化成微服务架构。
在这一过程中，得物结合自己的业务背景，自研了符合自己特色的微服务架构支撑平台，比如网关、流量回放平台、预案平台、DAL、全链路压测平台、微服务发布平台等，并在分布式核心场景中沉淀自己的最佳实践设计，如服务的无状态化、服务的幂等、分布式锁、分布式事务、缓存失效的设计等。
回顾过去，得物高可用架构的整体演进与中国电商平台的业务架构的演进阶段比较相似，大致可以分为四个阶段。
第一阶段，得物早期，业务场景比较简单，功能不复杂，团队的规模也较小，使用的开发语言是 PHP，采用的是单体架构，在高可用的建设上也比较少，当时的主要目标是为了快速满足基础的交易需求。
第二阶段，随着业务规模的逐步增大，团队规模也越来越大，单体架构已经不能支撑业务的快速发展。得物开始做架构升级，语言从 PHP 转到了 Java，框架上使用的 SpringCloud 全家桶，业务域也进行了拆分，独立出了订单、出价、优惠、商家、商品几个应用，但这个阶段在服务治理上的建设还比较薄弱。
第三阶段，时间来到 2019 年下半年，随着业务发展，得物的交易系统亟待优化。一方面系统架构需要承载高并发的流量；另一方面，前期业务模型的设计对日渐复杂的业务需求支撑也不友好。于是得物启动了“五彩石项目”，按照领域驱动设计的思路，对得物交易体系重新规划和设计。只用了 3 个月的时间，就完成了整个系统的重构。新的架构形成新的 6 个核心域，对大数据量场景也做了分库分表，得物也开始逐步建设自己的监控体系、服务治理体系、预案系统，在基础设施中不断升级，来确保系统的高可用。
关联阅读：《业务百倍增长，得物如何在三个月完成交易平台重构？》
第四阶段，随着业务的进一步快速发展，业务规模越来越大，对交易系统的高可用、稳定性有了更苛刻的要求，一旦业务出现问题就会被快速放大。得物就在原有架构不断治理、升级的基础上，逐步启动了异地双活、容器化项目，让系统的高可用、可扩展、跨地域的容灾能力得到新的提升。
异地多活混合云架构体系建设前文提到，得物为了应对规模更大更复杂的业务情况，在高可用架构上做了异地多活、多机房部署等升级。
灾备架构选择目前常见的灾备架构有冷备、热备、双活、多活等几种。
冷备：只有主数据中心承担业务请求，备份数据中心定期同步主数据中心的数据或者在停机的情况下才开始对主数据中心的数据进行备份，当主数据中心挂掉，需要停机一段时间，手动拉起。从严格意义上讲，在当前对分布式系统高可用的要求下，冷备技术不能算真正的灾备技术，恢复时间过长，对业务影响较大。热备：只有主数据中心承担业务请求。主数据中心会实时向备份数据中心实时同步数据，当主数据中心挂掉，可以通过控制中心自动切换到备份数据中心，通过这种方式来实现高可用。还有一种概念是暖备，与热备架构类似，只不过不能够自动切换，需要人工介入。双活/多活：分为同城双活/多活，异地双活/多活，跨国多活。多个数据中心都会承担业务流量，不同的架构，在具体的落地细节上的复杂度也是相差较大。而且在不同的业务体系下，也会有不同的流量路由、机房部署方式。得物目前采用的是热备 双活的模式。热备成熟可靠，在存储层采用热备，发生故障情况下，可以快速切换到备份节点进行恢复，备份节点一般不对外提供服务，因此热备的资源利用率相对来讲比较低。得物双活基于双数据中心，两个数据中心同时对外提供服务。主数据中心承担主要的流量（一般为 70%），在发生故障时，将流量切换到另一个数据中心。双活资源利用率高，相对一个数据中心，更加地可靠，但是技术难度高，需要投入比较大的时间和人力成本进行技术建设，针对核心买家链路、微服务框架、微服务治理体系、微服务基础设施等做了相应的技术改造来实现。
按需配置多机房部署方案多机房部署模式一般分为同城、异地（跨城）、跨国几种，异地一般又分为远端城市和近端城市两种。一般情况在部署地区上有以下几个方面需要考虑：
两个机房部署在同一个城市，如果遇到城市级别的停电或者自然灾害，很容易出现两个机房都不可用的情况，达不到灾备的要求。两个机房部署在异地，那么相对同城来说，同时遇到自然灾害的概率要小一些。但是选择两个较远的城市还是选择两个较近的城市需要根据自己的业务场景、用户属性、数据同步延迟的要求以及实际需要解决的问题来决定的。选择两个比较远的城市，比如北京和深圳，那适合的业务场景是对用户以及中心数据进行分区，北方的用户访问北京的机房，南方的用户访问深圳的机房，比较适合本地生活服务类的业务场景。一个机房能够满足用户的实用需求，能够接受较长时间的数据同步延时。得物虽然是多机房部署，但不是这种模式，得物多机房部署的目的是可以对用户进行调度，当一个机房出现问题的时候，自动调度到另外一个机房，面临大流量或者促销活动的时候，通过流量调度来确保系统稳定。而且对于目前电商的业务模式，商品中心的数据需要确保两个机房的实时性，远端城市的部署方式是不适合的。
得物在综合技术、人力、业务复杂度、业务场景、时间成本等情况后 ，决定部署异地双活-近端城市的架构模式，后续会逐步演进发展到两地三中心、异地多活并且结合混合云的部署架构。
异地双活要解决的核心问题是“确保在极端情况下买家核心链路依然可用”，聚焦于买家链路的稳定性保障。
在故障发生时，能够将买家流量从一个数据中心调拨到另一个数据中心。从技术上，需要解决的一个难题就是如何确保买家跨数据中心调拨后，依然能够保证事务的一致性。这一点非常的困难。
举一个例子，比如用户订单数据，该数据写入主数据中心，但是当流量调拨到另一个双活数据中心时，用户依然能够在之前的事务上下文访问到正确的数据。这意味着用户订单相关数据必须保证两个机房都能够正常访问到，即数据是双向实时同步的。这里的数据会涉及到 MySQL、Redis、ES、HBase、MQ 等。同样的，这条链路的服务依赖需要隔离在同一个机房，服务路由需要就近路由避免跨机房路由，具体一点，假设数据都存储在 MySQL 的话，那么 DB 的数据就存在仅中心机房部署、中心写单元读部署、单元化部署（双边写并双边同步）。这就要求从基础设施到业务服务进行技术改造来实现。
基础设施的建设与改造
为了更好的支持异地多活，需要做一些基础设施，为双活奠定基础。首先需要做一个双活控制台，用于整体控制流量调拨并监控双活的运行状态。之后对基础设施进行技术改造以支持双活，在这里会涉及到网关 DLB 层、RPC 服务路由与注册中心、配置中心、MQ、TOC、Redis、MySQL、ES、HBase 等，还定制了数据复制中心（DRC）、数据巡检中心（DCP、DAL）来实现流量的调度。确保流量调度后，在新的数据中心能访问到正确数据，与之前事务上下文保持一致。
业务系统的改造
业务系统的改造专注于核心买家链路，并不是对所有的链路进行单元化，有些面向 B 端的应用系统甚至完全不用改造。不同的买家链路架构改造方式不同，比如库存链路的 DB 会完全采用中心化部署的方式；商品详情链路中商品库会采用中心写单元读模式；订单链路则完全采用单元化部署方式。
买家链路的改造需要从流量入口开始梳理，先进行单元化链路标记，接着梳理上下游，根据上下游是否需要单元化并进行改造，然后再梳理 MQ、Redis、MySQL、TOC 等中间件，确定相应的单元化方案。
双活的业务复杂度很高，对业务系统的影响也比较大，得物目前一共有 几十个业务系统涉及单元化改造。这么大的改造对测试同学的挑战也非常大，除了需要测试正常的业务场景，还需要验证双活场景下的流量调度是否正确。
高可用平台治理方案应对“天灾人祸”为了预防突发事件，高可用架构需要在设计时提前考虑很多的异常场景，即所谓的“天灾人祸”，比如机器宕机、集群节点宕机、网络抖动、网络攻击、下游服务异常、服务自身代码 bug、消息堆积等。
因此在做技术设计 &实现时要做好相应的防灾难设计与措施，比如通过机器冗余、集群故障失效转移、主从复制断点续传、业务隔离、性能压测、限流/降级、流量回放、变更控制等手段来保障系统的高可用。
这里，可以把“天灾人祸”的原因归为几类：
1）硬件问题，比如机器宕机、集群节点宕机、网络抖动、网络攻击，一般依赖于企业的基础设施和相应的支撑团队，这种情况一般通过灾备来解决和预防，得物通过自建异地双活来实现极端情况下硬件问题的故障防控。
2）软件问题，比如服务本身异常、下游服务异常、代码 bug、中间件异常等，这里是故障防控的重点，也是故障频发的部分。
软件问题具体可以归因为：（1）变更引起的故障；（2）流量和容量变化引起的故障；（3）依赖故障；（4）机房、网络等环境故障；（5）其它：比如幂等失效、分布式 Id 溢出导致的故障。得物一般是建立变更故障防控、大促故障防控、日常故障防控，对软件问题进行预防，从微服务本身、微服务上下游依赖、微服务依赖的技术环境三个部分梳理潜在问题，并提前做好相应预案，在问题发生时可以通过执行相应的预案来预防和进行故障的快速恢复。
3）人为问题，一般涉及到各种线上误操作，通过软件产品自身的完备性、成熟的技术规范、操作 SOP、管控措施、CheckList 来应对。
此外在得物的系统链路中都有自定义的限流、熔断手段，当埋点数据触发阈值时，会执行指定的异常处理方法，进行限流或者对下游进行熔断、甚至是通过业务开关直接对指定的业务进行降级。除了系统链路中自动的熔断、降级措施外，我们还在自研的预案平台中有配置的各种预案，当出现异常情况，会人工或基于埋点的自动执行，来实现优雅降级，确保系统的高可用。
全链路压测平台得物全链路压测平台于 2019 年完成，在 2020 年的 618 大促首次使用生产环境进行压测，经历了多次大促实战，目前已经能够非常顺滑的验证核心链路应对大促突增流量的稳定性。去年双十一和今年 618，在限流和预案开启或关闭的情况下，得物采用梯度递增、脉冲、稳定水位进行流量验证，分别经过 3 轮和 2 轮压测后，核心链路达到预期的压测目标，并且在大促当天所有核心链路均符合预期表现。
得物整个全链路压测平台建设及实施涵盖了以下内容：
1）由 Fusion 封装了压测接入 API，所有中间件必须按照统一规范接入和使用；
2）构建流量漏斗模型，即外部流量从网关入口开始，在每个调用链路上的变化比例，流量配比参考历史双十一峰值 QPS；
3）通过 Mock 模块处理外部依赖的调用链路；
4）流量标透并建立影子中间件，包括 MySQL、Redis、MonogoDB、Kafka、RocketMQ、HBase、ES、分布式锁等；
5）流量标透传并进行核心链路改造，基于 Fusion 框架识别测试流量标，进行相应改造；
6）建设测试环境和仿真环境；
7）构建测试用户和测试数据；
8）实施单机接口测试、单机混合链路测试、全链路压测。
得物的流量标方案，就是要解决数据隔离问题，压测产生的脏数据不能写入线上环境，通过中间件平台封装的 fusion 脚手架，在 RPC、Redis、DB、MQ、跨线程中透传压测标，如果识别是压测流量，产生的数据会写入到影子库，以此来实现数据的隔离，确保线上稳定，为全链路的压测奠定了基础。
在全链路压测平台的建设中，我们也逐步摸索出了得物特色的全链路压测流程。得物的全链路压测流程包括：系统摸高，限流演练，预案演练 。通过全链路压测，帮助发现系统性能瓶颈，限流配置，预案缺失等诸多问题。
大促备战经验分享大促是考验电商高可用平台的最好时机，首先作为前提的是，每一次大促都会有一个目标策划，确定本次大促的业务和技术目标，之后进行大促备战。得物大促备战主要涵盖三个部分：1）整体稳定性保障；2）业务需求交付；3）组织保障。大促需要以保障稳定性为前提，做好按时的业务需求交付，同时整个组织需要具备强悍的项目管理能力。
到目前为止，得物整个大促备战从整体保障、域内保障、组织保障都有清晰的 SOP 和系统化的沉淀。一般分为启动阶段、规划阶段、各域执行交付阶段、压测 &验收阶段、作战阶段、作战复盘阶段实施等等，大促备战是井井有条的。
首先，得物有专门的 PMO 组织来整体保障需求的流水线交付，保障大促需求的按质交付，下面介绍得物的稳定性保障，主要分为两大部分：大促整体备战；各业务域备战。
大促整体备战，顾名思义从全局视角关注突增流量对全域买家链路的影响，确保在大促当天这些核心买家链路应对突增流量的稳定性。因此，首先会先对业务目标进行拆解，之后确定各个链路的流量，做好链路的容量评估以及各个服务的扩缩容。之后会从链路的稳定性入手，梳理链路的架构风险、链路自身的风险，做好链路的预案和演练。
最后，通过几轮的压测，确保各个主要链路满足既定业务目标的流量。整体上会规划好大促推进的节奏，准备当天的大促备战。
各业务域备战，则是围绕着业务域的核心链路稳定性展开，这些链路一般是 P0 链路，规划需要做的事情，并在总体节奏上符合整体大促备战的节奏。
总的来说，链路稳定性保障一般会从几个部分来展开：1）架构大图、业务链路梳理；2）可见性建设；3）风险识别与架构治理；4）可控性建设。下面做简单描述：
架构大图，涵盖业务架构、IT 架构，关于架构图，大家都很熟悉了，推荐一个架构模型——C4，可以使用 C4 的 L1、L2 来清晰描述 IT 架构。接着是域用例梳理，通过域用例推导业务链路，业务链路一般是域用例的顶级服务交互。一个业务链路的入口，一般就是一个服务，这个服务由服务自身、服务上下游依赖关系、服务依赖的底层技术环境（如 RPC、DB、缓存、MQ、Job、JVM、容器、物理机等）三个部分构成。通过架构大图、业务链路梳理，就可以把域内系统和链路描述的比较清晰，使我们对构建的系统就有比较全局性的理解。这一步相当于我们稳定性建设的目标判断。可见性建设，得物聚焦在系统监控大盘、业务链路大盘、域业务监控大盘，以及系统和业务链路精准报警几个部分构成。通过可见性建设，我们可以实时观测系统、业务链路的运行状况，及时发现正在发生的风险以及潜在的风险。风险识别和架构治理，聚焦在链路风险识别并制定治理方案。有了可见性建设，我们可以从链路通讯的历史数据，主要围绕 P0 链路进行体系化的链路风险分析，一般涵盖架构变更风险、SLA 风险、超时和重试合理性风险、强弱依赖风险、链路调用风险、链路依赖技术环境风险、集群或拓扑风险等，之后针对识别的风险制定相应的架构治理方案。可控性建设，聚焦于风险识别与预案体系。风险识别，我们会通过精准告警、SLO 巡检来识别，SLO 巡检有相应的 CheckList 判断是否系统有故障发生，并查看风险发生链路对应的预案。在故障发生之后，可以对故障快速定位和止损，理想的目标是每一个故障都有相应的预案应对。实际中，并不是所有的故障都有预案，但可以根据历史故障和一些先验知识将故障进行归类，建立相应的预案。另外，预案要能方便执行和触发。得物在出价库存域大促稳定性保障方案，整体方案主要涵盖以下内容：大促作战手册：梳理大促前、大促进行时、大促结束时需要按照时间节点完成的作战事项；业务链路稳定性保障：容量评估、预案与演练、接口限流、流量治理、压测与复盘；架构治理：架构分析与核心链路梳理、慢链路治理、DB 治理、Redis 治理、JVM 治理、定时任务/数据回流与商家后端管控；资损防控：梳理资损点、应急工具、处理 SOP 等；应急工具：数据核对、出价应急处理等。经验分享，写在最后高可用是互联网企业系统架构的基础要求之一，从架构师所能解决的问题的能力划分，小到解决一个子域或模块，大到一个组织，要求的能力完全不同。
架构师需要具备准确的定义问题能力和解决高可用系统面临的技术挑战的能力，这要求架构师具备强的思考力以及解决问题的技术能力。构建高可用的系统一般要求架构师能够：1）具备合理的架构设计推导逻辑；2）理解业务并将业务挑战映射到技术挑战；3）从 0 到 1 构建一个满足业务目标的高可用系统；4）在快速业务迭代演进的过程中保持系统高可用。
首先，架构设计推导逻辑，是架构师最基本的要求，要求架构师能够从用户问题洞察出发，理解用户问题的解决路径，定义商业流程及组织角色，构建出系统业务架构；接着，从业务架构推导 IT 架构，即应用架构、技术架构和数据架构。这就要求架构师具备架构分析、设计的相应方法论、工具。比如 TOGAF 企业架构方法论、DDD 方法论、C4 架构模型、UML 建模工具箱、四色模型等等，形成一套自己实战的方法论。
第二，理解业务并将业务挑战映射到技术挑战，就要求架构师在业务理解下，能够设计合理的架构方案并引导架构活动实施。架构方案要从明确的业务或技术目标展开并对目标合理性进行一定的干预，基于当前的商业环境、企业技术基础设施、企业技术文化，在有限资源和成本约束下，通过合理的架构活动满足目标用户需求，最终确保技术方案实施能够实现商业价值。架构师不是仅仅解决用什么技术、什么架构去实现的问题，而是要考虑业务的方向，从技术角度如何合理的实现，为企业业务支撑带来更高的 ROI。
最后，架构师需要具备较强的微服务架构及其支撑的基础设施相应储备，微服务架构一般包含服务拆分与合并、微服务开发框架、微服务治理体系、微服务生命管理平台、微服务支撑基础设施、微服务安全体系等等能力。整体知识非常的庞大，当架构师对微服务架构有深入理解和支撑基础设施较为广度及深度的知识储备，并且通过实践进行验证积累实践经验，就能够从高可用目标出发，进行合理技术选型，实现服务规划、构建和治理，使得服务构建和之后的演进都能满足高可用目标。
嘉宾介绍金思宇：得物技术 Leader，毕业于东北大学，先后在中兴通讯、阿里巴巴、唯品会任职，并有 2 次创业经验。对电商及上下游有比较丰富的开发及业务架构经验。19 年加入得物 App，目前主要负责交易平台及中间件平台，带领团队支撑得物 App 交易域的业务需求，完善业务基础能力；同时负责中间件团队的管理及技术演进规划。
陈贞宝：得物出价 &库存 Leader，曾在 Sybase、厦门锐特、阿里巴巴任职，有 5 年创业经历。曾负责 2 次 S 级大促以及多次的域内稳定性保障，在架构设计与治理、大促稳定性保障有较多实战经验和体系化思路。21 年加入得物 App，目前主要负责得物出价 &库存团队，带领团队完成技术规划、业务交付、稳定性保障等工作。
胡强忠：得物业务架构师，曾在中国航信的不同分支机构任职，有过一次创业经验。对 OTA、电商行业有较丰富的开发、架构经验。19 年加入得物 APP，目前主要负责交易平台的架构演进规划、业务领域建模、稳定性治理等工作。
