主备数据中心之间一般有热备、冷备、双活三种备份方式。

热备
热备的情况下，只有主数据中心承担用户的业务，此时备数据中心对主数据中心进行实时的备份，当主数据中心挂掉以后，备数据中心可以自动接管主数据中心的业务，用户的业务不会中断，所以也感觉不到数据中心的切换。

冷备
冷备的情况下，也是只有主数据中心承担业务，但是备用数据中心不会对主数据中心进行实时备份，这时可能是周期性的进行备份或者干脆不进行备份，如果主数据中心挂掉了，用户的业务就会中断。

双活
双活是觉得备用数据中心只做备份太浪费了，所以让主备两个数据中心都同时承担用户的业务，此时，主备两个数据中心互为备份，并且进行实时备份。一般来说，主数据中心的负载可能会多一些，比如分担60~70%的业务，备数据中心只分担40%~30%的业务。

A—P
AP 双活通过将业务分类，部分业务以数据中心 A 为主，数据中心 B 为热备，而部分业务则以数据中心 B 为主，数据中心 B 为热备，以达到近似双活的效果。

A—A
AA 双活则是真正的双活，同一个双活 LUN 的所有 I/O 路径均可同时访问，业务负载均衡，故障时可无缝切换。
————————————————

原文链接：https://blog.csdn.net/qq_44204058/article/details/103041608

冷备或者主备并不是一个理想的方案，而且*大多数情况下，只能是一个心理安慰，真正发生故障的情况下，这样的容灾模式根本起不到作用。

原因我就不重复了，大家如果有兴趣可以直接看那篇文章。

*近，公有云又出了些大故障，各大群和朋友圈又开始沸沸扬扬，但是整体看下来，声音无非两种：

• 单站点不靠谱，要有容灾，出现这种情况就得马上切，所以回去赶紧建设容灾站点；
• 鸡蛋不能放在一个篮子里，单云不靠谱，要多云。所以，多云就要选我们家的xx云，或者我们提供xx多云服务。

我在我的一个讨论群里就提出来，*种声音是有意识的建设，有这个意识很好，但是把这个事情想得太简单了。第二种声音，基本就是不动脑子的瞎BB，原因我下面讲。

转回正题来，既然上篇提到主备模式不靠谱，那到底怎么选？而且整天见各类技术文章，不是双活，就是多活，不是同城，就是异地，现在又出来个多云，好复杂。

下面我就谈谈我的理解：

首先，这么多名词是什么含义，要搞清楚，然后再看适不适合。

先讲相对简单的双活（简不简单，看后面就明白了），其实就是两个站点，同时承载业务流量，可以根据用户ID、地域或者其他业务属性也决定怎么分担流量，当一个站点故障时，可以快速（分钟级）切换到另一个站点，理想情况下，对业务基本是无损或者非常小的。

这里就跟前面讲的主备不同了，主备的另一个站点完全是不承载任何流量的。

这里再往深里看一眼，同时承载流量，也要看承载到那一层，也就是流量在统一站点内闭环，所有调用都是本机房内完成，还是只有应用层这样的无状态组件双活，但是数据访问、异步消息这些有状态的部件还是回到主站点调用，这两种模式又是不一样的。

其实第二种，就比前面讲的主备模式要好一些，因为这样至少可以保证应用层随时可用，不过真出故障的时候，还是少不了数据层的切换，这个其实是非常耗时的。跟主备模式一样，基本无法演练，因为代价太高，数据会有损。（如果数据层没有这么复杂，只有几个数据库，那是没问题问题的，但是分布式的场景下，上百个，几百个实例切换，这个代价和成本还是很大的。）

所以，再往下推导，如果想要做到有效果的双活，就必须保证每个站点，都是独立运行，所有的调用都是本机房调用且闭环，底层做好数据同步即可。

只有做到这个程度，当一个站点发生故障不可用时，就可以从接入层把故障站点的流量切换到另一个站点，双活的效果也就有了。

不过，做到这个程度，就不是说我们想要做就能做到的，如果您做个类似的架构设计，你会知道这里有三个关键的技术点：

*个，本机房调用

也就是一个分布式请求不能跨机房调来调去，这个是不行的，必须要保证本机房调用闭环。所以从分布式服务的路由策略上，以及服务化框架上，必须得支持这也中调用模式，同理，数据访问层，以及消息组件也要支持这种特性。

第二个，数据分片和一致性

为什么要做这个事情？我们知道一个系统中数据准确性、完整性和一致性是非常关键的，放到双活这个场景下，*关键的就是数据一致性，我们不能允许有同一个记录两边同时在变更，还要双向同步，比如用户交易和支付类的数据，同时变更的情况下，我们无法确认哪边是准确的。

前面提到，两个站点是同时承载不同的流量的，这就要根据一些业务属性来分配，比如用户ID、所属地域等等策略，这里为的就是能够在数据层面也要做好隔离，一个站点内只提供固定部分的用户访问。

这样就保证了单站点内同一分片的数据，不会在另外一个站点被变更，后续的同步也可以做到单向。

所以，这里的关键，就是数据要做分片，就要用到分布式的数据中间件，要做数据访问的路由设计，数据要同机房读写，还要做数据拆分这样的工作，技术门槛和工作量也不低。

这两点如果能够做到，其实就是我们经常说的“单元化”架构达成了，理论上，我们可以选择任何一个机房和地域，把系统搭建起来，就可以提供业务访问了。

但现实是更为复杂的，因为用户业务系统产生的数据，有可能会被其它系统用到，比如商品库存这样的系统，这就要涉及异步消息和数据的同步问题，而数据同步不仅仅是一个技术问题，而是个物理问题，我们接下来讲。

第三个，数据同步。

其实单从同步角度而言，目前很多的同步工具和开源产品已经比较完善，所以这里*大的问题，其实不在技术层面，而是在物理层面。

准确点，就是物理距离上的时延问题，这个无论是双活、多活，还是同城、异地，都绕不开的痛苦问题。

既然要双活，必然会选择另一个跟当前机房有一定距离的机房（同城或异地），而且距离必须得拉开才有意义，如果都在一个园区里面，就没有任何容灾意义了。

