從今天開始，我們將以Java后端技術(shù)為切入點，深入探討微服務(wù)架構(gòu)。本章的重點將聚焦于微服務(wù)中最關(guān)鍵的環(huán)節(jié)之一：服務(wù)發(fā)現(xiàn)與注冊。文章將循序漸進(jìn)，由淺入深，逐步引領(lǐng)你進(jìn)入微服務(wù)的廣闊世界。不論你是技術(shù)新手還是經(jīng)驗豐富的專家，我都希望通過這篇文章，能夠為你提供獨特而有價值的見解與收獲。

好的，我們開始！

單體架構(gòu)vs微服務(wù)架構(gòu)

單體架構(gòu)

首先，我們來看看以前的單體架構(gòu)。一個歸檔包（例如WAR格式）通常包含了應(yīng)用程序的所有功能和邏輯，這種結(jié)構(gòu)使得我們將其稱為單體應(yīng)用。單體應(yīng)用的設(shè)計理念強調(diào)將所有功能模塊打包成一個整體，便于部署和管理。這種架構(gòu)模式被稱為單體應(yīng)用架構(gòu)，意指通過一個單一的WAR包來承載整個應(yīng)用的所有責(zé)任和功能。

圖片

正如我們所展示的這張簡單示例圖所示，我們可以更深入地分析單體架構(gòu)的優(yōu)缺點，以便全面理解其在軟件開發(fā)和系統(tǒng)設(shè)計中的影響。

微服務(wù)架構(gòu)

微服務(wù)的核心理念是將傳統(tǒng)的單體應(yīng)用程序根據(jù)業(yè)務(wù)需求進(jìn)行拆分，將其分解為多個獨立的服務(wù)，從而實現(xiàn)徹底的解耦。每個微服務(wù)專注于特定的功能或業(yè)務(wù)邏輯，遵循“一個服務(wù)只做一件事”的原則，類似于操作系統(tǒng)中的進(jìn)程。這樣的設(shè)計使得每個服務(wù)都可以獨立部署，甚至可以擁有自己的數(shù)據(jù)庫，從而提高了系統(tǒng)的靈活性和可維護(hù)性。

圖片

通過這種方式，各個小服務(wù)相互獨立，能夠更有效地應(yīng)對業(yè)務(wù)變化，快速迭代開發(fā)和發(fā)布，同時降低了系統(tǒng)整體的復(fù)雜性，這就是微服務(wù)架構(gòu)的本質(zhì)。當(dāng)然，微服務(wù)架構(gòu)同樣存在其優(yōu)缺點，因為沒有任何一種“銀彈”能夠完美解決所有問題。接下來，讓我們深入分析一下這些優(yōu)缺點：

優(yōu)點

• 服務(wù)小而內(nèi)聚：微服務(wù)將應(yīng)用拆分為多個獨立服務(wù)，每個服務(wù)專注于特定功能，使得系統(tǒng)更具靈活性和可維護(hù)性。與傳統(tǒng)單體應(yīng)用相比，修改幾行代碼往往需要了解整個系統(tǒng)的架構(gòu)和邏輯，而微服務(wù)架構(gòu)則允許開發(fā)人員僅專注于相關(guān)的功能，提升了開發(fā)效率。
• 簡化開發(fā)過程：不同團(tuán)隊可以并行開發(fā)和部署各自負(fù)責(zé)的服務(wù)，這提高了開發(fā)效率和發(fā)布頻率。
• 按需伸縮：微服務(wù)的松耦合特性允許根據(jù)業(yè)務(wù)需求對各個服務(wù)進(jìn)行獨立擴(kuò)展和部署，便于根據(jù)流量變化動態(tài)調(diào)整資源，優(yōu)化性能。
• 前后端分離：作為Java開發(fā)人員，我們可以專注于后端接口的安全性和性能，而不必關(guān)注前端的用戶交互體驗。
• 容錯性：某個服務(wù)的失敗不會影響整個系統(tǒng)的可用性，提高了系統(tǒng)的可靠性。

缺點

• 運維復(fù)雜性增加：管理多個服務(wù)增加了運維的復(fù)雜性，而不僅僅是一個WAR包，這大大增加了運維人員的工作量，涉及的技術(shù)棧（如Kubernetes、Docker、Jenkins等）也更為復(fù)雜。
• 通信成本：服務(wù)之間的相互調(diào)用需要網(wǎng)絡(luò)通信，可能導(dǎo)致延遲和性能問題。
• 數(shù)據(jù)一致性挑戰(zhàn)：分布式系統(tǒng)中，維護(hù)數(shù)據(jù)一致性和處理分布式事務(wù)變得更加困難。
• 性能監(jiān)控與問題定位：需要更多的監(jiān)控工具和策略來跟蹤各個服務(wù)的性能，問題排查變得復(fù)雜。

應(yīng)用場景

所以微服務(wù)也并不是適合所有項目。他只適合部分場景這里列舉一些典型案例：

• 大型復(fù)雜項目：微服務(wù)架構(gòu)通過將系統(tǒng)拆分為多個小型服務(wù)，降低了每個服務(wù)的復(fù)雜性，使得團(tuán)隊能夠更加專注于各自負(fù)責(zé)的功能模塊，從而顯著提升開發(fā)和維護(hù)的效率。
• 快速迭代項目：微服務(wù)架構(gòu)能夠使得不同團(tuán)隊獨立開發(fā)和發(fā)布各自的服務(wù)，從而實現(xiàn)更高頻率的迭代和更快的市場反應(yīng)。
• 并發(fā)高的項目：微服務(wù)架構(gòu)則提供了靈活的彈性伸縮能力，各個服務(wù)可以根據(jù)需求獨立擴(kuò)展，確保系統(tǒng)在高并發(fā)情況下依然能保持良好的性能和穩(wěn)定性。

