常常听到“两地三中心”原来是：
 
两地 = 本地 + 异地
 
三中心 = 本地数据中心 + 本地备份数据中心 + 异地数据备份中心
 
 
 
主备数据中心之间一般有热备、冷备、双活三种备份方式。
 
热备的情况下，只有主数据中心承担用户的业务，此时备数据中心对主数据中心进行实时的备份，当主数据中心挂掉以后，备数据中心可以自动接管主数据中心的业务，用户的业务不会中断，所以也感觉不到数据中心的切换。
 
冷备的情况下，也是只有主数据中心承担业务，但是备用数据中心不会对主数据中心进行实时备份，这时可能是周期性的进行备份或者干脆不进行备份，如果主数据中心挂掉了，用户的业务就会中断。
 
双活是觉得备用数据中心只做备份太浪费了，所以让主备两个数据中心都同时承担用户的业务，此时，主备两个数据中心互为备份，并且进行实时备份。一般来说，主数据中心的负载可能会多一些，比如分担60~70%的业务，备数据中心只分担40%~30%的业务 。
 
 
 
参考文章：https://www.cnblogs.com/agileai/p/6000062.html
 

      同城双活应该很多人都有了解，也就是两个区两个应用同时接收流量且互不影响一方有难另一方能撑住全部流量具体大家可以网上了解这里只针对dubbo输出下我们的方案如果哪里有不对的欢迎指正共同成长共同进步。
 
1.先看下大体的一个结构
 
 
       这里做下说明，观澜和福田是深圳的两个片区，分别部署两套集群，zk这里我们做了互相同步保持数据一致，也就是zk福田中有观澜的服务，zk观澜有福田的服务，你中有我我中有你的感觉，这样一方挂了之后才能保持服务不断，但是我们正常情况下我们要保证：1.福田的消费方消费福田的服务 2.观澜的消费方消费观澜的服务 如果一方出问题我们要能快速回切（这里我们用了apollo做配合）
 
为了实现上述效果,这里我我们重写了dubbo的loadbance具体流程参见如下（为了简单我并没有画出zk）
 
 
      这里消费方消费服务时通过我们自己的loadbance进行进行区分不同的服务，loadbance怎么区分出属于各自的服务呢？
 
1. 消费方要知道自己所属片区（如观澜（gl）福田（ft））注：apollo配置
 
2. 消费方要知道服务所属片区（如观澜（gl）福田（ft）） 注：服务提供方设置带有片区名称的应用名称如setApplicationName("dubbo.provider.服务名称.gl")和setApplicationName("dubbo.provider.服务名称.ft")，服务名称可以通过apollo配置，不同的片区取对应的名称。
 
 我们分步骤看下代码：
 
1.重写loadbance
 
/**
  * 本地优先负载均衡
  **/
 public class LocalPriorityLoadBalance extends AbstractLoadBalance {
 
    private final static String SPLIT_TAG = "-";
     private final static String DUBBO_PROVIDER_APPLICATION_NAME_PRIFIX = "dubbo.provider.";
     private final static String CONSUME_IDC = "consume.idc"；
 
    @Override
     protected <T> Invoker<T> doSelect(List<Invoker<T>> list, URL url, Invocation invocation) {
          //过滤出本机房服务
      List<Invoker<T>> ipList = filterDataCenter(list);
      if (CollectionUtils.isNotEmpty(ipList)) {
 
            //把本机房ip出入dubbo的默认负责均衡中
            return new RandomLoadBalance().select(ipList, url, invocation);
     }
 
       //如果没过滤出来这里走默认的
 
   return new RandomLoadBalance().select(list, url, invocation);
     
     }
 
//过滤本机房服务
 
....................................................................................................
 
}
 
 
2. 使自己写的loadbance生效
 
 在项目resources/META-INF.duduo中新建：
 
com.alibba.dubbo.rpc.protocol
 
然后把我们自己写的loadbance路径和名称写进去：
 loadProvityLoadBalance=com.xxy.dubbo.LocalPriorityLoadBance
 
3. 使用我们自己的loadbance
 
可以针对每个接口进行指定，因为我们实际中并不需要每个服务都需要做双活
 
<dubbo:reference id="id" interface="com.xxy.xx" loadbance="loadProvityLoadBalance"/>
 
总结
 
