电子商务应用框架分析 B2C电商系统产品架构的推演过程

B2C电商系统产品架构的推演过程

编辑导语：对B2C电商平台来说，一套电商平台需要的基础体系和支撑体系是必须的，而且每个体系都不是单纯独立存在的，而是全员联动。那这个体系是如何推演出来的？大体框架是什么？涉及什么体系？我们一起来看看。

首先我们确定一个共同的意识就是所有的产品经理，在对产品作架构之前都需要搞明白几个问题。

那就是：

电商产品经理也不例外，也需要弄清楚我们的目标用户，我在本文中称它为“人”。

与上面对应的能提供什么，我称它为“货”。

最后一个是这个服务在什么场合下诞生，我称它为“场”。

也就是说电商产品经理的架构设计解决的是人、货、场的问题，在详细的描述人、货、场的问题之前。

我们回想下我们去线下实体超市购买商品的场景：

所以在做电商产品架构的时候也需要从现实中的业务场景来进行映射。

我们再来针对上述的业务场景进行扩充。

用户在整个商品购买过程涉及到买和卖的双方，我们定义为普通用户和商家用户（就是超市）。

于此对应，针对这些线下购物场景，我们来做一次线上产品功能的映射，要怎么设计呢？

纵观所有的互联网产品，对用户的门槛只有账号注册业务（当然不同的业务生态对应的门槛条件也是不一样的，这里不再细说）。

与之对应的就是登录，登录之后又涉及到账号信息的修改和维护。

所以这块的业务本文称之为用户体系，为什么要有用户体系？

无论在传统的商务往来还是现代电子商务有一点是非常明确的，那就是始终离不开交易。

交易的双方就是买卖主体，那么对于一个电商平台而言，需要撮合的就是买卖双方能够在平台产生交易。

交易是和人有关系，这个人是谁？多大年纪？性别是什么？哪个地方的人？平时的消费习惯是怎么样的？

这就需要一个基础性的服务能够统计这些数据，并且能对这些数据进行加工和分析，更好的支撑商品的销售，这个服务性的体系就是用户体系。

说到这里第一个体系诞生了。

当然电商产品中的用户体系不仅仅只有上面说的注册、登录等等，还包含一些会员信息、等级信息、用户画像以及卖东西的商户信息等等；

接下来我们再来看看现实中购物的第二步也就是“询问导购员需要购买的商品，比如洗衣粉”。

那么这个场景实际上是用户向导购员表达购买商品的意图（你想买什么），导购员根据普通用户的意图按照既定的路径引导消费者进入目标商品专区。

我们尝试透过现象看本质，消费者询问导购员的目的是想快速找到自己期望的产品，本质是用户对商品的一种寻找行为。

笔者这里不说寻找，而是用搜索来代替，这种用户在超市搜索商品的行为我们可以直接映射到线上平台；

电商产品架构的第二个体系就是搜索体系，消费者通过这个体系能快速找到自己期望的商品。

这个体系有哪些功能，我们可以想一想；

上文中提到的消费者到超市寻找商品是一种搜索行为，只是这种搜索的行为在一定程度上依赖于导购员来完成。

搜索体系是现在市面上所有电商产品的必备体系，它能将用户购买的意图转化为商品的陈列展示。

另外搜索也是电商产品最大的流量入口，主要是通过关键词的召回与内容展示排序，关于搜索体系的细节，这里不再介绍。

前面一直在讲用户进入超市，通过导购员寻找自己想要购买的商品。

这里引入第三个体系——商品体系。

我在上文提到了，搜索体系，顾名思义，是通过这个体系来触达商品。

所以商品体系也就孕育出来了，所谓商品体系就是存放商品的体系，那么是不是只负责商品的存放呢。

当然不是，一个商品从进货、管理、到发货都需要在商品体系中进行统一管理和调度，除此之外还会涉及到用户退货、签收、前台商品页面的展示等各个环节的处理。

再来问大家一个问题：超市的商品是怎么展示在货架上的？

很明显，每家超市在管理商品的时候也是分区分类别进行管理，目的当然是提升商品的管理效率，降低管理成本，所以放在货架上的商品也是有章可循。

按照既定的规则从上到下、从左到右来按照制定的规则进行摆放。

所以，在电商产品的架构里面也会包含这部分的内容，涵盖前台商品列表怎么展示、同类型的商品信息能否共享、商品的详情页怎么布局、商品图片怎么摆放等等。

这块的内容引入第四个体系——内容体系，业内常称为CMS（Content Management System）体系。

电商产品架构中的内容体系专门负责商品信息页面的布局、页面组件、图片、页面各个空间的布局，最大化的利用有限的硬件界面资源去展示有用的商品信息。