好的，關(guān)于微服務(wù)的基本概念我們已經(jīng)介紹完畢。接下來，我們將深入探討微服務(wù)架構(gòu)中至關(guān)重要的一環(huán)：服務(wù)注冊與發(fā)現(xiàn)。這一部分是微服務(wù)生態(tài)系統(tǒng)的核心，直接影響到系統(tǒng)的靈活性和可擴(kuò)展性。

注冊中心

從上面的討論中，我們可以看到，微服務(wù)架構(gòu)的核心在于將各個模塊獨立分開，以實現(xiàn)更好的靈活性和可維護(hù)性。然而，這種模塊化設(shè)計也帶來了網(wǎng)絡(luò)傳輸上的消耗，因此，理解微服務(wù)之間是如何進(jìn)行網(wǎng)絡(luò)調(diào)用的變得尤為重要。

接下來，我們將逐步探討微服務(wù)之間的通信方式，以及這些方式如何影響系統(tǒng)的整體性能。

調(diào)用方式

讓我們先思考一個關(guān)鍵問題：在微服務(wù)架構(gòu)中，如何有效地維護(hù)復(fù)雜的調(diào)用關(guān)系，以確保各個服務(wù)之間的協(xié)調(diào)與通信順暢？

如果你對微服務(wù)還不太熟悉，不妨換個角度考慮：我們的電腦是如何實現(xiàn)對其他網(wǎng)站的調(diào)用和訪問的？

固定調(diào)用

我們最簡單的做法是將 IP 地址或域名硬編碼在我們的代碼中，以便直接進(jìn)行調(diào)用。例如，考慮以下這段代碼示例：

//1：服務(wù)之間通過RestTemplate調(diào)用，url寫死
String url = "http://localhost:8020/order/findOrderByUserId/"+id;
User result = restTemplate.getForObject(url,User.class);

//2：類似還有其他http工具調(diào)用
String url = "http://localhost:8020/order/findOrderByUserId/" + id;
OkHttpClient client = new OkHttpClient();
Request request = new Request.Builder()
        .url(url)
        .build();
try (Response response = client.newCall(request).execute()) {
    String jsonResponse = response.body().string();
    // 處理 jsonResponse 對象。省略代碼

從表面上看，雖然將 IP 地址或域名硬編碼在代碼中似乎是一個簡單的解決方案，但實際上這并不是一個明智的做法。就像我們在訪問百度搜索時，不會在瀏覽器中輸入其 IP 地址，而是使用更為便捷和易記的域名。微服務(wù)之間的通信同樣如此，每個微服務(wù)都有自己獨特的服務(wù)名稱。

在這里，域名服務(wù)器的作用非常關(guān)鍵，它負(fù)責(zé)存儲域名與 IP 地址的對應(yīng)關(guān)系，從而使我們能夠準(zhǔn)確地調(diào)用相應(yīng)的服務(wù)器進(jìn)行請求和響應(yīng)。微服務(wù)架構(gòu)中也存在類似的機(jī)制，這就是我們所說的“服務(wù)發(fā)現(xiàn)與注冊中心”?？梢韵胂螅@個注冊中心就像是微服務(wù)的“域名服務(wù)器”，它存儲了各個微服務(wù)的名稱和它們的網(wǎng)絡(luò)位置。

圖片

在配置域名時，我們需要在 DNS 記錄中填寫各種信息；而在微服務(wù)的注冊中心中，類似的配置工作也同樣重要，只是通常是在配置文件中完成。當(dāng)你的服務(wù)啟動時，它會自動向注冊中心注冊自己的信息，確保其他服務(wù)能夠找到并調(diào)用它。

"域名"調(diào)用

因此，當(dāng)我們進(jìn)行服務(wù)調(diào)用時，整個過程將變得更加熟悉和直觀。例如，考慮下面這段代碼示例：

//使用微服務(wù)名發(fā)起調(diào)用
String url = "http://mall‐order/order/findOrderByUserId/"+id;
List<Order> orderList = restTemplate.getForObject(url, List.class);

當(dāng)然，這其中涉及許多需要細(xì)致實現(xiàn)的技術(shù)細(xì)節(jié)，但我們在初步理解時，可以先關(guān)注服務(wù)發(fā)現(xiàn)與注冊中心的核心功能。簡而言之，它們的主要目的是為了方便微服務(wù)之間的調(diào)用，減少開發(fā)者在服務(wù)通信時所需處理的復(fù)雜性。

通過引入服務(wù)發(fā)現(xiàn)與注冊中心，我們不再需要手動維護(hù)大量的 IP 地址與服務(wù)名稱之間的關(guān)系。

設(shè)計思路

作為注冊中心，它的主要功能是有效維護(hù)各個微服務(wù)的信息，例如它們的IP地址（當(dāng)然，這些地址可以是內(nèi)網(wǎng)的）。鑒于注冊中心本身也是一個服務(wù)，因此在微服務(wù)架構(gòu)中，它可以被視為一個重要的組件。每個微服務(wù)在進(jìn)行注冊和發(fā)現(xiàn)之前，都必須進(jìn)行適當(dāng)?shù)呐渲?，才能確保它們能夠相互識別和通信。

