前言
現在微服務實在是太火了，所以我們必不可少的是要學習一下SpringCloud了，服務化的核心就是將傳統的一站式應用
根據業務拆分成一個一個的服務，而微服務在這個基礎上要更徹底地去耦合（不再共享DB、KV，去掉重量級ESB），並
且強調DevOps和快速演化。
springcloud中常用的組件：
- 服務發現——Netflix Eureka
- 客戶端負載均衡——Netflix Ribbon
- 斷路器——Netflix Hystrix
- 服務網關——Netflix Zuul
- 分布式配置——Spring Cloud Config
一、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有兩種方式，1、是每一台
機器啟動一個logstash服務，讀取本地的日志文件，生成流傳給elasticsearch。2、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工具將會方便很多。
二、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可以實
現微服務中的所有系統的配置文件的統一管理，而且還可以實現當配置文件發生變化的時候，系統會自動更新獲取新的配置