開發與維運

Nacos 集群部署模式最佳實踐

2021-01-01

前言

Nacos 支持兩種部署模式：單機模式和集群模式。在實踐中，我們往往習慣用單機模式快速構建一個 Nacos 開發/測試環境，而在生產中，出於高可用的考慮，一定需要使用 Nacos 集群部署模式。我的上一篇文章《一文詳解 Nacos 高可用特性》提到了 Nacos 為高可用做了非常多的特性支持，而這些高可用特性大多數都依賴於集群部署模式。這篇模式文章便是給大家介紹一下，在實踐中可以被採用的幾種集群部署模式，無論你是希望自行搭建 Nacos，還是希望對 MSE 商業版 Nacos 有一個更加深刻的理解，我都很樂意跟你分享下面的內容。

由於篇幅限制，本文不會介紹如何將一個多節點的 Nacos 集群啟動起來，主要介紹的是一個多節點的 Nacos 集群啟動之後，我們的應用如何很好地連接到 Nacos 集群，即客戶端視角。這中間我們會引入一些其他組件以解決一些問題，本文標題也可以叫做《Nacos 接入點最佳實踐》。我將會介紹以下三種方案：直連模式、 VIP 模式和地址服務器模式，並對它們進行對比。

直連模式

直連模式是部署上最簡單、最容易理解的一種模式。

image.png

採用直連模式後，典型的開發場景配置如下：

nacos-client 配置

Properties properties = new Properties();
properties.setProperty(PropertyKeyConst.SERVER_ADDR, "192.168.0.1:8848,192.168.0.2:8848,192.168.0.3:8848");
NamingService namingService = NacosFactory.createNamingService(properties);

注意這裡的 PropertyKeyConst.SERVER_ADDR 的字面量是：serverAddr

Dubbo 配置

dubbo.registry.address=192.168.0.1:8848,192.168.0.2:8848,192.168.0.3:8848
dubbo.registry.protocol=nacos

如果有一天，Nacos 的 IP 變了，例如擴縮容，機器置換，集群遷移等場景，所有的應用都需要修改，這樣的方式並不靈活。所以並不是生產推薦的模式。

模式分析

  • 高可用性。集群本身的擴縮容必須要改動業務代碼才能被感知到，出現節點故障需要緊急下線、緊急擴容等場景，讓業務修改代碼是不現實的，不符合高可用的原則。
  • 可伸縮性。同上，可伸縮性不好。
  • 架構簡單，用戶理解成本低。
  • 沒有引入額外的組件，沒有新增組件的運維成本。

VIP 模式

VIP（Virtual IP） 模式可以很好的解決直連模式 IP 變化所帶來的應用批量修改的問題。什麼是 VIP 呢？

image.png

  • Real Server：處理實際請求的後端服務器節點。
  • Director Server：指的是負載均衡器節點，負責接收客戶端請求，並轉發給 RS。
  • VIP：Virtual IP，DS 用於和客戶端通信的 IP 地址，作為客戶端請求的目標 IP 地址。
  • DIP：Directors IP，DS 用於和內部 RS 通信的 IP 地址。
  • RIP：Real IP，後端服務器的 IP 地址。
  • CIP：Client IP，客戶端的 IP 地址。

我這裡介紹時並沒有用【負載均衡模式】，而是用了【VIP 模式】，主要是為了跟 Nacos 官方文檔保持一致。事實上，VIP 的叫法在阿里內部比較流行，所以在開源 Nacos 時也被習慣性的帶了出去。

image.png

VIP 幫助 Nacos Client 屏蔽了後端 RIP，相對於 RIP 而言，VIP 很少會發生變化。以擴容場景為例，只需要讓 VIP 感知到即可，Nacos Client 只需要關注 VIP，避免了擴容引起的代碼改造。

只要是具備負載均衡能力的組件，均可以實現 VIP 模式，例如開源的 Nginx 以及阿里雲負載均衡 SLB。

採用 VIP 模式後，代碼不需要感知 RIP，典型的開發場景配置如下：

nacos-client 配置

Properties properties = new Properties();
properties.setProperty(PropertyKeyConst.SERVER_ADDR, "{VIP}:8848");
NamingService namingService = NacosFactory.createNamingService(properties);

Dubbo 配置

dubbo.registry.address={VIP}:8848
dubbo.registry.protocol=nacos

域名配置

VIP 模式和直連模式都不具備可讀性，所以在實際生產中，往往還會給 VIP 掛載一個域名。

域名背後可以掛載 2 個 VIP 用作高可用，路由到相同的 rs；同時域名的存在也讓 VIP 的置換變得更加靈活，當其中一臺出現問題後，域名的 DNS 解析只會路由到另外一個正常的 VIP 上，為平滑置換預留了足夠的餘地。

