聊聊高可用架构——异地多活

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 相较于目前主流的“两地三中心”,“异地多活”技术实现了质的飞跃,可以为用户“提供‘丝般柔顺’的用户体验”。本文就聊聊异地多活的高可用架构。
很久没写了,要长草了。
今天咱们来聊聊高可用系统架构的热点——异地多活。
现在比较吊的多活方式是异地三节点,有多少公司真正实现了就不得而知了。为什么要做异地多活,主要是为了提升系统的容灾能力,比如单机房的网络故障、地震火灾等不可抗因素,都有可能造成整个机房瘫痪。
在上一家公司负责支付系统开发的时候,由于我们在天津机房的硬件设施太过老旧,经常时不时地网络故障,进而逼我们搭建了一个异地多活的架构。我们先来看看我们当时的做法。整个部署结构如下图:
             7497cfece9ffdfacadf67f646a24dc1a7287510f
  1. 通过域名做负载均衡,将请求路由到最近的可用服务的机房
  2. 服务全部机房内自治,不进行跨机房访问
  3. DB(mysql)仅有一个,机房2跨机房访问机房1的DB进行读写
整个架构看起来是可行的,并且当时也是有在生产环境使用。但是不难看出,机房2的服务,在响应时间上肯定要比机房1更慢。因为跨机房访问数据库带来了一定的网络延时,在最正常的情况下,通过当时购买的专线,可以控制在数十ms以内。
当机房1故障时,通过dns切换(据说可以智能切换,不过我们当时并没有实施)关闭机房1的请求,然后将机房2的数据库从slave升级为master,就可以完成整个容灾过程。看起来并不是全自动的,但至少比服务长时间瘫痪等待机房修复要好。而且,dns切换以及db切换,都可以通过自动的方式来实现。
上面的方案实现简单,对于一般的业务也够用了。但是,存在以下几个问题。而这几个问题,也是异地容灾跨不过的坎。
  1. 机房间延时。不管是机房2访问机房1的DB,还是DB之间的主从同步,都进行了跨机房的网络请求,其延时是难以避免的。
  2. 专线网络需要花钱,而且不便宜。严格来讲,你拉一条专线网络,这也是一个单点服务。如果要做到专线网络容灾,价格应该至少要翻番吧。
  3. 数据同步。对于实时性要求不高的业务,比如微信发朋友圈,可以允许延时。但对于支付(账号余额)这种数据来讲,必须是强一致性的。如果机房1挂了,机房2备份库的数据还是一份脏数据,那必然会带来重大的损失。所以,这种数据同步方案,对于强一致性要求的数据,是不可接受的。对于强一致性的数据,只有通过人为修复确保都更新到位后,才能恢复服务。也就是在此期间,其实服务也处于不可用状态。
通过以上分析,我们不难看出,1.2两个缺点,可以勉强花钱解决,但是对于3,花钱也解决不了。那么,对于强一致性要求的数据,我们如何来做容灾呢?
  1. 机房1、机房2实现双主(Master-Master)的数据库架构。两个数据库分别置于机房1和机房2,实现读写。master之间通过mysql的内部实现,进行数据同步。这个方案其实跟之前的方案区别不大,只是减少了服务去访问数据库的网络延时,属于一个伪数据强一致性方案。而且双主很依赖网络延时进行数据同步,同时容易出现脑裂现象,个人不推荐使用。
  2.  通过业务层来实现分布式事务,以此来确保两个机房数据的强一致性。两个数据库分别置于两个机房中,通过业务程序来实现分布式事务,也就是通过业务层来确保数据库1和数据库2都更新成功,才视为更新成功。这样确实可以保证数据库1和数据库2的数据强一致性。但是增加了系统的实现复杂度,也增强了对开发人员能力的要求。另外,分布式事务会增加业务处理时长以及失败率,如果单机房故障一年都仅有几个小时,这种分布式的代价是否值得呢?
  3. 将服务状态化。对用户进行分区,将用户请求固定路由到机房1或机房2。如此一来,两个机房不会对同一份数据进行更新,也就避免了数据强一致性的要求。同时,这两个数据库之间,仍然通过主备进行数据备份。当其中一个机房故障时,通过人为修复该机房同步到另外一个机房的数据后,再恢复机房1中的服务。对比在上家公司已实现的方案,这种方案有两个优点:减小了跨机房访问数据库的延时;减小了受灾用户群体。个人觉得该方案不错,但是如何在dns解析域名时进行状态化呢?如果又引入中间件,那不是又单点了吗?

好吧,如果细读了CAP理论,就会发现这个问题是没有十全十美的解决方案的。在这个问题上,我更加倾向于的解决方案是:使用阿里云服务,增加可用性。你有更好的方案吗,欢迎给我留言。


本文转载自 微信公众号 chiukong_diary

原文链接 : http://mp.weixin.qq.com/s?__biz=MzI0MzQ5MzMwMg==&mid=2247483662&idx=1&sn=e45bf4b395e727f543edc827fc050ee5&scene=1&srcid=0814e9DLDRSshqsi6PaGq116&from=groupmessage&isappinstalled=0#wechat_redirect


