在传统的软件技术架构系统中，基本上将业务功能集中在单一应用内，或者是单一进程中。尽管现代化的软件架构理论以及设计原则已推广多年，但实际技术衍化的速度迟缓并且变革动力不足。 其中的原因存在着复杂性以及多样性，我想主要的原因是没有一套整体的解决方案能够让工程师在面临稳定性风险下，毅然决然地实施系统重构。当系统应用规模随着业务的迅速发展时，系统的重要性愈发突出，开发人员将对系统的改造尤为敏感，从之前的徘徊犹豫，随之变得更加保守，只能延续过去的技术方案，将功能不断地累积在原有的系统架构上。这样的系统好比是豆腐叠罗汉，叠得越高越危险。因此，当面临巨大的服务压力时，系统不得不通过扩容的方式，来支撑应对。俗话说，“船小好调头”，“头病医头，脚病医脚”。臃肿的系统使得扩容变得毫无针对性，牵一发而动全身。由于服务运行情况存在差异性，具体哪个功能存在性能瓶颈，又因服务并非孤立而存在，使得评估结果存在着主观臆断性和不确定性，这种相互影响和作用下，使得扩容变得异常的困难，扩容无法量化，最终导致 “水桶效应”。

当应用场景规模增大时，为了提高了开发以及执行的效率，并且使得更优雅或者合适的解决问题成为可能，开发人员将会评估和选择更先进的技术，推动演进。由于系统应用过分地集中了所有功能，其功能所需依赖服务以及执行库文件也随之变得庞大，当需要适配新的技术时，不仅依赖冲突难存在不确定性并且难以应付，进而使代码重构变得异常困难，增加了适配新技术的难度。

正因为功能集中于一身，让应用资源占用率变得越来越大，使得持续集成、回归测试、以及分发部署变得愈发困难。比如，应用部署包磁盘占变多，让编译、打包、分发以及启动时间变长，不确定性因素变得更大。当应用发布上线后，存在功能性缺陷，需要回滚时，这样的试错和时间成本变得更加昂贵。

越是功能集中式的系统架构，在开发工程中，越依赖于与执行环境。这种执行环境承载着数据、服务以及配置，如若其中那个环节出现问题，开发进程不得不被迫中断，而不断地诊断问题和调试环境，使得快速开发变得要不可及，更不要说在本地开发。由于对环境的过分依赖，使得系统的稳定性变得更不确定性。其一，由于服务相互依赖，而服务又依赖环境，开发人员对单元测试职业习惯以及依赖程度降低，使得测试环节减少，或者说更依赖于集成测试。其二，当测试人员在部署测试环境执行集成测试时，不但部署成功率不断地降低，而且执行过程时间不断地增加，压缩了开发时间，也可能导致项目滞后。不仅提高了系统风险，并且增加了心理负担。这么说来，无论是快速开发和测试都变得更加艰难。

以上分析还只是停留在那些熟悉业务和技术的成员，当业务快速发展时，其发展速度与开发效率比不断扩大，招募和发展新人是必不可少的手段。当面对如此巨大和复杂的系统应用时，业务和技术所需的知识变得特别杂糅，让新人有一种 “独上高楼望，尽天涯路” 之感，学习曲线陡峭。在实际的实施过程中，文档完整性以及指导的系统性皆存在不足。

如何解决单体架构存在的问题

单体应用给我们带来的现实问题：

• 扩容困难（Problems in scalability ）
• 部署困难（Problems in deployment）
• 发布回滚困难（Problems in release rollback）
• 适配新技术困难（ Problems in adopting new technologies ）
• 快速开发困难（Problems in RAD）
• 测试困难（Problems in testing）
• 学习困难（Problems in learning）

实际上，在解决单体应用的问题上，数年前，就出现了相应的解决方法，比如 SOA 的技术路线。

SOA 解决一个现实的问题，那就是服务与服务之间解耦，将古老的进程内服务调用，通过网络协议转化成服务之间的调用。从早期发明了 CORBA、RMI、COM+、XML-PPC 等技术，不过问题也随之出现，由于这些技术绑定在某种技术或者平台，比如 RMI 属于 Java 平台技术，COM + 属于微软技术体系，XML=PRC 没有统一的协议标准，因此对平台无关性的通讯需要的协议呼声强烈，这时一些典型的技术陆续出现，如 WebServices 以及 MessageQueue。以及它们的集大成技术 ESB。

其中的代表技术有：WSDL（Web Service Definition Language）、SOAP（Simple Object Access Prototol）等技术。由于这些通讯协议标准相对笨重，虽然目前仍在被广泛的使用，但逐步被淘汰是大势所趋。

为什么不选 SOA 而选微服务

面向服务架构（SOA） VS 微服务

类同

