今年一直在做的事情就是成本優化，今天分享的是如何打造乙個彈性可伸縮服務。
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
問題：
Spring Cloud 微服務實戰筆記
傳統開發所有業務邏輯都在乙個應用中,開發，測試，部署隨著需求增加會不斷為單個專案增加不同業務模組 前端展現也不侷限於html檢視模板的形式,後端向前端支援需要更多的介面模組。隨著需求增多，專案變大，單體系統部署在乙個程序內部，往往修改很小的功能，為了部署上線也會影響其他功能。後期維護成本會變得越來越...
《Spring Cloud微服務實戰》開始預售
京東 亞馬遜已全面開啟預售！快來一起體驗spring cloud所帶來的全家桶式微服務架構解決方案！掃一掃前往京東購買 為什麼選擇spring cloud spring cloud簡介 版本說明 配置詳解 監控與管理 小結eureka詳解 原始碼分析 配置詳解 服務例項類配置 元資料 跨平台支援 原...
微服務實戰經驗分享
在過去的幾個月裡，我們已經聽到很多關於微服務的優缺點了。微服務真的只是soa嗎?微服務確實有助於進行複雜系統架構嗎？不論大家怎麼說，有一些公司已經轉向或正準備轉向基於微服務的方法了。他們在實踐過程中分享自己獲得的正面或負面的經驗，是很自然的事。最近，droplet公司的tom livesey分享了他...