微服務框架-基礎框架

對于微服務基礎框架可以看作是微服務治理架構的核心內容，包括了對微服務模塊的全生命周期管理能力，這個能力包括了微服務網關APP，DevOps，Docker和云集成，安全，負載均衡，服務注冊和發現等諸多能力。微服務基礎框架確實不是簡單的微服務網關，而是對整個微服務基礎環境的支撐和管控。

對于微服務基礎框架，建議參考InfoQ的一篇文章如下：

對于這篇文章的一些重點做如下一些說明：

第一種方案為集中式LB方案，對剛開始實施微服務架構時候仍然建議采用該方案，特別是有負載均衡硬件設備如F5，Array等，在加上硬件本身的HA，不會在LB上出現任何性能問題和可靠性問題。

對于第二種進程內LB方案是趨勢，當前微服務框架的主流方案，Netflix和Dubbo等均采用該方案，那這種時候服務注冊庫相當存粹，只是實時準確提供可用服務注冊列表和地址信息即可，但是這種方案我們可看到一般不會對調用的日志流進行審計和跟蹤。

第三種方案實際上是一種折中的方案，即在每個微服務節點都需要部署相對比較重的獨立進程外LB模塊，這種方案最大的問題仍然是在于整體基礎架構體系偏重同時后續維護工作量大。

2. 服務前端路由-微服務網關

此處核心能力即使微服務網關，不僅僅是實現服務代理和前端路由，還需要實現安全，限流，監控等擴展能力。可以看到對整個微服務環境的治理管控，微服務網關會起到重要作用，具體摘錄原文描述如下：

• 服務反向路由 ，網關要負責將外部請求反向路由到內部具體的微服務，這樣雖然企業內部是復雜的分布式微服務結構，但是外部系統從網關上看到的就像是一個統一的完整服務，網關屏蔽了后臺服務的復雜性，同時也屏蔽了后臺服務的升級和變化。
• 安全認證和防爬蟲 ，所有外部請求必須經過網關，網關可以集中對訪問進行安全控制，比如用戶認證和授權，同時還可以分析訪問模式實現防爬蟲功能，網關是連接企業內外系統的安全之門。
• 限流和容錯 ，在流量高峰期，網關可以限制流量，保護后臺系統不被大流量沖垮，在內部系統出現故障時，網關可以集中做容錯，保持外部良好的用戶體驗。
• 監控 ，網關可以集中監控訪問量，調用延遲，錯誤計數和訪問模式，為后端的性能優化或者擴容提供數據支持。日志，網關可以收集所有的訪問日志，進入后臺系統做進一步分析。
• 其它能力 ：實現線上引流，線上壓測，線上調試(Surgical debugging)，金絲雀測試(Canary Testing)，數據中心雙活(Active-Active HA)等高級功能。

要注意到在微服務架構里面的集群和負載功能其實有兩層，第一層是在微服務網關上面的分布式集群部署，可以減輕單個API GateWay節點的并發訪問壓力；另外一個是在微服務模塊上層的負載均衡部署，重點是實現在同一個微服務模塊集群部署后能夠進行負載均衡。

在講第一點服務注冊和發現的時候可以看到，對于LB是可以下沉到服務消費端的，那么在LB下移后對于微服務網關層的能力是否也可以完全下沉到微服務模塊節點（不管是進程內部署還是進程外部署），以實現完全意義上的去中心化分布式架構？

3. 服務容錯

該部分 主要還是講服務的限流和流量控制機制，而對于熔斷只是在發現問題和異常后所采用的操作 。對于服務容錯功能本身功能的重要性就在于，在復雜的微服務架構環境下，服務關聯和依賴相當多，當發生大量的服務異常調用的時候，極其容易引起雪崩效應，導致整個微服務環境完全崩潰。

對于服務的容錯，在考慮限流機制前，還可以考慮對服務進行分域，將不同域的服務單獨部署到不同的JVM容器中，這樣至少可以保證在A域的JVM完全崩潰的時候，不會影響到B，C等其它服務部署域。這個有點類似文章最佳實踐談到的 艙壁隔離模式(Bulkhead Isolation Pattern) 。

要實現服務的容錯管理i，首先要有實時的采集和統計服務運行數據，包括服務運行時間，次數等，這些是服務容錯，限流或容錯策略計算的基礎。

對于服務容錯需要分幾個層面來談：

首先來說是服務限流，即當出現超出預設的大并發服務調用的時候，直接在網關處控制服務的流入速度，即讓消費方調用在外面等待和排隊，然后慢慢的放進來，當然如果調用再大則會引起服務調用超時。注意這是服務消費方調用超時，而不是原始服務提供方，這種超時網關是不清楚的。

其次即開始不限流，服務全部放進來，但是服務提供方可能處理不過來大并發，這種情況下會出現服務超時調用，服務響應時間超過預設值，那么在這種情況下就啟動服務限流，控制流入速度。注意在服務限流后可能仍然無法解決服務超時或響應慢的問題。那么這個時候就必須進行服務熔斷處理，即禁止對該服務所有訪問。對于文中也談到了熔斷的彈性恢復機制，這也是一個相當關鍵的內容。

對于服務流量控制本身也有多個層級，可以針對所有服務，一個域的所有服務，單個服務都可以。即對服務調用總量或單個服務并發量都能夠進行靈活的限流規則定義，以確保整個微服務架構基礎環境的穩定性。

Netflix將上述容錯模式和最佳實踐集成到一個稱為Hystrix的開源組件中，凡是需要容錯的依賴點(服務，緩存，數據庫訪問等)，開發人員只需要將調用封裝在Hystrix Command里頭，則相關調用就自動置于Hystrix的彈性容錯保護之下。Hystrix組件已經在Netflix經過多年運維驗證，是Netflix微服務平臺穩定性和彈性的基石，正逐漸被社區接受為標準容錯組件。

4.Netflix的微服務框架

在原來談SOA和ESB的時候，我們一般會談兩個內容，即ESB服務總線和基于ESB總線的SOA管控和治理平臺。而對應到微服務框架也一樣的道理：

其一是：微服務網關(服務注冊發現，代理路由，安全，限流，日志，監控）

注意在這里我還是將服務注冊發現，日志等能力統一劃歸到一個完整的微服務網關應該具備的能力，雖然在實現中可能會分為多個子系統或組件，但是本身是屬于GateWay應該具備的能力。

Netflix是一家成功實踐微服務架構的互聯網公司，幾年前，Netflix就把它的幾乎整個微服務框架棧開源貢獻給了社區，這些框架和組件包括：

• Eureka: 服務注冊發現框架
• Zuul: 服務網關
• Karyon: 服務端框架
• Ribbon: 客戶端框架
• Hystrix: 服務容錯組件
• Archaius: 服務配置組件
• Servo: Metrics組件
• Blitz4j: 日志組件

下圖Fig 11展示了基于這些組件構建的一個微服務框架體系，來自recipes-rss。

Netflix的開源框架組件已經在Netflix的大規模分布式微服務環境中經過多年的生產實戰驗證，正逐步被社區接受為構造微服務框架的標準組件。Pivotal去年推出的Spring Cloud開源產品，主要是基于對Netflix開源組件的進一步封裝，方便Spring開發人員構建微服務基礎框架。

對于一些打算構建微服務框架體系的公司來說，充分利用或參考借鑒Netflix的開源微服務組件(或Spring Cloud)，在此基礎上進行必要的企業定制，無疑是通向微服務架構的捷徑。

 

 

來自：http://blog.sina.com.cn/s/blog_493a84550102wkna.html