亿级并发，API网关等核心组件，如何设计？

发布时间：2023年12月26日

说在前面

在40岁老架构师 尼恩的读者交流群(50+)中，很多小伙伴拿到一线互联网企业如阿里、网易、有赞、希音、百度、滴滴的面试资格。

最近，尼恩指导一个小伙伴简历，写了一个《高并发网关项目》作为简历黄金项目，帮这个小伙拿到 字节/阿里/微博/汽车之家 面邀，并且成功拿到大厂offer。

所以说，《高并发网关项目》是一个牛逼的项目。为了帮助大家拿到更多面试机会，拿到更多大厂offer。尼恩专门出了一章视频，介绍这个项目的架构和实操——《33章：10Wqps 高并发 Netty网关架构与实操》，结合视频，再结合一对一的简历指导，让大家的简历金光闪闪、脱胎换骨。

《33章：10Wqps 高并发 Netty网关架构与实操》 目录如下：

配合《33章：10Wqps 高并发 Netty网关架构与实操》， 尼恩会梳理几个工业级、生产级网关案例，作为架构素材、设计的素材。

前面，已经梳理了下面的经典案例：

除了以上的10个案例，这里，尼恩又找到一个漂亮的生产级案例：《亿级并发，API网关等核心组件，如何设计？》。

这些案例，并不是尼恩的原创。仅仅是尼恩在《33章：10Wqps 高并发 Netty网关架构与实操》学习材料中，供大家学习和交流使用。

《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】获取

文章目录

蚂蚁金服面对亿级并发场景的组件体系设计

作者：吕丹，蚂蚁金服技术专家

本文内容可以分为四大块，第一块是标准移动研发所需的基础服务体系，第二块是支撑亿级并发的核心组件“移动接入”的架构演进过程，第三块是双十一、双十二、新春红包这种大促活动的的应付方法，最后一块是目前已经对外输出的基础服务产品。

移动研发基础服务体系

首先介绍一下支付宝客户端的演进过程。

之前，支付宝客户端的主要功能是转账、订单支付、交易查询等等，它更像是一个专门为支付而设计的工具 APP，用户在需要支付时才会使用，支付完成后便不再打开。

然而，2013 年，蚂蚁金服 all in 无线之后，加入了很多服务，例如余额宝、卡券、探索发现等，几乎将支付宝网站的所有功能都转移到了移动端，支付宝也逐渐演化成一个平台级别的客户端。

之后，随着移动互联网的快速发展，公司内部孵化出了更多的 APP，其他行业也在移动互联网圈内铺开了大量的业务，为了提升用户量、用户粘性，APP 之间也开始进行了大量的业务融合，超级 APP 也因此而诞生，APP 开始朝着生态化的模式发展。

至今，支付宝客户端的年活跃用户数已超过8亿，在大促销活动期间，同时在线用户数超过3亿，并发请求超过1亿，每秒同时上线用户数超过百万。

这些数据背后，必然需要一套庞大、复杂、完整的支持系统来保障支付宝的顺畅运行，而移动研发基础服务体系便是这一体系的重要组成部分。

在研发过程中，我们将移动研发基础服务体系划分为四个主要部分：

  • 在APP研发阶段，主要包括应用框架、基础组件、云端服务和研发工具；
  • 在APP测试阶段，主要包括研发协作平台和真机测试平台，研发协作平台涵盖版本管理、迭代管理、安装包编译、构建和打包等功能，而真机测试则旨在替代人工服务，减少人力成本，提高测试效率；
  • 在APP运维阶段，主要包括智能发布、日志回溯、应急管理和动态配置；
  • 在APP运营阶段，主要包括舆情反馈、实时分析、离线计算和智能营销。

支付宝客户端的发展不仅体现在功能的丰富和用户基数的增长，更在于其背后支撑体系的日益完善和智能化。

从单一的工具应用成长为集多种服务于一体的平台，支付宝客户端的演进映射了整个移动应用生态的发展趋势，即通过不断的创新和整合，提升用户体验，满足用户多样化的需求。

蚂蚁移动接入架构演进

今天的主题为支撑亿级并发下的基础服务，而在亿级并发下移动接入又是最核心、最重要的一个环节。

