61 lines
6.9 KiB
Markdown
61 lines
6.9 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
45 从双十一看高可用的保障方式
|
||
从这一课时开始，专栏内容进入最后一个模块，即分布式高可用系列，这部分的内容，我将以电商大促为背景，讲解系统限流、降级熔断、负载均衡、稳定性指标、系统监控和日志系统等方面的内容。
|
||
|
||
今天一起来讨论一下，在面对电商大促、秒杀抢购等高并发的业务场景时，都有哪些高可用的保障手段。
|
||
|
||
从双十一限制退款说起
|
||
|
||
每年的电商大促活动，规模最大的就是双十一促销，双十一已经从光棍节，演变成了国内最大的电商促销活动。每年的双十一，我都会买一些打折力度比较大的商品，特别是数码产品，比如相机、键盘等，相信你肯定也和我一样，有很多“买买买”的经历。
|
||
|
||
类似双十一、618 这种促销活动，都会设置整点抢购。不知道你在双十一零点下单的过程中，有没有经历过排队等待，或者系统不可用的情况呢？
|
||
|
||
另外，细心的你可能已经发现了，历年的双十一活动，当天往往是不支持退款的，几大电商网站都会提前发布公告，对和订单无关的业务进行降级，比如订单退款。
|
||
|
||
上面这些，都是系统高可用的保障手段。以限制退款为例，一方面从业务角度考虑，由于活动期间流量巨大，订单产生数量过大，需要节省平台和商家的人力资源，节省库存盘点等工作；另一方面，退款处理并不是核心流程，在双十一当天，商家也没有这么多的资源来处理退款请求，在服务治理中，这是典型的业务降级，保护系统，对非核心业务做降级处理。
|
||
|
||
电商大促的高可用保障
|
||
|
||
电商大促高可用活动保障的核心是什么呢？当然是稳定性了。
|
||
|
||
大促是对系统架构的大考，稳定性是技术保障的核心，大公司内部都有严格的故障管理手段，以及故障评级制度，业务团队出现一个大的线上故障，可能一年的绩效都要受影响。
|
||
|
||
在服务治理中有一个服务可用性的概念，服务可用性是对服务等级协议 SLA 的描述，我们平时说的 4 个 9、5 个 9，就是 SLA。在实际业务中，即使是 4 个 9 的可用性，可能也不足以满足业务需求。我们来做一个简单的计算，假设一个核心链路依赖 10 个服务，这 10 个服务的可用性是 99.99%，那这个核心链路的可用性是 99.99% 的 10 次方，也就是 99.9%，可用性直接下降了一个等级，关联服务再多一些，可用性会更低。
|
||
|
||
这是一个理想的估算，在生产环境中，还要考虑服务发布、部署等导致的停机情况，可用性还会降低，如果是银行业、金融业等对可用性非常敏感的行业，这个数字是远远不够的。
|
||
|
||
回到电商大促，我们结合电商的业务场景，讨论一下在电商大促时，如果要保证高可用性，可以从哪些方面入手呢？
|
||
|
||
第一个特点是海量用户请求，万倍日常流量，大促期间的流量是平时的千百倍甚至万倍，从这一点来讲，要做好容量规划，在平时的演练中需做好调度。目前大部分公司的部署都是应用 Docker 容器化编排，分布式需要快速扩展集群，而容器化编排操作简单，可以快速扩展实例，可以说，容器化和分布式是天生一对，提供了一个很好的解决方案。
|
||
|
||
第二点是流量突增，是典型的秒杀系统请求曲线，我们都知道秒杀系统的流量是在瞬间达到一个峰值，流量曲线非常陡峭。为了吸引用户下单，电商大促一般都会安排若干场的秒杀抢购，为了应对这个特性，可以通过独立热点集群部署、消息队列削峰、相关活动商品预热缓存等方案来解决。
|
||
|
||
关于活动商品预热，这里简单展开说一下，秒杀活动都会提前给用户预告商品，为了避免抢购时服务不可用，我们可以提前把相关商品数据都加载到缓存中，通过缓存来支撑海量请求。
|
||
|
||
在模块六“分布式缓存”中，我花了很多篇幅对缓存的高可用、缓存命中率等知识点做了分享，你可以回顾并思考一下，秒杀活动中如何预热商品数据，可以更好地支撑前端请求？
|
||
|
||
最后一点是高并发，支撑海量用户请求，对于业务系统来说就是高并发，QPS 会是平时的几百倍甚至更高。开发经验比较多的同学都知道，如果在系统设计时没有考虑过高并发的情况，即使业务系统平时运行得好好的，如果并发量一旦增加，就会经常出现各种诡异的业务问题。比如，在电商业务中，可能会出现用户订单丢失、库存扣减异常、超卖等问题。
|
||
|
||
应对高并发，需要我们在前期系统设计时，考虑到并发系统容易出现的问题，比如在 Java 语言中，高并发时的 ThreadLocal 数据异常，数据库高并发的锁冲突、死锁等问题点，进行针对性的设计，避免出现业务异常。
|
||
|
||
可以看到，电商大促面临的问题主要是支撑高并发和高可用，高可用常见的手段有缓存、消息队列，关于这两部分的内容，我们在前面课时中也花了很大的篇幅去介绍，这里就不再赘述了。
|
||
|
||
另外还有一点在大促时特别重要，那就是避免服务雪崩问题、链路问题、故障传导。
|
||
|
||
关于服务雪崩我们在模块三“分布式服务”中简单提过，除了对服务可用性的追求，微服务架构一个绕不过去的问题就是服务雪崩。由于微服务调用通常是通过一个链路的形式进行，各个服务之间是一个调用链，牵一发而动全身，某个服务提供者宕机，可能导致整个链路上的连续失败，出现整体超时，最后可能导致业务系统停止服务。
|
||
|
||
避免服务雪崩问题，可以从限流、降级、熔断、隔离这几个方面入手，我喜欢称它们为高可用的 8 字箴言，在本模块后面的课时中，我将继续深入讨论这几个知识点。
|
||
|
||
总结
|
||
|
||
这一课时的内容，以双十一电商大促作为背景，总结了电商大促的业务特点，业务开发中保证稳定性的关键，并且简单介绍了高可用技术保障的几个常见手段，包括我们在前面讲解的消息队列技术、缓存技术，以及后面要展开讲解的限流、降级、熔断、隔离、负载均衡等手段。
|
||
|
||
在你的工作中，在对系统进行高可用设计时，都做了哪些工作呢？比如如何进行容量评估，超出系统水位如何进行限流和降级，使用了哪些高可用技术中间件呢？欢迎留言分享你的经验。
|
||
|
||
|
||
|
||
|