微服務架構——不可或缺的註冊中心

努力的小雨發表於2024-11-07

從今天開始，我們將以Java後端技術為切入點，深入探討微服務架構。本章的重點將聚焦於微服務中最關鍵的環節之一：服務發現與註冊。文章將循序漸進，由淺入深，逐步引領你進入微服務的廣闊世界。不論你是技術新手還是經驗豐富的專家，我都希望透過這篇文章，能夠為你提供獨特而有價值的見解與收穫。

好的，我們開始！

單體架構vs微服務架構

單體架構

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

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

微服務架構

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

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

優點

服務小而內聚：微服務將應用拆分為多個獨立服務，每個服務專注於特定功能，使得系統更具靈活性和可維護性。與傳統單體應用相比，修改幾行程式碼往往需要了解整個系統的架構和邏輯，而微服務架構則允許開發人員僅專注於相關的功能，提升了開發效率。
簡化開發過程：不同團隊可以並行開發和部署各自負責的服務，這提高了開發效率和釋出頻率。
按需伸縮：微服務的松耦合特性允許根據業務需求對各個服務進行獨立擴充套件和部署，便於根據流量變化動態調整資源，最佳化效能。
前後端分離：作為Java開發人員，我們可以專注於後端介面的安全性和效能，而不必關注前端的使用者互動體驗。
容錯性：某個服務的失敗不會影響整個系統的可用性，提高了系統的可靠性。

缺點

運維複雜性增加：管理多個服務增加了運維的複雜性，而不僅僅是一個WAR包，這大大增加了運維人員的工作量，涉及的技術棧（如Kubernetes、Docker、Jenkins等）也更為複雜。
通訊成本：服務之間的相互呼叫需要網路通訊，可能導致延遲和效能問題。
資料一致性挑戰：分散式系統中，維護資料一致性和處理分散式事務變得更加困難。
效能監控與問題定位：需要更多的監控工具和策略來跟蹤各個服務的效能，問題排查變得複雜。

應用場景

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

大型複雜專案：微服務架構透過將系統拆分為多個小型服務，降低了每個服務的複雜性，使得團隊能夠更加專注於各自負責的功能模組，從而顯著提升開發和維護的效率。
快速迭代專案：微服務架構能夠使得不同團隊獨立開發和釋出各自的服務，從而實現更高頻率的迭代和更快的市場反應。
併發高的專案：微服務架構則提供了靈活的彈性伸縮能力，各個服務可以根據需求獨立擴充套件，確保系統在高併發情況下依然能保持良好的效能和穩定性。

好的，關於微服務的基本概念我們已經介紹完畢。接下來，我們將深入探討微服務架構中至關重要的一環：服務註冊與發現。這一部分是微服務生態系統的核心，直接影響到系統的靈活性和可擴充套件性。

註冊中心

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

接下來，我們將逐步探討微服務之間的通訊方式，以及這些方式如何影響系統的整體效能。

呼叫方式

讓我們先思考一個關鍵問題：在微服務架構中，如何有效地維護複雜的呼叫關係，以確保各個服務之間的協調與通訊順暢？

如果你對微服務還不太熟悉，不妨換個角度考慮：我們的電腦是如何實現對其他網站的呼叫和訪問的？

固定呼叫

我們最簡單的做法是將 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 地址的對應關係，從而使我們能夠準確地呼叫相應的伺服器進行請求和響應。微服務架構中也存在類似的機制，這就是我們所說的“服務發現與註冊中心”。可以想象，這個註冊中心就像是微服務的“域名伺服器”，它儲存了各個微服務的名稱和它們的網路位置。

在配置域名時，我們需要在 DNS 記錄中填寫各種資訊；而在微服務的註冊中心中，類似的配置工作也同樣重要，只是通常是在配置檔案中完成。當你的服務啟動時，它會自動向註冊中心註冊自己的資訊，確保其他服務能夠找到並呼叫它。

"域名"呼叫

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

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

當然，這其中涉及許多需要細緻實現的技術細節，但我們在初步理解時，可以先關注服務發現與註冊中心的核心功能。簡而言之，它們的主要目的是為了方便微服務之間的呼叫，減少開發者在服務通訊時所需處理的複雜性。

透過引入服務發現與註冊中心，我們不再需要手動維護大量的 IP 地址與服務名稱之間的關係。

設計思路

