前言

從本章節開始，我們學習 Spring Cloud Alibaba 相關微服務元件。

Spring Cloud Alibaba 介紹

Spring Cloud Alibaba 致力於提供微服務開發的一站式解決方案。此專案包含開發分散式應用微服務的必需元件，方便開發者通過 Spring Cloud 程式設計模型輕鬆使用這些元件來開發分散式應用服務。

依託 Spring Cloud Alibaba，只需要新增一些註解和少量配置，就可以將 Spring Cloud 應用接入阿里微服務解決方案，通過阿里中介軟體來迅速搭建分散式應用系統。

Spring Cloud Alibaba 功能

1. 「服務限流降級 Sentinel」：支援 WebServlet，WebFlux，OpenFeign，RestTemplate，Dubbo，Gateway，Zuul 限流降級功能的接入。可以在執行時通過控制檯實時修改限流降級規則，並且還支援限流降級度量指標監控。
2. 「服務註冊與發現 Nacos」：適配 Spring Cloud 服務註冊與發現標準，預設集成了 Ribbon 的支援。
3. 「分散式配置管理 Nacos」：支援分散式系統中的外部化配置，配置更改時自動重新整理。
4. 「RPC 服務 Dubbo」：擴充套件 Spring Cloud 客戶端 RestTemplate 和 OpenFeign 以支援呼叫 Dubbo RPC 服務。
5. 「訊息驅動 RocketMQ」：基於 Spring Cloud Stream 為微服務應用構建訊息驅動能力。
6. 「分散式事務 Seata」：支援高效能且易於使用的分散式事務解決方案。
7. 「阿里雲物件儲存 OSS」：大規模，安全，低成本，高度可靠的雲端儲存服務。支援隨時隨地在任何應用程式中儲存和訪問任何型別的資料。
8. 「分散式任務排程 SchedulerX」：提供秒級、精準、高可靠、高可用的定時（基於 Cron 表示式）任務排程服務。同時提供分散式的任務執行模型，如網格任務。網格任務支援海量子任務均勻分配到所有 Worker（schedulerx-client）上執行。
9. 「阿里雲簡訊服務 SMS」：覆蓋全球的簡訊服務，友好、高效、智慧的通訊能力，幫助企業迅速搭建客戶觸達通道。

Spring Cloud Alibaba 元件

• Nacos：阿里巴巴開源產品，一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。
• Sentinel：面向分散式服務架構的輕量級流量控制產品，把流量作為切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。
• RocketMQ：一款開源的分散式訊息系統，基於高可用分散式叢集技術，提供低延時的、高可靠的訊息釋出與訂閱服務。
• Dubbo：Apache Dubbo™ 是一款高效能 Java RPC 框架。
• Seata：阿里巴巴開源產品，一個易於使用的高效能微服務分散式事務解決方案。
• Alibaba Cloud ACM：一款在分散式架構環境中對應用配置進行集中管理和推送的應用配置中心產品。
• Alibaba Cloud OSS：阿里雲物件儲存服務（Object Storage Service，簡稱 OSS），是阿里雲提供的海量、安全、低成本、高可靠的雲端儲存服務。您可以在任何應用、任何時間、任何地點儲存和訪問任意型別的資料。
• Alibaba Cloud SchedulerX：阿里中介軟體團隊開發的一款分散式任務排程產品，提供秒級、精準、高可靠、高可用的定時（基於 Cron 表示式）任務排程服務。
• Alibaba Cloud SMS：覆蓋全球的簡訊服務，友好、高效、智慧的互聯化通訊能力，幫助企業迅速搭建客戶觸達通道。

什麼是註冊中心

服務註冊中心是服務實現服務化管理的核心元件，類似於目錄服務的作用，主要用來儲存服務資訊，譬如提供者 url 串、路由資訊等。服務註冊中心是微服務架構中最基礎的設施之一。

註冊中心可以說是微服務架構中的“通訊錄”，它記錄了服務和服務地址的對映關係。在分散式架構中，服務會註冊到這裡，當服務需要呼叫其它服務時，就到這裡找到服務的地址，進行呼叫。

簡單理解就是：在沒有註冊中心時候，服務間呼叫需要知道被當服務調方的具體地址（寫死的 ip:port）。更換部署地址，就不得不修改呼叫當中指定的地址。而有了註冊中心之後，每個服務在呼叫別人的時候只需要知道服務名稱（軟編碼）就好，地址都會通過註冊中心根據服務名稱獲取到具體的服務地址進行呼叫。

舉個現實生活中的例子，比如說，我們手機中的通訊錄的兩個使用場景：

