阿里是如何抗住双11的?看完这篇你就明白了!
⑤无状态、一致性、并发控制、可靠性、幂等性、可恢复性…等。比如:投递了一个消息,如何保障消费端一定能够收到?上游重试调用了你的接口,保证数据不会重复?Redis 节点挂了分布式锁失效了怎么办?…这些都是在架构设计和功能设计中必须考虑的。 ⑥尽可能的异步化,尽可能的降低依赖。异步化某种程度可以提升性能,降低 RT,还能减少直接依赖,是常用的手段。 ⑦容错模式。 我在团队中经常强调学会“面向失败和故障的设计”,尽可能做一个“悲观主义者”,或许有些同学会不屑的认为我是“杞人忧天”,但事实证明是非常有效的。 从业以来我有幸曾在一些高手身边学习,分享受益颇多的两句话: 出来混,迟早要还的 不要心存侥幸,你担心的事情迟早要发生的 上图是比较典型的互联网分布式服务化架构,如果其中任意红色的节点出现任何问题,确定都不会影响你们系统正常运行吗? 限流降级 前面介绍过了限流和降级的一些场景,这里简单总结下实际使用中的一些关键点。 以限流为例,你需要先问自己并思考一些问题: 你限流的实际目的是什么?仅仅只做过载保护? 需要什么限流策略,是“单机限流”还是“集群限流”? 需要限流保护的资源有哪些?网关?应用? 水位线在哪里?限流阈值配多少? … 同理,降级你也需要考虑: 系统、接口依赖关系 哪些服务、功能可以降级掉 是使用手工降级(在动态配置中心里面加开关)还是自动熔断降级?熔断的依据是什么? 哪些服务可以执行兜底降级的?怎么去兜底(例如:挂了的时候走缓存或返回默认值)? … 这里我先卖下关子,篇幅关系,下篇文章中我会专门讲解。 监控预警 上图是我个人理解的一家成熟的互联网公司应该具备的监控体系。前面我提到过云原生时代“可观察性”,也就是监控的三大基石。 这里再简单补充一下 “健康检查”,形成经典的“监控四部曲”: (编辑:云计算网_泰州站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |