一張圖了解SpringCloud微服務架構

創(chuàng)新互聯(lián)建站-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設、高性價比濟水街道網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式濟水街道網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設找我們，業(yè)務覆蓋濟水街道地區(qū)。費用合理售后完善，十余年實體公司更值得信賴。

Spring Cloud作為當下主流的微服務框架，可以讓我們更簡單快捷地實現(xiàn)微服務架構。Spring Cloud并沒有重復制造輪子，它只是將目前各家公司開發(fā)的比較成熟、經(jīng)得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了復雜的配置和實現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護的分布式系統(tǒng)開發(fā)工具包。Spring Cloud中各個組件在微服務架構中扮演的角色如下圖所示，黑線表示注釋說明，藍線由A指向B，表示B從A處獲取服務。

由上圖所示微服務架構大致由上圖的邏輯結構組成，其包括各種微服務、注冊發(fā)現(xiàn)、服務網(wǎng)關、熔斷器、統(tǒng)一配置、跟蹤服務等。下面說說Spring Cloud中的組件分別充當其中的什么角色。

Fegin（接口調用）：微服務之間通過Rest接口通訊，Spring Cloud提供Feign框架來支持Rest的調用，F(xiàn)eign使得不同進程的Rest接口調用得以用優(yōu)雅的方式進行，這種優(yōu)雅表現(xiàn)得就像同一個進程調用一樣。

Netflix eureka（注冊發(fā)現(xiàn)）：微服務模式下，一個大的Web應用通常都被拆分為很多比較小的Web應用（服務），這個時候就需要有一個地方保存這些服務的相關信息，才能讓各個小的應用彼此知道對方，這個時候就需要在注冊中心進行注冊。每個應用啟動時向配置的注冊中心注冊自己的信息（IP地址，端口號, 服務名稱等信息），注冊中心將他們保存起來，服務間相互調用的時候，通過服務名稱就可以到注冊中心找到對應的服務信息，從而進行通訊。注冊與發(fā)現(xiàn)服務為微服務之間的調用帶來了方便，解決了硬編碼的問題。服務間只通過對方的服務ID，而無需知道其IP和端口即可以獲取對方方服務。

Ribbon（負載均衡）：Ribbon是Netflix發(fā)布的負載均衡器，它有助于控制HTTP和TCP客戶端的行為。為Ribbon，配置服務提供者的地址列表后，Ribbon就可基于某種負載均衡算法，自動地幫助服務消費者去請求。Ribbon默認為我們提供了很多的負載均衡算法，例如輪詢、隨機等。當然，我們也可為Ribbon實現(xiàn)自定義的負載均衡算法。在Spring Cloud中，當Ribbon與Eureka配合使用時，Ribbon可自動從EurekaServer獲取服務提供者的地址列表，并基于負載均衡算法，請求其中一個服務提供者的實例（為了服務的可靠性，一個微服務可能部署多個實例）。

Hystrix（熔斷器）：當服務提供者響應非常緩慢，那么消費者對提供者的請求就會被強制等待，直到提供者響應或超時。在高負載場景下，如果不做任何處理，此類問題可能會導致服務消費者的資源耗竭甚至整個系統(tǒng)的崩潰（雪崩效應）。Hystrix正是為了防止此類問題發(fā)生。Hystrix是由Netflix開源的一個延遲和容錯庫，用于隔離訪問遠程系統(tǒng)、服務或者第三方庫，防止級聯(lián)失敗，從而提升系統(tǒng)的可用性與容錯性。Hystrix主要通過以下幾點實現(xiàn)延遲和容錯。

• 包裹請求：使用HystrixCommand（或HystrixObservableCommand）包裹對依賴的調用邏輯，每個命令在獨立線程中執(zhí)行。這使用了設計模式中的“命令模式”。

• 跳閘機制：當某服務的錯誤率超過一定閾值時，Hystrix可以自動或者手動跳閘，停止請求該服務一段時間。

• 資源隔離：Hystrix為每個依賴都維護了一個小型的線程池（或者信號量）。如果該線程池已滿，發(fā)往該依賴的請求就被立即拒絕，而不是排隊等候，從而加速失敗判定。

• 監(jiān)控：Hystrix可以近乎實時地監(jiān)控運行指標和配置的變化，例如成功、失敗、超時和被拒絕的請求等。

