溢米教育推荐平台的效率与稳定性建设 | SOFAStack 用户说

本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提升内部推荐系统的开发效率和稳定性的案例。感谢溢米教育对 SOFAStack 的支持，同时也欢迎更多用户投稿 Join us。

SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服开源贡献。

写在前面

个性化推荐，相信你们都不陌生，简单来讲就是根据每一个人的偏好通过模型计算推荐出适合的东西，这些东西能够是视频、商品、文章、电影等。通过互联网这几年的发展，个性化推荐已经无处不在，不论是电商、教育、游戏、金融行业，推荐系统对业务的提高都有着很是重要的帮助。溢米教育做为一家互联网教育平台，近几年推荐业务发展很是迅速，技术团队也在持续的进行能力提高。业务快速增加的同时，亟需一个高效率、高稳定的推荐系统来支持推荐场景。

本文是根据咱们内部推荐平台效率与稳定性建设的实际经验整理，介绍了溢米教育推荐系统的改造优化。在整个过程当中咱们基于公司架构作了分析，确认了技术选型和改造方案，最终选择基于 SOFAStack 社区开源的 SOFAArk 组件开发框架，极大的提高了咱们推荐系统的开发效率和稳定性。但愿能给有一样困扰的技术团队参考。

背景

一次完整的个性化推荐，一般包括召回、过滤、排序等步骤。虽然步骤很少，可是涉及到的逻辑是很是多的，包括 abtest、用户画像、物品画像、离线数据、在线数据、模型系统、字段补全等等。个性化推荐极为依赖场景定制化，不一样的场景对应不一样的处理逻辑。

咱们能够想象，把这一堆处理逻辑都放在一个系统里面，应用会变得十分臃肿和复杂，随着业务系统不断的迭代更新，逐渐会变得难以维护，开发效率和系统稳定性都会面临不小的挑战。不幸的是，随着溢米业务快速发展，内部的推荐平台已经变得 “过劳肥”。不论是迭代效率、性能、稳定性都遇到了瓶颈，好比：

1. 发布耗时：算法团队一我的跟进一条业务线，致使业务迭代频繁、应用发布很是频繁，因为系统自己复杂性，这么一个庞然大物发布一次很是慢，下降了工程师效率；
2. 系统臃肿：全部模块统一维护，包含了存储、算法、业务等，几乎每次迭代都是只增不减，下降了系统可维护性；
3. 覆盖风险：多个团队共同维护一份代码，分支上容易存在冲突，合并代码存在覆盖风险，下降了团队合做效率；
4. 版本不一致：不一样业务团队使用的 jar 包版本不一致，每次升级一个 jar 包都会引发不少问题，致使各个团队在开发期间都要花费很多精力解决依赖冲突。

基于上述背景，溢米推荐平台不得不进行应用瘦身和系统改造，从而提高平台的开发效率和稳定性。然而在实际的改造过程当中，咱们不难发现这二者实际上是互相冲突的。为了提升稳定性，咱们确定要作到流程上的把控，好比测试、灰度、发布等流程的规范，这势必会影响业务迭代效率；反过来若是要提高效率，那么在流程上确定会有必定的舍弃，随之而来的是稳定性的潜在风险。 可是人老是须要梦想驱动的，每一个工程师都但愿能用一种架构或者方案，同时解决不少通用的问题，节约成本，提高效率， 让设计人员可以不至于疲于奔命， 解放生产力来完成更多有创新有挑战的工做。

调研

效率和稳定性并不是必定是二选一，在进行推荐平台升级改造以前，咱们梳理了溢米内部影响业务效率和系统稳定性的主要因素。

关于开发效率，从上面能够看出来除了开发部分是依赖平台所能提供的便利和开发者我的技术能力以外，其他大部分都是流程上的把控。这些流程上的把控一是为了保障业务迭代的正确性，二是为了提高业务迭代带来的线上服务稳定性，可是简单的流程不足以把控住这些点，而过分复杂的流程会很大程度上影响业务迭代效率，因此咱们须要思考而且寻求一种平衡，好比如何下降业务开发复杂度？如何提高平台提供的便利？如何在不影响稳定性的状况下简化业务迭代和维护流程？

关于稳定性，我列举几个在溢米内部遇到的几个相似案例：

• 推荐服务性能优化上线，功能性测试没有问题，可是没有通过压测致使高峰期服务能力降低，最终致使整个服务不可用，而上游因为没有作好服务治理也受影响变成了服务不可用；
• 推荐服务所依赖的某个数据源或者 RPC 响应从 10ms 忽然增加到 100ms，从而致使推荐服务主要线程池耗尽，最终致使服务不可用；
• 上游压测或者流量推广或者爬虫致使流量激增，可是推荐服务没有作好限流致使服务被打垮而不可用；
• 推荐系统依赖业务系统提供的RPC服务进行过滤，因为此RPC服务变动致使响应变慢，而推荐服务没有区分强弱依赖致使总体服务超时；
• 某个业务因为排期时间紧张，测试周期过短，上线后致使其它业务异常；