距离一旦拉开，物理距离就出来了，即使是专线相连，中间也要经过很多网络设备，如果是云化的网络架构下，经过的软硬设备就更多，还有可能涉及协议转换，如果中途跨运营商，就更难保障，这样一来时延肯定是几倍、十几倍，甚至是上百倍的上涨，直接从0.x毫秒，上涨到秒级别。

对于同城来说，这个问题还好，但是一旦跨省就完全不可控，特别是机房如果不是自己的，根本无法控制。所以，想大公司自建机房，一定会在这个层面做大量的优化，尽*大可能降低时延。

就以淘宝、天猫为例，按照之前了解的情况，基本也是杭州和上海这两个城市为主做双活，再远时延这个问题就绕不开了。

数据同步及时性为什么这么重要，一个是业务体验，不能说库存都没了，其他用户看到的还是有货，这个是不会被接受的。

再就是故障时，如果同步不及时，*有可能造成几秒钟内的交易数据丢失，或者不一致，像淘宝这样每秒4位数订单量的系统，丢几秒钟数据，造成的损失也是巨大的。所以，这里就必须要建设有一整套的数据完整性和一致性保障措施，尽*大程度降低业务损失。

所以，数据同步所依赖的时延问题，其实就已经超出了*大部分公司所能掌控的范畴，也不是单纯靠自身技术能解决的问题，要看天时和地利。

讲到这里，我想多活就不用讲了，时延这个问题解决不了，多活就是扯淡，至于同城和异地，我想看明白的读者，也知道怎么选择了，其实一样，还是取决于时延。

我们可以得出的几个结论：

• 不管怎么选择容灾方案，我们自己的业务系统，从自身架构上，一定要支持单元化，一定要支持数据同步才行，如果这都不支持，讲双活和多活，就是特么的扯淡。所以，打算搞双活，先从这里下手，当然牵出来就要涉及到分布式，还有很多大量细节技术问题。
• 一个合理的建设节奏应该是，同城双活—异地双活—两地三中心（同城双活+异地多活），因为你要解决的问题的复杂度和难度也是在逐步上升的，不可能一蹴而就。
• 题目里这些个名词，不是孤立的，而是从不同维度看到的结论，但是如果你偏离自己的业务场景去看，孤立的去看，就一定会被带到沟里去，而且不知道该如何下手，所以，一定别偏离你的业务场景，然后把它们联系起来。
• 一切都是ROI，为了保证高可用，就一定会有成本，高可用程度越高，成本就一定越高，所以成本投入得到的收益到底划不划算，这个只能自家公司自家评判。
• 现实情况，比我写的要复杂的多的多，推荐大家看两个成功案例，一个是毕玄的异地多活数据中心，一个是饿了么异地多活，几个关键字google一下就有了，里面涉及到的场景化的细节对大家理解这件事情的复杂度会有更帮助。

背景

数据库作为核心数据的重要存储，很多时候都会面临数据迁移的需求，例如：业务从本地迁移上云、数据中心故障需要切换至灾备中心、混合云或多云部署下的数据同步、流量突增导致数据库性能瓶颈需要拆分……

而传统的开源数据库迁移工具SSMA、imp/exp等为了保证迁移数据的一致性，必须要在迁移之前停止服务，容易造成业务中断。对于有些用户，迁移数据量非常大可能达TB级别，即便有了这些开源工具还需要规划磁盘空间大小、传输的网络带宽、CPU资源等等。另外由于这些开源工具的参数配置也相对比较复杂，对用户而言这部分学习成本也较高。

为此，UCloud推出了数据传输 (UCloud Data Transmission Service) UDTS服务，支持多种同构和异构数据源之间进行全量或增量数据传输、支持多库或全库的迁移、支持ETL数据过滤等，从而帮助用户降低数据迁移的风险、提高数据传输的实时可靠性，方便其灵活调整数据架构、实时同步数据并分析等。

UDTS一键启动迁移服务

传统的数据库迁移步骤包括系统环境的配置、工具的安装编译、数据备份、恢复测试等，整套流程不仅复杂且传输过程易出错，还可能面临数据丢失风险。

而UDTS从产品功能上实现了服务化，帮助用户简化了这些复杂的操作。用户无须关心所需的底层物理资源，也不需要关注工具的复杂参数配置， 只需要在控制台一键点击创建迁移任务， 选择增量/全量任务类型，填写数据源信息即可启动迁移服务。如图：

相比传统的迁移工具，UDTS更加灵活弹性，对于正在迁移的任务，用户如果不想迁移了可随时停止，如果任务信息填错等需要修改的时候，用户也可以随时进行修改重启。UDTS还能提供完善的运行信息，例如迁移任务的起始时间、剩余时间、数据量等。在安全可靠性方面，UDTS在公有云平台上进行数据迁移不仅支持外网的迁移，还提供UCloud内网的数据迁移。

支持丰富的迁移类型

如上图所示，目前UDTS支持主流数据库MySQL、TiDB、PgSQL、SQLServer、MongoDB、Redis的同构数据源之间的迁移，以及异构数据源的迁移MySQL->TiDB。还支持一些其他类型的迁移，例如从CSV->UDW（UCloud数据仓库）、CSV->MySQL。

了解到很多UFile用户有数据迁移的需求，因此UDTS新增了UFile之间的数据迁移，包括支持全bucket迁移、按prefix迁移、断点续传，同时可以与UCloud工作流服务StepFlow结合实现增量同步。

UDTS的三次重要升级

迁移维度从表到库

经过调研我们发现有些用户的表比较少且集中，有些用户一个表有上百G的数据，如果按库迁移的话，一个库里面上TB的数据迁移在导出阶段一旦出问题就得从头再来，因此UDTS*初是从表的维度开始迁移，一次只能迁移一个库里面的一张表。

