2684亿！双十一背后的技术

所有不可想象，终将化作寻常；我们相信“相信”，一切都是新的。

2019年阿里巴巴双十一交易额：2684亿

作为技术行业者的你，是否对这数据背后的技术更感兴趣？

这千亿级的交易量，业务平台是如何支撑的呢？！按个人的经验和所了解的一些技术，对双十一的技术栈做一个整理。

---

限流熔断

• 服务限流 ：当系统资源不够，不足以应对大量请求，对系统按照预设的规则进行流量限制或功能限制
• 服务熔断：当调用目标服务的请求和调用大量超时或失败，服务调用方为避免造成长时间的阻塞造成影响其他服务，后续对该服务接口的调用不再经过进行请求，直接执行本地的默认方法
• 服务降级：为了保证核心业务在大量请求下能正常运行，根据实际业务情况及流量，对部分服务降低优先级，有策略的不处理或用简单的方式处理

服务降级的实现可以基于人工开关降级（秒杀、电商大促等）和自动检测（超时、失败次数、故障），熔断可以理解为一种服务故障降级处理

相关博文： 扛住阿里双十一高并发流量，Sentinel是怎么做到的？

---

多级缓存

首先我们需要明白，什么是一个多级缓存系统，它有什么用。所谓多级缓存系统，就是指在一个系统 的不同的架构层级进行数据缓存，以提升访问效率。
我们都知道，一个缓存系统，它面临着许多问题，比如缓存击穿，缓存穿透，缓存雪崩，缓存热点等等问题。为了解决一级缓存存在的风险和问题，产生了多级缓存的概念。

相关博文： 千万级并发！如何设计一个多级缓存系统？

---

缓存预热

缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
缓存预热解决方案：
（1）直接写个缓存刷新页面，上线时手工操作下；
（2）数据量不大，可以在项目启动的时候自动进行加载；
（3）定时刷新缓存；

相关博文： Redis系列十：缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级

---

降级预案

• 为什么需要降级：当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。
• 降级的最终目：保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）

相关博文：服务降级方案

---

异地多活

异地多活一般是指在不同城市建立独立的数据中心，“活”是相对于冷备份而言的，冷备份是备份全量数据，平时不支撑业务需求，只有在主机房出现故障的时候才会切换到备用机房，而多活，是指这些机房在日常的业务中也需要走流量，做业务支撑。冷备份的主要问题是成本高，不跑业务，当主机房出问题的时候，也不一定能成功把业务接管过来。

相关博文：业界异地多活高可用架构设计方案总结

---

前端静态化

网站的本质其实就是BS，这里的BS我没有带上架构二字，而就是指Browser和Server即浏览器和服务器，而网站静态化技术的作用目标就是让客户端即浏览器的用户体验更好，但是如果我们想让网站在浏览器上运行的更快，在更快的基础上能设计更多更好的用户体验功能，那么我们需要做的工作其实就不仅仅是着眼于浏览器本身，而是要把和浏览器相关的一切作用因子结合在一起考虑，这就是网站静态化技术的本源所在。

相关博文： 网站静态化处理—web前端优化—上

---

统一网关

API网关可以看做系统与外界联通的入口，我们可以在网关进行处理一些非业务逻辑的逻辑，比如权限验证，监控，缓存，请求路由等等。

相关博文：什么是API网关 如何设计亿万级统一网关

---

容量评估

容量评估是架构师必备的技能之一，场景的容量评估包括数据量、并发量、带宽、CPU/MEM/DISK等。
从而提前对系统和平台进行系统或功能的改造和升级，来达到支撑业务需求的目的。

相关博文：系统容量评估

---

双十一预演

双十一预演是在测试环境，提前把时间设置为双十一当天。当然，这里并非是通过修改系统时间来模拟，而是修改jvm的时间，来达到模拟双十一当天的效果。
这样，能达到提前测试双十一当天可能存在的业务问题和风险，从而提前发现业务问题。

---

全链路压测

基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。
针对业务场景越发复杂化、海量数据冲击下整个业务系统链的可用性、服务能力的瓶颈，让技术更好的服务业务，创造更多的价值。

相关博文：聊聊全链路压测

---

故障演练

伴随着海量请求、节假日峰值流量和与日俱增的系统复杂度一起出现的，很有可能是预料之中以及意料之外的各种故障。在很多情况下，由于事故处理预案的缺失或者预案本身的不可靠，以及开发人员故障处理经验的缺失，造成在各种报警之中自乱了阵脚，从而贻误了最佳战机。特别是一些平时线上没出现过的异常故障，一旦突然出现，往往措手不及。
系统是否足够健壮？是否有足够的能力应对故障的发生？当面临故障时会出现什么行为？我们并不希望真正线上出现故障时才去验证这些问题，这样风险太大，成本太大。所以希望在线上环境隔离真实流量的情况下，提前模拟产生各种任何可能发生的故障，来观察系统的反应，验证预期策略。

相关博文：
阿里电商故障治理和故障演练实践
如何做好一次故障演练？