高可用架构怎么选?常见多活建设这么一对比就懂了

标签: | 发表时间:2020-11-21 20:54 | 作者:
出处:https://dbaplus.cn

采用高可用系统架构支持重要系统,为关键业务提供7x24的不间断服务,已经成为众多企业保障业务稳定、持续运转的主要选择。

 

服务多活是高可用架构重要实施手段,本文介绍了一些业界常用的多活手段,例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。

 

一、为什么要做多活

 

随着移动互联网的深入发展,用户增长达到一定规模后,不少企业都会面临高并发业务和海量数据的挑战,传统的单机房在机器容量上存在瓶颈。

 

在一些极端场景下,有可能所有服务器都出现故障,例如机房断电、机房火灾、地震等这些不可抗因素会导致系统所有服务器都故障从而导致业务整体瘫痪,而且即使有其他地区的备份,把备份业务系统全部恢复到能够正常提供业务,花费的时间也比较长。

 

为了满足中心业务连续性,增强抗风险能力,多活作为一种可靠的高可用部署架构,成为各大互联网公司的首要选择。

 

1、多活场景 

 

多活架构的关键点就是指不同地理位置上的系统都能够提供业务服务,这里的“活”是指实时提供服务的意思。与“活”对应的是字是“备”,备是备份,正常情况下对外是不提供服务的,如果需要提供服务,则需要大量的人工干预和操作,花费大量的时间才能让“备”变成“活。

 

单纯从描述来看多活很强大,能够保证在灾难的情况下业务都不受影响,是不是意味着不管什么业务,我们都要去实现多活架构呢?其实不是,实现多活架构都要付出一定的代价,具体表现为:

 

  • 不同多活方案实现复杂度不一样,随着业务规模和容灾级别的提升,多活方案会给业务系统设计带来更大复杂度;

  • 不管采用哪种多活方案都难以完全避免跨机房甚至是跨地区服务调用带来的耗时增加;

  • 多活会带来成本会上升,毕竟要多在一个或者多个机房搭建独立的一套业务系统。

 

因此,多活虽然功能很强大,但也不是每个业务都要上多活。例如,企业内部的IT系统、管理系统、博客站点等,如果无法承受异地多活带来的复杂度和成本,是可以不做异地多活的,而对于重要的业务例如核心金融、支付、交易等有必要做多活。

 

2、多活方案 

 

常见的多活方案有同城双活、两地三中心、三地五中心、异地多活等多种技术方案,不同多活方案技术要求、建设成本、运维成本都不一样。

 

下面我们会逐步介绍这几种多活方案并给出每种方案的优点和缺点。选用哪种方案要结合具体业务规模、当前基础建设能力、投入产出比等多种因素来决定。

 

二、同城双活

 

同城双活是在同城或相近区域内建立两个机房。同城双机房距离比较近,通信线路质量较好,比较容易实现数据的同步复制 ,保证高度的数据完整性和数据零丢失。

 

同城两个机房各承担一部分流量,一般入口流量完全随机,内部RPC调用尽量通过就近路由闭环在同机房,相当于两个机房镜像部署了两个独立集群,数据仍然是单点写到主机房数据库,然后实时同步到另外一个机房。

 

下图展示了同城双活简单部署架构,当然一般真实部署和考虑问题要远远比下图复杂:

 

 

服务调用基本在同机房内完成闭环,数据仍然是单点写到主机房数据储存,然后实时同步复制到同城备份机房。当机房A出现问题时候运维人员只需要通过GSLB或者其他方案手动更改路由方式将流量路由到B机房。

 

同城双活可有效用于防范火灾、建筑物破坏、供电故障、计算机系统及人为破坏引起的机房灾难。

 

1、服务路由 

 

  • zk集群:每个机房都部署一个zk集群,机房之间zk数据进行实时双向同步,每个机房都拥有所有机房zk注册数据;

  • 路由方案:条件路由  > 就近路由 > 跨机房路由,尽量避免跨机房调用;

  • 订阅方案:consumer订阅所有机房服务,provider只向该机房zk集群进行注册。

 

2、数据双活 

 

  • MySQL:采用MHA部署方案,主从半同步方案保证数据一致性。读写分离、读就近路由到机房内数据节点、写路由到master节点所在机房;

  • Redis:Redis cluster模式主从同步,就近读、写路由主节点机房。采用原生主从同步跨机房写性能较低,也可以依靠CRDT理论构建多节点双向同步,实现机房就近读写,但是整体实现较为复杂。

 

3、同城双城方案评估 

 

1)优势

 

  • 服务同城双活,数据同城灾备,同城不丢失数据情况下跨机房级别容灾;

  • 架构方案较为简单,核心是解决底层数据双活,由于双机房距离近,通信质量好,底层储存例如MySQL可以采用同步复制,有效保证双机房数据一致性。

 

 

