作者：洛浩
小邁於 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 感興趣的同學，還可以點選此處檢視更多案例和文章。