作者chengliangliang·2021-10-08 09:33

系统架构师·某大型保险

保险行业异地灾备数据复制技术选型及建设难点探讨总结

字数 10796阅读 4987评论 0赞 5

企业组织为防止生产数据中心由于灾难(火灾、地震、断电)等原因无法运行，预先设立一个或多个备份数据中心，并且在生产中心无法工作时，备份中心能够在规定的恢复时间内迅速接管关键应用从而保持业务的连续性。灾备恢复是以IT为核心生产力的企业保证组织业务连续性的最后一道防线。银保监会更是自2018年开始便对保险公司数据中心灾备系统建设标准提出了明确的监管要求，保险公司在开业的5个经营年度内需完成灾备中心建设。

对保险公司来说存储复制、数据库复制、跨DC集群HA等灾备技术一直作为其重要的的灾备技术手段被广泛运用。保险企业异地灾备建设主要有三大技术路线：第一，选择基于数据库异地容灾复制技术如Oracle ADG 、 DB2 HADR、SQLSERVER allwayson或者其他数据库复制技术。具体来说就是两个站点的数据库存主从关系，通过在灾备站点传输然后应用活动日志使备库实时保持数据同步，备库通常为没有打开的状态，启用备库需要进行切换。第二，选择基于存储的远程异地复制技术，主中心、同城、远程存储设备间建立同步或异步数据复制，存储层数据复制可做到block to block的增量复制所以复制效率非常高。但存储层复制对于带宽、时延、DWDM传输链路质量等条件要求都比较高。第三，可以借助第三方同步、复制软件的方式进行容灾数据复制。

9月28日，针对保险行业异地灾备数据复制技术选型，社区邀请保险行业技术专家、戴尔科技技术专家与保险行业负责异地灾备项目的技术骨干一同交流探讨，本期的线上交流重点围绕4个方面进行探讨：灾备中心建设不同技术路线的选择考虑、灾备建设成本方面的比较、异地灾备数据一致性如何保障、应用层相关数据容灾建设考虑。

# 一、灾备中心建设不同技术路线的选择
灾备的技术随着信息技术的发展日新月异变得越来越多样化，新兴的分布式集群容灾、超融合技术、云网联动、多云多AZ等新生态解决方案也加入到灾备建设中，为企业提供更多的选择。但保险公司业务的典型特征很大程度的限制了灾备建设的发展和技术的选择：在系统架构上，保险行业的业务系统体态庞大，呈现出“大核心、多分支”的体系，业务应用类型、版本一致性高。业务逻辑上，分支乃至各系统之间交互频繁、关联度高，交互过程对时间等重要变量极其敏感；在资源架构上，因历史规划布局的原因，传统的小型机、存储的架构较为普遍。那么如何结合保险企业的业务典型特征，在异地灾备数据复制技术路线上应该如何选择？

## 1、保险企业异地灾备建设主要有三大技术路线: 基于数据库异地容灾复制技术基于存储的远程异地复制技术借助第三方同步、复制软件的方式进行容灾数据复制，异地灾备数据复制技术3大技术路线各有哪些优缺点？

**嘉宾：trouble_qu 售前技术支持 , 戴尔科技金融行业解决方案中心**
我理解的主流复制技术对比如下：
（1）存储复制技术：要求数据库数据存储在集中式存储上，基于存储阵列的复制技术使用专用 SAN 网络进行复制，复制技术成熟，对主机资源消耗低，并且可根据需求选用双活、同步或异步复制模式，支持双活，支持多中心闭环（既任一复制链路断，不影响其它链路和整体容灾），复制技术稳定，运维简便，只是同步和异步模式下灾备切换时会涉及存储切换的环节，双活模式对距离，链路质量要求较高。
（2）虚拟机复制技术：如数据库部署在虚拟机环境，可基于虚拟化复制技术实现容灾，虚拟化复制技术可基于虚拟机文件的变化进行增量复制，但案例相对较少，一般应用于中小型规模的数据库，且日常备端无法使用。
（3） 数据库复制技术：基于数据库本身的复制机制来实现跨中心复制，支持通过 IP 网络以增量方式进行复制，同时支持以库为单位进行细颗粒度的复制，并可根据需求选用同步或异步复制模式。采用此项技术，灾备端的数据库为启动状态且支持查询操作，相对灵活，但数据库切换操作复杂，对于切换时数据库状态的要求比较严苛，实际切换的操作也相对复杂，对数据库管理员的能力要求较高。
（4）第三方软件技术：主要针对文件系统里的数据进行复制，一般用于应用程序的复制，日志文件的复制等，稳定性和可靠性需要进一步验证，目前业界不太用于关键数据的容灾。