❝

當我想給張三打電話時，那我需要在通訊錄中按照名字找到張三，然後就可以找到他的手機號撥打電話。—— 服務發現

李四辦了手機號並把手機號告訴了我，我把李四的號碼存進通訊錄，後續，我就可以從通訊錄找到他。—— 服務註冊

通訊錄 —— ？什麼角色（服務註冊中心）

❞

總結：服務註冊中心的作用就是「服務的註冊」和「服務的發現」。

常見的註冊中心

• Netflix Eureka
• Alibaba Nacos
• HashiCorp Consul
• Apache ZooKeeper
• CoreOS Etcd
• CNCF CoreDNS

CAP 原則與 BASE 理論

CAP 原則

CAP 原則又稱 CAP 定理，指的是在一個分散式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分割槽容錯性），三者不可得兼。

CAP 由 Eric Brewer 在 2000 年 PODC 會議上提出。該猜想在提出兩年後被證明成立，成為我們熟知的 CAP 定理。CAP 三者不可兼得。

取捨策略

CAP 三個特性只能滿足其中兩個，那麼取捨的策略就共有三種：

• 「CA without P」：如果不要求P（不允許分割槽），則C（強一致性）和A（可用性）是可以保證的。但放棄 P 的同時也就意味著放棄了系統的擴充套件性，也就是分散式節點受限，沒辦法部署子節點，這是違背分散式系統設計的初衷的。
• 「CP without A」：如果不要求A（可用），相當於每個請求都需要在伺服器之間保持強一致，而P（分割槽）會導致同步時間無限延長（也就是等待資料同步完才能正常訪問服務），一旦發生網路故障或者訊息丟失等情況，就要犧牲使用者的體驗，等待所有資料全部一致了之後再讓使用者訪問系統。設計成 CP 的系統其實不少，最典型的就是分散式資料庫，如 Redis、HBase 等。對於這些分散式資料庫來說，資料的一致性是最基本的要求，因為如果連這個標準都達不到，那麼直接採用關係型資料庫就好，沒必要再浪費資源來部署分散式資料庫。
• 「AP without C」：要高可用並允許分割槽，則需放棄一致性。一旦分割槽發生，節點之間可能會失去聯絡，為了高可用，每個節點只能用本地資料提供服務，而這樣會導致全域性資料的不一致性。典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完。這其實就是先在 A（可用性）方面保證系統可以正常的服務，然後在資料的一致性方面做了些犧牲，雖然多少會影響一些使用者體驗，但也不至於造成使用者購物流程的嚴重阻塞。

總結

現如今，對於多數大型網際網路應用的場景，主機眾多、部署分散，而且現在的叢集規模越來越大，節點只會越來越多，所以節點故障、網路故障是常態，因此分割槽容錯性也就成為了一個分散式系統必然要面對的問題。那麼就只能在 C 和 A 之間進行取捨。但對於傳統的專案就可能有所不同，拿銀行的轉賬系統來說，涉及到金錢的對於資料一致性不能做出一絲的讓步，C 必須保證，出現網路故障的話，寧可停止服務，可以在 A 和 P 之間做取捨。

總而言之，沒有最好的策略，好的系統應該是根據業務場景來進行架構設計的，只有適合的才是最好的。

BASE 理論

CAP 理論已經提出好多年了，難道真的沒有辦法解決這個問題嗎？也許可以做些改變。比如 C 不必使用那麼強的一致性，可以先將資料存起來，稍後再更新，實現所謂的 “最終一致性”。

這個思路又是一個龐大的問題，同時也引出了第二個理論 BASE 理論。

❝

BASE：全稱 Basically Available（基本可用），Soft state（軟狀態），和 Eventually consistent（最終一致性）三個短語的縮寫，來自 ebay 的架構師提出。

❞

BASE 理論是對 CAP 中一致性和可用性權衡的結果，其來源於對大型網際網路分散式實踐的總結，是基於 CAP 定理逐步演化而來的。其核心思想是：

❝

既然無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。

❞

Basically Available（基本可用）

基本可用是指分散式系統在出現故障的時候，允許損失部分可用性（例如響應時間、功能上的可用性）。需要注意的是，基本可用絕不等價於系統不可用。

• 響應時間上的損失：正常情況下搜尋引擎需要在 0.5 秒之內返回給使用者相應的查詢結果，但由於出現故障（比如系統部分機房發生斷電或斷網故障），查詢結果的響應時間增加到了 1~2 秒。
• 功能上的損失：購物網站在購物高峰（如雙十一）時，為了保護系統的穩定性，部分消費者可能會被引導到一個降級頁面。

