汽车之家10年系统架构演进与平台化架构实践

汽车之家10年系统架构演进与平台化架构实践本站　　汽车之家-主机厂事业部-技术部

　　汽车之家-主机厂事业部-技术部。2016年加入汽车之家，先后负责过电商ERP系统、商家系统、线索系统、订单中心、AIDCC的研发和架构现主要负责电商交易系统的整体技术架构升级和业务处理等工作。

　　汽车之家电商系统诞生在2014年，成长于2016~2019年，并经历多年双11、818晚会的洪峰考验，沉淀了稳定可靠、性能卓越的在线交易能力。随着业务中台的建设浪潮兴起，2019年进入中台化建设阶段，输出其在汽车电商领域五年沉淀的能力，助力汽车电商行业发展，加速企业数字化转型！

　　这个部分主要讲一下汽车之家电商系统的架构发展历程，每个阶段的业务状况、技术挑战和技术体系的应对策略。

　　互联网大环境在2011~2013年经过千团大战、电商大战‍[1]之后，电商业务已经成了互联网流量变现除广告模式外的另外一块战略高地。在2013年“双十一”期间，汽车之家推出购车服务，将交易环节作为一个重要发展方向[2]。

　　在业务起步阶段 对技术的要求就是快速迭代上线，验证产品可行性。在满足业务日常需求的同时，技术架构上的思考也未停止过。考虑到未来电商系统的可扩展性，参考业界阿里巴巴的技术体系，2014年开始研发技术栈也逐步从系变成Java体系，并与2015年5月30日完成所有的应用切换，上线完整的在线网上购车平台车商城。

　　随着电商业务迅猛发展，技术人员的增加，到2016年技术团队已经有了上百人。单体架构之痛迎面扑来，就以一个前台的商城git项目而言，就几乎近30个maven的子项目，遇上需求并行开发，经常出现代码的合并冲突、需求上线等待、线上慢SQL等问题，整个系统的开发效率和系统稳定性都变差了。

　　这个时候的系统支撑面临巨大的挑战，系统架构必须升级进化。我们开始做分布式战略，把原来的单一系统拆分成多个高内聚，低耦合的中心化系统。也就是现在的用户中心、商品中心、订单中心、促销中心、优惠券中心、商家中心，每个独立的系统可以独立设计、独立接需求、独立发布，整个研发效率和系统稳定性都上了一个台阶。

　　在这个阶段我们在技术上完成 支撑汽车电商百万级商品系统[3]、订单系统[4]、优惠券系统[5]构建，并完成了应用的全部上云[6]、自动化测试平台构建[7]。

　　同时在业务上探索了自营整车电商模式 、开放平台模式、B2B2C模式、报价单模式、顾问模式、TPCC模式、平行售卖等各种经营模式。

　　电商发展的速度实在太快了，到了2019年公司内已经有了多种在线交易模式，比如旅游类、车品与后市场服务类、积分兑换类等。公司基于发展战略决定搭建电商中台，一方面为了集中公司优质的产品资源、运营资源，打造具有影响力的垂直类电商交易平台，另一方面也是为了合理管控技术资源，实现电商系统的统一。在此背景之下，我所在的团队承担起了搭建电商中台的任务，由于各个系统间的业务形态、技术架构差异很大，所以我们面临的第一个问题就是用什么方式能够实现交易类系统的整合。

　　为此我们一方面开始熟悉不同业务场景下的交易系统的现状，另一方面也在技术方案上进行着思考和讨论。最终我们选择了“以数据归一为基础，提供标准化中台服务，从下层向上层逐个系统整合”的方案。

　　数据是公司的核心资产，任何系统尤其是交易类系统，数据更是重中之重。主数据的建设一方面能够统一数据模型，打破系统壁垒；另一方面也能够通过集中的数据进行经营性数据分析，为业务决策提供依据，因此我们将主数据的建设作为了系统整合的第一步。