**嘉宾：wanggy 系统工程师 , 戴尔科技金融行业解决方案中心**
（1） 存储路线：
优点：多分区和多主机业务的不同数据通过存储容易保障一致性，rpo比较容易量化和管理，切换快，适合站点级切换；
缺点：链路资源要求高；

（2）数据库路线：
优点：数据传输量小，带宽少，适合单一业务；
缺点：一致性比较难于保障，多平台和跨平台难于实现；

（3）第三方工具：
优点：可定制化，跨平台和应用；
缺点：可靠性稳定性，以及数据一致性的校验需要严格测试，一般成本较低；
针对核心业务去，以上方式建议同时选择至少两种或者全部部署，以应对不同场景。

## 2、保险企业如何选择合适的灾备技术是一个挑战？灾备有存储级别，数据库级别，应用级别等多种方案和技术，对网络，存储等资源的消耗和灾备切换的效果，RTO，RPO等都有差别，如何根据企业实际选择合适的技术是一个挑战？听听同行在这块的一些建议！

**嘉宾：pc1989 存储工程师 , 某保险公司**
第一点：一个完整而合理的灾备架构还是要综合采用多样化的技术方案，按照风险收益平衡的原则，去分别对应不同的灾难应对场景，不同的业务类型，不同的IT基础架构，不同的灾难恢复目标。
第二点： 科学规划，分步实施，充分考虑公司自身的运维管理能力和应急处理能力，确保能够平滑过渡，避免基础架构的大幅调整，避免架构层引入过多的技术风险。

**嘉宾：kevinshopping 科技信息经理 , 某保险有限公司**
灾备技术选择性有很多该如何制定适合本企业自身的方案建议如下：
（1）明确目标
需业务系统拥有者进行RTO/RPO制定，明确容灾目标
（2）技术选择
根据RTO/RPO进行容灾技术方案选择
存储级：成本高、对于传输通道要求也高，好处对于上层应用数据库为透明可以高效的保证底层数据的一致性。
数据库级：成本较小、无需单独配置agent ,通过日志传输来保证数据的一致性，缺乏压缩去重，在对数据频繁操作时，数据增量不大，但操作日志可能很大，这样对于传输通道压力较大。
应用软件级：需要单独部署agent对生产系统会有一定的入侵，需额外支付软件相应的license及维护费用。

以上三类该如何选择应从务实方向出发，在能实现灾备目标的前提下选择维护人力成本最小对于生产环境入侵最小方案。

## 3、如何结合保险企业的业务典型特征，在异地灾备数据复制技术路线上应该如何选择？

**嘉宾：trouble_qu 售前技术支持 , 戴尔科技金融行业解决方案中心**
不同应用对数据复制架构的选择是由该应用对应的业务需求决定的。在多个数据复制架构同时能够满足业务需求时，就需要在多个维度上对这些数据复制架构之间的差异进行对比，最终确定数据复制架构。这些维度主要是否能保证数据一致性保证、系统恢复时间、案例数量、对当前应用的架构影响、对当前应用的性能影响、扩展性等多个方面。

通常，存储在数据库种的结构化数据由于对数据一致性，完整性要求较高。仍采用较为稳定，成功案例较多的数据库或存储的复制技术，乃至两种技术相结合的方式。其中数据库方式灵活性高，存储方式维护简单，各有优势。而电子保单，音视频文件等非结构化数据，建议统一使用NAS或对象存储的复制技术实现容灾数据复制，从而以较细的文件目录的粒度实现同步或异步的文件级数据复制

