阿里是如何抗住双11的？看完这篇你就明白了!(3)

⑤无状态、一致性、并发控制、可靠性、幂等性、可恢复性…等。比如：投递了一个消息，如何保障消费端一定能够收到?上游重试调用了你的接口，保证数据不会重复?Redis 节点挂了分布式锁失效了怎么办?…这些都是在架构设计和功能设计中必须考虑的。

⑥尽可能的异步化，尽可能的降低依赖。异步化某种程度可以提升性能，降低 RT，还能减少直接依赖，是常用的手段。

⑦容错模式。

我在团队中经常强调学会“面向失败和故障的设计”，尽可能做一个“悲观主义者”，或许有些同学会不屑的认为我是“杞人忧天”，但事实证明是非常有效的。

从业以来我有幸曾在一些高手身边学习，分享受益颇多的两句话：

出来混，迟早要还的

不要心存侥幸，你担心的事情迟早要发生的

上图是比较典型的互联网分布式服务化架构，如果其中任意红色的节点出现任何问题，确定都不会影响你们系统正常运行吗?

限流降级

前面介绍过了限流和降级的一些场景，这里简单总结下实际使用中的一些关键点。

以限流为例，你需要先问自己并思考一些问题：

你限流的实际目的是什么?仅仅只做过载保护?

需要什么限流策略，是“单机限流”还是“集群限流”?

需要限流保护的资源有哪些?网关?应用?

水位线在哪里?限流阈值配多少?

…

同理，降级你也需要考虑：

系统、接口依赖关系

哪些服务、功能可以降级掉

是使用手工降级(在动态配置中心里面加开关)还是自动熔断降级?熔断的依据是什么?

哪些服务可以执行兜底降级的?怎么去兜底(例如：挂了的时候走缓存或返回默认值)?

…

这里我先卖下关子，篇幅关系，下篇文章中我会专门讲解。

监控预警

上图是我个人理解的一家成熟的互联网公司应该具备的监控体系。前面我提到过云原生时代“可观察性”，也就是监控的三大基石。

这里再简单补充一下 “健康检查”，形成经典的“监控四部曲”：

（编辑：ASP站长网）