关于架构设计:OPPO互联网业务多活架构演进和实践

OPPO 是如何保障互联网业务的高可用？多活架构如何落地，如何依据业务需要继续演进？针对简单的零碎，如何提供牢靠的监控计划？……

OPPO 尽管是一家手机公司，然而其互联网业务的规模十分宏大，月活用户数超过 3 亿，既有内容业务、散发业务，也有商业广告、金融等业务。整体上，用户的应用十分高频，来自客户端的申请和数据量十分宏大，并且这几年始终在继续高速倒退。

随着业务复杂度和并发量迅速减少，OPPO 面临的难题是如何保障互联网业务的高可用？多活架构如何落地，如何依据业务需要继续演进？针对简单的零碎，如何提供牢靠的监控计划？…… 带着这些疑难，InfoQ 记者采访了 OPPO 互联网服务零碎后端框架团队负责人罗工。

据悉，他于 2015 年退出 OPPO，有十余年的研发经验，并在高可用架构、PaaS 平台和根底框架研发等方面有丰盛的实践经验。罗工负责 OPPO 后端框架体系建设，包含 API 网关、微服务框架、服务网格等，且经验了 OPPO 从千万级用户到亿级用户的增长历程。

1. OPPO 业务多活的诉求

据罗工介绍，OPPO 业务多活的三个外围诉求是老本、扩大、容灾。

具体说来，老本是指业务总体技术经营老本，包含基础设施的资源老本、研发老本，还包含业务中断的老本、品牌和口碑老本；

扩大是因为业务规模过大，一个服务须要调用数百个三方实例、一个数据库被数百个实例连贯、一个服务须要连贯几十个数据库，架构非常复杂。因而，这就须要对用户进行分片，放大业务规模，天然演进到单元化多活的架构；

容灾，一方面是极其状况下对用户数据可靠性保障的需要，另一方面，因业务过于简单、解决的链路很长，总会呈现一些意外状况，频率还挺高，而问题定位到复原的工夫超过公司 RTO 的要求。机房外部共享运营商线路、DNS、SNAT 防火墙、负载平衡、K8s 集群、注册核心、监控等资源，而机房之间是绝对隔离的环境，同时出问题的概率大幅升高。在业务呈现无奈主动复原的故障时，先切换机房复原业务，而后再从容定位问题根因。

2. 业务多活的两大挑战

OPPO 互联网业务有两大特点：一是业务品种多，没有主线；二是十分高频，申请量大。

先说第一大特点：业务品种多，没有主线，很难制订对立的用户单元划分规定。对平台服务的提供方来说，比方流动、评论、账号、积分、内容中台等，所有机房都须要读写，都需全量的数据。因而，要设计一个 N 主全量数据的架构难度十分大。

以业务中台 – 评论零碎为例，多活架构如下：

• 评论以独立 SDK、独立域名提供服务。防止在业务部署的多个机房的外部调用，否则，评论服务就须要每个机房提供读写服务；
• 记录日志、流水，比方点赞记录、勾销点赞记录，防止批改、计数操作；
• 最终统一。通过订阅的形式更新元数据、缓存，防止双写造成的数据不统一，同时在数据谬误时更容易修复；
• 按用户单元进行调度，用户只会拜访其中一个机房，感知不到两个机房独立更新的元数据的差别。

通过以上措施，把平台业务和产品业务离开，防止机房外部调用。

第二大特点是十分高频，申请量大。罗工示意，“一方面，咱们提供的服务自身就是用户应用频率较高的，另一方面，还有一些常驻服务，比方天气、推送通道、软件自更新、手机云服务等。个别的开源技术计划无奈撑持集群的规模，比方 1000 个实例的 Redis 集群，并且运行的老本过高，自愈能力和可观测性有余等，因而须要自研或深度的掌控。这对技术上的挑战很大。”

