使用高可用性系统体系结构来支持重要系统并为关键业务提供7x24不间断服务已成为许多公司确保业务稳定性和连续运营的主要选择。
服务多活动性是高可用性体系结构的重要实现方法。本文介绍了行业中常用的多种活动方法，例如同一城市的双重活动，两个地方的三个中心以及不同地方的多重活动建筑设计方案，并详细介绍了各种方案的优点。缺点。
一、为什么还要做更多的工作？
随着移动互联网的深入发展，在用户增长达到一定规模之后，许多公司将面临高并发服务和海量数据的挑战。传统的单机房在机器容量方面存在瓶颈。
在某些极端情况下，所有服务器可能会发生故障。例如，计算机机房停电，计算机机房火灾，地震和其他不可抗力因素将导致系统中的所有服务器发生故障，并使整个业务瘫痪。备份，要恢复所有备份业务系统以能够正常提供服务，需要花费很长时间。
为了满足中心业务的连续性并增强抵御风险的能力，Multiactive作为可靠且高度可用的部署体系结构，已成为主要互联网 公司的主要选择。
1、多个现场场景
多活动体系结构的关键点是，位于不同地理位置的所有系统都可以提供业务服务。在此，“实时”是指实时提供服务。对应于“活动”的是“备份”，备份是用于备份。通常情况下，不提供外部服务。如果需要提供服务，则需要大量的手动干预和操作，并且需要很多时间才能获得“备份”。成为“直播”。
从描述的角度来看，多生活非常强大。它可以确保灾难发生时业务不会受到影响。这是否意味着无论从事什么业务，我们都必须实施多生命体系结构？其实不是。为了实现多活动架构，必须付出一定的代价。具体表现为：
因此，尽管Duosheng非常强大，但并非每项业务都必要。例如，如果企业的内部IT系统，管理系统，博客站点等无法承受在不同地方进行的多项活动带来的复杂性和成本，那么他们就不能在不同地方进行多项活动，而对于诸如核心财务，付款和交易。当有必要做更多工作时。
2、多现场直播节目
常见的多活动解决方案包括同一城市中的多个活动程序，两个地方的三个中心，三个地方的五个中心以及不同地方的多个活动。不同的多功能项目的技术要求，建设成本以及运行和维护成本都不同。
下面，我们将逐步介绍这些多个活动程序，并给出每个程序的优缺点。应当结合具体的业务规模，当前的基础设施建设能力和投入产出比等多种因素来确定选择哪种计划。
二、在同一个城市现场直播
同一城市的现场活动人员将在同一城市或相似区域中建立两个计算机房。同一城市的双机房之间的距离相对较近，通讯线路质量良好。更容易实现数据的同步复制，从而确保高度的数据完整性和零数据丢失。
同一城市中的两个计算机房各自承担部分流量。通常，入口流量是完全随机的。内部RPC调用应通过最近的路径在同一计算机房中关闭，这等效于在两个计算机房的镜像中部署两个独立的群集，并且数据仍写入单个点中。然后，将主计算机室数据库实时同步到另一个计算机室。
下图显示了在同一城市中双活动的简单部署体系结构。当然，实际的部署和考虑要比下图复杂得多：
服务调用基本上完成了同一计算机房中的闭环，并且数据仍在单个点写入主机室中的数据存储，然后同步复制到位于同一城市的备用计算机房中。即时的。当计算机机房A发生问题时，运维人员只需手动更改路由方法，即可通过GSLB或其他解决方案将流量路由到计算机机房B。
同一城市的双重活动可以有效地防止火灾，建筑物损坏，电源故障，计算机系统和人为损坏引起的计算机机房灾难。
1、服务路由
2、数据处于活动状态
3、对同一城市的两城市规划的评估
1）优点
2）缺点
三、两地三中心建筑
所谓两地三中心，是指同一城市的两个中心+远程灾难恢复中心。远程灾难恢复中心是指在偏远城市建立备份灾难恢复中心，用于双中心的数据备份。数据和服务通常很冷。当双中心所在的城市或地区异常时，它们将无法提供外部服务。当时，远程灾难恢复中心可以使用备份数据进行业务恢复。
对两个地方的三个中心的评估
1）优点
2）缺点
在同一城市和两个地方的三个中心进行双重活动的建设计划不是很复杂。与同一个城市的三个中心相比，同一个城市的双活动可以有效地解决异地数据灾难恢复的问题，但仍然不能解决同一个城市的双活动的诸多弊端。为了解决这两种体系结构的缺点，必须引入更复杂的解决方案来解决这些问题。
四、在不同的地方生活更多
不同地点的多活动是指在不同地点分布的多个站点同时向外界提供服务的业务场景。在不同地方进行多活动是一种高可用性架构设计。与传统灾难恢复设计的主要区别在于“多活动”，即所有站点都同时提供外部服务。
1、挑战在不同地方生活更多
2、单位化
所谓的单元（我们在下面改用RZone）是指可以完成所有业务操作的独立集合。该集合包含所有企业所需的所有服务以及分配给该部门的数据。
模块化体系结构是将单元用作系统部署的基本单元。整个工作站的所有计算机室中都部署了几个单元。每个计算机机房中的单元数是可变的，任何单元都可以部署系统所需的所有应用程序。在统一架构下，服务仍是分层的。区别在于每一层中的任何节点都属于某个单元，并且仅属于该单元。当上层调用下层时，仅选择单元中的节点。
必须根据业务本身分析为流量细分选择的维度。
对于电子商务和金融服务，最重要的过程是订单下达，付款和交易过程。数据分段和用户ID拆分是最佳选择。买家的相关操作将在您所在的位置完成。
对于与业务相关的操作，它无法统一，因此需要按照以下所述的非统一模式进行部署。当然，用户运营业务不能完全避免跨部门甚至跨计算机机房的呼叫。例如，当两个买方A和B转移业务时，当A和B的数据单元不一致时，B的操作需要跨单元完成。将介绍跨单元呼叫服务路由的问题。
3、非统一的应用程序和数据
对于无法统一的业务和应用程序，有两种可能性：
加上两个或多个非统一的应用程序，我们的计算机房部署可能看起来像这样。每个计算机室都有两个RZone。 MZone维护类似的两站点三中心部署方法。远程计算机室跨区域和计算机室调用MZone服务。转让。 QZone的每个机房维护着一套完整的数据，并且这些机房通过数据链接实时进行实时同步。
4、请求路由
1） API入口网关
为了确保用户请求可以正确输入自己的单元，每个计算机机房将部署一个流量输入网关集群。当用户请求到达计算机房并首先进入流量网关时，流量网关可以感知全局流量碎片，计算用户的流量单位并将流量转发到相应的单位，从而可以路由用户请求到该单元中相应的单元。
使用GateWayr转发方法可以确定订户单元将用户流量路由到正确的位置，但是HTTP转发也会导致一定的性能损失。
为了减少HTTP流量转发的数量，可以在用户请求返回时将用户的路由标识信息带到cookie上。当用户下次发出请求时，他可以预先获得路由标识符并直接请求相应的单元。这种方法可以大大减少HTTP流量转发。
2）服务路由
尽管应用程序已经统一，但是跨单位调用仍然是不可避免的。例如，用户A将钱转移给用户B。如果A和B处于不同的单位，则需要跨单位调用用户B的操作。将请求路由到B用户数据所在的单元。如果在不同地方有多个活动，则中间件（例如RPC，MQ，DB等）需要提供路由功能，以将请求正确地路由到相应的单元。让我们以RPC路由为例来说明中间件如何在不同位置执行路由。其他中间件（数据库中间件，缓存中间件，消息中间件等）也是如此。
上面显示了多实时下的RPC接口定义方法。您需要指出RPC类型。如果它是RZone服务，则必须提供uid解析方法。下图显示了RPC注册中心的路由和寻址过程，该过程与同一城市的过程有所不同。
5、数据同步
QZone类型数据：此类数据仅需要确保最终一致性，并且不会对短期不一致产生影响，但是它具有很大的延迟感，例如某些算法，风险控制，配置和其他数据。这种数据基本上是在每个机房中部署的一组QZone，然后这些机房彼此同步。
MZone数据：这种数据具有高度的一致性，并且必须没有任何不一致之处。它只能使用同一城市的双活部署方法，并且企业需要能够容忍远程呼叫的延迟。
RZone数据：此类数据的每个区域都有其自己的主节点。如果数据不在单元中，则需要将其路由到相应的节点进行写入。此类数据部署如下：
6、项目评估
1）优点
2）缺点
五、摘要
本文讨论了多寿命建筑的一些一般概念和一些关键技术点的解决方案，以及不同解决方案的比较。建立完整的远程多活动功能比上面的讨论要复杂得多。必须对其依赖的各种中间件，存储等进行相应的统一转换，并支持完整的流调度以及操作和维护控制功能。
由于篇幅所限，本文不会详细介绍各种存储（例如Redis，MySQL）的数据同步和复制以及在多个活动下的高可用性解决方案。有兴趣的学生可以去学习更多有关此知识的信息。