微服務架構的雲端應用

什麼是微服務架構

微服務架構（Microservices Architecture）是將應用拆分紅小業務單元進行開發和部署，使用輕量級協議通訊，經過協同工做實現應用邏輯的架構模式。

靈活、穩定、省資源是微服務架構的主要優勢——

• 可獨立部署、升級、替換、伸縮
• 自由選擇開發語言
• 高效利用資源
• 故障隔離

服務多、管理難度大是微服務架構的不足之處——

• 服務多，帶來更多操做
• 管理複雜度提高
• 部署難度加大

但整體來講，微服務架構是很是吸引人的，不然也不會獲得像Twitter、Netflix、Amazon、eBay等知名大廠的青睞。

微服務架構模式

微服務架構模式主要可分爲：

• 聚合模式
• 代理模式
• 資源共享模式
• 異步消息模式

聚合模式

聚合模式即多個服務聚合到一個服務，稱之爲聚合服務。聚合服務最多見的表現是Web服務，主要功能爲頁面表現，後端服務爲純業務功能服務。也就是說，聚合模式下擴展業務只需增長一個新的後端微服務便可。

聚合服務符合DRY原則，能夠是一個更高層次的組合微服務，增長業務邏輯後進一步發佈成一個新的微服務，同時每一個服務都有本身的緩存和數據庫。

聚合模式是微服務架構中最經常使用的模式。

代理模式

代理模式是一種特殊的聚合模式，即對外將服務統一包裝。代理模式能夠僅僅委派請求，也能夠進行數據轉換工做。

咱們能夠將代理模式比作經過收發室統一收發信件的小區，不管是外部請求仍是內部數據服務，均由代理處理。

資源共享模式

微服務架構的資源共享模式可實現部分業務的邏輯分離、數據共享。

資源共享模式經常使用在「一體化架構」向「微服務架構」遷移的過渡階段，以及有數據一致性要求的兩個服務。

異步消息模式

微服務架構的異步消息模式適用於不須要同步的場景，如任務型服務，利用消息隊列代替其餘微服務架構模式所採用的REST請求及響應。

微服務架構帶來的挑戰

1. 服務部署的挑戰

   每一個服務都須要獨立的代碼管理、版本管理、編譯構建、測試環境部署、生產環境部署、代碼回滾等，人工管理大量微服務幾乎是一個不可能完成的任務。

2. 服務紳縮的挑戰

   無狀態服務須要配置負載均衡和增長節點，有狀態服務須要擴充單個服務的資源。爲了減小資源浪費，開發者須要監控每一個服務，並在必要的時候減小節點和資源。

3. 服務高可用的挑戰

   每種服務的高可用策略都不同，這其中無狀態服務的管理相對簡單，而每一個有狀態服務的管理則是一個難題。

4. 服務容錯的挑戰

   任何一個服務的可用性都不是100%的，在分佈式系統中，當某個依賴服務不可用時，系統自身也將不能工做。尤爲是依賴大量服務的複雜的分佈式系統，以來服務的可用性加上網絡不穩定的因素，系統自身的可用性極可能沒法獲得使人滿意的保障。

5. 依賴關係的挑戰

   若是將依賴配置文件寫在代碼中，須要從新部署才能生效，而配置文件還可能會污染代碼。

6. 服務監控的挑戰

   監控CPU仍是負載？大量微服務的出現也是對服務監控的嚴峻考驗。

好雨的微服務架構解決方案

好雨的微服務架構解決方案(www.goodrain.com)核心思路爲——

• 簡化用戶操做
• 微服務內部封裝、總體對外
• 包裝技術、服務業務

好雨雲底層是經過Docker實現，並儘量作到讓用戶感覺不到Docker的使用體驗。在好雨雲，複雜特性被包裝在了內部，經過服務總體對外，用戶無需管理計算資源和網絡資源。

服務部署

好雨雲支持Java、Python、PHP、Ruby、Golang,Node.JS等主流開發語言，並支持Github、好雨託管倉庫等代碼倉庫。

服務伸縮

好雨雲支持服務伸縮，其中水平伸縮用於無狀態的Server和Worker類服務，垂直伸縮用於有狀態的服務。

部分有狀態服務支持水平分區（Sharding），用戶只須要調整節點個數就能夠了。

服務高可用

好雨雲經過高可用調度器，使無狀態服務、有狀態服務具有高可用特性。

依賴關係

好雨雲的依賴關係解決方案相似於Spring的依賴注入，參數經過環境變量實現，調整服務的依賴關係只須要界面點擊便可完成。

服務容錯

好雨雲的服務容錯原理相似於保險絲，當某一服務變慢，達到斷路器的閥值，該服務將自動下線，不至於影響其餘服務，而當延遲變小時，該服務逐步恢復。

使用異步也能夠達到服務容錯的效果，具體可參考CQRS模式。

服務監控

好雨雲將平均響應時間、吞吐率、在線人數等業務指標用於服務監控。

用業務監控替代技術監控，實際場景中的服務監控得以變得簡單而易於理解。

實時性能分析

最慢的SQL語句不必定是對數據庫影響最大的，好雨雲的實時性能分析經過CEP＋log實現，從實際出發解決問題，開發者能夠很直觀的瞭解當前對系統影響最大的URL是哪一個。