电商系统架构发展历程,每个阶段的业务状况、技术挑战和技术体系的应对策略。
业务起步&快速迭代试错
架构:从NET技术栈到Java栈。
在业务起步阶段对技术的要求:
考虑电商系统的可扩展性,研发技术栈逐步从 .NET 体系变成 Java 体系。
业务验证可行&快速发展 架构:完成按领域划分的微服拆分、各服务独立承接业务需求
随着电商业务迅猛发展,技术人员的增加,到 2016 年技术团队已经有了上百人。单体架构之痛扑来,一个前台商城 git 项目就近 30 个 Maven 的子项目,遇上需求并行开发,经常出现代码的合并冲突、需求上线等待、线上慢 SQL 等问题,整个系统的开发效率和系统稳定性都变差:
系统支撑面临巨大的挑战,系统架构必须升级进化。把原单一系统拆成多个高内聚,低耦合中心化系统。即用户中心、商品中心、订单中心、促销中心、优惠券中心、商家中心,每个独立的系统可以独立设计、独立接需求、独立发布。
此间,在技术上完成支撑电商百万级商品系统、订单系统、优惠券系统构建,并完成了应用的全部上云 、自动化测试平台构建。
电商系统统一
架构:完成电商主数据建设,API读写切换,业务逻辑复杂化,订单量增长迅速
电商发展的速度实在太快了,公司基于发展战略决定搭建电商中台:
为此:
最终选择“以数据归一为基础,提供标准化中台服务,从下层向上层逐个系统整合”的方案:
数据是公司的核心资产,任何系统尤其是交易类系统,数据更是重中之重。主数据建设:
交易流程最重要数据集中在商家、商品、订单、促销活动4个领域,需结合公司交易业务现状,分别对这4个领域主数据进行抽象,统一建模,尽可能适配大多交易场景。订单主数据核心数据模型结构:
完成统一的数据模型后,下一步就要将现有异构型数据导入主数据库,采用读取数据库 Binlog(MySQL、SQL Server)进行数据加工的方式完成初期的数据同步导入,也是对业务侵入最小、最快的实现方案。
完成主数据建设,下一步开始基于主数据的 API 标准化建设,API 可看做系统的神经,高质量的 API 可以串联起一个优质的系统,统一了 API 在一定程度上也就实现了系统的收口。
为此,遵循单一职责原则,按领域区分,明确边界,做到所有底层 API 功能原子化,便于上游使用者组装 API 完成业务逻辑,同时统一 API 参数结构和响应结构,统一错误码,基于 API 网关统一发布、调用,API 的数据统计监控、降级、限流实现统一管控。
有标准化 API,自然要让业务方进行使用才能体现API价值,为防止步子迈太大,也按业务重要性及量级,采用读写分阶段的方案逐个业务进行调用切换,看似很合理步骤,实际执行过程也暴露很多问题:
这时要从对方角度出发做取舍。即在标准 API 上增加一层适配层,用于新老协议转换,让业务方只需切换域名和请求的 URL 即可,其他逻辑不变,最大限度做到对业务方友好:
完成 API 读写切换后,基于主数据的功能基本完成聚合,此时需将通用功能进行系统化统一,如统一的商家管理后台、统一的运营后台、统一的 C 端交易体验等,系统层级的统一整合是为给使用者一个统一操作界面,体现平台专业性。
系统整合过程中,采用“共性沉淀,差异取舍”原则,对通用能力如:商品发布、订单列表等功能,抽象出通用能力,提供统一的单元化操作界面,满足各业务方使用。
对业务方特有功能,建议业务方实现,而对那些目前还无法形成通用能力但未来有可能作为通用能力的功能,按 MVP 原则,随业务迭代不断实现功能沉淀。
在整个系统整合过程,必然出现在整合原有系统功能的同时又有新需求加入。对此,采用新老系统同步开发,看似增加成本,其实对新系统整合有好处:
在完成绝大部分的系统整合工作后,电商核心交易链路已经可跑通,并在线上经历长时间验证,从商家入驻、商品发布、商品展示、下单、支付、履约、售后,到最终结算,期间遇到问题也在一一化解。在这个阶段完成:
多品类、多业务 架构:平台化架构,服务编排化,业务配置化、数据可视化,流程标准化等
电商业务中台继续向业务“逼近”,系统抽象和建设难度指数型增加,出现一系列问题:
综上所述,电商业务中台在建设过程中抽象业务线的共性能力以及共性能力的复用性设计与实现尤其重要,业务中台要做到能力复用和灵活多变才能让中台建设在企业的发展过程中起到降本增效的效果。系统架构必须升级,进入平台化架构阶段。
平台化架构:基础能力跟每个业务方的特性业务拆分,把业务和业务之间的逻辑进行隔离。
平台化最核心是业务抽象建模和系统架构开放性:
适合之家电商平台的解决方案:通过领域驱动建模抽象出电商业务中台多业务线的共性能力并预留扩展点,然后利用服务编排对共性能力进行组合。
原理图:
每个在电商业务中台运行的业务可以理解为:业务身份 + 业务流程 + 规则,业务流程通过流程服务编排来实现,扩展点通过扩展点机制来实现。
整个交易流程中 B 端的商家入驻、商品发布相对通用,不同的业务的主要流程差别体现在订单收单前以及支付后的订单履约,这些流程都需定制开发,为此整个解决方案核心在于订单平台化架构设计。
如图,整个订单平台化架构分为四层:
整个订单平台化架构升级实践过程总结:
业务平台在对各业务同时提供服务时,要能区分每次业务服务请求的业务身份要素,以便提供差异化个性化的服务;因此要对企业各业务的身份和特征进行建模和区分,其产出即为业务身份。业务身份具有唯一性。
有了业务身份,业务中台就可针对抽象这业务流程和业务规则,并基于业务身份实现服务路由、业务监控。业务身份类似 SaaS 系统租户,不同业务方在中台通过业务身份进行数据权限隔离,保证各业务的运营只能看见自己业务部分的数据。
如汽车电商领域,业务身份通过人、货、场三维抽象:
根据这些维度确定了唯一的业务身份后,每笔交易的业务流程就确定下来了。
电商业务中台整体采用微服务架构、将整个电商系统拆分为商家中心、用户中心、商品中心、促销中心、交易中心、履约中心、售后中心。每个中心在逻辑上分成:
有两种常见做法:
服务拆分好处无需赘述,但要实现业务价值,不是看单个服务能力,而要协调所有服务保证企业端到端业务流程的成功。业务中台是企业业务的集成平台,集成技术须松散地耦合组成流程的应用程序和资源,否则流程逻辑将被硬编码到特定的技术平台中,更改可能代价高昂,违背业务流程复用。
服务编排领域参考:
都存在某些程度不足,无法应用到电商业务中台服务编排,最终选用 Apache Camel 为服务编排的底层引擎进行二开。
Apache Camel 诞生 2007,2009 成为 Apache 顶级项目更名 Apache Camel,目前最新版本3.0。Apache Camel 的优点在于在发布后十多年的时间里,已经拥有三百多种扩展组件;扩展机制也极其方便和灵活;通过开箱即可用的最佳实践来解决应用集成问题;它基于事件驱动的架构,有着良好的性能和吞吐量。
简单的服务流程编排样例:
业务中台使用服务编排技术:
SPI,Java 提供的一套用来加载和运行第三方扩展的接口实现类的机制,一般用在组件替换和框架扩展的场景。SPI 将服务接口与服务实现分离以解耦、提升应用程序可扩展性。程序设计中,模块之间采用面向接口编程而不做具体实现类引用,通过动态加载实现类达到应用程序插件化。
COLA 框架一种应用架构的扩展点框架。COLA框架扩展是通过注解,Extension 扩展注解里面使用用例(useCase)、业务(bizId)、场景(scenario)三个属性标识身份。使用 COLA 框架的扩展点可以在代码层面支持不同业务身份的逻辑隔离,因为不同逻辑分散在不同实现类,符合开闭原则。
COLA 框架在应用 Spring 上下文初始化完毕阶段,开始扫描带有 Extension 注解的 bean 进行扩展点注册,以 Map 的结构存储,Key 是 useCase、bizId、scenario 的字符串拼接,value 是该 bean。
运行时,通过业务身份定位扩展点实现类,然后执行扩展点实现的逻辑。定位扩展点支持三层路由,先按 useCase+bizId+scenario 找扩展点实现,如果没有则按照 useCase+bizId+scenario 默认值查找,如果还未找到则根据 useCase+bizId 默认值 +scenario 默认值查找:
简单业务场景,对应用系统的高扩展性、业务隔离的非功能性要求不多。但随同一应用系统支撑的业务变多、业务场景复杂,在架构层需提供统一的扩展解决方案,将变化的业务规则固化下来,这不仅有助统一技术规范,还能减少硬编码的IF-ELSE、策略模式等因开发人员水平不一致带来的理解上复杂度、规范上的一致性。
通过扩展点机制,业务中台就可从业务身份和框架层面实现对不同业务管理,像 SaaS 管理租户一样管理业务,不同业务身份在不同场景下对预定义的扩展点进行扩展。阿里巴巴的业务中台也正是基于扩展点的思想,实现的核心业务逻辑和技术细节的分离和解耦,共享事业部才能对集团内几百条业务线进行支撑的。
在验证功能后对电商交易系统的的场景进行分类,首选用户感知度小、即使出问题也对用户影响最小的节点进行重构试用,如未支付订单超时关闭、用户取消订单。
用户取消订单为例,在修改前各业务的用户取消订单的逻辑为修改订单状态为已取消状态然后执行同一个流程,流程的执行顺序为硬编码,伪代码如图:
修改后根据各业务的特性的进行精细编排,如二手车业务没有使用优惠券的场景,就不需要这环节;积分这通用能力,扩展的是万里通积分。伪代码如:
旅行家业务线的的酒店、机票业务无传统的商品库存的概念,那么就不再需要还商品库存的操作,而是抽象一个新的通用能力:取消供应商订单,并预置了取消酒店供应商订单的扩展以及取消机票供应商订单 2 个扩展点。伪代码如图:
整个系统的应用效果明显,主要体现在性能、人效提升:
平台化架构实践中,将那些影响业务流转的核心配置统一提取,并按业务身份进行属性值配置,确保整个交易流程链路标准统一,减少对交易核心链路代码的频繁修改,不同业务根据不同的属性值在相同的交易流程中的不同节点进行灵活切换。
如商品是否自动推到资源池、下单是否需填写身份证、支付成功是否推送线索、超过 N 天未确认收货是否自动确认收货完成等,所有配置项均通过配置管理后台统一维护。
对电商中台中包括业务身份在内的所有元数据,也通过配置管理后台统一管理并提供统一API对外提供查询服务。
从业务和技术多维出发,针对日常工作出现的常见业务或技术问题,研发出各类实用便捷的小工具,实现工作效率提升、问题快速定位等效果,如消息分发、检索工具;商品优惠价格速算工具;商品展示价格比对监控工具;缓存管理工具;一键降级工具等。
随工具化意识提升,这类小工具不断出现并汇集,构成研发必不可少的工具箱。
电商系统的性能指标、资源利用率指标、调用量等系统维度的指标通过云平台实现统一监控,业务数据同理,需提供统一的业务数据可视化工具,为业务方提供决策参照。
为此,采用实时 + 离线开发订单可视化大屏系统,通过该系统能按业务线、订单状态、区域等多维度实时监控订单量变化。若固定时间段内订单量波动超过阈值,发钉钉消息及时通知业务方。
离线数据,也按日、周、月等从多维进行数据统计分析,最终以邮件和办公App消息形式发给业务方,这些手段都是为实现电商数据可视化管理,为业务使用方提供更多便捷的工具对电商业务全方位管控。
整个电商中台建设,将这些经验及日常问题解决办法,作为一种财富不断沉淀,以往都是采用 wiki 这种文档管理工具进行汇总。
为让这些知识产生价值,也开始搭建电商知识库系统,将所有能作为知识沉淀的内容,按不同领域分类录入知识库系统,整套知识库对外提供快速检索和定位功能,能服务技术、产品运营人员,进一步培养知识积累意识,提升工作效率。
二十年前,互联网刚在中国流行,信息都是通过资讯展示,几乎无在线交易;十年前,互联网经过快速发展,消费者可在淘宝、天猫、京东为代表的在线商城上购买自己需要或喜欢的商品进行在线交易;而如今各种电商形态不断涌现,已百花齐放,如内容电商小红书、兴趣电商抖音快手,社交电商微商、拼多多等,会员电商天猫 88vip、京东 plus 等。这些在线交易形态充分证明电商在互联网领域流量变现重要地位,已成互联网企业基础设施的水电煤。
电商中台建设不光是技术体系搭建,也是一个组织结构重新塑造的过程。但随时间推移,中台价值增长空间愈窄,需有意识寻找创新点,突破现有系统边界,跨界思考,于是也开始与前台业务走近,积极开展对新业务探索和技术架构升级。
在过往探索汽车电商业务模式,发现核心痛点在无法绕过 4S 店提供服务。近年特斯拉和国内造车新势力突起,新兴直销模式一举打破传统车企 4S 经销体系生态;国内购车群体也日益年轻化,让我们看到线上订车 + 线下交付的新零售模式可能。
通过升级电商系统现有能力,商品支持SKU选配,订单支持大小定金组合支付、退款,新增交付系统,为工业协会定制车业务、汽车新零售线下店业务提供业务支持。未来还会继续打造业界对齐的新能源选配价格浮动模式以及商品可选配套的服务包模式。
在原有的电商交易下单流程中,设计对外的服务都是颗粒度比较小的原子化服务,这就导致了业务方接入成本比较高,用户体验也不太好。未来我们将会通过增加 BFF 层、精简调用链、电商接入脚手架等技术手段提升业务的产品力以及运营效率。