Nacos引擎的命名空間怎么使用 ？
命名空間是Nacos引擎內部的邏輯數據隔離分區概念。命名空間的常用場景之一是不同環境的配置和服務的區分隔離，例如開發環境、測試環境和生產環境的資源隔離等。不同的命名空間下，可以存在相同的Group、DataId或服務名稱。命名空間創建完成后，將命名空間ID配置在應用中。服務注冊時會根據配置注冊到指定的命名空間中，如果沒有指定命名命名空間，會默認注冊到public。如果注冊到一個不存在的命名空間ID，也能夠提示注冊成功，但是在控制臺無法可視化操作該服務，創建對應的命名空間后就可以正常操作了。
配置代碼：Spring Cloud yml方式（properties方式同理）。
spring:
cloud:
nacos:
config:
server-addr: ${NACOS_SERVER_ADDRESS}
namespace: ${NACOS_CONFIG_NAMESPACE}
discovery:
server-addr: ${NACOS_SERVER_ADDRESS}
namespace: ${NACOS_NAMING_NAMESPACE}
Dubbo yml方式（properties方式同理）。
dubbo:
registry:
address: nacos://Nacos地址
parameters[namespace]: 命名空間ID
生產環境下-Nacos引擎設置多少個節點比較好呢？
- 購買實例前建議您先評估實際需求，然后參考章節：產品規格 ，預留30%左右的容量，然后訂購對應能力規格的產品。
- Nacos提供單機版和集群版，單機版只有一個節點，不建議生產使用。集群版提供3、5、7、9節點集群，集群節點數量越多，對故障節點數量的容錯能力就越強，只要查過半數的節點正常就能正常提供服務例如9節點集群，即使同時有4個節點宕機或故障，依然能正常提供服務。建議您根據實際的需要以及服務的可用性要求訂購對應的實例。
- 如果購買的實例無法隨著業務發展無法滿足實際需求可以使用擴容操作。具體的操作可以參考章節：管理實例。
如何創建專屬賬戶給客戶端提供服務？
MSE中Nacos引擎默認開啟鑒權功能，訪問未認證或者授權的用戶訪問實例。
Nacos鑒權默認支持JWT認證，通過用戶、角色、權限三者共同作用來賦予用戶權限，詳情請參見章節Nacos引擎訪問權限 。
是否支持回滾配置的歷史版本？
MSE 注冊配置中心提供了配置歷史查詢功能。目前默認僅保存30天以內的變更記錄。查看和回滾歷史配置。
在基礎信息頁面，左側菜單點擊配置管理>配置列表，選擇命名空間，查看當前配置。在左側導航欄，選擇歷史版本。在歷史版本頁面選擇命名空間、分組、和DataId，點擊搜索，即可查看配置的歷史。詳細操作請參見章節配置管理。
在配置歷史頁面選擇指定版本的歷史配置擊回滾，確認后即可回滾至歷史版本。
在配置列表頁面點擊編輯按鈕，可以查看當前配置的內容，可以確認是回滾至歷史版本。回滾操作也會產生一條新的配置變更記錄。
Nacos上修改服務實例的權重不生效問題
問題現象
控制臺服務詳情頁面修改服務實例時，設置了實例的權重，但實際調用流量時，流量分配未按照預期權重進行分配。
問題原因
- 應用框架不支持按權重分配流量負載均衡。
- 應用框架有自身的負載均衡配置方式，不使用Nacos的權重屬性進行負載均衡。
- 應用未使用權重值進行地址選擇。
解決方案
Nacos中服務實例的權重僅為實例的一個屬性。當修改權重值后，權重值會伴隨實例信息被推送到Nacos客戶端。實際使用時由于使用方式的不同，可能會導致權重屬性被忽略。
- 如果所使用的應用框架不支持按權重分配流量。例如Spring Cloud等框架，此類框架僅識別流量值為0（不引入流量）和非0（引入流量），不支持按照Nacos實例中的流量值進行流量負載均衡。您可以按照以下方法解決。
- 尋找擴展插件以增加流量分配支持。
- 更換其他應用框架。
- 應用框架有自身的負載均衡配置方式，不支持使用Nacos的權重屬性。如Dubbo、Spring Cloud Alibaba + Loadbalance等。可以在社區中詢問或根據對應框架文檔查看如何配置負載均衡。
- 未使用應用框架進行開發，但是應用在處理時未使用權重值進行地址選擇。
應用在獲取到實例列表后，根據其中的weight字段實現自定義的選擇邏輯。
使用Nacos客戶端默認的selectOneHealthyInstance方法進行選擇。
Nacos連接超時問題
問題現象
當程序連接Nacos出現超時問題時，可能出現如下幾種報錯：
Connection timed out
Read Timeout
TimeoutException: Waited 3000 milliseconds
問題原因
可能是以下幾種原因，導致程序連接Nacos出現超時問題。
- 客戶端與服務端的網絡傳輸異常，導致客戶端發出的請求無法抵達服務端或服務端的回復無法抵達客戶端。或者服務端處理請求速度慢，導致客戶端誤認為超時。
- 使用VPN導致的網絡問題。
- 客戶端的處理線程阻塞或異常，亦或客戶端處于Full GC、OOM或CPU爭搶等狀態， 無法及時處理服務端返回的數據包，導致客戶端誤認為超時。
- Nacos集群處于異常狀態，無法響應請求。
解決方案
- 如果僅有某一個客戶端節點出現超時報錯，可能是這些客戶端節點與Nacos之間的網絡出現問題，或是這些客戶端節點存在異常或阻塞。
此時，您可在錯誤所在的客戶端節點上，使用ping、telnet和curl等命令，訪問Nacos集群。查看客戶端監控是否存在高CPU使用率、頻繁FullGC和OOM等信息，以此排查是否存在網絡問題。
ping ${mse.nacos.host}
telnet ${mse.nacos.host}:47588
curl ${mse.nacos.host}:47588/nacos/v1/ns/service/list
- 如果使用了VPN，請關閉VPN或查看VPN設置后重試。
- 如錯誤信息存在于所有的客戶端節點，可以在監控分析頁面查看Nacos實例的監控信息：
- 在概覽頁簽，查看引擎的每秒查詢數和每秒操作數是否超過了每秒處理請求數（TPS）。
- 關于每秒處理數的取值，請參見實例能力評估。
- 在連接數監控頁簽，查看客戶端版本數量和長鏈路數量是否超過了連接數。
- 關于連接數的取值，請參見實例能力評估。
- 在jvm監控頁簽，查看引擎Full GC是否頻繁出現。
- 當通過ELB訪問Nacos時，查看資源的入口流量和出口流量是否超出購買時指定的帶寬大小。
- 在系統資源監控tab頁查看資源的內存使用率和CPU使用率是否接近或超過100%，導致實例出現異常。
- 如果僅是偶爾發生超時錯誤，考慮設置更長的超時時間避免此類問題。
- 若Java Client版本為1.0.0~1.4.X，則建議升級客戶端版本到2.x系列版本。
- 若Java Client版本為2.0.0~2.1.1， 請將Java Client版本先升級至2.1.2及以上，再設置超時時間。
- 若Java Client版本為2.1.2及以上，請在應用進程的JVM參數中添加如下參數：
-Dnacos.remote.client.grpc.timeout=${請求超時，單位毫秒，默認3000}；
檢測所連接的服務端是否健康，不健康則觸發重連。
-Dnacos.remote.client.grpc.server.check.timeout=${服務端健康檢測，單位毫秒，默認3000}；
檢測當前連接狀態是否健康，不健康則觸發重連。
-Dnacos.remote.client.grpc.health.timeout=${連接健康檢測，單位毫秒，默認3000}；
Nacos連接失敗問題
問題現象
當程序連接Nacos出現連接失敗問題時，可能會出現如下幾種報錯。
Client not connected,currentstatus:STARTING
Client not connected,currentstatus:UNHEALTHY
no available server, currentServerAddr: xxxxx
Connection refused
問題原因
可能是如下幾種原因，導致程序連接Nacos出現連接失敗。
Nacos的訪問地址或端口配置錯誤。
訪問Nacos集群時，網絡異常。
使用VPN導致的網絡問題。
客戶端存在高CPU使用率、頻繁FullGC等問題。
解決方案
- 在錯誤所在的客戶端節點上，使用ping、telnet和curl等命令，訪問Nacos集群，排查是否存在網絡問題。
ping ${mse.nacos.host}
telnet ${mse.nacos.host}:47588
telnet ${mse.nacos.host}:48588
curl ${mse.nacos.host}:47588/nacos/v1/ns/service/list
- 檢查應用的相關配置，是否配置了正確的MSE實例訪問地址、端口等信息。
- 如果報錯信息為Connection refused?，請從緊隨其后的報錯信息中查看實際連接的地址與MSE實例的連接地址是否不相同。例如Connection refused: /127.0.0.1:48588說明某些配置錯誤地指向了本機地址。
- 如果使用了VPN，請檢查VPN設置是否正確。若不正確，請關閉VPN或修改VPN設置后重試。
- 若通過上述步驟還無法定位問題，注冊配置中心控制臺的監控分析頁面，查看Nacos的如下信息：
- 在概覽頁簽，查看引擎的每秒查詢數和每秒操作數是否超過了每秒處理請求數（TPS）。
- 關于每秒處理數的取值，請參見實例能力評估。
- 在連接數監控頁簽，查看長鏈路數量是否超過了連接數。
- 關于連接數的取值，請參見實例能力評估。
- 在jvm監控頁簽，查看引擎是否頻繁出現Full GC。
- 在資源監控頁簽，查看資源的入口流量和出口流量是否超出購買時指定的帶寬大小。
- 在資源監控頁簽，查看資源的內存使用率和CPU使用率是否接近或超過100%，導致節點可能出現異常。
- 資源的內存使用率和CPU使用率接近或超過100%，請嘗試變更實例規格進行升配，請參見變更實例規格。
Nacos 持久化實例健康檢查異常問題
問題現象
當在Nacos中注冊的持久化實例選擇健康檢查方式為HTTP/TCP時，服務實例的健康狀態始終顯示為不健康，但實例配置或狀態正常。
可能原因
MSE的Nacos為托管類產品，部署在內網資源池的vpc中，不與應用程序部署在一起。出于安全規范的考量，僅開放單向請求，在網絡層面禁止從服務端向外部發起的TCP連接/HTTP請求。上述原因可能導致健康檢查始終會以超時等網絡原因顯示失敗。
解決方案
將注冊的服務類型修改為非持久化。即注冊服務提供者時，指定ephemeral字段為true或移除對ephemeral字段的設置（ephemeral字段缺省值為true）。
如何查找Nacos-Client日志
Nacos-Client的日志根據相關的編程語言不同而有所差異，不同的編程語言版本Client的日志獲取方式如下：
Java ?Nacos Client
Java語言的Nacos-Client的日志一般在應用服務所在節點的?{user.home}/logs/nacos/目錄下 ,{user.home}為啟動應用服務進程的系統用戶的根目錄。
若使用的是Spring Cloud，部分低版本Spring Cloud會覆蓋Nacos-Client的日志配置，導致日志輸出在應用服務的日志中。
其中，naming.log是注冊中心模塊相關日志，config.log是配置中心模塊相關日志。2.0.0之后版本中，Nacos-Client新增了remote.log，remote.log是gRPC連接相關的日志。
Go Nacos-Client
Go語言的Nacos-Client的日志默認在/tmp/nacos/log/目錄下，可以通過LogDir:參數修改日志路徑。
Go語言的Nacos-Client日志不區分具體模塊內容，應該所有的日志都會在同樣的日志文件中。
Python Nacos-Client
Python語言的Nacos-Client使用Python的Logging模塊，會和應用的Logging模塊保持一致并輸出到應用的日志中。
C++ Nacos-Client
C++語言的Nacos-Client的日志默認在應用所在目錄下，文件名為nacos-sdk-cpp.log, 可通過Logger.cpp中的setBaseDir設置日志目錄。
引擎升級或重啟時，出現訪問異常或中斷服務
集群升級或重啟會輪轉進行。不同節點數量的集群可能出現的情況不同。
- 3個節點以上的集群：不會出現中斷服務，無法訪問的情況，但仍可能出現少量的短時間的請求失敗，客戶端會立刻重試恢復。
- 單節點集群：會導致集群不可用并中斷服務。僅開發版集群為單節點，不保證高可用。
控制臺還能查到不存在的服務實例IP如何處理的
問題現象
應用服務實例停止，注冊配置中心控制臺仍能看到該服務實例。
應用服務重啟或發布后，注冊配置中心控制臺仍能看到該服務實例。
可能原因
服務實例并未徹底關閉，進程仍然存在并發送心跳維持連接，導致Nacos未摘除服務提供。
有額外的應用進程在發送心跳維持連接，導致Nacos未摘除服務提供者。
解決方案
- 確認該服務實例已經不應該在線的情況下，先在MSE控制臺上對該服務提供者執行下線操作，防止有更多流量進入到該故障節點。
- 根據部署環境的不同排查服務提供者是否未徹底關閉：
- 直接部署到云主機：登錄到對應IP的云主機上，使用ps -ef | grep ${應用名}、netstat -anp | grep 48588或netstat -anp | grep 47588等命令，查看服務提供者進程是否還存在，是否與Nacos還保持著連接。如果是，則確認后關閉該進程。
- 通過自建Kubernetes、Docker或容器服務部署：檢查是否存在幽靈Pod或Container（即Pod或Container已經不可見，但對應的程序進程未終止銷毀），可通過在Node或宿主機上執行**ps -ef | grep ${應用名}**等命令，查看是否該應用提供者的個數等同于期望個數。如果不相同，則確認后找到該幽靈Pod并徹底關閉。
