猿辅导是一家在线教育公司，目前公司的产品涵盖学龄前（斑马 AI 课）、K12（猿辅导）、少儿编程（猿编程）以及教育类的相关应用（猿题库、小猿搜题、小猿口算），我们希望用科技去改变教育。
在猿辅导背后，是一个庞大的工程体系去支撑整个教育系统。这个教育系统除了面向几亿名终端用户以外，还负责支撑几万人的辅导老师、教研、主讲老师团队的日常工作。这个工程系统是一部庞大的在线教育机器，涉及的领域包括机器学习、音视频处理、实时计算、互动课堂等多个技术方向。我们使用了微服务架构去实现这样庞大的业务系统，成千上万个微服务被部署在多个核心机房中。

我们的主要用户群体均为付费用户，对于系统的稳定性要求会更加严格。辅导老师、主讲老师和教研老师依赖我们的系统去传递知识、传递快乐，学生依赖我们的系统获得成长，短暂的服务不可用都有可能给大量的家庭带来影响。我们的业务规模每年以数倍增速进行扩张，系统设计之初的冗余很快就会被高增速打满。可用性、可扩展性是我们在系统设计上最优先考虑的要素。
为此，团队需要不停地检视我们的工程体系，发现其中潜在的问题，做好准备去迎接未来的挑战。

基础平台

IDC

猿辅导的机房设施分为核心机房与边缘机房，其中核心机房内部署了大部分的存储、应用服务。核心机房主要部署在国内的主要一线城市内，除了自建的 IDC 机房以外，我们也会使用阿里云和腾讯云的相关云主机来补充弹性能力。核心机房之间一般都通过多条网络专线连接，核心机房本身也可以作为中转节点以确保网络的高可用能力。
同时，我们也使用了阿里云和腾讯云的边缘计算能力，在众多国内二三级城市以及北美的部分城市内部署了大量的边缘机房，边缘机房则作为直播系统的一部分，部署直播边缘节点，为用户提供低延迟的音视频流转发服务。

存储设施

我们的持久化数据存储以关系型存储为主，因此 MySQL 是公司内使用范围最广的数据库。我们自己维护了若干个大规模的 MySQL 集群，分布在各个核心机房内。此外，对于一些特殊场合，我们也使用了阿里云的相关关系型存储产品作为补充，包括 RDS、DRDS 和 PolarDB。
在性能要求极高的场景下，我们优先使用 Redis 作为分布式内存缓存数据库。和 MySQL 类似，工程团队在每个核心机房内都有自维护的 Redis 集群，大部分自维护的集群都使用 Redis Sentinel 作为高可用方案。阿里云上 Redis 集群也同时被团队所使用。同时，有部分早期的服务也在使用 Memcached 作为分布式内存数据库。
Hbase 和 ElasticSearch 在一些 OLAP 场景下也会被使用，例如教研系统的数据分析、用户搜索等等。

应用服务编排

在猿辅导早期，我们直接使用物理机进行服务部署。很快地我们遇到了这种部署模式的瓶颈，因此我们基于 Docker 容器运行时，自己实现了一套容器编排服务。现在，我们大部分的应用服务都使用自建的这套 Docker 编排服务进行部署，它主要帮助我们去关联容器与物理机，去维护容器的生命周期，暴露一套统一的接口使研发可以自助进行构建、部署操作。
在 2021 年的春晚活动前期，这套容器编排引擎已经不再很好地满足大规模扩、缩容的场景了，我们的研发团队在这次活动中小规模尝试了 Kubernetes。Kubernetes 很好地支持了春晚活动业务，因此在活动后，猿辅导开始大规模迁移应用服务编排引擎到 Kubernetes。
我们为 Kubernetes 实现了一些相关的工程设施，例如流水线引擎 Pipelix、Kubernetes API 代理 Plume、CI/CD 平台 Phoenix。同时我们也使用 Argocd 来管理非标服务的编排需求。

应用服务

站内流量调度

