SpringCloud（一）淺談SpringCloud

前言

如今微服務實在是太火了，因此咱們必不可少的是要學習一下SpringCloud了，服務化的核心就是將傳統的一站式應用
根據業務拆分紅一個一個的服務，而微服務在這個基礎上要更完全地去耦合（再也不共享DB、KV，去掉重量級ESB），並
且強調DevOps和快速演化。

springcloud中經常使用的組件：

• 服務發現——Netflix Eureka
• 客戶端負載均衡——Netflix Ribbon
• 斷路器——Netflix Hystrix
• 服務網關——Netflix Zuul
• 分佈式配置——Spring Cloud Config

1、SpringCloud的架構設計

1.1 SpringCloud架構圖細解

上面的SpirngCloud的架構圖，分層概述一下。

• web服務器的選型，這個我選擇的是nginx+keepalived，haproxy也是一個選擇，可是haproxy在反向代理處理跨域
  訪問的時候問題不少。因此咱們nginx有些地方作了keep-alive模式處理，減小了三次握手的次數，提升了鏈接效率。
  keepalived作nginx的負載，虛擬一個vip對外，兩個nginx作高可用，nginx自己反向代理zuul集羣。

• api gateway，這裏的zuul不少人詬病，說是速度慢推薦直接用nginx，這裏我仍是推薦使用zuul的，畢竟zuul含有
  攔截器和反向代理，在權限管理、單點登陸、用戶認證時候仍是頗有用的，並且zuul自帶ribbon負載均衡，若是你直接用
  nginx，還須要單獨作一個feign或者ribbon層，用來作業務集羣的負載層，畢竟直接把接口暴露給web服務器太危險了。
  這裏zuul帶有ribbon負載均衡和hystrix斷路器，直接反向代理serviceId就能夠代理整個集羣了。

• 業務集羣，這一層我有些項目是分兩層的，就是上面加了一個負載層，下面是從service開始的，底層只是單純的接口，
  controller是單獨一層由feign實現，而後內部不一樣業務服務接口互調，直接調用controller層，只能說效果通常，多
  了一次tcp鏈接。因此我推薦合併起來，由於作過spring cloud項目的都知道，feign是含有ribbon的，而zuul也含有
  ribbon，這樣的話zuul調用服務集羣，和服務集羣間接口的互調都是高可用的，保證了通信的穩定性。Hystrix仍是要有
  的，沒有斷路器很難實現服務降級，會出現大量請求發送到不可用的節點。固然service是能夠改造的，若是改形成rpc方
  式，那服務之間互調又是另一種狀況了，那就要作成負載池和接口服務池的形式了，負載池調用接口池，接口池互相rpc
  調用，feign client只是經過實現接口達到了仿rpc的形式，不過速度表現仍是不錯的。

• redis緩存池，這個用來作session共享，分佈式系統session共享是一個大問題。同時呢，redis作二級緩存對下降整個
  服務的響應時間，而且減小數據庫的訪問次數是頗有幫助的。固然redis cluster仍是redis sentinel本身選擇。

• eureak註冊中心這個高可用集羣，這裏有不少細節，好比多久刷新列表一次，多久監測心跳什麼的，都很重要。

• spring admin，這個是很推薦的，這個功能很強大，能夠集成turbine斷路器監控器，並且能夠定義全部類的log等級，
  不用單獨去配置，還能夠查看本地log日誌文件，監控不一樣服務的機器參數及性能，很是強大。它加上elk動態日誌收集系
  統，對於項目運維很是方便。

• zipkin，這個有兩種方式，直接用它本身的功能界面查看方式，或者用stream流的方式，由elk動態日誌系統收集。但
  是我必需要說，這個對系統的性能損害很是大，由於鏈路追蹤的時候會形成響應等待，並且等待時間很是長接近1秒，這在
  生產環境是不能忍受的，因此生產環境最好關掉，有問題調試的時候再打開。

• 消息隊列，這個必須的，分佈式系統不可能全部場景都知足強一致性，這裏只能由消息隊列來做爲緩衝，這裏我用的是
  Kafka。

• 分佈式事物，我認爲這是分佈式最困難的，由於不一樣的業務集羣都對應本身的數據庫，互相數據庫不是互通的，互相服
  務調用只能是相互接口，有些甚至是異地的，這樣形成的結果就是網絡延遲形成的請求等待，網絡抖動形成的數據丟失，
  這些都是很可怕的問題，因此必需要處理分佈式事物。我推薦的是利用消息隊列，採起二階段提交協議配合事物補償機制，
  具體的實現須要結合業務，這裏篇幅有限就不展開說了。

