Open TFdream opened 3 years ago
转载：【vivo互联网技术】vivo 全球商城：架构演进之路：https://mp.weixin.qq.com/s/N1hq-sABMvi6edPJ7qfxyw
本文讲述 vivo 官方商城从单体应用到具备综合能力电商平台的演进，系统架构往服务化、中台化的变迁历程。
vivo官方商城，是vivo官方的线上电商平台，主营vivo手机及专属配件。经过几年发展，已经完成了从单体应用到具备综合能力电商平台的演进，整体系统架构也逐步往服务化、中台化变迁。我们在这条系统架构升级的道路中，实践出了一些系统架构经验。
通过本篇文章，可以让对电商感兴趣的小伙伴们，更为全面地了解最基础的电商业务模式，了解电商体系具备的技术和架构，了解系统在不同时期的架构演进。
“冰冻三尺，非一日之寒”。任何一个电商系统的架构升级，都不是一蹴而就的，都需要一个稳步发展的过程，不同阶段业务发展的形态和体量决定着系统架构。下面从一张图开始，给大家描述下商城近几年架构变迁的历史。
2015年之前，vivo官方商城是外包项目，采用了市面上比较成熟的 ECStore（企业级开源网上电商系统）电商产品作为系统基础，主语言是PHP。
项目版本就是在此基础上进行二次开发迭代。
和大多数电商平台早期的发展一样，满足快速部署、快速上线。
同时弊端也很明显：
为了解决这些问题，架构迫切需要升级、系统需要重构。
2015年5月，vivo官方商城正式启动重构计划。vivo启用自己的研发团队，目标很明确，自研一套属于自己的vivo官方商城，为用户提供更好的购物体验。
在2016年1月，属于我们自己的vivo官方商城正式上线了。
商城v1.0以主流的 Java 作为开发语言，采用经典的 MVC 框架，开发出了一个囊括了各个业务模块的单体应用，整体业务模块如下图所示：
相比之前，这次重构最重要的指导思想就是“分层”。
业务上对各个模块进行逻辑分层。划分出了商品模块、订单模块、营销模块、结算模块等等，使得代码逻辑更为清晰。
架构上也进行分层解耦： 【表现层】– 最贴近用户的一层，主要用来处理数据展示逻辑并渲染数据； 【服务层】– 负责表现层与数据层之间的业务逻辑； *【数据层】– 负责数据的落地存储，存储介质使用常用的Mysql和Redis；
单体应用的时期，vivo官方商城业务发展尚处于初期，业务复杂度不高。首页、商详页、结算页逻辑比较简单轻量。
v1.0的架构完全能够满足支撑日常的新品及活动运营，且版本迭代更为快速。相比于ECStore 性能提升了至少两个量级，所以商城v1.0的重构非常成功。
官方商城 v1.0 架构升级之后，平稳地度过了一段时间。近两年，vivo手机产品越来越多，线上业务开始迅猛发展。
随之而来的是用户量级的快速增长，商城v1.0的单体架构弊端也逐渐暴露：
基于以上问题，我们开始基于业务模块进行垂直的系统物理拆分。新的系统架构采用主流的SOA架构（Service Oriented Architecture，即面向服务的架构）。
商城 v2.0 从2017年开始，以服务化为核心稳步进行拆分独立。我们得保证既有的业务不受丝毫影响的情况下独立模块，有人形容这个过程为“高速换轮胎”，动作稍有不慎，对系统来说都是致命的。
最终在花了近一年半的时间，我们实现了活动、商品、订单、优惠券四大核心系统的拆分。拆分出来业务线开始各司其职，提供服务化的能力，共同支撑主站业务。
下面将介绍各个系统拆分的整个过程。
官方商城作为vivo的唯一线上官方渠道，承载着所有新品的线上活动需求。每次的新品发布会，都是由商城系统负责完成。大量频繁的活动需求，引起频繁的商城版本变更、上线，引发我们的思考。
相比电商的核心交易链路，活动系统本身比较独立，不应与主线交易耦合在一起。因此在2017年年中，将商城中的专题页配置，新品发布会，抽奖，预约功能剥离出来，独立出了商城活动系统。
2017年8月，活动系统独立上线。新的活动系统开始承接新品、大促等各种促销活动需求。随着活动系统不断迭代发展，目前已经成为电商平台一个重要组成部分。
商品系统是支撑整个电商平台的核心，是电商系统中最重要的组成部分。商品连接着用户和平台，通过商品的详情页可以完美地向用户展示产品内容，诠释产品内涵。
商城 v2.0 服务化，商品是这次整改的重点。
我们在思考v1.0架构带来系统性问题的时候，也开始思考如何通过这次拆分来对应未来的业务增长。商城v1.0商品模块亟待解决的问题：
商品系统的独立是带着以上的问题和思考进行的，大的目标是划清业务边界，彻底和商城解耦。我们希望分离后的商品系统能够更好、更快速地承接未来全品类的扩展，全面服务化。为进一步服务好商城主体业务夯实基础。
优惠券是业界内常用的营销手段之一，每到大促、节假日、新品，都会发放大量的优惠券。与外部广告商合作、内购福利、保值换新等也以优惠券的形式承载。
随着营销活动力度加大，优惠券使用场景增多，优惠券系统问题也逐渐暴露：
优惠券系统独立需要解决的就是以上问题，独立后优惠券存储能力提升，支撑未来5年内的优惠券发放量级。整体发券接口性能也得到提升，发券由原来的异步发券、异步到账，优化到同步发券、实时到账。同时提供平台级优惠券能力，面向全公司业务，提供通用的优惠券营销能力。
订单系统也有与优惠券同样的问题，随着用户量级的爆发式增长，性能问题逐渐暴露：
订单系统的独立，首次引入了 ES，Sharding-JDBC 等技术组件，解决数据量和高并发的痛点。订单系统上线后，无论是订单的存储量级还是下单的并发量级，都提高了不止十倍，至少满足未来 5 年的业务高速发展。
至此，商城核心系统拆分完成，各系统提供统一标准化服务，具备更纯粹的业务基础能力，与商城主站解耦，迭代效率大幅提升。
商城 v3.0 是针对商城业务快速发展，进行的业务系统完善。
这一阶段由于商城业务渠道不断扩展，促销玩法不断增多，商城衍生出很多独立的业务子系统。其中包含代销系统、CPS系统、促销系统 3 大业务系统。
为了丰富自身的商品品类，支撑起更多的运营玩法，我们开始探索代销的业务，尝试对接品类优质的平台方。很多平台方也都支持系统对接，采用以销定采的销售模式。
代销系统就在此背景下诞生了。我们希望代销系统能够成为外部平台方和vivo商城之间的“粘合剂”，并能够提供以下的主要功能：
本文讲述 vivo 官方商城从单体应用到具备综合能力电商平台的演进，系统架构往服务化、中台化的变迁历程。
一、前言
vivo官方商城，是vivo官方的线上电商平台，主营vivo手机及专属配件。经过几年发展，已经完成了从单体应用到具备综合能力电商平台的演进，整体系统架构也逐步往服务化、中台化变迁。我们在这条系统架构升级的道路中，实践出了一些系统架构经验。
通过本篇文章，可以让对电商感兴趣的小伙伴们，更为全面地了解最基础的电商业务模式，了解电商体系具备的技术和架构，了解系统在不同时期的架构演进。
二、架构变迁史
“冰冻三尺，非一日之寒”。任何一个电商系统的架构升级，都不是一蹴而就的，都需要一个稳步发展的过程，不同阶段业务发展的形态和体量决定着系统架构。下面从一张图开始，给大家描述下商城近几年架构变迁的历史。
2015年之前，vivo官方商城是外包项目，采用了市面上比较成熟的 ECStore（企业级开源网上电商系统）电商产品作为系统基础，主语言是PHP。
项目版本就是在此基础上进行二次开发迭代。
和大多数电商平台早期的发展一样，满足快速部署、快速上线。
同时弊端也很明显：
为了解决这些问题，架构迫切需要升级、系统需要重构。
2.1 商城 v1.0 单体时期
2015年5月，vivo官方商城正式启动重构计划。vivo启用自己的研发团队，目标很明确，自研一套属于自己的vivo官方商城，为用户提供更好的购物体验。
在2016年1月，属于我们自己的vivo官方商城正式上线了。
商城v1.0以主流的 Java 作为开发语言，采用经典的 MVC 框架，开发出了一个囊括了各个业务模块的单体应用，整体业务模块如下图所示：
相比之前，这次重构最重要的指导思想就是“分层”。
业务上对各个模块进行逻辑分层。划分出了商品模块、订单模块、营销模块、结算模块等等，使得代码逻辑更为清晰。
架构上也进行分层解耦： 【表现层】– 最贴近用户的一层，主要用来处理数据展示逻辑并渲染数据； 【服务层】– 负责表现层与数据层之间的业务逻辑； *【数据层】– 负责数据的落地存储，存储介质使用常用的Mysql和Redis；
单体应用的时期，vivo官方商城业务发展尚处于初期，业务复杂度不高。首页、商详页、结算页逻辑比较简单轻量。
v1.0的架构完全能够满足支撑日常的新品及活动运营，且版本迭代更为快速。相比于ECStore 性能提升了至少两个量级，所以商城v1.0的重构非常成功。
2.2 商城 v2.0 服务化
官方商城 v1.0 架构升级之后，平稳地度过了一段时间。近两年，vivo手机产品越来越多，线上业务开始迅猛发展。
随之而来的是用户量级的快速增长，商城v1.0的单体架构弊端也逐渐暴露：
基于以上问题，我们开始基于业务模块进行垂直的系统物理拆分。新的系统架构采用主流的SOA架构（Service Oriented Architecture，即面向服务的架构）。
商城 v2.0 从2017年开始，以服务化为核心稳步进行拆分独立。我们得保证既有的业务不受丝毫影响的情况下独立模块，有人形容这个过程为“高速换轮胎”，动作稍有不慎，对系统来说都是致命的。
最终在花了近一年半的时间，我们实现了活动、商品、订单、优惠券四大核心系统的拆分。拆分出来业务线开始各司其职，提供服务化的能力，共同支撑主站业务。
下面将介绍各个系统拆分的整个过程。
2.2.1 活动系统独立
官方商城作为vivo的唯一线上官方渠道，承载着所有新品的线上活动需求。每次的新品发布会，都是由商城系统负责完成。大量频繁的活动需求，引起频繁的商城版本变更、上线，引发我们的思考。
相比电商的核心交易链路，活动系统本身比较独立，不应与主线交易耦合在一起。因此在2017年年中，将商城中的专题页配置，新品发布会，抽奖，预约功能剥离出来，独立出了商城活动系统。
2017年8月，活动系统独立上线。新的活动系统开始承接新品、大促等各种促销活动需求。随着活动系统不断迭代发展，目前已经成为电商平台一个重要组成部分。
2.2.2 商品系统独立
商品系统是支撑整个电商平台的核心，是电商系统中最重要的组成部分。商品连接着用户和平台，通过商品的详情页可以完美地向用户展示产品内容，诠释产品内涵。
商城 v2.0 服务化，商品是这次整改的重点。
我们在思考v1.0架构带来系统性问题的时候，也开始思考如何通过这次拆分来对应未来的业务增长。商城v1.0商品模块亟待解决的问题：
商品系统的独立是带着以上的问题和思考进行的，大的目标是划清业务边界，彻底和商城解耦。我们希望分离后的商品系统能够更好、更快速地承接未来全品类的扩展，全面服务化。为进一步服务好商城主体业务夯实基础。
2.2.3 优惠券系统独立
优惠券是业界内常用的营销手段之一，每到大促、节假日、新品，都会发放大量的优惠券。与外部广告商合作、内购福利、保值换新等也以优惠券的形式承载。
随着营销活动力度加大，优惠券使用场景增多，优惠券系统问题也逐渐暴露：
优惠券系统独立需要解决的就是以上问题，独立后优惠券存储能力提升，支撑未来5年内的优惠券发放量级。整体发券接口性能也得到提升，发券由原来的异步发券、异步到账，优化到同步发券、实时到账。同时提供平台级优惠券能力，面向全公司业务，提供通用的优惠券营销能力。
2.2.4 订单系统独立
订单系统也有与优惠券同样的问题，随着用户量级的爆发式增长，性能问题逐渐暴露：
订单系统的独立，首次引入了 ES，Sharding-JDBC 等技术组件，解决数据量和高并发的痛点。订单系统上线后，无论是订单的存储量级还是下单的并发量级，都提高了不止十倍，至少满足未来 5 年的业务高速发展。
至此，商城核心系统拆分完成，各系统提供统一标准化服务，具备更纯粹的业务基础能力，与商城主站解耦，迭代效率大幅提升。
2.3 商城 v3.0 业务系统拓展
商城 v3.0 是针对商城业务快速发展，进行的业务系统完善。
这一阶段由于商城业务渠道不断扩展，促销玩法不断增多，商城衍生出很多独立的业务子系统。其中包含代销系统、CPS系统、促销系统 3 大业务系统。
2.3.1 代销系统：商城与代销商品纽带
为了丰富自身的商品品类，支撑起更多的运营玩法，我们开始探索代销的业务，尝试对接品类优质的平台方。很多平台方也都支持系统对接，采用以销定采的销售模式。
代销系统就在此背景下诞生了。我们希望代销系统能够成为外部平台方和vivo商城之间的“粘合剂”，并能够提供以下的主要功能：