2)劣势

 

  • 数据库写数据存在跨机房调用,在复杂业务以及链路下频繁跨机房调用增加响应时间,影响系统性能和用户体验;

  • 保证同城市地区容灾,当服务所在的城市或者地区网络整体故障、发生不可抗拒的自然灾害时候有服务故障以及丢失数据风险。对于核心金融业务至少要有跨地区级别的灾备能力;

  • 服务规模足够大(例如单体应用超过万台机器),所有机器链接一个主数据库实例会引起连接不足问题。

 

三、两地三中心架构

 

所谓两地三中心是指同城双中心 + 异地灾备中心。异地灾备中心是指在异地的城市建立一个备份的灾备中心,用于双中心的数据备份,数据和服务平时都是冷的,当双中心所在城市或者地区出现异常而都无法对外提供服务的时候,异地灾备中心可以用备份数据进行业务的恢复。

 

 

两地三中心方案评估 

 

1)优势

 

  • 服务同城双活,数据同城灾备,同城不丢失数据情况下跨机房级别容灾;

  • 架构方案较为简单,核心是解决底层数据双活,由于双机房距离近,通信质量好,底层储存例如MySQL可以采用同步复制,有效保证双机房数据一致性;

  • 灾备中心能防范同城双中心同时出现故障时候利用备份数据进行业务的恢复。

 

2)劣势

 

  • 数据库写数据存在跨机房调用,在复杂业务以及链路下频繁跨机房调用增加响应时间,影响系统性能和用户体验;

  • 服务规模足够大(例如单体应用超过万台机器),所有机器链接一个主数据库实例会引起连接不足问题;

  • 出问题不敢轻易将流量切往异地数据备份中心,异地的备份数据中心是冷的,平时没有流量进入,因此出问题需要较长时间对异地灾备机房进行验证。

 

同城双活和两地三中心建设方案建设复杂度都不高,两地三中心相比同城双活有效解决了异地数据灾备问题,但是依然不能解决同城双活存在的多处缺点,想要解决这两种架构存在的弊端就要引入更复杂的解决方案去解决这些问题。

 

四、异地多活

 

异地多活指分布在异地的多个站点同时对外提供服务的业务场景。异地多活是高可用架构设计的一种,与传统的灾备设计的最主要区别在于“多活”,即所有站点都是同时在对外提供服务的。

 

1、异地多活挑战 

 

  • 应用要走向异地,首先要面对的便是物理距离带来的延时。如果某个应用请求需要在异地多个单元对同一行记录进行修改,为满足异地单元间数据库数据的一致性和完整性,需要付出高昂的时间成本;

  • 解决异地高延时即要做到单元内数据读写封闭,不能出现不同单元对同一行数据进行修改,所以我们需要找到一个维度去划分单元;

  • 某个单元内访问其他单元数据需要能正确路由到对应的单元,例如A用户给B用户转账,A用户和B用户数据不在一个单元内,对B用户的操作能路由到相应的单元;

  • 面临的数据同步挑战,对于单元封闭的数据需全部同步到对应单元,对于读写分离类型的,我们要把中心的数据同步到单元。

 

2、单元化 

 

所谓单元(下面我们用RZone代替),是指一个能完成所有业务操作的自包含集合,在这个集合中包含了所有业务所需的所有服务,以及分配给这个单元的数据。

 

单元化架构就是把单元作为系统部署的基本单位,在全站所有机房中部署数个单元,每个机房里的单元数目不定,任意一个单元都部署了系统所需的所有的应用。单元化架构下,服务仍然是分层的,不同的是每一层中的任意一个节点都属于且仅属于某一个单元,上层调用下层时,仅会选择本单元内的节点。

 

 

选择什么维度来进行流量切分,要从业务本身入手去分析。

 

例如电商业务和金融的业务,最重要的流程即下单、支付、交易流程,通过对用户id进行数据切分拆分是最好的选择,买家的相关操作都会在买家所在的本单元内完成。

 

对于商家相关操作则无法进行单元化,需要按照下面介绍的非单元化模式去部署。当然用户操作业务并非完全能避免跨单元甚至是跨机房调用,例如两个买家A和B转账业务,A和B所属数据单元不一致的时候,对B进行操作就需要跨单元去完成,后面我们会介绍跨单元调用服务路由问题。

 

3、非单元化应用和数据 

 

