溢米教育推薦平臺的效率與穩定性建設 | 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 服務： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-ark-jvm

SOFAArk 官方文檔： https://www.sofastack.tech/sofa-boot/docs/sofa-ark-readme

SOFAArk 源碼： https://gitee.com/sofastack/sofa-ark

經過 SOFAArk+SOFABoot 的組合，咱們將應用進行拆分，分爲宿主應用+數據模塊+業務模塊：

• 主應用： 負責整個容器的狀態保持；
• 數據模塊： 負責數據通訊，包括 Redis，DB，RPC 等基礎服務；
• 業務模塊： 只須要負責調用數據模塊進行業務實現，最終數據經過主應用進行與外部交互。

咱們創建了一套模塊化開發、測試、發佈流程，可以在業務中臺上面進行模塊開發，而且制定一套模塊拆分、開發標準：

• 越底層的模塊，應該越穩定，越具備高度複用性；
• 不要讓穩定模塊依賴不穩定模塊，減小依賴；
• 提高模塊的複用度、自完備性；
• 業務模塊之間儘可能不要耦合。

數據模塊改造前，因爲每一個業務團隊使用的方式不一致，算法團隊使用的存儲又很是複雜，數據量又很是的龐大，常常會遇到擴容、縮容、數據遷移等各式各樣的問題，這對算法開發、運維都帶來了極大的困擾，可是通過模塊化改造以後，咱們能夠對全部的數據層出口都進行收攏，全部的底層存儲都由數據模塊控制，不論是升級、擴縮容、遷移，只須要對數據模塊進行升級發佈，業務模塊徹底不須要作任何事情，這對算法開發人員來講確定是節約了很大的成本、解放了大部分的資源，並且統一在數據模塊進行穩定性維護也相對簡單。

將來規劃

模塊化、平臺化、自動化的好處顯而易見，你們都很清楚，場景標準化和可快速擴展性大大提高了業務迭代效率，新業務的接入成本也大大下降，在新場景上面能夠低成本創新，從而知足高速發展的業務體系，可是有沒有想過平臺化帶來的問題呢，我這邊列舉幾個點：

• 平臺問題的放大
• 平臺化以後大部分細節只有平臺開發人員瞭解，一方面會致使人爲因素問題擴大，其次也會對用戶習慣帶來挑戰
• DevOps的落地問題

因此綜上可見改造不是一蹴而就的，將來咱們會持續迭代，如運維平臺化建設進行整個系統平臺化落地，打造一套完整的推薦中臺服務。

總結和致謝

目前大部分的推薦場景已經完成了模塊化的拆分，已經穩定的在生產線上運行了幾個月，在此感謝螞蟻金服 SOFAStack 的開源貢獻，同時也很是感謝 SOFAArk 開源維護者：善逝，在使用過程當中，SOFAStack 團隊提供了高效和專業的支持。

SOFAArk 源碼： https://gitee.com/sofastack/sofa-ark