后来又调研到有用户的一个MySQL实例有十几个库，每个库有二十几张表，如果按表迁移可能要创建几百个任务，对于该用户来说按表迁移的显然任务量巨大。于是我们很快开发支持了按库进行迁移，将这个用户库里面所有表一次全部迁移过去。另外UDTS还支持多库及全库的迁移，可以将一个实例下除系统库（mysql, information_schema, performance_schema, test, sys）以外的所有库一次性迁移过去。

支持ETL数据过滤

有些用户会面临这样的需求：在数据迁移的时候不希望或者不需要将所有数据完整的迁移到目标库，因此UDTS开发了按条件（行）选择及按列选择功能。

还有一些数据整合的场景，用户原来的数据分散在不同的数据库中，现在希望整合到同一个高性能数据库中。但有时会遇到数据库名重复冲突导致无法整合。于是UDTS提供了迁移时重命名的功能，可以针对数据库也可以针对表，这样就帮助这类用户解决了数据整合的难题。同时我们还提供了列级的映射，让用户有更灵活的迁移服务。

使用过MySQL的用户可能经常会遇到这种情况，如果业务量大，从库老是追不上主库。我们遇到有用户在做完全量迁移后，做增量迁移的时候发现老是追不上主库，经过分析发现该用户有一个批量计算在里面，有一张表有几千万条数据，每隔一段时间做一次批量计算，将那张表拷贝一份在里面做大量的运算，用完了之后再删掉，不断的重复做这件事情。但由于这些表都是临时生成的只知道前缀不知道名字，于是UDTS增加了一个数据过滤功能，支持按特定的前缀来排除特定的表，这样运行出来速度就很快，任务一旦启动就从来没有掉过队，一直是实时保持同步的。

从单地域到多地域

UDTS 从*初的北京单地域逐渐扩展了很多其他地域，这里涉及到跨地域甚至跨国迁移的问题。单地域迁移，比如在北京几个可用区之间的延时*多可能一两毫秒，而跨国迁移中有些国家网络延时可能达到几十毫秒，而低延时对于数据迁移的服务来说非常关键。

*个大问题就是带宽问题，同一地域内无论是内网还是外网带宽可以认为是无限的，但跨国迁移不同，云厂商的网络出口流量出于成本或安全的考虑都会做一些限制，因此*开始经常遇到一些失败的情形，迁移过程中网络突然断掉，这是由于流量超过了云厂商机房的网络阈值导致IP被限制了，因此我们要保证整个迁移过程中网速不能超过数据中心的阈值。

第二个问题是高延迟，例如数据库连接中间丢包产生的现象比较多就必须做一些改进，因此UDTS产品需要更健壮，断点续传的功能一定要非常稳健。

第三个问题是我们发现有很多跨国迁移用户对数据非常敏感不愿意走公网，需要单独拉一条专线，但是由于专线的厂商有一些保活机制在里面，会对数据库连接产生干扰，经常遇到网络突然中断的情况。因此专线之间的保活措施如果确实有问题可以把机制关掉，另外数据库的错误连接数一定要设置的很高，不然很容易达到阈值导致连接连不上去。

UDTS在多地域的支持上，除了UCloud国内的节点（含台湾，香港），也陆续开通了如新加坡、越南、巴西圣保罗等海外节点，后续还会逐步扩展UDTS服务至UCloud全地域节点实现全球化级别的服务。

UDTS双向迁移

为什么要做双向迁移呢？假如一个用户要确保迁移万无一失，一旦迁过去一段时间后出错了，立马要回切，这里面就涉及到一个问题，一般数据迁移都是从源到目的做一个全量，然后增量同步，才会把业务切过去。但是这个过程流量只会写一边，导致不断产生的新数据并没有写到源端。

有些场景很复杂，不只是一个关系型数据库，迁移下来有一整套比如缓存、DNS服务或者其他服务，万一整个迁移过来后工作一段时间发现出问题了，就需要立马把业务切回去，这时从数据库的角度来说基本切不回去了，因为目的端已经产生了很多增量数据而源端没有。如果有双向同步，数据写到目标端就可以实时同步到源端，将业务随时切回来。

还有异地双活的场景，有些用户可能一部分业务跑在这家云厂商另外一部分业务跑在另外一家云厂商上面，或两边厂商都要跑一模一样的环境，这些都需要数据同步，从而达到跨云协同或者跨云容灾。一家云商出问题以后，快速将业务切换到另外一家云商上，保证业务可用。

双活怎么做？不管哪家云厂商数据库都支持高可用，不用同云厂商做了不同的架构改造，每一家都有自己的模式。UCloud的关系型数据库UDB高可用的结构不能和AWS的高可用结构通过主从做实时同步，一个主库可以有很多个从库，但是一个从库只能有一个主库。如果有了双向同步，就可以实现业务的双活部署，无论从哪边写都可以实时的同步。

双向同步有一个难点就是流量循环，为了避免这个问题，我们一般用打标签的方法，给一条语记做一个标记，迁移的时候就能识别出来这个是从哪边迁移过来直接扔掉不迁。

打标签的方案有三种：

• 方案一：修改数据库源码，在binlog中给源加标记；

• 方案二：要求表有主键，将 insert/update 修改为 replace into；

• 方案三：将每一条语句打包成带特殊TAG语句的事务，同步服务识别出TAG，忽略整条事务。

这里我们选择的是方案三，主要是由于方案一需要改动数据库源码，还需要数据库团队合作，且这个方案只能支持我们自己的云数据库，不能支持原生MySQL数据库及其它厂商的数据库；方案二限制太多，且有sql语句重复执行的问题。

总结

数据迁移作为IT架构不同阶段中的重要一环，无论是从本地迁移上云或是异地多活（灾备）等场景，UDTS都能够保证数据的平滑迁移，解决传统数据迁移的诸多难题。为了进一步提高用户体验，UDTS将不断完善当前已有功能，并支持更多同构、异构类型的数据传输服务。

正文如下：

公司在19年实现了业务系统的整体上云，合作的云厂商是腾讯云。当前系统上云也是主流互联网公司的趋势，使用各种云产品和服务也带来了*大的好处，有效的降低了成本，提高了运维部署的效率，提升了业务的可靠性。因此过了一年，大数据平台又从自建的机房，搬上了华为云，从此从单一云厂商也变成了多云厂商，公司的DevOps平台也需要去适应这种变化从而进行改造。