对于无法单元化的业务和应用,会存在下面两种可能性:

 

  • 延时不敏感但是对数据一致性非常敏感,这类应用只能按照同城双活方式部署。其他应用调用该类应用的时候会存在跨地区调用可能性,要能容忍延时,这类应用我们称为MZone应用;

  • 对数据调用延时敏感但是可以容忍数据短时间不一致,这类应用和数据可以保持一个机房一份全量数据,机房之间以增量的方式实时同步,这类应用我们暂时称为QZone。

 

加上两种以上非单元化应用我们的机房部署可能是下面这样,每个机房有两个RZone,MZone保持类似两地三中心部署方式,异地机房调用MZone服务需要跨地区、跨机房调用。而QZone每个机房都保持一份完整数据,机房之间通过数据链路实时相互同步。

 

 

4、请求路由 

 

1)API入口网关

 

为了保证用户请求能正确进入自己所属单元,每一个机房都会部署流量入口网关集群。当用户请求到达进入机房内最先进入到流量网关,流量网关能感知全局的流量分片情况,计算用户所处流量单元并将流量转发到对应的单元,这样就可以将用户请求路由到对应的单元内。

 

 

采用GateWayr转发方式可以确定用户单元从而将用户流量路由到正确位置,但是HTTP转发也会造成一定性能损耗。

 

为了减少HTTP流量转发量,可以在在用户请求返回的时候在cookie上带上该用户的路由标识信息。当用户下次在请求的时候请求的时候可以提前获取到路由标识直接请求到对应的单元,这种方式可以大幅度减少HTTP流量转发。

 

2)服务路由

 

虽然应用已经进行了单元化,但是依然无法避免跨单元调用,例如A用户给B用户转账,如果A和B所处单元不同,对B用户操作需要跨单元去调用,这个时候需要能将请求路由到B用户数据所在的单元。异地多活情况下RPC、MQ、DB等等中间件都需要提供路由能力,将请求能正确路由到对应的单元。下面以RPC路由为例说明异地多活下中间件是如何进行路由的,对于其他中间件(数据库中间件、缓存中间、消息中间件等)也是一样方法。

 

 

public interface ManualInterventionFacade {

    @ZoneRoute(zoneType= ZoneType.RZone,uidClass = UidParseClass.class)

    ManualRecommendResponse getManualRecommendCommodity(ManualRecommendRequest request);

}

 

上面展示了多活下的RPC接口定义方法,需要注明该RPC类型,如果是RZone服务必须要提供解析uid方法。下图展示了RPC注册中心路由寻址过程,和同城双活有一定的差异性。

 

 

 

5、数据同步 

 

QZone类型数据:这种数据只需要保证最终一致性,对于短暂不一致无影响,但是对延时非常铭感,例如一些算法、风控、配置等数据。这类数据基本上都是每个机房部署一套QZone,然后机房之间相互同步。

 

 

MZone数据:这类数据对一致性非常铭感,不能出现不一致,只能采用同城双活部署方式,业务需要能容忍异地调用延时。

 

 

RZone数据:这类数据每个Zone都有自己的主节点,如果数据不在该单元内需要路由到对应的节点去写。这类数据部署情况像下面这样:

 

6、方案评估 

 

1)优势

 

  • 容灾能力大幅度提高,服务异地多活,数据异地多活;

  • 理论上系统服务可以水平扩展,异地多机房突破大幅度提升整体容量,理论上不会有性能担忧;

  • 将用户流量切分到多个机房和地区去,有效能减少机房和地区级别的故障影响范围。

 

2)劣势

 

  • 架构非常复杂,部署和运维成本很高,需要对公司依赖的中间件、储存做多方面能力改造;

  • 对业务系统有一定的侵入性,由于单元化影响服务调用或者写入数据要路由到对应的单元,业务系统需要设置路由标识(例如uid);

  • 无法完全避免跨单元、跨地区调用服务,例如上面的转账业务。我们要做的是尽力避免跨地区的服务调用。

 

五、总结

 

本文讨论了一些多活建设的大体思路以及一些关键技术点的解决方案,各种不同方案对比。要建立起完整的异地多活能力远远比上面讨论的要复杂的多,需要对依赖的各种中间件、储存等做相应的单元化改造并配套完整的流量调度和运维管控能力。

 

由于篇幅限制本文并未详细介绍各种储存(例如Redis、MySQL)在多活下数据同步复制以及高可用方案,有兴趣的同学可以去深入了解这方面知识。

 

作者丨官网商城开发团队来源丨vivo互联网技术(ID:vivoVMIC)

相关 [架构 常见 建设] 推荐:

高可用架构怎么选?常见多活建设这么一对比就懂了

- -
采用高可用系统架构支持重要系统,为关键业务提供7x24的不间断服务,已经成为众多企业保障业务稳定、持续运转的主要选择. 服务多活是高可用架构重要实施手段,本文介绍了一些业界常用的多活手段,例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点. 随着移动互联网的深入发展,用户增长达到一定规模后,不少企业都会面临高并发业务和海量数据的挑战,传统的单机房在机器容量上存在瓶颈.