• 面向服务（ Service-Oriented ）
• 松耦合（Loose-Coupling）
• 自包含（Self-Contained）
• 平台无关性（Independent Platform）

差异

• 原子性（Atomic）
• 自治性（Autonomous）
• 开发运维体系（DevOps）
• 轻量级（Lightweight）
• 通讯协议（Communication Protocol）

微服务是粒度小的 SOA，正由于 SOA 体系庞大，不可能实现更好的原子性，并且它采用了统一统治的方式，例如 ESB 那样的大型解决方案。这样技术选型，针对单一的服务无法实现自行管理，无形之中增加了团队运维成本。开发人员不能很好的实施 DevOps 技术手段。同时，SOA 采用了 WSDL、SOAP 等重量级的通讯协议，增加了开发成本以及性能损耗。在微服务中，大多数服务 API 通过 REST 的方式暴露，这样大大地降低了适配的成本。

微服务是趋势

让我们看看 google 和百度统计的结果吧

图（1）Google 中 spring boot 的搜索热度

spring boot 和 spring cloud 是做微服务的最佳搭档。从图（1）上，我们能够看到 spring boot 2013 年在全球开始流行，一直到 2017 年 2 月到了 100 的热度。

图（2）google 中 spring cloud 的搜索热度

从图（2）上，我们可以看到 spring cloud 从 2012 年开始热度都是比较平和，在 2015 年 6 月之后，也就是微服务开始兴起的时候，spring cloud 开始迅速增长，在 2017 年 2 月达到了 100 的搜索热度。（地图上没有中国，估计是因为中国被墙掉了的原因）

图（3）百度搜索中 spring boot 的搜索热度

图（3）是百度地图统计的结果，我们可以看到 spring boot 在国内是 2015 年 6 月开始流行的，2017 年增长尤为突出。

图（4）百度搜索中 spring cloud 的搜索热度

图（4）我们可以看到，spring cloud 是从 2016 年 6 月开始在中国流行，往往新技术要在中国流行，都会落后硅谷一年，看看一年前的硅谷，就是现在的中国，所以大家也就能够判断到了 spring cloud 在中国的发展曲线了，也就是 2018 年 2 月 spring cloud 在中国的热度将达到顶峰。

虽然流行并不代表你需要。但是，既然流行就有他流行的原因，就有他优点。后面我们将回来认识下微服务。

什么是微服务

微服务是用一组小服务的方式来构建一个应用，服务独立运行在不同的进程中，服务之间通过轻量的通讯机制（如 RESTful 接口）来交互，并且服务可以通过自动化部署方式独立部署。正因为微服务架构中，服务之间是相互独立的，所以不同的服务可以使用不同的语言来开发，或者根据业务的需求使用不同类型的数据库。

微服务架构的优点与挑战

优势

• 服务简单，只关注一个业务功能
  传统的整体风格的架构在构建部署和扩展伸缩方面有很大的局限性，其服务端应用就像是一块铁板，笨重且不可拆分，系统中任何程序的改变都需要整个应用重新构建和部署新版本。在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。 而微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立且松耦合，单一功能的改变只需要重新构建部署相应的服务即可。

• 每个微服务可由不同团队开发
  传统的开发模式在分工时往往以技术为单位，比如 UI 团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，不同的服务可以采用不同的技术来实现，一个团队中应该包含开发所需的所有技能，比如用户体验、数据库、项目管理。

• 微服务是松散耦合的
  微服务架构抛弃了 ESB 复杂的业务规则编排、消息路由等功能，微服务架构中服务是高内聚的，每个服务都会处理相应的业务，所有的业务逻辑应该尽量在服务内部处理，且服务间的通信尽可能的轻量化，比如使用 Restful 的方式。

• 可用不同的编程语言与工具开发
  传统的软件开发中经常会使用同一个技术平台来解决所有的问题，而经验表明使用合适的工具做合适的事情会让开发变得事半功倍。微服务架构天生就具有这样的特性，我们可以使用 Node.js 来开发一个简单的报表页面，使用 C++ 来编写一个实时聊天组件。

挑战

• 运维开销
  更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。

• DevOps 要求
  使用微服务架构后，开发团队需要保证一个 Tomcat 集群可用，保证一个数据库可用，这就意味着团队需要高品质的 DevOps 和自动化技术。而现在，这样的全栈式人才很少。

• 隐式接口
  服务和服务之间通过接口来 “联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。

• 重复劳动
  在很多服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。

• 分布式系统的复杂性
  微服务通过 REST API 或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。

• 事务、异步、测试面临挑战
  跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案，而现在看起来，这些技术并没有成熟。

微服务设计原则

