spring-cloud概述

單體架構

把業務的所有功能實現都打包在一個war包或者jar包，這種方式就成為單體架構。

比如Spring課程中的博客系統,前端+后端+數據庫實現，都在一個項目中，這種架構就稱為單體架構.

舉個例子：

比如在電商系統中，我們會設計用戶管理，商品管理，訂單管理，支付管理，庫存管理等等這些功能，在早期我們是會把這些模塊都寫在一個web項目中，然后統一部署到一個Web服務器中。

這種架構開發簡單，部署簡單，?個項?就包含了所有的功能，省去了多個項?之間的交互和調?消耗。直接部署在?個服務器即可。

集群和分布式架構

但是呢，隨著時間的發展，單體機構的弊端就逐漸顯現了，就比如隨著網站的用戶量越來越大，需求也會越來越多，流量也會越來越大，服務可能就會面臨一下問題：

后端服務器的壓力就會越來越大，負載越來越高，甚至出現無法訪問的情況。
業務場景逐漸復雜，為了滿足用戶的需求，單體應用也會越來越大，各個業務代碼之間的耦合度也會越來越高，任何一個問題，可能會導致整個項目重新構建，發布。
一個微小的問題，可能會導致整個應用掛掉。

解決方案：

橫向：添加服務器，把單臺機器變成多臺機器的集群。
縱向：把一個應用，按照業務進行拆分，拆分為多個項目，此架構也稱為垂直架構或分布式架構。

舉個例子，方便理解：

比如最開始只有一臺機器，它能承擔1000個用戶，但是后來發展為10000個用戶：

橫向：擴容機器，從一臺機器，擴容到10臺機器，每臺機器負責1000個用戶。（集群）
縱向：按照功能進行劃分。（分布式）

集群和分布式

**集群（cluster）**是將一個系統完整的部署到多個服務器上，每個服務器都能提供系統的所有服務，多個服務器通過負載均衡調度完成任務，每個服務器稱為集群的節點（node）。
分布式是將一個系統拆分為多個子系統，多個子系統部署在多個服務器上，多個服務器上的子系統協同合作完成一個特定任務。

舉個生活實例：

有一個小餐館，剛開始只有一個廚師，這個廚師他負責做飯相關的所有工作，但隨著餐館的生意的好轉，一個廚師忙不過來：
1. 橫向：再招聘一個廚師，這兩個廚師都可以獨立做飯。
2. 縱向：廚師的工作分為：洗菜，切菜，配菜，炒菜…..
  
  就可以單獨招一個配菜師，負責洗菜，切菜，配菜….
后面生意如果更加好了，就可以再招聘多個配菜師，多個廚師。

集群和分布式的區別和聯系

從概念上，集群是多個計算機做同樣的事情（可以替代），而分布式是多個計算機做不同的事情（不可替代）。
從功能上，集群的每一個節點功能是相同的，并且是可以替代的，分布式也是多個節點組成的系統，但是每個節點完成的業務是不同的，一個節點出現問題，這個業務就不可訪問了。
從關系上，分布式和集群在實踐中，很多時候是互相配合使用的，比如分布式的某一個節點，可能由一個集群來代替。分布式架構大多是建立在集群上的，所以實際的分布式架構設計中并不會把分布式和集群單獨區分，而是統稱為：分布式架構。

微服務架構

在分布式架構下，當部署的服務越來越多，重復的代碼就會越來越多，服務的調用關系也會越來越復雜，我們可以把一些通用的，會被多個上層服務調用的共享業務，提取成獨立的基礎服務，組成一個個微笑的服務，這就是微服務。

微服務，可以理解為“很小的服務”，小到一個服務只對應一個單一的功能，只做一件事，這個服務可以單獨部署運行。

微服務之間可以采用 REST 和 RPC 協議進行通信。（類似http，可以理解為接口的約定）

微服務，也可以理解是分布式架構的一種拓展，這種架構模式下它拆分的粒度更小，服務更獨立，可以理解為：微服務是一種經過良好架構設計的分布式架構方案。

分布式架構和微服務架構：

分布式架構和微服務架構有很多相似之處，例如都強調將系統拆分成多個獨立的模塊，多個模塊可以部署在不同的服務器上等。不過兩者也存在一些區別：

基本概念

