新东方云教室核心业务系统架构

新东方云教室（以下简称云教室），目前已经服务100+个分校/机构上直播课，支撑百万用户同时在线上课，直播课类型涵盖小班课、多视频课、双师子母班课、大班课、H5超大班课，用户前端已经覆盖全端支持包括PC的Windows、Mac，移动的iOS、Android，以及H5。

云教室核心业务系统架构

如上图所示，支撑云教室业务功能的核心业务系统，目前的主要功能模块包括用户、注册登陆、教室课表、课件、机构管理等。系统服务主要分为Client API、Open API、管理后台。Client API为各个用户前端提供业务功能接口，包括登陆注册、课表等，Open API为外部机构系统接入云教室能力提供对接接口，包括核心的用户、教室、课件等的管理和打通，管理后台为没有系统接入能力的机构提供统一的业务管理运营后台，管理包括用户、教室、课件等业务，以及查看业务运营数据，做课中实时监课等。

云教室业务目前已达到百万日活，日课量达到十万，支持大班万人同时上课互动，今年的疫情使得在线教育成为趋势，云教室的业务量还会不断攀升，业务对系统的要求也会越来越高。目前我们的服务可用性SLA已经要求达到四个九以上，所有核心服务接口响应时间也是在百毫秒以下。

服务端系统采用Java语言使用Spring、Spring Boot、MyBatis等主流框架开发。核心业务数据存储在MySQL，采用主从架构读写分离，一主多从，主库做了HA设计。另外，核心业务数据大表做分库分表拆分，以支撑不断增长的业务要求。核心业务服务和接口大量采用了缓存架构设计，以满足业务上的高并发、高性能的要求，缓存层是Redis集群，可动态扩缩容。我们的系统中很多地方还用到了分布式的消息系统Kafka，比如对于前端大量业务数据上报、耗时的课件处理，以及异构系统间调用交互等场景，Kafka起到了重要的削峰、异步处理、解耦的作用。另外，线上业务访问并发往往很高，为了避免瞬时激增的业务访问把系统冲垮，我们采用了分布式流量控制组件Sentinel在接口层增加了流量的监控和限流保护机制，内部服务间的依赖调用也利用Sentinel的熔断、降级机制保护服务以得到更好的稳定性。再有，我们很多功能在系统实现上涉及到定时任务处理，这里我们使用了分布式的任务调度平台XXL-JOB来实现任务的定时调度执行。很多时候，我们的业务功能规则和逻辑控制开关大多需要随时快速变更调整，比如登陆应急降级处理、课表缓存策略降级、课件上传类型的控制等等，这里采用了Nacos实现配置中心。以上系统架构也是经过一年多，随着业务发展需要逐步搭建和完善的，尤其今年疫情要求我们的系统快速升级优化，未来也还会针对业务要求不断完善，以更好的赋能和服务业务。

今年疫情这个黑天鹅事件，对我们公司和我们团队来说，和各行各业一样，是困难更是挑战。经过一年的研发，云教室产品初步成型，今年本计划按正常节奏逐步开展业务，疫情使得我们的线上直播业务需求瞬间增长百倍，几乎线下都要转到线上来上课。对我们团队来说，做好这件事与其说是艰巨的任务，不如说是使命，因为做好这件事对新东方意义可想而知。

疫情导致业务激增百倍

任务艰巨，因为大量的工作要在短时间内完成，而且远程办公沟通不畅更增加了困难，所以整个团队每个人都是精神紧绷的状态日以继夜地工作。两周的时间内我们要做的事，包括基础设施组件横纵向扩容、服务程序性能及可用性改造优化、完善监控机制，以及处理线上各种各样的问题等等。

以服务程序性能改造优化来说，核心业务大表就以每天几百万条的速度增长，很快就达到几千万，后面还一直持续增长。通过对时间要求、系统影响、现有资源等方面综合的考量，我们最终没有采用对大表做分表的优化方案，而是对历史数据做定期归档，并增加数据的全量缓存以满足更高的性能要求和业务需求。这个优化改造从方案讨论设计、研发、测试、上线，我们只用一周的时间完成，上线后系统稳定，核心接口性能提升10倍，系统负载也相应降低10倍。这期间除了大量系统优化工作要做，业务高峰我们还要值班及时响应、快速处理线上各种突发问题，以确保服务的可用性。

核心大表优化方案

核心大表优化效果

一个团队是否具有战斗力和实力，只有在遇到困难时才能真正考验和检验出来，时间紧、任务重、困难多，需要每个人的全心付出、努力以及高效的工作。结果证明我们的团队是可以打硬仗的。经过团队上下的齐心协力，我们克服各种困难，不辱使命，很好的完成了疫情期间的业务支撑工作，在这个过程中团队以及每个人也得到了很好的磨砺和成长。相信随着我们业务的继续发展，我们团队也会越来越成熟和具有实力，并不断为公司为教育行业做出更多的贡献。