tips：一個域名可以綁定多個 A 記錄，一個 A 記錄對應一個 IPv4 類型的 VIP，DNS 域名服務器了對多個 A 記錄會有負載均衡策略和健康檢查機制。

VIP 模式的最終生產高可用版架構便產生了：

image.png

典型的開發場景配置只需要將 VIP 替換為域名即可。

nacos-client 配置

Properties properties = new Properties();
properties.setProperty(PropertyKeyConst.SERVER_ADDR, "mse-abc123-nacos.mse.aliyuncs.com:8848");
NamingService namingService = NacosFactory.createNamingService(properties);

Dubbo 配置

dubbo.registry.address=mse-abc123-nacos.mse.aliyuncs.com:8848
dubbo.registry.protocol=nacos

模式分析

  • 高可用性。域名的可用性需要由 DNS 域名服務器負責，可用性保障較高；VIP 需要由高可用的負責均衡組件支持，且流量經過負載均衡轉發，對 VIP 的實現有較高可用性的要求。
  • 可伸縮性。水平擴縮容時，只需要讓 VIP 感知即可，可伸縮性好。
  • 依賴了域名解析系統和負載均衡系統，生產部署時，需要有配套設施的支持。

地址服務器模式

地址服務器介紹

說起地址服務器，可能大家對這個詞會感到陌生，因為地址服務器的概念主要在阿里內部比較普及，也是阿里中間件使用最廣的一種尋址模式。但是在開源領域，鮮有人會提及，但對於 Nacos 部署模式而言，地址服務器模式是除了 VIP 模式之外，另外一個生產可用的推薦部署方式。

地址服務器是什麼？顧名思義，是用來尋址地址的服務器，發送一個請求，返回一串地址列表。儘管在阿里內部使用的真實地址服務器比這複雜一些，但下圖這個簡單的交互邏輯，幾乎涵蓋了地址服務器 90% 的內容。

image.png

實現一個簡易版本的地址服務器並不困難，推薦使用 Nginx 搭建一個靜態文件服務器管理地址， 當然你可以使用 Java！

@Controller
public class AddressServerController {
    @RequestMapping("/nacos/serverlist")
    public ResponseEntity<String> serverlist() {
        return ResponseEntity.ok().
            header("Content-Type", "text/plain").
            body("192.168.0.1:8848\r\n" +
                    "192.168.0.2:8848\r\n" +
                    "192.168.0.3:8848\r\n"
            );
    }
}

使用地址服務器可以完成集群地址和客戶端配置的解耦，解決直連模式中無法動態感知集群節點變化的問題。客戶端根據地址服務器返回的列表，隨後採取直連模式連接；並且在客戶端啟動後，會啟動一個定時器，輪詢感知 AddressServer 的變化，進而及時更新地址列表。

並且地址服務器建議配置域名，增加可讀性。所以最後的部署交互架構是這樣的：

image.png

熟悉 RPC 的朋友看到這裡應該能夠很好地對 VIP 模式和地址服務器模式做一個類比：

  • VIP 模式是類似 DNS 的服務端負載均衡技術
  • 地址服務器是類似服務發現機制的客戶端負載均衡技術

nacos-client 的源碼專門適配了地址服務器模式，我們只需要配置好 addressServer 的 endpoint 即可。

nacos-client 配置

Properties properties = new Properties();
properties.setProperty(PropertyKeyConst.ENDPOINT, "{addressServerDomain}");
properties.setProperty(PropertyKeyConst.ENDPOINT_PORT, "8080");
NamingService namingService = NacosFactory.createNamingService(properties);

注意，這裡 PropertyKeyConst.ENDPOINT 的字面量是：endpoint ，配置的是地址服務器的地址。

Dubbo 配置

dubbo.registry.address=0.0.0.0?endpoint=127.0.0.1&endpointPort=8080
dubbo.registry.protocol=nacos

dubbo.registry.address 的 url 可以任意填寫，因為當 serverAddr 和 endpoint 同時存在時，默認是優先從地址服務器去選址的。

此時，只需要把真實的 Nacos Server IP 配置到地址服務器中即可。

Dubbo 通過 url 的 kv 屬性將值透傳給 Nacos 創建 Nacos-Client。Dubbo + Nacos 使用地址服務器模式時，建議 Dubbo 版本 >= 2.7.4，nacos-client 版本 >= 1.0.1

模式分析

  • 高可用性。域名的可用性需要由 DNS 域名服務器負責，可用性保障較高；地址服務器的職責單一，有較高的可用性；運行時 Client 直連 Nacos Server 節點，可用性靠 nacos-sdk 保障。
  • 可伸縮性。水平擴縮容時，只需要讓地址服務器感知即可，可伸縮性好。
  • 依賴了域名解析系統和地址服務器，生產部署時，需要有配套設施的支持。