移动接入并不是单个系统，而是一整套组件的总称，包括：Spanner+ 连接管理、API网关、PUSH通知和SYNC数据同步等。

这些组件共同构成了移动业务流量的主要通道，不仅要保持客户端的状态，还需实现集中管理和部分业务数据处理。

起初，并不存在“移动接入”这一概念，它的形成与发展与支付宝客户端的历程相似，都是通过不断的迭代和改进逐步完善的。

最初阶段，各个业务单元各自提供API或直接向客户端展示能力，缺乏统一的架构、模型和管控机制。

为了应对这一挑战，在 all in 阶段我们引申出了一个 API 网关，以实现集中管理，并且增加了PUSH推送功能。

由于公司拥有众多APP，我们期望这些功能能够被复用，因此架构设计上支持多APP同构，同时为客户端提供了多个SDK，以便随时进行集成。

蚂蚁移动接入架构的演进是一个从分散到集中，从单一到多元的过程，旨在提高服务效率和用户互动体验，确保在亿级并发的挑战下，移动服务依然能够稳定运行，满足用户需求。

网关架构

上图是一个移动 API 网关的架构，从图中可以看到，我们把 API 生命周期定义为以下几个阶段：API 定义、API 研发、API 发布、API 配置、API 上线、API 运营和 API 下线。

而移动网关又把 API 生命周期切分成三大块，分别是研发支撑阶段、运行时阶段和服务治理阶段。

研发支撑阶段主要有四个能力，分别为 Code-Gen（代码生成）、API-MAN（API管理）、API-Test（API测试） 和 API-Mock（API模拟）。

为了提高 API 数据在网络上的传输效率，目前蚂蚁的 API 模型全部都采用了 protobuf 进行序列化，因此，为了方便业务开发，API 网关提供了统一的基于 proto 文件的代码生成工具，并且为了减少客户端的文件大小和方法数限制，我们修改了官方提供的生成代码，有效减少了冗余的方法并大大减小了客户端文件大小。

在运行时阶段，核心的功能包括 API 流量管控、数据验签、用户鉴权以及接口系统路由等。

API 日常的运维由服务治理体系负责，主要的能力为 API 监控，并根据实时数据进行 API 质量模型评估，并提供了一些应急管理措施。

API 网关最为核心的架构设计是 Pipeline，尽管网关在表面上只是一个简单的API管控和路由系统，但它涉及众多节点，而每个节点的功能又相互独立，并且随着业务的发展，功能节点会逐渐增加，在某些场景下，还需要做不同的节点组合。

如果使用传统的链式调用，代码执行串会非常的长，同时扩展和维护起来都非常的困难。

因此我们参考了 netty 的 Pipeline 设计，完成了自己的 Pipeline 链路。

Pipeline 中的各个 handler 保持相互独立，同时可以根据需要和配置自由组合，这为后续功能扩展提供了良好的架构支持。

蚂蚁金服的API网关架构通过精细化的阶段划分和灵活的Pipeline设计，确保了API生命周期的有效管理和服务的高效运行。

这种架构不仅提高了API的开发和运维效率，还通过优化代码生成和序列化过程，减少了客户端的负担，从而提升了整体的性能和用户体验。

随着业务的发展和技术的进步，这种架构设计能够适应不断变化的需求，为蚂蚁金服乃至整个移动应用生态提供了坚实的基础。

代码变革

从代码来看，我们可以明显感受到调用过程的变化。原先，它是一个远程调用，需要处理路径、参数等问题。但在统一数据交互后，对于业务系统而言，这个调用过程更接近于本地调用，直接调用函数并封装模型。这种方式使得业务研发人员可以更专注于业务逻辑的编写，而无需关注底层的通信实现，从而显著提高了研发效率。

移动网络与有线网络存在显著差异。移动网络环境复杂，用户状态多变，可能处于地下室、电梯或其它网络信号弱的环境中。

在移动场景下，用户对体验的要求极高，例如在支付时，用户期望立即获得支付结果。

过去，我们主要对服务端进行了改进，而对客户端的改进有限。

了解决用户问题、性能问题并提升用户体验，我们进行了一次升级，构建了一个统一接入网关，并将其置于基础组件之上。同时，我们研发了性能数据同步和增强了IP调度等能力。

