本文来自 SOFAArk 用户—溢米教育投稿，分享其内部使用 SOFAArk 组件后极大提高内部推荐系统的开发效率和稳定性的案例。感谢溢米教育对 SOFAStack 的支持，同时也欢迎更多用户投稿 Join us。
SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，主要提供类隔离和应用(模块)合并部署能力，由蚂蚁金服开源贡献。
写在前面
个性化推荐，相信大家都不陌生，简单来说就是根据每个人的偏好经过模型计算推荐出适合的东西，这些东西可以是视频、商品、文章、电影等。经过互联网这几年的发展，个性化推荐已经无处不在，不管是电商、教育、游戏、金融行业，推荐系统对业务的提升都有着非常重要的帮助。溢米教育作为一家互联网教育平台，近几年推荐业务发展非常迅速，技术团队也在持续的进行能力提升。业务快速增长的同时，亟需一个高效率、高稳定的推荐系统来支持推荐场景。
本文是根据我们内部推荐平台效率与稳定性建设的实际经验整理，介绍了溢米教育推荐系统的改造优化。在整个过程中我们基于公司架构做了分析，确认了技术选型和改造方案，最终选择基于 SOFAStack 社区开源的 SOFAArk 组件开发框架，极大的提升了我们推荐系统的开发效率和稳定性。希望能给有同样困扰的技术团队参考。
背景
一次完整的个性化推荐，通常包括召回、过滤、排序等步骤。虽然步骤不多，但是涉及到的逻辑是非常多的，包括 abtest、用户画像、物品画像、离线数据、在线数据、模型系统、字段补全等等。个性化推荐极为依赖场景定制化，不同的场景对应不同的处理逻辑。
我们可以想象，把这一堆处理逻辑都放在一个系统里面，应用会变得十分臃肿和复杂，随着业务系统不断的迭代更新，逐渐会变得难以维护，开发效率和系统稳定性都会面临不小的挑战。不幸的是，随着溢米业务快速发展，内部的推荐平台已经变得 “过劳肥”。不管是迭代效率、性能、稳定性都遇到了瓶颈，比如：
- 发布耗时： 算法团队一个人跟进一条业务线，导致业务迭代频繁、应用发布非常频繁，由于系统本身复杂性，这么一个庞然大物发布一次非常慢，降低了工程师效率；
- 系统臃肿： 所有模块统一维护，包含了存储、算法、业务等，几乎每次迭代都是只增不减，降低了系统可维护性；
- 覆盖风险： 多个团队共同维护一份代码，分支上容易存在冲突，合并代码存在覆盖风险，降低了团队合作效率；
- 版本不一致： 不同业务团队使用的 jar 包版本不一致，每次升级一个 jar 包都会引起很多问题，导致各个团队在开发期间都要花费不少精力解决依赖冲突。
基于上述背景，溢米推荐平台不得不进行应用瘦身和系统改造，从而提升平台的开发效率和稳定性。然而在实际的改造过程中，我们不难发现这两者其实是互相冲突的。为了提高稳定性，我们肯定要做到流程上的把控，比如测试、灰度、发布等流程的规范，这势必会影响业务迭代效率；反过来如果要提升效率，那么在流程上肯定会有一定的舍弃，随之而来的是稳定性的潜在风险。 但是人总是需要梦想驱动的，每个工程师都希望能用一种架构或者方案，同时解决很多通用的问题，节约成本，提升效率， 让设计人员能够不至于疲于奔命， 解放生产力来完成更多有创新有挑战的工作。
调研
效率和稳定性并非一定是二选一，在进行推荐平台升级改造之前，我们梳理了溢米内部影响业务效率和系统稳定性的主要因素。
| 开发效率 | 系统稳定 | |
|---|---|---|
| 影响因素 | 业务复杂度+开发复杂度 | 业务变更：代码变更+数据变更 |
| 业务迭代流程+开发流程 | 非业务变更：配置变更+代码变更 | |
| 业务变更+服务变更上线 | 流量变化 | |
| 稳定性流程 | 硬件故障 |
关于开发效率，从上面可以看出来除了开发部分是依赖平台所能提供的便利和开发者个人技术能力之外，其余大部分都是流程上的把控。这些流程上的把控一是为了保障业务迭代的正确性，二是为了提升业务迭代带来的线上服务稳定性，但是简单的流程不足以把控住这些点，而过度复杂的流程会很大程度上影响业务迭代效率，所以我们需要思考并且寻求一种平衡，比如如何降低业务开发复杂度？如何提升平台提供的便利？如何在不影响稳定性的情况下简化业务迭代和维护流程？
关于稳定性，我列举几个在溢米内部遇到的几个类似案例：
- 推荐服务性能优化上线，功能性测试没有问题，但是没有经过压测导致高峰期服务能力下降，最终导致整个服务不可用，而上游由于没有做好服务治理也受影响变成了服务不可用；
- 推荐服务所依赖的某个数据源或者 RPC 响应从 10ms 突然增长到 100ms，从而导致推荐服务主要线程池耗尽，最终导致服务不可用；
- 上游压测或者流量推广或者爬虫导致流量激增，但是推荐服务没有做好限流导致服务被打垮而不可用；
- 推荐系统依赖业务系统提供的RPC服务进行过滤，由于此RPC服务变更导致响应变慢，而推荐服务没有区分强弱依赖导致整体服务超时；
- 某个业务由于排期时间紧张，测试周期太短，上线后导致其它业务异常。
结合这些案例和上文总结的系统稳定性影响因素，可以发现除了硬件故障是不可控之外，其余几点基本都是因为变更而引起的。那么如何不受变更影响而提升稳定性呢？上面我们介绍过最主要也是最有效的是变更流程控制，通过测试、灰度、发布流程规范，其余也可以通过技术手段来控制，比如性能优化、服务治理、业务隔离、强弱依赖区分、多机房容灾、扩容等等。
针对以上开发效率和稳定性分析，最开始确定如下了改造目标：
-
场景模块化
- 系统瘦身，拆分模块，提高系统可维护性
- 模块复用，提升开发效率
-
模块开发时隔离
- 各模块单独迭代开发，解决之前统一迭代开发的代码冲突问题
- 各模块单独测试，提升测试效率
-
模块运行时隔离
- 模块运行时类隔离，解决模块间包冲突问题
- 模块间有明确的服务边界，一定程度的故障隔离
-
模块动态可插拔
- 动态升级，秒级发布回滚
改造
为了满足改造目标，我们初步确认了三个选择：
1）采用自定义 SPI 的 ServiceLoader 动态加载实现；
2）采用自定义 Classloader 实现；
3）寻求开源软件支持。
基于资源成本、时间成本的考虑，我们选择了寻求开源支持，蚂蚁金服开源其分布式架构吸引了我们的关注，经过技术判断，我们最终决定使用 SOFAStack 社区开源的 SOFAArk 组件开发框架。
SOFAArk 定义了一套相对简单的类加载模型、特殊的打包格式、统一的编程界面、事件机制、易扩展的插件机制等，从而提供了一套较为规范化的插件化、组件化的开发方案。更多内容可以参考官方文档：
SOFA JVM 服务： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-ark-jvm
SOFAArk 官方文档： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-readme
SOFAArk 源码： https://github.com/sofastack/sofa-ark
通过 SOFAArk+SOFABoot 的组合，我们将应用进行拆分，分为宿主应用+数据模块+业务模块：
- 主应用： 负责整个容器的状态保持；
- 数据模块： 负责数据通信，包括 Redis，DB，RPC 等基础服务；
- 业务模块： 只需要负责调用数据模块进行业务实现，最终数据通过主应用进行与外部交互。
我们建立了一套模块化开发、测试、发布流程，能够在业务中台上面进行模块开发，并且制定一套模块拆分、开发标准：
- 越底层的模块，应该越稳定，越具有高度复用性；
- 不要让稳定模块依赖不稳定模块，减少依赖；
- 提升模块的复用度、自完备性；
- 业务模块之间尽量不要耦合。
数据模块改造前，由于每个业务团队使用的方式不一致，算法团队使用的存储又非常复杂，数据量又非常的庞大，经常会遇到扩容、缩容、数据迁移等各式各样的问题，这对算法开发、运维都带来了极大的困扰，但是经过模块化改造之后，我们可以对所有的数据层出口都进行收拢，所有的底层存储都由数据模块控制，不管是升级、扩缩容、迁移，只需要对数据模块进行升级发布，业务模块完全不需要做任何事情，这对算法开发人员来说肯定是节约了很大的成本、解放了大部分的资源，而且统一在数据模块进行稳定性维护也相对简单。
未来规划
模块化、平台化、自动化的好处显而易见，大家都很清楚，场景标准化和可快速扩展性大大提升了业务迭代效率，新业务的接入成本也大大降低，在新场景上面可以低成本创新，从而满足高速发展的业务体系，但是有没有想过平台化带来的问题呢，我这边列举几个点：
- 平台问题的放大
- 平台化之后大部分细节只有平台开发人员了解，一方面会导致人为因素问题扩大，其次也会对用户习惯带来挑战
- DevOps的落地问题
所以综上可见改造不是一蹴而就的，未来我们会持续迭代，如运维平台化建设进行整个系统平台化落地，打造一套完整的推荐中台服务。
总结和致谢
目前大部分的推荐场景已经完成了模块化的拆分，已经稳定的在生产线上运行了几个月，在此感谢蚂蚁金服 SOFAStack 的开源贡献，同时也非常感谢 SOFAArk 开源维护者：善逝，在使用过程中，SOFAStack 团队提供了高效和专业的支持。
SOFAArk 源码： https://github.com/sofastack/sofa-ark