以 Redis 为例，如上图所示，后端搭建多个 Redis Group，Proxy 实现 Redis 3.0 Cluster 协定，将一部分 slot 流量分发给 Redis Group，这样 Redis Group 的规模就能失去管制。

基于 RocksDB 研发日志存储系统，对数据进行压缩，性能和老本大大优于 ElasticSearch Lucene 架构。

3. 业务多活架构设计的技术选型

据罗工介绍，多活架构分为接入层、服务层、数据层。

接入层包含 HttpDNS、域名调度零碎、单元划分服务、四层负载平衡、SSL 卸载、API 网关。其中，四层负载平衡基于 DPDK 开发，性能比较简单。SSL 卸载采纳规范的 Nginx，扩大了一些 Prometheus 监控指标。API 网关基于 Netty 网络框架开发，NIO 局部应用了 Netty Native transports，采纳微内核 + 全异步的模型，相比 Zuul/Spring Cloud Gateway 计划有较大的性能劣势。

服务层自身是无状态的，扩大了服务路由、同机房优先、机房级熔断等性能，依据单元号 / 申请染色标记筛选服务提供者实例。

数据层分为同城多活计划、异地多活计划。同城多活即集群跨 AZ 高可用，是一个 CP 的计划。它对于开发者是无感知的，一旦呈现故障就会主动切换自愈。罗工走漏，这里的切换过程没有采纳域名计划，而是批改 SDK 服务发现，以及 Anycast 跨机房路由变更。

异地多活是一个 AP 计划，双向同步，谋求最终一致性。

4. OPPO 互联网业务多活架构的历程

据悉，OPPO 互联网业务品种很多，目前在大量应用同城多活、异地多活的计划。

实际上，OPPO 互联网业务是在近几年疾速倒退起来的，因而一开始就有同城多活、异地多活，并行倒退。

晚期，同城多活、异地多活不足对立方法论，比方按用户单元进行调度（缩小用户感知的不统一、数据同步抵触）、主线多活、保障少数用户、最终统一、数据分类（利用不同的 CAP 模型）、平台业务 SDK 化，后果业务做到了多活，但满足不了 RTO 要求，异常情况不能为大多数用户提供服务，以及下层业务多活，而依赖平台服务须要跨机房调用。

前期，业务多活不只是关注数据层的同步计划，更关注方法论、设计准则的推广，梳理下层业务与平台业务的关系、业务主线、数据分类利用不同的 CAP 模型，以及建设对立的多活决策与观测平台，整个过程更智能化、缩小误判、过滤抖动。

最近几年，OPPO 业务多活的研发重点在于开发人员无感，升高业务多活接入老本。

• 数据层创立数据库 / 中间件集群抉择跨 AZ 高可用、异地同步即可。
• 服务层主动注入相干的环境变量，防止用户配置谬误。
• 接入层打造故障决策的中枢，整合多个监控数据源信息，穿插验证，防止误判，过滤抖动，以及接入层和数据层联动等，实现自动化的接入流量调度。

最大难题

在整个多活业务架构设计中，最大的难题就是没有主线，很难对立单元划分的规定，平台型服务须要在每个机房提供本机房拜访、提供全量数据，没有方法利用单元化的思路去解决。

这里，罗工谈到了三种解决思路。

第一种解决思路：提供 2+2 外围机房本地读写能力，北方抉择 2 个机房做同城多活，南方抉择 2 个机房做同城多活，南北之间双向同步。数据结构设计上，防止应用计数器，防止应用 update，用日志、流水、南北别离订阅 MySQL 重建 ES/Cache/ 计数器、库存南北别离扣减等形式代替，达成数据的最终统一。2+2 之外的机房调用同城的服务。

第二种解决思路：提供本机房的读能力，而写集中到核心机房。

第三种解决思路：下层业务对平台服务的依赖，肯定要做好降级，有应急伎俩，比方账号登录验证，业务能够本人适当的缓存，也能够在 Token 设计时就具备一些不依赖数据层的降级验证能力。

