24亿级用户超级APP背后的全技术大揭秘

进入十亿级用户“APP 俱乐部”，可以说是很多做 APP 的公司梦寐以求的目标。

2017年，刚刚成立2年的茄子科技（海外SHAREit Group）交出了一份亮眼的出海成绩单，旗下APP  SHAREit（国内茄子快传）全球用户总数达到了10亿+，跻身十亿级用户“APP俱乐部”。

之后，SHAREit 仍保持着惊人的增长速度。2018 年，SHAREit 全球用户超 15 亿，2019 年，SHAREit 全球用户超 18 亿，月活超过 5 亿。截止目前，茄子科技包括 SHAREit 在内的多款 APP 产品全球累计安装用户量近 24 亿。

伴随着 SHAREit 在全球成为“爆款”产品，茄子科技也成为国内出海潮中的众多互联网公司中先一步闯出一番天地的佼佼者。出海之旅愈发深入，抵达终点的路径也就愈发清晰，这是一场关于产品、技术、运营的综合考验。

对于出海企业来说，如果把移动互联网产品看作一根支起全球的“撬棍”，那么这根撬棍能发挥出多大的力量，离不开背后坚实的技术支撑。

近日，InfoQ 专访了茄子科技多位技术 Leader，试图从技术的维度探究下，几十亿量级的超级 APP 是怎样“炼”成的，以及在技术的护航下，这家公司是如何支撑业务一路迅猛扩张到 24 亿用户规模的。

基于 24 亿级这样庞大的用户规模，应该怎样做基础架构搭建？

成立 6 年来，茄子科技用户规模从 0-1 的过程，实际上也是该公司的基础架构从 0-1、从 1-10 的建设历程。

茄子科技基础架构负责人在接受 InfoQ 采访时表示，无论从用户角度，还是从服务端建设角度看，公司整个基础架构从一开始简单的、小规模的系统，逐步演进到了全面的分布式系统。

整个架构演进分为 2 个阶段：

• 初级阶段：

早期产品功能简单，数据量少，算法相对简单，业务迭代速度快，大约一周迭代一个版本，但面临后端人力不足的挑战。整个后端业务 100% 在公有云上，团队充分利用公有云的 SaaS 和 PaaS 服务来支持业务迭代。

• 快速发展阶段：

到这一阶段，在某些业务场景下，公有云 SaaS 和 PaaS 服务已经无法满足需求。

一是成本的需求。当业务规模小时，采用公有云的 SaaS 和 PaaS 服务的成本较低，但一旦业务规模扩大，数据规模和服务压力成数量级增长后，成本会线性上涨。二是与功能 / 性能相关的需求。公有云的 SaaS 服务提供的多是标准化、通用的能力，其会为解决多租户问题设限制。随着公司业务发展，已触发了诸多限制进而导致影响业务增长。

因此，茄子科技开始逐步减少对云厂商的深度依赖，在采用其基础设施层面的 IaaS 服务的同时，与自研服务相结合，完成对业务的支持。

后来，在公司由工具型产品向内容产品转型的过程中，数据量日益激增，推荐算法不断增加，进一步提高了对数据存储及算力的要求，于是，茄子科技结合开源软件引入了大量自研架构服务。

目前，茄子科技的架构分为两方面：一是 IasS 层面依托公有云提供基础资源，整体采用混合云的多云架构，以最大化获取云计算资源，充分应用每个云厂商的优势，提升议价能力。

二是根据自有业务场景采用开源 + 自研架构。在技术组件选择方面，现阶段主要以开源方案为主，并在此基础上针对业务场景做深度扩展和定制，如在开源软件基础上定制自有的 KV 存储系统。

茄子科技一开始只采用“一朵云”，后来综合权衡容灾、成本等因素，转向多云架构。

但这一转变并不容易。

在这个过程中，要做部分用户和业务迁移。但以前在“一朵”公有云上时，与公有云的各种服务做了技术上的深度绑定，这导致无法直接平行迁移。需要对基础架构和基础服务升级改造后，再进行服务迁移。

服务迁移相对容易，麻烦的是做整个架构升级，因为它要求全公司所有业务线都要动起来，这极为考验整体架构的扩展能力。在迁移过程中，还要保证零事故、无缝迁移保证高可用，让用户不受任何干扰。

