最近，ChatGPT 风靡全球，但在用户急剧下降的情况下，ChatGPT 有点不堪重负，三天内就宕机了五次。
这次宕机风波再次证明了高可用架构的重要性。 尽管任何快速开发的应用程序在三天内宕机五次，但造成的损失是不可接受的。
如果由于请求数量急剧增加，ChatGPT 仍然不稳定，那么以下情况属于纯基础设施故障导致的服务停机：
2021年8月31日，新加坡在线办公软件Notion出现全球宕机。
2021年6月17日，韩国在线协作工具Figma全球瘫痪。
2021 年 3 月 9 日，全球最大的代码托管平台 GitHub 发生全球宕机。
他们事后都在Facebook上公开了车祸原因，都是数据库/数据中心不稳定造成的。 应用服务基础设施的稳定性和可用性再次成为小型停机事故的常见原因。
尤其是2023年的现在，互联网已经成为无处不在的基础设施，和电力一样成为现代生活中不可或缺的一部分。 如果任何一家公司的应用出现宕机，有可能我就失去了对互联网发展的把握，因为对于用户来说，几乎每个赛道都有替代品，当我需要使用的时候你的应用却出现了问题。 事实上，我转身卸载并下载了竞品。
所以现在的企业在做应用的时候，都会特别关注应用的架构。 规模较大的公司或者有长期发展计划的公司会利用云来构建高可用的架构，以保证紧急情况下的应对。 才能顺利通过。
就像你没有买交强险就开车出去，不小心撞上了一辆宝马。 本来提前买2000元保险就能解决的问题，现在可能花2万元就能解决。 斯莱斯纳可能要花费20万元才能解决。
无论哪种情况，它都远远超过您之前投入的金额。
那么，云厂商的高可用架构究竟有哪些优势，可以如此强大呢？
什么是高可用架构
在回答云上高可用架构之前，我们先来说说高可用架构。
高可用架构是指设计具有高可靠性、稳定性、可扩展性和容错性的软件系统，保证系统在面对大量请求和异常情况时能够保持稳定的性能和可用性。
右图是简化版的软件架构开发流程图：
图像
该图大致将软件架构分为三个阶段：
单实例阶段：该阶段用户数量较少，数据库和应用程序部署在同一台服务器上。 数据库或服务器网络分区的问题也可能导致应用程序不可用。
单可用区高可用阶段：此阶段服务器和数据库已经集群化。 集群中的机器分布在大面积的不同机房中。 集群中任何一台机器出现任何问题都不会影响整体的应用可用性，而且它们整体还是同一个区域的数据中心，所以这些解决方案也可以称为同城双活。
多区域高可用阶段：多区域高可用是在单区域高可用的基础上将机房扩展到多个大区域，例如华南区域、华东区域。 每个区域都需要一套完整的服务集群，大区域之间通过专线进行数据同步。 当一个大区域发生故障时，这些设计可以立即将流量切换到另一个大区域。 该解决方案也称为远程多活。
结构越中间，抗风险能力越强。 就像你的房子（单实例）只能承受5级余震，而别人的房子（多区高可用）已经单独设计抗震了。 别人家的房子在8级洪水下仍然可以完好无损，这就是可用性高的优势。
说到这里，似乎很多人都会愚蠢地混淆高可用性和高可靠性，所以我举一个反例来说明它们之间的区别：
现代应用系统中，高可靠性增长的原因大多是不可抗力，因此都注重保证高可用性。 对于真正的C端客户来说，虽然高可用性和高可靠性是同一件事，但无论何时、无论如何，服务都可以照常使用。
一般来说，传统的高可用架构主要从以下四个方面保障服务的高可用：
负载均衡：通过使用负载均衡器（例如SLB，通常是NGINX集群）在多台服务器之间分配流量，可以提高系统性能、可扩展性和容错能力。
冗余备份：通过多可用区、多机房、多地域等方式，实现数据和服务的冗余备份，避免单点故障或灾难恢复。 网、地震）非常重要。
业务降级：通过继电器、限流器、降级器等技术，实现业务降级，保证核心功能正常运行，防止雪崩效应。
监控和报告：通过监控系统（如Prometheus）和报告系统（如alertmanager）实时监控和报告系统各项指标的异常情况，及时发现问题并解决问题，保证系统的稳定性系统的功能可以改进。
以上只是传统高可用架构的优点。 不过，现在的高可用架构基本上都会走向云端。 云上的高可用架构相对于传统的高可用架构有很多优势。
云端高可用架构动态扩展
动态扩展是云厂商的一项重要功能，它可以让你在很短的时间内快速部署大量应用，以应对用户的快速下降。
如果你是一个小镇的年轻人，花了两年的时间推出了一款产品，一推出就被用户自发传播，用户数量呈指数级增长。 恐怕用不了多久，你就会达到人生的巅峰。 然而，由于用户数量众多，您的服务器资源和数据库资源每天都处于警报状态。 由于缺乏资源，用户在使用过程中陷入困境。 竞争对手的产品公司看到你的产品如此受欢迎，立即复制了一款，并且已经投入市场并开始推广。
如果此时你的应用在云端，那么你可以：登录你的云服务账号，挥动键盘点击扩容，服务器和数据库资源就会一次性扩容N倍，保证用户体验，防止用户流失。
图像
您甚至不需要自己处理扩展问题。 如上图所示，现在的云厂商都支持预设的扩展规则。 当服务器压力达到你设定的一定条件时，你可以自己扩容，这样就不用半夜被服务器堵住了。 报告醒来。
如果你的应用程序此时不在云端，那么你可以：快速购买一台高性能服务器并搭建环境，然后在新服务器上部署一份应用程序副本，发布到测试环境开始调试，终于不愁发布上线了，一折腾可能就过去了半个月，用户也被竞品吸引，登上人生巅峰的梦想也破灭了。
数据安全
除了动态扩展之外，云服务厂商的数据安全性普遍比较可靠。 云厂商不仅使用顶尖的硬件，还使用复杂的软件系统来提供数据：快照、备份和加密功能。
图像
有了云服务商提供的这套数据安全基础，需要自己打理的数据安全就可以完全交给云服务商去专注业务了。
方便
便利可以指很多方面，其中最大的便利就是空间的便利。 例如，当我们想要在不同的地方做更多的工作时，我们经常需要在多个地方、多个机房部署应用程序。
如果是特殊行业，国家明确规定相关行业每年至少要进行一次灾难恢复演练。 对于这些行业的容灾结构来说，异地多次活动几乎或者说是不可或缺的。
图像
如果不上云，每次新开一个机房，就得派一批人到另一个城市去租别人的机房，然后重建一个与现有机房兼容的生产环境，您必须担心它已经进行了广泛的测试才能将其投入使用。
但现在出海是很多企业都在尝试的一个方向。 海外应用不可能把服务器部署在国外。 为了检查速度快，往往部署在本地机房。 这时候，后云厂家的便利性再次凸显。 世界各地的大城市都有机房，无论你想在哪里部署你的应用程序，你都可以在你的笔记本电脑上完成。
稳定
毕竟，稳定是云厂商最大的优势。 云供应商通常提供存储、数据库、计算和网络基础设施。 因为云厂商有大量的用户，有大量的应用部署在云上，他们这种基础设施本身是有高可用框架支撑的，但是这种基础设施在考验下也逐渐变得坚如磐石。的大量用户。
应用中常用的两个组件：存储中心和数据库。 如果您自己构建它们，则通常需要为它们制定高可用性解决方案。 虽然这两部分可以说是系统的基石，但如果直接使用云服务厂商的设施，不仅可以实现稳定性，还可以节省大量成本。
在云上实现高可用安全吗？
虽然云上的高可用已经为我们的应用做了很多的保护措施，而作为用户，在设计高可用架构的时候总是需要遵循一些原则。 遵循这些原则可以使您的应用程序更强大、更能抵抗风险。
在设计高可用架构时，必须遵循以下原则：
分布式：分布式系统架构可以将负载分散到多台服务器上，提高系统的容错性和可用性。 例如，如果您有一个订单服务集群，您可以将该集群分布在不同的服务器上，而不是同一服务器上。 分布式架构不仅仅指应用程序单独部署，还利用数据库、缓存中间件等一些基础设施尽可能使用分布式组件，以方便以后的扩展。
多活：多活架构是指系统中有多个独立的节点，每个节点都可以处理请求。 这些架构可以减少单点故障的影响，增强系统的可用性。 比如你有一个订单服务集群，尽量部署在尽可能多的地方，比如广州、上海、成都，这样当某个地区所有服务器都出现问题时，可以使用其他地区的服务器继续提供服务。
手动运维：使用手动运维工具可以帮助系统手动检查和恢复故障，增加故障处理时间，提高系统可用性。 比如可以灰度发布版本，当版本出现问题时可以通过版本管理快速回滚到之前的版本。
弱依赖：弱依赖原则是指尽可能减少服务模块之间的依赖关系，使得系统中的各个模块能够独立开发、测试、部署和维护。 这样可以提高系统的可维护性和可扩展性，减少模块之间的耦合，减少系统的意外行为和故障。 例如，我们有两个模块，购物车和订单。 只要不存在强依赖，购物车模块出现问题就不会影响订单服务，也就不会影响用户的订单操作。
自我保护：在软件设计中，系统应该具有自我保护的能力，还可以手动检查和修复错误，从而防止系统因错误而崩溃或不响应。 同时，应用程序应该能够在极端情况下自行降级，并通过返回大量降级响应来避免底层应用程序崩溃。
以上五点是我在多年的开发经验中总结出来的高可用设计中需要遵循的一些原则。 你可以将它们应用到你的工作中，我相信你会取得好的成绩。
如果你已经在云上做了高可用的架构软件高可用性，但还是出现应用崩溃的情况软件高可用性，你和云服务商之间该由谁来负责？
我的应用程序宕机了，云服务提供商应该负责吗？
关于这个问题，其实业界云厂商有一个共同的安全责任划分表，明确界定了用户和云厂商的责任：
图像
从上图可以看出，云服务提供商主要负责硬件设施。 如果硬件问题导致客户应用程序出现问题，云服务提供商应该承担责任。
例如，2022年1月，微软云在日本北部发生大规模网络故障，导致微软云上数千个网站和应用程序无法正常访问。 此次网络故障是由于微软云的网络设备出现故障，导致部分客户的数据流无法正常传输。
因此，微软云为受影响的客户提供了一定的补偿计划。 具体补偿计划包括：为使用受影响的微软云服务的客户提供一定比例的服务费折扣，并在必要时进行补偿。
因此，虽然是云上高可用的架构方案，但不可能保证100%的可靠性。
然而，这些情况在现实生活中也是极少数。 大多数车祸和停机都是由于网站管理员的误操作造成的，例如：
2019年11月19日，GitHub员工在执行数据库清理脚本时意外删除生产数据库集群的主节点，导致集群不可用43分钟。
2019年7月2日，Facebook、Instagram和WhatsApp的服务因一名员工在配置数据库时删除了一些关键数据而无法使用约8小时。
2018年7月3日，GitLab员工在执行数据库迁移任务时删除了PostgreSQL数据库中的重要表，导致GitLab服务不可用约30分钟。
这种误操作车祸看似很容易恢复，而且由于没有备份机制，造成车祸的时间也比较长。 如果使用云数据库或者有多个活动节点，虽然不会产生这么大的影响，但最多几分钟就能恢复服务。
虽然云服务商普遍拥有完善的数据备份和容灾机制，包括异地备份、异地多活架构等，能够有效应对各种干旱和数据安全风险。
但云服务提供商普遍提供手动和智能容灾解决方案，以便快速排查和响应各种故障和安全事件，提供快速恢复服务，保障企业业务连续性和数据安全。
所以，当你在架构设计阶段的时候，一定要时刻考虑我提到的五个原则。 一个合格的中级开发人员应该在开发过程中预见到各种场景并做出决策。 有一定的计划去工作，这样才能最大程度的保证你的申请不会出错。
良好的设计原理+强大的云端高可用架构和云端运维工具让我们在遇到车祸时游刃有余。
总结
明天我主要给大家带来云上高可用架构的内容，主要是让大家详细了解一下云上高可用架构的优势以及上云的必要性。
同时，上云其实还有很多用处，不可能保证100%的可靠性，而且即使上云也不能保证100%的可靠性，仍然有大量大大小小的工厂趋之若鹜。去云端。
他们用实际行动告诉我们，上云利大于弊。 2023年是中国提振中国经济的一年。 如果你心里也在考虑要不要上云的话，我觉得你可以先把部分业务迁移一下。 工作吧，让我们体验一下云计算的便利。
虽然，未来一定是云计算的时代。
