前言
今年一直在做的事情就是成本優化，今天分享的是如何打造一個彈性可伸縮服務。
why？ 為什麼需要彈性伸縮？
一個網站，通常流量大小不是每時每刻都一樣，有高峰，有低谷，如果每時每刻都要保持能夠扛住高峰流量的機器數目，那麼成本會很高。一個誘人的想法就是根據流量大小自動調節機器的數量，這就需要我們開發彈性伸縮服務。
How？怎麼實作彈性伸縮？
我們公司使用的是阿裡的ECS，而它提供彈性伸縮組機器，按秒計費，可以随時申請随時釋放，它是我們能夠進行彈性伸縮的最基本條件。由于這個How内容較多，接下來就詳細說一下這個How如何實作。
彈性伸縮服務
這塊着實是做了不少的工作，前前後後經曆了大半年的時間，接下來一一詳述。
工作模式由“推”改“拉”
我們的彈性配置設定政策依賴實時的qps，需要實時的擷取流量大小，是以必須能夠在某個地方擷取目前請求的QPS，自然而然會想到使用消息隊列，我們可以使用隊列提供的接口，擷取某段時間内的qps，并根據速率調整我們的機器服務數，這涉及到服務的改造。由于我們的一些服務都是以RPC調用進行互動（即“推”模式），是以勢必要改造這些服務，使其主動從隊列中拉取消息并處理。如下圖所示。
服務拆分，機器降配
我們的計算服務使用的高配置機器（16核16G），而阿裡雲伸縮組的機器配置很低（最高配置4核，記憶體大小可調），是以一些計算型服務需要拆分，使其能夠在低配機器運作。如下圖，是我們做的一個拆分示意。
服務快速部署
由于需要随時增加和減少機器，這需要服務有快速部署上線和下線的能力，是以可以使用docker。具體使用方法本文不贅述。
日志收集
由于彈性伸縮服務随時上下線，但是日志不能扔。需要日志收集服務跟随業務服務一同部署，同樣可以利用docker，日志随時收走。
實時配置設定算法
完成了如上3個基本工作，接下來就好辦多了，我們設計一個彈性配置設定算法：根據隊列中進去的消息速率來決定機器數目。
每個服務都需要有一個配置檔案
[strategy]
#一個服務能夠扛多少qps
speed_ratio = 2.5
#部署一個服務大概需要多少秒
start_time = 300
#每次部署多少個，至少為1
incr_num = 2
#固定機器有多少個
persistence = 16
算法大緻流程：
- 取一段時間間隔内隊列中消息速率，假設為A。
- 擷取目前正在運作的服務數S。
- 計算目前已經啟動的服務（固定+彈性配置設定）能夠扛住的速率B（B=S*speed_ratio）。
- 假設隊列中速率波動幅度C（通過觀察流量波動寫死的固定值）。
- 如果A>B+C，則申請新機器，根據配置檔案，申請incr_num個機器，并部署服務。
- 如果A<B-C，則釋放機器，根據配置檔案，釋放incr_num個機器，并下線服務。
- 注意要保持至少persistence指定的機器數，這些機器不能釋放，它主要是應付平時低谷時的流量。
問題：
-
可不可以根據隊列中unack的數目來配置設定機器？
答案是不行。能夠唯一表示目前請求大小的名額隻有qps，而我們服務可以提前知道的隻有性能資料：即單台機器能扛多少qps，而不是單台機器能夠減少多少個unack。此外如果使用unack為配置設定名額，當服務出現bug，大面積當機時，unack累積非常快，會導緻算法配置設定無限多的機器，而此時解決問題的正解為：復原服務-查找bug-修正-上線，而不是配置設定更多的機器，因為新配置設定的機器部署的服務可能也會當機。
-
如何應對流量突增？
本算法主要應對正常情況下的機器配置設定，對于突增流量分為兩種情況。1：正常可預測的突增（比如淘寶雙11，雙12），這種情況下我們可以先提前準備好大量固定機器，然後把配置中的incr_num調的盡可能大，這樣隻要流量上漲，可以一次增加幾百台甚至上千台機器扛過突增流量。2：異常突增，這種情況對于各種部署方式的服務（即使随時随地保證扛過平時正常情況下的流量峰值）都可能造成危害，并不是隻有彈性配置設定的服務專有，這個時候的正解的是防攻擊、流量過濾、降級。
-
阿裡雲機器配置設定集中造成接口失敗
當短時間内頻繁調用阿裡雲的機器配置設定接口，會傳回錯誤資訊，造成配置設定失敗。解決方法為，調用加入時間間隔（比如每隔1s調用一次機器配置設定接口），并且進行失敗重試。
-
阿裡雲ECS啟動失敗
有的時候機器申請成功，但是啟動失敗，情況有兩種，1：啟動時間過長，2：根本啟動不起來。解決這兩種問題的方法為，嘗試啟動一段時間，超過一定時間（比如start_time）後果斷放棄，重新申請新機器，防止整個服務啟動過程過長跟不上qps的上漲速度。
總結
如今，彈性伸縮服務穩定運作半年有餘，節省了大概60%~70%的機器成本，加上前面兩個算法優化《我是如何利用跳表優化搜尋引擎的？》，《最長公共子序列與最小編輯距離-你有更快的算法麼？》，使得我們負責的服務機器成本下降了80%以上。這也導緻了阿裡雲的小夥伴對我們産生了質疑，懷疑我們正在逐漸把服務遷出阿裡雲，但是這真的是冤枉了我們，誰規定使用阿裡雲的ECS就不能對服務進行優化了。對于同樣使用雲ECS的小夥伴，可以考慮用彈性伸縮節省成本，這将是一件很有意思并且富有挑戰的事情。