分布式架構：一種將系統分解成多個子系統、模塊或組件，并將它們分布到不同的計算節點上運行的架構風格。這些節點可以是物理服務器、虛擬機或容器等，節點之間通過網絡進行通信，以協同完成業務功能。（服務拆分，拆了就行）
微服務架構：一種特定的分布式架構風格，將一個大型復雜應用分解成多個小型、獨立、松耦合的服務，每個服務專注于特定的業務功能，并且可以獨立開發、部署和擴展。

服務粒度

分布式架構：服務粒度可以是較大的模塊或子系統，例如按業務模塊劃分的用戶模塊、訂單模塊、支付模塊等。
微服務架構：服務粒度更小，通常聚焦于單一的業務功能，例如用戶服務中的用戶注冊服務、用戶登錄服務等。

服務耦合度

分布式架構：服務之間的耦合度相對較高，因為它們共同組成一個完整的系統，往往需要緊密協作。例如，分布式架構中的服務之間可能共享數據庫或數據模型。
微服務架構：服務之間保持較低的耦合度，每個服務獨立運行，有自己獨立的數據庫和數據模型，服務之間的交互通過輕量級通信協議進行。

數據管理

分布式架構：數據管理方式取決于具體的分布式架構設計，可以是集中式的數據庫，也可以是分布式數據庫等。
微服務架構：采用去中心化的數據管理方式，每個微服務都有自己的數據庫和數據模型，數據的訪問和操作都在服務內部進行。

部署方式

分布式架構：部署方式可以是集中式或分布式，多個子系統或模塊可以部署在同一個服務器或不同的服務器上，部署方式相對較為靈活。
微服務架構：通常采用容器化技術（如Docker、Kubernetes等）進行部署，每個微服務可以獨立部署在容器中，容器之間的隔離性和獨立性較好。

分布式架構側重于壓力的分散，強調的是服務的分散化，微服務側重與能力的分散，更強調服務的專業化和精細分工，從實踐的角度來看，微服務架構通常是分布式服務架構，反之則未必成立，所以，選擇微服務通常意味著需要解決分布式架構的各種難題。

<aside> 💡

注意：對于架構的發展，從單體架構 → 垂直架構 → 分布式架構 → 微服務架構。

所有的架構都是為了更好的服務產品，合適的才是最好的。

</aside>

微服務帶來的挑戰

隨著產品的復雜性和流量的增加, 技術架構也在不斷的發?變化. 不論是早期的單體架構, 還是現在?泛使?的微服務架構, 都是為了更好的服務產品, 解決問題.

微服務架構帶來好處的同時, 也?臨著?些挑戰, 從單體服務轉向微服務意味著管理更加復雜. 接下來我們從優勢和挑戰兩個??分析?下微服務架構

優勢

易開發和維護. 每個微服務負責的業務?較清晰, 體量?, 開發和維護成本降低。
容錯性?，?個服務發?故障, 可以使故障隔離在單個服務中, 不影響整體服務故障。
擴展性好，每個服務都是獨?運?的, 我們可以結合項?實際情況進?擴展, 按需伸縮。
技術選型靈活，每個微服務都是單獨的團隊來運維，可以根據業務特點和團隊特點，選擇適合的技術棧。

挑戰雖然微服務具備很多的優勢, 但由于服務數的增加, 服務治理也是我們?臨的巨?挑戰。

服務依賴，隨著服務的數量增多, 服務之間的關系也會變得更加復雜. ?個服務的更改, 需要考慮對其他服務的影響。
運維成本. ?個業務流程會涉及多個微服務共同完成, 有更多的服務需要編譯, 部署, 運?, 甚?可能是不同的編程語?, 不同的運?環境, 當然也需要集群來處理故障轉移等. 這對于運維?員??, 挑戰是巨?的。
開發和測試. ?個業務流程可能涉及多個微服務共同完成, 服務調?引??絡延遲, 不可靠的?絡, 如何進?容錯處理等問題. 這對開發和測試??, 難度也會提升。
服務監控. 在?個單體結構中, 很容易實現服務的監控. 因為所有功能都在?個服務中, 微服務架構下, 不僅需要對整個鏈路進?監控, 還需要對每?個服務實現監控。
負載均衡. 微服務架構中的服務實例數量可能?常龐?，因此需要有效的服務發現和負載均衡機制來管理請求流量和保證?可?性。
….

微服務解決?案- Spring Cloud

什么是Spring Cloud

看一下官網是怎么說的：Spring Cloud

Spring Cloud 提供了?些可以讓開發?員快速構建分布式服務的?具, ?如配置管理, 服務發現, 熔斷，智能路由等.。他們可以在任何分布式環境中很好的?作。