代码变革的核心在于将远程调用转换为更高效的本地调用，这样不仅简化了业务逻辑的实现，也提升了研发效率。通过构建统一接入网关和增强的基础组件，我们能够更好地应对移动网络环境的复杂性，满足用户对高性能体验的需求。

这种变革不仅优化了服务端的性能，也改善了客户端的体验，为用户提供了一种更加稳定和快速的支付方式，进一步巩固了移动支付在现代社会中的地位。

统一接入网关

统一接入网关（ACCGW）可以被看作是一个前置的Nginx，它是蚂蚁基于Nginx进行二次开发的一套组件，内部称之为Spanner。

它在接入架构中主要负责非业务逻辑的处理，包括SSL的卸载、MMTP协议的解析、数据的压缩与解压缩、客户端TCP长连接的维持、接入流量的总控、数据包的路由以及客户端日志的接入等功能。

API网关、PUSH推送、数据同步等组件都在它的支持下运作。

网络协议优化

MMTP 协议的全称是蚂蚁移动传输协议，基于 TLV 的数据结构，这种数据结构的好处是分包解包的效率非常高，且它是基于二进制的，存储成本相对较低。同时还满足了客户端多个组件的链路复用，当然 MMTP 配合客户端也有自己的一些特性，同时我们也加入了很多新特性，例如智能连接策略。

因为移动环境下用户的网络状态不是很可靠，如果是传统的连接方式，不一定能满足所有 RPC 请求，所以我们做了策略改进。

在能够使用长连接的情况下尽量使用长连接，如果出现长连接连不上或者闪断的情况，我们就尝试使用短连接的方式，短连接可以满足当时紧急的 RPC 发数据。

同时我们还会使用一些并发建连的策略，如先连接哪个运营商的网络就使用哪个，连接后我们会使用智能心跳策略，以适应不同运营商、不同地区维持连接的心跳时间差异。

在并发建连过程中，客户端可能同时存在多个长连接，数据包可能在传输过程中丢失，因此我们加入了柔性断连，确保正在传输的数据包能安全送达。

另外，多个连接建立后，客户端可能出现问题，服务端无法及时感知连接状态，因此我们加入了假连接监测。

数据包派发时携带序列号，客户端回报后，如果序列号返回，证明连接可用；否则，认为连接是假死状态，可在合适的时间点断开连接。

MTLS 是蚂蚁移动安全传输协议，基于 TLS1.3。我们在做的时候，TLS1.3 还没有正式发布，但是我们了解到一些它的特性，并将某些特性加入到了设计中。比如采用了 1RTT ECDHE 的握手方式。1RTT ECDHE 是基于 ECC 加密套件，ECC 的最大特点是密钥串比较小，更小的数据在移动方面有非常大的优势，例如提升传输效率，节省存储成本。在存储或传输过程中，数据包大小是移动领域特别关注的点。

也因为如此，我们选择了 ZSTD 压缩算法，ZSTD 有非常大的压缩比，且在该压缩比之下，压缩和解压缩的效率都不错。另外，在某些可支持重放的业务场景中，我们还加入了 0RTT 策略，第一时间把数据从客户端发送到服务端。通过上述优化，RPC 的平均响应效率提升了 5~6 倍。

蚂蚁金服通过统一接入网关和一系列网络协议优化，显著提升了移动环境下数据传输的效率和安全性能。这些优化不仅提高了数据传输的速度和响应时间，还确保了数据在复杂网络环境中的稳定性和可靠性。通过智能连接策略、柔性断连、假连接监测等技术手段，蚂蚁金服为移动应用提供了一种高效、安全的数据传输解决方案，进一步巩固了其在金融科技领域的领导地位。

SYNC 数据同步

SYNC 数据同步听起来有点陌生，但实际上可以看作是 PUSH 的演进版本。

它是基于 TCP、双向传输的。尽管传统的 RPC 调用能够解决大部分问题，但在某些特定场景下，它仍存在缺陷。例如，客户端启动之后，需要通过 RPC 请求来检测服务端是否有新的数据。其实 90% 的情况是查询接口没有任何的变化或者返回的数据客户端已经存在了，所以这个过程非常冗余。不仅数据查询冗余，请求本身也是冗余的，因为没有变化发生，这些调用其实是可以避免的。