Soft state（軟狀態）

什麼是軟狀態呢？相對於原子性而言，要求多個節點的資料副本都是一致的，這是一種 “硬狀態”。

軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分散式儲存中一般一份資料會有多個副本，允許不同副本資料同步的延時就是軟狀態的體現。

Eventually consistent（最終一致性）

系統不可能一直是軟狀態，必須有個時間期限。在期限過後，應當保證所有副本保持資料一致性。從而達到資料的最終一致性。這個時間期限取決於網路延時，系統負載，資料複製方案設計等等因素。

實際上，不只是分散式系統使用最終一致性，關係型資料庫在某個功能上，也是使用最終一致性的，比如備份，資料庫的複製都是需要時間的，這個複製過程中，業務讀取到的值就是舊值。當然，最終還是達成了資料一致性。這也算是一個最終一致性的經典案例。

總結

總的來說，BASE 理論面向的是大型高可用可擴充套件的分散式系統，和傳統事務的 ACID 是相反的，它完全不同於 ACID 的強一致性模型，而是通過犧牲強一致性來獲得可用性，並允許資料在一段時間是不一致的。

為什麼需要註冊中心

瞭解了什麼是註冊中心，那麼我們繼續談談，為什麼需要註冊中心。在分散式系統中，我們不僅僅是需要在註冊中心找到服務和服務地址的對映關係這麼簡單，我們還需要考慮更多更復雜的問題：

• 服務註冊後，如何被及時發現
• 服務宕機後，如何及時下線
• 服務如何有效的水平擴充套件
• 服務發現時，如何進行路由
• 服務異常時，如何進行降級
• 註冊中心如何實現自身的高可用

這些問題的解決都依賴於註冊中心。簡單看，註冊中心的功能有點類似於 DNS 伺服器或者負載均衡器，而實際上，註冊中心作為微服務的基礎元件，可能要更加複雜，也需要更多的靈活性和時效性。所以我們還需要學習更多 Spring Cloud 微服務元件協同完成應用開發。

註冊中心解決了以下問題：

• 服務管理
• 服務之間的自動發現
• 服務的依賴關係管理

Nacos 介紹

Nacos 是 Alibaba 公司推出的開源工具，用於實現分散式系統的服務發現與配置管理。英文全稱 Dynamic Naming and Configuration Service，Na 為 Naming/NameServer 即註冊中心，co 為 Configuration 即配置中心，Service 是指該註冊/配置中心都是以服務為核心。服務（Service）是 Nacos 世界的一等公民。

❝

官網是這樣說的：一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。

❞

Nacos 致力於發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，可以快速實現動態服務發現、服務配置、服務元資料及流量管理。

Nacos 可以更敏捷和容易地構建、交付和管理微服務平臺。 Nacos 是構建以“服務”為中心的現代應用架構的服務基礎設施。

使用 Nacos 簡化服務發現、配置管理、服務治理及管理的解決方案，讓微服務的發現、管理、共享、組合更加容易。

Nacos 安裝

環境準備

Nacos 依賴 Java 環境來執行。如果您是從程式碼開始構建並執行 Nacos，還需要為此配置 Maven 環境，請確保是在以下版本環境中安裝使用:

• JDK 1.8+；
• Maven 3.2.x+。

下載原始碼或者安裝包

可以通過原始碼和發行包兩種方式來獲取 Nacos。

原始碼方式

從 Github 上下載原始碼方式。

git clone https://github.com/alibaba/nacos.git
cd nacos/
mvn -Prelease-nacos -Dmaven.test.skip=true clean install -U  
ls -al distribution/target/

// change the $version to your actual path
cd distribution/target/nacos-server-$version/nacos/bin

發行包方式

您可以從 https://github.com/alibaba/nacos/releases 下載最新穩定版本的 nacos-server 包。

啟動伺服器

Linux/Unix/Mac

在 Nacos 的解壓目錄 nacos/bin 目錄下啟動。

啟動命令（standalone 代表著單機模式執行，非叢集模式）:

sh startup.sh -m standalone

如果您使用的是 ubuntu 系統，或者執行指令碼報錯提示符號找不到，可嘗試如下執行：

bash startup.sh -m standalone

Windows

啟動命令：

cmd startup.cmd

或者雙擊 startup.cmd 執行檔案。

訪問

訪問：http://localhost:8848/nacos/ ，預設使用者名稱/密碼是 nacos/nacos。

關閉伺服器

Linux/Unix/Mac

sh shutdown.sh

相關推薦