而且，产品 / 业务迭代发展不等人，研发人力没有冗余，留给整个迁移的时间窗口非常短，仅仅只有不到六个月时间。

时间紧张，基础研发团队通过倒排工期，快速推进，制定了“四步走”计划：

一，和云厂商共同制定整体架构方案；

二，内部云平台团队与基础架构团队联合制定自研方案，商讨自研架构方案如何适配到业务侧；

三，与业务研发部门一起制定零事故实现平行迁移和架构升级方案；

四，拉通所有团队高效协作。

一步一步迈进，克服了所有挑战后，最终，基础研发团队在规定时间内完成了迁移，在这个过程中，也成功做到了零宕机事故，对用户零干扰。

上述负责人表示，现在乃至于未来一段时间，茄子科技还会采用混合公有云方案来支撑业务，应用架构朝着云原生架构方向走，“云原生，要生在云上，长在云上，要用云的各种便利性，例如，应充分利用公有云灵活的弹性扩缩容能力及多云融合跨区域的容灾能力，来实现高可用性、高性能、高可扩展的架构”。

关于技术选型背后的逻辑，茄子科技侧重综合平衡项目、团队、技术三个方面。

• 项目：明确项目的性质、规模、重要程度、时间要求。项目需求会影响甚至限制技术的选型，如果项目是实验性项目且开发时间短，此时要重点考虑快速开发能力，框架选型考虑选用生态成熟的技术。如果项目重要且开发周期长，这时对并发性、实时性、可用性，数据一致性及安全性均有高要求，组件选型上尤其要慎重。

• 团队：考虑技术团队成员背景，针对较基础的技术选型，如语言、框架、数据库、中间件等，通常选择适合团队的、相对熟悉的技术。如果想选择其他技术，要评估团队是否 hold 住。

• 技术：从应用性、可维护性、可扩展性、性能等方面考虑技术特性，重点考察技术的成熟度、社区活跃度、架构匹配度等，侧重评估技术是否适合业务场景。

随着用户量剧增，平台复杂度会大大提升。如何解决复杂性的问题，上述负责人认为，首先从架构层面要做好分层解耦，业务系统层、中间件层、基础服务层、云平台层等权责明晰。分层后，需划定好边界，以避免各层互相推诿。另外，还离不开将单体服务微服务化、配置化，在微服务化拆分过程中要持续加强建设服务治理的生态体系。

出海环境下，移动互联网 APP 用户群体遍布全球，这对做好个性化分发和推荐，满足不同用户深层次的个性化需求带来了极大的挑战。

茄子快传的产品矩阵目前覆盖全球 200 多个国家和地区，尤以新兴市场 — 东南亚、南亚、中东、非洲、俄语地区为主。针对这么多国家，怎样做算法推荐？

茄子科技大数据和 AI 负责人向 InfoQ 表示，针对不同国家，APP 采用相同的框架，但在内容推荐过程中，算法端存在差异，受众群体变了，策略也要有相应调整。

在针对某一国家的用户进行内容推荐前，团队首先会从负责该国一线业务的人员处了解相关信息，如国家文化习俗，受众特点、喜好等，再基于这些信息制定算法策略的 Baseline。

推荐算法的重心在于迭代。一方面会基于业务团队反馈或者 Badcase 来调整，具象化共识。另一方面进行线上 AB 实验，基于数据方法论来检验效果和调优。

“茄子科技不光跟其他公司一样面临不同内容、类型的推荐，我们的推荐系统面向的受众覆盖众多国家和地域，不似国内地域间差异不明显。不同国家的差异有时候往往是巨大的，不同国家的用户风格、习惯、偏好都存在较大差异。因此，我们的大数据投喂算法已覆盖了多产品的多类内容，涵盖业务种类多样。在做好算法体系的扩展性的同时，我们针对不同国家、不同场景也会做额外的深度探察”，上述负责人表示。