背景说明
这里对我们公司的devOps平台简单概述下：
DevOps平台概述
对于有一定规模的互联网公司，devOps平台是必不可少的。好处和优势就不多介绍了。

我们公司的devOps平台主要的系统有：
工单系统： 关于机器的申请，云产品的创建回收等等流程化的操作，都需要接入工单系统进行逐级的审批和自动化操作
发布系统：  对于一线业务开发人员在开发应用时，只需要提交代码，在发布系统新建一次变更，就可以自动将代码集成到对应环境的机器上。
cmdb和应用管理系统：对公司的机器资源以及应用资源进行管理
部署系统：能够给机器下发各种部署任务，完成软件的部署工作
各种域名DNS管理以及配置管理等。
当然还有其他系统
（ 然而这些系统现在都是我一个人进行开发和维护  – – ）

言归正传，回到今天需要描述的场景，如何在devOps平台上支持多云厂商云产品的管理。
以下描述都以机器申请的场景为例

单一云场景
在业务系统上腾讯云以后，业务方在新应用申请或是应用服务器扩容的场景，发起工单用于审核和服务器自动化扩容。

当时的技术实现，主要涉及到工单系统和资源管理系统的改造，工单负责流程的流转和审核，资源管理系统负责调用对应的云平台API进行对云资源的操作，从而做到系统间的解耦。由于系统来来回回负责开发的人员太多，我刚接手工单系统的时候，已经支持了腾讯云cvm的创建，但是所有的逻辑代码都放在了工单系统中，包括调用腾讯云平台API的实现。

在我前期熟悉代码的时候，遇到了以下问题：

代码的逻辑比较混乱，结构不清晰，代码注释较少，阅读理解起来比较复杂
代码的可扩展性不高，存在不少的if else代码来扩展实现，当场景多的时候代码量就过多
代码的可复用性不高，存在不少重复代码
起初我也对系统进行了改造，在资源管理系统中新增了调用腾讯云API的接口实现，希望能够先将系统解耦，将云资源在一个系统中进行统一管理。
然而这个时候，我开发接口的角度依然是对照腾讯云API的文档，基本是一个接口对应腾讯云的API的接口。
申请CVM的流程如下：

工单通过审批，随后调用资源管理系统中的创建CVM接口，资源管理系统调用腾讯云平台接口创建CVM，返回申请的情况和实例的id列表。然而这个时候虽然腾讯云返回了实例id，但并不是说机器已经创建完成了，也可能在准备中，因此这个时候工单还需要定时任务查询机器状态是否在运行中，只有等所有的机器创建完成才说明这次机器申请完成，随后才能进行后续的部署操作.

这样看来整体的流程还算是清晰的。

随后过了一年，当大数据选择上华为云时，新的需求出现了，工单系统需要支持华为云ECS的创建.虽然说，按照之前的流程去开发好像也没什么问题，工单之前的审批逻辑不变，只是*后审批通过以后选择调用资源管理系统的华为云创建ECS接口，当时的我也正打算这么干，毕竟这种逻辑也比较简单，不需要考虑什么。

但是在前期准备前，我梳理了下整体的开发流程和思路，发现了一些问题，导致我打算开始优化和重构整个系统.
华为云和腾讯云在处理上方式不同。华为云和腾讯云在调用创建接口后，后续的操作并不是相同的方式，华为云创建后会返回joid来标记这次申请，随后需要根据jobid查询本次申请的状态，是否已经创建成功，成功后再去查询相关的机器信息。
如果按照以前的流程，由于华为云和腾讯云在后续的操作不同，导致在完成后续操作时，工单系统中需要有两种实现方式来适应华为云和腾讯云的不同，如果说以后有第三种云，那代码的可扩展性不高。
然后我开始意识到这样的方式并不是很好，根本原因是思考角度的问题。

由于在单云场景中，所有的流程都是按照腾讯云的规范和方式来设计的，对后期代码扩展性的考虑较少，然而在当前需要支持多云资源管理的场景下，并不是很友好.因此我觉得需要对原来的方式进行优化。

多云场景

在多云场景的角度下，我开始思考，既然是资源管理系统，为什么不从资源本身的角度出发，来思考对其生命周期的管理。

以腾讯云的cvm和华为云的ecs为例，其本质都是弹性云服务器.聚焦弹性云服务器，我们需要做到对其生命周期的管理，例如创建、回收、查询、更改配置等操作，这是不论哪个云厂商都需要支持的功能.

从这种角度出发，流程就可以梳理成这样：
工单系统审批完成后，调用资源管理系统的接口创建云服务器，资源管理系统返回申请id，是记录在系统中标识唯一一次申请的记录，后续的操作就由资源管理系统来完成，工单系统只需要定时根据申请id查询本次申请的状态是否是已完成，完成后获取机器的基本信息.

这种做法从工单系统的角度来说，就简单了很多，只需要去调用接口申请机器，后面不论是腾讯云还是华为云的逻辑都无需关心，这样相对来说是比较合理的。

接下来就需要对资源管理系统进行改造和优化了。
以下是我设计的类图：

简单介绍下每个类各自的作用：

CvmService接口：
在这个接口中，我主要定义了关于弹性服务器在创建的场景下，需要提供的方法，和我上面描述的一样，包含一个创建服务器的接口和查询创建申请状态的接口。在这个接口类的方法更主要为弹性服务器自身生命周期或者其他需要对外提供的方法，类似以后我会提供回收服务器，查询服务器信息等接口。

BaseCvmServiceImpl抽象类：
在这个抽象类中，我主要做了两件事情，定义公共的函数以及确定一些方法的流程。定义公共函数应该比较容易理解，例如无论是腾讯云或是华为云，创建成功以后一定需要插入cmdb中，或者是对申请记录的增删改查，这些都是公共的方法，可以将它们放在这个公共类中，减少重复代码的出现。另外确定一些方法的流程，我还是以创建的方法举例，在抽象类中，我实现了createCvmInstance接口方法，在方法的实现中，我约定了创建的整个流程。