结合这些案例和上文总结的系统稳定性影响因素，能够发现除了硬件故障是不可控以外，其他几点基本都是由于变动而引发的。那么如何不受变动影响而提高稳定性呢？上面咱们介绍过最主要也是最有效的是变动流程控制，经过测试、灰度、发布流程规范，其他也能够经过技术手段来控制，好比性能优化、服务治理、业务隔离、强弱依赖区分、多机房容灾、扩容等等。

针对以上开发效率和稳定性分析，最开始肯定以下了改造目标：

• 场景模块化
• 系统瘦身，拆分模块，提升系统可维护性
• 模块复用，提高开发效率

• 模块开发时隔离
• 各模块单独迭代开发，解决以前统一迭代开发的代码冲突问题
• 各模块单独测试，提高测试效率

• 模块运行时隔离
• 模块运行时类隔离，解决模块间包冲突问题
• 模块间有明确的服务边界，必定程度的故障隔离

• 模块动态可插拔
• 动态升级，秒级发布回滚

改造

为了知足改造目标，咱们初步确认了三个选择：

1）采用自定义 SPI 的 ServiceLoader 动态加载实现；

2）采用自定义 Classloader 实现；

3）寻求开源软件支持。

基于资源成本、时间成本的考虑，咱们选择了寻求开源支持，蚂蚁金服开源其分布式架构吸引了咱们的关注，通过技术判断，咱们最终决定使用 SOFAStack 社区开源的 SOFAArk 组件开发框架。

SOFAArk 定义了一套相对简单的类加载模型、特殊的打包格式、统一的编程界面、事件机制、易扩展的插件机制等，从而提供了一套较为规范化的插件化、组件化的开发方案。更多内容能够参考官方文档：

SOFA JVM 服务： www.sofastack.tech/sofa-boot/d…

SOFAArk 官方文档： www.sofastack.tech/sofa-boot/d…

SOFAArk 源码： github.com/sofastack/s…

经过 SOFAArk+SOFABoot 的组合，咱们将应用进行拆分，分为宿主应用+数据模块+业务模块：

• 主应用：负责整个容器的状态保持；
• 数据模块：负责数据通讯，包括 Redis，DB，RPC 等基础服务；
• 业务模块：只须要负责调用数据模块进行业务实现，最终数据经过主应用进行与外部交互。

咱们创建了一套模块化开发、测试、发布流程，可以在业务中台上面进行模块开发，而且制定一套模块拆分、开发标准：

• 越底层的模块，应该越稳定，越具备高度复用性；
• 不要让稳定模块依赖不稳定模块，减小依赖；
• 提高模块的复用度、自完备性；
• 业务模块之间尽可能不要耦合。

数据模块改造前，因为每一个业务团队使用的方式不一致，算法团队使用的存储又很是复杂，数据量又很是的庞大，常常会遇到扩容、缩容、数据迁移等各式各样的问题，这对算法开发、运维都带来了极大的困扰，可是通过模块化改造以后，咱们能够对全部的数据层出口都进行收拢，全部的底层存储都由数据模块控制，不论是升级、扩缩容、迁移，只须要对数据模块进行升级发布，业务模块彻底不须要作任何事情，这对算法开发人员来讲确定是节约了很大的成本、解放了大部分的资源，并且统一在数据模块进行稳定性维护也相对简单。

将来规划

模块化、平台化、自动化的好处显而易见，你们都很清楚，场景标准化和可快速扩展性大大提高了业务迭代效率，新业务的接入成本也大大下降，在新场景上面能够低成本创新，从而知足高速发展的业务体系，可是有没有想过平台化带来的问题呢，我这边列举几个点：

• 平台问题的放大
• 平台化以后大部分细节只有平台开发人员了解，一方面会致使人为因素问题扩大，其次也会对用户习惯带来挑战
• DevOps的落地问题

因此综上可见改造不是一蹴而就的，将来咱们会持续迭代，如运维平台化建设进行整个系统平台化落地，打造一套完整的推荐中台服务。

总结和致谢

目前大部分的推荐场景已经完成了模块化的拆分，已经稳定的在生产线上运行了几个月，在此感谢蚂蚁金服 SOFAStack 的开源贡献，同时也很是感谢 SOFAArk 开源维护者：善逝，在使用过程当中，SOFAStack 团队提供了高效和专业的支持。

SOFAArk 源码： github.com/sofastack/s…

公众号：金融级分布式架构（Antfin_SOFA）