另外还会涉及到UGC、PGC等内容的展示，当然内容体系不单纯只是用于展示商品信息，随着电子商务行业发展的逐渐成熟，CMS体系也逐渐被应用在页面广告、图标、页面组件等的应用。

超市里有了商品，用户自然就可以挑选自己的商品，那么在挑选商品的过程里可能对商品的参数、价格等信息需要和导购员进行沟通。

这个业务场景映射到线上，就需要有能和卖东西的商户进行沟通这样的功能业务。

这个就是我讲的第五个体系，即时通讯体系，也叫——IM体系。

IM即时通讯体系，简单的来讲就是在线沟通工具，作为买卖双方在整个交易完成前期唯一的沟通桥梁。

对于商家，其响应率、服务满意度都是一直努力的方向。

对于电商平台而言也是不可或缺的一项业务，这个里面涵盖了客服分流、坐席负载均衡、关键词回复等等基础功能。

有了内容、有了商品、有了搜索也有了用户，是不是电商的架构就完事了，当然不是，普通用户要想完成商品的购买需要依靠什么。

依靠的是支付，所有交易过程需要靠支付系统来支撑用户完成。

接下来说第六个体系—–支付体系；

支付体系一般比较复杂，有的公司是依托于三方支付机构搭建的内部支付网关体系，有的是具有三方支付牌照的第三方支付公司，复杂程度也不同。

一般情况下，对接三方支付搭建自己的支付平台是大部分公司能接受的（毕竟支付牌照不好申请）。

普通用户在电商平台去进行支付，首先要有支付方式供普通用户去选择，这个就是收银的台子（收银台）。

那么这个钱被扣到哪去了，又是怎么结算的，这个就是支付清结算体系的内容了。

好了，说到了现在，提到了用户体系、搜索体系、商品体系、内容体系、IM体系、支付体系，这些构成了一个电商产品的基础架构，但是不是一套成熟的体系只有这些呢？

也不是，我们在线下超市购物的时候还经常看到打折促销的活动，这个业务场景怎么映射到线上去？

同理，电商平台里面的卖家也就是上文中提到的商家。

商家为了提升店铺及商品的销售额，会在不同的季节、不同的时间推出各种各样的活动。

比如常见的满多少减多少、下单立减、拼团等，那么这些功能怎么通过线上来实现呢？

这个就需要一个促销系统，专门负责各类活动信息的维护。

比如活动的新建、上架、下架，通过促销系统来实现商品的销售，当然促销系统本不仅仅这么简单，这里不再细说，同样后续会推出促销系统的架构和产品设计；

另外随着活动的逐渐开展，难免会出现羊毛党，怎么去规避呢？

顾名思义，需要有一个系统能能够及时发现羊毛党，规避平台被薅羊毛的情况发生。

这个系统我们定义为风控系统，在普通用户发起交易之前风控系统就需要去提前预警该笔交易是否存在风险。

除此之外交易中和交易后都需要让风控系统进行全程干预，这个就是所谓的事前预警、事中侦测和事后分析统计。

当然风控系统对于每家公司并不是一个刚需系统，因业务、因规模而定。

除了以上说的，电商平台的产品架构还会涉及到数据体系、供应链体系、金融体系等等。

以上就是一套电商平台需要的基础体系和支撑体系，每个体系都不是单纯独立存在的，而是全员联动。

每个系统都承担着自己的职责，做好自己的本质工作，发挥着自己的作用，形成完整的一套电商产品架构体系。

本文旨在简单的普及电商产品架构的推导过程，后续将陆续针对不同的电商业务系统详细拆解分享给大家。

如果你对电商产品也有兴趣，欢迎大家来交流，我们一起共成长。

本文由 @产品研究站 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Pexels，基于CC0协议

全球大型电商测试基础架构设计概览

作者 | 茹炳晟

编辑 | Eva

本文为 eBay中国研发中心测试基础架构技术主管 茹炳晟关于“eBay高效能测试基础架构的前世今生”主题分享的部分节选，想了解全部内容，请在公众号后台回复关键词“高效能架构”获取完整直播视频。

“知其然知其所以然”是学习和深入理解技术本质的核心，面对大型网站的测试基础架构的复杂性以及测试框架的复杂性，作为测试架构师和资深测试开发工程师很有必要从根本上理解问题的本质和设计的初衷。但是如果直接讲解各个模块的功能以及设计固然能明白其作用和原理，但是其过程是相当地乏味，而且很难从业务驱动的层面理解问题的本质。所以本次极客 Live的讲解抛弃了传统的就技术谈技术的方式，而是采用业务驱动为切入点，以工程实际问题为主线，以提出问题到给出对应解决方案为主干，讲解大型电商网站的高效能测试基础架构是如何在业务的驱动下演进与发展的。

