1. 分布式的基本概念

1.1 什么是分布式系統(tǒng)？

• 分布式系統(tǒng)（Distributed System）：由多臺服務(wù)器（或節(jié)點(diǎn)）協(xié)同工作，對外提供一個整體服務(wù)。
• 不同節(jié)點(diǎn)之間通過網(wǎng)絡(luò)通信來協(xié)同處理請求或共享數(shù)據(jù)，相對于「單體應(yīng)用」而言，可以帶來更高的吞吐量、可用性和靈活擴(kuò)展能力。

1.2 分布式 vs. 單體架構(gòu)

• 單體架構(gòu)
  • 所有業(yè)務(wù)模塊部署在同一應(yīng)用實(shí)例中，垂直擴(kuò)容（升級服務(wù)器硬件）成為主要的擴(kuò)展方式。
  • 優(yōu)點(diǎn)：開發(fā)調(diào)試較簡單，部署方便。
  • 缺點(diǎn)：當(dāng)應(yīng)用規(guī)模過大時，任何一個模塊出現(xiàn)故障或性能瓶頸，都會影響整個系統(tǒng)，并且無法靈活擴(kuò)容單個模塊。
• 分布式架構(gòu)
  • 將系統(tǒng)拆分成若干服務(wù)或節(jié)點(diǎn)，每個節(jié)點(diǎn)可以獨(dú)立運(yùn)行、獨(dú)立擴(kuò)容、獨(dú)立維護(hù)。
  • 優(yōu)點(diǎn)：更好的可擴(kuò)展性、可靠性，能處理更高并發(fā)和數(shù)據(jù)量。
  • 缺點(diǎn)：系統(tǒng)變得復(fù)雜，需要處理 網(wǎng)絡(luò)通信、數(shù)據(jù)一致性、運(yùn)維管理 等問題。

 （1）是一個程序拆分成多個模塊，每個模塊部署在不同虛擬機(jī)上，這叫分布式嗎？

?? 是的，這是最典型的分布式方式，叫“微服務(wù)架構(gòu)”。

每個模塊（比如訂單、用戶、商品服務(wù)）可以獨(dú)立開發(fā)、部署、伸縮，節(jié)點(diǎn)之間通過 REST API 或 RPC 調(diào)用通信。

（2）如果是一個程序本身部署多個虛擬機(jī)實(shí)例，這算分布式嗎？

?? 這叫集群部署，也算分布式的一種，但更準(zhǔn)確說是“分布式部署”或者“高可用集群”。

多個實(shí)例共享負(fù)載，提高并發(fā)處理能力和可用性，但它們屬于同一個服務(wù)模塊。

（3）多個虛擬機(jī)放在一臺云服務(wù)器上，還算分布式嗎？

??是的，從系統(tǒng)架構(gòu)角度看，只要是多個獨(dú)立進(jìn)程/服務(wù)協(xié)同工作，就算分布式。

但從容錯和可用性角度看：

• 如果多個虛擬機(jī)都在一臺物理服務(wù)器上，不能實(shí)現(xiàn)真正的容災(zāi)備份；
• 一旦這臺云服務(wù)器掛了，所有虛擬機(jī)都掛了。

（4）Redis 的哨兵模式可以部署在一個云服務(wù)器上嗎？

??可以，但不推薦。

• 哨兵模式本意是為了高可用自動故障轉(zhuǎn)移；
• 如果所有哨兵、主從節(jié)點(diǎn)都在一臺云服務(wù)器，一旦機(jī)器故障，高可用機(jī)制就失效了；
• 實(shí)際部署建議：至少部署在三臺機(jī)器（物理或云）上，防止單點(diǎn)故障。

Redis 的部署模式

（5）數(shù)據(jù)庫的分庫也能部署在一個云服務(wù)器上嗎？

??能，但也不推薦。

• 分庫是為了提升性能、解決單點(diǎn)瓶頸；
• 如果多個庫都在同一臺機(jī)器上，機(jī)器的CPU、內(nèi)存、磁盤IO是共享的，無法做到真正的擴(kuò)展與隔離；
• 一旦這臺機(jī)器宕機(jī)，所有庫都不可用。

1.3 分布式系統(tǒng)的核心挑戰(zhàn)

• 數(shù)據(jù)一致性：多節(jié)點(diǎn)同時修改同一數(shù)據(jù)，如何保證最終數(shù)據(jù)正確？
• 可用性：某個節(jié)點(diǎn)失敗不會影響整體服務(wù)。
• 可擴(kuò)展性：需要隨業(yè)務(wù)增長快速增加節(jié)點(diǎn)處理能力。
• 網(wǎng)絡(luò)延遲與可靠性：網(wǎng)絡(luò)抖動、分區(qū)故障等異常場景必須做好應(yīng)對策略（如重試、降級）。
• 系統(tǒng)復(fù)雜度：日志監(jiān)控、調(diào)試、部署都更加繁瑣。