现在个性化推荐已经不是社交产品发展的趋势了，而成为了标配。但一个不能忽视的问题是，现阶段个性化推荐还没有那么智能。有时候，算法推荐的可能并不是用户想要的，算法往往推荐给用户大量相似内容，这反而会给用户带来困扰。“投用户所好”和“挖掘用户的深度目标和需求”之间的矛盾仍未完全调和。

对于这个问题，上述负责人认为，“投用户所好”是浅度目标，而“发掘用户深度需求”是深度目标，深度目标更难实现，难在其无法量化，不好刻画。

他认为，这一矛盾的核心在于算法优化目标。解决这类问题的前提是构建评价指标，进行推荐效果评估时，除评价单一目标优化效果等目标外，还会从多目标的角度作评估，如关注多样性、新颖性、惊喜度等。

当用户偏好和深度目标发生冲突时，首先会基于场景分析业务目标，建立正向收益的同时，提出负向折损的忍耐度。在执行中的判断，会根据某些场景的独立性、影响周期等做指标置换。但当深度目标不确定时，冲突比较难化解，对此，团队在做置换的基础上会基于价值取向，做更多服务于用户长期增长的工作。

具体推荐过程中，团队还会收集用户端的反馈，来验证推荐效果，推荐效果的 Feedback 和调优是推荐最重要一个环节，团队从方方面面全方位收集各种反馈，以此来做整体调优。

据了解，茄子科技整个数据链路包括两部分，一部分是偏技术方向的演变，另一方面是支撑多样业务的演变。基于这两类场景，采用两类思路，第一类偏渐进，另外一类偏创新的思路。

其中，渐进思路往往映射通用解决方案，因为大数据从采集、处理、分析、架构，都有相对成熟的通用技术方案。茄子科技采用业界通用的流、批计算引擎，同时为了可靠性，并基于业务多变的诉求做渐进升级和二次开发，比如，茄子科技业务的特殊性使得在多云多区域上面临不小挑战，因此也会有针对性的做平台层的封装。

目前茄子科技还正在推进湖仓一体架构的逐步演变，将数据湖、数据仓库等不同概念相融合。

前端工程化，通俗的理解是，尽可能快速地实现可信赖的产品。其中两个关键词，“快速” ，讲求开发速度、构建速度、测试速度、问题定位速度；“可信赖”，包括代码的质量、产品的性能、安全、及重现和定位问题能力。

茄子科技前端负责人介绍，SHAREit 的前端工程化建设经历了三个阶段：石器时代，工业时代，信息时代。

石器时代：

在石器时代，典型特征是单工程的 MVC 架构，公司发展初期人比较少，反而效率更高，问题也比较少。但随着公司发展越来越快，SHAREit 从单业务发展到多业务的平台型产品时，单工程架构在人员节奏方面出现了较多问题，如代码耦合导致一些问题浮现出来。这时，便开始工程组件化重构，进入到工业化时代。

工业时代

工业化时代，典型的特征是组件化。茄子科技使用的是多工程、多仓库的方案，每个组件或 SDK 都有自己独立的仓库，都可以独立于主工程进行单独的编译和运行。这方面分为三大层：APP 的壳、业务层、基础层，基础层再往下还有更多、更细粒度的划分。前端团队自上而下通过 AAR 的方式进行依赖。组件化采用“分而治之”的思想，很好地解决了多团队协同作战的问题。

信息时代

随着公司孵化更多产品，每个产品在不同国家定制不同功能，规模越来越大了，用以前的组件化形式很难高效地支撑现有的业务，于是，茄子科技引入了 Google Bundle 技术，进入到信息化时代。其实针对这一问题，国内多采用插件化的方案，但由于海外不能做插件化技术，茄子科技只能运用谷歌自有特性。

在信息化时代，典型的特征是 Bundle 组件化。Bundle 模块具有反向依赖的特征。通过增加 Bundle 壳及自动化检测工具的形式，让 App Bundle 的特性和以前已有的组件化融合，让开发者保持已有的开发模式。通过 App Bundle，可以做到针对每个国家用一个 APP 按需定制不同功能，如内容、直播、游戏等。

为提升效率和质量，茄子科技还搭建了客户端 CI/CD 平台，流程主要有编码规范检测、大文件 / 图片检测、静态代码扫描，关键文件触发 Review、代码 Review、安全风险检测，预编译、包体积监控，编译速度监控等，能做到自动打包、自动检测、自动化测试与发布。