首先是对参数的校验，校验通过后，开始在服务器申请表中新增一条记录，然后调用云平台API创建机器，然后更新申请的状态，将申请id返回给调用方。随后通过定时任务去完成后续的操作。

以抽象类中的createCvmInstance为例，将上述我说的流程进行了约定和实现，其中校验参数的checkCreateCvmParam方法和invokeCreateCvm方法都是定义的抽象方法，需要各自云平台的实现类需要去实现。

同样的 completeCvmCreateApplyTask方法是用来完成调用创建后后续的操作的，我也进行了同样的约定和实现，在这里就不多讲了。

另外说明一点就是我对申请状态的定义：

大致概括了所有会出现的场景。

各自云平台的实现类：
各自云平台的实现类就没什么好说的了，就是实现一些父类中的抽象方法和自己的方法。这里我在编写的过程中有个改变就是，将*终调用云平台的API单独放在了一个Api类中，这里的一个方法对应着云平台的一个方法，这样拆分，使得细粒度上允许这些API方法的重复使用，也更加的清晰

以上的架构相较之前有什么优势，我认为是以下几点：

1.系统间的耦合度降低
2.系统内重复代码更少
3.系统更具有扩展性

在开发过程中，我约定好以上的结构后，首先开发了华为云ECS创建的实现，随后又把之前已有的腾讯云的逻辑按照现在的结构也重写了一遍。在写腾讯云的过程，我的感受就是的确比*次写的时候轻松很多，因为很多方法的结构已经确定了，也存在很多公用的代码已经开发完成，只需要补一些个性的代码，整体流程就完成了。

以上方法实现以后，对于接入层来说，也只需要一套代码就可以搞定，可以使用工厂模式，获取对应云平台的实现类来调用。

不过没有一样东西是完美的，架构也是。上面的这种方法，其实对基类中的流程约定是有一定要求的，需要具有一定的通用性。如果太过通用，就会出现很多重复代码，对流程的限制也少了。但是如果不够通用，那么以后在扩展时，就会很头疼，有时候可能需要硬生生往上靠。不过系统本来就是需要一步步优化的，区别就是有的人看得近，有的人看得远。

思考

以上的优化，我从中的思考有两点：

1.优化后，云资源就可以做到真正的管理，这样的话后续的就可以在成本管理上做些文章。成本管理对所有互联网公司来说，都是必不可少的（此处忽略那些财大气粗的场）。当整体系统都上云以后，每个月都可以统计公司在成本上的支出，同时也可以多种角度多维度进行比较分析数据，帮助公司省钱。

2.另一点则是这次改造后我的想法，由于之前看过公司内，公司外部的开源代码库，对于知名的框架例如：springboot、dubbo、mybatis等，在阅读源码理解原理的同时，我也一直感叹这些代码的架构之美，但是反观自己，可能更多的是在写一些模块的业务逻辑，要么就是写MVC的东西、要么就是别人已经设计好框架，只需要去填充就好了，在架构上并没有好好的思考过。即使是在互联网公司，更多的是注重快速，快速的实现、发布、迭代、反馈。然而随着时间的推移，场景的变化，往往起初的设计思想和架构体系需要更新换代，这个时候沉下心去思考下，即使花更多的时间，我觉得也是更有意义的。而且大部分的系统和代码都是需要有一批批的开发者来维护和创新，只有前面的骨架搭得好，系统才能逐渐完善和壮大。

————————————————

原文链接：https://blog.csdn.net/qq_20614905/article/details/109703337

云计算灾备：云时代CIO的心病

某云因为“一个未知代码bug”，爆发了大规模宕机事件，大量的互联网公司受其影响，App、网站全部瘫痪

造成的经济损失不可估量，从老板到员工都从清晨温暖的被窝里爬出来赶去公司应急处理。业界有人戏称某云是“一年

一宕机，今年特别早”。

无独有偶，去年也有多家云计算供应商出现大规模的现网事故，北京一家初创公司在使用某云服务器8个月后，放在云服

务器上包括备份的数据全部丢失，导致公司几年来的平台数据全部丢失，造成“近千万元损失”。

在云计算时代，云计算所带来的种种优势使得大量的企业纷纷将自身业务在云端托管，但当云服务出现故障时带来的损

失难以控制，也令许多企业的CIO们忧心忡忡。显然，“不将所有的鸡蛋放在一个篮子里”是一种*有效的方案，即通

过将业务部署在多个云（不同的公有云、私有云）来进行灾备。

多云/混合云+容器：Cloud 2.0时代的良药

在各种多云/混合云的解决方案中，多云/混合云+容器的组合是一种更好的选择。

首先，由于容器提供了统一的软件交付标准，应用与整个运行时环境分离，所以用户可在多个云上的容器服务间随意的

迁移这些应用，而不必担心对环境的依赖，同时也有效地避免了云供应商的锁定。

同时，由于容器的秒级弹性机制，用户可以快速的对不同云上的应用和资源进行弹性伸缩，企业的成本并不会因为使用

多云方案而明显的增加。

*后，多云/混合云容器解决方案是一种轻技术栈的方案，搭建与部署较为简单，无须考虑大量的基础设施的问题。

这些都是传统的多云/混合云解决方案所不具备的。

华为容器多云/混合云解决方案：基于集群联邦的云灾备实践

目前业界主流的容器服务，基本上都是使用CNCF社区的Kubernetes。而Kubernetes官方社区的多云容器的方案集群

联邦（Kubernetes Cluster Federation），是在15年由华为云容器团队引入社区并主导，经过多年的发展，华为云容

器团队将在本月发布业界首个商用级别的多云容器解决方案。

华为容器多云/混合云解决方案基于社区的集群联邦技术，提供了跨云的多集群统一管理、应用在多集群的统一部署和流量

分发，并可以结合Istio技术，实现应用流量的全局治理（南北向+东西向），为您彻底解决云灾备问题的同时，也可以在

很多场景下发挥价值。

华为容器多云/混合云解决方案适用于以下场景：

• 业务云上灾备场景

