深刻理解分析微服務(下)

深刻理解分析微服務(下)

噹噹噹當~~下半部分來咯，直接進入主題把，你們也能夠關注個人微信公衆號 Java周某人，能夠免費領取一些大廠面試資料

服務框架和治理

微服務不少的時候，就須要有治理了。一個好的微服務框架通常分爲如下14個部分。以下圖所示。這就是開篇所說的，微服務涉及的東西不少，有些初創公司和業務不成熟的產品是不太適合的，成本比較高。

目前國內比較好的微服務框架就是阿里巴巴的DUBBO了,國外的就是spring cloud,你們能夠去研究一下.

監控體系

監控是微服務治理的重要環節。通常分爲如下四層。以下圖所示。

監控的內容分爲五個部分：日誌監控，Metrics監控（服務調用狀況），調用鏈監控，告警系統和健康檢查。

日誌監控，國內經常使用的就是ELK+KAFKA來實現。健康檢查和Metrics，像spring boot會自帶。Nagios也是一個很好的開源監控框架。

Trace調用鏈監控

調用鏈監控是用來追蹤微服務以前依賴的路徑和問題定位。例如阿里的鷹眼系統。主要原理就是子節點會記錄父節點的id信息。

下圖是目前比較流行的調用鏈監控框架。

微服務的限流熔斷

假設服務A依賴服務B和服務C，而B服務和C服務有可能繼續依賴其餘的服務，繼續下去會使得調用鏈路過長。若是在A的鏈路上某個或幾個被調用的子服務不可用或延遲較高，則會致使調用A服務的請求被堵住，堵住的請求會消耗佔用掉系統的線程、io等資源，當該類請求愈來愈多，佔用的計算機資源愈來愈多的時候，會致使系統瓶頸出現，形成其餘的請求一樣不可用，最終致使業務系統崩潰。

通常狀況對於服務依賴的保護主要有兩種方式：熔斷和限流。目前最流行的就是Hystrix的熔斷框架。

下圖是Hystrix的斷路器原理圖：

限流方式能夠採用zuul的API限流方法。

Docker 容器部署技術&持續交付流水線

隨着微服務的流行，容器技術也相應的被你們重視起來。容器技術主要解決了如下兩個問題：

1：環境一致性問題。例如java的jar/war包部署會依賴於環境的問題（操着系統的版本，jdk版本問題）。

2：鏡像部署問題。例如java，rubby，nodejs等等的發佈系統是不同的，每一個環境都得很麻煩的部署一遍，採用docker鏡像，就屏蔽了這類問題。

下圖是Docker容器部署的一個完整過程。

更重要的是，擁有如此多服務的集羣環境遷移、複製也很是輕鬆，只需選擇好各服務對應的Docker服務鏡像、配置好相互之間訪問地址就能很快搭建出一份徹底同樣的新集羣。

容器調度和發佈體系

目前基於容器的調度平臺有Kubernetes，mesos，omega。下圖是mesos的一個簡單架構示意圖。

下圖是一個完整的容器發佈體系

喜歡這篇文章的話，能夠給做者點個喜歡，點下關注，天天都會分享Java相關文章！

記得必定要關注我哦，會不定時的福利贈送，包括整理的面試題，學習資料，源碼等~~