2. 分布式架構(gòu)的主要組成部分

Spring Boot 下的分布式架構(gòu)通常包含以下幾個關(guān)鍵部分：

3. Spring Boot 分布式架構(gòu)的實(shí)現(xiàn)方式

• Redis 提供緩存和分布式鎖，提升性能
• Nacos/Eureka 讓微服務(wù)可以互相發(fā)現(xiàn)
• MQ 讓服務(wù)之間異步通信，減少耦合
• Seata 保證分布式事務(wù)一致性
• 負(fù)載均衡 + API 網(wǎng)關(guān) 讓服務(wù)更高效

3.1 分布式服務(wù)（微服務(wù)）

微服務(wù)（Microservices）是 架構(gòu)設(shè)計理念，它強(qiáng)調(diào)將一個大型應(yīng)用拆分成多個 獨(dú)立部署、獨(dú)立運(yùn)行 的小型服務(wù)，每個服務(wù)負(fù)責(zé)特定的業(yè)務(wù)邏輯。是否是微服務(wù) 不取決于是否運(yùn)行在 同一臺云服務(wù)器，而取決于它們是否是獨(dú)立的服務(wù)實(shí)例。

微服務(wù)的特點(diǎn)

• 獨(dú)立運(yùn)行：不同服務(wù)可以分開部署，即使運(yùn)行在同一臺云服務(wù)器上，也屬于不同的微服務(wù)。
• 獨(dú)立進(jìn)程：通常一個微服務(wù)運(yùn)行在一個 獨(dú)立的 JVM（不同的 Java 進(jìn)程），而不是多個模塊共享同一個 JVM。
• 獨(dú)立數(shù)據(jù)庫（推薦）：但不強(qiáng)制，多個微服務(wù)可以共享一個數(shù)據(jù)庫。

1. 微服務(wù)必須部署在不同的服務(wù)器上才算微服務(wù)嗎？不是，微服務(wù)可以部署在同一臺服務(wù)器上，只要它們是獨(dú)立的進(jìn)程（不同的 JVM 實(shí)例）。

例如：

• order-service.jar (端口 8081)
• stock-service.jar (端口 8082)
• payment-service.jar (端口 8083)

這些都是微服務(wù)，即使它們都在同一臺服務(wù)器上運(yùn)行。

2. 只要是同一個 JVM 里的多個模塊，就不能算是微服務(wù)？

• 是的，不能算微服務(wù)，如果多個模塊運(yùn)行在同一個 JVM（比如 Spring Boot 的 module1、module2 在同一個 application 里），它們更像是單體應(yīng)用的多個業(yè)務(wù)模塊。
• 微服務(wù)的關(guān)鍵是獨(dú)立部署和獨(dú)立進(jìn)程。

3. 多個微服務(wù)共享同一個數(shù)據(jù)庫，還叫微服務(wù)嗎？

• 是的，仍然可以叫微服務(wù)，但這會帶來分布式事務(wù)問題。
• 推薦的微服務(wù)架構(gòu) 是 每個微服務(wù)獨(dú)立數(shù)據(jù)庫，但現(xiàn)實(shí)中，很多公司還是會讓多個微服務(wù)共享數(shù)據(jù)庫，避免數(shù)據(jù)一致性問題。
• 共享數(shù)據(jù)庫的微服務(wù) 仍然是微服務(wù)，但會讓事務(wù)管理變得復(fù)雜。

• 含義：把一個龐大的單體應(yīng)用拆分成若干個服務(wù)，每個服務(wù)只負(fù)責(zé)一個“相對獨(dú)立的業(yè)務(wù)領(lǐng)域或功能”，稱之為“微服務(wù)”。
  • 示例：
    • UserService：專注處理用戶登錄、注冊、用戶信息管理
    • OrderService：負(fù)責(zé)訂單的創(chuàng)建、查詢、支付信息對接
    • ProductService：管理產(chǎn)品、庫存、定價等
    • PaymentService：處理支付渠道、賬務(wù)、對賬邏輯
• 好處：
  1. 解耦：每個服務(wù)都可獨(dú)立部署、升級，互不影響。
  2. 獨(dú)立擴(kuò)展：哪塊業(yè)務(wù)壓力大就擴(kuò)容對應(yīng)服務(wù)的節(jié)點(diǎn)，而不是整合到一起。
  3. 技術(shù)棧靈活：不同服務(wù)甚至可以用不同的語言或框架。