• config配置中心，這是頗有必要的，由於服務太多配置文件太多，沒有這個很難運維。這個通常利用消息隊列創建一個
  spring cloud bus，由git存儲配置文件，利用bus總線動態更新配置文件信息。

• 實時分佈式日誌系統，logstash收集本地的log文件流，傳輸給elasticsearch，logstash有兩種方式，一、是每一臺
  機器啓動一個logstash服務，讀取本地的日誌文件，生成流傳給elasticsearch。二、logback引入logstash包，而後直
  接生產json流傳給一箇中心的logstash服務器，它再傳給elasticsearch。elasticsearch再將流傳給kibana，動態查
  看日誌，甚至zipkin的流也能夠直接傳給elasticsearch。這個配合spring admin，一個查看動態日誌，一個查看本地
  日誌，同時還能遠程管理不一樣類的日誌級別，對集成和運維很是有利。

1.2 兩個總結

• spring cloud的不少東西都比較精確，好比斷路器觸發時間、事物補償時間、http響應時間等，這些都須要好好的設計，
  並且能夠優化的點很是多。好比：http通信可使用okhttp，jvm優化，nio模式，數據鏈接池等等，均可以很大的提升
  性能。

• docker問題，不少人說不用docker就不算微服務。其實我我的意見，spring cloud自己就是微服務的，只須要jdk環境
  便可。編寫dockerfile也無非是集成jdk、添加jar包、執行jar而已，或者用docker compose，將多個不一樣服務的image
  組合run成容器而已。可是帶來的問題不少，好比通信問題、服務器性能損耗問題、容器進程崩潰問題，固然若是你有一套成
  熟的基於k8s的容器管理平臺，這個是沒問題的，若是沒有可能就要斟酌了。而spring cloud自己就是微服務分佈式的架構
  ，因此我的仍是推薦直接機器部署的，固然好的DevOps工具將會方便不少。

2、SpringCloud經常使用組件介紹

2.1 Eureka

一個RESTful服務，用來定位運行在AWS地區（Region）中的中間層服務。由兩個組件組成：Eureka服務器和Eureka客戶端。
Eureka服務器用做服務註冊服務器。Eureka客戶端是一個java客戶端，用來簡化與服務器的交互、做爲輪詢負載均衡器，並
提供服務的故障切換支 持。Netflix在其生產環境中使用的是另外的客戶端，它提供基於流量、資源利用率以及出錯狀態的
加權負載均衡。

2.2 Ribbon

Ribbon，遠程過程調用，包含軟件負載均衡算法。

Ribbon客戶端組件提供一系列完善的配置選項，好比鏈接超時、重試、重試算法等。Ribbon內置可插拔、可定製的負載均衡組件。
下面是用到的一些負載均衡策略：

• 簡單輪詢負載均衡
• 加權響應時間負載均衡
• 區域感知輪詢負載均衡
• 隨機負載均衡

Ribbon中還包括如下功能：

• 易於與服務發現組件（好比Netflix的Eureka）集成
• 使用Archaius完成運行時配置
• 使用JMX暴露運維指標，使用Servo發佈
• 多種可插拔的序列化選擇
• 異步和批處理操做
• 自動SLA框架
• 系統管理/指標控制檯

2.3 Hystrix

斷路器能夠防止一個應用程序屢次試圖執行一個操做，即極可能失敗，容許它繼續而不等待故障恢復或者浪費 CPU 週期，而它
肯定該故障是持久的。斷路器模式也使應用程序可以檢測故障是否已經解決。若是問題彷佛已經獲得糾正​​，應用程序能夠嘗試調
用操做。

斷路器增長了穩定性和靈活性，以一個系統，提供穩定性，而系統從故障中恢復，並儘可能減小此故障的對性能的影響。它能夠幫助
快速地拒絕對一個操做，即 極可能失敗，而不是等待操做超時（或者不返回）的請求，以保持系統的響應時間。若是斷路器提升
每次改變狀態的時間的事件，該信息能夠被用來監測由斷路器保 護系統的部件的健康情況，或以提醒管理員當斷路器跳閘，以在
打開狀態。

流程圖:

2.4 Zuul

相似nginx，反向代理的功能，不過netflix本身增長了一些配合其餘組件的特性。

2.5 Spring Cloud Config

當一個系統中的配置文件發生改變的時候，咱們須要從新啓動該服務，才能使得新的配置文件生效，spring cloud config能夠實 現微服務中的全部系統的配置文件的統一管理，並且還能夠實現當配置文件發生變化的時候，系統會自動更新獲取新的配置