　　在交易流程中，最重要的数据集中在商家、商品、订单、促销活动这四个领域，我们结合公司交易场景的现状，分别对这四个领域的主数据进行抽象，统一建模，尽可能的适配大多数的交易场景。

　　完成了统一的数据模型后，下一步就需要将现有的异构型数据导入到主数据库中，我们采用了读取数据库binlog（mysql、sqlserver）进行数据加工的方式完成初期的数据同步导入，这也是对业务侵入最小、最快的实现方案。

　　完成了主数据建设，下一步我们便开始进行基于主数据的API标准化建设，API可以看做是系统的神经，高质量的API可以串联起一个优质的系统，统一了API在一定程度上也就实现了系统的收口。

　　为此，我们遵循单一职责的原则，按照领域进行区分，明确边界，做到所有底层API功能原子化，便于上游使用者灵活组装API完成业务逻辑，同时统一API的参数结构和响应结果的结构，统一错误码，基于API网关统一发布、调用，API的数据统计监控、降级、限流实现统一管控。

　　有了标准化的API，自然需要让业务方进行使用才能体现出API的价值，为了防止步子迈的太大，我们也是按照业务的重要性以及量级，采用读写分阶段的方案逐个业务进行调用切换，看似很合理的步骤，在实际执行过程中也暴露了很多问题：

　　①在读写强依赖的场景，比如：用户下单完成后马上会跳转到订单详情查看订单，这个时候在未完成写API切换的时候，由于数据同步延迟会导致通过读API读取数据失败，这时就没有办法按照先读后写分阶段进行切换，最好的办法是读写同时切换。

　　②对于业务切换影响最小的方式，当然是兼容原接口的参数和返回结果，如果我们强加业务方按照我们标准的API进行切换，势必给业务方带来切换成本和不必要的负作用。

　　这个时候我们自然要从对方的角度出发做一些取舍。我们采用的方式是在标准API之上增加了一层适配层，用于新老协议的转换，让业务方只需要切换域名和请求的URL即可，其他逻辑不变，最大限度的做到对业务方友好。

　　③由于我们提供的底层API都是原子的，但在实际场景中，尤其是前后端分离的项目，前端是不大愿意为了一个结果多次调用接口获取，面对这种情况，我们也是在后端增加了一层门面层，基于底层原子API组合成满足业务场景的API对外提供，对于差异化的接口逻辑做适度兼容。

　　④读写切换不可能一蹴而就，在这个过程中势必会存在主数据API和原业务API并存的场景，鉴于所有API的入口都将由我们统一提供，因此我们也是采用了路由的机制，通过路由层的location进行区分转发，所有API做到对调用方的透明。

　　⑤在实际API切换的过程中，还有一种特殊的场景，因为最终要实现系统的整合，对于那些后续会被整合掉的功能强行做API切换其实也是一种资源的浪费，因此我们也是提前做了预判，可以适度的不做切换，等待功能整合后将整体功能进行切换。

　　在完成API读写切换之后，基于主数据的功能基本完成了聚合，此时就需要将通用功能进行系统化的统一，比如：统一的商家管理后台、统一的运营后台、统一的C端交易体验等，系统层级的统一整合目的是为了给使用者一个统一的操作界面，体现平台的专业性。

　　在系统整合的过程中，我们采用了“共性沉淀，差异取舍”的原则，对于那些通用的能力，比如：商品发布、订单列表等功能，我们会抽象出通用的能力，提供统一的单元化的操作界面，满足各业务方的使用诉求。

　　对于业务方特有的功能，我们会建议业务方去实现，而对于那些目前还无法形成通用能力但未来有可能作为通用能力的功能，我们会按照MVP原则，用最快的方式实现小版本的上线，随着业务的迭代不断的实现功能沉淀。

　　在整个系统整合的过程中，必然会出现在整合原有系统功能的同时又有新需求的加入，面对这种场景，我们的采用的方式是新老系统同步开发，看似增加了成本，其实对于新系统的整合是有好处的，一方面能够不影响业务的开展，不会因为技术性的整合对业务造成停滞，另一方面可以通过新老系统的对比，找出新系统可能存在的问题，这也会是验证整合后的新系统功能的最佳途径。

