點擊上方 "程序員小樂"關注, 星標或置頂一起成長
每天凌晨00點00分, 第一時間與你相約
每日英文
Sometimes being too nice is dangerous, you have to show your mean side once in a while to avoid getting hurt.
有時候，太善良也是種危險。偶爾你也得厲害一點，才能免受傷害。
每日掏心話
做人不要太玻璃心，不要別人一條信息沒回，就覺得自己做錯了什麼，不要被人一句”呵呵“，就覺得對方是討厭自己。玻璃心，想太多，什麼事都對號入座，何必那麼累。
來自：SimpleEasy | 責編：樂樂
鏈接：segmentfault.com/a/1190000017766364
程序員小樂(ID:study_tech)第 789 次推文 圖片來自百度
往日回顧：30 張圖帶你徹底理解紅黑樹
正文
Spring Cloud作為當下主流的微服務框架，可以讓我們更簡單快捷地實現微服務架構。Spring Cloud並沒有重複製造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。Spring Cloud中各個組件在微服務架構中扮演的角色如下圖所示，黑線表示註釋說明，藍線由A指向B，表示B從A處獲取服務。
Spring 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實現自定義的負載均衡算法。在Spring Cloud中，當Ribbon與Eureka配合使用時，Ribbon可自動從EurekaServer獲取服務提供者的地址列表，並基於負載均衡算法，請求其中一個服務提供者的實例（為了服務的可靠性，一個微服務可能部署多個實例）。
Hystrix（熔斷器）：當服務提供者響應非常緩慢，那麼消費者對提供者的請求就會被強制等待，直到提供者響應或超時。在高負載場景下，如果不做任何處理，此類問題可能會導致服務消費者的資源耗竭甚至整個系統的崩潰（雪崩效應）。Hystrix正是為了防止此類問題發生。Hystrix是由Netflix開源的一個延遲和容錯庫，用於隔離訪問遠程系統、服務或者第三方庫，防止級聯失敗，從而提升系統的可用性與容錯性。Hystrix主要通過以下幾點實現延遲和容錯。
包裹請求：使用HystrixCommand（或HystrixObservableCommand）包裹對依賴的調用邏輯，每個命令在獨立線程中執行。這使用了設計模式中的“命令模式”。
跳閘機制：當某服務的錯誤率超過一定閾值時，Hystrix可以自動或者手動跳閘，停止請求該服務一段時間。
資源隔離：Hystrix為每個依賴都維護了一個小型的線程池（或者信號量）。如果該線程池已滿，發往該依賴的請求就被立即拒絕，而不是排隊等候，從而加速失敗判定。
監控：Hystrix可以近乎實時地監控運行指標和配置的變化，例如成功、失敗、超時和被拒絕的請求等。
回退機制：當請求失敗、超時、被拒絕，或當斷路器打開時，執行回退邏輯。回退邏輯可由開發人員指定。
Zuul（微服務網關）：不同的微服務一般會有不同的網絡地址，而外部客戶端可能需要調用多個服務的接口才能完成一個業務需求。例如一個電影購票的手機APP，可能調用多個微服務的接口才能完成一次購票的業務流程，如果讓客戶端直接與各個微服務通信，會有以下的問題：
客戶端會多次請求不同的微服務，增加了客戶端的複雜性。
存在跨域請求，在一定場景下處理相對複雜。
認證複雜，每個服務都需要獨立認證。
難以重構，隨著項目的迭代，可能需要重新劃分微服務。例如，可能將多個服務合併成一個或者將一個服務拆分成多個。如果客戶端直接與微服務通信，那麼重構將很難實施。
-
某些微服務可能使用了對防火牆/瀏覽器不友好的協議，直接訪問時會有一定的困難。
以上問題可藉助微服務網關解決。微服務網關是介於客戶端和服務器端之間的中間層，所有的外部請求都會先經過微服務網關。使用微服務網關後，微服務網關將封裝應用程序的內部結構，客戶端只用跟網關交互，而無須直接調用特定微服務的接口。這樣，開發就可以得到簡化。不僅如此，使用微服務網關還有以下優點：
易於監控。可在微服務網關收集監控數據並將其推送到外部系統進行分析。
易於認證。可在微服務網關上進行認證，然後再將請求轉發到後端的微服務，而無須在每個微服務中進行認證。
減少了客戶端與各個微服務之間的交互次數。
Spring Cloud Bus（ 統一配置服務）：對於傳統的單體應用，常使用配置文件管理所有配置。例如一個SpringBoot開發的單體應用，可將配置內容放在application.yml文件中。如果需要切換環境，可設置多個Profile，並在啟動應用時指定spring.profiles.active={profile}。然而，在微服務架構中，微服務的配置管理一般有以下需求：
集中管理配置。一個使用微服務架構的應用系統可能會包含成百上千個微服務，因此集中管理配置是非常有必要的。
不同環境，不同配置。例如，數據源配置在不同的環境（開發、測試、預發佈、生產等）中是不同的。
運行期間可動態調整。例如，可根據各個微服務的負載情況，動態調整數據源連接池大小或熔斷閾值，並且在調整配置時不停止微服務。
配置修改後可自動更新。如配置內容發生變化，微服務能夠自動更新配置。綜上所述，對於微服務架構而言，一個通用的配置管理機制是必不可少的，常見做法是使用配置服務器管理配置。Spring Cloud Bus利用Git或SVN等管理配置、採用Kafka或者RabbitMQ等消息總線通知所有應用，從而實現配置的自動更新並且刷新所有微服務實例的配置。
Sleuth+ZipKin（跟蹤服務）：Sleuth和Zipkin結合使用可以通過圖形化的界面查看微服務請求的延遲情況以及各個微服務的依賴情況。需要注意的是Spring Boot 2及以上不在支持Zipkin的自定義，需要到官方網站下載ZipKin相關的jar包。
另外需要提一點的是Spring Boot Actuator，提供了很多監控端點如/actuator/info、/actuator/health、/acutator/refresh等，可以查看微服務的信息、健康狀況、刷新配置等。
歡迎在留言區留下你的觀點，一起討論提高。如果今天的文章讓你有新的啟發，學習能力的提升上有新的認識，歡迎轉發分享給更多人。
猜你還想看
阿里、騰訊、百度、華為、京東最新面試題彙集
微服務的生離死別，看這篇就對了！
Java中的對象都是在堆上分配的嗎？
在Spring Boot項目中整合使用Activiti
關注訂閱號「程序員小樂」，收看更多精彩內容
嘿，你在看嗎？
閱讀更多 程序員小樂 的文章
