一張圖了解Spring cloud微服務架構
一張圖了解Spring cloud微服務架構
Spring cloud作為當下主流的微服務框架，讓我們實現微服務架構簡單快捷，Spring cloud中各個組件在微服務架構中扮演的角色如下圖所示，黑線表示注釋說明，藍線由A指向B，表示B從A處獲取服務。
cloud組成的微服務架構圖 由上圖所示微服務架構大致由上圖的邏輯結構組成，其包括各種微服務、注冊發現、服務網關、熔斷器、統一配置、跟蹤服務等。下面說說Spring cloud中的組件分別充當其中的什么角色。
Fegin(接口調用)：微服務之間通過Rest接口通訊，Spring Cloud提供Feign框架來支持Rest的調用，Feign使得不同進程的Rest接口調用得以用優雅的方式進行，這種優雅表現得就像同一個進程調用一樣。
Netflix eureka(注冊發現)：微服務模式下，一個大的Web應用通常都被拆分為很多比較小的web應用(服務)，這個時候就需要有一個地方保存這些服務的相關信息，才能讓各個小的應用彼此知道對方，這個時候就需要在注冊中心進行注冊。每個應用啟動時向配置的注冊中心注冊自己的信息（ip地址，端口號, 服務名稱等信息），注冊中心將他們保存起來，服務間相互調用的時候，通過服務名稱就可以到注冊中心找到對應的服務信息，從而進行通訊。注冊與發現服務為微服務之間的調用帶來了方便，解決了硬編碼的問題。服務間只通過對方的服務id，而無需知道其ip和端口即可以獲取對方方服務。
Ribbon(負載均衡)：Ribbon是Netflix發布的負載均衡器，它有助于控制HTTP和TCP客戶端的行為。為Ribbon，配置服務提供者的地址列表后，Ribbon就可基于某種負載均衡算法，自動地幫助服務消費者去請求。Ribbon默認為我們提供了很多的負載均衡算法，例如輪詢、隨機等。當然，我們也可為Ribbon實現自定義的負載均衡算法。在SpringCloud中，當Ribbon與Eureka配合使用時，Ribbon可自動從EurekaServer獲取服務提供者的地址列表，并基于負載均衡算法，請求其中一個服務提供者的實例（為了服務的可靠性，一個微服務可能部署多個實例）。
Hystrix(熔斷器)：當服務提供者響應非常緩慢，那么消費者對提供者的請求就會被強制等待，直到提供者響應或超時。在高負載場景下，如果不做任何處理，此類問題可能會導致服務消費者的資源耗竭甚至整個系統的崩潰（雪崩效應）。Hystrix正是為了防止此類問題發生。Hystrix是由Netflix開源的一個延遲和容錯庫，用于隔離訪問遠程系統、服務或者第三方庫，防止級聯失敗，從而提升系統的可用性與容錯性。Hystrix主要通過以下幾點實現延遲和容錯。
包裹請求：使用HystrixCommand（或HystrixObservableCommand）包裹對依賴的調用邏輯，每個命令在獨立線程中執行。這使用了設計模式中的“命令模式”。
跳閘機制：當某服務的錯誤率超過一定閾值時，Hystrix可以自動或者手動跳閘，停止請求該服務一段時間。
資源隔離：Hystrix為每個依賴都維護了一個小型的線程池（或者信號量）。如果該線程池已滿，發往該依賴的請求就被立即拒絕，而不是排隊等候，從而加速失敗判定。
監控：Hystrix可以近乎實時地監控運行指標和配置的變化，例如成功、失敗、超時和被拒絕的請求等。
回退機制：當請求失敗、超時、被拒絕，或當斷路器打開時，執行回退邏輯?；赝诉壿嬁捎砷_發人員指定。
Zuul(微服務網關) ：不同的微服務一般會有不同的網絡地址，而外部客戶端可能需要調用多個服務的接口才能完成一個業務需求。例如一個電影購票的手機APP，可能調用多個微服務的接口才能完成一次購票的業務流程，如果讓客戶端直接與各個微服務通信，會有以下的問題：
客戶端會多次請求不同的微服務，增加了客戶端的復雜性。
存在跨域請求，在一定場景下處理相對復雜。
認證復雜，每個服務都需要獨立認證。
難以重構，隨著項目的迭代，可能需要重新劃分微服務。例如，可能將多個服務合并成一個或者將一個服務拆分成多個。如果客戶端直接與微服務通信，那么重構將很難實施。
某些微服務可能使用了對防火墻/瀏覽器不友好的協議，直接訪問時會有一定的困難。
以上問題可借助微服務網關解決。微服務網關是介于客戶端和服務器端之間的中間層，所有的外部請求都會先經過微服務網關。使用微服務網關后，微服務網關將封裝應用程序的內部結構，客戶端只用跟網關交互，而無須直接調用特定微服務的接口。這樣，開發就可以得到簡化。不僅如此，使用微服務網關還有以下優點：
易于監控?？稍谖⒎站W關收集監控數據并將其推送到外部系統進行分析。
易于認證?？稍谖⒎站W關上進行認證，然后再將請求轉發到后端的微服務，而無須在每個微服務中進行認證。
減少了客戶端與各個微服務之間的交互次數。
Spring cloud bus（ 統一配置服務）：對于傳統的單體應用，常使用配置文件管理所有配置。例如一個SpringBoot開發的單體應用，可將配置內容放在application.yml文件中。如果需要切換環境，可設置多個Profile，并在啟動應用時指定spring.profiles.active={profile}。然而，在微服務架構中，微服務的配置管理一般有以下需求：
集中管理配置。一個使用微服務架構的應用系統可能會包含成百上千個微服務，因此集中管理配置是非常有必要的。
不同環境，不同配置。例如，數據源配置在不同的環境（開發、測試、預發布、生產等）中是不同的。
運行期間可動態調整。例如，可根據各個微服務的負載情況，動態調整數據源連接池大小或熔斷閾值，并且在調整配置時不停止微服務。
配置修改后可自動更新。如配置內容發生變化，微服務能夠自動更新配置。綜上所述，對于微服務架構而言，一個通用的配置管理機制是必不可少的，常見做法是使用配置服務器管理配置。Spring cloud bus利用Git或SVN等管理配置、采用Kafka或者RabbitMQ等消息總線通知所有應用，從而實現配置的自動更新并且刷新所有微服務實例的配置。
Sleuth+ZipKin(跟蹤服務)：Sleuth和Zipkin結合使用可以通過圖形化的界面查看微服務請求的延遲情況以及各個微服務的依賴情況。需要注意的是Spring boot2及以上不在支持Zipkin的自定義，需要到官方網站下載ZipKin相關的jar包。
另外需要提一點的是Spring boot actuator，提供了很多監控端點如/actuator/info、/actuator/health、/acutator/refresh等，可以查看微服務的信息、健康狀況、刷新配置等。