**嘉宾：wanggy 系统工程师 , 戴尔科技金融行业解决方案中心**
金融企业的“业务连续性规划”，确实是一个非常大的话题，具体到IT系统的容灾建设是基础。由于业务建设导致的关联越来越复杂是历史遗留的问题，需要进行整体的规划才可以逐步解决上述架构面临的复杂性。

**一般建设路径如下：**
（1）业务关联分析，形成统一业务平台的影响分析报告，制订服务目录，包括RPO、RTO等等，与业务部门达成的SLA，形成业务关联组；
（2）根据上述业务关联组，选择不同的技术路线，例如：集中存储方式、应用方式、数据库方式、备份方式等等；
（3）制订业务切换白皮书和红皮书，实现切换自动化；
针对保险行业，核心交易系统的业务连续性建设仍然是重中之重，需要采用各种手段保证业务的连续性，并且数据的保护水平应该最高。其他的业务则应该围绕核心业务，采用合理的方法进行业务的连续性建设。

另外，建议在选择分布式系统、超融合系统等新兴系统时，要看是否具备上述的功能，实现的方式，是否具备各种应用的一致性的要求。在这些系统建设中，也应该考虑内部是否具备细粒度的多种保护水平的技术方案，例如：以VM或者卷为单位进行多种方式的保护，以分布式卷实现多站点容灾等等技术。

# 二、灾备建设成本方面的比较
灾备恢复是以IT为核心生产力的企业保证组织业务连续性的最后一道防线，银保监会更是自2018年开始便对保险公司数据中心灾备系统建设标准提出了明确的监管要求，保险公司在开业的5个经营年度内需完成灾备中心建设。同城情况下，灾备中心的使用场景为，在生产中心无法工作时，备份中心能够在规定的恢复时间内迅速接管关键应用从而保持业务的连续性。因此，灾备中心大部分时间处于备用状态，仅在生产数据中心由于灾难(火灾、地震、断电)等原因无法运行时，在这种情况下，如何进一步提升投入资金的价值，如何进一步降低灾备中心的建设成本是大家关心的主要问题。

## 1、保险企业如何统筹灾备建设，降低运维成本及难度？
从当前金融行业看，很多公司都采用两地三中心架构，同城应用级灾备，异地数据级灾备，而且大多是分阶段进行建设，那么如何进行灾备统筹建设，可以更好的统一管理，这样既可以降低运维成本，也可以降低建设难度？不知道大家有没有什么很好的建设经验。

**嘉宾：kevinshopping 科技信息经理 , 某保险有限公司**
现在有很多的大的保险公司已经实现两地三中心，同城双活，异地灾备的或者多地多活方式。只要涉及双活方式。灾备及建设可以按照以下方式规划和推进：
（1）明确灾备目标值RTO、RPO，这个两个值需要系统ower进行评估，如系统的重要性、业务的连续性要求等。（注：实际上每个业务部门都会觉得自己的系统是最关键、最重要的，需要BCP（业务连续性计划）小组对目标进行有效引导，避免所有的系统都成为关键核心）
（2）目标明缺后再进行灾备技术方案的选择，容灾方案可以分为：存储级、数据库级及软件级。
存储级：要求级费用比较高（存储同构、存储虚拟化对同步线路延时抖动要求均比较高）···········好处是对于上层数据库及应用来说都是透明的，上层应用、数据库改动较小。
数据库级：采用自有容灾技术无第三方插件安装，但需要考虑的问题生产端频繁操作数据虽然最终的数据增量并不大，但日志可能很大，导致同步时间周期较长。
软件级：采用第三容灾同步软件或系统，需要在生产数据库及应用服务器上安装相应的agent，成本及对生产环境有入侵配置。
（3）容灾推进
建议先易后难，顺序从数据级、应用级再到双活逐步推荐，运维难度和成本个人认为最好是基于现有灾备软件和系统（如数据库自带容灾技术或企业已有的备份系统）减少运维人员学习成本降低对现有运维人员的操作系统改变。