上面只写了大致的思路代码并未完全给出，因为剩余代码相对也比较简单，如果有需要可以联系沟通，下面是个人微信公众为方便沟通欢迎大家加入一起成长 一起发财
 
 
 
 
 
 
 
 
 
 
 
 

 

  

  
存储双活已家喻户晓人人皆知，但是，你知道存储双活+虚拟化+应用集群，应该如何部署呢？在“数据中心双活该如何构建”文章中，谈到要构建从应用、服务器、网络到存储的端到端双活，必须要求端到端每个部件支持双活才可以。但由于很多应用不支持集群部署，这种情况只能从网络和存储层，或通过服务器虚拟化软件HA功能实现双活；今天重点聊聊基于虚拟机软件的应用该如何部署双活。
  
在医疗、证券交易、政府和制造等行业，对存储高可用和业务连续性有较高需求，业务集中在Oracle、虚拟化、ERP、MS SQL、HIS等业务系统，业务的实时在线诉求使其对双活方案需求也相对更旺盛一些。
  
但随着虚拟化和云计算广泛使用，核心业务已经逐渐实现虚拟化，大多数客户现网应用都呈现出物理、虚拟化混合的景象，在云计算领域，OpenStack的Ironic模块和技术，就是要实现物理和虚拟化的整合和云统一，具体参看“OpenStack Ironic如何管理物理和虚拟计算资源”文章。那在双活方案中，也需要同时考虑物理和虚拟化应用部署方案，下面拿Oracle数据为例来说明。
  
随着Oracle数据库不断被部署在虚拟化环境，通常情况，对业务连续性方案的考虑无碍乎采用主备容灾和双活。主备容灾方案要么是存储数据级复制，或是采用数据库Golden Gate或Data Gurd特性复制，但是数据库特性本身License比较昂贵，且无法自动化主备切换，更不能满足业务对连续性RPO=0、RTO=0要求，即使采用存储复制技术也很难解决RTO=0的要求。
  
所以双活方案就逐渐的成了首选，在考虑到商务问题，Oracle RAC相对于操作系统集群、Hypervisor自带的HA，也存在价格问题，所以在在项目实施过程中，一般也是折中建议客户采用系统自带应用和虚拟化集群。
  
存储双活方案中，需要保证端到端的双活，存储需要支持双活。目前主流存储厂商都支持双活特性和部署方案，如华为HyperMetro、HDS GAD、Dell Live Volume、IBM HyperSwap(配合阵列MetroMirror)和SVC ESC、富士通 Storage Cluster、HP PeerPersistence、EMC vPlex和VMAX3 SRDF/Metro、Netapp MetroCluster (在Syncmirror数据镜像之上增加了FailOver功能)。或者在应用和服务器层提供存储双活方案，如Oracle RAC(配合ASM)和GPFS(配合Oracle RAC或PureScale)。这些存储双活技术有所差别，但在业务连续性上，实现的效果很类似。
  
但针对双活服务器应用层的集群部署方案，需要结合应用集群软件，业务容灾诉求综合考虑，目前主要的部署方式包括下面几种情况。
  
物理应用部署
  
Oracle、DB2、Exchange和SAP HANA等应用集群部署在物理服务器上时，业务自动切换就需要Oracle RAC、DB2、MSFC或操作系统自动的集群软件实现，这种方式适合时延、性能要求很高的场景。
  
虚拟应用部署
  
Oracle，DB2，Exchange等应用部署在Vmware、Hyper-V或Fusioshere 等VM上时；在集群可靠性上，首先Vmware，Hyper-V和Fusionshere VM具备HA功能切换，再者基于VM内的Oracle，DB2，Exchange等应用也具有HA能力，所以，虚拟化上部署应用集群又有2种部署方式。
  
单机应用部署：即Oracle RAC、DB2、MSFC单机部署在VM中，采用虚拟化平台的HA功能切换。优点部署简单，切换容易，这种部署方式有大量案例，所以经过充分验证。
集群应用部署：除了Hypervisor的HA切换外，还需要依靠Oracle RAC、DB2、MSFC或操作系统集群软件切换，即在应用层实现嵌套集群部署。
  
在第二种部署方案中，Hypervisor的HA集群和应用集群一般都会有兼容性问题，一旦出现问题，很多Hypervisor厂商也不提供技术支持，如VMware和Oracle都是相互建议不同时部署集群，类似的，其他Hypervisor和应用集群理论上也有类似问题。总之，在应用虚拟化双活方案，目前应用还是主要采用单机部署方式。
  
下面谈谈云存储和存储如何上云。云存储概念想必大家都耳熟能详，但什么是云存储目前没有统一的定论。现实中很多厂商宣传的云存储并不具备上述特点。那么怎样的存储才是云存储，云存储应该具备怎样的特征，以及从技术层面谈谈存储上云的思路。
  
云存储源自云计算，也类似云计算，所以应该从服务角度出发，分析其应该具备的存储服务能力。
  