在 Spring Boot 中如何實(shí)現(xiàn)微服務(wù)？

• Spring Boot + Spring Cloud
• Spring Cloud 提供了微服務(wù)生態(tài)，包括：
  • 服務(wù)注冊與發(fā)現(xiàn)（Eureka, Nacos, Consul），讓各微服務(wù)在一個注冊中心上登記并獲取彼此的地址
  • 負(fù)載均衡（Ribbon 或 Spring Cloud LoadBalancer），在調(diào)用某個微服務(wù)時自動從多個實(shí)例中選一臺
  • 服務(wù)調(diào)用（Feign），通過 HTTP/REST 的方式去請求其他微服務(wù)
  • 熔斷、限流（Hystrix, Sentinel），在調(diào)用失效時防止雪崩
  • 網(wǎng)關(guān)（Spring Cloud Gateway），統(tǒng)一處理路由、鑒權(quán)、流量控制
• 服務(wù)間通信方式
  • HTTP/REST：最常見的形式，每個微服務(wù)暴露 RESTful API，其他微服務(wù)通過 HTTP 調(diào)用。
  • RPC：部分場景需要高性能的調(diào)用，可以使用 RPC（例如 Dubbo、gRPC），減少網(wǎng)絡(luò)開銷，提升效率。
  • 消息隊列：如果是異步調(diào)用場景，還會結(jié)合 MQ 來實(shí)現(xiàn)解耦與異步化。

3.2 服務(wù)注冊與發(fā)現(xiàn)（Service Discovery）

當(dāng)我們有了多個微服務(wù)之后，問題來了：如何讓它們相互找到對方？

• 傳統(tǒng)做法：在配置文件里寫死每個服務(wù)的地址。但一旦服務(wù)集群擴(kuò)容或 IP 地址變動，就要重新修改配置，非常麻煩。
• 分布式做法：服務(wù)注冊與發(fā)現(xiàn)。各個微服務(wù)在啟動時，自動向“注冊中心”報到，注冊中心會保存當(dāng)前可用的服務(wù)實(shí)例列表。其他服務(wù)要調(diào)用它時，只需要從注冊中心查到目標(biāo)服務(wù)的地址就行。

常見的注冊中心：

• Eureka（Netflix OSS）
• Nacos（阿里巴巴開源，功能更強(qiáng)大，也能做配置中心）
• Zookeeper（Apache 基金會項目，也能做服務(wù)注冊，但更多用于分布式協(xié)調(diào)）

在 Spring Boot + Spring Cloud 中配置服務(wù)注冊發(fā)現(xiàn)，大致流程：

1. 在 pom.xml 中引入對應(yīng)的依賴（例如 spring-cloud-starter-alibaba-nacos-discovery）。
2. 在 application.yml 中配置好注冊中心地址 server-addr: localhost:8848 等。
3. 啟動時，服務(wù)會自動注冊到 Nacos（或其他注冊中心）。

3.3 分布式配置中心

配置中心 主要解決的是“在分布式環(huán)境中，如何統(tǒng)一管理各個微服務(wù)的配置”，避免每個服務(wù)都各自持有不同的配置文件，難以維護(hù)。

• Spring Cloud Config：早期常用的配置中心，基于 Git 存儲配置
• Nacos Config：Nacos 同時提供注冊發(fā)現(xiàn)和配置管理
• Apollo（攜程開源）或 Disconf 等也可以

好處：

• 統(tǒng)一管理：所有配置信息都在一個地方（配置中心），修改后可實(shí)時生效。
• 動態(tài)更新：微服務(wù)在運(yùn)行時能監(jiān)控到配置變動，自動刷新，無需重啟。
• 區(qū)分環(huán)境：如 DEV, TEST, PROD 環(huán)境對應(yīng)不同配置。

3.4 分布式緩存（Redis 等）

在分布式環(huán)境下，數(shù)據(jù)庫通常成為性能瓶頸。為減少對數(shù)據(jù)庫的直接訪問和壓力，需要一個 高性能的分布式緩存。Redis 是最常用的選擇，它具有以下優(yōu)勢：

1. 內(nèi)存存儲，讀寫速度快。
2. 豐富的數(shù)據(jù)結(jié)構(gòu)（字符串、哈希、列表、集合、有序集合等）。
3. 支持 主從復(fù)制、Cluster 集群，適合分布式部署。
4. 常用于 緩存熱點(diǎn)數(shù)據(jù)、分布式 Session、分布式鎖 等場景。