当今大型电子商务网站的测试基础架构和其他行业的测试基础架构相比，最大的特殊性在于“快”。一般传统 IT企业的产品发布是以“月”为单位的，所以在这种大背景下，测试执行的时间，测试用例的维护工作量以及测试用例的稳定性要求都不会成为关键问题。但是对于电子商务网站，尤其是具有全球业务的大型电商网站，产品上线周期都是以“天”甚至是以“小时”为单位的，这样就对全回归测试的执行时间，测试用例的维护工作量以及测试用例的稳定性有极高的要求。

比如全回归测试的时间不能大于 100分钟，API测试的稳定性要在 99%，GUI测试的稳定性要在 95%，失败用例的追踪和修复的时间周期小于 2小时等等，这些要求的实现都会与测试基础架构的设计有着直接的关系。换言之，如果没有一套高效能的测试基础架构和 CI/CD系统的支撑，这些目标的实现就会无从谈起。所以听众会发现互联网产品的测试基础架构设计原则都会围绕“唯快不破”这一基本原则。

围绕这一基本原则本次 Live主要涉及了以下几大块，并在最后结合 eBay的最佳实践介绍了全球大型电商测试基础架构设计概览。

GUI Automation Test Framework 前世今生

Test Data Platform 起源与发展

API Automation Test Framework 演进之路

Test Execution Environment 演变与创新

Test Report Platform 演变与创新

GUI Automation Test Framework 的前世今生

这个模块主要从最原始的 GUI测试开始讲起，然后逐渐深入，并从全局发展的维度阐述了 GUI自动化测试框架的发展，其中涉及了 Page-object模型的由来，Flow模型解决的问题和 Unified-Flow模型的原始驱动力等主要内容。

首先是从最原始的手工测试开始。最初的情况是，先有业务需求，然后业务需求会分解成功能需求，功能需求会变成测试需求。（举个例子，功能需求是做 login操作，但是分解成测试需求，就会包含 login的基本功能验证，并发情况下的 login验证，也会做安全相关的的验证，包括 SQL注入，跨站脚本攻击等，那就会有不同层面的测试需求。）然后这些测试需求都是在本地测试环境上进行手工测试验证。

随着手工测试用例的不断增多，以及版本快速发布引发的大量回归测试要求，单纯靠手工测试已完全不能满足项目的要求，于是最初的基于录制与回放技术的 UI自动化测试被广泛应用。最典型的就是 HP的 QTP（现在属于 MF，并且改名叫 UFT了），测试用例经过简单的录制就可以顺利回放，很大程度上减少了测试执行的人员工作量。

但是随着录制的测试用例数量不断增加，这些用例的维护就成了问题。录制 10个用例是很好，你录制 100个也觉得挺好的，但是当用例数量达到成百上千后，万一 UI有改动，所有脚本全部要跟着一起改，这样的维护工作量完全是不能接受的，尤其是对于大型项目。所以在这个基础上，我们为了解决大量脚本代码的应对 UI变化的可维护问题，我们把一些基于操作的测试步骤单独录制并定义成可重用的脚本 step，然后通过编辑的方式合并这些 step成一个真正能跑的测试脚本。我们把这种设计称为“基于操作的可重用脚本片段”。一个典型的应用例子是把 Login做成一个可重用的脚本，Logout一个可重用的脚本，然后当中的其他业务操作做成多个可重用的脚本，然后测试用例自己随便去拼接这些脚本以覆盖测试的场景。这种情况下，比如当 Login的 UI发生了变动，只需要修改 Login的脚本，而其他所有调用 Login的测试用例不需要做任何的改动。

虽然基于操作的可重用脚本很大程度上缓解了测试用例的维护工作量，但是这样的脚本片段的粒度控制还不是最高效的。举个实际的例子，由于前端控件升级，原本的输入框控件发生了变化，那么所有脚本中有输入框控件的都需要更新，另外的例子是如果某个页面元素发生了变化，那么所有涉及到这个页面的基于操作的可重用脚本都需要随之变动。所以更好的的设计应该是基于控件 +页面的可重用抽象，这就是非常典型的 Page-object模型。每一个页面都可以被封装成一个类，这个类里包含了页面上元素与控件的定义，测试用例是由调用页面元素的操作构成的集合。