当初，在 all in 之后，我们对用户体验进行了一些优化，比如实现了预加载功能。当客户端启动时，会触发数据的预加载，尽管这时客户端还没有进入相关模块，但为了提升用户体验，客户端会发送大量 RPC 请求，这导致了大量的冗余并发请求。

另一个问题是客户端无法主动感知服务端数据的变化。

例如，在聊天应用场景中，用户是等待交互的，如果使用 RPC 定时拉取的方式，客户端和服务端的成本会很高，整体响应时间也会变慢。

而通过 SYNC 的推送模式，服务端在产生新数据时，可以直接通过 TCP 将数据推送到客户端，客户端可以立即接收到数据并进行业务处理，比如支付宝的扫码支付、当面付等功能都是通过 SYNC 服务来同步结果数据的。

SYNC 的核心机制是 oplog，它类似于 MySQL 的 binlog，是对每条增量数据的快照。

SYNC 会为每条 oplog 生成一个唯一且递增的版本号，并通过记录客户端当前数据版本号来计算两端之间的差异，只同步这些差异数据。由于 SYNC 基于TCP，可以实现双向主动传输，从而实现实时、有序、可靠、增量的数据传输。

同时，SYNC 在客户端触发场景时，并不是基于业务场景，而是基于事件，如建立连接、登录、从后台切换到前台等操作，因此，它可以实现单次事件触发多个业务的增量计算。

当没有增量数据时，客户端无需进行任何 RPC 请求，从而大幅减少请求次数和冗余数据传输，不仅提高了效率和实时性，也间接减轻了系统的压力。

SYNC 数据同步通过优化传统 RPC 调用的局限性，提供了一种高效、实时的数据传输解决方案。

它通过 oplog 机制和 TCP 双向传输，实现了数据的增量同步和主动推送，显著提升了用户体验，并减轻了系统的负担。

SYNC 的应用场景广泛，特别是在需要快速响应和数据实时更新的金融支付领域，如支付宝的扫码支付等功能，都得益于 SYNC 服务的高效数据同步能力。

移动调度中心

对于客户端请求而言，最重要的是在第一时间内找到正确的 IP 并把请求发出去。

之前这些工作一般是由传统 DNS 来做，但传统 DNS 会有一些问题，例如 DNS 劫持、DNS 解析失败、不同运营商 DNS 解析效率不同等等，解析 DNS 需要消耗额外的 RTT。

为了解决这些问题，我们设立了移动调度中心，它是基于 HTTPDNS，并在此基础上加入了用户分区信息。什么叫用户分区呢？

面对亿级并发，服务端肯定不会在一个机房里，可能是在多个机房中，且机房内部还有逻辑分区。

只有服务端知道用户属于哪个逻辑区，客户端本身无法感知。

当某个分区的用户接入进来后，如果没有在正确的分区内，且又需要转到其它分区做业务处理时，如果是采用传统 DNS 是无法实现的，因为无法解析出用户属于哪个 IP 列表。

而 HTTPDNS+ 分区数据的模型，可以让客户端快速拿到最准确的 IP 地址，同时客户端还可以针对这个 IP 地址做质量检测和有效性检测，在请求之前就确定最优的 IP 地址。

另外，HTTPDNS 还可以支持海外节点的部署。HTTPDNS 一定不会比 DNS 的效果差，因为它还有 DNS 来兜底，一旦 HTTPDNS 出现问题，那么就会切换到 DNS 去做解析。

以上的演进过程满足了绝大多数日常的需求，但是支付宝有很多大促场景，每次大促的玩法都不同，且峰值集中在一刹那。

针对这个场景，我们又孵化出了新的模式，一是 API 网关的去中心化，二是 SYNC-PULL 机制，三是 SYNC-Bucket 计算模式。

移动调度中心通过结合 HTTPDNS 和用户分区信息，提高了客户端请求的效率和准确性。它不仅优化了 DNS 解析的可靠性，还支持海外节点的灵活部署。