通过华为容器多云/混合云解决方案，用户可以将自身的业务同时部署在多个云的容器服务上，在某个云出现事故时，通过

统一流量分发的机制，自动的将业务流量切换到其他云上，同时通过Kubernetes的快速弹性能力，迅速在其他云上扩容应

用和资源。*快秒级自动解决一次现网事故，再也不用担心“一年一宕机”的问题了。

• 业务流量分发场景

通过华为容器多云/混合云解决方案，业务可以同时部署在不同地域的云机房中，通过统一流量分发的机制，实现应用访问

流量的地域亲和，降低业务访问时延；同时，用户可以将线下IDC中的业务在云上扩展，当业务流量激增时，快速在云上弹

性扩容，将大部分的流量引导到云上实例；在流量回落后，自动缩容云上实例，流量全部回归线下IDC，用户不再需要根

据流量峰值始终保持和维护大量资源，节约成本。

• 业务与数据分离场景

对于金融、安全等行业的用户，业务数据的敏感性要求相关业务必须运行在用户的IDC中，通过华为容器多云/混合云解决

方案，用户就可以将数据业务保留在本地的IDC中而将一般业务部署在云上，通过多云/混合云容器解决方案统一管理。

• 开发与部署分离场景

在CI/CD的场景中，一些用户处于IP安全的考虑，希望开发环境在本地的IDC，生产环境在云上。通过华为容器多云/混合云

解决方案，就可以将开发环境的集群和生产环境的集群统一管理，实现应用线上发布的全自动流水线。

• 业务与计算分离场景

对于AI、基因测序、视频处理等行业的用户，其计算任务依赖特殊的硬件，如CPU、裸金属服务器等，通过华为

容器多云/混合云解决方案，用户就可以将计算业务部署在云上，弹性利用云上的特殊硬件算力，而在私有云或其他云上

部署一般业务，避免了大规模使用特殊硬件带来的成本压力。

一、redis持久化的两种方式：
RDB: 对内存中数据库状态进行快照
AOF: 把每条写命令都写入文件
RDB方式：将redis在内存中的数据库状态保存到磁盘里面，RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件的数据状态。

RDB的生成方式：

指向命令手动生成
通过配置自动生成
1.指向命令手动生成

有两个redis命令可以生成RDB文件，一个是SAVE，另一个是BGSAVE，SAVE命令会阻塞redis服务器进程，直到RDB文件

创建完毕为止，在服务器阻塞期间,服务器不能处理任何的进程,BGSAVE会派出一个子进程，然后由子进程负责创建RDB

文件，服务器进程（父进程）继续处理命令请求，创建RDB文件结束之前，客户端发送的 BGSAVE 和 SAVE 命令会被服务器拒*

2.通过配置自动生成

可以设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令，可以通过save选项设置多个保

存条件，但只要其中任意一个条件被满足就会执行BGSAGE命令

AOF方式：是通过保存redis服务器所执行的写命令来记录数据库状态的AOF文件刷新方式，有三种：

1.appendfsync always — 每提交一个修改命令都调用fsync到AOF文件，非常慢，但是很安全；

2.appendfsync everysec — 每秒都调用fsyns刷新到AOF文件，很快但可能丢失一秒内的数据；

3.appendfsync no — 依靠OS进行刷新，redis不主动刷新AOF，这样*快但是安全性差；

默认并且推荐每秒刷新，这样在速度和安全上都做到了兼顾

二、数据恢复
1.ROB方式

ROB文件的载入工作是在服务器启动时自动执行的，没有专门用于载入ROB文件命令，只要redis服务器再启动时检测到

ROB文件存在，它就会自动载入ROB的文件，在服务器载入的期间，会一直处于阻塞状态，直到载入工作完成为止

2.AOF方式

服务器在启动时，通过载入和执行AOF文件中保存的命令来还原服务器关闭之前的数据，具体过程：

载入AOF文件

创建模拟客户端

从AOF文件中读取一条命令

使用模拟客户端执行命令

循环读取并执行命令，直到全部完成

如果同时启动了AOF和ROB方式，AOF优先，启动时只加载AOF文件恢复数据

三、RDB和AOF对比总结
两种备份方案的选择：

对于RDB持久化，

一方面是bgsave在进行fork操作时redis主进程会阻塞，

另一方面，子进程向硬盘写数据也会带来IO压力，但数据的完整性和一致性受备份条件影响可能较差；

而AOF持久化由于持续的写入IO压力更大，但数据的一致性和完整性较好。
————————————————

原文链接：https://blog.csdn.net/qq_35275233/article/details/87892822

sloat · 141 天前 · 1861 次点击
这是一个创建于 141 天前的主题，其中的信息可能已经有所发展或是发生改变。
墨西哥北美网速及延迟测试 背景介绍 *近我们公司打算在北美部署 SAAS 应用，原来老板已经决定部署在 BAT 北美区域的云上，但前段时间看到米国的“净网行动”，老板十分担心业务的可持续性，怕 BAT 云被禁后业务中断，前期投入泡汤，让我寻找其他方案。恰好双十一期间在找海外服务器优惠的时候，发现华为云在墨西哥城有云服务，老板就让测测墨西哥城访问米国及枫叶国的时延，看看是否能满足业务需求。 测试发现网络质量不错，想着有人应该跟我们有类似的需求，就把测试过程跟结果发出来，给大家做个参考。 墨西哥访问北美网络时延测试 以下图场景为例。我在华为云的拉美-墨西哥城一区域购买了 ECS 实例和 EIP，部署了一个简单的 Web 服务，并分别测试米国、枫叶国通过公网访问墨西哥节点网络时延。

光说没用，上来就测，干他~！ 先上搬瓦工的测速站点，大部分 VPS 厂商节点通过公网访问我在墨西哥城部署的 web 应用，IP 网络延迟如下：

惊喜！米国的西部、中部、东部访问墨西哥节点时延竟然只有 50~80ms，同时也没有丢包，其中洛杉矶的 VPS 供应商 quadraNET 到墨西哥竟然有 43ms 。枫叶国到墨西哥节点时延是 72~100ms，只有温哥华有 2.6%的丢包率。 墨西哥城访问北美的网络时延，对于我们来说完全能满足网络需求。 再测下墨西哥节点访问米国西部阿里云测速域名的延迟，测速网址：oss-us-west-1.aliyuncs.com