进一步，为了让测试用例的拼装更接近业务，可重用脚本可以基于业务流程进行抽象封装。这样面向终端用户的 UI测试用例就是对业务流程脚本的拼装。这样的测试用例脚本就会更接近业务驱动 BDD，而且不仅测试人员可以拼装测试用例，产品经理或者项目经理也可以快速方便的拼装测试用例。

更进一步，为了应对电商业务的全球化发展，很多业务流程在不同的国家都会有轻微的差异性，比如同一个商品在美国售卖没有问题，但是在某些欧洲国家售卖就需要提供额外的信息，甚至是压根不允许售卖。为了应对这种业务差异性的需求，业务流程就会有在各个国家都有不同的·版本，对应地，测试的业务流程脚本就必须能够处理这种轻微的差异性，比如同一业务脚本可以支持不同的入口 page和出口 page，业务流程内部可以根据业务功能开关支持不同的分支等等，这就形成了 Unified Business Flow框架。同时，为了进一步降低 Page代码的维护工作量，我们还引入了自动化的 Page Code Generator。

全球大型电商测试基础架构的设计概览

核心理念是 Everything is a service，并由此提出了 Automation as a Service的架构。希望读者能从中根据自己公司的业务上下文对其进行裁剪或者进一步扩展改进。

......

最后我们谈一下优秀的测试基础架构所应该具有的特点来结束本文。

专一性：优秀的测试基础架构应该让测试开发者只需要关心自己的测试逻辑，而不需要去关注诸如测试在那里执行，测试数据怎么生成等非业务测试相关的内容。

统一性：优秀的测试基础架构应该能很方便地和各种 CI/CD集成，理想的情况就是 Unified Test Execution as a Service. 只要一个简单的 Restful调用发起测试请求，至于后台的测试框架，测试执行环境，测试报告等都对 CI/CD系统透明。

扩展性：当有新的测试框架（比如 Puppeteer，NightWatch等）需要接入的时候，基础架构的改动越小越好，甚至可以做到无缝接入。

灵活性：测试基础架构的各个模块可以按需加载使用，比如在我们的系统中，基于 AI的 Defect分类模块，多语言全球 Site测试比较报告模块等都是按项目或者 Phase加载的。

公众号后台回复关键词“高效能架构”获取完整直播视频

除茹炳晟老师之外，全球架构师峰会深圳站还邀请了诸多国内外顶尖架构师前来详解：

微信 数百亿消息收发背后的 Yard平台设计

菜鸟 全球跨域 RPC架构

滴滴 地图引擎架构实践和 AI技术应用

微博 个性化推荐引擎

Facebook 万亿级混合复杂时空数据的处理决策

Google研究院 ：TensorFlow在深度学习中的应用

...

更多内容欢迎识别下方二维码或点击 阅读原文 ，目前 ArchSummit限时报名，席位有限 ，如需帮助可直接联系票务小助手豆包（微信：aschina666，或致电 010-84780850）

相关问答

电子商务组织架构-企业、组织的整体结构形式电子商务组织架构概况地讲是指企业、组织或团队的整体结构形式。具体则是指企业、组织或团队在管理要求、管控定...

[最佳回答]1、互联网最基本的特征是:互动、共享、廉价;2、电子支票的使用步骤是购买电子支票、电子支票付款、清算;3、电子商务是3层框架结构,底层是网络平台,...

我是学电子商务的,我们若把电子商务形象化地看作是一座建筑物的话,那么中间的主题分为4层,而左右两旁各有一大支柱。主体4层:即3层基础和1层上层,自下而上...

高人,每个标点2分,你舍得么?我给你断句个先!

电商网站架构是一个很需要经验的活,基本需要面对的技术难题有瞬时高并发,稳定性,安全性,支付业务等。电商网站最高并发的挑战是抢购,如何能抗住抢购的流量...

掌握电子商务基本概念和分类。了解电子商务产生的基础。掌握企业间网络交易与中介交易业务流程。掌握电子商务功能与特征。了解电子商务的实现...

[回答]科学与宗教关系的三个层次1关于科学与宗教的关系,长期以来人们形成了多种学说或观点,如所谓的“冲突说”、“相互关联说”、“认识的不同状态说”、...

电子商务框架中的基础6指的是电子商务系统中必备的6个基本组成部分,包括:1.产品目录管理:对产品进行分类、描述、定价等管理。2.订单管理:处理订...

电子商务的论文类型可以是各种形式,以下是一些可能的论文类型:理论模型研究:这种类型的论文通常会提出一个全新的理论模型,用于解释电子商务中的某些现象或...

1、财务中心财务中心分管公司的财务、审计事项,同时对业务发展风险进行有效评估控制,反洗钱、反恐怖融资,管理备付金账户,进行业务清算,以及日常财务事项的...