作為註冊中心，它的主要功能是有效維護各個微服務的資訊，例如它們的IP地址（當然，這些地址可以是內網的）。鑑於註冊中心本身也是一個服務，因此在微服務架構中，它可以被視為一個重要的元件。每個微服務在進行註冊和發現之前，都必須進行適當的配置，才能確保它們能夠相互識別和通訊。

這就類似於在本地配置一個DNS伺服器，如果沒有這樣的配置，我們就無法透過域名找到相應的IP地址，進而無法進行有效的網路通訊。

在這個系統中，健康監測扮演著至關重要的角色，其主要目的在於確保客戶端能夠及時獲知伺服器的狀態，尤其是在伺服器發生故障時，儘管這種監測無法做到完全實時。健康監測的重要性在於，我們的微服務架構中，每個模組通常會啟動多個例項。儘管這些例項的功能相同，目的在於分擔請求負載，但它們的可用性卻可能有所不同。

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

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

註冊中心的角色相對簡單，它的主要職責是收集和維護可用的IP地址，並將這些資訊提供給客戶端。具體的實現細節和操作流程，可以參考下面的圖片

實戰

這樣一來，關於系統架構的各個方面，我們基本上都已經有了全面的瞭解。接下來，我們可以直接進入實踐環節，進行具體的使用演示。在這裡，我們將以Spring Cloud Alibaba為例，選擇Nacos作為我們的服務發現與註冊中心。

準備工作

JDK：這是開發必備的基礎環境。

Maven：仍然會用maven進行專案的依賴管理。並啟動Springboot專案。

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

Nacos Docker 快速開始

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

透過這種方式，你可以在最短的時間內搭建起一個穩定的Nacos服務。

windows 本地

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

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

startup.cmd -m standalone

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

Spring Boot 啟動

那麼現在，我們可以直接開始啟動本地的兩個服務：一個是使用者模組，另一個是訂單模組。此外，我們還將建立一個公共模組，以便於共享通用的功能和資源。為了簡化演示，我們將編寫最基本的程式碼，主要目的是為學習和演示提供一個清晰的框架。我們的專案結構如圖所示：

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

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

    <!-- nacos服務註冊與發現 -->
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
</dependencies>

請新增一些必要的配置檔案資訊，下面的內容相對簡單。不過，每個服務都需要獨立指定一個微服務名稱，這裡僅提供一個示例供參考。

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），則系統會預設將資源部署在公共空間（public）中。在這種情況下，如果需要使用其他名稱空間，使用者必須自行建立一個新的名稱空間。例如：

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

我們也可以檢視每個服務的詳細資訊，這些資訊包含了豐富的內容。

示例程式碼

此時，我們並沒有整合任何其他工具，而只是單獨將 Nacos 的 Maven 依賴整合到我們的專案中。在這個階段，我們已經可以透過註解的方式來使服務名稱生效，這樣就無需在程式碼中硬編碼 IP 地址。接下來，我們來看看配置類的具體程式碼如下：

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

然後，我們可以將使用者端的業務程式碼編寫得更加簡潔明瞭，如下所示：

@RequestMapping(value = "/findOrderByUserId/{id}")
public R  findOrderByUserId(@PathVariable("id") Integer id) {
    log.info("根據userId:"+id+"查詢訂單資訊");
    // ribbon實現，restTemplate需要新增@LoadBalanced註解
    // mall-order  ip:port
    String url = "http://mall-order/order/findOrderByUserId/"+id;

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

我們的訂單端業務程式碼相對簡單，呈現方式如下：

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

我們來看下呼叫情況，以確認是否確實能夠實現預期的效果。

第三方元件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;
}

同樣可以正常呼叫成功。

不過，在實施過程中還有一些需要注意的細節。許多開發者傾向於將這些呼叫封裝到一個單獨的微服務模組——即 api-service，並將其作為子專案依賴於當前的微服務。這種做法能夠有效地將外部 API 呼叫與內部服務邏輯進行區分，避免將不同型別的功能混雜在同一個包中。看下：

好的，到此為止，我們已經完成了一個完整的呼叫流程。這一切的設定和配置為我們後續的開發奠定了堅實的基礎。接下來，我們就可以專注於實現實際的業務邏輯，比如資料庫的呼叫與儲存操作。

學習進階

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

接下來，我們將透過分析原始碼，帶領大家全面瞭解 Nacos 是如何高效解決註冊中心的三大核心任務的。

gRPC