　　在完成绝大部分的系统整合工作之后，电商核心的交易链路已经可以跑通，并且在线上经历了长时间的验证，从商家入驻、商品发布、商品展示、下单、支付、履约、售后，到最终的结算，期间遇到的问题也在一一化解。在这个阶段我们完成了公司内3大交易系统的整合，并进行了电商平台秒杀系统的架构升级[8]，优惠券系统的架构升级，支撑了2020-2021的818晚会、双11、双12等大型活动的秒杀、发券场景。另外我们也在积极探索领域驱动模型DDD的理论与业界实践，并在总库系统的重构中进行了落地实践[9]，这也为后续的平台化架构升级提供了技术支撑。

　　在电商业务中台继续向业务的“逼近”过程中，系统的抽象和建设难度也成指数型增加，出现了一系列新问题：

　　（1）随着建设中台项目的结束，人员的撤离，电商业务中台在集成这么多业务线的逻辑之后，代码里充斥着大量条件判断，每次需求迭代的开发成本和测试回归成本都很高，如何隔离不同业务之间的逻辑，减少业务之间的耦合度呢？

　　（3）当新业务接入电商业务中台，如何基于已有的能力和解决方案快速组装上线，以支撑业务快速迭代创新？

　　综上所述，电商业务中台在建设过程中抽象业务线的共性能力以及共性能力的复用性设计与实现尤其重要，业务中台要做到能力复用和灵活多变才能让中台建设在企业的发展过程中起到降本增效的效果。系统架构必须升级，这就进入了平台化架构阶段。

　　什么是平台化架构？就是要把基础能力跟每个业务方的特性业务拆分，要把业务和业务之间的逻辑进行隔离。平台化最核心的是业务抽象建模和系统架构的开放性，业务抽象解决共性的80%问题，系统架构开放性解决20%的个性化问题。

　　在参考ThoughtWorks给出的《现代企业架构》的方案[10]以及业界的互联网公司美团[11]、有赞[12]的中台解决方案，我们给出了适合之家电商平台的解决方案：通过领域驱动建模抽象出电商业务中台多业务线的共性能力并预留扩展点，然后利用服务编排对共性能力进行组合。其原理如图所示：

　　每一个在电商业务中台运行的业务可以理解为：业务身份+业务流程+规则，业务流程通过流程服务编排来实现，扩展点通过扩展点机制来实现。在整个交易流程中B端的商家入驻、商品发布相对通用，不同的业务的主要流程差别体现在订单收单前以及支付后的订单履约，这些流程往往都是需要定制化开发，为此整个解决方案核心在于订单平台化的架构设计。

　　业务身份的概念最早由阿里巴巴提出，业务平台在对各业务同时提供服务时，需要能区分每一次业务服务请求的业务身份要素，以便提供差异化个性化的服务；因此需要对企业各业务的身份和特征进行建模和区分，其产出即为业务身份。业务身份具有唯一性，业务身份类似于身份证号码一样，需要保证在整个业务中台上必须是唯一的。

　　有了业务身份业务中台就可以针对抽象这个业务流程和业务规则，并基于业务身份实现服务路由、业务监控。其次业务身份就类似SAAS系统中的租户的概念，不同的业务方在中台通过业务身份进行数据权限隔离，这样能保证各业务的运营只能看见自己业务部分的数据。

　　比如在汽车电商领域，业务身份我们通过人、货、场三个维度进行抽象。人的维度有是否开通会员、是否是认证车主、开通了哪些增值服务等；货的维度有商品类型（整车、实物商品、虚拟商品等），交付方式（核销、兑换、4S店交付）等；场的维度有线上下单、线下下单、在哪个线上商城下单，在哪个交付店下单、商品投放渠道来源等。根据这些维度确定了唯一的业务身份后，每笔交易的业务流程就确定下来了。