基本在 62ms 左右。 在测下墨西哥节点访问米国东部阿里云延迟，测速网址：oss-us-east-1.aliyuncs.com

比西部高 20ms 左右，基本在 82ms 左右。

现在受国际环境影响，直接在北美部署业务存在太多不确定性，幸好华为云墨西哥城节点可以覆盖北美区域，并且网络延迟在 100ms 以下，给我们出海企业吃了颗定心丸。

墨西哥 墨西哥城 节点 北美2 条回复 • 2020-12-03 16:25:37 +08:00
Inuyashaaa 1
Inuyashaaa 136 天前
考虑净网行动怕被封所以从 BAT 转华为，这是什么逻辑？服务北美用户的 SaaS 数据放华为还是放境外，这是提前准备上实体清单吗？为啥不直接用 AWS/Azure/GCP
bytejet 2
bytejet 126 天前
回头有云连接这块的需求可以随时联系！

resouer · 137 天前 · 2111 次点击
这是一个创建于 137 天前的主题，其中的信息可能已经有所发展或是发生改变。
什么是 KubeVela ？
一言以蔽之，KubeVela 是一个简单易用且高度可扩展的应用管理平台与核心引擎。KubeVela 是基于 Kubernetes 与 OAM 技术构建的。

详细的说，对于应用开发人员来讲，KubeVela 是一个非常低心智负担的云原生应用管理平台，核心功能是让开发人员方便快捷地在 Kubernetes 上定义与交付现代微服务应用，无需了解任何 Kubernetes 本身相关的细节。在这一点上，KubeVela 可以被认为是云原生社区的 Heroku。

另一方面，对于平台团队来讲，KubeVela 是一个强大并且高可扩展的云原生应用平台核心引擎。基于这样一个引擎，平台团队可以快速、高效地以 Kubernetes 原生的方式在 KubeVela 中植入任何来自云原生社区的应用管理能力，从而基于 KubeVela 打造出自己需要的云原生平台，比如：云原生数据库 PaaS 、云原生 AI 平台、甚至 Serverless 服务。在这一点上，KubeVela 可以被认为是一个“以应用为中心”的 Kubernetes 发行版，以 OAM 为核心，让平台团队可以基于 KubeVela 快速打造出属于自己的 PaaS 、Serverless 乃至任何面向用户的云原生平台项目。

中文详细介绍文章： https://mp.weixin.qq.com/s/LauydAy1ngcDuZ3lhqrL6Q
项目主页： https://github.com/oam-dev/kubevela/
项目文档： https://kubevela.io

现在在项目里已经大量使用redis了，为了提高redis的性能和可靠性我们需要知道和做到以下几件事：

常用内存优化手段与参数
redis的性能如何是完全依赖于内存的，所以我们需要知道如何来控制和节省内存。

首先*重要的一点是不要开启Redis的VM选项，即虚拟内存功能，这个本来是作为Redis存储超出物理内存数据的一种数据在内存与磁盘换入换出的一个持久化策略，但是其内存管理成本非常的高，所以要关闭VM功能，请检查你的redis.conf文件中 vm-enabled 为 no。

其次*好设置下redis.conf中的maxmemory选项，该选项是告诉Redis当使用了多少物理内存后就开始拒*后续的写入请求，该参数能很好的保护好你的Redis不会因为使用了过多的物理内存而导致swap,*终严重影响性能甚至崩溃。

另外Redis为不同数据类型分别提供了一组参数来控制内存使用，我们知道Redis Hash是value内部为一个HashMap，如果该Map的成员数比较少，则会采用类似一维线性的紧凑格式来存储该Map, 即省去了大量指针的内存开销，这个参数控制对应在redis.conf配置文件中下面2项：

hash-max-zipmap-entries 64
hash-max-zipmap-value 512
含义是当value这个Map内部不超过多少个成员时会采用线性紧凑格式存储，默认是64，即value内部有64个以下的成员就是使用线性紧凑存储，超过该值自动转成真正的HashMap。

hash-max-zipmap-value 含义是当 value这个Map内部的每个成员值长度不超过多少字节就会采用线性紧凑存储来节省空间。

以上2个条件任意一个条件超过设置值都会转换成真正的HashMap，也就不会再节省内存了，那么这个值是不是设置的越大越好呢，答案当然是否定的，HashMap的优势就是查找和操作的时间复杂度都是O(1)的，而放弃Hash采用一维存储则是O(n)的时间复杂度，如果成员数量很少，则影响不大，否则会严重影响性能，所以要权衡好这个值的设置，总体上还是*根本的时间成本和空间成本上的权衡。

同样类似的参数还有：

list-max-ziplist-entries 512
说明：list数据类型多少节点以下会采用去指针的紧凑存储格式。

list-max-ziplist-value 64
说明：list数据类型节点值大小小于多少字节会采用紧凑存储格式。

set-max-intset-entries 512
说明：set数据类型内部数据如果全部是数值型，且包含多少节点以下会采用紧凑格式存储。

Redis内部实现没有对内存分配方面做过多的优化，在一定程度上会存在内存碎片，不过大多数情况下这个不会成为Redis的性能瓶颈，不过如果在Redis内部存储的大部分数据是数值型的话，Redis内部采用了一个shared integer的方式来省去分配内存的开销，即在系统启动时先分配一个从1~n 那么多个数值对象放在一个池子中，如果存储的数据恰好是这个数值范围内的数据，则直接从池子里取出该对象，并且通过引用计数的方式来共享，这样在系统存储了大量数值下，也能一定程度上节省内存并且提高性能，这个参数值n的设置需要修改源代码中的一行宏定义REDIS_SHARED_INTEGERS，该值默认是10000，可以根据自己的需要进行修改，修改后重新编译就可以了。

持久化
redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化。redis支持两种持久化方式，一种是 Snapshotting（快照）也是默认方式，另一种是Append-only file（缩写aof）的方式。