数据同步

数据同步方面。如果 ES、MQ、MongDB 自身提供了多机房数据同步的能力，那无需做太多研发工作。Redis 则能够革新 AOF 为 binlog 模式，从而具备订阅同步的能力。

如果 ES、MQ、MongDB、Redis 作为惟一数据存储，用相干组件本身的同步能力；如果能够从 MySQL 数据源重建，则优先应用 MySQL 的同步机制，在各机房别离订阅 MySQL 重建其余组件的数据。其益处是防止了数据存储双写的一致性问题、数据修复比拟容易。

对 OPPO 而言，它们自研了 Jins 数据同步框架，用来同步 MySQL 等数据库的 binlog，采取下列措施晋升性能：

• 弱小的数据筛选、过滤机制，缩小数据量；
• 一个 MySQL 实例一个数据库，MySQL binlog 是实例级别，库之间会相互影响；
• 事务并行、程序保障，进步指标库写入并发度，这个须要深入研究 InnoDB 的原理；
• 数据压缩、加密、分片传输；
• 拆散 Store 模块和 Relay 模块，即数据传输先落到指标机房的中继日志，而后独立的过程把中继日志写入指标库；
• 多消费者反对，反对同步到多个指标库，缩小数据库的订阅压力；
• 数据传输过程中的一致性保障，数据订阅进去写到本地存储，而后传到指标机房的中继日志，再写入指标库，整个过程须要 2PC 机制保障数据一致性。

通过上述伎俩，南北机房的双向同步比照风行开源软件，在典型场景下根本达到一倍的性能晋升，超过 20000 TPS。

自动化调度

据悉，自动化调度分为多个档次，数据层的主动故障切换和自愈，接入层的机房流量主动调度。罗工介绍，在机房流量主动调度方面，首先须要多维度的监控数据，防止单个数据源数据品质问题造成误判，包含客户端调用链或 APM 的数据、外网拨测平台的数据、机房网络设备监控数据、四层负载平衡监控数据、API 网关监控数据。

数据汇总到多活调度平台（青龙），进行综合决策，避免误判，过滤抖动，输入故障类型指令，以及察看调度的成果。

另一个要害即便是调度执行零碎，须要客户端网络库、HttpDNS、传统 DNS、API 网关深度联动，保障切换过程失效的及时性、失效一致性。

罗工示意，当初，他们外围业务基本上能够实现分钟级实现机房调度，流量 100% 切换到新机房。

目前，他们正在做一些新的尝试，比方调度决策中枢接入更多的数据源，优化算法，晋升故障判断的及时性、准确性，无效过滤抖动，缩小人工的干涉。

他们的同城多活、异地多活以双机房为主，须要 200% 的容量。他们正尝试划分更小单元，逐渐迁徙到三活单元化架构，迫近 150% 容量的现实状况。

在数据层，他们持续推动计算存储拆散，升高正本数，升高数据层多活的老本。并且，Elasticsearch、Redis、MongDB、MySQL 异地同步都收敛到 MySQL 异地同步雷同的传输通道 -Jins。异地两个机房部署齐全独立的集群，缩小机房之间的依赖，晋升数据传输性能、数据安全性。

5. 写在最初

回顾 OPPO 互联网业务的实际历程，罗工认为业务多活架构的胜利与一些因素密切相关。在业务分层和数据分类上，CAP 定理束缚的是数据，不是业务。同一个业务的不同数据能够采纳不同的多活计划，能够共存异地多活、同城多活，重点保障主线性能，保障少数用户。在基础设施层面，尤其是接入层、数据层，要尽量做到对用户通明，升高业务接入的老本。否则，规范、动作不统一，运维治理的老本也很高。

他说：“业务架构设计须要深刻把握基础设施的限度条件，比方 Redis AOF 革新为 binlog 后，局部数据结构不同提供反对，就须要从业务设计上躲避。”