　　电商业务中台整体采用微服务架构、将整个电商系统拆分为商家中心、用户中心、商品中心、促销中心、交易中心、履约中心、售后中心。每个中心在逻辑上分成了带有业务属性的能力和不带业务属性的基础能力两层。基础能力层关注领域模型的实体属性、行为、事件，不会随着业务的需求调整而发生变化，聚焦于行业共性行为、收敛业务模型，保障基础服务的稳定性。带有业务属性的能力是在基础能力层之上通过服务组合、流程编排之类的技术手段，构成面向业务的解决方案，完成业务共性到个性化的转变。有两种常见的做法如下：

　　其一是使用硬编码来实现。随着不同业务线的逻辑不断增加，各个业务能力调用的基础能力会变得盘根错节，很难做到可配置、灵活化。当发生需求变更的时候，测试人员很难评估修改的影响范围，回归测试的成本周期长，这样很难真正做到敏捷开发、快速响应业务。

　　其二是使用服务编排。通过服务编排现有微服务进行服务组合服务，然后一次性的返回前台需要的信息。不同业务线的能力执行不同的流程，通过图形化、XML、JSON的编排框架，即可以让流程清晰，也可以屏蔽代码细节。

　　服务拆分的好处无需赘述，但是要实现业务价值，不是看单个服务的能力，而是要协调所有服务保证企业端到端业务流程的成功。业务中台是企业业务的集成平台，集成技术必须松散地耦合组成流程的应用程序和资源，否则流程的逻辑将被硬编码到特定的技术平台中，更改可能代价高昂，从而违背业务流程复用的整个目标。

　　在服务编排领域，已经有很多的工业界解决方案，我们参考了基于API网关的服务编排[13]，基于工作流系统的编排框架Flowable和Activiti[14]、基于微服务架构编排框架的Netflix Conductor[16]和Zeebe[17]。通过对技术原理进行分析，发现它们都存在某些程度上的不足，无法应用到电商业务中台的服务编排，最终我们选用Apache Camel [18]做为服务编排的底层引擎进行二次封装开发。Apache Camel 诞生于2007年，2009年前后成为Apache项目更名为Apache Camel，目前最新版本是3.0。Apache Camel的优点在于在发布后十多年的时间里，已经拥有三百多种扩展组件；扩展机制也极其方便和灵活；通过开箱即可用的最佳实践来解决应用集成问题；它基于事件驱动的架构，有着良好的性能和吞吐量[19]。

　　业务中台使用服务编排技术一方面可以将交易的能力自动识别出来作为组件可视化的呈现，形成能力地图；另一方面，基于这些基础能力实现服务流程的编排，能够通过拖拉拽的方式快速搭建出适合业务的全部或者部分交易流程，类似积木，复用基础组件，灵活搭配，进而实现电商企业级能力的复用，节约开发成本，快速赋能业务的目标。

　　扩展点的全称是Service Provider Interface，简称为SPI。是Java提供的一套用来加载和运行第三方扩展的接口实现类的机制，一般用在组件替换和框架扩展的场景。SPI将服务接口与服务实现分离以达到解耦、提升了应用程序的可扩展性。在程序设计中，模块之间采用面向接口编程而不做具体的实现类引用，通过动态加载实现类达到应用程序的插件化。

　　COLA框架是阿里巴巴技术专家提出的一种应用架构的扩展点框架[20]。COLA框架的扩展是通过注解的方式来实现的，Extension扩展注解里面使用用例（useCase）、业务（bizId）、场景（scenario）三个属性用来标识身份。使用COLA框架的扩展点可以在代码层面支持不同业务身份的逻辑隔离，因为不同的逻辑分散在不同的实现类里面，符合软件设计的开闭原则。

　　在运行时，通过业务身份定位扩展点实现类，然后执行扩展点实现的逻辑。定位扩展点实现的时候支持三层路由，首先会按照useCase+bizId+scenario找扩展点实现，如果没有则按照useCase+bizId+scenario默认值查找，如果还未找到则根据useCase+bizId默认值+scenario默认值查找，具体原理如图所示：