部署模式對比

直連模式 VIP 模式 地址服務器模式
轉發模式 直連 代理（網絡多一跳） 直連
高可用 弱，代碼配置不靈活，節點故障時無法批量變更 強 強
可伸縮性 弱 強 強
部署成本 無 負載均衡組件運維成本高 地址服務器運維成本低
負載均衡模式 nacos-sdk 客戶端負載均衡 負載均衡組件提供負載均衡能力 nacos-sdk 客戶端負載均衡
開源接受度 高 高 低，地址服務器模式在開源領域不太普遍
企業級能力 不方便 靈活 靈活
跨網絡 內網環境，平坦網絡 VIP 模式靈活地支持反向代理、安全組、ACL 等特性，可以很好的工作在內/外網環境中，使得應用服務器和 Nacos Server 可以部署在不同的網絡環境中，藉助 VIP 打通 內網環境，平坦網絡
推薦使用環境 開發測試環境 生產環境，雲環境 生產環境

Nacos 這款開源產品很好地支持了地址服務器這種模式，所以無論是大、中、小型公司在自建 Nacos 時，都可以選擇地址服務器模式去構建生產高可用的 Nacos 集群，地址服務器組件相對而言維護簡單，Nginx，Java 構建的 Web 服務器均可以輕鬆實現一個地址服務器。使用地址服務器後，nacos-client 與 nacos-server 之間仍然是直連訪問，所以可以很好的運作在平坦網絡下。

VIP 模式同樣推薦在自建場景使用，但運維成本相對地址服務器還是要高一些，可以根據自己公司的運維體系評估。經過了 VIP 的轉發，有利有弊。弊端比較明顯，網絡多了一跳，對於內網環境這樣的平坦網絡而言，是不必要的；優勢也同樣明顯，大公司往往環境比較複雜，數據中心之間有網絡隔離，應用和中間件可能部署在不同的網絡環境中，藉助於 VIP 可以很好地做網絡打通，並且基於 VIP 可以很好實現安全組、ACL 等特性，更符合企業級訴求。

當然，組合使用地址服務器 + VIP 也是可以的，可以充分的融合兩者的優勢：

image.png

MSE Nacos 的實踐

上述場景主要介紹了三種模式的具體部署方案，以及自建 Nacos 場景如何做到高可用，最後要介紹的是阿里雲環境 MSE 是如何部署的。

MSE（微服務引擎）提供了 Nacos 註冊中心中心的全託管能力，除了要做上述提到的高可用、可伸縮、易用性，還要考慮以下的因素：

  • 開源接受度。避免給用戶帶來太多理解成本，儘量做到對標開源，這樣用戶接受度才會高。
  • 網絡隔離。MSE 提供的是 BaaS 化的能力，Nacos Server 部署在雲產品 VPC，與用戶 VPC 是隔離的，需要解決網絡隔離問題。
  • 網絡安全。MSE Nacos 是獨享模式，網絡上租戶隔離是最基本的要求。除此之外企業級用戶會對 MSE Nacos 提出安全組/ACL 控制的訴求，這些都需要考量。

綜上，MSE Nacos 最終採用的是域名 + SLB 的 VIP 模式。

image.png

MSE Nacos 提供兩個域名，其中公網域名可以用做本地開發測試，或者自建環境、混合雲等場景的接入點，內網域名用做阿里雲生產環境接入點。公網域名有帶寬限制，需要在集群創建時根據場景選擇合適的帶寬，而內網域名則沒有帶寬限制。公網域名請注意添加 IP 訪問白名單。

總結

本文介紹了 Nacos 的三種部署模式，並就高可用、可伸縮、易用性等方面對各個模式進行了介紹，並對自建 Nacos 場景的部署選型進行了分析，同時介紹了 MSE Nacos 企業版的部署架構，對雲環境部署 Nacos 進行了補充。

文章提及的三種模式其實也都是中間件組件常見的部署模式，不僅僅 Nacos，例如 Redis、DB 等場景，同樣有參考價值。

本文提及了地址服務器這個可能在開源領域不太常見的組件，在阿里內部則用得非常普遍。

另外，Nacos 本身也提供了 addressServer 模塊，出於篇幅考慮沒有在本文中提及，後續我會單獨整理一篇文章介紹，感興趣的同學可以自行參考 Nacos 官方文檔和官方博客中的內容。

掃碼瞭解更多技術內容與客戶案例：

image.png

Leave a Reply

Your email address will not be published. Required fields are marked *