vivo 官网商城开发团队：同城双活与异地多活架构分析，java 面试问项目流程
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 入口网关
还未添加个人签名 2021.03.18 加入
还未添加个人简介
评论