這就類似于在本地配置一個DNS服務(wù)器，如果沒有這樣的配置，我們就無法通過域名找到相應(yīng)的IP地址，進(jìn)而無法進(jìn)行有效的網(wǎng)絡(luò)通信。

圖片

在這個系統(tǒng)中，健康監(jiān)測扮演著至關(guān)重要的角色，其主要目的在于確?？蛻舳四軌蚣皶r獲知服務(wù)器的狀態(tài)，尤其是在服務(wù)器發(fā)生故障時，盡管這種監(jiān)測無法做到完全實時。健康監(jiān)測的重要性在于，我們的微服務(wù)架構(gòu)中，每個模塊通常會啟動多個實例。盡管這些實例的功能相同，目的在于分擔(dān)請求負(fù)載，但它們的可用性卻可能有所不同。

圖片

例如，同一個服務(wù)名稱可能會對應(yīng)多個IP地址。然而，如果其中某個IP對應(yīng)的服務(wù)出現(xiàn)故障，客戶端就不應(yīng)該再嘗試調(diào)用這個服務(wù)的IP。相反，應(yīng)該優(yōu)先選擇其他可用的IP，這樣就能夠有效實現(xiàn)高可用性。

接下來談?wù)勜?fù)載均衡。在這里需要注意的是，每個服務(wù)節(jié)點僅將其IP地址注冊到注冊中心，而注冊中心本身并不負(fù)責(zé)具體調(diào)用哪個IP。這一切都完全取決于客戶端的設(shè)計和實現(xiàn)。因此，在之前討論域名調(diào)用的部分中提到，這里面的細(xì)節(jié)實際上還有很多。

注冊中心的角色相對簡單，它的主要職責(zé)是收集和維護(hù)可用的IP地址，并將這些信息提供給客戶端。具體的實現(xiàn)細(xì)節(jié)和操作流程，可以參考下面的圖片

圖片

實戰(zhàn)

這樣一來，關(guān)于系統(tǒng)架構(gòu)的各個方面，我們基本上都已經(jīng)有了全面的了解。接下來，我們可以直接進(jìn)入實踐環(huán)節(jié)，進(jìn)行具體的使用演示。在這里，我們將以Spring Cloud Alibaba為例，選擇Nacos作為我們的服務(wù)發(fā)現(xiàn)與注冊中心。

準(zhǔn)備工作

JDK：這是開發(fā)必備的基礎(chǔ)環(huán)境。

Maven：仍然會用maven進(jìn)行項目的依賴管理。并啟動Springboot項目。

Nacos Server：你需要自己搭建好一個nacos服務(wù)端。

Nacos Docker 快速開始

如果你本身沒有nacos，我建議你可以在本地通過Docker快速搭建一個Nacos實例。具體步驟可以參考官方文檔中的快速入門指南：Nacos Quick Start with Docker。

通過這種方式，你可以在最短的時間內(nèi)搭建起一個穩(wěn)定的Nacos服務(wù)。

windows 本地

當(dāng)然，你也可以選擇在本地直接搭建Nacos服務(wù)。按照以下步驟進(jìn)行操作，這里就以此為例進(jìn)行說明。首先下載：https://github.com/alibaba/nacos/releases

然后本地直接解壓后運行命令即可成功，如下：

startup.cmd -m standalone

圖片

打開本地地址：http://127.0.0.1:8848/nacos/index.html

圖片

Spring Boot 啟動

那么現(xiàn)在，我們可以直接開始啟動本地的兩個服務(wù)：一個是用戶模塊，另一個是訂單模塊。此外，我們還將創(chuàng)建一個公共模塊，以便于共享通用的功能和資源。為了簡化演示，我們將編寫最基本的代碼，主要目的是為學(xué)習(xí)和演示提供一個清晰的框架。我們的項目結(jié)構(gòu)如圖所示：

圖片

首先，公共模塊的主要職責(zé)是導(dǎo)入所有服務(wù)共享的依賴，這樣可以確保各個模塊之間的一致性和復(fù)用性。這里就不演示了。我們只看下order和user模塊的依賴。他倆其實是一樣的，目的就是讓自己的服務(wù)注冊到中心去。

<dependencies>
    <dependency>
        <groupId>com.xiaoyu.mall</groupId>
        <artifactId>mall-common</artifactId>
        <version>0.0.1-SNAPSHOT</version>
        <scope>compile</scope>
    </dependency>

    <!-- nacos服務(wù)注冊與發(fā)現(xiàn) -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
</dependencies>

請?zhí)砑右恍┍匾呐渲梦募畔?，下面的?nèi)容相對簡單。不過，每個服務(wù)都需要獨立指定一個微服務(wù)名稱，這里僅提供一個示例供參考。

server:
  port: 8040

spring:
  application:
    name: mall-user  #微服務(wù)名稱

  #配置nacos注冊中心地址
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
        namespace: 9f545878-ca6b-478d-8a5a-5321d58b3ca3

命名空間

如果不特別配置命名空間（namespace），則系統(tǒng)會默認(rèn)將資源部署在公共空間（public）中。在這種情況下，如果需要使用其他命名空間，用戶必須自行創(chuàng)建一個新的命名空間。例如：

圖片