目录
相关文章
|
2月前
|
存储 Cloud Native 关系型数据库
PolarDB 高可用架构设计与实践
【8月更文第27天】 在现代互联网应用中,数据库作为核心的数据存储层,其稳定性和可靠性尤为重要。阿里云的 PolarDB 作为一款云原生的关系型数据库服务,提供了高可用、高性能和自动化的特性,适用于各种规模的应用。本文将详细介绍 PolarDB 的高可用架构设计,并探讨其实现数据安全性和业务连续性的关键技术。
58 0
|
3月前
|
关系型数据库 MySQL Serverless
Serverless高可用架构体验评测
Serverless高可用架构作为企业业务上云不得不考虑的一种低成本高可靠的方案,已经在多领域得到了非常好的验证。希望可以通过阅读文章,让你对Serverless架构得到更深的了解。
12569 21
Serverless高可用架构体验评测
|
2月前
|
运维 监控 关系型数据库
【一文搞懂PGSQL】7. PostgreSQL + repmgr + witness 高可用架构
该文档介绍了如何构建基于PostgreSQL的高可用架构,利用repmgr进行集群管理和故障转移,并引入witness节点增强网络故障检测能力。repmgr是一款轻量级的开源工具,支持一键部署、自动故障转移及分布式节点管理。文档详细描述了环境搭建步骤,包括配置postgresql参数、安装与配置repmgr、注册集群节点以及配置witness节点等。此外,还提供了故障手动与自动切换的方法及常用命令,确保集群稳定运行。
|
2月前
|
数据挖掘 关系型数据库 MySQL
Serverless高可用架构的解决方案体验
Serverless高可用架构的解决方案体验
148 6
|
2月前
|
弹性计算 运维 关系型数据库
云上Serverless高可用架构一键部署体验与测评
在数字化转型背景下,Serverless架构因其实现业务敏捷、降低成本及提升服务可靠性而备受青睐。本文以阿里云Serverless应用引擎(SAE)为核心,展示了一种高可用、低成本且易于扩展的解决方案。通过单地域双可用区部署,构建了具备自动伸缩与故障恢复能力的架构。借助阿里云的一键部署功能,大幅简化了搭建流程,实现了快速部署,并通过性能与成本分析验证了其优势。对比传统ECS,SAE在资源利用与运维效率上表现更佳,特别适合平均负载较低的应用场景。
|
2月前
|
弹性计算 运维 关系型数据库
Serverless高可用架构解决方案评测
Serverless高可用架构方案提供卓越效能与极简运维体验,支持服务托管、弹性伸缩及按量付费,有效降低成本并优化性能。一键部署快速启动,流程直观,文档详实;但在高级配置与特定场景实践方面指导有限。方案采用双可用区部署确保高可用性,自动故障切换保障服务连续。成本模型按需计费,减轻企业负担。功能上集成监控、日志与负载均衡,简化运维,加速上线。性能方面,秒级弹性伸缩保证资源高效匹配负载。总体而言,此方案竞争力强,特别推荐给初创公司及需灵活应对流量波动的场景。
144 2
|
2月前
|
运维 监控 负载均衡
如何构建高可用的系统基础架构
【8月更文挑战第15天】构建高可用的系统基础架构是一个复杂而系统的工程,需要综合考虑设计原则、关键技术和实践策略等多个方面。通过冗余设计、分布式架构、自动化与智能化等技术的运用,可以显著提升系统的可用性和稳定性。同时,加强运维团队的能力建设和制定完善的高可用性策略也是确保系统高可用性的重要保障。希望本文能为读者在构建高可用系统时提供有益的参考和借鉴。
|
2月前
|
关系型数据库 Serverless 分布式数据库
阿里云 Serverless 高可用架构
阿里云的《卓越效能,极简运维,Serverless高可用架构》解决方案提供了全托管服务、自动扩展、高可用性、无缝集成以及内置安全等核心功能。该方案通过免除底层基础设施的管理,允许用户专注于应用程序开发,同时确保应用的稳定运行和资源的有效利用。 **核心功能简介**: - **全托管服务**:用户无需关心底层硬件,由阿里云负责维护和扩展计算资源。 - **自动扩展**:根据业务需求自动调整资源,确保应用在高峰期有足够的计算能力,低谷期则节省成本。 - **高可用性**:多地域和多可用区部署,实现故障自动切换,确保业务连续性。 - **无缝集成**:与阿里云的其他服务(如数据库、消息队列等)深度
|
2月前
|
关系型数据库 Serverless 分布式数据库
Serverless高可用架构
PolarDB在《Serverless高可用架构》中展现了零代码改造、极简易用与自适应弹性的特性,提供按需伸缩与计费服务。相比传统架构,它能自动调整资源满足不同负载需求。阿里云Serverless服务简化了开发者的工作流程,让用户专注业务创新。为了优化用户体验,可通过提供最佳实践、深化文档内容、增强社区支持等方式进一步提升。PolarDB不仅降低了迁移难度,还简化了数据库管理,确保资源高效利用,是企业数字化转型的关键技术支撑。
|
2月前
|
JSON API 网络架构
Django 后端架构开发:DRF 高可用API设计与核心源码剖析
Django 后端架构开发:DRF 高可用API设计与核心源码剖析
42 0
下一篇
无影云桌面