snapshotting
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置:

save 900 1 #900秒内如果超过1个key被修改，则发起快照保存
save 300 10 #300秒内容如超过10个key被修改，则发起快照保存
save 60 10000 #60秒内容如超过10000个key被修改，则发起快照保存
也可以命令行的方式让redis进行snapshotting：
redis-cli -h ip -p port bgsave
保存快照有save和bgsave两个命令，save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有 client的请求，这种方式会阻塞所有client请求，所以不推荐使用。
快照生成过程大致如下：

redis调用fork,现在有了子进程和父进程；
父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照；
当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。
同时snapshotting也有不足的，因为两次快照操作之间是有时间间隔的，一旦数据库出现问题，那么快照文件中保存的数据并不是全新的，从上次快照文件生成到Redis停机这段时间的数据全部丢掉了。如果业务对数据准确性要求*高的话，就得采用aof持久化机制了。

aof
aof 比快照方式有更好的持久化性，是由于在使用aof持久化方式时，redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存 write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要通过fsync函数强制os写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次）：

appendonly yes //启用aof持久化方式
# appendfsync always //每次收到写命令就立即强制写入磁盘，*慢的，但是保证完全的持久化，不推荐使用
appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
# appendfsync no //完全依赖os，性能*好,持久化没保证
aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据 以命令的方式保存到临时文件中，*后替换原来的文件。bgrewriteaof命令如下：

redis-cli -h ip -p port bgrewriteaof
bgrewriteaof命令执行过程如下：
redis调用fork ，现在有父子两个进程；
子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令；
父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题；
当子进程把快照内容写入以命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件；
现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。
这两种持久化方式有各自的特点，快照相对性能影响不大，但一旦崩溃，数据量丢失较大，而aof数据安全性较高，但性能影响较大，这就得根据业务特点自行选择了。

主从复制
redis的主从复制策略是通过其持久化的rdb文件来实现的，其过程是先dump出rdb文件，将rdb文件全量传输给slave，然后再将dump后的操作实时同步到slave中。

要使用主从功能需要在slave端进行简单的配置：
slaveof master_ip master_port #如果这台机器是台redis slave，可以打开这个设置。
slave-serve-stale-data no #如果slave 无法与master 同步，设置成slave不可读，方便监控脚本发现问题。
配置好之后启动slave端就可以进行主从复制了，主从复制的过程大致如下：

Slave端在配置文件中添加了slaveof指令，于是Slave启动时读取配置文件，初始状态为REDIS_REPL_CONNECT；
Slave端在定时任务serverCron(Redis内部的定时器触发事件)中连接Master，发送sync命令，然后阻塞等待master发送回其内存快照文件(*新版的Redis已经不需要让Slave阻塞)；
Master端收到sync命令简单判断是否有正在进行的内存快照子进程，没有则立即开始内存快照，有则等待其结束，当快照完成后会将该文件发送给Slave端；
Slave端接收Master发来的内存快照文件，保存到本地，待接收完成后，清空内存表，重新读取Master发来的内存快照文件，重建整个内存表数据结构，并*终状态置位为 REDIS_REPL_CONNECTED状态，Slave状态机流转完成；
Master端在发送快照文件过程中，接收的任何会改变数据集的命令都会暂时先保存在Slave网络连接的发送缓存队列里（list数据结构），待快照完成后，依次发给Slave,之后收到的命令相同处理，并将状态置位为 REDIS_REPL_ONLINE。
整个复制过程完成，流程如下图所示：

从以上的复制过程中可以发现，Slave从库在连接Master主库时，Master会进行内存快照，然后把整个快照文件发给Slave，也就是没有象MySQL那样有复制位置的概念，即无增量复制，如果一个master连接多个slave，就会比较影响master性能了。

数据备份策略
具体的备份策略是可以很灵活的，比如可以大致如下：

为了提高master的性能关闭master的持久化机制，即不进行快照也不进行aof，而是在凌晨访问量低的时候定时的用bgsave命令进行快照，并将快照文件保存到备份服务器上；
slave端开启aof机制，并定时的用bgrewriteaof 进行数据压缩，将压缩后的数据文件保存到备份服务器上；
定时的检查master与slave上的数据是否一致；
当master出问题并需要恢复时，如果采用master的备份快照恢复直接将备份的dump.rdb拷贝到相应路径下重启即可；如果要从slave端恢复，需要在slave端执行一次快照，然后将快照文件拷贝到master路径下然后重启即可。不过有一点需要注意的是，master重启时slave端数据会被冲掉，所以slave端要在master重启前做好备份。
持久化磁盘IO方式及其带来的问题
有Redis线上运维经验的人会发现Redis在物理内存使用比较多，但还没有超过实际物理内存总容量时就会发生不稳定甚至崩溃的问题，有人认为是基于快照方式持久化的fork系统调用造成内存占用加倍而导致的，这种观点是不准确的，因为fork 调用的copy-on-write机制是基于操作系统页这个单位的，也就是只有有写入的脏页会被复制，但是一般的系统不会在短时间内所有的页都发生了写入而导致复制，那么是什么原因导致Redis崩溃的呢？

答案是Redis的持久化使用了Buffer IO造成的，所谓Buffer IO是指Redis对持久化文件的写入和读取操作都会使用物理内存的Page Cache，而大多数数据库系统会使用Direct IO来绕过这层Page Cache并自行维护一个数据的Cache，而当Redis的持久化文件过大(尤其是快照文件)，并对其进行读写时，磁盘文件中的数据都会被加载到物理内存中作为操作系统对该文件的一层Cache，而这层Cache的数据与Redis内存中管理的数据实际是重复存储的，虽然内核在物理内存紧张时会做Page Cache的剔除工作，但内核可能认为某块Page Cache更重要，而让你的进程开始Swap，这时你的系统就会开始出现不稳定或者崩溃了。经验是当你的Redis物理内存使用超过内存总容量的3/5时就会开始比较危险了。

————————————————

原文链接：https://blog.csdn.net/tonyXf121/article/details/8475603