　　对于简单的业务场景，对应用系统的高扩展性、业务隔离的非功能性要求并不多。但是随着同一应用系统支撑的业务变多、业务场景变复杂，在架构层面需要提供统一的扩展解决方案，将变化的业务规则固化下来，这不仅有助于统一技术规范，还能减少硬编码的IF-ELSE、策略模式等因开发人员水平不一致带来的理解上复杂度、规范上的一致性。

　　通过扩展点机制，业务中台就可以从业务身份和框架层面实现对不同的业务的管理像SAAS管理租户一样管理业务，不同业务身份在不同场景下对预定义的扩展点进行扩展。阿里巴巴的业务中台也正是基于扩展点的思想，实现的核心业务逻辑和技术细节的分离和解耦，共享事业部才能对集团内几百条业务线）服务编排+扩展点应用举例

　　在验证功能后对电商交易系统的的场景进行了分类，首先选取用户感知度小、即使出问题也对用户影响最小的节点进行重构试用，如未支付订单超时关闭、用户取消订单。

　　在平台化架构实践中我们将那些影响业务流转的核心配置统一提取出来，并按照业务身份进行属性值的配置，确保整个交易流程链路的标准统一，减少对交易核心链路代码的频繁修改，不同业务根据不同的属性值在相同的交易流程中的不同节点进行灵活切换。

　　从业务和技术的度出发，针对日常工作中出现的常见业务问题或者技术问题，研发出各类实用便捷的小工具，实现工作效率的提升、问题的快速定位等效果，比如：消息分发、检索工具；商品优惠价格速算工具；商品展示价格比对监控工具；缓存管理工具；一键降级工具等等。随着大家工具化意识的不断提升，这类小工具不断的出现并汇集在一起，就构成了研发人员必不可少的工具箱。

　　电商系统的性能指标、资源利用率指标、调用量等系统维度的指标通过公司云平台能够实现统一的监控，对于业务数据同理，我们需要提供统一的业务数据可视化工具，为业务方提供做相关决策的参照依据。

　　我所在的这个团队在公司内部的电商领域是一个专业的团队，多年来积累了很多技术以及产品运营层面的经验。在整个电商中台的建设过程中，我们也是将这些经验以及日常问题的解决办法，作为一种财富不断的沉淀，以往都是采用wiki这种文档管理工具进行汇总。

　　二十年前，互联网刚开始在中国流行，信息都是通过资讯的方式展示，几乎没有在线交易；十年前，互联网经过快速发展，消费者可以在淘宝、天猫、京东为代表的在线商城上购买自己需要或喜欢的商品进行在线交易；而如今各种电商形态不断涌现，已成百花齐放的趋势，比如内容电商小红书、兴趣电商抖音快手，社交电商微商、拼多多等，会员电商天猫88vip、京东plus等。这些在线交易形态充分证明了电商在互联网领域流量变现的重要一环，已经成为互联网企业基础设施的水电煤。

　　在过往探索汽车电商的业务模式，我们发现核心痛点在无法绕过4S店提供服务。近年来特斯拉和国内造车新势力的异军突起，新兴的直销模式一举打破传统车企4S经销体系的生态；国内购车群体也日益年轻化让我们看到了线上订车+线下交付的新零售模式正在变成可能。

　　在原有的电商交易下单流程中，设计对外的服务都是颗粒度比较小的原子化服务，这就导致了业务方接入成本比较高，用户体验也不太好。未来我们将会通过增加BFF层、精简调用链、电商接入脚手架等技术手段提升业务的产品力以及运营效率。

　　dbaplus社群是围绕Database、BigData、AIOps的企业级专业社群。资深大咖、技术干货，每天精品原创文章推送，每周线上技术分享，每月线下技术沙龙，每季度Gdevops&DAMS行业大会。