• 隔离
  服务必须设计为单独相互隔离工作。当你将一个整体单片系统分解成一组服务时，这些服务必须彼此解耦，这样才能更加连贯和自给自足。每个服务应该能够处理其自己的故障，而不会影响或破坏整个应用程序或系统。隔离和解耦特性使服务能够非常快速地从故障状态中恢复。服务的隔离特性具有以下优点：容易采用连续交付，更好的扩展，有效的监控和可测试性。

• 自治性
  隔离为自治性铺平了道路。 服务必须设计为自主自治的。它必须具有凝聚力，能够独立地实现其职能。每个服务可以使用良好定义的 API（URI）独立调用。API 以某种方式标识服务功能。自主服务还必须处理自己的数据。更流行的术语是多语言持久性，其中每个服务都有自己的持久存储。 自主还确保弹性。自主服务具有以下优点：有效的服务编排和协调，更好的扩展，通过良好定义的 API 进行通信，更快速和可控的部署。

• 单一责任
  服务必须设计为高度凝聚。单一的职责（责任）原则是服务只执行一个重要的功能。 单一责任与 “微观” 一词很好地结合。‘微’意味着小，细粒度，只与其责任范围内相关。单一责任功能具有以下优点：服务组合无缝，更好的扩展，可重用性，可扩展性和可维护性。

• 有界上下文
  您的服务应该有多大或小？ 答案就在于所谓有界上下文设计原则。这是一个关键模式，同时是领域驱动设计（DDD）建模方法。有界的上下文是关于微服务将提供其服务功能的上下文。它根据有关领域模型和识别离散边界，并相应地设计您的微服务，使其更具凝聚力和自主性。这也意味着跨边界的通信变得更有效率，在一个有界上下文中的服务不需要依赖于另外一个有限上下文中的太多的事情了。

• 异步通信
  在设计离散边界和使用其自己的有界上下文设计服务时，跨边界的服务通信必须是异步的。异步通信模式自然导致服务之间的松耦合，并允许更好的缩放。使用同步通信，会阻止调用并等待响应。 处于阻塞状态的服务不能执行另一个任务，直到接收到响应并释放底层线程为止。它导致网络拥塞，并影响延迟和吞吐量。异步通信还可以带来实现良好定义的集成或通信模式的概念，以实现涉及不同服务的逻辑工作流。

• 位置独立
  根据设计，微服务是在虚拟化环境或 docker 容器中部署。随着云计算的出现，我们可以拥有大量可以利用动态缩放环境的服务实例。服务可以在跨小型或大型集群的多个节点上运行。服务本身可以根据底层计算资源的可用性或效率来重新定位。必须能够以位置独立的方式来寻址或定位服务。通常，可以使用不同的查找发现模式来消费使用您的服务。服务的客户端或消费者不必烦恼部署或配置特定服务的位置。它只是使用某种逻辑或虚拟地址来定位服务。

1. 构建秒杀活动架构

1.1 说明

  系统架构的设计,一定程度上取决于流量的多少、流量的洪峰值和波谷值,有效的预估好流量是至关重要的一步,流量的大小不一样,我们的架构设计相应的也会不一样.这会影响到后续的系统架构设计.反而系统的搭建并不是最难的部分,因为现在很多大公司,都有一套自己的成熟架构体系

1.2 关键设计

1.2.1 围绕着产品设计,驱动技术.

  1).一般秒杀活动都是T+N的,这样设计的好处,就是提前帮我们预估好用户流量,这一步也会影响到我们是否扩容,至于坊间传说的临时扩容,本人一直持保守态度,显然对于大流量洪峰来临,这种临时扩容的方案还不够成熟,因为微博一直在砰砰打脸.
  2).秒杀活动前,来一波小游戏,有些人问是不是产品脑子冒泡?我是来秒杀商品的.....
  3).秒杀活动前,需输入12306式的验证码,产品是不是又该挨打?
  4).秒杀活动前,倒计时弹幕提醒,产品已gg

其实这些小伎俩的设计,一方面为了防止活动未开始前大流量涌入,一方面是为了防止恶意用户攻击,另一方面是为活动造势

1.2.2 缓存和预热

  1).页面静态话,静态页面部署在CDN服务器上,服务器多机房部署,异地多活,使得用户能就近访问到相应的节点服务器.
  2).redis双泳道
  3).热点数据提前落地

1.2.3 消息中间件MQ

  延迟队列、阻塞队列

1.2.4 限流、降级

  推荐sentinel开源中间件,sentinel是以流量为切入点,从流量控制、熔断降级、系统负载保护等多个纬度保护服务稳定性.sentinel和谷歌guaval不同的地方在于它可以做到全局性的限流.对于快到水位线时候,可以随机拒绝一些请求,做好保护.

1.2.5 网关拦截

  过滤和限制恶意请求和爬虫之类的,限制参与秒杀的用户需要登陆的token

1.2.6 是否查询数据库

  大型秒杀活动是可以不查数据库的,数据异步落库就行