使用 Redis 的關(guān)鍵點(diǎn)：

• 設(shè)計 合理的緩存鍵（key），比如 product:detail:{productId}。
• 設(shè)置 過期時間，避免緩存數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)長期不一致。
• 考慮 緩存穿透、緩存雪崩、緩存擊穿 等問題，并進(jìn)行對應(yīng)的防護(hù)（如 Bloom Filter, 加互斥鎖, 合理限流等）。

3.5 分布式鎖

在分布式環(huán)境中，如果多個節(jié)點(diǎn)同時對同一個資源進(jìn)行寫操作，就容易出現(xiàn)數(shù)據(jù)不一致或并發(fā)沖突。因此，需要一種分布式鎖來保證 在同一時間，只有一個節(jié)點(diǎn)可以獲取鎖，進(jìn)行資源操作。

常見方案：

• Redis 分布式鎖
  • 使用 SETNX（set if not exist） + EXPIRE 或 SET key value NX PX time 命令實(shí)現(xiàn)。
  • 注意要設(shè)置超時時間，避免鎖無法釋放導(dǎo)致死鎖。
  • 也要考慮鎖的續(xù)約和解鎖時的原子性操作（Lua 腳本），以避免誤刪他人的鎖。
• Zookeeper 分布式鎖
  • 利用 ZK 的臨時順序節(jié)點(diǎn)來競爭鎖，監(jiān)聽事件，一旦獲取鎖的節(jié)點(diǎn)斷開連接，就自動刪除節(jié)點(diǎn)，其他節(jié)點(diǎn)立即感知到并可重新競爭。

示例：基于 Redis 的簡易分布式鎖代碼（示例性，不是完整生產(chǎn)級）

String lockKey = "lock:order";
String lockVal = UUID.randomUUID().toString();
// 嘗試加鎖
Boolean success = redisTemplate.opsForValue().setIfAbsent(lockKey, lockVal, 10, TimeUnit.SECONDS);
if (Boolean.TRUE.equals(success)) {
    try {
        // 執(zhí)行業(yè)務(wù)邏輯
    } finally {
        // 解鎖時，先判斷鎖是否是自己加的
        String val = redisTemplate.opsForValue().get(lockKey);
        if (lockVal.equals(val)) {
            redisTemplate.delete(lockKey);
        }
    }
}

3.6 分布式事務(wù)

在單體應(yīng)用中，事務(wù)只需要依賴數(shù)據(jù)庫的本地事務(wù)（ACID）即可。但在分布式系統(tǒng)中，可能一個操作需要 跨多個微服務(wù)、跨多個數(shù)據(jù)庫，這時就出現(xiàn)了 分布式事務(wù) 問題：

• 例如，在電商場景下，創(chuàng)建訂單 時，要同時扣減庫存、生成支付記錄等，這些操作都在不同微服務(wù)里完成；如果其中某一步出錯，就需要回滾之前的操作。

常見分布式事務(wù)方案：

• 2PC（兩階段提交）：協(xié)調(diào)者告訴所有參與者先預(yù)提交，然后再統(tǒng)一提交或回滾。實(shí)現(xiàn)復(fù)雜，性能損耗大，適合對一致性要求極高的場景。
• TCC（Try-Confirm-Cancel）：業(yè)務(wù)系統(tǒng)自己實(shí)現(xiàn)各個操作的 “Try, Confirm, Cancel”，實(shí)現(xiàn)靈活，但開發(fā)成本高。
• Seata：阿里開源的分布式事務(wù)框架，提供 AT 模式（對 JDBC 層做代理），也提供 TCC 等模式。

Seata 示例

@GlobalTransactional
public void placeOrder(Order order) {
    // 跨服務(wù)調(diào)用
    inventoryService.decreaseStock(order.getProductId(), order.getQuantity());
    paymentService.processPayment(order);
    orderMapper.insert(order);
    // Seata 會在這里把整個調(diào)用過程進(jìn)行管理，可做到成功或回滾
}

在執(zhí)行過程中，如果其中一個調(diào)用報錯，Seata 就會通知其他服務(wù)進(jìn)行回滾。

3.7 分布式消息隊列

消息隊列 (Message Queue) 用于解耦系統(tǒng)、異步處理和削峰填谷。常見的 MQ 方案有：

• RabbitMQ：輕量級，支持事務(wù)與確認(rèn)機(jī)制，適合傳統(tǒng)企業(yè)應(yīng)用以及對消息可靠性要求高的場景。
• Apache Kafka：高吞吐，大規(guī)模數(shù)據(jù)流處理的“事實(shí)標(biāo)準(zhǔn)”，更多用于大數(shù)據(jù)、日志收集、流式處理等場景。
• RocketMQ：阿里開源的分布式消息中間件，和 Kafka 類似，也有較高的吞吐。