首先，云存储应该支持自助能力和租户角色，让租户觉得自己使用的就是一台单独的存储服务设备，而且可以自助配置、按需求通过电子流获取资源；
再次，云存储应该支持SAL或服务等级要求，厂商基于不同客户的行业背景和业务负载，提供SLA模板，匹配业务需求。
其次，云储存应该支持计费和计量能力，让服务可以度量，不造成资源的浪费。
最后，云存储应该采用新的商业模式和付费模式，迎合云计算和大数据对存储的弹性要求，比如PayU、PayG模式，既可以吸引客户、减低客户对存储投资的风险压力，又可以刺激存储厂商的创新能力。
  
云存储离不开基于云计算技术的支持，目前已经有成熟的云存储产品和存储上云的商业实践，下面我们简单看几个存储上云或云存储的例子，如果您有更多实践和卓见，欢迎留言一起讨论。
  
云网盘或企业网盘，统一Portal或客户端访问，按需分配、计量付费，多为对象存储，用时注册不用时注销。采用存储免费试用模式。
数据服务编排，主要针对大企业客户，存储资源池化，基于SLA和模块定制，统一Portal提供服务目录；支持拉拽式容灾和备份，用户对底层数据物理位置无感知，产品如EMC Vipr和Huawei DJ等产品。
对接云计算平台，数据服务化能力上报给云计算平台，上层云计算租户根据需求和SLA要求，通过智能API和存储级别能力匹配来取数据。
数据在公有云间流动，数据实现不同介质(HDD、SSD、VTL、PTV和S3等)、不同存储、云上和云下分级流动，资源池共享，数据接口互通；很多情况下，通过类似混合云的存储网关承担数据在云上云下流动的枢纽。产品如IBM SmartCloud Storage Access、NetApp DataFabric/ Fabric Pool、EMC CloudArray等。
  

   
温馨提示：请搜索“ICT_Architect”或“扫一扫”下面二维码关注公众号，获取更多精彩内容。
   

   

    

   
   

  
 

 
 
本文首发于 vivo互联网技术 微信公众号
 链接：https://mp.weixin.qq.com/s/OjfFcjnGWV5kutxXndtpMg
 作者：vivo官网商城开发团队
 
 
采用高可用系统架构支持重要系统，为关键业务提供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、同城双活方案评估
 
优势
 
 
 
 
服务同城双活，数据同城灾备，同城不丢失数据情况下跨机房级别容灾。
 
 
架构方案较为简单，核心是解决底层数据双活，由于双机房距离近，通信质量好，底层储存例如mysql可以采用同步复制，有效保证双机房数据一致性。
 
 
劣势
 
 
 
 
数据库写数据存在跨机房调用，在复杂业务以及链路下频繁跨机房调用增加响应时间，影响系统性能和用户体验。
 
 
保证同城市地区容灾，当服务所在的城市或者地区网络整体故障、发生不可抗拒的自然灾害时候有服务故障以及丢失数据风险。对于核心金融业务至少要有跨地区级别的灾备能力。
 
 
服务规模足够大(例如单体应用超过万台机器)，所有机器链接一个主数据库实例会引起连接不足问题。
 
 
三、两地三中心架构
 
所谓两地三中心是指 同城双中心 + 异地灾备中心。异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，数据和服务平时都是冷的，当双中心所在城市或者地区出现异常而都无法对外提供服务的时候，异地灾备中心可以用备份数据进行业务的恢复。
 
 
两地三中心方案评估
 
优势
 
 
 
服务同城双活，数据同城灾备，同城不丢失数据情况下跨机房级别容灾。
架构方案较为简单，核心是解决底层数据双活，由于双机房距离近，通信质量好，底层储存例如mysql可以采用同步复制，有效保证双机房数据一致性。
灾备中心能防范同城双中心同时出现故障时候利用备份数据进行业务的恢复。
 
劣势
 
 
 
 
数据库写数据存在跨机房调用，在复杂业务以及链路下频繁跨机房调用增加响应时间，影响系统性能和用户体验。
 
 
服务规模足够大(例如单体应用超过万台机器)，所有机器链接一个主数据库实例会引起连接不足问题。
 
 
出问题不敢轻易将流量切往异地数据备份中心，异地的备份数据中心是冷的，平时没有流量进入，因此出问题需要较长时间对异地灾备机房进行验证。
 
 
同城双活和两地三中心建设方案建设复杂度都不高，两地三中心相比同城双活有效解决了异地数据灾备问题，但是依然不能解决同城双活存在的多处缺点，想要解决这两种架构存在的弊端就要引入更复杂的解决方案去解决这些问题。
 