好的，現(xiàn)在我們來啟動這兩個服務(wù)，看看運行效果。這樣一來，兩個服務(wù)都成功注冊了。不過需要特別注意的是，如果希望這兩個服務(wù)能夠相互通信，務(wù)必將它們部署在同一個命名空間下。

圖片

我們也可以查看每個服務(wù)的詳細(xì)信息，這些信息包含了豐富的內(nèi)容。

圖片

示例代碼

此時，我們并沒有集成任何其他工具，而只是單獨將 Nacos 的 Maven 依賴集成到我們的項目中。在這個階段，我們已經(jīng)可以通過注解的方式來使服務(wù)名稱生效，這樣就無需在代碼中硬編碼 IP 地址。接下來，我們來看看配置類的具體代碼如下：

@Bean
@LoadBalanced  //mall-order => ip:port
public RestTemplate restTemplate() {
    return new RestTemplate();
}

然后，我們可以將用戶端的業(yè)務(wù)代碼編寫得更加簡潔明了，如下所示：

@RequestMapping(value = "/findOrderByUserId/{id}")
public R  findOrderByUserId(@PathVariable("id") Integer id) {
    log.info("根據(jù)userId:"+id+"查詢訂單信息");
    // ribbon實現(xiàn)，restTemplate需要添加@LoadBalanced注解
    // mall-order  ip:port
    String url = "http://mall-order/order/findOrderByUserId/"+id;

    R result = restTemplate.getForObject(url,R.class);
    return result;
}

我們的訂單端業(yè)務(wù)代碼相對簡單，呈現(xiàn)方式如下：

@RequestMapping("/findOrderByUserId/{userId}")
public R findOrderByUserId(@PathVariable("userId") Integer userId) {
    log.info("根據(jù)userId:"+userId+"查詢訂單信息");
    List<OrderEntity> orderEntities = orderService.listByUserId(userId);
    return R.ok().put("orders", orderEntities);
}

我們來看下調(diào)用情況，以確認(rèn)是否確實能夠?qū)崿F(xiàn)預(yù)期的效果。

圖片

第三方組件OpenFeign

在單體架構(gòu)中，你會直接使用 RestTemplate 類來調(diào)用自身的其他服務(wù)？顯然是不可能的，因此，在這種情況下，借助流行的第三方組件 OpenFeign 可以顯著簡化服務(wù)之間的交互。OpenFeign 提供了一種聲明式的方式來定義 HTTP 客戶端，使得我們可以更方便地進(jìn)行服務(wù)調(diào)用，同時保持代碼的可讀性和可維護(hù)性。

首先，我們需要在項目的 pom.xml 文件中添加相應(yīng)的 Maven 依賴。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

初次之外，還需要加一個注解在啟動類上：

@SpringBootApplication
@EnableFeignClients //掃描和注冊feign客戶端bean定義
public class MallUserFeignDemoApplication {、
  public static void main(String[] args) {
      SpringApplication.run(MallUserFeignDemoApplication.class, args);
  }
}

以前寫ip地址那里換成類的時候，我們需要單獨定義一下服務(wù)類：

@FeignClient(value = "mall-order",path = "/order")
public interface OrderFeignService {
    @RequestMapping("/findOrderByUserId/{userId}")
    R findOrderByUserId(@PathVariable("userId") Integer userId);
}

這樣一來，我們在調(diào)用服務(wù)時就可以采用更加簡潔和直觀的寫法。是不是覺得這種方式使用起來更加舒服？

@Autowired
OrderFeignService orderFeignService;

@RequestMapping(value = "/findOrderByUserId/{id}")
public R  findOrderByUserId(@PathVariable("id") Integer id) {
    //feign調(diào)用
    R result = orderFeignService.findOrderByUserId(id);
    return result;
}

同樣可以正常調(diào)用成功。

圖片

不過，在實施過程中還有一些需要注意的細(xì)節(jié)。許多開發(fā)者傾向于將這些調(diào)用封裝到一個單獨的微服務(wù)模塊——即 api-service，并將其作為子項目依賴于當(dāng)前的微服務(wù)。這種做法能夠有效地將外部 API 調(diào)用與內(nèi)部服務(wù)邏輯進(jìn)行區(qū)分，避免將不同類型的功能混雜在同一個包中?？聪拢?/p>

圖片

好的，到此為止，我們已經(jīng)完成了一個完整的調(diào)用流程。這一切的設(shè)置和配置為我們后續(xù)的開發(fā)奠定了堅實的基礎(chǔ)。接下來，我們就可以專注于實現(xiàn)實際的業(yè)務(wù)邏輯，比如數(shù)據(jù)庫的調(diào)用與存儲操作。

學(xué)習(xí)進(jìn)階

接下來我們將深入探討相關(guān)內(nèi)容。由于許多細(xì)節(jié)尚未詳盡講解，之前的實戰(zhàn)環(huán)節(jié)主要旨在讓大家對服務(wù)注冊與發(fā)現(xiàn)中心的作用有一個初步的理解。為了更好地掌握這一主題，我們需要關(guān)注一些關(guān)鍵問題，例如客戶端的負(fù)載均衡、心跳監(jiān)測以及服務(wù)注冊與發(fā)現(xiàn)等。

接下來，我們將通過分析源碼，帶領(lǐng)大家全面了解 Nacos 是如何高效解決注冊中心的三大核心任務(wù)的。

gRPC