据悉，前端团队已经涵盖开发、测试、构建、部署一系列流程，通过自研 APM 系统的预警机制、自动分配、辅助信息等，能够及时发现且快速定位问题，并优化迭代，最终形成整个研发流程闭环。

如何保证全球 24 亿级用户使用产品的稳定性，对茄子科技来说，是至关重要的一环。

“稳定性” ，即产品可以给用户预期内的服务。这句话看似轻松，但当面对海量用户以及复杂的全球环境时，实现起来就不容易了。

具体而言，服务端高可用、客户端高可用、传输连接速度、传输速度、在线内容拉取性能、播放成功率等都属于稳定性体系建设的范畴。

为了确保稳定性，茄子科技搭建了一整套作用于整个软件开发周期的体系化解决方案。在开发阶段有一系列开发规范以及本地校验流程，便于研发提前发现问题；而从提交 MR 开始，构建系统会自动执行预设的校验流程，全部完成后才能合入主干；在测试阶段，除常规测试外，还会覆盖全面的自动化测试。在用户真实环境中，会自动采集用户使用中的稳定性指标如启动速度、卡顿、内存、崩溃、网络等问题，上报后 APM 平台会进行数据清洗、加工处理、自动分配，结合报警，开发就可以第一时间开始排查线上发生的问题。

茄子科技平台自身的高流量特点对稳定性要求高。茄子科技认为，稳定性的范畴不应仅局限在平台建设上，还要扩大至涵盖组织、人、工具、故障管理等多方面、完整的稳定性体系建设。

首先，从公司整个组织结构看，公司自上而下、跨团队（包括业务团队、基础研发团队、产品团队、内容运营团队等），都要达成稳定性的共识机制。因为各个团队对稳定性理解不同，如果达不成共识，稳定性建设就无从谈起。

此外，根据成本、业务容忍度，系统当前的稳定性状态，针对不同的业务系统，设定不同的稳定性目标，核心业务的目标稳定性显然更重要。稳定性体系建设过程中也要避免“一刀切”都是最核心指标，这需要我们做好稳定性、成本、研发效率之间的平衡。

从人的角度看，开发、测试、运维、安全，需要每个人从自身岗位出发去做技术体系的建设，做好流程规范、开发规范、测试规范、运维上线规范、事故复盘等。

稳定性建设还离不开工具作为手段。从工具的角度看，要通过客户端链路埋点，服务端限流降级等一系列技术方案的需求，由基础研发团队输出一系列的支持工具和平台。

稳定性建设里，最关键的一点是故障管理。故障管理分为故障前、故障中、故障后。

事前预防，包括做业务成熟度评估，分析其短板；做容错测试，通过主动性测试提高故障处理能力；上线前做容量评估和规划。还要建立流程，保证故障发生时能第一时间响应。

当故障发生时，又该如何应对？首先是机制保障，故障要是没有机制保障，其他的事情便无从谈起。这些机制包括，故障发生后相关团队能否快速响应，共同成立临时“作战室”，快速解决线上故障；当故障升级或者高等级故障发生时，是否有足够的资源投入等。针对一些底层的业务组件，茄子科技还会和云厂商一起联合排障。

故障解决完了，但事情还远远没有完。故障解决完后的总结、改进和跟踪也不能忽视。故障处理完后，各个业务方会一起复盘故障原因，并列出整改措施。复盘结束后，相关人员会对措施关键节点进行追踪、写故障报告，最终输出到故障知识库，作为以后的查阅。

最后，会检查类似 / 关联服务是否存在隐患，通过举一反三的思路，避免减少重复犯错。

据悉，茄子科技已打通了公司多个内部系统，让开发部门在解决问题时能得到更全面的信息，方便定位问题、解决问题。

“如果一句话来总结：我们的稳定性系统，核心是数据，依托的是平台，并且建立了一整套闭环体系化流程。”茄子科技前端负责人表示。

来源：infoQ

——————END——————

欢迎关注“Java引导者”，我们分享最有价值的Java的干货文章，助力您成为有思想的Java开发工程师！