★目录01前言02架构演进2.1初始阶段2.2微服务阶段2.3主数据阶段2.4平台架构阶段03平台架构实践3.1业务标识3.2服务编排3.3业务配置3.4开发工具3.5数据可视化3.6知识沉淀04收官4.1新零售探索4.2架构升级党的巅峰考验沉淀了稳定、可靠、卓越的在线交易能力。随着电商中台建设浪潮的兴起，2019年将进入中台建设阶段，输出其在汽车电商领域五年积累的能力，助力汽车电商行业发展，加速企业数字化转型！这部分架构演进主要讲述了汽车之家电商系统架构的发展历程，各阶段的业务现状、技术挑战和技术系统应对策略。在互联网环境的起步阶段，经过2011~2013年的千团大战和电商大战[1]，电商业务成为除广告模式之外的又一战略制高点，实现互联网流量。2013年“双十一”期间，汽车之家推出购车服务，将交易环节作为重要发展方向[2]。在业务启动阶段，技术需求是快速迭代上线，验证产品的可行性。在满足业务日常需求的同??时，对技术架构的思考也没有停止。考虑到未来电商系统的可扩展性，参考业界阿里巴巴的技术体系，技术栈的研发从2014年开始，逐步从.NET体系转向Java体系，并且都2015年5月30日完成应用切换。推出完整的在线购车平台汽车商城。在微服务阶段，随着电商业务的快速发展和技术人员的增多，到2016年技术团队已达数百人。单体架构的痛苦迎面而来。一个前端商城git项目，有近30个maven子项目。满足并行开发需求时，经常会出现代码合并冲突，等待线上需求，线上开发速度慢等问题。SQL等问题，整个系统的开发效率和系统稳定性都变差了。此时，系统支撑面临巨大挑战，系统架构必须升级演进。我们开始做分布式策略，把原来的单体系统拆分成多个高内聚低耦合的中心化系统。即目前的用户中心、产品中心、订单中心、促销中心、优惠券中心、商家中心。每个独立的系统都可以独立设计、独立接收、独立发布。整个研发效率和系统稳定性都得到了提升。脚步。现阶段，我们在技术上完成了支撑汽车电商的百万级商品系统[3]、订单系统[4]、优惠券系统[5]的搭建，并完成了所有应用上云[6]]和自动化测试平台Build[7]。同时，在业务方面探索了自营汽车电商模式、开放平台模式、B2B2C模式、报价模式、顾问模式、TPCC模式、平行进口车销售等多种商业模式。电子商务在主数据阶段的发展速度太快了。到2019年，公司已经拥有旅游、汽车产品及售后服务、积分兑换等多种在线交易方式，公司根据发展战略决定打造电子商务平台。一方面，旨在集中公司优质的产品资源和运营资源，打造具有影响力的垂直电子商务交易平台。统一。在这样的背景下，我的团队承担了搭建电商中台的任务。由于各个系统的业务形态和技术架构差异很大，我们面临的第一个问题就是如何实现交易类系统的集成。为此，我们一方面开始熟悉交易系统在不同业务场景下的现状，另一方面也在思考和探讨技术方案。最终，我们选择了“基于数据规范化，提供标准化中台服务，从下到上层层层集成系统”的解决方案。数据规范化数据是企业的核心资产，任何系统，尤其是交易系统，数据都是最重要的。一方面，主数据的构建可以统一数据模型，打破系统壁垒；另一方面，也可以通过集中数据进行运营数据分析，为业务决策提供依据。因此，我们把主数据的建设作为系统集成的第一步。步。在交易过程中，最重要的数据集中在商户、商品、订单、促销活动四个领域。我们结合公司交易场景的现状，对这四个领域的主数据进行抽象，统一建模。适用于大多数交易场景。下面是订单主数据的核心数据模型结构示意图：完成统一的数据模型后，下一步就是将已有的异构数据导入主数据库。我们采用读取数据库binlog（mysql、sqlserver）数据处理的方式完成初始同步数据导入，这也是对业务侵入性最小、实现速度最快的方案。API标准化已经完成了主数据的建设，下一步将启动基于主数据的API标准化建设。API可以看作是系统的神经。高质量的API可以串联一个高质量的系统，在一定程度上统一API。也实现了系统的关闭。为此，我们遵循单一职责原则，按领域区分，明确边界，实现所有底层API功能的原子化，让上游用户可以灵活组装API完成业务逻辑，并在同时统一API的参数结构和响应结果的结构。统一错误代码，基于API网关统一发布和调用，API数据统计监控、降级、限流实现统一管控。API读写切换有了标准化的API，业务方自然要用它来体现API的价值。为了防止步骤过多，我们也采用分阶段的方案，根据业务的重要性和大小进行读写，按业务来调用和切换业务，看似合理，但在实际执行过程中也暴露出很多问题：1）在读写依赖性强的场景下，例如：用户下单后，会立即跳转至订单详情查看订单，此时写API切换还没有完成，由于到数据同步延迟，通过readAPI读取数据会失败。这时候就没有办法按照先读后写的阶段来切换了。最好的方法是同时在读和写之间切换。2）对业务切换影响最小的方法当然是兼容原接口的参数和返回结果。如果强行让业务端按照我们的标准API进行切换，势必会给业务端带来切换成本和不必要的副作用。这个时候，我们自然要站在对方的角度做出一些选择。我们采用的方法是在标准API之上增加一层适配层，用于新旧协议的转换，这样业务方只需要切换域名和请求的URL，其他逻辑不变，从而达到最大限度的商业友好。3）由于我们提供的底层API都是原子的，在实际场景中，尤其是前后端分离的项目，前端是不愿意多次调用接口得到一个结果的。面对这种情况，我们也在后端增加了一个门面层，基于底层的原子API，组合满足业务场景的API对外提供，适度兼容差异化的接口逻辑。4）不可能一夜之间在读写之间切换。在这个过程中，难免会出现主数据API和原有业务API并存的场景。由于所有的API入口都会由我们统一提供，所以我们也采用了路由机制。通过路由层对位置进行区分和转发，所有的API对调用者都是透明的。5）在实际API切换的过程中，还有一个特殊的场景，因为最终要实现系统集成。对那些后面要集成的功能强行切换API，其实是一种资源的浪费，所以我们也提前了。做好预判后，可以不适当切换，等功能集成后再切换整体功能。系统功能集成完成API读写切换后，基本聚合了基于主数据的功能。这时候就需要系统统一通用功能，比如：统一商户管理后台、统一运营后台、统一C端交易体验等，系统层面统一集成的目的是为用户提供一个统一的操作界面，体现平台的专业性。在系统集成过程中，我们采取“沉淀共性，取舍差异”的原则。对于那些通用的能力，比如：产品发布、订单列表等功能，我们将通用能力抽象出来，提供一个统一的单元操作接口，满足所有业务方的诉求。对于业务方特有的功能，我们会建议业务方去实现，对于那些还不能形成通用能力但未来可能会成为通用能力的功能，我们会遵循MVP原则，用最快的方式实现小版本上线，随着业务的迭代不断实现功能沉淀。在整合整个系统的过程中，在整合原有系统功能的同时，难免会增加新的需求。面对这种场景，我们采用新旧系统同步开发的方式，这样似乎增加了成本。事实上，新系统的整合是有益的。一方面，不会影响业务的发展，不会因为技术整合造成业务停滞。另一方面，通过新旧系统的对比，发现新系统可能存在的问题，这也是验证新集成系统功能的最佳方式。在完成大部分系统集成工作后，电商的核心交易环节已经能够跑通，并经过长时间的在线验证，从商家入驻、产品发布、产品展示、下单、支付、合同履行，从售后到结算，期间遇到的问题也一一解决。现阶段，我们完成了公司三大交易系统的整合，升级了电商平台秒杀系统[8]架构和优惠券系统架构，支持2020-2021818晚会，双11、双12等大型活动闪购、发券场景。此外，我们也在积极探索领域驱动模型DDD的理论和行业实践，并在发票通用数据库系统的重构中实现[9]，也为平台架构的后续升级提供了技术支持.在平台架构阶段，随着电商业务中心不断向业务“靠拢”，系统的抽象度和搭建难度也呈指数级增长，一系列新的问题也随之出现：1）与中台项目建设结束，随着人员的疏散，电商业务中心整合了这么多业务线的逻辑后，代码中充满了条件判断。每次需求迭代的开发成本和测试回归成本都非常高。如何隔离不同业务之间的逻辑，降低业务之间的耦合度？2）如何将已接入电商业务平台的多个业务线的公共能力进行抽象，避免重复建设？3）当新业务接入电商业务平台后，如何基于现有能力和解决方案快速组装上线，支持业务快速迭代创新？4）如何利用技术手段帮助提升产品运营日常工作的效率？综上所述，在电商业务中台建设过程中，业务线通用能力的抽象以及通用能力的复用性设计与实现显得尤为重要。业务中台必须实现能力复用和灵活性，使中台建设在企业发展过程中起到降本增效的作用。系统架构必须升级，已经进入平台架构阶段。平台架构实践什么是平台架构？就是将基础能力从各业务方的特色业务中分离出来，将业务与业务之间的逻辑进行隔离。平台化的核心是业务抽象建模和系统架构的开放性。业务抽象解决了80%的共性问题，系统架构的开放性解决了20%的个性化问题。参考了ThoughtWorks[10]给出的《现代企业架构白皮书》方案以及业内互联网公司美团[11]和有赞[12]的中台方案，我们给出了一个适合家庭电商平台的解决方案：通过领域驱动建模将电商业务中多个业务线的共性能力抽象出来并预留扩展点，然后通过服务编排将共性能力组合起来。原理如图：运行在电商业务平台中的各个业务可以理解为：业务标识+业务流程+规则，业务流程通过流程服务编排实现，扩展点通过扩展点机制实现。在整个交易过程中，B端商户和产品发布是比较常见的。不同业务的主要流程差异体现在接单前和付款后的订单履行。这些过程通常需要定制开发。为此，整个解决方案的核心在于订单平台的架构设计。如图：整个订单平台架构分为四层，从下到上：基础设施层：提供存储、消息、RPC等中间件基础服务层：按领域组织的基础服务，领域服务为不同的业务提供扩展点。业务能力层：连接不同领域的服务，形成可以对外使用的业务能力，如下单、支付等。业务流程层：安排业务能力，形成订单交易流程，完成订单交易流程。业务层：制定业务标识、扩展点实现、业务流程配置等，实现不同的业务差异化。订单平台架构升级的整个过程可以概括如下：BusinessIdentity业务标识的概念最早是由阿里巴巴提出的。当业务平台同时为各种业务提供服务时，需要能够区分每个业务服务请求的业务身份。提供差异化??和个性化服务的要素；因此，需要对企业各个业务的身份和特征进行建模和区分，输出的就是业务身份。企业身份是独一无二的。企业身份类似于身份证号码。需要保证在整个业务平台中是唯一的。有了业务标识，业务中心就可以抽象出业务流程和业务规则，并根据业务标识实现业务路由和业务监控。其次，业务身份类似于SAAS系统中租户的概念。不同的业务方通过业务标识在中台隔离数据权限，使得每个业务的操作只能看到自己业务的数据。比如在汽车电商领域，我们通过人、货、地三个维度来抽象商家身份。人的维度包括是否是会员、是否是认证车主、开通了哪些增值服务等；商品维度包括商品类型（整车、实物商品、虚拟商品等）、配送方式（验证、换货、4S店配送）等；市场维度包括线上下单、线下下单、在哪家网店下单、在哪家外卖店下单、产品分销渠道来源等。根据这些维度确定了唯一的业务标识后，确定了每笔交易的业务流程。服务编排电商业务中心整体采用微服务架构，将整个电商系统拆分为商家中心、用户中心、产品中心、推广中心、交易中心、履约中心、售后中心。每个中心在逻辑上分为两层：有业务属性的能力和没有业务属性的基础能力。基础能力层关注领域模型的实体属性、行为和事件，不会随着业务需求的调整而变化。聚焦行业共性行为，融合商业模式，保障基础服务的稳定性。具有业务属性的能力基于基础能力层，通过服务组合、流程编排等技术手段，形成面向业务的解决方案，完成业务从通用性到个性化的转变。常用的方法有以下两种：一种是使用硬编码来实现。随着不同业务线的逻辑不断增加，每个业务能力调用的基础能力会相互交织，难以配置和灵活。当需求发生变化时，测试人员很难评估修改的影响范围，回归测试成本周期长，难以真正做到敏捷开发和快速响应业务。二是使用服务编排。通过现有微服务的服务编排来组合服务，然后一次性返回前台需要的信息。不同业务线的能力执行不同的流程。通过图形化、XML、JSON编排框架，让流程清晰，屏蔽代码细节。服务拆分的好处无需细说，但要实现业务价值，不是只看单一服务的能力，而是要协调所有服务，确保企业端到端业务流程的成功.业务中台是企业业务的集成平台。集成技术必须将组成流程的应用程序和资源松散耦合，否则流程的逻辑将被硬编码到特定的技术平台中，更改可能代价高昂，从而违反业务流程重用的整个目标。服务编排框架在服务编排领域，已经有很多行业解决方案。我们参考了基于API网关的服务编排[13]、基于工作流系统的编排框架Flowable和Activiti[14]、基于微服务架构的编排框架NetflixConductor[16]和Zeebe[17]。通过对技术原理的分析，发现它们都存在一定的不足，无法应用于电商业务平台的服务编排。最后，我们选择ApacheCamel[18]作为二次打包开发的服务编排底层引擎。ApacheCamel诞生于2007年，2009年左右成为Apache顶级项目，更名为ApacheCamel。最新版本是3.0。ApacheCamel的优势在于，它在发布后的十几年里，已经拥有了300多个扩展组件；扩展机制也极为方便灵活；它通过开箱即用的最佳实践解决应用程序集成问题；它基于具有良好性能和吞吐量的事件驱动架构[19]。下面是一个简单的业务流程编排示例：一方面，业务中心使用的业务编排技术，可以自动识别交易能力，将其作为组件的可视化呈现，形成能力地图；另一方面，基于这些基础能力，可以实现对业务流程的编排，可以通过拖拽的方式，快速构建适合业务的全部或部分交易流程，类似搭积木，复用基础组件，灵活搭配，进而实现电商企业级能力的复用，节省开发成本，快速赋能商家的目标。扩展点框架扩展点的全称是ServiceProviderInterface，简称SPI。是Java提供的一套加载运行第三方扩展接口实现类的机制，一般用于组件替换和框架扩展场景。SPI将服务接口与服务实现分离，实现解耦，提高应用的可扩展性。在程序设计中，模块之间采用面向接口的编程方式，不引用具体的实现类，通过动态加载实现类实现应用的插件化。COLA框架是阿里巴巴技术专家提出的应用架构扩展点框架[20]。COLA框架的扩展是通过注解实现的。Extension扩展注解使用三个属性：用例（useCase）、业务（bizId）和场景（scenario）来标识身份。使用COLA框架的扩展点可以在代码层面支持不同业务标识的逻辑隔离，因为不同的逻辑分散在不同的实现类中，符合软件设计的开闭原则。应用Spring上下文初始化完成后，COLA框架开始扫描带有Extension注解的bean进行扩展点注册，并存储到Map的结构体中。键是useCase、bizId和场景字符串的串联，值是bean。在运行时，通过业务标识定位到扩展点实现类，然后执行扩展点实现的逻辑。实现位置扩展点时，支持三层路由。首先会根据useCase+bizId+scenario找到扩展点实现。如果没有扩展点，会按照useCase+bizId+scenario的默认值进行查找。如果一直没有找到，会使用useCase+bizId+scenario+scenario默认值搜索，具体原理如图：对于简单的业务场景，非功能性需求不多，可扩展性高以及应用系统的业务隔离。但随着同一应用系统支持的业务越来越多，业务场景越来越复杂，需要在架构层面提供统一的扩展方案，固化不断变化的业务规则。这不仅有利于统一技术规范，还可以减少因开发者层级不一致、理解复杂度和规范一致性导致的硬编码IF-ELSE、策略模式等问题。通过扩展点机制，业务中心可以从业务标识和框架层面管理不同的服务，就像SAAS管理租户一样，不同的业务标识可以在不同的场景下扩展预定义的扩展点。阿里巴巴的业务中台也是基于扩展点的思想，实现了核心业务逻辑和技术细节的分离和解耦，让共享的业务部门可以支撑集团内数百条业务线。服务编排+扩展点应用示例功能验证完成后，对电商交易系统的场景进行分类。首先，选择用户感知度低，即使出现问题对用户影响最小的节点进行重构和试用。例如，未支付的订单超时关闭，用户取消订单。以用户取消订单的场景为例，在修改之前，各个业务的用户取消订单的逻辑都是修改订单状态为取消，然后执行相同的流程。流程的执行顺序是硬编码的，伪代码如图：根据各个业务的特点，进行了精心安排。比如二手车业务不使用优惠券，就不需要这个链接；在点位的通用能力方面，万里通点位得到了扩展。伪代码如图：旅行者业务线的酒店机票业务没有传统的商品库存概念，因此不再需要退货商品库存的操作，而是抽象出一个新的通用能力：取消供应商订单，还预设了取消酒店供应商订单和取消机票供应商订单两个扩展点。伪代码如图所示：整个系统应用效果明显，主要体现在性能和人效的提升上。性能的提升主要体现在系统响应时间的缩短上。修改后，取消订单接口的生产环境TP99提升百分比约为30%。人效的提升主要体现在测试取消订单和新增流程节点所用时间的对比上。修改前，业务流程之间的代码是耦合的。修改流程，增加新节点，需要对之前的业务进行回归测试。修改后不需要对每个业务进行回归测试。业务配置在平台架构实践中，提取影响业务流程的核心配置，根据业务身份配置属性值，保证整个交易流程环节的统一标准，减少对业务流程的需求交易核心链接代码。修改频繁，不同业务根据不同的属性值在同一交易流程的不同节点灵活切换。例如：产品是否自动推送到资源池，下单时是否需要填写身份证，支付成功是否推送线索，是否超过N天未确认发货，是否自动确认发货等所有配置项统一通过配置管理后台维护。此外，对于电商平台中包括商家身份在内的所有元数据，我们也通过配置管理后台进行统一管理，提供统一的API对外提供查询服务。开发工具从多维度的业务和技术出发，针对日常工作中出现的常见业务问题或技术问题，开发各种实用便捷的小工具，以提高工作效率，快速定位问题，例如：新闻发布与检索工具;商品折扣价速算工具；商品陈列比价监控工具；缓存管理工具；一键降级工具等随着大家对工具的认识不断提高，这样的小工具不断出现，汇集在一起??，形成了开发者不可或缺的工具箱。通过公司云平台统一监控数据可视化电商系统的性能指标、资源利用率指标、调用量等系统维度指标。对于业务数据，我们需要为业务方提供统一的业务数据可视化工具。为相关决策提供参考。为此，我们开发了实时+离线的订单可视化大屏系统。通过该系统，可以从业务线、订单状态、区域等多个维度实时监控订单量的变化。如果固定时间内的订单量波动超过我们预先设置的阈值，就会发送钉钉消息，及时通知业务方。此外，对于线下数据，我们也按照日、周、月进行多维度的数据统计分析，最终以邮件、办公APP消息的形式发送给业务方。这些手段的目的是实现电子商务的数据化。可视化管理为企业用户提供了更加便捷的电子商务业务综合管控工具。知识沉淀我所在的团队是公司内部电子商务领域的专业团队，多年来在技术和产品运营方面积累了大量经验。在整个电商平台的建设过程中，我们也把这些经验和解决日常问题的方法当作财富的不断积累。以前我们都是用wiki这个文档管理工具来总结的。为了让这些知识产生价值，我们也着手构建自己的电子商务知识库系统，将所有可以作为知识积累的内容，按照不同的领域，全部录入到知识库系统中。整套知识库提供快速检索和定位功能，可以服务于技术人员和产品操作人员，进一步培养大家的知识积累意识，提高大家的工作效率。结束二十年前，互联网在中国刚刚开始流行。信息以信息的形式展示，几乎没有网上交易。在商城购买您需要或喜欢的商品进行在线交易；而现在各种形式的电商层出不穷，成为百花齐放的趋势，比如内容电商小红书、趣味电商抖音快手、社交电商微商、拼多多、会员电商天猫88vip、京东plus等这些形式的线上交易充分证明电子商务是互联网领域流量变现的重要组成部分，已经成为互联网企业基础设施的实用工具。电子商务平台的建设不仅是技术体系的建立，更是组织架构重塑的过程。但随着时间的推移，中台价值的增长空间会越来越窄。这就需要有意识地寻找创新，突破现有体制的界限，进行跨界思维。因此，我们也开始向前端业务靠拢，积极进行新的业务探索和技术架构升级。探索新零售以往在探索汽车电商的商业模式时，我们发现核心痛点是不能绕开4S店提供服务。近年来，特斯拉和国内新造车企业的异军突起，新兴的直销模式一举打破了传统车企4S经销体系的生态；国内的购车者也越来越年轻化，所以我们看到新车在线下单+线下配送的零售模式正在成为可能。通过升级电商系统现有能力，产品支持SKU匹配，订单支持大小押金组合支付、退款，全新配送系统为行业协会定制车业务和新车零售业务提供业务线下门店支持。未来，我们将继续打造与行业接轨的新能源可选价格浮动模式和可选产品服务包模式。架构升级在原有的电商交易下单流程中，对外服务被设计为粒度比较小的原子服务，导致业务方接入成本较高，用户体验较差。未来我们将通过增加BFF层、打通调用链、接入电商脚手架等技术手段，提升业务的产品力和运营效率。