此外，针对支付宝特定的大促场景，我们采用了创新的去中心化 API 网关、SYNC-PULL 机制和 SYNC-Bucket 计算模式，以应对突发的高流量和复杂的业务需求。

这些技术的应用，确保了支付宝在大规模活动中能够提供稳定、高效的服务，满足了用户在关键时刻的支付体验。

网关去中心化

网关去中心化解决的一个核心问题就是成本。大促场景下，业务量不停上升，峰值可能非常高。但峰值只有一刹那，而在其余时间，服务器资源往往处于闲置状态，这无疑是一种巨大的资源浪费。而为了保证大促时不崩溃，机器又不能减少，所以对应用的压力是非常大的。

如果都是做单点，那么还会存在稳定性的问题。例如，如果在网关发布时出现错误，可能会影响到所有业务流程。此外，如果某个接口出现问题，可能会导致客户端陷入死循环，进而影响其他系统业务的正常进行。为了应对这些风险，我们采用了网关去中心化的策略就可以抵消这些风险，如果只是单个系统出问题，那么不会因为网络的问题导致其他业务发生问题。

网关去中心化通过分散风险和优化资源利用，有效解决了大型促销活动中面临的成本和稳定性问题。它确保了即使在极端的业务高峰期间，系统也能保持稳定运行，同时减少了资源浪费。通过这种方式，我们能够提供更加可靠和高效的服务，保障用户在关键时刻的顺畅体验。

SYNC-PULL 读扩散

为什么会有 SYNC-PULL 读扩散的需求呢？

在支付宝内部，有许多高价值商户，他们各自拥有庞大的粉丝群体，需要定期或不定期地发布运营消息。

如果采用 SYNC 的写扩散方式，为每个粉丝发送一条数据，不仅会浪费存储资源，而且效率低下。假设某个商户有 5 亿关注用户，5 亿数据全部入库最快也要几十分钟。

此外，由于商户众多，大家都争夺同一资源，可能导致排队现象。对于商户来说，无法立即将活动信息触达用户，而对于服务端来说，存储了大量重复的消息，造成了资源的浪费。即使使用了缓存，每个用户的数据索引仍需存储，这对数据每秒处理量（TPS）的要求极高。

为了解决这些问题，我们采用了读扩散模式，将其抽象为关注关系，每个商户成为一个主题（Topic），所有数据存储在对应的 Topic 下。

由于用户关注的大 V 数量相对较少，且大 V 发布数据的频率不高，有效数据集并不多，因此可以将超级大 V 的数据首先存储在缓存中，然后通过二叉索引快速定位用户关注关系，并通过现有的 SYNC 机制将增量数据推送到客户端。

这样，原本亿级的数据存储需求降低为一条存储，响应时间也从分钟级缩短到秒级，大幅提升了效率和用户体验。

最初，我们在实施 SYNC 时，希望每个业务都能相对独立和隔离，计算也是独立的。

当时业务场景不多，但随着越来越多的业务接入，达到了 80 个独立业务场景，每个业务都需要独立计算。由于客户端基于事件驱动，建立连接后需要进行 80 次独立业务计算，在大促活动每秒百万次请求的情况下，很容易达到亿级，这对数据库、应用程序和缓存的压力极大，同时这种方式也无法满足未来的持续发展需求。

为了解决这些问题，我们针对原来的计算特性抽象出了几个分类。

例如，基于用户维度、基于设备维度、基于一次性、基于多端同步、基于全局用户配置的几个大类数据，抽象成几个抽象模型。

我们姑且认为是有 5 个 bucket，所有的计算都基于 bucket 方式来做，如果有新的业务加入，那就根据它的特性把它归到某个 bucket 中。

另外，大促场景下会有高优先级的业务，所以需要做一些特定的限流策略。

针对这种情况，bucket 可以动态的增减，业务进出 bucket 也可以随时切换。

bucket 上线之后，当时我们的计算量下降超过了 80%，在后面的 2、3 年中，业务从 80 个增加到 300 个，服务器也没有增加。整体来说，对性能的提升还是非常明显的。

大促活动场景应对之道

前面的内容主要是移动接入方面的组件设计如何支撑亿级场景，下面我们聊一下，如何切实的应对大促活动。

应对大促的几个步法