MQ 的作用：

• 解耦：比如，用戶下單后，需要發(fā)送優(yōu)惠券、通知物流、通知商家等，而如果所有這些操作都放在下單接口里，會導(dǎo)致耦合過高；使用 MQ，每個消費(fèi)者服務(wù)負(fù)責(zé)監(jiān)聽消息并執(zhí)行相應(yīng)的業(yè)務(wù)邏輯。
• 削峰填谷：在高峰時段，訂單系統(tǒng)可以快速寫入消息隊列，后臺處理系統(tǒng)再慢慢消費(fèi)，避免直接壓垮數(shù)據(jù)庫或其他服務(wù)。
• 異步：不需要同步等待消息處理完成，加快用戶請求的響應(yīng)速度。

3.8 API 網(wǎng)關(guān)與負(fù)載均衡

當(dāng)服務(wù)拆分越來越多，我們往往需要一個統(tǒng)一的 網(wǎng)關(guān) 來管理請求：

• 服務(wù)網(wǎng)關(guān)（如 Spring Cloud Gateway、Nginx、Kong）：
  • 統(tǒng)一對外提供訪問入口
  • 進(jìn)行路由分發(fā)，鑒權(quán)，限流，監(jiān)控等
  • 在微服務(wù)復(fù)雜時，可以屏蔽內(nèi)部服務(wù)接口的變化，對外提供穩(wěn)定的 API。
• 負(fù)載均衡：
  • 當(dāng)某個微服務(wù)有多個實(shí)例時，網(wǎng)關(guān)或負(fù)載均衡器需要把請求分散到各個實(shí)例上，避免其中一個實(shí)例被打滿。
  • 常見方式：Nginx 反向代理 或 Spring Cloud Ribbon （新版 Spring Cloud LoadBalancer）都可實(shí)現(xiàn)負(fù)載均衡。

4、整體流程與示例

4.1 典型電商微服務(wù)調(diào)用鏈

以 電商訂單 流程為例，來看看分布式系統(tǒng)下的一般調(diào)用。

1. 用戶 訪問 API 網(wǎng)關(guān)（或 Nginx），請求 /api/order/create 接口。
2. 網(wǎng)關(guān)解析路由規(guī)則，將請求轉(zhuǎn)發(fā)給 OrderService。
3. OrderService 調(diào)用 UserService 檢查用戶信息（比如積分、等級等）。
4. OrderService 調(diào)用 ProductService 檢查庫存、扣減庫存；同時查詢商品價格。
5. OrderService 寫入訂單數(shù)據(jù)庫，本地事務(wù)或分布式事務(wù)處理。
6. OrderService 向 MQ 發(fā)送消息，用于通知其他服務(wù)（如物流、積分系統(tǒng)等）。
7. MQ 的消費(fèi)者（如 LogisticsService）消費(fèi)消息并執(zhí)行下一步操作。

在這個過程中，會用到：

• 服務(wù)注冊中心（保證 OrderService 能動態(tài)發(fā)現(xiàn) ProductService 的地址）
• 分布式緩存（可能在 OrderService、ProductService 的查詢環(huán)節(jié)做緩存）
• 分布式鎖（避免多次重復(fù)扣減庫存）
• 分布式事務(wù)（如要保證扣庫存與下單一致）
• 消息隊列（通知其他異步任務(wù)）

4.2 部署模式

• 開發(fā)/測試環(huán)境：一般都是在本地 Docker 或者虛擬機(jī)里把注冊中心、MQ、Redis、數(shù)據(jù)庫等組件跑起來即可。
• 生產(chǎn)環(huán)境：會把各個服務(wù)獨(dú)立部署在多臺服務(wù)器（或容器云）上：
  • 注冊中心、配置中心（Nacos/Consul/Eureka）集群
  • Redis 高可用集群（主從+哨兵模式或 Redis Cluster）
  • MQ 集群（RabbitMQ 集群或 Kafka 集群）
  • 分布式文件系統(tǒng)（如 MinIO, FastDFS, OSS 等）
  • 后端數(shù)據(jù)存儲（MySQL 或者多分片數(shù)據(jù)庫），需要做讀寫分離或分庫分表
  • 若干微服務(wù)集群（UserService、OrderService...），通過容器編排（Kubernetes 或 Docker Swarm）進(jìn)行管理

到此這篇關(guān)于Java中的分布式（概念說明）的文章就介紹到這了,更多相關(guān)java分布式內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！