**嘉宾：cpc1989 存储工程师 , 某保险公司**
（1）在遵守国家标准及银行保险业的相关规范的基础上，参考行业经验，确定两地三中心建设总体目标。一般对中小规模保险公司来说，同城灾难恢复等级达到国家标准4~6 级，异地达到国家标准3~4级。
（2）在风险分析和业务影响分析分析基础上，做好应用系统分类，确定不同类型应用系统的恢复等级和恢复目标。
（3）技术方案选型上，宜重点关注数据层方案，优先满足数据容灾保护需求，在此基础上考虑应用层和网络层方案。
（4）按照成本风险平衡原则，综合评估运用多种技术方案对不同业务系统设计不同的灾难恢复方案 ，并注意分步实施，平滑过渡， 避免基础架构的大幅调整，也避免架构层引入过多的技术风险。

## 2、 如何降低保险行业异地容灾的成本？如何实现DC与公有云或私有云之间的容灾，技术是否可行？是否合规？基础架构如何设计？网络层面如何考虑？

**嘉宾：kevinshopping 科技信息经理 , 某保险有限公司**
异地容灾需要降低成本可以从以下几方面考虑：
（1）异地容灾方案选择数据级
（2）在异地容灾方案中选择数据库自带容灾技术如Oracle ADG、DB2 HADR、Mysql主从等，降低对第三方容灾软件的依靠和维护成本。
（3）基础架构，有些保险公司基础架构中计算资源非全部采用x86架构可能还有小部分的小机，这部分若采用数据库自带容灾技术得需要进行分析，为了降低容灾方案投入可以让第三方提供容灾小机，从而降低硬件采购成本。存储部分灾备环境可以采用分布式存储将计算、存储统一管理(如生产DC采用传统SAN架构，容灾环境可以考虑分布式存储架构)。
（4）网络架构，DC中最好采用单独区域用于生产、灾备互联，路由协议需要选择可控性较强的如BGP，减少因灾备中心配置错误引起生产中心不稳定。生产和容灾中心专线可咨询两数据中心之间是否有大带宽互联线路，如果有可以采用该方式，这样一般会比单独向ISP申请成本更低。
（5）DC与云端容灾，因保险受银保监监管，如果数据需要容灾在云端，那建议必须通过备份软件或系统先对数据进行加密操作。

**嘉宾：trouble_qu 售前技术支持 , 戴尔科技金融行业解决方案中心**
（1） 根据容灾建设方法论，首先需要对公司所有业务进行 BIA 确定业务等级及对应信息系统等级；
（2） 确定异地容灾的建设策略（比如大同城小异地等），并根据 BIA 确定的业务等级确定异地灾备的覆盖范围，从而圈定建设的信息系统；
（3） 根据信息系统等级不同，相对应采取不同的容灾技术来控制成本，信息系统等级高的系统采用高标准的容灾技术，信息系统等级较低的系统采用较低的容灾技术。
需要强调的是，在确定灾备技术方案前，建议先就灾备建设的策略和初步预算跟高层达成一致，再去考虑详细的方案设计，否则很有可能难以达到高层期望。

**嘉宾：wanggy 系统工程师 , 戴尔科技金融行业解决方案中心**
目前有这样的案例是做数据级容灾。通过本地的备份设备将数据传输到私有云或者公有云中。由于是备份数据，去重之后的传输时十分必要的，可以大大节约网络带宽和容量带来的云环境的成本。

数据传输到公有云上是需要在安全可靠性的层面进行评估的，重要的数据需要加密之后才可以进行上传。从基础架构和网络层面的复杂性来看，通过备份方式进行数据级的容灾目前是成本最低的混合架构容灾方式。

**嘉宾：lsx 信息技术经理 , 大唐控股**
我觉得关键是有总体规划，系统建设时就预先定好容灾级别、各种策略。这样才能估算好各种资源。
在公有云上运营系统，如果建设时合规做得好，容灾时合规这块特殊的地方就不多了