通过几年的大促经验，我们在技术上提炼出了应对大促的几个步法：

首先业务同学设定业务目标，确定业务玩法；技术同学在收到大促介绍之后，开始分解技术指标，并根据各自系统的能力、流程和特性确定相应的技术方案，确定技术方案的步骤则主要为：链路分析、容量评估、性能优化、流控方案、预案策略以及确定弹性流量规则。

在确定完成技术应对方案后，最重要的是进行全链路的压测，通过影子用户，影子表进行生产环境的全链路压测，每个系统压测周期短则几天，长则需要数月。

在不断的压测中发现问题，发现瓶颈，优化后再次进行压测，直到完成技术目标；在全链路完成压测指标后，进行多轮活动的演练，以模拟真实业务场景，并验证技术方案的准确性；

此后，根据实际需要，择时进入大促阶段。

在这个阶段，研发同学主要工作是配合运维进行预案的执行、观察大促期间各种指标的变化，并根据监控确认是否需要应急。

当然，应急方案在之前的演练中也需要进行验证。

随后大促活动结束后，需要进行预案 & 应急策略的回滚和验证，这样大促活动才算真正结束。

同时，更重要的是，我们需要对每年的大促进行复盘 review，以便发现不足，在后续的活动中加以改进。

大促活动场景应对之道——流控

在大促执行过程中，最为关键的是流控。

对技术同学来说，让系统在活动中活下来是对大促最给力的支持，流控是系统最有力的屏障。

由于各系统在大促活动中发挥的作用、业务的紧急程度和集群规模各不相同，因此在促销活动中通常会牺牲一些特性来为主干链路释放性能，例如流水日志、压缩阈值、消息顺序等。

流量的管控也会分多级，在最上层 LVS 会在 VIP 上进行数十亿级别的流量控制，接入网关层则会根据连接数和包数进行亿级流量控制，而API网关层则进行千万级别的控制。

在这些层次上，通常简单的计数就可以满足需求。

然而，在业务层，特别是中低流量的业务层，通常采用令牌桶和分布式限流方法。此外，在API网关上，还可以执行一些自定义脚本，模拟返回结果，以帮助业务系统抵御一部分请求。

流量控制在大型促销活动中扮演着守护者的角色，通过精细化的分层管理，确保了系统的稳定性和业务的连续性。从高层到低层，从简单的计数到复杂的分布式限流，每一步都是为了让用户体验更加流畅，让促销活动能够顺利进行。

通过这些措施，我们不仅提高了系统的抗压能力，也保证了促销活动的效果，实现了技术和业务的双赢。

自动化真机测试

除了核心链路之外，我们还需要一系列的后勤支持服务。例如，在测试阶段，我们依赖于自动化，尤其是真实的设备模拟测试，以减轻人工测试的工作量。

在我们的数据中心，部署了数以千计的智能手机，它们通常用于执行自动化的运维检查，包括应用的安装与卸载、性能消耗评估、功能验证等。

自动化测试不仅减少了重复的体力劳动，还起到了自动审核和服务监控的作用，用于检查小程序并及时发现潜在问题。利用自动化测试平台，我们能够节省超过60%的重复性人力成本。

勤服务的自动化不仅提高了测试效率，还增强了服务的可靠性和响应速度，为保障促销活动的顺利进行提供了坚实的后勤保障。通过这种自动化的方式，我们能够更好地利用资源，提高效率，同时确保了服务的高质量。

客户端智能发布——确保客户端万无一失

如果要确保客户端万无一失，那么最核心的就是灰度流程，灰度流程结束之后，我们才能发布到生产环境中。

智能发布系统主要支持客户端的各种发布包，包括安装包、离线包、小程序包等。

经过多年的发布经验积累，我们已经形成了一些标准模板，例如灰度用户、灰度覆盖率等。在灰度测试阶段，我们可以根据需要选择合适的模板，并依照既定逻辑，利用自动化流程来替代人工操作。

舆情分析——及时获取用户反馈

客户端发布之后，业务同学一定非常关注用户的意见和市场的反馈，技术同学则希望第一时间收集到用户的真实反馈。

