Nacos 如何對同一配置做 beta 灰度發布并按客戶端 IP 命中灰度版本【免費下載鏈接】nacosan easy-to-use dynamic service discovery, configuration and service management platform for building AI cloud native applications.項目地址: https://gitcode.com/GitHub_Trending/na/nacos本文解決的問題是同一個namespaceId groupName dataId的配置如何額外發布一份只對被指定客戶端 IP 可見的 beta 版本并驗證命中與退出灰度的完整流程。Nacos 中灰度版本是同一 Config 身份下的從屬發布狀態namespaceId - groupName - dataId - grayName不是新的一條頂層配置。beta 內置規則按grayNamebeta存儲匹配條件是請求標簽ClientIp在逗號分隔的 beta IP 列表中優先級為Integer.MAX_VALUE內置規則中最高。以下內容基于 Nacos 3.x 的灰度模型config_info_gray表 GrayRule相關語義定義見 Config 灰度發布規范。操作前的兩個前提有一個可通過 HTTP 訪問的 Nacos 服務端。下文所有接口路徑都帶有/nacos前綴例如/nacos/v3/admin/cs/config命令中的http://Nacos 服務地址需要你替換為實際可訪問的協議、主機和端口。從 3.3 版本線開始運行時不再支持從舊表config_info_beta、config_info_tag向config_info_gray的兼容遷移。如果你的部署來自 3.0 之前版本且使用過 beta 灰度發布必須先完成相關數據遷移再升級否則本文流程不適用于舊表中的數據。第一步發布正式配置beta 版本依附于正式配置先確保正式版本存在。向POST /nacos/v3/admin/cs/config提交 form 表單發布字段與 集成測試的表單構造 一致curl -X POST http://Nacos 服務地址/nacos/v3/admin/cs/config \ -d dataIdgray.example.com \ -d groupNameDEFAULT_GROUP \ -d contentformal-content \ -d tag \ -d appName \ -d src_user \ -d configTags \ -d desc \ -d use \ -d effect \ -d typetext \ -d schema成功時響應為{data: true}測試中對該布爾值做了斷言。不傳namespaceId時默認使用publicnamespace。第二步用 betaIps 請求頭發布 beta 版本關鍵點同一個發布接口只需額外攜帶betaIps請求頭攜帶betaIps的發布會寫入 beta 灰度版本而不是覆蓋正式配置不帶灰度選擇字段的發布才寫正式配置。curl -X POST http://Nacos 服務地址/nacos/v3/admin/cs/config \ -H betaIps: 10.0.0.2 \ -d dataIdgray.example.com \ -d groupNameDEFAULT_GROUP \ -d contentbeta-content \ -d tag \ -d appName \ -d src_user \ -d configTags \ -d desc \ -d use \ -d effect \ -d typetext \ -d schemabetaIps的取值是要命中的客戶端 IP逗號分隔可寫多個 IP。示例中的10.0.0.2、gray.example.com、DEFAULT_GROUP等均為示例值替換為你自己的 dataId、group 和客戶端 IP。成功后同樣返回{data: true}此后該配置同時擁有正式版本和grayNamebeta的灰度版本兩者共享namespaceId groupName dataId但內容、md5、最后修改時間和灰度規則各自獨立。第三步通過 Admin beta 查詢接口驗證 beta 版本已生效驗證用專門的 beta 查詢端點而不是正式配置查詢。注意Admin 正式查詢不會靜默返回灰度內容要檢查 beta 版本必須走 beta 端點curl http://Nacos 服務地址/nacos/v3/admin/cs/config/beta?dataIdgray.example.comgroupNameDEFAULT_GROUPnamespaceId可省略省略時為public。命中時data中包含該配置的身份、beta 內容和規則示例結果字段來自 beta Admin API 集成測試 的斷言{ data: { dataId: gray.example.com, groupName: DEFAULT_GROUP, namespaceId: public, content: beta-content, grayName: beta, grayRule: 包含 betaIps 的序列化灰度規則 } }其中grayRule為序列化后的灰度規則測試斷言其內容包含發布時傳入的betaIps值。如果該配置當前沒有 beta 版本接口返回 HTTP 404錯誤碼為RESOURCE_NOT_FOUND錯誤消息為Config is not in beta。第四步按客戶端 IP 驗證運行時灰度命中運行時查詢端點是GET /nacos/v3/client/cs/config供客戶端獲取實際生效的配置curl http://Nacos 服務地址/nacos/v3/client/cs/config?dataIdgray.example.comgroupNameDEFAULT_GROUP命中邏輯由 Config 發布與查詢規范 定義運行時查詢先從客戶端 IP、顯式 tag 和連接標簽構建請求標簽再遍歷已排序的灰度版本返回第一個命中的灰度版本未命中才回退正式配置。因此從betaIps列表中的機器本例中源 IP 為10.0.0.2的客戶端發起該請求返回的是 beta 內容響應還包含命中的灰度版本的 md5、encryptedDataKey、最后修改時間、配置類型和灰度元數據從列表外的機器發起同一請求返回的是正式配置內容。當存在多個灰度版本時按優先級降序匹配優先級相同再按grayName排序beta 規則優先級為Integer.MAX_VALUE是內置規則中最先被匹配的。響應中是否包含 beta/tag 元數據字段的驗證可參考 Client API 測試場景說明 中ConfigOpenApiITCase對GET /v3/client/cs/config的描述。第五步停止灰度刪除 beta 版本確認灰度完成后刪除 beta 版本即可退出灰度curl -X DELETE http://Nacos 服務地址/nacos/v3/admin/cs/config/beta?dataIdgray.example.comgroupNameDEFAULT_GROUP刪除灰度版本只移除該版本不刪除正式配置。刪除后再執行第三步的 beta 查詢會返回 404Config is not in beta此時所有客戶端都拿回正式配置這一查詢結果就是灰度已停止的判定依據。可選分支Console 側存在等價的/nacos/v3/console/cs/config/beta查詢與刪除端點見 Console API 測試場景說明行為差異是 beta 不存在時返回 HTTP 200 且datanull而不是 404Console 發布走 Console 請求頭體系。限制與邊界單個配置的最大灰度版本數受nacos.config.gray.version.max.count限制默認值為10beta 與 tag 灰度版本都計入該限制。內置灰度規則只有兩類betaClientIp命中逗號分隔的 beta IP 列表和taggrayName為tag_{tag}按請求 tag 匹配。如果請求顯式指定 tag 但未命中 tag 灰度會返回 tag-specific not-found而不是回退正式配置。灰度內容持久化在config_info_gray表中灰度發布或刪除都會記錄歷史變更并觸發攜帶對應grayName的 Config 變更事件beta/tag 變更在 3.3 版本線之后不得再通過 legacyisBeta/tag字段做舊表遷移。除 HTTP 接口外Maintainer SDK 通過BetaConfigMaintainerService提供 beta 和灰度發布的編程能力適合把上述流程放進運維腳本見 SDK Java 實現規范。進一步閱讀Config 灰度發布規范、Config 發布與查詢規范、Admin API 測試場景說明。【免費下載鏈接】nacosan easy-to-use dynamic service discovery, configuration and service management platform for building AI cloud native applications.項目地址: https://gitcode.com/GitHub_Trending/na/nacos創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 Nacos 如何對同一配置做 beta 灰度發布并按客戶端 IP 命中灰度版本？
Nacos 如何對同一配置做 beta 灰度發布并按客戶端 IP 命中灰度版本【免費下載鏈接】nacosan easy-to-use dynamic service discovery, configuration and service management platform for building AI cloud native applications.項目地址: https://gitcode.com/GitHub_Trending/na/nacos本文解決的問題是同一個namespaceId groupName dataId的配置如何額外發布一份只對被指定客戶端 IP 可見的 beta 版本并驗證命中與退出灰度的完整流程。Nacos 中灰度版本是同一 Config 身份下的從屬發布狀態namespaceId - groupName - dataId - grayName不是新的一條頂層配置。beta 內置規則按grayNamebeta存儲匹配條件是請求標簽ClientIp在逗號分隔的 beta IP 列表中優先級為Integer.MAX_VALUE內置規則中最高。以下內容基于 Nacos 3.x 的灰度模型config_info_gray表 GrayRule相關語義定義見 Config 灰度發布規范。操作前的兩個前提有一個可通過 HTTP 訪問的 Nacos 服務端。下文所有接口路徑都帶有/nacos前綴例如/nacos/v3/admin/cs/config命令中的http://Nacos 服務地址需要你替換為實際可訪問的協議、主機和端口。從 3.3 版本線開始運行時不再支持從舊表config_info_beta、config_info_tag向config_info_gray的兼容遷移。如果你的部署來自 3.0 之前版本且使用過 beta 灰度發布必須先完成相關數據遷移再升級否則本文流程不適用于舊表中的數據。第一步發布正式配置beta 版本依附于正式配置先確保正式版本存在。向POST /nacos/v3/admin/cs/config提交 form 表單發布字段與 集成測試的表單構造 一致curl -X POST http://Nacos 服務地址/nacos/v3/admin/cs/config \ -d dataIdgray.example.com \ -d groupNameDEFAULT_GROUP \ -d contentformal-content \ -d tag \ -d appName \ -d src_user \ -d configTags \ -d desc \ -d use \ -d effect \ -d typetext \ -d schema成功時響應為{data: true}測試中對該布爾值做了斷言。不傳namespaceId時默認使用publicnamespace。第二步用 betaIps 請求頭發布 beta 版本關鍵點同一個發布接口只需額外攜帶betaIps請求頭攜帶betaIps的發布會寫入 beta 灰度版本而不是覆蓋正式配置不帶灰度選擇字段的發布才寫正式配置。curl -X POST http://Nacos 服務地址/nacos/v3/admin/cs/config \ -H betaIps: 10.0.0.2 \ -d dataIdgray.example.com \ -d groupNameDEFAULT_GROUP \ -d contentbeta-content \ -d tag \ -d appName \ -d src_user \ -d configTags \ -d desc \ -d use \ -d effect \ -d typetext \ -d schemabetaIps的取值是要命中的客戶端 IP逗號分隔可寫多個 IP。示例中的10.0.0.2、gray.example.com、DEFAULT_GROUP等均為示例值替換為你自己的 dataId、group 和客戶端 IP。成功后同樣返回{data: true}此后該配置同時擁有正式版本和grayNamebeta的灰度版本兩者共享namespaceId groupName dataId但內容、md5、最后修改時間和灰度規則各自獨立。第三步通過 Admin beta 查詢接口驗證 beta 版本已生效驗證用專門的 beta 查詢端點而不是正式配置查詢。注意Admin 正式查詢不會靜默返回灰度內容要檢查 beta 版本必須走 beta 端點curl http://Nacos 服務地址/nacos/v3/admin/cs/config/beta?dataIdgray.example.comgroupNameDEFAULT_GROUPnamespaceId可省略省略時為public。命中時data中包含該配置的身份、beta 內容和規則示例結果字段來自 beta Admin API 集成測試 的斷言{ data: { dataId: gray.example.com, groupName: DEFAULT_GROUP, namespaceId: public, content: beta-content, grayName: beta, grayRule: 包含 betaIps 的序列化灰度規則 } }其中grayRule為序列化后的灰度規則測試斷言其內容包含發布時傳入的betaIps值。如果該配置當前沒有 beta 版本接口返回 HTTP 404錯誤碼為RESOURCE_NOT_FOUND錯誤消息為Config is not in beta。第四步按客戶端 IP 驗證運行時灰度命中運行時查詢端點是GET /nacos/v3/client/cs/config供客戶端獲取實際生效的配置curl http://Nacos 服務地址/nacos/v3/client/cs/config?dataIdgray.example.comgroupNameDEFAULT_GROUP命中邏輯由 Config 發布與查詢規范 定義運行時查詢先從客戶端 IP、顯式 tag 和連接標簽構建請求標簽再遍歷已排序的灰度版本返回第一個命中的灰度版本未命中才回退正式配置。因此從betaIps列表中的機器本例中源 IP 為10.0.0.2的客戶端發起該請求返回的是 beta 內容響應還包含命中的灰度版本的 md5、encryptedDataKey、最后修改時間、配置類型和灰度元數據從列表外的機器發起同一請求返回的是正式配置內容。當存在多個灰度版本時按優先級降序匹配優先級相同再按grayName排序beta 規則優先級為Integer.MAX_VALUE是內置規則中最先被匹配的。響應中是否包含 beta/tag 元數據字段的驗證可參考 Client API 測試場景說明 中ConfigOpenApiITCase對GET /v3/client/cs/config的描述。第五步停止灰度刪除 beta 版本確認灰度完成后刪除 beta 版本即可退出灰度curl -X DELETE http://Nacos 服務地址/nacos/v3/admin/cs/config/beta?dataIdgray.example.comgroupNameDEFAULT_GROUP刪除灰度版本只移除該版本不刪除正式配置。刪除后再執行第三步的 beta 查詢會返回 404Config is not in beta此時所有客戶端都拿回正式配置這一查詢結果就是灰度已停止的判定依據。可選分支Console 側存在等價的/nacos/v3/console/cs/config/beta查詢與刪除端點見 Console API 測試場景說明行為差異是 beta 不存在時返回 HTTP 200 且datanull而不是 404Console 發布走 Console 請求頭體系。限制與邊界單個配置的最大灰度版本數受nacos.config.gray.version.max.count限制默認值為10beta 與 tag 灰度版本都計入該限制。內置灰度規則只有兩類betaClientIp命中逗號分隔的 beta IP 列表和taggrayName為tag_{tag}按請求 tag 匹配。如果請求顯式指定 tag 但未命中 tag 灰度會返回 tag-specific not-found而不是回退正式配置。灰度內容持久化在config_info_gray表中灰度發布或刪除都會記錄歷史變更并觸發攜帶對應grayName的 Config 變更事件beta/tag 變更在 3.3 版本線之后不得再通過 legacyisBeta/tag字段做舊表遷移。除 HTTP 接口外Maintainer SDK 通過BetaConfigMaintainerService提供 beta 和灰度發布的編程能力適合把上述流程放進運維腳本見 SDK Java 實現規范。進一步閱讀Config 灰度發布規范、Config 發布與查詢規范、Admin API 測試場景說明。【免費下載鏈接】nacosan easy-to-use dynamic service discovery, configuration and service management platform for building AI cloud native applications.項目地址: https://gitcode.com/GitHub_Trending/na/nacos創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考