汽车电商平台发展趋势：汽车之家电商系统架构演进与平台化架构实践
汽车电商平台发展趋势：汽车之家电商系统架构演进与平台化架构实践电商发展的速度实在太快了，到了2019年公司内已经有了多种在线交易模式，比如旅游类、车品与后市场服务类、积分兑换类等。公司基于发展战略决定搭建电商中台，一方面为了集中公司优质的产品资源、运营资源，打造具有影响力的垂直类电商交易平台，另一方面也是为了合理管控技术资源，实现电商系统的统一。在此背景之下，我所在的团队承担起了搭建电商中台的任务，由于各个系统间的业务形态、技术架构差异很大，所以我们面临的第一个问题就是用什么方式能够实现交易类系统的整合。同时在业务上探索了自营整车电商模式 、开放平台模式、B2B2C模式、报价单模式、顾问模式、TPCC模式、平行进口车售卖等各种经营模式。随着电商业务迅猛发展，技术人员的增加，到2016年技术团队已经有了上百人。单体架构之痛迎面扑来，就以一个前台的商城git项目而言，就几乎近30个maven的子项目，遇上需求并行开发，经常出现代码的合并冲突、需求上线等待
汽车之家电商系统诞生在2014年，成长于2016~2019年，并经历多年双11、818晚会的洪峰考验，沉淀了稳定可靠、性能卓越的在线交易能力。 随着业务中台的建设浪潮兴起，2019年进入中台化建设阶段，输出其在汽车电商领域五年沉淀的能力， 助力汽车电商行业发展 ，加速企业数字化转型！
架构演进这个部分主要讲一下汽车之家电商系统的架构发展历程，每个阶段的业务状况、技术挑战和技术体系的应对策略。
- 起步阶段
互联网大环境在2011~2013年经过 千团大战、电商大战 [1] 之后，电商业务已经成了互联网流量变现除广告模式外的另外一块战略高地。 在2013年“双十一”期间，汽车之家推出购车服务，将交易环节作为一个重要发展方向[2] 。
在业务起步阶段 对技术的要求就是快速迭代上线，验证产品可行性。在满足业务日常需求的同时，技术架构上的思考也未停止过。考虑到未来电商系统的可扩展性，参考业界阿里巴巴的技术体系，2014年开始研发技术栈也逐步从 .NET体系变成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的价值，为了防止步子迈的太大，我们也是按照业务的重要性以及量级，采用读写分阶段的方案逐个业务进行调用切换，看似很合理的步骤，在实际执行过程中也暴露了很多问题：
1) 在读写强依赖的场景，比如：用户下单完成后马上会跳转到订单详情查看订单，这个时候在未完成写API切换的时候，由于数据同步延迟会导致通过读API读取数据失败，这时就没有办法按照先读后写分阶段进行切换，最好的办法是读写同时切换。
2) 对于业务切换影响最小的方式，当然是兼容原接口的参数和返回结果，如果我们强加业务方按照我们标准的API进行切换，势必给业务方带来切换成本和不必要的负作用。
这个时候我们自然要从对方的角度出发做一些取舍。我们采用的方式是在标准API之上增加了一层适配层，用于新老协议的转换，让业务方只需要切换域名和请求的URL即可，其他逻辑不变，最大限度的做到对业务方友好。
3) 由于我们提供的底层API都是原子的，但在实际场景中，尤其是前后端分离的项目，前端是不大愿意为了一个结果多次调用接口获取，面对这种情况，我们也是在后端增加了一层门面层，基于底层原子API组合成满足业务场景的API对外提供，对于差异化的接口逻辑做适度兼容。
4) 读写切换不可能一蹴而就，在这个过程中势必会存在主数据API和原业务API并存的场景，鉴于所有API的入口都将由我们统一提供，因此我们也是采用了路由的机制，通过路由层的location进行区分转发，所有API做到对调用方的透明。
5) 在实际API切换的过程中，还有一种特殊的场景，因为最终要实现系统的整合，对于那些后续会被整合掉的功能强行做API切换其实也是一种资源的浪费，因此我们也是提前做了预判，可以适度的不做切换，等待功能整合后将整体功能进行切换。
系统功能整合在完成API读写切换之后，基于主数据的功能基本完成了聚合，此时就需要将通用功能进行系统化的统一，比如：统一的商家管理后台、统一的运营后台、统一的C端交易体验等，系统层级的统一整合目的是为了给使用者一个统一的操作界面，体现平台的专业性。
在系统整合的过程中，我们采用了“共性沉淀，差异取舍”的原则，对于那些通用的能力，比如：商品发布、订单列表等功能，我们会抽象出通用的能力，提供统一的单元化的操作界面，满足各业务方的使用诉求。
对于业务方特有的功能，我们会建议业务方去实现，而对于那些目前还无法形成通用能力但未来有可能作为通用能力的功能，我们会按照MVP原则，用最快的方式实现小版本的上线，随着业务的迭代不断的实现功能沉淀。
在整个系统整合的过程中，必然会出现在整合原有系统功能的同时又有新需求的加入，面对这种场景，我们的采用的方式是新老系统同步开发，看似增加了成本，其实对于新系统的整合是有好处的，一方面能够不影响业务的开展，不会因为技术性的整合对业务造成停滞，另一方面可以通过新老系统的对比，找出新系统可能存在的问题，这也会是验证整合后的新系统功能的最佳途径。
在完成绝大部分的系统整合工作之后，电商核心的交易链路已经可以跑通，并且在线上经历了长时间的验证，从商家入驻、商品发布、商品展示、下单、支付、履约、售后，到最终的结算，期间遇到的问题也在一一化解。 在这个阶段我们完成了公司内3大交易系统的整合，并进行了 电商平台秒杀系统的架构升级[8] ，优惠券系统的架构升级，支撑了2020-2021的818晚会、双11、双12等大型活动的秒杀、发券场景。 另外我们也在积极探索 领域驱动模型DDD的理论与业界实践，并在发票总库系统的重构中进行了落地实践[9] ，这也为后续的平台化架构升级提供了技术支撑。
- 平台化架构阶段
在电商业务中台继续向业务的“逼近”过程中，系统的抽象和建设难度也成指数型增加，出现了一系列新问题：
1）随着建设中台项目的结束，人员的撤离，电商业务中台在集成这么多业务线的逻辑之后，代码里充斥着大量条件判断，每次需求迭代的开发成本和测试回归成本都很高，如何隔离不同业务之间的逻辑，减少业务之间的耦合度呢？
2）如何抽象出已接入电商业务中台的多条业务线的共性能力，以避免重复建设呢？
3）当新业务接入电商业务中台，如何基于已有的能力和解决方案快速组装上线，以支撑业务快速迭代创新？
4) 如何能够利用技术手段帮助产品运营日常工作提效呢？
综上所述，电商业务中台在建设过程中抽象业务线的共性能力以及共性能力的复用性设计与实现尤其重要，业务中台要做到能力复用和灵活多变才能让中台建设在企业的发展过程中起到降本增效的效果。系统架构必须升级，这就进入了平台化架构阶段。
平台化架构实践什么是平台化架构？就是要把基础能力跟每个业务方的特性业务拆分，要把业务和业务之间的逻辑进行隔离。平台化最核心的是业务抽象建模和系统架构的开放性，业务抽象解决共性的80%问题，系统架构开放性解决20%的个性化问题。
在参考 ThoughtWorks给出的《现代企业架构白皮书》的方案[10] 以及业界的互联网公司 美团[11]、有赞[12] 的中台解决方案，我们给出了适合之家电商平台的解决方案：通过领域驱动建模抽象出电商业务中台多业务线的共性能力并预留扩展点，然后利用服务编排对共性能力进行组合。其原理如图所示:
每一个在电商业务中台运行的业务可以理解为： 业务身份 业务流程 规则，业务流程通过流程服务编排来实现，扩展点通过扩展点机制来实现。 在整个交易流程中B端的商家入驻、商品发布相对通用，不同的业务的主要流程差别体现在订单收单前以及支付后的订单履约，这些流程往往都是需要定制化开发，为此整个解决方案核心在于订单平台化的架构设计。