为了满足这些需求，我们引入了舆情分析系统求，舆情系统可以分为 4大 大块：数据采集（主要采集渠道为各大媒体中心）、应用市场评论、开会的反馈功能和客户满意中心的数据；数据内容则可以包含各种热点话题、热点事件和主要生产问题；

数据存储，目前主要由 4 大块来支撑：元数据一般可以采用关系型数据库，文档数据使用的是 MongoDB，爬虫采集的条目通过 MQ 来传输，所有数据最终会落至 ES 中，用来做检索和基础分析；

数据计算更多的是通过文件算法来对 ES 中的数据进行分析，最终产出各种趋势和各种事件、话题排行，同时针对每一个用户反馈又可以实时通知到相关的负责人。

在这里我们说的移动分析主要是基于客户端日志埋点的数据分析能力。

客户端需要有标准的埋点 SDK 来采集 Native、H5、小程序的各种框架 & 容器埋点，也需要支持业务自定义的业务埋点。

同时，为了在大促场景能有效的提升服务端性能，埋点的写入与上报也需要有一些措施来进行动态的控制，埋点在客户端完成后，在合适的时机就会上报给服务端的移动日志网关，（移动日志网关目前也已经逐步被纳入到移动接入中进来）。

当客户端日志上报到服务端之后，即可由日志网关输出到服务端日志文件或投递至消息组件，供其他的平台进行消费计算，这包括如 Jstorm、kepler、Flink 这样实时计算平台，也可以投递到 Spark、odps 等离线大数据计算平台来进行进一步分析。

作为基础组件，移动分析除了日志采集和同步之外，也进行了一些框架输出日志的基本数据分析，行为分析（像日活、新增、流存在）、页面分析（停留时长，参与度）、闪退分析、卡顿分析，并提供了日志回溯和日志拉取等能力供研发同学进行问题排查和分析。

当然，这些数据可以用于各种业务分析，分析的形式完全取决于业务方想如何使用。

无论是舆情分析系统还是移动分析，都旨在通过数据的采集、存储、计算和分析，为业务和技术团队提供用户反馈和市场动态的深入了解。

这些系统的设计和实现，不仅要求技术上的精准和高效，更要求对业务需求的深刻理解和灵活应对。

通过这些分析，我们可以更好地理解用户行为，优化产品和服务，从而在激烈的市场竞争中保持领先地位。

对外输出的基础服务产品

技术组件产品服务输出：成熟一个，开放一个

经过这几年的努力，我们的基础能力也沉淀了不少可以输出的技术产品。

这些技术产品覆盖了从 APP 研发到测试到运维到运营的各个阶段，有客户端框架、客户端基础组件，有云端基础服务（像 API 网关、SYNC 数据同步、PUSH 通知这些），有开放工具，有插件，有伴随研发测试的研发协作平台来进行迭代管理、编译、构建、打包，真机测试平台，也有 APP 运维阶段所需的智能发布、日志管理、应急管理，还有用于 APP 运营的，各种数据分析和营销投放产品。

这些能力目前已经输出到了蚂蚁国际（印度 paytm、马来西亚、印度尼西亚、菲律宾等）的多个合作伙伴 APP，公有云的上百个企业级 APP，以及私有云的数十家金融 APP。

我们的宗旨是，成熟一个、开放一个，来与合作伙伴共建移动互联网的生态。

说在最后：有问题可以找老架构取经

API网关等核心组件 相关的面试题，是非常常见的面试题。

以上的内容，如果大家能对答如流，如数家珍，基本上 面试官会被你 震惊到、吸引到。

最终，让面试官爱到 “不能自已、口水直流”。offer， 也就来了。

在面试之前，建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》，里边有大量的大厂真题、面试难题、架构难题。很多小伙伴刷完后， 吊打面试官， 大厂横着走。

在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。

另外，如果没有面试机会，可以找尼恩来帮扶、领路。

尼恩指导了大量的小伙伴上岸，前段时间，刚指导一个40岁+就业困难小伙伴，拿到了一个年薪100W的offer。

尼恩技术圣经系列PDF

……完整版尼恩技术圣经PDF集群，请找尼恩领取

《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓

文章来源:https://blog.csdn.net/crazymakercircle/article/details/135228907
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
最新文章