2. 技术难点

其实在第一章节,我并没有过细的赘述,因为现在业界这些框架已经非常成熟了,拿来即用,甚至有些活动并没有那么的流量,可能都无需限流.

2.1 库存是否锁定

  是否锁定库存需要看场景,像卖林俊杰演唱会门票这种,是无需锁库存的,why?
  对于用户购买意愿非常强烈的活动中,是无需锁定库存的,一方面可以做到公平购买,另一方面防止一些用户其实就是看看的心态,下单了不付钱,导致那些真正想买的人买不到票.而一般的活动是需要锁定库存的,即用户预下单后就锁定库存,但是一般我们秒杀的订单都具有时效性,一般在5-30分钟不等.

2.2 如何释放库存

  1)首先查询库存,检查库存状况,库存不足直接返回前端.
  2)库存够,用户可以购买商品,用户预下单
  3)服务端构建用户订单消息,锁定库存,推送订单消息给延迟消费队列和更新订单缓存,调用预下单接口,然后调用第三方预支付接口
  4)前端唤起sdk去付款
  5)支付成功,第三方支付会回调通知商户,然后通知业务线去更新支付状态
  6)规定时间里面成功支付的订单,删掉缓存
  7)延迟消费队列监听,先查询缓存,看缓存数据是否存在,存在的为,超时订单,需要释放库存加1,缓存里面不存在的订单为成功支付的有效订单,落库

2.3 如何解决超卖的问题

redis本质上是没有办法保证是否超卖的问题,在高并发下这种现象很常见.以下提供一些解决方案,性能上可以根据实际情况做调整.

  1)悲观锁
  2)乐观锁
  3)分布式锁
  4)队列串行化
  5)异步队列分散
  6)分段锁

 

 

促销系统是电商系统另外一个比较大，也是比较复杂的系统，作为一个卖货的，当我们准备好了店铺、商品，那么剩下的就是卖货了。

但是，卖的好不好，有时候并不取决与你的商品质量，而是会不会营销，会不会做活动，甚至说即便你的商品质量不好。但是如果营销活动做得好，那也是可以卖的比别人挣钱的，所以促销活动很重要。它需要分析市场结合自身条件合理的创建促销活动，我们理解的促销活动可能是优惠券，满X减Y，和一些专题活动。

下面对促销活动进行一个系统的总结：广义上来说，一切为了扩大商家销售和用户优势的行为都属于促销活动。

鉴于软件行业和电商系统的特征，电商的促销系统设计应该是分为这几个大的分类：促销活动、CMS系统、优惠券、拼团。

• 优惠券：这大家可能很熟悉，设置优惠券的规则，然后进行发放，用户可以在购买商品的时候使用优惠券；
• 拼团：这大家也很熟悉，比如：拼多多大家可能都用过，简单来说需要设置拼团的人数，价格，当拼团人数达到时，拼团成功，然后进行发货。
• 促销活动：促销活动一般是与CMS系统一起用的，促销活动模块用于设置活动的规则，而CMS系统用户推广活动。其实来说CMS系统对技术的要求是很高的，一些小的电商是不支持CMS的，那么促销活动就会通过广告位进行推广，或者不推广。

先促销活动，再说优惠券，再说拼团，下面详细说说。

一、促销活动

促销活动是什么呢？

接触电商系统设计的产品经理肯定明白，促销活动与优惠券类似，都是在购买商品时如果满足促销条件或者优惠券的条件就会对用户的购买进行优惠。

不同点在于：优惠券是具体的东西，他与商品是分离的，优惠券更加灵活，而促销活动一般来说会与商品绑定，并且这种活动的制定可能还会与节日有关——清明节了，我要搞个促销活动，促销活动的目的性更强，既然是“活动”那么也就注定了推广的重要性。

这也就是为什么促销活动要与CMS系统连用，可以达到更好的宣传效果，下面我从几个方面说说促销活动：

1. 促销活动都有哪些形式，每种形式的规则是什么？
2. 促销活动具体的创建规则与业务流程？
3. 促销活动在订单中的问题。
4. 对促销活动的管理。
5. 促销活动在产品中的具体设计方法。

1. 促销活动的各种形式

满减促销：

满减促销是最常见的一种促销活动，当订单满足一定金额优惠一定金额，一般会产与多个订单，比如：满200减20。这样，为了能够获得优惠可能就会多买几件，满减促销分为两种形式：每满减和阶梯满减，在创建活动的时候只能选择一种形式。

什么每满减呢？

——每满X元减Y元，比如每满100元减10元，如果订单满足一个100元优惠10元，如果订单满足两个100元，优惠20元，以此类推。

什么是阶梯满减呢？