在這里，我想先介紹一下 Nacos 的實現(xiàn)方式。自 Nacos 2.1 版本起，官方不再推薦使用 HTTP 等傳統(tǒng)的 RPC 調(diào)用方式，雖然這些方式仍然是被支持的。如果你計劃順利升級到 Nacos，需特別關(guān)注一個配置參數(shù)：在 application.properties 文件中設(shè)置 nacos.core.support.upgrade.from.1x=true。

在之前的分析中，我們已經(jīng)探討過 Nacos 1.x 版本的實現(xiàn)，那個版本確實是通過常規(guī)的 HTTP 調(diào)用進(jìn)行交互的，Nacos 服務(wù)端會實現(xiàn)一些 Controller，就像我們自己構(gòu)建的微服務(wù)一樣，源碼的可讀性非常高，容易理解。調(diào)用方式如下面的圖示所示：

圖片

但是，自 Nacos 2.1 版本以來，系統(tǒng)進(jìn)行了重要的升級，轉(zhuǎn)而采用了 gRPC。gRPC 是一個開源的遠(yuǎn)程過程調(diào)用（RPC）框架，最初由 Google 開發(fā)。它利用 HTTP/2 作為傳輸協(xié)議，提供更高效的網(wǎng)絡(luò)通信，并使用 Protocol Buffers 作為消息格式，從而實現(xiàn)了快速且高效的數(shù)據(jù)序列化和反序列化。

圖片

性能優(yōu)化：gRPC 基于 HTTP/2 協(xié)議，支持多路復(fù)用，允許在一個連接上同時發(fā)送多個請求，減少延遲和帶寬使用。

二進(jìn)制負(fù)載： 與基于文本的 JSON/XML 相比，協(xié)議緩沖區(qū)序列化為緊湊的二進(jìn)制格式。

流控與雙向流：gRPC 支持流式數(shù)據(jù)傳輸，能夠?qū)崿F(xiàn)客戶端和服務(wù)器之間的雙向流通信，適用于實時應(yīng)用。

解決 GC 問題：通過真實的長連接，減少了頻繁連接和斷開的對象創(chuàng)建，進(jìn)而降低了 GC（垃圾回收）壓力，提升了系統(tǒng)性能。

Nacos 升級使用 gRPC 是基于其眾多優(yōu)點，但我也必須強調(diào)，沒有任何技術(shù)是所謂的“銀彈”，這也是我一貫的觀點。最明顯的缺點是系統(tǒng)復(fù)雜性的增加。因此，在選擇技術(shù)方案時，必須根據(jù)自身的業(yè)務(wù)需求做出明智的決策。

在新版 Nacos 的源碼中，你會發(fā)現(xiàn)許多以 .proto 后綴命名的文件。這些文件定義了消息的結(jié)構(gòu)，其中每條消息代表一個小的信息邏輯記錄，包含一系列稱為字段（fields）的名稱-值對。這種定義方式使得數(shù)據(jù)的傳輸和解析變得更加高效和靈活。

例如，我們可以隨便找一個 Nacos 中的緩沖區(qū)文件。

圖片

雖然這不是我們討論的重點，但值得指出的是，gRPC 的引入將為 Nacos 帶來顯著的性能優(yōu)化。盡管我們在這里不深入探討其具體實現(xiàn)，但了解這一點是很重要的，因為在后續(xù)的所有調(diào)用中，gRPC 都將發(fā)揮關(guān)鍵作用。

服務(wù)注冊

當(dāng)我們的服務(wù)啟動時，會發(fā)生一個重要的過程：服務(wù)實例會向 Nacos 發(fā)起一次請求，以完成注冊。如下圖示：

image

為了提高效率，我們不再逐步進(jìn)行源碼追蹤，盡管之前已經(jīng)詳細(xì)講解過如何查看 Spring 的自動配置。今天，我們將直接關(guān)注關(guān)鍵源碼的位置，以快速理解 Nacos 的實現(xiàn)細(xì)節(jié)。