debezium 架构和常见使用场景

- -
Debezium是一个开源项目,为捕获数据更改(change data capture,CDC)提供了一个低延迟的流式处理平台. 你可以安装并且配置Debezium去监控你的数据库,然后你的应用就可以消费对数据库的每一个行级别(row-level)的更改. 只有已提交的更改才是可见的,所以你的应用不用担心事务(transaction)或者更改被回滚(roll back).

架构必备:Rate limiting 的作用和常见方式

- - 互联网技术和架构
Rate limiting 在 Web 架构中非常重要,是互联网架构可靠性保证重要的一个方面. 从最终用户访问安全的角度看,设想有人想暴力碰撞网站的用户密码;或者有人攻击某个很耗费资源的接口;或者有人想从某个接口大量抓取数据. 大部分人都知道应该增加 Rate limiting,做请求频率限制. 从安全角度,这个可能也是大部分能想到,但不一定去做的薄弱环节.

RESTful 架构风格下的 4 大常见安全问题

- - 文章 – 伯乐在线
伴随着RESTful架构风格的大量应用微服务架构的流行,一些本来难以察觉到的安全问题也逐渐开始显现出来. 在我经历过的各种采用RESTful微服务架构风格的应用中,某些安全问题几乎在每个应用中都会出现. 然而它们并非是什么高深的技术难题,只不过是借着微服务的流行而显得越发突出,这些都可以通过一些安全实践来避免.

【主数据架构】4种常见的主数据管理实现风格 | 首席架构师智库

- -
主数据管理(MDM)系统的基础是什么,这取决于您所认同的实现风格,这为项目成功提供了最佳机会. 这在很大程度上取决于您在数据管理方面的业务情况. 有几种不同的实现样式可供选择,主要的区别在于是否从中心集线器控制数据,还是将集线器与现有数据源同步. 但是,为什么必须仔细考虑执行的风格呢?. 对大多数组织来说,在整个组织中维护一个单一版本的真相是一个高度优先级的任务——同时还要满足遵从性和监管义务.

有关云架构建设和选型的思考

- - 博客园_知识库
  最近在负责公司内部私有云的建设,一直在思考怎么搞云计算,怎么才能够把云架构设计得好一些. 本文尽量全面的列出了云架构建设和选型的考量因素.   我们主要从五个层面逐步评估云架构的建设和选型,分别是:.   计算机云经过多年的发展,由一开始的概念,慢慢发展成熟并能够推向市场,提供多种多样的服务,市场空间非常之大.

雪球跨端架构建设之跨端容器篇

- - 掘金 前端
导读: 随着移动互联网的迅猛发展,目前市面上「端」的形态多种多样,Web、App 、车载、微信小程序等各种端大行其道,同一个业务需求往往又需要在多端上去实现,针对不同端去编写多套代码的成本显然非常高. 近年来「跨端」是前端界比较流行的一个词汇,不论是国内还是国外,跨端技术百家争鸣,方案频出. 雪球大前端团队将今年在跨端能力建设上的演进和推广工作整理成系列文章,由七部分组成:.

汤楚熙:美团实时数仓架构演进与建设实践

- - IT瘾-dev
编辑整理:李瑶 DataFun. 出品平台:DataFunTalk. 导读:大家好,我叫汤楚熙,来自美团数据平台中心的计算平台团队,当前主要工作内容是实时数仓平台的研发. 今天和大家分享一下实时数据在美团的典型应用场景,实时数仓建设中的挑战和解决方案,包括一些关键的设计细节. 01 建设背景 首先,来介绍一下美团实时数据的典型应用场景以及建设过程遇到的一些问题.

数据仓库简介、发展、架构演进、实时数仓建设、与离线数仓对比

- - zhisheng的博客
数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务,数据仓库的建设也是“数据智能”中必不可少的一环. 本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个方面全面分享关于数仓的详细内容. 原地地址: https://ververica.cn/developers/how-to-do-real-time-counting/.

MGR复制架构+自动化运维平台,汽车之家MySQL高可用建设实践

- -
陶会祥,2020年加入汽车之家,任职智能数据中心-云平台部,负责之家数据库的运维及RDS产品研发工作,致力于为公司提供安全,稳定,可靠的数据库服务. MySQL具有开源免费,运维简单,性能好等优点,是在汽车之家使用最多的一种数据库. 数据库作为应用的后端存储,承担着数据持久化存储的功能,是应用可以正常对外提供服务的关键组件,数据库的高可用非常重要.