• 回退機制：當請求失敗、超時、被拒絕，或當斷路器打開時，執(zhí)行回退邏輯。回退邏輯可由開發(fā)人員指定。

Zuul（微服務網(wǎng)關）：不同的微服務一般會有不同的網(wǎng)絡地址，而外部客戶端可能需要調用多個服務的接口才能完成一個業(yè)務需求。例如一個電影購票的手機APP，可能調用多個微服務的接口才能完成一次購票的業(yè)務流程，如果讓客戶端直接與各個微服務通信，會有以下的問題：

• 客戶端會多次請求不同的微服務，增加了客戶端的復雜性。

• 存在跨域請求，在一定場景下處理相對復雜。

• 認證復雜，每個服務都需要獨立認證。

• 難以重構，隨著項目的迭代，可能需要重新劃分微服務。例如，可能將多個服務合并成一個或者將一個服務拆分成多個。如果客戶端直接與微服務通信，那么重構將很難實施。

• 某些微服務可能使用了對防火墻/瀏覽器不友好的協(xié)議，直接訪問時會有一定的困難。

以上問題可借助微服務網(wǎng)關解決。微服務網(wǎng)關是介于客戶端和服務器端之間的中間層，所有的外部請求都會先經(jīng)過微服務網(wǎng)關。使用微服務網(wǎng)關后，微服務網(wǎng)關將封裝應用程序的內部結構，客戶端只用跟網(wǎng)關交互，而無須直接調用特定微服務的接口。這樣，開發(fā)就可以得到簡化。不僅如此，使用微服務網(wǎng)關還有以下優(yōu)點：

• 易于監(jiān)控。可在微服務網(wǎng)關收集監(jiān)控數(shù)據(jù)并將其推送到外部系統(tǒng)進行分析。

• 易于認證?？稍谖⒎站W(wǎng)關上進行認證，然后再將請求轉發(fā)到后端的微服務，而無須在每個微服務中進行認證。

• 減少了客戶端與各個微服務之間的交互次數(shù)。

Spring Cloud Config（ 統(tǒng)一配置服務）：對于傳統(tǒng)的單體應用，常使用配置文件管理所有配置。例如一個SpringBoot開發(fā)的單體應用，可將配置內容放在application.yml文件中。如果需要切換環(huán)境，可設置多個Profile，并在啟動應用時指定spring.profiles.active={profile}。然而，在微服務架構中，微服務的配置管理一般有以下需求：

• 集中管理配置。一個使用微服務架構的應用系統(tǒng)可能會包含成百上千個微服務，因此集中管理配置是非常有必要的。

• 不同環(huán)境，不同配置。例如，數(shù)據(jù)源配置在不同的環(huán)境（開發(fā)、測試、預發(fā)布、生產(chǎn)等）中是不同的。

• 運行期間可動態(tài)調整。例如，可根據(jù)各個微服務的負載情況，動態(tài)調整數(shù)據(jù)源連接池大小或熔斷閾值，并且在調整配置時不停止微服務。

• 配置修改后可自動更新。如配置內容發(fā)生變化，微服務能夠自動更新配置。綜上所述，對于微服務架構而言，一個通用的配置管理機制是必不可少的，常見做法是使用配置服務器管理配置。Spring Cloud Bus利用Git或SVN等管理配置、采用Kafka或者RabbitMQ等消息總線通知所有應用，從而實現(xiàn)配置的自動更新并且刷新所有微服務實例的配置。

Sleuth+ZipKin（跟蹤服務）：Sleuth和Zipkin結合使用可以通過圖形化的界面查看微服務請求的延遲情況以及各個微服務的依賴情況。需要注意的是Spring Boot 2及以上不在支持Zipkin的自定義，需要到官方網(wǎng)站下載ZipKin相關的jar包。另外需要提一點的是Spring Boot Actuator，提供了很多監(jiān)控端點如/actuator/info、/actuator/health、/acutator/refresh等，可以查看微服務的信息、健康狀況、刷新配置等。

當前題目：一張圖了解SpringCloud微服務架構
轉載注明：http://bm7419.com/article28/psojcp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信小程序、定制開發(fā)、面包屑導航、移動網(wǎng)站建設、全網(wǎng)營銷推廣、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)