——满X1元减Y1元，满X2元减Y2元，满Xn元减Yn元，比如满100减10元，满200减300元，满300减50元。

显而易见阶梯满减是消费越多优惠比例越大，设置多个阶梯，如果设置了每满减同时设置阶梯满减肯定会有冲突的，因为订单金额相同时优惠金额可能不一样，也就是说，不能共用。

单品促销：

单品促销就很简单喽，就是一件商品打折。

这里说明一下哈，不仅仅是这里，所有的，你没看错，我是说所有的打折都支持两种选择，百分比打折和金额打折，在设置打折规则的时候进行单选百分比或者固定金额。

那么，百分比打折和固定金额打折不同点在于哪呢？

差异化的造成主要体现在价格的变动上，当价格变动对折扣打折是没有影响的。因为是按比例计算，而对于固定金额打折就会有影响，无论价格的过高或者过低，都会造成优惠金额的不合理。但是，固定金额打折的优势是易于消费者理解，优惠价格可控，对于资金的掌控更加稳定。

在进行百分比打折的时候，前端同时显示折扣比例和折扣金额。

套装促销：

套装促销就是多件商品捆绑销售，设置套餐价格，但是在设置的时候其他促销形式有所不同。不同点主要体现在前端的展示上，其他的促销获得是依附在某个商品之上的，当我们进入商品详情页就会看到促销活动的介绍。然后选择规格当，数量等信息，当选择满足条件后就会实现优惠。

而套装促销是多商品，下面的赠品促销，满赠促销也是一样，这种多商品的促销在展现形式上有所不同。

首先来说，我们在设置套装的时候肯定选择多个商品，而每一个商品肯定会有多个SKU信息，那么说我们在选择商品的时候应该精确到商品的SKU，也就是把规格选出来。

为什么要这样选呢？因为我们最终要设置套餐价格，那么这个套餐价格肯定基于某个确定的原价的，也就是每个套装商品的SUK价格。

其次，我们要考虑到前端的展示问题。

既然是促销活动，我们现在还原一个场景：

小张没有鞋穿了，要去商场买鞋，而鞋子肯定有很多规格，小张要买43码红色的鞋子100元，如果选择43码黑色的鞋子可能就是200元了。

这个时候服务员告诉他：我们现在搞套装活动，红色的鞋子加红色的袜子一共110元，红色的鞋子加红色的袜子一共120元，黑色的鞋子加红色的袜子一共210元，黑色的鞋子加黑色的袜子一共220元，红色袜子单独购买20元，黑色袜子单独购买40元。

那么，在这种场景下，小张的选择是多样化的，他可以选择任意的组合，然后给钱就行了。但是，如果把这种场景还原到产品设计中就会产生很多问题。

原因很简单：我们在线下购买商品，当我们提交订单之前，我们面向的是所有的商品。而在网上购物的时候，我们要进入某一个具体的商品才能看到促销活动——我们在网上看到一双鞋，然后活动是加上某个袜子110元，难道我们要返回首页在去寻找那个袜子吗，显然是不行的。

也就是说，套装的选择要在鞋子这个商品的详情页面完成，可是鞋子的商品详情页只能展示鞋子的，比如：尺码，颜色；是无法选择袜子的规格信息的。

所以，一般来说有两种处理方式：

1. 直接把套装做成商品。
2. 在商品详情页面增加套装选项。

直接把套装做成商品：

这个跟商品的编辑流程是一样的，我们在定义商品标题的时候，直接把它写成某个套餐，比如：化妆品套餐，然后利用规格设置不同的套餐价格。

比方说：套餐一牙刷+牙膏10元，套餐二牙刷+牙膏+杯子12元，套餐三单个牙刷5元，以此类推。但是，这种也可以实现套装促销的效果，但是这种方式却偏了促销系统的设计规则。其实根本没有促销规则，商品本身的设定就是套装也就没有规则可言。

在商品详情页面增加套装选项：

这种方式就是设置完套装后，在相关商品的详情页面在选择规格的时候增加套装选项。当选择某个套装后显示套装信息，套装信息是某个具体的SKU信息，套装和主商只能二选一，选择商品就不能购买套餐，选择套装就不能在选择商品信息了。

下面举一个例子：

有A B C D E 五个SKU信息，要进行不同的套装组合，AB AC AD AE BC BD DE ，这是7个套装。

那么，在我们进入A商品的详情页面时，套装信息就会显示所有的，因为跟它都有关。当我们进入B商品的详情页面时，显示AB BC 两种套餐，因为B只有这两种套装。同理，当我们进入E时，显示AE DA ,也就是说只显示跟当前商品有关的套装信息。这是这种设置方式，其实来说产品的设计形式没有固定的，我们也总在寻求更好的解决方案。

赠品促销：

赠品促销也是多商品，当我们在购买主商品满足赠品条件后，就会获得赠品，有两种方式：