@Override
public void register(Registration registration) {
  //此處省略非關(guān)鍵代碼
    NamingService namingService = namingService();
    String serviceId = registration.getServiceId();
    String group = nacosDiscoveryProperties.getGroup();

    Instance instance = getNacosInstanceFromRegistration(registration);

    try {
        namingService.registerInstance(serviceId, group, instance);
        log.info("nacos registry, {} {} {}:{} register finished", group, serviceId,
                instance.getIp(), instance.getPort());
    }
    //此處省略非關(guān)鍵代碼

在服務(wù)注冊的過程中，我們可以觀察到構(gòu)建了一些自身的 IP 和端口信息。這些信息對于服務(wù)的正確識別和調(diào)用至關(guān)重要。此外，這里值得一提的是命名空間（Namespace）的概念。命名空間在 Nacos 中用于實現(xiàn)租戶（用戶）粒度的隔離，這對于微服務(wù)架構(gòu)中的資源管理尤為重要。

命名空間的常見應(yīng)用場景之一是不同環(huán)境之間的隔離，比如開發(fā)、測試環(huán)境與生產(chǎn)環(huán)境的資源隔離。

圖片

接下來，我們將進(jìn)行一個服務(wù)調(diào)用，這里使用的是 gRPC 協(xié)議。實際上，這個過程可以簡化為一個方法調(diào)用。

private <T extends Response> T requestToServer(AbstractNamingRequest request, Class<T> responseClass)
        throws NacosException {
    try {
        request.putAllHeader(
                getSecurityHeaders(request.getNamespace(), request.getGroupName(), request.getServiceName()));
        Response response =
                requestTimeout < 0 ? rpcClient.request(request) : rpcClient.request(request, requestTimeout);
        //此處省略非關(guān)鍵代碼

服務(wù)端處理

當(dāng) Nacos 服務(wù)端接收到來自客戶端的 gRPC 調(diào)用請求后，會立即啟動一系列處理流程，以確保請求能夠得到有效響應(yīng)。關(guān)鍵代碼的實現(xiàn)細(xì)節(jié)可以參考下面這部分。

@Override
@TpsControl(pointName = "RemoteNamingServiceSubscribeUnSubscribe", name = "RemoteNamingServiceSubscribeUnsubscribe")
@Secured(action = ActionTypes.READ)
@ExtractorManager.Extractor(rpcExtractor = SubscribeServiceRequestParamExtractor.class)
public SubscribeServiceResponse handle(SubscribeServiceRequest request, RequestMeta meta) throws NacosException {
    String namespaceId = request.getNamespace();
    String serviceName = request.getServiceName();
    String groupName = request.getGroupName();
    String app = RequestContextHolder.getContext().getBasicContext().getApp();
    String groupedServiceName = NamingUtils.getGroupedName(serviceName, groupName);
    Service service = Service.newService(namespaceId, groupName, serviceName, true);
    Subscriber subscriber = new Subscriber(meta.getClientIp(), meta.getClientVersion(), app, meta.getClientIp(),
            namespaceId, groupedServiceName, 0, request.getClusters());
    ServiceInfo serviceInfo = ServiceUtil.selectInstancesWithHealthyProtection(serviceStorage.getData(service),
            metadataManager.getServiceMetadata(service).orElse(null), subscriber.getCluster(), false, true,
            subscriber.getIp());
    if (request.isSubscribe()) {
        clientOperationService.subscribeService(service, subscriber, meta.getConnectionId());
        NotifyCenter.publishEvent(new SubscribeServiceTraceEvent(System.currentTimeMillis(),
                NamingRequestUtil.getSourceIpForGrpcRequest(meta), service.getNamespace(), service.getGroup(),
                service.getName()));
    } else {
        clientOperationService.unsubscribeService(service, subscriber, meta.getConnectionId());
        NotifyCenter.publishEvent(new UnsubscribeServiceTraceEvent(System.currentTimeMillis(),
                NamingRequestUtil.getSourceIpForGrpcRequest(meta), service.getNamespace(), service.getGroup(),
                service.getName()));
    }
    return new SubscribeServiceResponse(ResponseCode.SUCCESS.getCode(), "success", serviceInfo);
}

這段代碼包括提取請求信息、創(chuàng)建相關(guān)對象、處理訂閱或取消訂閱的操作，并返回相應(yīng)的結(jié)果。通過這種方式，Nacos 可以高效管理微服務(wù)的服務(wù)發(fā)現(xiàn)和注冊功能。

心跳監(jiān)測

在 Nacos 2.1 版本之前，每個服務(wù)在運行時都會向注冊中心發(fā)送一次請求，以通知其當(dāng)前的存活狀態(tài)和正常性。這種機(jī)制雖然有效，但在高并發(fā)環(huán)境下可能會引入額外的網(wǎng)絡(luò)負(fù)擔(dān)和延遲。

然而，升級到 2.1 版本后，這一過程發(fā)生了顯著的變化。首先，我們需要思考一下心跳監(jiān)測的本質(zhì)。顯然，心跳監(jiān)測是一種定期檢查機(jī)制，這意味著服務(wù)會在設(shè)定的時間間隔內(nèi)自動發(fā)送心跳信號以確認(rèn)其存活狀態(tài)。因此，可以合理地推測，這一功能在客戶端實現(xiàn)為一個定時任務(wù)，它會按照預(yù)定的時間頻率定期向注冊中心報告服務(wù)的健康狀態(tài)。

為了更好地理解這一機(jī)制的實現(xiàn)，我們接下來將重點關(guān)注相關(guān)的關(guān)鍵代碼。

public final void start() throws NacosException {
       // 省略一些代碼
        
        clientEventExecutor = new ScheduledThreadPoolExecutor(2, r -> {
            Thread t = new Thread(r);
            t.setName("com.alibaba.nacos.client.remote.worker");
            t.setDaemon(true);
            return t;
        });
        
        // 省略一些代碼
        
        clientEventExecutor.submit(() -> {
            while (true) {
                try {
                    if (isShutdown()) {
                        break;
                    }
                    ReconnectContext reconnectContext = reconnectionSignal
                            .poll(keepAliveTime, TimeUnit.MILLISECONDS);
                    if (reconnectContext == null) {
                        // check alive time.
                        if (System.currentTimeMillis() - lastActiveTimeStamp >= keepAliveTime) {
                            boolean isHealthy = healthCheck();
                            if (!isHealthy) {
                                 // 省略一些代碼

我將與健康監(jiān)測無關(guān)的代碼基本去除了，這樣你可以更加直觀地觀察 Nacos 是如何進(jìn)行實例健康監(jiān)測的。由于健康監(jiān)測的核心目的在于確認(rèn)服務(wù)的可用性，因此這一過程的實現(xiàn)相對簡單。

在這段代碼中，我們可以清晰地看到，健康監(jiān)測并不涉及任何復(fù)雜的數(shù)據(jù)傳輸。其主要功能僅僅是向服務(wù)器發(fā)送請求，以檢測服務(wù)器是否能夠成功響應(yīng)。這種設(shè)計極大地降低了網(wǎng)絡(luò)開銷，使得監(jiān)測過程更加高效。

圖片

服務(wù)端的代碼同樣清晰且簡單。如下所示：

@Override
@TpsControl(pointName = "HealthCheck")
public HealthCheckResponse handle(HealthCheckRequest request, RequestMeta meta) {
    return new HealthCheckResponse();
}

總體而言，這種優(yōu)化顯著減少了網(wǎng)絡(luò) I/O 的消耗，提升了系統(tǒng)的整體性能。乍一看，似乎并沒有做什么復(fù)雜的操作，但這并不意味著我們就無法判斷客戶端是否能夠正常連接。實際上，關(guān)鍵的判斷邏輯被設(shè)計在外層代碼中。

Connection connection = connectionManager.getConnection(GrpcServerConstants.CONTEXT_KEY_CONN_ID.get());
RequestMeta requestMeta = new RequestMeta();
requestMeta.setClientIp(connection.getMetaInfo().getClientIp());
requestMeta.setConnectionId(GrpcServerConstants.CONTEXT_KEY_CONN_ID.get());
requestMeta.setClientVersion(connection.getMetaInfo().getVersion());
requestMeta.setLabels(connection.getMetaInfo().getLabels());
requestMeta.setAbilityTable(connection.getAbilityTable());
//這里刷新下時間。用來代表它確實存活
connectionManager.refreshActiveTime(requestMeta.getConnectionId());
prepareRequestContext(request, requestMeta, connection);
//這次處理的返回
Response response = requestHandler.handleRequest(request, requestMeta);

別著急，服務(wù)端同樣運行著一個定時任務(wù)，負(fù)責(zé)定期掃描和檢查各個客戶端的狀態(tài)。我們看下：

public void start() {
    initConnectionEjector();
    // Start UnHealthy Connection Expel Task.
    RpcScheduledExecutor.COMMON_SERVER_EXECUTOR.scheduleWithFixedDelay(() -> {
        runtimeConnectionEjector.doEject();
        MetricsMonitor.getLongConnectionMonitor().set(connections.size());
    }, 1000L, 3000L, TimeUnit.MILLISECONDS);
//省略部分代碼，doEject方法再往后走，你就會發(fā)現(xiàn)這樣一段代碼
//outdated connections collect.
for (Map.Entry<String, Connection> entry : connections.entrySet()) {
    Connection client = entry.getValue();
    if (now - client.getMetaInfo().getLastActiveTime() >= KEEP_ALIVE_TIME) {
        outDatedConnections.add(client.getMetaInfo().getConnectionId());
    } else if (client.getMetaInfo().pushQueueBlockTimesLastOver(300 * 1000)) {
        outDatedConnections.add(client.getMetaInfo().getConnectionId());
    }
}
//省略部分代碼，

通過這些分析，你基本上已經(jīng)掌握了核心概念和實現(xiàn)細(xì)節(jié)。我們不需要再多做贅述。我們繼續(xù)往下看。

負(fù)載均衡

談到負(fù)載均衡，首先我們需要確保本地?fù)碛幸环莘?wù)器列表，以便于合理地分配負(fù)載。因此，關(guān)鍵在于我們?nèi)绾螐淖灾行墨@取這些可用服務(wù)的信息。那么，具體來說，我們應(yīng)該如何在本地有效地發(fā)現(xiàn)和獲取這些服務(wù)呢？

服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)的機(jī)制會隨著實例的增加或減少而動態(tài)變化，因此我們需要定期更新可用服務(wù)列表。這就引出了一個重要的設(shè)計考量：為什么不將服務(wù)發(fā)現(xiàn)的檢索任務(wù)直接整合到心跳任務(wù)中呢？

首先，心跳任務(wù)的主要目的是監(jiān)測服務(wù)實例的健康狀態(tài)，確保它們能夠正常響應(yīng)請求。而服務(wù)發(fā)現(xiàn)則側(cè)重于及時更新和獲取當(dāng)前可用的服務(wù)實例信息。這兩者的目的明顯不同，因此將它們混合在一起可能會導(dǎo)致邏輯上的混淆和功能上的復(fù)雜性。

此外，兩者的時間間隔也各有不同。心跳監(jiān)測可能需要更頻繁地進(jìn)行，以及時發(fā)現(xiàn)和處理服務(wù)故障，而服務(wù)發(fā)現(xiàn)的頻率可以根據(jù)具體需求適當(dāng)調(diào)整。基于這些原因，將心跳監(jiān)測和服務(wù)發(fā)現(xiàn)分開成兩個獨立的定時任務(wù)，顯然是更合理的選擇。

接下來，讓我們深入研究服務(wù)發(fā)現(xiàn)的關(guān)鍵代碼，看看具體是如何實現(xiàn)這一機(jī)制的：

public void run() {
    //省略部分代碼
    if (serviceObj == null) {
        serviceObj = namingClientProxy.queryInstancesOfService(serviceName, groupName, clusters, 0, false);
        serviceInfoHolder.processServiceInfo(serviceObj);
        lastRefTime = serviceObj.getLastRefTime();
        return;
    }
    
    if (serviceObj.getLastRefTime() <= lastRefTime) {
        serviceObj = namingClientProxy.queryInstancesOfService(serviceName, groupName, clusters, 0, false);
        serviceInfoHolder.processServiceInfo(serviceObj);
    }
    //省略部分代碼

當(dāng)然，接下來我們將探討服務(wù)器端的處理邏輯，以下是服務(wù)端處理的關(guān)鍵代碼部分：

public QueryServiceResponse handle(ServiceQueryRequest request, RequestMeta meta) throws NacosException {
    String namespaceId = request.getNamespace();
    String groupName = request.getGroupName();
    String serviceName = request.getServiceName();
    Service service = Service.newService(namespaceId, groupName, serviceName);
    String cluster = null == request.getCluster() ? "" : request.getCluster();
    boolean healthyOnly = request.isHealthyOnly();
    ServiceInfo result = serviceStorage.getData(service);
    ServiceMetadata serviceMetadata = metadataManager.getServiceMetadata(service).orElse(null);
    result = ServiceUtil.selectInstancesWithHealthyProtection(result, serviceMetadata, cluster, healthyOnly, true,
            NamingRequestUtil.getSourceIpForGrpcRequest(meta));
    return QueryServiceResponse.buildSuccessResponse(result);
}

這樣一來，我們便能夠獲得一些關(guān)鍵的服務(wù)信息。

負(fù)載均衡算法

如果同一個微服務(wù)存在多個 IP 地址，那么在進(jìn)行服務(wù)調(diào)用時，我們該如何選擇具體的服務(wù)器呢？通常，我們會想到使用 Nginx 作為服務(wù)端的負(fù)載均衡工具。然而，除了在服務(wù)器端進(jìn)行負(fù)載均衡之外，我們同樣可以在微服務(wù)客戶端配置負(fù)載算法，以優(yōu)化請求的分發(fā)。

此時，我們要明確的是，這部分邏輯實際上并不屬于 Nacos 的職責(zé)范圍，而是由另一個組件——Ribbon 來負(fù)責(zé)。Ribbon 專注于實現(xiàn)客戶端負(fù)載均衡，確保在微服務(wù)架構(gòu)中，客戶端能夠智能地選擇合適的服務(wù)器進(jìn)行調(diào)用，從而提高系統(tǒng)的性能和穩(wěn)定性。

接下來，我們可以深入查看 Ribbon 的關(guān)鍵代碼，了解它是如何選擇服務(wù)器的。，具體來說，Ribbon 通過一個名為 LoadBalance 的類來攔截請求，并根據(jù)預(yù)設(shè)的負(fù)載均衡策略來挑選合適的服務(wù)器。

圖片

讓我們來深入分析一下關(guān)鍵代碼，其實所有的負(fù)載均衡算法邏輯都集中在 getServer 方法的實現(xiàn)中。

public <T> T execute(String serviceId, LoadBalancerRequest<T> request, Object hint)
        throws IOException {
    ILoadBalancer loadBalancer = getLoadBalancer(serviceId);
    Server server = getServer(loadBalancer, hint);
    if (server == null) {
        throw new IllegalStateException("No instances available for " + serviceId);
    }
    RibbonServer ribbonServer = new RibbonServer(serviceId, server,
            isSecure(server, serviceId),
            serverIntrospector(serviceId).getMetadata(server));

    return execute(serviceId, ribbonServer, request);
}

我們可以對負(fù)載均衡策略進(jìn)行局部配置，以便根據(jù)特定的業(yè)務(wù)需求和場景靈活調(diào)整服務(wù)調(diào)用的行為。

#被調(diào)用的微服務(wù)名
mall‐order:
 ribbon:
    #指定使用Nacos提供的負(fù)載均衡策略（優(yōu)先調(diào)用同一集群的實例，基于隨機(jī)&權(quán)重）
    NFLoadBalancerRuleClassName:com.alibaba.cloud.nacos.ribbon.NacosRule

當(dāng)然，我們也可以進(jìn)行全局配置，以便在整個系統(tǒng)范圍內(nèi)統(tǒng)一管理負(fù)載均衡策略和參數(shù)。

@Bean
public IRule ribbonRule() {
    // 指定使用Nacos提供的負(fù)載均衡策略（優(yōu)先調(diào)用同一集群的實例，基于隨機(jī)權(quán)重）
    return new NacosRule();
}

總結(jié)

隨著本文的深入探討，我們對微服務(wù)架構(gòu)中的服務(wù)發(fā)現(xiàn)與注冊機(jī)制有了更全面的認(rèn)識。從單體架構(gòu)的局限性到微服務(wù)的靈活性，我們見證了架構(gòu)演進(jìn)的歷程。服務(wù)發(fā)現(xiàn)與注冊作為微服務(wù)通信的基石，其重要性不言而喻。通過Nacos這一強大的注冊中心，我們不僅實現(xiàn)了服務(wù)的動態(tài)注冊與發(fā)現(xiàn)，還通過心跳監(jiān)測、負(fù)載均衡等機(jī)制，確保了服務(wù)的高可用性和穩(wěn)定性。

在技術(shù)選型上，Nacos的gRPC實現(xiàn)展示了其在性能優(yōu)化方面的潛力，同時也帶來了系統(tǒng)復(fù)雜性的挑戰(zhàn)。然而，通過精心設(shè)計的客戶端和服務(wù)端代碼，我們能夠有效地管理服務(wù)實例，實現(xiàn)服務(wù)的快速響應(yīng)和負(fù)載均衡。這些機(jī)制的實現(xiàn)，不僅提升了系統(tǒng)的伸縮性和容錯性，也為微服務(wù)的快速發(fā)展提供了堅實的基礎(chǔ)。