## 3、异地灾备数据复制三种技术在建设成本上的对比分析？三种建设技术对存储成本上的分析以及扩展性的对比，在异地数据级灾备层面，有没有基于分布式存储做数据库灾备的保险公司案例？三种技术对基础网络带宽的消耗？ 这也是成本的大头。

**嘉宾：kevinshopping 科技信息经理 , 某保险有限公司**
（1）存储级复制对于存储成本最高，扩展性三种技术都具有一定的扩展性，采用哪种技术的关键是要看灾备的RTO和RPO目标。
（2）如果采用数据库级容灾技术，灾备中心存储可以与生产中心不一致，我们灾备中心就采用了分布式存储为灾备中心提供存储资源。
（3）存储级对于网络要求高，但数据复制效率也高；数据库级由于采用的是日志复制同步，对于日志的压缩去重有限；应用级可以采用压缩去重，一般压缩去重率较高，可以大大降低网络带宽消耗。

# 三、异地灾备数据一致性保障
保险行业的业务系统，涉及较多的账务处理，对交易数据的强一致性要求。异地灾备通常跨行政区域建设，通常带宽建设成本较好，采用的带宽较低，如何在现有的带宽情况下，保证高并发交易的数据一致性是一个值得探讨和密切关注的问题。

## 1、异地容灾中，对于高时效并发交易数据强一致性如何保障？远程灾备二地两个以上中心或同城多中心，如何做到数据实时同步，用以应对在线交易，精准的数据经营分析，实时计算场景需求

**嘉宾：wanggy 系统工程师 , 戴尔科技金融行业解决方案中心**
数据实时同步类的分布式业务仍然遵循CAP的原则，就是一致性（Consistency, C）、可用性（Availability, A）、分区容错性（Partition Tolerance, P），CAP的结论是三者不可兼得。

所以考虑到金融业务的强一致性要求，因此在分区容错和可用性方面就需要做出一定的让步。一般来说，强一致性的交易系统会通过集中存储方式实现两地三中心的容灾，保证异地数据的强一致性，分布式系统很难达到多环境强一致性的要求。

## 2、异地数据同步如何解决广域网高延时导致的数据同步效率低的问题？有哪些优化举措？如何解决坏块问题？包括物理坏块和逻辑坏块。

**嘉宾：trouble_qu 售前技术支持 , 戴尔科技金融行业解决方案中心**
首先建议去看下是不是真的有必要传输这么多数据，有些不在容灾范围的数据是否可以不做复制，从而节约带宽。

