采用高可用性系统架构支撑重要系统，为关键业务提供7x24不间断服务，已经成为许多企业保证业务稳定持续运行的主要选择。 多主动服务是高可用性架构的重要实现手段。本文详细介绍了几种业内常见的多活动手段，如城市双活、两地三中心、异地多活动建筑设计方案，并详述了各方案的优缺点。 一、为什么要多做工作？随着移动互联网的深入发展，客户增长达到一定规模后，许多企业将面临高并发业务和海量数据的挑战。传统的单间在机器能力上有瓶颈。 在少数极端场景下，有可能所有服务器都出现故障，比如机房停电、机房火灾、地震等不可抗拒的因素，导致系统所有服务器都出现故障，导致业务整体瘫痪。而且即使其他地区有备份，恢复所有备份业务系统正常提供业务也需要很长时间。 为了满足中心的业务连续性，加强抗风险能力，多火作为一种可靠、高可用的部署架构，成为各大互联网公司的首选。 1.多活场景多活架构的关键点是不同地理位置的系统可以提供业务服务。这里的“活”是指实时提供服务。 “活”字对应的是“备用”，备用就是备份。正常情况下，不对外提供服务。如果需要提供服务，需要大量的人工干预和操作，将待机转为上线需要大量的时间。 从简单的描述来看，multi-activity是非常强大的，可以保证在灾难的情况下业务不会受到影响。是不是意味着无论什么业务，都要实现多活动架构？实际上，活度架构的实现是要付出一定代价的，具体体现在以下几个方面:不同的活度方案有不同的实现复杂度，随着业务规模和容灾水平的提高，活度方案会给业务系统设计带来更大的复杂度；无论采用哪种多活动方案，都很难完全避免跨房间甚至跨区域服务调用带来的耗时添加；更多的活动会导致更高的成本。毕竟需要在一个或多个机房内搭建独立的业务系统。 所以，虽然多活的功能很强大，但并不是每个业务都需要多活。 例如，IT系统、管理系统、博客网站等。在一个企业内部，如果不能承受异地多做的复杂性和成本，可以不进行异地多做，但对于核心财务、支付、交易等重要业务，必须进行异地多做。 2.多活动方案常见的多活动方案有同城双活动、两地三中心、三地五中心、异地多活动等多种技术方案。不同的多活动方案有不同的技术要求、建设成本以及运营和维护成本。 下面，我们将逐步详细介绍这些多活动方案，并给出每个方案的优缺点。 选择哪种方案总是由许多因素决定的，如具体的业务规模、现有的基础设施容量、投入产出比等。 二、同城双住同城双住就是在同一个城市或类似地区建立两个机房。 同一个城市的两个机房距离比较近，通信线路质量好，很容易实现数据的同步复制，从而保证数据的高度完整和零数据丢失。 同一个城市的两个机房各自承担一部分流量，一般入口流量是完全随机的，内部RPC调用通过最近的路由环路尽可能近的在同一个机房，相当于两个机房两个独立集群的镜像部署，数据还是单点写入主机机房的数据库，然后实时同步到另一个机房。 下图是同城双活的简单部署架构。当然一般真实的部署和考虑远比下图复杂:服务调用基本在同一个机房完成闭环，数据仍然是单点写入主机房进行数据存储，然后实时同步复制到同城备份机房。 当A机房出现问题时，运维人员只需通过GSLB或其他方案手动改变路由模式，将流量路由到b机房 同城双活可以有效防止因火灾、建筑破坏、供电故障、计算机系统、人为破坏等造成的机房灾难。 1.服务路由zk集群:每个机房配备一个zk集群，机房之间的zk数据实时同步，每个机房都有所有机房注册的zk数据；路由方案:条件路由>:最近路由>:跨房间路由，尽量避免跨房间呼叫；订阅方案:消费者订阅所有机房服务，提供商只向本机房zk集群注册。 2.数据主动MySQL:采用MHA部署方案，主从半同步方案保证数据一致性。 读写分离，读路由到机房最近的数据节点，写路由到主节点所在的机房；Redis:Redis集群模式是主从同步，最近的读写路由是到主节点机房。 利用原生主从同步进行跨机房写入，性能较低，但也可以依靠CRDT理论构造多节点双向同步，实现机房附近的读写，但整体实现较为复杂。 3.同城双城方案评估1)优势服务，同城双活，同城数据容灾，同城跨机房容灾不丢失数据；架构比较简单，核心是处理底层数据。由于两个机房距离近，通信质量好，底层存储如MySQL可以同步复制，有效保证了两个机房的数据一致性。 2)存在写劣质数据库数据的跨机房调用，复杂服务和链路下频繁的跨机房调用增加响应时间，影响系统性能和客户体验；保证同城区域的容灾能力，当服务所在城市或局部地区全网故障或不可抗拒的自然灾害发生时，存在服务中断和数据丢失的风险。 对于核心金融业务，至少需要具备跨区域的灾备能力；如果服务规模足够大(例如，单个应用程序超过10，000台机器)，链接到一个主数据库实例的所有机器将导致连接不足。 3.两地三中心结构。所谓两地三中心架构，是指同城双中心+异地灾备中心。 异地容灾中心是指异地建立备份容灾中心，用于双中心的数据备份。数据和服务通常是冷的。当双中心所在城市或地区出现异常，无法对外提供服务时，远程容灾中心可以使用备份数据进行业务恢复。 二三中心方案评价:1)优势服务，同城双活，同城数据容灾，跨机房级容灾，同城不丢失数据；架构比较简单，核心是处理底层数据。由于两个机房距离近，通信质量好，底层存储如MySQL可以同步复制，有效保证了两个机房的数据一致性。容灾中心可以防止同一个城市的双中心同时出现故障，利用备份数据进行业务恢复。 2)存在写劣质数据库数据的跨机房调用，复杂服务和链路下频繁的跨机房调用增加响应时间，影响系统性能和客户体验；服务规模足够大(比如单个应用超过10000台机器)，所有机器都链接到一个主数据库实例，会造成连接不充分；如果出了问题，我不敢轻易切断远程数据备份中心的流量。远程备份数据中心很冷，通常没有流量进来。所以，如果出了问题，验证远程容灾室需要很长时间。 同城双活、两地三中心建设复杂度不高。相对于同城双活，两地双活、三地三中心可以有效应对异地数据容灾问题，但仍然无法应对同城双活的诸多缺点。为了处理这两种架构的缺点，应该引入更复杂的解决方案来处理这些问题。 四。异地多活异地多活是指分布在不同地方的多个站点同时对外提供服务的业务场景。 多活是一种高可用的架构设计，与传统容灾设计的主要区别是“多活”，即所有站点同时对外提供服务。 1.异地多活挑战。要搬到异地，首先要面对的就是物理距离带来的延迟。 如果一个应用请求需要在不同的地方修改多个单元中的同一行记录，那么要满足不同单元之间数据库数据的一致性和完整性就要花费大量的时间。在处理异地高延迟时，需要封闭地读写单元格中的数据，不同的单元格不可能修改同一行数据，所以我们需要找一个维度来划分单元格。对单元中其他单元数据的访问需要被正确地路由到相应的单元。比如客户A给客户B转账，客户A和客户B的数据不在同一个单元，客户B的操作可以路由到对应的单元；面对数据同步的挑战，所有封闭单元的数据都需要同步到相应的单元。对于读写分离的类型，我们需要将中心数据与单元同步。 2.Unitization所谓的unit(下面我们用RZone代替)是指一个能够完成所有业务操作的自成一体的集合。该集合包含所有业务所需的所有服务以及分配给该单元的数据。 模块化架构是以单元为系统部署的基本单位，在全站所有机房部署若干单元。每个机房的单元数量是不确定的，任何一个单元都配备了系统所需的所有应用。 在单元化架构下，服务仍然是分层的，但不同的是每层中的任何节点都只属于一个单元。上层调用下层时，只会选择本单元的节点。 流量细分选择什么维度，要从业务本身分析。 比如电商业务和金融业务，最重要的流程是下单、支付和交易。拆分客户id的数据是最好的选择，买家的相关操作会在买家所在的单位完成。 与业务相关的操作不能单元化，需要按照下面详述的非单元化模式进行部署。 当然，客户运营业务也不能完全避免跨单位甚至跨机房呼叫。比如两个买家A和B转账，A和B的数据单位不一致，B的操作需要跨单位完成。稍后，我们将详细讨论跨单元呼叫服务的路由问题。 3.不统一的应用程序和数据。对于不能单元化的服务和应用，有两种可能:对延迟不敏感但对数据一致性敏感，这类应用只能部署在同一城市。 当其他应用调用这类应用时，会有跨区域调用的可能，所以我们在可以容忍延迟的情况下，将这类应用称为MZone应用。它对数据呼叫延迟很敏感，但可以容忍短时间内的数据不一致。这种应用和数据可以在一个机房里保存满满的数据量，机房之间以增量的方式实时同步。这类应用暂称为QZone。 除了两个以上的非单位应用，我们的机房部署可能是这样的:每个机房有两个r zone，MZone在两个地方保持类似的三中心部署模式。在不同机房调用MZone服务，需要跨区域、跨机房调用。 QZone的每个机房都保存着一份完整的数据，机房之间通过数据链实时同步。 4.请求路由1)API门户网关为了保证客户的请求能够正确进入自己的单元，每个机房都会部署一个流量门户网关集群。 当客户请求到达机房时，它首先进入流量网关。流量网关可以感知全局流量分片，计算出客户所在的流量单元，并将流量转发到相应的单元，从而将客户请求路由到相应的单元。 GateWayr转发可以确定客户端单元，将客户端流量路由到正确的位置，但是HTTP转发也会造成一定的性能损失。 为了减少HTTP流量的转发量，当客户请求返回时，可以将客户的路由标识信息添加到cookie中。 客户下次提出请求时，可以提前获取路由标识，直接向相应的单元请求，可以大大减少HTTP流量的转发。 2)虽然服务路由的应用已经单元化，但是跨单元调用是无法避免的。比如客户A转账给客户B，如果客户A和客户B在不同的单位，客户B的操作需要跨单位调用。此时，请求需要被路由到客户B的数据所在的单元。 RPC、MQ、DB等。中间件需要提供路由能力，以便在多活的情况下将请求正确地路由到相应的单元。 下面以RPC路由为例说明远程激活下的中间件如何路由，同样的方法也适用于其他中间件(数据库中间件、缓存中间件、消息中间件等)。). 公共接口ManualInterventionFacade { @ zone route(zone type = zone type。RZone，uid class = uid parse class . class)manual recommendersponse getmanualrecommendecommodity(manualrecommenderequest请求)；}以上是多活动下RPC接口的定义方法。有必要指出RPC类型。如果是RZone服务，需要提供uid解析方法。 下图是RPC注册中心的路由寻址过程，肯定和同城主动服务不一样。 5.数据同步QZone型数据:这类数据只要保证最终的一致性，对短期的不一致没有影响，但是对延迟非常敏感，比如少量的算法、风控、配置数据。 这种数据基本上就是每个机房部署一套QZone，然后机房之间互相同步。 MZone数据:这类数据对一致性非常敏感，不能不一致。只能部署在同一个城市，业务需要能够容忍异地的通话延迟。 RZone数据:这种数据的每个区域都有自己的主节点。如果数据不在该单元中，则需要路由到相应的节点进行写入。 这类数据的部署如下:6 .方案评价:1)超强容灾能力大幅提升，异地服务更主动，异地数据更主动；理论上系统服务可以横向扩展，异地多机房的突破大大提高了整体容量，理论上不会有性能上的担忧；将客户流量划分到多个机房和区域可以有效减少机房和区域的故障范围。 2)劣势架构非常复杂，部署和运维成本非常高，需要对公司多方面依赖的中间件和存储进行改造；对业务系统肯定是侵入性的，因为单元化影响服务调用或者用户写的数据到相应单元的路由，业务系统需要设置路由标识(比如UID)；不可能完全避免跨单位、跨地区的呼叫业务，比如上述转账业务。 我们应该做的是尽量避免跨区域的服务电话。 5.摘要本文论述了建设少量活动的总体思路和少量关键技术点的处理方案，并对各种方案进行了比较。 要在异地建立一个完整的多活动能力，远比上面讨论的复杂，需要对各种依赖的中间件、存储等进行相应的单元化改造。以及完整的流量调度和运维管控能力。 由于篇幅所限，本文没有详细介绍各种存储系统(如Redis和MySQL)的数据同步复制和高可用方案，有兴趣的同学可以深入了解一下这些知识。 作者官网商城开发团队来源vivo互联网科技(ID: vivovmic)