spring cloud(雜記)

部分文字摘錄自：https://gitbook.cn/books/5d82...
微服務架構的定義，就是將原來的單體應用按義務範圍來劃分爲多個小的模塊，每一個微服務運行在本身的進程中，相互不產生影響，徹底自動化獨立部署，並使用輕量級機制通訊，一般是 HTTP RESTUFUL API，可對各微服務進行集中管理。
Spring Cloud 包含以下的核心組件：

• 服務註冊與發現：Eureka、Consul、Zookeeper
• API 網關：Zuul、Spring Cloud Gateway
• REST 調用：Feign
• 負載均衡：Ribbon
• 容錯處理：Hystrix
• 鏈路追逐：Sleuth、Zipkin
• 配置管理：Config

服務註冊與發現組件主要解決兩個問題：服務註冊和服務發現。

• 服務註冊：服務實例將自身服務信息註冊到註冊中心。這部分服務信息包括服務所在主機 IP 和提供服務的 Port，以及暴露服務自身狀態以及訪問協議等信息。
• 服務發現：服務實例請求註冊中心獲取所依賴服務信息。服務實例經過註冊中心，獲取到註冊到其中的服務實例的信息，經過這些信息去請求它們提供的服務

API 網關能夠作一下事情：

• 統一入口
• 統一限流
• 統一認證鑑權
• 動態路由制定和修改
• 負載
• 服務容錯降價
• 版本控制
• 統一監控日誌記錄
• 協議轉換：如 HTTP => RPC 協議
• 緩存
• 靜態
• 灰度：線上灰度部署，能夠減少風險

REST 調用的方式。通常狀況咱們發送一個 HTTP 請求，多是採用完整域名或者 IP 加 URI 接口的方式，可是咱們不可能爲每一個服務都分配一個域名，這是不現實的；咱們也不可能直接經過 IP 的方式調用，一是 IP 可能會太多，最主要的是 IP 會常常變更，那樣又會改動代碼，多麻煩。

有了 Feign 這個工具，這些問題都不存在了。

Feign 是一個聲明式 WebService 客戶端，旨在使編寫 Java HTTP 客戶端變得更容易。使用 Feign 能讓編寫的 WebService 客戶端更加簡潔，它的使用方法很簡單，就是定義一個接口，而後在上面添加註解。

負載均衡

負載均衡好理解，咱們的一個微服務爲了提升性能可能會部署多臺，這個時候就須要將壓力分散到每臺服務器上，Ribbon 就是來幹這個事情的。

容錯處理

隨着業務的擴展，服務的數量也會隨之增多，邏輯會更加複雜，一個服務的某個邏輯須要依賴多個其餘服務才能完成。一旦一個依賴不能提供服務極可能會產生雪崩效應，最後致使整個服務不可訪問。

Hystrix 熔斷就是爲了不服務的雪崩產生，當 A 服務調用 B 服務時，若是 B 服務不能快速響應，Hystrix 就會在必定時間內作熔斷處理，放回默認爲值。

鏈路追逐、配置管理

鏈路追蹤

主要是爲了方便排查問題，咱們的一個服務可能要調用多個微服務才能完成全部操做，當某個服務報錯出現異常了怎樣快速定位是哪一個服務報錯了呢？咱們不可能把全部的服務日誌都打開觀察吧，鏈路追蹤就是爲了方便咱們查看微服務的調用鏈，讓我快速定位那個服務出現了異常。

常見的鏈路追蹤有 Sleuth、Zipkin、Skywalking 等。

配置管理

咱們的項目裏面除了常見的配置數據庫、緩存等外，可能還有不少的其餘配置，好比：某些三方服務域名，帳號密鑰等。固然這些配置也徹底能夠都放在項目裏面的配置文件中，可是當你要修改配置，可能就要重啓服務才能使新的配置生效。

有辦法能夠動態的修改配置，而且在不重啓服務的狀況下讓配置生效嗎？確定有。Spring Cloud Config 就幫咱們實現了咱們想要的功能，還有功能更強大的配置管理服務，攜程開源的 Apollo② 分佈式配置中心，你指的擁有。

容器化部署

當咱們在使用微服務的時候，那麼有一個問題必定會困擾咱們，那就是項目的測試和部署。

由於在單體應用下，部署項目很簡單，直接打包啓動就能夠了，而對於微服務來講，由於有各個組件的存在因此讓測試和部署都變得很麻煩，並且有時還由於環境配置等差別致使意向不到的問題。而容器化是微服務部署一把利劍，統一標準，讓個人環境高度一致，方便咱們快速的部署上線應用。