1. 只要购买主商品就会获得赠品。
2. 购买一定数量才能获取赠品。

而赠送的形式也有两种：全部赠送，赠送一件或者N件。

在设置的时候我们首先要选择主商品、满赠条件——购买即赠还是制定购买数量赠送。

然后选择赠品——可以选择多个，是全部赠送还是部分赠送，对于赠品只需要在专题页面说明就可以了，然后在详情页面介绍赠品信息。

加价优惠：

加价优惠是当我们满足了一定金额，如果在多付一定的金额就会优惠多少，或者免费赠送什么。

比如：我们一共花了120元想去结账，然后系统提示你，当订单金额达到150元就是享受-20优惠，或者赠送某某商品。对于加价优惠要选择商品，然后设置当满X元，在加Y元时，优惠N元或者免费送F商品，这样设置。

多买优惠促销：

多买优惠促销就是买的越多，优惠越大，可以设置一定金额随便买几件，或者当几件的时候极则，规则的核心是商品的件数——也就是多买。

这个地方既然是多买，那么在设置活动的时候肯定要设置活动的商品池——可以逐个拉去，也可以按分类拉去，多买优惠只有在这些商品上才能生效，其他商品不生效，在设置规则的时候可以设置。

1. 订单满X件N折
2. 订单金额X元内任意购

根据具体情况设定。

定金促销：

定金促销一般会出现在商品预售的时候，当商品进行预售时，设置定金促销，用户提前付定金可以抵扣一定金额。

比如：定金30抵扣50，相当于优惠50元，当商品进行发售的时候付尾款即可完成订单。

2. 促销活动的创建规则与业务流程

促销活动的创建分为三个步骤：

1. 设置活动基本信息：比如活动的标题，活动时间？
2. 设置活动的规则：满赠促销还是单品促销，规则是什么？
3. 设置活动商品：参与活动的商品是什么？

创建完成。

2.1 设置活动的基本信息

活动标题：设置活动的标题，可以设置多个标题，不同标题的作用不同，根据需求看你需要几个标题，然后每个标题展示在哪里。

活动编码：活动的唯一编码，创建活动是自动生成，这种编码很常见，不仅仅是这里，比如订单的编码，账单的编码，这些编码的规则，一般与时间，用户，商品等联系进行组合设置。

活动时间：设置活动的时间，只有在时间范围内活动才生效，如果活动时间未到但是活动开启了，需要在前端进行倒计时提升。

推广渠道：商城一般会有很多用户端，选择活动在哪里投放：H5，公众号，微信小程序，支付宝小程序，APP，PC端商城。

限购数量：商品的限购数量，从这几个方面来考虑，每项都是默认不限购，之所以进行限购主要是考虑到库存的原因：

1. 每个商品的限购数量：当此商品卖出X件不在参与活动。
2. 商品的总数量：参与活动所有的商品一共多少？
3. 每个用户的限购数量：每个用户最多可以购买多少件，达到上限不可继续参与活动，

用户范围：活动的用户范围，当用户在范围内才能参与活动，否则无法参与活动，默认不限制用户范围。

1. 选择指定用户：从用户列表进行获取多个用户。
2. 用户会员等级：选择那个等级的会员才可以参与活动。
3. 用户分组：那个用户组才可以参与活动。

对于用户范围的限定，主要看后台是如何对用户进行分类的，根据这些分类记性限购，如果用户有标签；也可以根据标签进行限购——如果分新用户，老用户，也可以根据此限购，主要取决于系统的设置。

是否与优惠券通用：一般来说促销活动是不与优惠券通用的，现在市面上的电商促销活动又不会与优惠券通用，所以这个地方可以再后台写死，只要是参与促销活动的商品都不与优惠券通用。

推广链接：创建活动时会自动生成活动链接和活动二维码用户推广使用。

 

2.2 设置活动的规则

在上面已经介绍了活动的形式以及它们不同的规则，但我们设置完活动的基本信息后就要设置活动的规则分类两步：

1. 选择活动类型：满减，单品，套装，赠品，加价，多买，定金。
2. 不同的活动其规则肯定是不同的，然后设置活动的规则。

满减：

选择满减类型：阶梯满减、每满减

设置满减规则：

• 阶梯满减：满X1减Y1、满X2减Y2、满Xn减Yn……
• 每满减：订单每满X元减Y元

单品：

选择打折形式：百分比、指定金额

设置打折程度:

• 百分比：X%
• 指定金额：X元

套装：设置套装价格——X元

赠品：

1. 设置赠送条件：买即赠、买X件即赠
2. 选择赠送数量：全部赠送，部分赠送（赠送几件）

加价：

1. 设置当满X元时加Y元时生效
2. 设置奖励形式：减N员或者送F商品