在這裡，我想先介紹一下 Nacos 的實現方式。自 Nacos 2.1 版本起，官方不再推薦使用 HTTP 等傳統的 RPC 呼叫方式，雖然這些方式仍然是被支援的。如果你計劃順利升級到 Nacos，需特別關注一個配置引數：在 application.properties 檔案中設定 nacos.core.support.upgrade.from.1x=true。

在之前的分析中，我們已經探討過 Nacos 1.x 版本的實現，那個版本確實是透過常規的 HTTP 呼叫進行互動的，Nacos 服務端會實現一些 Controller，就像我們自己構建的微服務一樣，原始碼的可讀性非常高，容易理解。呼叫方式如下面的圖示所示：

但是，自 Nacos 2.1 版本以來，系統進行了重要的升級，轉而採用了 gRPC。gRPC 是一個開源的遠端過程呼叫（RPC）框架，最初由 Google 開發。它利用 HTTP/2 作為傳輸協議，提供更高效的網路通訊，並使用 Protocol Buffers 作為訊息格式，從而實現了快速且高效的資料序列化和反序列化。

效能最佳化：gRPC 基於 HTTP/2 協議，支援多路複用，允許在一個連線上同時傳送多個請求，減少延遲和頻寬使用。

二進位制負載：與基於文字的 JSON/XML 相比，協議緩衝區序列化為緊湊的二進位制格式。

流控與雙向流：gRPC 支援流式資料傳輸，能夠實現客戶端和伺服器之間的雙向流通訊，適用於實時應用。

解決 GC 問題：透過真實的長連線，減少了頻繁連線和斷開的物件建立，進而降低了 GC（垃圾回收）壓力，提升了系統效能。

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

在新版 Nacos 的原始碼中，你會發現許多以 .proto 字尾命名的檔案。這些檔案定義了訊息的結構，其中每條訊息代表一個小的資訊邏輯記錄，包含一系列稱為欄位（fields）的名稱-值對。這種定義方式使得資料的傳輸和解析變得更加高效和靈活。

例如，我們可以隨便找一個 Nacos 中的緩衝區檔案。

雖然這不是我們討論的重點，但值得指出的是，gRPC 的引入將為 Nacos 帶來顯著的效能最佳化。儘管我們在這裡不深入探討其具體實現，但瞭解這一點是很重要的，因為在後續的所有呼叫中，gRPC 都將發揮關鍵作用。

服務註冊

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

為了提高效率，我們不再逐步進行原始碼追蹤，儘管之前已經詳細講解過如何檢視 Spring 的自動配置。今天，我們將直接關注關鍵原始碼的位置，以快速理解 Nacos 的實現細節。

@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 中用於實現租戶（使用者）粒度的隔離，這對於微服務架構中的資源管理尤為重要。

名稱空間的常見應用場景之一是不同環境之間的隔離，比如開發、測試環境與生產環境的資源隔離。

接下來，我們將進行一個服務呼叫，這裡使用的是 gRPC 協議。實際上，這個過程可以簡化為一個方法呼叫。

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 呼叫請求後，會立即啟動一系列處理流程，以確保請求能夠得到有效響應。關鍵程式碼的實現細節可以參考下面這部分。

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

這段程式碼包括提取請求資訊、建立相關物件、處理訂閱或取消訂閱的操作，並返回相應的結果。透過這種方式，Nacos 可以高效管理微服務的服務發現和註冊功能。

心跳監測

在 Nacos 2.1 版本之前，每個服務在執行時都會向註冊中心傳送一次請求，以通知其當前的存活狀態和正常性。這種機制雖然有效，但在高併發環境下可能會引入額外的網路負擔和延遲。

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

為了更好地理解這一機制的實現，我們接下來將重點關注相關的關鍵程式碼。

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) {
                                 // 省略一些程式碼

我將與健康監測無關的程式碼基本去除了，這樣你可以更加直觀地觀察 Nacos 是如何進行例項健康監測的。由於健康監測的核心目的在於確認服務的可用性，因此這一過程的實現相對簡單。

在這段程式碼中，我們可以清晰地看到，健康監測並不涉及任何複雜的資料傳輸。其主要功能僅僅是向伺服器傳送請求，以檢測伺服器是否能夠成功響應。這種設計極大地降低了網路開銷，使得監測過程更加高效。

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

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

總體而言，這種最佳化顯著減少了網路 I/O 的消耗，提升了系統的整體效能。乍一看，似乎並沒有做什麼複雜的操作，但這並不意味著我們就無法判斷客戶端是否能夠正常連線。實際上，關鍵的判斷邏輯被設計在外層程式碼中。

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

彆著急，服務端同樣執行著一個定時任務，負責定期掃描和檢查各個客戶端的狀態。我們看下：

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方法再往後走，你就會發現這樣一段程式碼
//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());
    }
}
//省略部分程式碼，