簡單來說，Spring Cloud就是分布式微服務架構的一站式解決方案，是微服務架構落地的多種技術的集合。

?如:

Distributed/versioned configuration 分布式版本配置
Service registration and discovery 服務注冊和發現
Routing 路由
Service-to-service calls 服務調?
Load balancing 負載均衡
Circuit Breakers 斷路器
Distributed messaging 分布式消息
....

<aside> 💡

Spring Cloud 并不是Spring 團隊研發的框架, 它只是把?些?較優秀的解決微服務架構中常 ?問題的開源框架基于SpringCloud規范進?了整合, 并基于SpringBoot的?格,對這些組件進?封裝, 屏蔽掉了復雜的配置和實現原理. 為開發者提供了開箱即?的微服務開發體驗. 這些開源技術的框架是由各個公司來維護的. Spring Cloud 就是這些微服務的?管家.

</aside>

就可以理解為：

買房之后需要裝修，裝修時，需要買家電，電視，空調，洗衣機，冰箱等。然后這個時候來了一個企業，出了一些套餐：

套餐一：電視1 + 空調1 + 洗衣機2 + 冰箱3，

套餐二：電視2 + 空調1 + 洗衣機2 + 冰箱4

……..

Spring Cloud就類似這個企業

Spring Cloud和SpringBoot的版本對應關系

由于Spring Cloud的所有子項目都依賴SpringBoot，所以SpringBoot和SpringCloud的版本之間也存在一定的對應關系。

這邊建議一一對應版本信息，如果不對應的話后續可能會出現一些版本問題上的錯誤。

SpringCloud的實現方案

在SpringCloud的規范下，有很多實現，其中最為出名的是：

Spring Cloud Netflix
Spring Cloud Alibaba

Spring Cloud Netflix

SpringCloudNetflix是NetflixOSS(NetflixOpenSourceSoftware)在SpringCloud規范下的實現。

包含的組件及其主要功能大致如下：

Eureka: 服務注冊和發現
Zuul: 服務?關
Ribbon: 負載均衡
Feign: 服務調?組件
Hystrix: 斷路器, 提供服務熔斷和限流
Hystrix Dashboard: 監控?板
……….

在很?的?段時間?, Spring Cloud ?度被泛指 Spring Cloud Netflix. Spring Cloud?直以來把 Netflix OSS 套件作為其官?默認的?站式解決?案. 然?, Netflix公司在2018年前后宣布其核?組件Hystrix、Ribbon、Zuul等均進?維護狀態, Spring Cloud 也被迫宣布刪除這些維護模塊.

<aside> 💡

spring-cloud-netflix 并沒有從Spring Cloud的依賴中完全刪除, 只是從2020.0版本起, 他只管理Eureka

</aside>

Spring Cloud Netflix 在很多公司都有?規模使?, ?旦停?更新, 短期看影響不?, 但?期顯然是不合適的, Spring Cloud官?也提供了?些替換建議。

Netflix	推薦替代品	說明
Hystrix	Resilience4j	Hystrix也推薦大家使用Resilience4j代替自己
Hystrix Dashboard / Turbine	Micrometer + Monitoring System	說白了，監控這件事交給更專業的組件去做
Ribbon	Spring Cloud Loadbalancer	忍不住了，Spring終究親自出手
Zuul 1	Spring Cloud Gateway	忍不住了，Spring終究親自出手
Archaius 1	Spring Boot外部化配置 + Spring Cloud配置	比Netflix實現的更好、更強大

Spring Cloud Alibaba

Spring Cloud Alibaba是阿里巴巴基于Spring Cloud生態推出的一站式微服務解決方案?，集成了阿里巴巴的開源中間件和云服務組件，提供分布式應用開發、服務治理、配置管理等核心功能，是Spring Cloud第二代實現的主要組成部分。??它填補了Spring Cloud Netflix停更后的空白，成為當前主流的微服務實現方案。??主要由 Nacos、Sentinel、Seata 等組件組成。

Spring Cloud 實現對?

功能	SpringCloud官方	Spring Cloud Netflix	Spring Cloud Alibaba
服務注冊/發現	Eureka	Eureka	Nacos
服務調用	OpenFeign	Feign	Dubbo
配置中心	SpringCloudConfig	Archaius	Nacos
服務網關	SpringCloudGateway	Zuul	SpringCloudGateway
負載均衡	SpringCloud LoadBalance	Ribbon	Dubbo