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

好的，我們開始！

單體架構vs微服務架構

單體架構

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

圖片

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

微服務架構

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

圖片

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

優(yōu)點

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

缺點

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

應用場景

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

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

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

注冊中心

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

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

調用方式

讓我們先思考一個關鍵問題：在微服務架構中，如何有效地維護復雜的調用關系，以確保各個服務之間的協(xié)調與通信順暢？

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

固定調用

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

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

//2：類似還有其他http工具調用
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 地址，而是使用更為便捷和易記的域名。微服務之間的通信同樣如此，每個微服務都有自己獨特的服務名稱。

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

圖片

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

"域名"調用

因此，當我們進行服務調用時，整個過程將變得更加熟悉和直觀。例如，考慮下面這段代碼示例：

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

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

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

設計思路

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

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

圖片

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

圖片

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

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

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

圖片

實戰(zhàn)

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

準備工作

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

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

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

Nacos Docker 快速開始

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

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

windows 本地

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

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

startup.cmd -m standalone

圖片

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

圖片

Spring Boot 啟動

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

圖片

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

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

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

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

server:
  port: 8040

spring:
  application:
    name: mall-user  #微服務名稱

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

命名空間

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

圖片

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

圖片

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

圖片

示例代碼

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

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

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

@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è)務代碼相對簡單，呈現(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);
}

我們來看下調用情況，以確認是否確實能夠實現(xiàn)預期的效果。

圖片

第三方組件OpenFeign

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

首先，我們需要在項目的 pom.xml 文件中添加相應的 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地址那里換成類的時候，我們需要單獨定義一下服務類：

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

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

@Autowired
OrderFeignService orderFeignService;

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

同樣可以正常調用成功。

圖片

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

圖片

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

學習進階

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

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

gRPC

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

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

圖片

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

圖片

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

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

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

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

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

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

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

圖片

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

服務注冊

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

image

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

@Override
public void register(Registration registration) {
  //此處省略非關鍵代碼
    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());
    }
    //此處省略非關鍵代碼

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

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

圖片

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

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);
        //此處省略非關鍵代碼

服務端處理

當 Nacos 服務端接收到來自客戶端的 gRPC 調用請求后，會立即啟動一系列處理流程，以確保請求能夠得到有效響應。關鍵代碼的實現(xiàn)細節(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)建相關對象、處理訂閱或取消訂閱的操作，并返回相應的結果。通過這種方式，Nacos 可以高效管理微服務的服務發(fā)現(xiàn)和注冊功能。

心跳監(jiān)測

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

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

為了更好地理解這一機制的實現(xià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)測無關的代碼基本去除了，這樣你可以更加直觀地觀察 Nacos 是如何進行實例健康監(jiān)測的。由于健康監(jiān)測的核心目的在于確認服務的可用性，因此這一過程的實現(xiàn)相對簡單。

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

圖片

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

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

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

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);

別著急，服務端同樣運行著一個定時任務，負責定期掃描和檢查各個客戶端的狀態(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)細節(jié)。我們不需要再多做贅述。我們繼續(xù)往下看。

負載均衡

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

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

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

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

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

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

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);
    }
    //省略部分代碼

當然，接下來我們將探討服務器端的處理邏輯，以下是服務端處理的關鍵代碼部分：

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);
}

這樣一來，我們便能夠獲得一些關鍵的服務信息。

負載均衡算法

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

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

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

圖片

讓我們來深入分析一下關鍵代碼，其實所有的負載均衡算法邏輯都集中在 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);
}

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

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

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

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

總結

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

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