前言

nacos 2.0.0 已經發布了 alpha1, alpha2 和 beta 三個版本了，部分測試報告也已經出來了。

• Nacos2.0.0-ALPHA2 服務發現性能測試報告

• Nacos 2.0.0-ALPHA2 配置性能測試報告

還是比較值得期待的。

前段時間也一直在完善 nacos-sdk-csharp 這個項目。

主要就是對接 Nacos 2.0.0 這一塊，也考慮到之前主要是針對Open API封裝，同時參考JAVA的SDK進行功能疊加。

這一次就索性全部重新來過了，也對齊 JAVA SDK 提供的方法。

這其中最為重要的應該是底層協議由 HTTP 換成 gRPC，也是長輪詢到長連接的一個跨越。

現在就和大家簡單梳理一下老黃在對接中認為要注意的地方。

這里以 nacos 2.0.0 beta 版本為準，后續版本可能會有變化。

端口

nacos 的默認端口是 8848，也是之前 HTTP 協議對接時的請求端口，那么我們是不是通過 8848 這個端口進行 gRPC 的交互呢？

答案是否定的！

nacos 里面做了一個約定，把 gRPC 的服務端口設置成 nacos 啟動的端口加 1000。

也就是說，nacos 的端口是 8848 的話，那么 gRPC 服務端口就是 9848

所以這里是第一個注意的點。

proto 文件

下面是 nacos 提供的 proto 文件，這個是SDK和Server交互的基礎。

syntax = "proto3";import "google/protobuf/any.proto"; import "google/protobuf/timestamp.proto";option java_multiple_files = true; option java_package = "com.alibaba.nacos.api.grpc.auto";message Metadata {string type = 3;map<string, string> headers = 7; }message Payload {Metadata metadata = 2;google.protobuf.Any body = 3; }service RequestStream {// build a streamRequestrpc requestStream (Payload) returns (stream Payload) {} }service Request {// Sends a commonRequestrpc request (Payload) returns (Payload) {} }service BiRequestStream {// Sends a commonRequestrpc requestBiStream (stream Payload) returns (stream Payload) {} }

這里有 3 個 service，其中 RequestStream 這個在實際對接中是沒有使用到的。所以只介紹其他兩個。

Request 這個是通用請求，發布配置，注冊服務之類的請求都是通過這個方法來交互的。

BiRequestStream 這個是雙向流，主要是用來注冊連接，和一些監聽回調。

Nacos 1.x 里面， 配置的監聽回調是基于長輪詢機制，服務的監聽回調是基于udp機制。

再來看看 service 的參數和響應。

Payload 的設計是有兩個部分， 一個是自定義類型的 metadata， 一個是 Any 類型的 body。

metadata 里面有一個 type 字段，這個字段代表的是客戶端和服務端交互的 RPC 語義。好比說，我要發布配置，就是通過這個 type 告訴服務端，當前請求是要做什么。

body 這個在交互時需要做一下轉換，拿到一個 object 對象，序列化成一個 JSON 字符串，最后在轉化成 Any 類型的 value。

下面是一個簡單的示例：

var?body?=?new?Google.Protobuf.WellKnownTypes.Any {//?convert?the?request?paramter?to?a?json?string,?as?the?bodyValue?=?Google.Protobuf.ByteString.CopyFromUtf8(request.ToJsonString()) };

這里有一個要注意的地方，在生成 C# 代碼后，會因為參數名和方法名一樣造成編譯不過，所以這里要修改一下生成代碼的參數名。

對接

知道了服務端的端口， proto 文件也有了，接下來就可以和服務端對接了。

想要和服務端對接上，成功獲取到正確的數據，其實還有不少內容的。

下面老黃拆成 3 個小節來說。

建立連接

Step 1:

與 gRPC 服務端進行交互，首先就是要創建一個 Channel ，這里用的是 Insecure 的方式，不需要提供額外的證書信息。

Step 2:

創建 Request 請求客戶端，并發起 ServerCheckRequest 請求，檢查服務是否可用，不可用就直接關閉這個 Channel 了。

Step 3:

創建 BiRequestStream 請求客戶端，注冊處理服務端推送的相關操作，主要是配置和服務的變更。

注冊完成后，還要發送 ConnectionSetupRequest 請求和 server 端建立真正意義上的連接。

這一步至關重要，因為這一步過后，服務端會把這個連接維護到客戶端的連接管理里面，后續的請求會通過這個來判斷是不是合法的請求。可以理解成拿到了大門的鑰匙。

這一步完成之后，就可以通過 Request 發送請求了。

請求與響應

這里的請求，指的是通過 Request 發起的。

前面有提到，body 參數這一塊，是對一個 JSON 字符串進行轉化后的值。

這個 JSON 字符串大概成下面這樣。

{"headers":?{"h1":?"v1","h2":?"v2"},"requestId":?"xxxx","biz-prop-1":?"value-1","biz-prop-2":?"value-2","biz-prop-n":?"value-n", }

其中， headers 和 requestId 這兩個是通用參數，每個接口都應該帶上，其他的就是各個接口需要什么就加什么。

響應的話會有正常和異常。

正常的話，返回的 type 是和請求的 type 相對應的。

好比 ConfigPublishRequest 就會對應 ConfigPublishResponse。

如果服務端處理異常了，就會返 ErrorResponse

這里的異常可以分為兩類。

請求沒有注冊

{"resultCode":500,"errorCode":301,"message":"Connection?is?unregistered.","success":false}?

出現這種情況后，客戶端這邊是要重新和服務端進行連接，不然所有的請求都會是這個返回。

可能的原因有：

• 在請求之前沒有提前在雙向流里面發起建立連接的請求。

• 客戶端與服務端斷開過連接

請求處理失敗

這個一般就是服務端處理出現了異常。

重新連接

如果響應告訴客戶端請求沒有注冊，這個時候要及時觸發重新連接，這樣才不會讓業務受到影響。

觸發重連操作后，會有一個 SwitchServer 的操作，可以簡單理解成換了一個服務地址，然后重復連接里面的幾個步驟。

到這里其實對接相關的內容基本差不多了，剩下的就是對接具體的請求和其他操作了。

也附上一張老黃之前畫的粗糙的圖。

寫在最后

老黃參與的 nacos-sdk-csharp 目前已經基本適配好了 nacos 2.0.0 beta 版本，但是還有許多細節需要慢慢的調整和改進。

希望有感興趣的大佬一起參與到這個項目來。

nacos-sdk-csharp 的地址 ：https://github.com/nacos-group/nacos-sdk-csharp

總結

以上是生活随笔為你收集整理的聊一聊和Nacos 2.0.0对接那些事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。