通過對權益玩法平臺現有業務應用的Serverless化改造，權益團隊在雙十一期間完美地支撐了業務需求，在研發效率、運維保障等方面都體現出了很高的價值和收益。
項目背景
淘寶權益平臺是負責淘寶權益營銷的核心團隊，團隊除了負責拉菲權益平臺外，也越來越多地承接營銷IP和輕互動營銷等需求，這類需求除了內容上非常多樣外、交付上也是又多又急，對技術的挑戰性非常大。有別于平臺型應用，營銷IP類需求對業務模型和架構的要求相對不高，但是對開發產研的效率要求非常高，所以我們急需一套可靠的產研體系去支撐營銷IP和輕互動的需求。
權益玩法平臺就是在這樣的背景下誕生的，其設計目標是通過對營銷和玩法通用能力的沉淀和復用，構建出一整套營銷玩法能力體系，來降低業務需求的開發成本，提升業務的交付效率。
基于Ring容器化的嘗試
為了實現既定的設計目標，權益玩法平臺一開始設計了基于Ring容器化能力的方案，Ring是由我們團隊自研開發的JVM容器化框架，支持對業務能力進行動態加載，其核心特點是JVM熱部署和機器按需部署。Ring框架由一個宿主應用和多個業務容器組成，宿主應用提供整體的基礎能力和共享能力，不同業務擴展由各自的容器(farjar載體)實現，通過控制不同的宿主應用分組掛載不同的業務jar包實現業務的隔離效果。借助Ring框架的熱部署能力，可以實現秒級部署能力，效率上有極大的優勢。
基于機器分組的業務隔離能力：
基于基座應用和容器應用的產研隔離和熱部署機制：
平臺開發同學負責基座應用基礎服務和共享服務的開發和運維
業務開發同學專注于業務邏輯開發，基于熱加載能力部署到基座應用
???權益玩法平臺基于Ring的業務形態
權益玩法平臺在Ring的支持下，在同一應用內，實現了對核心業務的獨立部署和對非核心業務混部方案，既滿足了核心業務的穩定性要求，又節省了整體業務的維護成本和資源成本。
???Ring架構的優點
效率高：
由平臺提供中間件和通用服務支持，降低了業務開發成本；
支持熱部署發布，開發和交付效率高；
隔離性好：
基于機器分組的強隔離能力保障業務和流量隔離；
???Ring架構的不足
Ring框架本身是為業務擴展設計的，但權益玩法平臺多個業務間并非擴展關系，所以來說Ring并不是最佳的使用場景，使用上也存在系統權限、產研角色等一定的局限性；
為支持熱部署，Ring框架在應用底層框架上做了很多的改造和定制，除了潛在的內存泄漏等風險外，這些需要業務開發時進行感知的特殊邏輯，也無形中提高了開發和運維的門檻和成本；
???小結
基于Ring架構的權益玩法平臺應用已經能很好的支持業務發展，但同時也存在一些的不足和問題。為更好的支持業務發展，我們也在不斷探索更好的架構和產研模式。也在這個過程中，剛好遇到Serverless的大范圍推廣，在經過調研和比較之后，我們決定擁抱Serverless重構我們的產研體系。
初識Serverless
Serverless是個相對比較廣義的概念，從不同的角度可以有不同的解釋。從我的粗淺的理解來說，Serverless可以簡單認為是一種將應用與基礎設施進行分離的架構理念，通過指導軟件架構和職責分工，使開發者更聚焦在業務邏輯，從而減少對基礎設施的關注，其核心要素是架構分層和產研分工：
從計算機發展的角度看，分層一直是永恒的話題，操作系統分層、網絡分層、文件系統分層，分層讓更多的底層實現得以屏蔽，讓上層使用者只需要通過簡單的API即可使用計算機復雜的能力，在這一過程中，分層變得越來越多、分工也變得越來越細，除了操作系統層面的分層，我們也看到了云服務提供了計算資源的分層，中間件提供了基礎服務的分層，Serverless更進一步提供了業務運行時的分層。有了Serverless，業務開發者不用再關心中間件、機器資源、jvm容器，只需要把業務代碼寫好，剩下的都交給Serverless。
Serverless的設計目標
免運維：應用的運維工作將由Serverless的服務提供方負責，普通業務開發人員不用再關注機器部署、擴縮容等運維的事情；
更低成本：借助彈性能力，Serverless會根據應用負載動態進行擴縮容以滿足業務的實際需求，避免了資源的浪費情況；
快速交付：從普通應用發布要重啟整個jvm容器、中間件相比，Serverless發布粒度可以控制在單純業務代碼維度（業務函數），可以獲得極致的發布效率體驗；
統一架構：所有的基礎能力都由Serverless基座負責，所以JDK的升級、中間件升級、通用二方包版本維護等不再需要推動每個業務去升級，只需要由專人通過Serverless基座即可完成業務無感升級；
Serverless應用解構
相較于傳統應用，Serverless應用對于我們認知中的研發體系挑戰還是比較大的，Serverless的整個設計和運作體系都和傳統應用發生了很大的變化，這對于技術研發同學來說，了解這其中的原理和思路是必不可少的。所以我試圖從一個傳統應用出發，通過逐步解構整個過程，粗淺的介紹下Serverless是怎么實現和運作的：
第一層. 普通應用：
我們一般的普通應用都由Pandora容器(隔離容器)加載，其中包括了中間件和業務自己的spring容器
第二層. 業務邏輯拆解
我們日常開發的代碼中，除了業務本身的代碼，肯定也包括很多通用的代碼邏輯，比如對商品、人群等服務的封裝和調用，這些大多數應用都會用到的邏輯，我們卻一直在多個應用間不斷地重復編寫這些代碼。
第三層. 業務容器分層
通過區分業務代碼和通用代碼，我們可以進一步對業務的Spring容器進行拆分，區分成通用Spring容器和業務Spring容器，進而就分別控制不同業務容器的加載和銷毀。
第四層. Serverless化
通過將業務能力和通用能力分層之后，就可以進一步形成以基座應用和業務應用為概念的獨立產品和部署體系，從功能、產研和運維體系上進行了徹底的隔離和分工。
Serverless的產研和交付形式
Serverless對于業務最大的影響就是對原有產研體系的革命，一方面出現了專門的分工人員專職負責Serverless基座的開發和運維角色，另一方面，普通的業務開發不再需要關注機器容器、jvm和中間件等服務，更專注于業務需求實現和交付：
傳統應用交付形式：研發負責整個Docker容器內的所有東西
Serverless的全新產研分工：職責分工，專業的人做自己最專業的事情
Serverless的全新應用交付形式：分層獨立交付
Serverless全新部署體驗
除了能力分層和產研分工，Serverless帶來的還有一個重點特性就是飛一般的部署速度。以往可能需要五~十分鐘才能完成的部署，Serverless縮短到了一分鐘以內，真正讓日常的開發體驗朝著所寫即所得更進一步。
要了解Serverless部署快在哪里，我們要從普通的應用部署流程說起，看看我們平時的部署都慢在哪里：
上面是我們一個普通應用第一次新部署和更新部署的核心節點，鏡像構建、中間件及基礎服務啟動都是耗費了大量時間，而且為了保障服務不中斷，我們還要考慮分批部署，將原本已經很長的部署時長Double了一下。
為了解決部署耗時的問題，Serverless設計了一套更高效和敏捷的部署體系，其中通過多種機制加速了我們的整個部署流程：
免業務鏡像構建：
在Serverless體系下，每次業務交付的只剩下業務代碼，已無感知Docker容器，自然也就沒了鏡像構建的必要，鏡像的管理統一交由Serverless基座負責，而且基座內也只會包含中間件和通用業務功能等不頻繁更新的內容，業務的變更內容將通過獨立的fatjar形式動態加載到運行容器中。
緩存服務容器：
在鏡像標準化的前提下，鏡像的加載和啟動就不用再依賴于業務本身的變更發布，在業務發布使用之前，機器就可以提前把Docker、JVM、中間件、Spring容器、通用服務等加載和啟動起來，并統一緩存到容器緩存池中，業務真正使用的時候只需要拉取已初始完成的容器加載業務代碼，并完成流量切換就可以提供服務。
滾動發布：
在普通情況下，為了保證服務不中斷，我們至少需要提供兩臺服務機器，發布的時候還需要分兩批平滑發布，除了部署很耗時，測試和調試也是很麻煩。有了Serverless，在預發環境等測試環境我們就可以只部署一臺機器，發布的時候，Serverless會從緩存容器中拉起一臺新的容器進行加載，在完成快速啟動后，進行流量切換就完成了平滑部署，真正讓部署起飛。
通過總結以上幾個核心的機制，Serverless讓一個環境的新部署和更新部署變更非常簡單和高效：
Serverless插件-通用能力下沉的利器
在Serverless基座中，除了中間件等基礎能力外，更重要的是要承載業務通用能力下沉的重任。一方面，每個業務應用基本都會涉及到需要去對接商品、賬號、人群等二方服務，其中有些服務會存在文檔不全面、依賴臃腫、協議不規范等問題，極大影響了業務開發的質量和效率；另一方面，業務自身也有很多需要復用的業務邏輯，如何快速共享和接入、統一升級和維護也是大家一直來苦惱的問題。對于業務來說，非常需要那么一個解決方案，既能簡單可靠成本低，又能滿足以下所有的能力復用訴求：
類隔離機制：
不同二方依賴和模塊間通過類隔離來解決模塊間類沖突問題，同時解耦單模塊升級對其他模塊的影響來保障穩定性；
可控類導出機制：
類隔離機制解決了不同模塊之間的類沖突問題，但業務通用模塊的存在核心還是給上層頁面提供服務，模塊和業務之間不可避免需要通信機制（如進程間通信常用到的socket通信），這就需要可控的類導出機制，控制只導出必要的接口類或者API接口等方式，既要實現通信能力，又要避免了通信模塊和業務代碼之間的類沖突問題和依賴升級問題；
生命周期管理機制：
如果共享的業務模塊涉及到更復雜的邏輯，就會出現一個模塊內不同功能在何時啟動和初始化的問題。尤其是在Serverless存在容器緩存機制的情況下，就必然需要生命周期管理機制來控制不同邏輯的初始化和銷毀動作，比如在容器緩存時初始化無副作用的邏輯，而在真正使用時再把有其余的功能進行初始化，以滿足不同業務的多樣化訴求；
統一升級維護能力：
類似于二方包這樣的共享方案，統一升級維護一直是個大難題，聯系人幫忙升級也是常事，所以在Serverless體系下，這也是必然要考慮和解決的問題；
Serverless插件就是給這些問題提出的一個完美解決方案：
繼承自Pandora的優秀類隔離機制：每個插件獨享自己的ClassLoader，多個插件之間依賴互不影響，可以獨立升級和切換而不影響其他插件和業務本身；
多粒度的類導出能力：可以將類的導出控制在最小粒度，在提供服務的前提下將對業務應用的影響控制在最低水平，也最大幅度降低了插件的修改升級對業務潛在的影響和風險；
完善的生命周期管理：滿足不同插件在不同階段執行自定義邏輯的需求，豐富了Serverless插件的使用場景和想象空間；
統一的管理和運維能力：借助Serverless的統一基座服務，Serverless插件將由基座維護者統一進行維護，插件的升級等問題都將真正做到業務無感，所有業務應用都可以享受到最新最全的插件帶來的業務效率大提升。
Serverless的優勢小結
通過對Serverless的初步了解和研究，我們也總結出了Serverless的幾個核心優勢，這些優勢也成了我們決定全面擁抱Serverless的關鍵：
高效的產研效率：
深度集成公司產研體系，應用管理和運維成本都非常低；
業務開發無需感知和管理中間件和Docker等邏輯，業務開發成本明顯降低；
基于滾動發布和容器緩存機制，實現了比肩于熱部署的發布效率；
完善的隔離和插件機制：
完善的類隔離和導出機制，在二方包隔離、插件隔離、沖突規避等方面可以發揮很大的作用；
通過插件機制，可以方便地實現業務代碼的共享和復用，實現業務能力的有效沉淀
開放的插件生命周期擴展能力，給業務提供了非常大的創造和想象空間；
運維成本低：
統一維護的Docker、中間件、JDK、依賴包等能力，讓應用的基礎升級維護變得簡單；
基于彈性和緩存機器資源池能力的快速動態擴縮容能力，將會降低業務的維護成本；
權益玩法平臺的Serverless實現
權益玩法平臺在經歷了以Ring為基礎的運行模式之后，我們開始了全面擁抱Serverless的腳步：
創建了統一的權益玩法平臺基座，有權益團隊統一維護升級，服務于所有的權益玩法平臺Serverless應用集；
針對常用的賬號、商品、人群等二方服務，統一通過Serverless插件進行了封裝，業務應用可以開箱即用；
針對中間件、日志等服務則進行了二次插件封裝，以降低業務的上手成本和使用成本；
同時基于業務擴展型的業務應用，我們通過平臺能力下沉、業務擴展Serverless接入的方式來滿足平臺管控和業務隔離的雙向需求：
成果和收益
通過對權益玩法平臺現有業務應用的Serverless化改造，權益團隊在雙十一期間完美地支撐了業務需求，在研發效率、運維保障等方面都體現出了很高的價值和收益：
得益于簡化的業務研發流程和豐富的插件支持、業務的部署和交付周期相比于之前減少30%，開發成本大幅降低，業務開發效率提升顯著；
得益于部署流程優化、容器緩存機制和滾動部署加速，部署時長減少80%，極大縮短了需求交付周期；
成果和收益
Serverless作為公認的未來軟件產研體系方向之一，我們也必將持續推進現有業務的Serverless改造，也期望Serverless能給我們的業務技術帶來更多的創新力和想象力；
Serverless作為最新的產研體系，也必然存在著各種問題和挑戰，作為使用Serverless的業務之一，我們也是見證了Serverless從初期問題頻出到最終完美表現雙十一的過程，也期待Serverless能進一步升級優化，提供更強大的能力，助力業務發展。
團隊介紹
我們是大淘寶技術權益營銷技術團隊，是一支以權益優惠為核心的專業營銷團隊。我們肩負著支撐天貓淘寶雙11、618、雙十二等大促和各類權益營銷活動的使命，是全集團權益營銷策略執行和用戶優惠觸達的主陣地。團隊構建了以權益平臺為核心、權益玩法和互動相結合的完善權益營銷技術體系，實現百萬級的業務峰值流量支撐和億級規模的權益發放能力，為業務打造出覆蓋幾億消費者、千萬商家的全方位營銷解決方案，不斷支撐業務創新的持續發展，成就更高的商業價值。
¤?拓展閱讀?¤
3DXR技術?|?終端技術?|?音視頻技術
服務端技術?|?技術質量?|?數據算法