目前猿辅导有两套注册中心，分别是 ZooKeeper 和 Nacos。ZooKeeper 是比较早期的技术选型，在经历业务的高速增长后，ZooKeeper 的写能力遇到了瓶颈，因此我们在 2020 年将注册中心替换成了 Nacos 以支持更好的集群扩展。同时我们还自己实现了一套 Naming Agent，代理所有的注册、发现请求，为应用服务屏蔽了 Nacos 的实现细节，为将来更换注册中心预留了接口。
应用服务之间使用 Thrift 协议相互进行通信，为了携带 meta 信息，我们使用 THeaderTransport 作为 Thrift 传输层协议。

任务调度

定时任务被广泛应用于各个业务系统中，例如当用户下订单后，定时检查订单是否超时；在最终一致性事务中负责最终状态检查；在系统中巡检潜在的数据不一致风险等等。因为历史原因，目前系统中有三套定时任务实践。
首先我们通过自定义的 Docker 编排引擎，实现了 job 容器的持久化运行，在这个容器中通过 crontab 来调度任务。但这种方案在物理机故障时不能很好地处理容灾问题，所以我们在业务服务中直接使用 Spring 的 @Cron 注解进行任务调度，同时使用 ZooKeeper 进行 Leader 选举确保同一时刻只有一个任务在执行。随着系统的进一步复杂化，原先零星的定时任务成了系统设计中的一个常见模式，我们引入了 xxl-job 作为分布式任务调度引擎。

消息队列

在公司早期，我们使用过 RabbitMQ 作为消息队列服务，但很快地我们遇到了 RabbitMQ 不能抗挤压以及可扩展性上的问题。就像一开始我们提到的，可用性与可扩展性是团队考虑技术选型的第一要素，为此我们迁移了大部分的消息队列到 Kafka 和 RocketMQ 上。
同时，我们使用 MySQL 以及 tutor-on-tick-message 服务实现了延迟消息能力，解决了 RocketMQ 延迟消息天数的限制。

开发与部署

代码仓库、代码搜索、发布系统、CI 系统、包管理、配置管理、装机

开发语言

Java、Spring Boot、Monorepo、Node.js、Python、C++

可见性

可见性工程

日志

我们使用 Fluentd 去各个基础设施上进行日志采集，并将日志写入[阿里云 SLS]以提供搜索、分析能力。此外，日志也会持久化落盘在 Hbase 上。

指标分析

随着业务规模扩大和复杂度逐渐上升，也为了适应基础设施云原生化发展，我们正在将指标体系从 OpenFalcon 切换到 Prometheus。当前业务可以使用 Prometheus SDK 埋点，通过 PromQL 查询和通过 Grafana 可视化自己的业务数据大盘。
同时也因为庞大的业务规模和 Prometheus 的数据模型特点，我们遇到了部分指标维度爆炸的问题，这极大影响了 Prometheus 集群的性能和可用性。我们正在积极尝试 VictoriaMetrics、M3 等分布式存储方案，也在探索进一步增强 TSDB 的各维度线性拓展的能力。

链路分析

阿里云 Tracing，Skywalking

报警

AlertManager, Cicada

测试

持续测试平台、流量复制、流量比对

入站流量

猿辅导的大部分入站流量都是 HTTPS 请求，这些请求在经过 DNS 解析后，会通过阿里云、腾讯云的相关 ELB 产品在 4 层进行负载均衡。接下来请求会进入 Nginx 集群在 7 层进行流量路由，我们同时也使用了 Nginx 的 Upstream 负载均衡能力使流量均匀地分发到每组应用服务的不同实例上。
在今年基础架构的一个主要改进方向上，我们拆分了这一层 Nginx 的路由转发能力与负载均衡能力，让这一层 Nginx 只负责路由转发。同时使用 Kubernetes Ingress Controller 集群做 Kubernetes 内 HTTP 流量的负载均衡。这个架构一方面简化了每一层的复杂度，使得路由组件可以单独演进；另一方面也对 Docker 集群向 Kubernetes 迁移提供了支持。

客户端

客户端体系

Web

语言

TypeScript、JavaScript、Node.js、Angular、Vue、React、SPA、SSR、Electron

构建

构建系统、发布、CDN、NPM

iOS

语言

OC、Swift

Library

存储

构建

构建系统、包发布系统、制品管理

Android

Hybrid

Flutter

React Native