在此基础上，建议做一下带宽评估，确认下复制的数据在一个业务周期下的数据变化量或增量(根据使用的不同技术评估对象有些差别），基于评估结果确定所需的真实带宽。

评估是否可以使用带压缩，消重等功能的复制技术进一步节约带宽，或者使用带宽加速器在网络层进行压缩，当然这涉及到架构变动，可能需要下决心改造

如果还不行，升带宽吧。

**嘉宾：kevinshopping 科技信息经理 , 某保险有限公司**
广域网高延时说明数据传输已经达到了带宽峰值，建议针对同步数据大小进行评估，然后根据RTO和RPO目标进行带宽评估，该扩容带宽就得扩容带宽。

坏块问题非容灾同步也会存在不可避免，需要定期对备份数据和容灾数据进行数据验证，验证数据可用性。

## 3、异地容灾备份架构如何确保数据的实时性和一致性？
异地容灾备份的架构中，对于数据要求较高。如何在网络带宽有限的情况下，确保业务数据的实时性和一致性。一旦发生灾害，异地数据中心的系统及服务能够在最短时间内恢复？

**嘉宾：wanggy 系统工程师 , 戴尔科技金融行业解决方案中心**
异地容灾备份架构中， 确保业务数据的实时性和一致性，如果是“应用级”容灾并且网络带宽有限的情况下，只能采取“异步”数据传输的方式。“数据级”的容灾，则采用类似DataDomain的去重技术进行数据传输是常用的手段。

使用存储级别的异地容灾技术，可以提升多个业务系统的一致性，可以很容易制订切换脚本，大大加快异地数据中心的系统和服务的恢复时间。

**嘉宾：kevinshopping 科技信息经理 , 某保险有限公司**
异地灾备架构规划传输通道带宽是保证RTO、RPO至关重要的条件之一，如果在网络带宽有限的情况下只能考虑数据的压缩、去重从而降低需要传输的数据量，但压缩、去重后在灾备端数据恢复时所需时间也必然增加。

**嘉宾：trrouble_qu 售前技术支持 , 戴尔科技金融行业解决方案中心**
实时性和一致性问题是RPO的问题。
异地容灾受网络时延等客观条件的影响，在不对生产读写性能造成很大影响的情况下，几乎不太可能做到强一致性。因此，建议通过业务影响分析工作梳理业务的真实RPO需求，并说明异地中心的限制条件，与他们就可接受的数据丢失量达成一致，降低他们对异地数据丢失量的期望值，然后再考虑技术方案的设计。在带宽有限的情况，考虑比如网络层的带宽加速器，存储或数据库层的压缩、消重、增量数据传输等技术来提升传输效率。还有一点很重要，就是尽可能明确哪些数据是真正需要做灾备的，有些日志类的数据建议不用考虑灾备，从而使得带宽真正为有价值的数据服务。

## 四、应用层相关数据容灾建设考虑
传统的保险行业应用，在应用层通常还有一些数据持久化的保存需求，通常存储于NAS盘中，在异地容灾方面有什么好的的方案推荐。随着近期云化和微服务化技术越来越成熟，推广的越来越广泛，在保险行业也开始开始使用，相关数据方面如何实现灾备建设需求，如何保障RTO和RPO的要求，大家也进行深入的探讨。

## 1、异地机房非结构化数据同步方案推荐？主机房和灾备机房的应用在做同步时，由于虚拟机挂载了NAS盘，所以当灾备机房带宽不足时，传输NAS文件就很困难，这类情况有什么好的方案推荐吗，谢谢。

**嘉宾：kevinshopping 科技信息经理 , 某保险有限公司**
该问题建议从2个方面考虑：
（1）在灾备中心规划设计的时候需要对现有业务进行应用配置、应用变更频率、数据全量/增量及数据库日志变化量进行调研，确认从生产中心需要向灾备中心同步传输的总体数据量，然后根据RPO进行传输带宽计算，这样才能保证在目标时间内可完成所有数据的传输。
（2）非结构化数据同步
目前市场上有第三方同步软件可以实现虚拟机及指定目录配置和数据容灾，如英方，此类软件在做容灾的时候需要注意一点，初始化备份完成后生产端与灾备端同步异常停止后需要对目录下所有数据进行校验，检验完成后（若数据量大这校验时间可能会涉及到比较长）才会启动新的增量同步。

**嘉宾：JanXCJanXC 系统架构师 , nec**
做灾备实质上最怕的就是带宽不足和带宽争用，因为网络的问题导致的数据不同步，那灾备的实效性就会大打折扣。所以做灾备需要对网络流量进行评估和规划，做好QOS，带宽紧促时，优先保障核心、重要数据。
对于该问题，挂在nas文件及传输，不知是否可以 采用公有云的方式，即主机房的NAS文件在本地保存的同时传输至公有云NAS，灾备机房从公有云上下载文件，规避两地带宽的占用。不知是否合适，敬请参考。

## 2、Iaas云及容器云有什么较好的灾备方案？当前很多保险公司已经建设了Iaas云及容器云，云厂商的方案有时具会有一些条件限制，例如有的要求1:1成本过高，有的只能做整个DC切换等。请问老师有没有一些比较优秀的非厂商的灾备方案？

**嘉宾：half_life 工程师 , 上海骥步科技有限公司**
Iaas云的容灾相对来说更复杂一些，我来回答一下容器云的灾备问题。
对于容器云的灾备，实际上现在也可以等价为基于k8s平台的灾备了，大致的方案取决于对RPO的要求：
如果对RPO的要求不高，比如在半小时或者以上的小时级别
这种情况下可以通过备份恢复来进行灾备方案的搭建。首先要对源k8s平台的集群的所有关键应用进行定时的备份，例如每小时一次备份，备份的间隔就决定了RPO。备份的数据要上传到一个共享的存储中，例如S3的对象存储。主站点如果出现问题，或者进行灾难演练时，在远端站点的k8s平台对最近的备份点进行恢复，这样就可以构建一个RPO在小时级别的灾备方案。
虽然k8s平台已经屏蔽了大多数硬件、平台间的差异，但还是有几个方面的问题需要额外的关注：1是不同k8s版本、发行版之间的差异；2是使用的不同存储之间的差异；3是应用配置方面，比如域名需要改动等等。
对RPO的要求比较高，在分钟甚至秒级
在这种情况下，上述备份恢复的方案不再适用，而要考虑结合异地数据复制的技术或者方案。大致有两种思路，1是假设不同k8s平台用的是同一种主存储，这样就可以利用现有的主存储的数据复制来进行数据部分的复制，同时要结合诸如多集群（联邦）的技术来同步k8s的资源（比如pod，namespace等）到远端站点。第二个思路是假设主存储也不相同，那就要实现或者利用一个跨不同存储的数据同步技术，来实现数据的复制，同时也跟1一样要结合多集群的技术来同步k8s的资源，来实现整体的灾备方案。
这里面的难点主要是数据同步的技术，不管是基于主存储的数据同步方案，还是在主存储层之上的方案，同时还要结合多集群的控制平面来编排整个跨平台、跨云的方案。

## 3、微服务改造后的应用灾备是否有成熟方案？目前已有的跨中心微服务灾备方案能实现什么程度的应用级灾备保障？

**嘉宾：trouble_qu 售前技术支持 , 戴尔科技金融行业解决方案中心**
根据我的经验，微服务改造后的应用基本做到了多节点的集群化，可以考虑使用跨中心的应用层双多活的方案实现容灾。其好处在于灾备中心与生产中心一样可以同时对外提供服务，支撑业务运营，提升资源使用率，另外减少切换的中间环节，提升RTO，还可以做到生产灾备的统一发版和变更，发挥微服务的优势，具备较高的业务响应速度。这种方案下数据库还是建议采用传统的数据库复制或存储复制方式进行容灾，保障灾备数据的可用性，这是一种既有一定先进性，也相对易于运维的方案

**嘉宾：wanggy 系统工程师 , 戴尔科技金融行业解决方案中心**
主要看数据的持久层部署在对象存储或者集中存储上，可以分别采用上述的持久层方案进行部署。
而对于应用的业务连续性，则需要考虑后端微服务架构的应用提供方式进行选择，目前常见的都是通过容器化部署来实现，通过容器管理平台实现应用的高可用，例如VMware Tanzu提供的高可用保障。

# 五、交流达成的共识总结

通过本场保险同行的交流活动达成了一些交流共识如下，仅供参考：
（1）存储复制、数据库复制和三方工具，均为当前主流的容灾技术方案，存储复制具有复制技术成熟，对主机资源消耗低等特点，但成本相对较高，数据库具有成本低、数据传输量小等特点，但数据库切换操作复杂。三方工具具有兼容性好、可定制化的特点，但稳定性和可靠性有待验证；
（2）异地灾备建设，可用从细化建设范围和技术选择控制方面来控制建设成本，提高建设成效；
（3）强一致性的交易系统会通过集中存储方式实现两地三中心的容灾，保证异地数据的强一致性，分布式系统很难达到多环境强一致性的要求；
（4）应用层主要看数据的持久层部署在对象存储或者集中存储上，可以分别采用不用的持久层方案进行部署。

灾备复制技术路线选型存储双活灾备建设

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

保险行业异地灾备数据复制技术选型及建设难点探讨总结

添加新评论0 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料