一个云服务商带崩了最火的两大热门社交与娱乐的平台，今年4个9 99.99%的目标又是谁的KPI呢？
大家好，我是皇子。
据阿里云客户服务中心反馈，北京时间 2024年07月02日10:04，阿里云监控发现上海地域可用区 N 网络访问出现异常，阿里云工程师正在紧急处理中。
然后戏剧性的是 #小红书崩了 #B站崩了 的话题相继登上热搜。
当日 10:21 时，B站（哔哩哔哩）App用户（UP主）遭遇无法使用浏览历史、关注、消息界面、更新界面等问题，视频评论区和用户主页也无法加载。
B站客服界面显示“服务器正在休息”。
随后，也有不少网友反映#小红书崩了#刷新不出推荐内容。
虽然还是有一些内容能看到的，不过是非动态加载的，内容刷也刷不掉，体验还是差了不少。
而小红书客服则表示，对于小红书崩了一事已记录反馈，会尽快查看排查，用户可稍后再尝试使用。
不过很快，当日 7月 2 日 11：47，阿里云客户服务中心反馈再次反馈，经阿里云工程师紧急介入处理后，于 10:35 完成网络切流调度后，10:42 访问异常问题恢复。
这里，我们也可以稍微从中学习一些相关的技术点，比如：
什么是可用区 N 网络？
在云计算领域，可用区（Availability Zone, AZ）是指由独立的物理基础设施支撑的数据中心区域，它们通常位于同一地理区域内，但彼此之间在电力供应、网络连接和物理位置上是隔离的，以确保其中一个可用区发生故障时，不会影响到其他可用区的服务。
可用区 N 网络中的N代表的是特定的可用区标识符，并没有特殊的含义。不同的云服务提供商可能会有不同的命名规则。
例如，在阿里云中，一个地域内可能有多个可用区，如华北2（北京）地域支持 12 个可用区，包括北京可用区 A 和北京可用区 B 等。
建立多个可用区的意义在于：每个可用区内部署了独立的计算、存储和网络资源，以及必要的冗余和容灾措施，以提高系统的可用性和数据的安全性。
由此我们大胆猜想，小红书和B站此次大面积崩溃的原因涉及到了基础服务，如：用户服务、内容服务。而这个服务使用的又正好使用的是上海地域可用区 N 网络。
服务降级
从上面我们还发现，即使在网络服务不可用的情况下，B站和小红书应对的策略也不太一样：B站直接是拒绝了服务，而小红书这是返回了静态资源（也有可能是后端缓存资源），这样小红书这种体验自然会比B站好上不少。
站在服务层面，我们可以理解为小红书触发了服务降级，即在部分功能或服务不可用时，提供有限的功能或静态内容，以维持基本的服务水平。
服务可用性
回到开头的3个9和4个9又是指什么呢？--- 指的是一年中服务维持可用的时间，即服务可用性。
而服务可用性中的3个9和4个9是用来衡量系统或服务可靠性的一个标准，我们来看下在这个标准下，一年之中要达到这个要求，我们的服务不可用时间具体是多少呢？
3个9（99.9%）：意味着一年中服务不可用的时间不能超过8.76小时（大约等于1天）。
4个9（99.99%）：意味着一年中服务不可用的时间不能超过52.56分钟（大约等于0.7天）。
此次故障，据阿里云客户服务中心反馈，受影响的服务包括OSS、ECS、RDS、K8S、OTS、DTS、KMS、PolarDB、Redis、Mongo、ElasticSearch等。
从发现故障到影响恢复用时38分钟
这个故障切换与自动恢复能力还很强的，不过理论上应该可以更快的。
当然事情肯定不是那么简单的，具体故障细节等待官方披露。
最后，我们需要注意的是：
网络不可用是无法完全避免的
分布式系统设计中CAP定理，大多数都是允许分区容忍性（Partition tolerance）。
所以在CAP定理一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三个属性最多只能同时实现两个，不可能三者兼得中，我们大多数也选择在一致性和可用性中间选择和平衡，即CP或者AP。
第三方服务不可靠的
第三方服务不可靠就跟我们做接口设计时，相信的一个道理一样：别相信用户从前端传递过来的信息，除了认证授权信息，那么我们为了确保接入第三方服务器发生故障后服务仍能正常访问，可以哪些策略呢？
冗余设计：建立服务的多个副本或者使用多个第三方服务器供应商，这样即使一个服务器或供应商出现问题，其他服务器仍能继续提供服务。 负载均衡：通过负载均衡器分配请求到不同的服务器，当某一台服务器故障时，自动将流量导向其他健康的服务实例。 故障切换与自动恢复：实现自动检测和故障切换机制，一旦检测到某个服务或服务器不可用，立即切换到备用系统或资源，保证服务不间断。 服务降级：在部分功能或服务不可用时，提供有限的功能或静态内容，以维持基本的服务水平。 异地多活部署：在不同地理位置部署服务，确保即使某个地区的数据中心遇到问题，其他地区的服务还能继续运行。 定期演练与预案：定期进行灾难恢复演练，确保团队熟悉应对流程，并准备好应急预案以快速响应各类故障情况。 第三方服务监控：对第三方服务的可用性和性能进行持续监控，一旦发现异常，立即采取行动或通知供应商。
这些策略共同构成了一个高可用性（HA，High Availability）架构的基础，旨在减少单点故障对整体服务的影响，确保服务的连续性和稳定性。
既然看到这，点个赞、在看或者转发再走呀❤️
推荐阅读：
关于作者：一位热爱技术，并在职场与自媒体间探索的实践者，希望通过分享个人经验和见解，帮助更多人实现自我成长和价值。
可以在下方添加我微信和一支烟花AI社区技术群，一起交流技术、职场心得。欢迎～
原文作者：皇子谈技术；如有侵权，请联系管理员删除。