多买优惠：设置多买形式——M件N折或者X元任意购

定金：设置定金金额X抵扣金额Y

2.3 设置活动商品

当我们设置完促销规则的时候就要选择活动商品了，不管是什么类型的活动都要选择活动商品。只是不同的活动选择商品的规则不一样，我们来看下：不同促销活动他们选择活动商品时，有什么不同？

• 满减：选择全部商品或者部分商品，部分商品可以根据分类，品牌进行筛选，可以手动制定某些商品。
• 单品：选择某一个商品。
• 套装：选择多个商品组合，每个组合代表一个套装，这里注意，套装商品的选择需要精确到SKU。
• 赠品：选择主商品，然后选择赠品，赠品可多选可单选，赠品要精确到SKU。
• 多买优惠：这个选择商品的形式有所不同，要选择商品池，构建一个商品的水池，水池里的商品即为活动商品的范围，用户参与活动必须到水池里选择商品。
• 加价：设置商品范围，如果奖励形式是赠品，需要设置赠品。
• 定金：选择定金商品。

2.4 活动创建完成

KO，到现在为止促销活动的创建已经完成，我们总结一些：

首先，定义活动的基本规则，这些基本规则肯定是通用的，它不影响活动规则。

然后，设置活动规则，不同的活动有不同的形式，而不同的形式有不同的设置规则。

最后，根据不同的活动规则选择参与活动的商品。

这样活动就创建完成了，这是促销活动的创建方式与流程。不管什么样的促销活动都可以这样来设置，要把基本设置，活动规则，参与商品相互分开，这样有利于我们理解。下面，最后说说促销活动在订单流程中的问题。

3. 促销活动在订单流程中的问题

当用户进行下单的时候，首先要判断：商品是否参与促销活动？参与哪个促销活动？

然后，判断：是否满足促销规则？满足哪个促狭规则？

最后，计算满足情况下，优惠的金额是多少？在用户订单付款页面要告诉用户优惠金额是多少？

• if(活动商品){哪个活动}
• if（规则1）{优惠金额计算}
• else if（规则2）{优惠金额计算}
• erse if（不是活动商品）（不计算优惠）

当用户下单完成后，多个商品可以放在一个订单下统一发货，不能统一发货需要进行拆单，订单的详细问题现在先不说，以后会专门讲订单。

4. 对促销活动的管理

促销活动的管理是管理已经创建出来的活动列表，主要管理的是活动的状态和编辑活动，删除活动。

编辑活动：当活动创建完成后可能因为一些原因需要修改，这个时候需要去编辑。

删除：删除活动后，活动将直接终止。

活动状态管理：未开始，活动中，以结束，是否投放。

• 未开始：活动时间未到。
• 活动中：处在活动时间内。
• 已结束：活动时间已过。

是否投放：当投放之后活动才会生效，投放状态与活动时间状态（其他三个状态）相互独立，互不影响，无论是否投放都有可能处在其他三个状态中的一个，时间状态是无法操作的，可以操作投放状态。

删除：直接删除活动，如果活动正在活动中，那么活动将直接终止。

5. 促销活动在产品中的具体设计方法

5.1促销活动的前端展示

促销活动在用户端的展示主要体现在详情页面和列表页面，当满足促销活动是要在商品的列表页面加上标签。

比如：

• “满减”：在商品的详情页面要加上促销栏目。
• “促销：满100件10元”，让用户可以看到，如果是套装商品和赠品，需要展示每个商品的SKU信息、商品图片、价格、规格等。

5.2 促销活动的后台设计

促销活动属于促销系统的一部分，对于后台的设计，活动管理和创建活动两个部分。

创建活动：一个创建活动的菜单，点击进去就是创建页面、填各种表单、最后保存，表单的内容上面已经说了，就是促销活动的创建流程。

活动管理：一个活动管理菜单栏，点击进去是活动列表，管理活动状态、投放状态、删除。

二、优惠券

优惠券与促销活动的不同点是：优惠券突出的是商品。

当我们要买哪个商品时，我们会考虑用哪个优惠券，而从设计上来说，专题活动要比优惠券难度高。

1. 优惠券的各种类型

现金券：优惠券直接抵扣现金，不设置使用门槛，比如：50元现金券，现金券之所以称之为现金券，就是因为它可以当做现金直接使用，相当于你自己的钱，没有订单金额的限制。

满减券：与促销活动的满减类似，当订单满足一定金额才可以使用优惠券，比如：满200减20元。

折扣券：在购买某些商品是可以进行打折，比如8折，那么100块钱的东西就是80元。

单品券：单品券是针对特定的商品才可以使用，指定特定商品后可以设置满减或者折扣或者现金券。

分类券：分类券是针对特定分类的商品才可以使用，指定分类后设置满减或者折扣或者现金券。

