【Spring Cloud】全家桶介紹（一）
一、微服務架構
1、微服務架構簡介
1.1、分散式：不同的功能模組部署在不同的伺服器上，減輕網站高併發帶來的壓力。
1.2、叢集：多臺伺服器上部署相同應用構成一個叢集，通過負載均衡共同向外提供服務。
1.3、微服務：微服務架構模式就是將web應用拆分為一系列小的服務模組，這些模組可以獨立地編譯、部署，並通過各自暴露的API介面通訊，共同組成一個web應用。
1.4、SpringCloud是基於SpringBoot的一整套微服務框架，提供了一系列可配置的元件，如配置管理、服務發現、負載均衡、熔斷器、斷路器、智慧路由、微代理、控制匯流排、全域性鎖、決策競選、分散式會話和叢集狀態管理等。
2、微服務的特點
- 單一職責：每一個服務模組都對應單一的業務實現
- 微：服務拆分的顆粒度很小
- 面向服務：每個服務對外僅暴露服務介面API即可，不關心服務的技術實現，與技術、語言和平臺無關
- 自治：服務間互相獨立、互不干擾
- 團隊獨立
- 技術獨立：提供Rest介面，面向服務即可
- 前後端分離
- 資料庫分離：每個服務使用自己的資料來源
- 部署獨立：每個服務都是獨立的元件，可複用，可替換，降低服務間的耦合
3、三者的關係
微服務是一種結構理念，設計原則，提供理論指導；
Spring Boot專注於快速、方便整合的單個微服務個體，可以基於Spring Boot快速開發單個微服務；
Spring Cloud是一個基於Spring Boot實現的服務工具治理包，專注於全域性的服務治理框架。
二、Spring Cloud
1、Spring Cloud元件架構
上圖中各元件的元件和執行流程如下：
-
- 所有請求都通過API閘道器來訪問內部服務；
- 閘道器接受請求後，從註冊中心獲取可用服務模組；
- 由Ribbon進行負載均衡後，分發到後臺的具體例項；
- 各個服務模組之間通過Feign進行通訊處理業務；
- Hystrix負責處理服務超時熔斷；
- Turbine監控服務間的呼叫和熔斷相關指標。
再來看一個具體例項上的Spring Cloud服務流程：
2、Spring Cloud元件簡介
2.1、主要元件簡介
- Eureka，服務註冊中心
- Zuul，API服務閘道器
- Config，分散式配置中心，支援本地倉庫、SVN、Git、Jar包內配置等模式
- Dashboard，Hystrix儀表盤，監控叢集模式和單點模式，其中叢集模式需要收集器Turbine配合
- Ribbon，客戶端負載均衡
- Feign，宣告式服務呼叫
- Bus，訊息匯流排
2.2、元件主要功能
Eureka和Ribbon，一個註冊服務，一個消費服務。
Hystrix，為了優化Ribbon，防止整個微服務架構因為某個服務節點的問題導致崩潰，起到保險絲的作用。
Dashboard，給Hystrix統計和展示用，而且監控服務節點的整體壓力和健康情況。
Turbine，叢集收集器，服務於Dashboard。
Zuul，加在整個微服務最前沿的防火牆和代理器，隱藏微服務結點IP埠資訊，加強安全保護。
Config，為了解決所有微服務各自維護各自的配置，設定一個統一的配置中心，方便修改配置。
Bus是因為config修改完配置後各個結點都要refresh才能生效實在太麻煩，所以交給bus來通知服務節點重新整理配置的。
3、SpringCloud全家桶
- 首先為了提供微服務之間的發現和註冊，需要服務註冊中心提供註冊與發現功能，採用Eureka元件。
- 消費者從註冊中心拿到服務提供者的註冊地址資訊列表，為了從中選擇一個提供方，避免流量集中在某臺機，需要客戶端負載均衡元件Ribbon。
- 消費者得到具體提供方的地址資訊後，發起遠端呼叫，通過宣告式呼叫元件Feign，將遠端RestFul呼叫封裝成介面呼叫。
- 在微服務架構中，為了避免某個服務掛掉後引起服務雪崩，以及做到服務端失敗後快速響應，提供了服務熔斷以及降級機制Hystrix元件。
- 為了對外遮蔽內部服務呼叫細節，在最前沿加入閘道器元件，提供流量控制、身份鑑別、負載均衡等安全防護功能，採用API閘道器Zuul元件。
- 隨著系統訪問量的增加，為避免單點的註冊中心成為系統性能瓶頸，註冊中心採用Eureka叢集方式部署。
- 隨著系統擴大，Eureka叢集的部署以及服務模組的增多，每個模組維護各自的配置資訊，複雜且容易出錯，引入配置中心SpringCloud Config元件，提供統一的配置資訊管理。
- 為了避免每次配置資訊的變更都需要重啟服務才能生效，引入訊息匯流排Bus元件，提供無需重啟、實時重新整理配置資訊等功能。
後續也會按照這個順序逐個介紹各元件，以及各元件demo的開發搭建，最終完成一個SpringCloud全家桶demo..