2023-06-12 15:14:49 57阅读
容灾(Disaster Tolerance),是指在自然灾害、设备故障、人为操作破坏等灾难发生时,尽可能保证生产系统数据少丢失,保持生产系统的业务不间断地运行。
在衡量系统容灾效果或高可用特性时,一般有两个指标:
在高可用方面有一些与容灾接近的概念,有时它们之间是相通的,但侧重点不同:
容灾的基本方式,是在生产站点以外建立的冗余站点,灾难发生后,冗余站点可以接管用户正常的业务,达到业务不间断的目的。按照容灾系统对应用系统的保护程度可以分为数据级容灾、应用级容灾和业务级容灾。
到目前为止,灾备容灾都是行业内应对灾难的主流方式,也就是常说的冷备、热备。灾备容灾建立在数据级容灾或应用级容灾基础上,常用的实现方式是在备份机房构建一套相同的应用系统,灾难发生时会在约定的时间范围(RTO)内恢复运行,尽可能减少灾难带来的损失。
灾备容灾建设普遍都有建设周期长、业务成本高、使用频率低等问题,建设成本是所有应用容灾必然的共性,灾备容灾的局限性主要由于灾备中心平时不提供服务:
应用多活是应用容灾技术的一种高级形态,指在同城或异地机房建立一套与本地生产系统部分或全部对应的生产系统,所有机房内的应用同时对外提供服务。当灾难发生时,多活系统可以分钟级内实现业务流量切换,用户甚至感受不到灾难发生,对应前面提到的业务级容灾等级。
相较于传统的灾备容灾,应用多活具备如下优势:
与其他所有容灾解决方案一样,应用多活的根本目标是保障业务连续性,而故障是不可避免的,所以目标主要包含两个方面:
实现上由三个核心要点组成:
在考虑系统架构时,一定的顺序可以帮助厘清这三者的关系:隔离代表着拆分的粒度,其中包括逻辑数据拆分和物理部署拆分;拆分决定着冗余的方式,其中包括数据备份方式和冗余部署方式;隔离和冗余决定系统静态的结构,路由通过流量调配,在静态的结构上维护系统动态的可用性。
应用多活构建于上述三点之上,需要实现两个一致性,即流量路由一致性和数据读写一致性:
在物理架构方面,隔离拆分与物理距离相关,冗余类型与集群模式相关,如下表所示。
隔离|冗余 |
单集群 |
多集群 |
同城
|
|
|
异地
|
|
|
根据特征,尝试从表格中归纳三类应用多活的典型架构:单集群模型、多集群模型、单元化模型。
单集群模型:同城场景应用多活,实现机房级别容灾,依赖技术组件支持跨机房组成高可用集群,对应用系统的代码侵入较小。
多集群模型:同城场景应用多活(或接受跨地域调用延迟的异地场景),实现机房级别容灾,技术组件无法跨机房组成高可用集群,依赖跨集群数据单向同步以及集群切换的数据容错和保护,对应用系统的代码侵入较大。
单元化模型:为了解决单集群无法突破物理距离限制的问题,阿里提出了“单元化”方案。核心思路是对数据进行分片,通过自上而下的流量路由,让特定分片的数据到特定中心完成读写,以此解决数据一致性的问题, 并在此基础上解决了业务的容灾和水平扩展问题。这个可以水平扩展的逻辑中心称为"单元"。
单元分为两种类型,中心单元与普通单元。单元内部署的业务分为三种类型,全局业务、核心业务、共享业务。中心单元只有一个,部署全局业务、核心业务、共享业务。普通单元部署核心业务、共享业务, 普通单元具备水平的扩展能力,可以任意复制。
对比前两个模型,单元化业务具备更高层级的抽象,核心是将业务逻辑和数据在同一个单元闭环,有点类似微服务的思想,以跨单元业务调用代替跨单元产生和消费数据。
三种业务分类在概念上易于理解,但底层还是依赖于技术组件的跨集群数据同步,并且路由调配需要与数据分片保持一致,实现上更加复杂,对应用系统的代码侵入最大。对于核心业务类型,需要支持数据双向同步,并以中心单元为中心构建星状数据同步,这样才能在某个单元故障时,其他单元能接管它的数据。
应用多活的技术方案,一般分为四个部分,分别是接入层、应用层、数据层和管理层,四层组件遵循应用多活的设计目标,支撑应用构建应用多活架构能力。
一次业务流量请求,从移动端或PC端发起调用,到进入业务应用的整个流量链路过程中,期望能尽早进行路由纠错,以减少下游不必要的二次纠错和跨机房调用。
在流量链路上,DNS域名解析是最早的一个环节,但DNS仅支持按权重随机分流,无法满足应用多活架构流量灵活路由的需求。HTTPDNS具备自定义路由规则的能力,但HTTPDNS也存在着不适用于PC端流量的局限性。综上所述,应用多活架构需要在机房入口处部署一套流量接入网关,来负责七层流量的灵活路由。
接入网关核心能力可以概括为:
接入网关在技术架构设计时,存在单集群和多集群两种模式:
单集群模式:
多集群模式:
应用多活架构中,微服务多活组件同样需要具备流量路由纠错能力,来满足多种微服务调用场景的路由需求:
业务应用集成微服务多活组件通常有SDK、Agent、Sidecar等不同形态,核心能力可以概括为:
微服务多活组件在技术架构设计时,存在单集群和多集群两种模式:
单集群模式:
多集群模式:
由于消息是异步消费的,从消息被生产出来再到被消费到的时间段中,流量路由规则可能发生了变化(例如进行了切流)。如果消息有堆积的话,那么这个异步消费的时间差还会更长,生产和消费两个时间点路由规则不一致的概率会更大。因此只在上游通过接入网关、微服务调用进行流量路由是不够的,还需要在消息消费时按照最新的路由规则再次进行路由纠错。
业务应用集成消息多活组件通常有SDK、Agent、Sidecar等不同形态,核心能力可以概括为:
消息多活组件在技术架构设计时,存在单集群和多集群两种模式:
单集群模式:
多集群模式:
数据层多活核心需要解决的是数据一致性的问题,需要针对可能出现数据不一致的问题场景进行数据一致性保护:
数据层是读写数据库前的最后一道关卡,相比采用异步或定时数据对账来事后发现数据不一致问题的方式,在数据写入前通过路由正确性校验和错误流量禁写等保护措施,能够提早杜绝数据不一致的发生,从而避免此类问题的进一步扩大和蔓延。
业务集成数据层多活组件通常有SDK、Agent、Sidecar等不同形态,核心能力可以概括为:
数据层多活组件在技术架构设计时,存在单集群和多集群两种模式:
单集群模式:
多集群模式:
2023-06-12 15:14:49 57阅读
容灾(Disaster Tolerance),是指在自然灾害、设备故障、人为操作破坏等灾难发生时,尽可能保证生产系统数据少丢失,保持生产系统的业务不间断地运行。
在衡量系统容灾效果或高可用特性时,一般有两个指标:
在高可用方面有一些与容灾接近的概念,有时它们之间是相通的,但侧重点不同:
容灾的基本方式,是在生产站点以外建立的冗余站点,灾难发生后,冗余站点可以接管用户正常的业务,达到业务不间断的目的。按照容灾系统对应用系统的保护程度可以分为数据级容灾、应用级容灾和业务级容灾。
到目前为止,灾备容灾都是行业内应对灾难的主流方式,也就是常说的冷备、热备。灾备容灾建立在数据级容灾或应用级容灾基础上,常用的实现方式是在备份机房构建一套相同的应用系统,灾难发生时会在约定的时间范围(RTO)内恢复运行,尽可能减少灾难带来的损失。
灾备容灾建设普遍都有建设周期长、业务成本高、使用频率低等问题,建设成本是所有应用容灾必然的共性,灾备容灾的局限性主要由于灾备中心平时不提供服务:
应用多活是应用容灾技术的一种高级形态,指在同城或异地机房建立一套与本地生产系统部分或全部对应的生产系统,所有机房内的应用同时对外提供服务。当灾难发生时,多活系统可以分钟级内实现业务流量切换,用户甚至感受不到灾难发生,对应前面提到的业务级容灾等级。
相较于传统的灾备容灾,应用多活具备如下优势:
与其他所有容灾解决方案一样,应用多活的根本目标是保障业务连续性,而故障是不可避免的,所以目标主要包含两个方面:
实现上由三个核心要点组成:
在考虑系统架构时,一定的顺序可以帮助厘清这三者的关系:隔离代表着拆分的粒度,其中包括逻辑数据拆分和物理部署拆分;拆分决定着冗余的方式,其中包括数据备份方式和冗余部署方式;隔离和冗余决定系统静态的结构,路由通过流量调配,在静态的结构上维护系统动态的可用性。
应用多活构建于上述三点之上,需要实现两个一致性,即流量路由一致性和数据读写一致性:
在物理架构方面,隔离拆分与物理距离相关,冗余类型与集群模式相关,如下表所示。
隔离|冗余 |
单集群 |
多集群 |
同城
|
|
|
异地
|
|
|
根据特征,尝试从表格中归纳三类应用多活的典型架构:单集群模型、多集群模型、单元化模型。
单集群模型:同城场景应用多活,实现机房级别容灾,依赖技术组件支持跨机房组成高可用集群,对应用系统的代码侵入较小。
多集群模型:同城场景应用多活(或接受跨地域调用延迟的异地场景),实现机房级别容灾,技术组件无法跨机房组成高可用集群,依赖跨集群数据单向同步以及集群切换的数据容错和保护,对应用系统的代码侵入较大。
单元化模型:为了解决单集群无法突破物理距离限制的问题,阿里提出了“单元化”方案。核心思路是对数据进行分片,通过自上而下的流量路由,让特定分片的数据到特定中心完成读写,以此解决数据一致性的问题, 并在此基础上解决了业务的容灾和水平扩展问题。这个可以水平扩展的逻辑中心称为"单元"。
单元分为两种类型,中心单元与普通单元。单元内部署的业务分为三种类型,全局业务、核心业务、共享业务。中心单元只有一个,部署全局业务、核心业务、共享业务。普通单元部署核心业务、共享业务, 普通单元具备水平的扩展能力,可以任意复制。
对比前两个模型,单元化业务具备更高层级的抽象,核心是将业务逻辑和数据在同一个单元闭环,有点类似微服务的思想,以跨单元业务调用代替跨单元产生和消费数据。
三种业务分类在概念上易于理解,但底层还是依赖于技术组件的跨集群数据同步,并且路由调配需要与数据分片保持一致,实现上更加复杂,对应用系统的代码侵入最大。对于核心业务类型,需要支持数据双向同步,并以中心单元为中心构建星状数据同步,这样才能在某个单元故障时,其他单元能接管它的数据。
应用多活的技术方案,一般分为四个部分,分别是接入层、应用层、数据层和管理层,四层组件遵循应用多活的设计目标,支撑应用构建应用多活架构能力。
一次业务流量请求,从移动端或PC端发起调用,到进入业务应用的整个流量链路过程中,期望能尽早进行路由纠错,以减少下游不必要的二次纠错和跨机房调用。
在流量链路上,DNS域名解析是最早的一个环节,但DNS仅支持按权重随机分流,无法满足应用多活架构流量灵活路由的需求。HTTPDNS具备自定义路由规则的能力,但HTTPDNS也存在着不适用于PC端流量的局限性。综上所述,应用多活架构需要在机房入口处部署一套流量接入网关,来负责七层流量的灵活路由。
接入网关核心能力可以概括为:
接入网关在技术架构设计时,存在单集群和多集群两种模式:
单集群模式:
多集群模式:
应用多活架构中,微服务多活组件同样需要具备流量路由纠错能力,来满足多种微服务调用场景的路由需求:
业务应用集成微服务多活组件通常有SDK、Agent、Sidecar等不同形态,核心能力可以概括为:
微服务多活组件在技术架构设计时,存在单集群和多集群两种模式:
单集群模式:
多集群模式:
由于消息是异步消费的,从消息被生产出来再到被消费到的时间段中,流量路由规则可能发生了变化(例如进行了切流)。如果消息有堆积的话,那么这个异步消费的时间差还会更长,生产和消费两个时间点路由规则不一致的概率会更大。因此只在上游通过接入网关、微服务调用进行流量路由是不够的,还需要在消息消费时按照最新的路由规则再次进行路由纠错。
业务应用集成消息多活组件通常有SDK、Agent、Sidecar等不同形态,核心能力可以概括为:
消息多活组件在技术架构设计时,存在单集群和多集群两种模式:
单集群模式:
多集群模式:
数据层多活核心需要解决的是数据一致性的问题,需要针对可能出现数据不一致的问题场景进行数据一致性保护:
数据层是读写数据库前的最后一道关卡,相比采用异步或定时数据对账来事后发现数据不一致问题的方式,在数据写入前通过路由正确性校验和错误流量禁写等保护措施,能够提早杜绝数据不一致的发生,从而避免此类问题的进一步扩大和蔓延。
业务集成数据层多活组件通常有SDK、Agent、Sidecar等不同形态,核心能力可以概括为:
数据层多活组件在技术架构设计时,存在单集群和多集群两种模式:
单集群模式:
多集群模式: