小邁與 SAE 的合作中，整體研發效能有了極大的提升，彈性速度從分鐘級縮短到了妙級，新項目上線速度從天級縮短到了分鐘級。
作者：洛浩
小邁于 2015 年 1 月成立，是一家緻力以數字化領先為優勢，實作業務高品質自增長的移動網際網路科技公司。始終堅持以使用者價值為中心，以資料為驅動，為使用者開發豐富的工具應用、休閑遊戲、益智、運動等系列的移動應用。累計開發 400 餘款産品，累計使用者下載下傳安裝量破七億。而在未來三年内，小邁以成為全球領先開發者增長服務平台為願景及使命，希望通過标準化的産品和服務賦能，為開發者提供全鍊路解決方案，以技術+服務全方位保駕護航，助燃産品持續增長，幫助工具和休閑遊戲的開發者提升産品的成功率。
在小邁内部，實行扁平化的管理風格，每個業務團隊都可以獨立選擇采用更适合自己的技術棧和基礎架構，是以内部出現了 ECS，K8s，SAE（Serverless 應用引擎）三種不同計算平台共存的局面，而且都在跑微服務架構，不同的計算平台都有自己獨特的優勢和價值，而同樣也會面臨各自的挑戰，目前主要在使用 SAE 平台的主要是遊戲團隊。
為什麼選擇 SAE
對于大部分休閑類遊戲來講，首先遊戲本身存在自己的生命周期，而在生命周期内，遊戲本身會出現非常大的波峰波谷。比如，白天比晚上流量大的多，白天流量又集中在幾個時間點，而晚上 8 點是業務的最高峰，淩晨 2 點到 6 點幾乎沒有流量，但是又不能停服。另外，在遊戲剛上線的時候，每次營運活動又會拉來大量的新客戶湧入，就需要背景服務能夠快速響應流量的變化，是以業務方就期望能有一種自動彈性伸縮的計算平台。其次，大部分休閑類遊戲都是無狀态的，還可以拆分成不同的服務子產品來提升服務性能和品質，如聊天、紅包、背包、更新、使用者資料擷取、視訊處理、廣告投放等，是以就可以采用微服務架構來部署。最後遊戲在上線期間，也會疊代增加很多新的功能子產品，需要頻繁的釋出更新。是以業務方在選型的時候，就會綜合考慮：
- 系統的穩定性和容災能力
- 平台的自動彈性伸縮能力
- 對微服務架構的支援
- 便捷的釋出復原能力，甚至是不停服更新
這些能力，其實通過 ECS 或者 K8s 自建也都能實作，但是會給業務團隊帶來大量的運維成本，而且很難平衡成本的投入。尤其是在彈性方面，自建彈性效率很難滿足流量的快速變化，往往還是需要備援大量的資源。而 SAE 可以非常好的滿足以上 4 個需求。其實小邁的遊戲團隊早在 SAE 公測期間，就開始關注試用 SAE 了。截止到目前，在 SAE 上累計已經部署了 50 多個服務和應用，涉及十幾款遊戲，比如愛上猜成語、成語最強答人、我找茬賊快、答多多、歡樂找找茬、多多短視訊等，感興趣的話可以下載下傳 APP 試玩下。
SAE 落地實踐
Serverless 應用引擎 SAE 定位是容器之上的一站式應用托管平台，核心價值是給使用者提供全應用生命周期管理、微服務治理、彈性免運維的 K8s 運作環境。本質上，使用者的代碼最終還是運作在容器裡，隻是這個容器不用去維護管理。是以對于存量的遊戲服務來講，可以零改造直接遷移部署到 SAE 上。而且 SAE 針對 JAVA 應用，還提供了 JAR 包直接部署的模式，省去了小邁打鏡像的步驟，和原有使用 ECS 的模式非常接近，但是使用體驗上會更加簡單，大概的對比如下：
SAE 比較核心的能力就是高可用和自動彈性，對于小邁的遊戲團隊，在部署 JAR 包的時候可以勾選多可用區，就能達到跨可用區的容災。SAE 底層其實是會提供多個分布在不同可用區的 K8s 叢集，承載業務的容器執行個體可以在多可用區自動排程。對于彈性的配置同樣也非常簡單，可以基于 CPU、記憶體、QPS、RT 等名額來進行設定，對于小邁的線上遊戲，主要還是通過CPU和記憶體的使用率來觸發擴縮，同時還能指定最大執行個體數和最小執行個體數，非常的便捷。而且目前定時彈性和監控名額彈性還可以混用，那麼對于有營運活動時，就可以通過兩種彈性方式共同使用的方式，來確定資源的彈性。但是這裡需要注意的是監控名額的門檻值，需要根據業務的實際情況來配置，建議上線前，通過壓測來明确。
另外通過應用監控，也能非常友善的檢視到服務接口的調用情況，這些能力都已經預設內建到了 SAE 的平台上，對業務排障很有幫助。
最後在小邁的遊戲團隊，主要采用的是 Spring Cloud 和 Dubbo 技術棧，是以對微服務治理能力的支援，也是非常必要的。目前 SAE 的控制台上，可以直接配置微服務的健康檢查、優雅下線腳本、配置管理、微服務的灰階釋出、一鍵復原等。但是在實際使用的過程，也踩過一些坑，比如在做服務釋出的時候，健康檢查有時候會逾時導緻執行個體不停重新開機，因為有時候服務會加載大量的資料和類庫，啟動比較耗時。加大健康檢查的逾時時間可以降低出現機率，但是釋出時間就會拉長。而且在服務剛啟動的時候，初始響應比較慢，其實是服務還沒有完全 ready，這裡就比較依賴 SAE 提供微服務優雅上線的能力，可以確定服務的正常上線。另外對于分批發部，為了避免負載的流量突然打到新執行個體，這裡比較推薦使用微服務流量百分比灰階能力。經過一段時間的實踐，最後落地的業務架構大緻如下：
小邁的遊戲團隊基本隻用關注業務邏輯，資源層面托管給了 SAE 平台，極大的簡化了運維複雜度。另外為了應對業務的快速疊代，小邁還采用 Jenkins 封裝了 SAE 的 API 接口，實作了 CI/CD 能力，極大加速了服務的上線速度。對比原來的彈性效率和部署效率，整體研發效能有了極大的提升，彈性速度從分鐘級縮短到了妙級，新項目上線速度從天級縮短到了分鐘級。
總結和展望
1、SAE 在微服務領域提供了 Serverless 化的運作平台，給使用者提供了降本增效的新選擇。另外 SAE 底層采用的是托管的 K8s 叢集，也給使用者做容器化轉型提供了最簡單的方式。
2、SAE 在應用管理和微服務治理方面的加成，使得 SAE 成為有别于容器服務的一站式應用 PAAS 平台，讓使用者可以專注在業務疊代。
3、針對應用的管理，SAE 還提供了環境“一鍵啟停”功能，比如針對開發測試環境，可以設定定時關閉和開啟，優化非線上環境的資源占用，可以幫助小邁進一步優化費用。
4、針對 JAVA 應用，SAE 提供了 DragonWell JDK 版本，可以加速 JAVA 應用的啟動速度和線程資源的消耗，啟動速度大約可以節省 40% 的耗時。
5、未來，SAE 還會不斷提升彈性效率、加強應用管理層面的功能疊代，期望給使用者帶來更多的增值體驗，比如剛釋出支援 PHP 的 ZIP 包部署能力，可以簡化 WEB 應用上雲的複雜度。
對 Serverless 感興趣的同學，還可以點選此處檢視更多案例和文章。