透過這些分析，你基本上已經掌握了核心概念和實現細節。我們不需要再多做贅述。我們繼續往下看。

負載均衡

談到負載均衡，首先我們需要確保本地擁有一份伺服器列表，以便於合理地分配負載。因此，關鍵在於我們如何從註冊中心獲取這些可用服務的資訊。那麼，具體來說，我們應該如何在本地有效地發現和獲取這些服務呢？

服務發現

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

首先，心跳任務的主要目的是監測服務例項的健康狀態，確保它們能夠正常響應請求。而服務發現則側重於及時更新和獲取當前可用的服務例項資訊。這兩者的目的明顯不同，因此將它們混合在一起可能會導致邏輯上的混淆和功能上的複雜性。

此外，兩者的時間間隔也各有不同。心跳監測可能需要更頻繁地進行，以及時發現和處理服務故障，而服務發現的頻率可以根據具體需求適當調整。基於這些原因，將心跳監測和服務發現分開成兩個獨立的定時任務，顯然是更合理的選擇。

接下來，讓我們深入研究服務發現的關鍵程式碼，看看具體是如何實現這一機制的：

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 作為服務端的負載均衡工具。然而，除了在伺服器端進行負載均衡之外，我們同樣可以在微服務客戶端配置負載演算法，以最佳化請求的分發。

此時，我們要明確的是，這部分邏輯實際上並不屬於 Nacos 的職責範圍，而是由另一個元件——Ribbon 來負責。Ribbon 專注於實現客戶端負載均衡，確保在微服務架構中，客戶端能夠智慧地選擇合適的伺服器進行呼叫，從而提高系統的效能和穩定性。

接下來，我們可以深入檢視 Ribbon 的關鍵程式碼，瞭解它是如何選擇伺服器的。，具體來說，Ribbon 透過一個名為 LoadBalance 的類來攔截請求，並根據預設的負載均衡策略來挑選合適的伺服器。

讓我們來深入分析一下關鍵程式碼，其實所有的負載均衡演算法邏輯都集中在 getServer 方法的實現中。

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

我們可以對負載均衡策略進行區域性配置，以便根據特定的業務需求和場景靈活調整服務呼叫的行為。

#被呼叫的微服務名
mall‐order:
 ribbon:
    #指定使用Nacos提供的負載均衡策略（優先呼叫同一叢集的例項，基於隨機&權重）
    NFLoadBalancerRuleClassName:com.alibaba.cloud.nacos.ribbon.NacosRule

當然，我們也可以進行全域性配置，以便在整個系統範圍內統一管理負載均衡策略和引數。

@Bean
public IRule ribbonRule() {
    // 指定使用Nacos提供的負載均衡策略（優先呼叫同一叢集的例項，基於隨機權重）
    return new NacosRule();
}

總結

隨著本文的深入探討，我們對微服務架構中的服務發現與序號產生器制有了更全面的認識。從單體架構的侷限性到微服務的靈活性，我們見證了架構演進的歷程。服務發現與註冊作為微服務通訊的基石，其重要性不言而喻。透過Nacos這一強大的註冊中心，我們不僅實現了服務的動態註冊與發現，還透過心跳監測、負載均衡等機制，確保了服務的高可用性和穩定性。

在技術選型上，Nacos的gRPC實現展示了其在效能最佳化方面的潛力，同時也帶來了系統複雜性的挑戰。然而，透過精心設計的客戶端和服務端程式碼，我們能夠有效地管理服務例項，實現服務的快速響應和負載均衡。這些機制的實現，不僅提升了系統的伸縮性和容錯性，也為微服務的快速發展提供了堅實的基礎。

不論你是初涉微服務的新手，還是深耕多年的專家，希望本文的分析和實踐案例能為你提供新的視角和深入的見解！

我是努力的小雨，一名 Java 服務端碼農，潛心研究著 AI 技術的奧秘。我熱愛技術交流與分享，對開源社群充滿熱情。同時也是一位騰訊雲創作之星、阿里雲專家博主、華為云云享專家、掘金優秀作者。

💡 我將不吝分享我在技術道路上的個人探索與經驗，希望能為你的學習與成長帶來一些啟發與幫助。

🌟 歡迎關注努力的小雨！🌟