品牌券：品类券是针对特定品牌的商品才可以使用，指定品牌后设置满减或者折扣或者现金券。

平台券：平台券适用于所有的店铺的优惠券，无论在哪个商家，哪个店铺，都可以使用，优惠金额由平台承担。

店铺券：店铺券是入驻平台的商家自己发布的优惠券，只在本店铺有效，优惠金额由店铺承担。

2. 优惠券的设计规则

优惠券的设计规则分为三步：

1. 创建优惠券
2. 领取优惠券
3. 优惠券核销

2.1 创建优惠券

在创建优惠券的时候需要填写相关的信息，以及选择一些信息。

优惠券名称：给优惠券起一个名称。

选择优惠券类型：现金券，折扣券，满减券。

优惠券面值和使用条件：现金券（X元）、折扣券（满X元Y折）、满减券（满X元减Y元）。

推广渠道：优惠券的发放渠道：公众号、小程序、app、PC端商城。

有效时间：优惠券的有效时间，这里有两种时间的设置方式，相对时间和绝对时间；相对时间（用户领取后X天内有效）、绝对时间（开始时间——结束时间内有效），时间的设置应该应该精确到某年某月某时某分。

使用范围：设置优惠券的使用范围，全部商品可用，还是部分商品可用，如果是部分商品可用可以通过分类品牌进行筛选，最后可以选择指定商品不可用；也可以直接指定某些商品可用。

返还规则：返还规则主要考虑到退款退货的情况，从订单的流程上来说分为正向流程和逆向流程。

• 正向流程是指：用户正常下单最后收获，没有退款退货操作。计算订单金额时需要减去优惠券的金额，告诉用户优惠金额是多少
• 逆向流程是指：用户付款之后发生退款，退货操作

逆向流程主要考虑到优惠券的返还问题——怎么返还？

因为可能有很多个商品才同时满足优惠，用户如果仅仅退某款商品该怎么办，退款的细节以后讲订单的时候再说还涉及到一些结账分佣的问题，那么现在在这个地方优惠券的返还规则。

1. 统一不返还：优惠券用了就不能退了，不管你退货还是退款。
2. 优惠分摊：当多个商品满足优惠券使用条件但是用户退款某个商品时，以优惠券的形式返还给用户改商品分摊的优惠金额。优惠券的使用条件不变，比如用户用了一张满200减60的优惠券，订单有两个商品——一个60元，一个120元，根据权重，这减的60元属于60元商品20元，属于120元商品40元，用户退120元商品的就返还给用户一张满200减40的优惠券，那个也一样。

2.2 领取优惠券

优惠券的领取方式有两种：主动领取和被动领取。

主动领取：用户需要在我的优惠券界面主动领取才可以使用优惠券。

被动领取：直接发送给用户，默认领取。

2.3 优惠券核销

当用户下单时需要判断提示用户使用哪种优惠券，逻辑上分为以下几个步骤：

1. 从用户的优惠券列表中筛选可用的优惠券，是否是有效时间，是否在商品范围之内，这里用户未领取的优惠券一同计算。
2. 如果有多种优惠券满足使用条件默认给用户使用优惠金额最高的。
3. 如果金额相同默认为用户选择使用快过期的优惠券。

3. 优惠券的管理

优惠券的管理，主要是：统计优惠券的使用情况。

优惠券发放了多少？用户领取了多少？核销了多少？剩余多少？这些操作对应的时间是什么时候？

4. 优惠券的产品设计方法

4.1 优惠券的前端展示问题

我们主要考虑：优惠券在什么地方展示？展示的形式是什么？

——展示的位置主要有商品详情页面，个人优惠券中心页面。

商品详情页面需要展示用户领取的和未领取的包含在商品下的优惠券，只要是属于商品下的优惠券都需要展示出来。

个人优惠券中心展示用户所有的优惠券，已用的、没有用户，提供领取入口，用户进入可以领取优惠券。

4.2 优惠券管理的后台设计方法

优惠券的后台设计，分为两个菜单：创建优惠券，优惠券管理

1. 创建优惠券：点击创建优惠券菜单进入编辑页面，须填写先关信息，选择相关信息，表单内容为 2.2.1创建优惠券的各种信息可以去上面看；创建完成点击保存优惠券创建成功，在优惠券管理菜单里显示
2. 优惠券管理：主要以列表的形式展示优惠券。

优惠券的管理，主要是对优惠券的统计作用列表信息为下：

• 优惠券信息：优惠券名称，优惠券金额，使用条件
• 推广信息：展示推广的渠道
• 发放量、领取量、核销量。

如果是没有发放完成的优惠券可以执行停止发放或者继续发放操作，还可以执行删除操作，删除后前端的领券中心将没有优惠券，同时从后台的优惠券管理中删除。