四、异地多活
 
异地多活指分布在异地的多个站点同时对外提供服务的业务场景。异地多活是高可用架构设计的一种，与传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。
 
1、异地多活挑战
 
（1）应用要走向异地，首先要面对的便是物理距离带来的延时。如果某个应用请求需要在异地多个单元对同一行记录进行修改，为满足异地单元间数据库数据的一致性和完整性，需要付出高昂的时间成本。
 
（2）解决异地高延时即要做到单元内数据读写封闭，不能出现不同单元对同一行数据进行修改，所以我们需要找到一个维度去划分单元。
 
（3）某个单元内访问其他单元数据需要能正确路由到对应的单元，例如A用户给B用户转账，A用户和B用户数据不在一个单元内，对B用户的操作能路由到相应的单元。
 
（4）面临的数据同步挑战，对于单元封闭的数据需全部同步到对应单元，对于读写分离类型的，我们要把中心的数据同步到单元。
 
2、单元化
 
所谓单元(下面我们用RZone代替)，是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据。
 
单元化架构就是把单元作为系统部署的基本单位，在全站所有机房中部署数个单元，每个机房里的单元数目不定，任意一个单元都部署了系统所需的所有的应用。单元化架构下，服务仍然是分层的，不同的是每一层中的任意一个节点都属于且仅属于某一个单元，上层调用下层时，仅会选择本单元内的节点。
 
 
选择什么维度来进行流量切分，要从业务本身入手去分析。例如电商业务和金融的业务，最重要的流程即下单、支付、交易流程，通过对用户id进行数据切分拆分是最好的选择，买家的相关操作都会在买家所在的本单元内完成。对于商家相关操作则无法进行单元化，需要按照下面介绍的非单元化模式去部署。当然用户操作业务并非完全能避免跨单元甚至是跨机房调用，例如两个买家A和B转账业务，A和B所属数据单元不一致的时候，对B进行操作就需要跨单元去完成，后面我们会介绍跨单元调用服务路由问题。
 
3、非单元化应用和数据
 
对于无法单元化的业务和应用，会存在下面两种可能性：
 
（1）延时不铭感但是对数据一致性非常铭感，这类应用只能按照同城双活方式部署。其他应用调用该类应用的时候会存在跨地区调用可能性，要能容忍延时，这类应用我们称为MZone应用。
 
（2）对数据调用延时铭感但是可以容忍数据短时间不一致，这类应用和数据可以保持一个机房一份全量数据，机房之间以增量的方式实时同步，这类应用我们暂时称为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、数据同步
 
（1）QZone类型数据：这种数据只需要保证最终一致性，对于短暂不一致无影响，但是对延时非常铭感，例如一些算法、风控、配置等数据。这类数据基本上都是每个机房部署一套QZone，然后机房之间相互同步。
 
 
（2）MZone数据：这类数据对一致性非常铭感，不能出现不一致，只能采用同城双活部署方式，业务需要能容忍异地调用延时。
 
 
（3）RZone数据：这类数据每个Zone都有自己的主节点，如果数据不在该单元内需要路由到对应的节点去写。这类数据部署情况像下面这样
 
 
6、方案评估
 
优势
 
 
 
 
容灾能力大幅度提高，服务异地多活，数据异地多活。
 
 
理论上系统服务可以水平扩展，异地多机房突破大幅度提升整体容量，理论上不会有性能担忧。
 
 
将用户流量切分到多个机房和地区去，有效能减少机房和地区级别的故障影响范围。
 
 
劣势
 
 
 
 
架构非常复杂，部署和运维成本很高，需要对公司依赖的中间件、储存做多方面能力改造。
 
 
对业务系统有一定的侵入性，由于单元化影响服务调用或者写入数据要路由到对应的单元，业务系统需要设置路由标识(例如uid)。
 
 
无法完全避免跨单元、跨地区调用服务，例如上面的转账业务。我们要做的是尽力避免跨地区的服务调用。
 
 
五、总结
 
本文讨论了一些多活建设的大体思路以及一些关键技术点的解决方案，各种不同方案对比。要建立起完整的异地多活能力远远比上面讨论的要复杂的多，需要对依赖的各种中间件、储存等做相应的单元化改造并配套完整的流量调度和运维管控能力 。
 
由于篇幅限制本文并未详细介绍各种储存(例如Redis、MySQL)在多活下数据同步复制以及高可用方案，有兴趣的同学可以去深入了解这方面知识。
 
更多内容敬请关注vivo 互联网技术微信公众号
 
 
注：转载文章请先与微信号：Labs2020联系