每年一次的双十一大促临近，因此上周末公司组织了一次技术交流闭门会，邀请了电商、物流、文娱内容、生活服务等知名一线互联网公司的技术大牛，一起探讨了一些大促稳定性保障相关的技术话题。
我作为会议主持人，也和这些技术大牛交流了很多案例经验，从他们身上汲取了很多新的思路和技术实践。我将其中一些比较干货的技术实践案例整理了出来，供大家学习参考下。
PS：出于脱敏原因，部分内容我已经做了处理，但不影响阅读。
大促典型场景及优化方案
1、云资源稳定性保障
-
单云模式存在一定稳定性风险，混合云架构在容灾方面效果更好；
-
核心链路梳理，可以将历史大促或者峰值的访问URL存储起来，经过处理后作为核心链路参考；
-
验证线上的性能容量搭建单独的仿真环境，为了避免和线上不一致，可通过一套标准的脚本来进行检查配置；
-
弹性伸缩容：设置动态扩缩容，超过固定的比例阈值，进行动态扩容（双十一零点峰值时候慎用）；
-
云资源保障方面，和云厂商提前沟通，尽可能将没有大促业务的公司服务器资源和自己公司放在同一个可用区或机房，避免资源共享&竞争导致的问题，同时邀请云厂商驻场保障也是很有必要的；
2、电商场景的性能优化实践
1）应用优化
-
火焰图、链路追踪分析是很好的问题分析助力工具；
-
利用监控，Arthas等工具探测链路在哪个方法/代码块耗时大，不断压测优化验证；
2）业务优化(深库存场景)
-
为了应对秒杀场景高并发，可以通过缓存+数据库方式来解决；
-
90%库存放缓存应对高并发；
-
10%库存放数据库应对超卖；
3）数据库优化(深库存场景)
-
阿里云RDS有针对库存更新的patch，可以到3000/s；
3、数据库稳定性保障的SOP
- 数据库的可用性底线：99.99%；
- 故障需要有严格的定义规则；
- 数据库稳定性三板斧：
1）扩容：DB是有状态服务，计算层便于扩容，将DB节点放到容器中，有需要扩容；
2）灾备：对于大流量读场景可通过流量切换方式，将部分流量迁移到备份集群分流；
3）巡检：慢SQL是常见的问题，可通过自动监控和历史数据分析，提供辅助式决策；
线上监控告警及容灾预案
1、如何做好监控告警？
-
关键路径收集；
-
容量指标限制；
2、除了基础监控，还有哪些关键监控指标？
-
线程池监控；
-
预估指标-容量规划；
3、分布式集群架构，单节点对整体的影响是什么？
-
单节点可能是关键节点，少量报错很难被发现，需要单点监控分析；
-
单节点出现问题可以T下线，通过日志等手段进行报错分析，保留现场；
4、除了基础监控，服务层会做哪些监控相关的事项？
-
数据库层也需要做好监控；
-
比较好的实践是双机热备，在数据同步方面需要有专门的保障机制；
5、高并发下，MySQL主备同步会有较大延迟，该如何处理？
-
采用MySQL的并行复制+写操作不刷盘方式；
-
非交易业务的查询放在备库，降低主库压力；
-
梳理落地SOP机制，遇到问题时首先快速线上止血，解决故障；
-
存在主备延迟情况，可以开启参数调整方式来处理(临时开启，快启快关) ；
-
同城双活架构下，可通过定时任务的方式自动检测MySQL的双0模式，定时改写数据；
-
高并发下MySQL主库往往写压力比较大，事务日志和binlog IO比较频繁，导致备库拉取binlog比较卡，较好的方式是通过降级延时方式做数据同步，保证最终数据一致性；
服务保护手段：限流降级熔断隔离
限流
-
限流的目的是控制访问应用的流量在系统承载范围内；
-
在业务请求入口（网关）限流，避免内部互相调用放大流量；
-
限流是个演进状态，从连接池、IP、指定SQL到更细的层级粒度做限流；
-
每个调用层都做限流，每个应用先保证自己可用，对其他依赖调用要做到“零信任”；
降级
- 降级：强依赖可以通过熔断的方式做紧急处理，弱依赖提前主动降级；
- 预案：分为主动预案和紧急预案：
1）主动预案：提前进行风险识别，然后针对性的方案，可以降低已知的风险；
2）紧急预案：假设出现重大的问题，才需要决策是否启用的方案（风险较大）；
3）预案平台：预案平台的目的是留痕，方便后续把预案恢复回来；
熔断
- 熔断下游强依赖的服务；
- 大促四板斧：关停并转。
1）双十一零点的前半小时， 做一个动态推送，把日志关掉；
2）真正流量来的时候，留一台机器来观察错误和异常的日志；
隔离
- 隔离：核心业务和非核心业务做隔离；
- 身份识别和业务隔离：
1）RPC group分组：假设有100个节点，40个给核心业务(交易)，60个给其他业务；
2）业务身份：中台架构可通过业务身份把订单秒杀等应用打上标记，便于隔离区分；
业务稳定性保障
-
涉及到交易订单&优惠券等和钱有关场景，线上造特殊数据进行实时定制化校验对账；
转载：https://www.cnblogs.com/imyalost/p/15522245.html