ADmobile借助阿裡雲提供的彈性伸縮組，通過設定自定義監控名額進行彈性的擴縮容，應對廣告業務的激增流量。
12月21日，在阿裡雲彈性計算年度峰會上，ADmobile首席架構師王威發表了《ADmobile廣告業務雲上彈性計算最佳實踐》的演講，介紹了ADmobile業務雲上最佳實踐。
【圖：ADmobile首席架構師王威】
本文主要根據王威的演講整理而成，内容分為四部分：
- 業務背景介紹；
- 業務發展中的技術痛點；
- 解決方案；
- 實踐經驗。
01 ADmobile（艾狄墨搏）業務背景介紹
ADmobile是一家程式化的廣告聚合SaaS服務商，通過自主研發的廣告聚合管理系統，整合流量管理、UR工具，為APP廣告變現提升收益。通過一站式廣告聚合平台，ADmobile提供專業多元度的資料報表，還有聚合管理、靈活的營運方式和多樣靈活的優化工具。
上圖可以看到，ADmobile業務發展中服務資源的變化：從最早期就是一台伺服器、一個資料庫支撐我們業務發展，到現在有200台以上的伺服器，還有資料庫、中間件、負載均衡等一系列雲資源。業務高峰的時候，ECS數量一度達到400台，甚至曾經超過500台；業務高速發展的同時，流量也在激增，對于技術和運維都是一種極大的挑戰。
02 ADmobile業務發展中的三大技術痛點
在早期的方案當中，對于流量峰值的變化，基本無法靈活應對，隻能通過部署伺服器去應對流量波動。一些特殊的日子，例如618、雙11的大促期間，流量會出現爆發式增長，這需要技術人員提前準備足量的伺服器，應對流量的激增，保證我們業務能夠平穩運作。
早期部署方式也比較傳統，即在一台指定的伺服器上，把我們的項目營運好，制定一些相應的啟動腳本來生成ECS鏡像，通過批量的建立ECS來保證服務正常運作。
早期的技術架構看上去很簡單，總共隻有3個服務，這是我們線上營運的業務。通過負載均衡進入服務A，通過服務發現調用B和C，整體三個服務支撐了我們現在的一大塊業務。這個技術架構中，所有的伺服器都是固定的，是以無法根據流量變化去實時動态調節伺服器資源，是以造成了伺服器資源很大的備援和浪費。
服務資源備援、突發大流量的應對困難、鏡像生成非常耗時（基本上需要數十分鐘甚至小時級别），這三個技術痛點導緻很難應對業務實時的變化釋出。
03 我們的解決方案
目前，ADmobile選擇了增加了彈性伺服器組，釋出方式上采用了ECS自動同步最新服務，并采用了Jenkins+K8s的一鍵部署。在一台伺服器上把服務部署好，其他的伺服器會定時同步最新的服務，并重新啟動服務，這樣避免了重新生成ECS鏡像，可以實作更加靈活的釋出。
上圖是我們技術架構中的一個，相比早期的架構可以明顯地看到多了一個彈性伸縮組。彈性伸縮組的存在，既避免了伺服器資源很大的備援和浪費，又能更好地應對一些大量流量的突增業務。在彈性伸縮組裡面還可以通過部署一部分搶占式執行個體，來進一步降低伺服器成本。
這是另一個業務架構，它是基于K8s搭建的，現在比較流行通用的架構，分為資料層、服務層、網關層和展示層。
1. 資料層，可能包括資料庫MySQL、緩存Redis、對象存儲OSS等。
2. 服務層，以K8s為核心，包括我們自己搭建的Kubernetes，隻有在進行釋出的時候才會占用一些資源，不釋出的時候基本上不占用資源。
3. 網關層，主要是通過負載均衡對外提供服務，目前在嘗試将服務網格應用到業務中，還處于測試階段，接下來如果測試穩定，可能就會把負載均衡全部切到服務網格上。
4. 展示層，包括PC端、移動端、小程式等。在這種架構中間，還使用了阿裡雲的平台服務，像注冊中心、日志記錄等服務穿插在整個業務的所有過程中。
以下介紹我們在實際工作中遇到的常見問題及解決方案。
1、如何應對流量激增
這是很多業務運作過程中都會碰到的問題，流量激增可以分為兩類：一類是可預測的流量，例如，早高峰或者晚高峰由于使用者量的增加導緻流量激增，這種可預測的流量激增，可以定時的擴容的政策來保證業務運作；另一類是不可預測的流量，一般可以通過API或者SDK方式自定義監控名額，借用阿裡雲的接口提前進行擴容，即根據名額的波動、變化進行相應的擴容或者縮容。實作方式是根據自己的業務結合阿裡雲的SDK 、API相應的腳本進行編寫。
2、如何選擇監控名額
伸縮容過程中的一些監控名額，例如平均負載、CPU使用率、記憶體使用率、網絡流量、磁盤IO等，可以根據不同的應用類型來選擇不同的監控名額。以JAVA應用為例，它是比較占用記憶體的，當記憶體占比到70%-80%，它的CPU占用可能還很小；如果我們監控它的CPU使用率，盡管CPU占用處于正常範圍，而記憶體可能已經用到90%或者更高，這種監控名額的選擇是不太恰當的，我們應該根據不同的應用靈活地選擇監控名額。
3、如何選擇擴容和縮容的名額值
這個主要是指阿裡雲彈性伸縮組的擴容和縮容的名額值。根據我們的實踐，不建議設定相等值，例如，當CPU使用率大于50%的時候進行擴容，CPU使用率小于50%的時候進行縮容。這是因為擴容或者縮容都有冷卻時間，如果CPU的使用率就在50%左右上下波動，可能最終導緻我們的擴容或者縮容的目的無法實作。
04 四大實踐經驗總結
我們總結的實踐經驗有4點：
第一，不要把所有的ECS都交給彈性伸縮組來控制。因為彈性伸縮組是比較靈活的，如果我們設定的名額不太嚴格，可能導緻ECS出現無序的擴容，或者出現ECS數量變成零等異常情況，進而對業務造成影響。
第二，彈性伸縮組裡面設定合适的執行個體上限。這個和第一個類似，如果不設定上限或者上限值設定的不合理，可能會導緻無序擴容，應用異常或者監控名額持續上升，最終導緻伺服器數量異常，對成本帶來負擔。
第三，部署适當比例的搶占式執行個體。搶占式執行個體的折扣在活動中可能低到1折，如果業務結構合适，通過配置設定一定比例的搶占式執行個體，可以有效地降低成本。
第四，善用雲上運維自動化服務。阿裡雲提供了很多好用的工具，例如使用ECS雲助手，可以對伺服器進行批量的漏洞修複或者軟體更新。
最後，分享一個彈性伸縮組的案例。在上圖中，最高峰的時候，ECS數量應該有45台，最低的時候有10台，并且最低10台的時候我們做了一定的備援處理。如果放開限制，ECS數量會變得更少，通過這樣的部署方案，經過測算，成本總共降低了約30%。
點選大會官網，觀看王威的精彩演講視訊。