楔子: 以螞蟻集團典型的建站場景為例，在接入 Kusion 后，用戶側配置代碼減少到 5.5%，用戶面對的 4 個平臺通過接入統一代碼庫而消減，在無其他異常的情況下交付時間從 2 天下降到 2 小時……

注：本文是柴樹杉在 2021 GIAC 大會上分享的內容。

00

你好 GIAC

大家好，我是來自螞蟻集團的同學，很高興能在 GIAC 的編程語言新范式板塊和大家分享《KCL 配置策略語言》。KCL 語言是螞蟻內部的 Kusion 解決方案中針對云原生基礎設施配置代碼化自研的 DSL 語言，目前已經在建站場景等一些場景開始小范圍推廣試用。

我們先看一下簡單的 KCL 代碼：

schema GIACInvitation[name: str]:Name: str = nameTopic: str = "分享主題"Company?: str = NoneType: str = "分享嘉賓"Address: str = "深圳"invitation = GIACInvitation("姓名") {Topic: "KCL 配置策略語言"Company: "螞蟻集團" }

這個例子代碼先通過 schema 定義了一個 GIACInvitation 結構體：該結構體有一個 str 類型的 Name 參數，同時還有一組標注了類型和默認值的屬性。然后通過聲明式的語法構造了 GIACInvitation 的實例 invitation。

這個例子雖然簡單，但是包含了 KCL 最重要的 schema 語言結構。從例子可以看出 KCL 嘗試通過聲明式的語法、靜態類型檢查特性來改進配置代碼的編寫和維護工作。這也是設計 KCL 語言的初衷，我們希望通過編程領域成熟的技術理論來解決云原生領域的配置代碼化的問題。

01

KCL 語言的誕生背景

在經典的 Linux/UNIX 操作系統中，我們通過 Shell 和系統內置的各種工具和內核進行交互，同時通過 Shell 腳本來管理更上層的 App?？梢哉f Shell 語言極大地簡化了內核的編程界面，不僅僅提升了操作系統易用性也簡化了上層 App 的管理和運維，也提高了生產效率。而 Kubernetes 作為容器管理領域的事實標準，已經成為云計算時代的 Linux/UNIX。類比 UNIX 系統，Kubernetes 目前還缺少一種符合其聲明式、開放、共享設計理念的交互語言及工具。

1.1 為何要設計 KCL 語言？

K8s 已經成為云計算的操作系統，但是目前尚缺少功能完備的 Shell 交互界面。目前雖然有很多而且開源方案，但是還沒有像 UNIX 的 Shell 那種出現比較成熟的方案，特別是尚無法滿足頭部互聯網企業大規模工程化的要求。云原生技術與企業落地之間存在 Gap 需要填補，這正是云原生工程化要解決的問題，也是設計 KCL 語言的出發點。

1.2 目前是一個好時機

云原生的思路是高度的開放化和民主化，結果就是萬物可配置，一切配置都是代碼。在配置代碼面前人人平等，每個用戶都可以通過調整配置代碼和基礎平臺設施進行交互。因此對配置的編寫和維護正在成為云計算時代軟件工程師的必備的技能和需求?；趯υ圃渲么a化需求的日益旺盛，硅谷的諸多頭部公司已經對這個方向進行了大規模的實踐和驗證，這些都給了我們大量可以參考的經驗。

因此螞蟻的 Kusion 項目嘗試通過 KCL 配置策略語言正是為了簡化云原生技術設施的接入方式設計，其設計目標不僅僅是為了提升螞蟻基礎設施的開放程度及使用效率，同時希望能夠優化共享、協同的開發流程，可以說其定位正是云原生時代的 Shell 語言。雖然目前還處于探索和實踐階段，我們通過此文和大家分享下 KCL 語言的設計與實現的一些理念，為云原生的快速到來貢獻一點綿薄之力。

1.3 KCL 誕生歷史

KCL 語言從 2019 年開始初期的調研和設計工作。到 2020 年 3 月發布 kcl-0.1，基于 Python 定制語法，采用 Go 版本的 Grumpy 和 AntLR 等工具開發。2020 年下半年改用 Python 語言并加快了開發和迭代速度，發布的 kcl-0.2.x 引入了大量語言特性、增加了 Plugin 擴展支持、同時支持 IDEA 插件。2021 年上半年開始統一優化和整合語言特性，發布的 kcl-0.3 優化類型系統、集成單元測試工具、優化執行性能并提供了 Go 等多語言的 API 支持、同時通過 LSP 為 VSCode 提供支持。2021 年下半年開始在建站等常見落地，同時引入靜態類型檢查和優化性能，完善語言的文檔支持。

02

KCL 語言的設計原則

基于螞蟻踐行多年的經典運維中臺沉淀的經驗和對各種問題利弊的思考，Kusion 項目對如何充分利用云原生技術帶來的紅利，打造一個開放、透明、聲明式、可協同的運維體系進行了探索和思考，提出并實踐了基于基礎設施代碼化的云原生協同開發的模型。而 KCL 語言正是 Kusion 項目為了解決云原生協同開發而設計的聲明式的配置編程語言，簡單、穩定、高效和工程化是 KCL 語言設計的設計理念。

2.1 簡單為王

簡單不僅僅可以降低學習和溝通的成本，而且可以減少代碼出問題的風險。不論是 UNIX 奉行的 KISS 原則還是 Go 語言推崇的 Less is more 設計理念，簡化易用的界面始終是各種成功產品追求的一個目標。同樣從簡單原則出發，KCL 語言在參考現代編程語言之上只保留了必要的元素，同時通過類型自動推導、引入受限的控制流和 schema 提供了基礎靈活的配置定義編寫能力，刪減語言特性始終是 KCL 語言設計工作的一個重要目標。

2.1.1 聲明式語法

聲明式編程是和命令式編程并列的一種編程范式，聲明式編程只告訴你想要的結果，執行引擎負責執行的過程。聲明式編程使用更加簡單，可以降低命令式拼裝造成的復雜性和副作用，保持配置代碼清晰可讀，而復雜的執行邏輯已經由 Kubernetes 系統提供支持。

KCL 語言通過簡化對 schema 結構體實例化的語法結構對聲明式語法提供支持，通過僅提供少量的語句來減少命令過程式編程帶來的復雜性。圍繞 schema 和配置相關的語法，KCL 希望每種配置需求盡可能通過固定的寫法完成，使得配置代碼盡可能的統一化。

比如作為 KCL 聲明式語法的核心結構 schema 可以采用聲明式方式實例化：

schema Name:firstName: strlastName: strschema Person:name: Name = {firstName: "John"lastName: "default"}JohnDoe = Person {name.lastName: "Doe" }

首先通過 schema 定義了一個 Name 結構，結構包含 2 個字符串類型的必填屬性。

然后在 Person 中復用 Name 類型聲明一個 Name 屬性，并且給 Name 屬性設置了默認值以簡化用戶使用。

最終在定義 JohnDoe 配置定義的時候，只需填寫 Name.lastName 一個屬性參數即可，其他部分屬性均采用默認的參數。

對于一些標準的業務應用，通過將可復用的模型封裝為 KCL schema，這樣可以為前端用戶提供最簡單的配置界面。比如基于螞蟻內部 Konfig 大庫中 sofa.SofaAppConfiguration 只需添加少量的配置參數就可以定制一個 App。

appConfiguration = sofa.SofaAppConfiguration {resource: resource.Resource {cpu: "4"memory: "8Gi"disk: "50Gi"}overQuota: True }

通過聲明式語法描述必要的參數（其他的參數全部采用默認配置），可以極大簡化普通用戶的配置代碼。

2.1.2 順序無關語法

有別于命令式編程，KCL 推崇的是更適合于配置定義的聲明式語法。以斐波那契數列為例，可以把一組聲明式的定義看作一個方程組，方程式的編寫順序本質上不影響方程組的求解，而計算屬性依賴并“求解”的過程由 KCL 解釋器完成，這樣可以避免大量命令式拼裝過程及順序判斷代碼。

schema Fib:n1: int = n - 1n2: int = n1 - 1n: intvalue: intif n <= 1:value = 1elif n == 2:value = 1else:value = (Fib {n: n1}).value + (Fib {n: n2}).valuefib8 = (Fib {n: 8}).value # 21

代碼中 Fib 定義的成員 n、n1 和 n2 有一定的依賴關系，但是和它們書寫的順序并無關系。KCL 語言引擎會根據聲明式代碼中的依賴關系自動計算出正確的執行順序，同時對類似循環引用等異常狀態告警。

2.1.3 同名配置合并

當整個業務和開發維護團隊都變得復雜時，配置代碼的編寫和維護也將變得復雜化：同一份配置參數可能散落在多個團隊的多個模塊中，同時一個完整的應用配置則需要合并這些散落在不同地方的相同和不同配置參數才可以生效，而相同的配置參數可能因為不同團隊的修改而產生沖突。通過人工方式同步這些同名配置和合并不同的配置都是一個極大的挑戰。

比如 Konfig 大庫中應用配置模型分為 base 和各環境 stack 配置，要求程序運行時按照某一 merge 策略合并為一份應用配置，相當于要求大庫前端配置能夠自動合并，即能夠分開多次定義并且合并，然后實例化生成相應的唯一前端配置。

借助 KCL 語言的能力和 Konfig 的最佳實踐，可通過將基線配置和環境配置自動合并簡化配置的編寫。比如對于標準 SOFA 應用 opsfree，其基線配置和環境配置分別維護，最終交由平臺工具進行配置合并和檢查。KCL 語言通過自動化合并同名配置實現簡化團隊協同開發的設計目標。

比如 base 配置收集的通用的配置：

appConfiguration = sofa.SofaAppConfiguration {mainContainer: container.Main {readinessProbe: probe_tpl.defaultSofaReadinessProbe}resource: res_tpl.mediumreleaseStrategy: "percent" }

然后再預發環境在 base 配置的基礎之上針對某些參數進行微調：

appConfiguration = sofa.SofaAppConfiguration {resource: resource.Resource {cpu: "4"memory: "8Gi"disk: "50Gi"}overQuota: True }

合并的 pre 配置實際是一份 SofaAppConfiguration 配置（相當于如下等效代碼，環境配置的優先級默認高于基線配置）

appConfiguration = sofa.SofaAppConfiguration {mainContainer: container.Main {readinessProbe: probe_tpl.defaultSofaReadinessProbe}resource: resource.Resource {cpu: "4"memory: "8Gi"disk: "50Gi"}overQuota: TruereleaseStrategy: "percent" }

目前的同名配置雖然只針對應用的主包配置有效，但已經帶來了可觀察的收益。

2.2?穩定壓倒一切

越是基礎的組件對穩定性要求越高，復用次數越多的穩定性帶來的收益也更好。因為穩定性是基礎設施領域一個必備的要求，不僅僅要求邏輯正確，而且需要降低錯誤出現的幾率。

2.2.1 靜態類型和強不可變性

很多配置語言采用運行時動態檢查類型。動態類型最大的缺點只能檢查正在被執行屬性的類型，這非常不利于開發階段提前發現類型的錯誤。靜態類型不僅僅可以提前分析大部分的類型錯誤，還可以降低后端運行時的動態類型檢查的性能損耗。

除了靜態類型，KCL 還通過 final 關鍵字禁止某些重要屬性被修改。靜態類型再結合屬性的強不可變性，可以為配置代碼提供更強的穩定性保障。

schema CafeDeployment:final apiVersion: str = "apps.cafe.cloud.alipay.com/v1alpha1"final kind: str = 123 # 類型錯誤schema ContainerPort:containerPort: int = 8080protocol: "TCP" | "UDP" | "SCTP" = "TCP"ext? : str = None

比如對于 CafeDeployment 中的 apiVersion 信息是一種常量類型的配置參數，final 為這類配置提供保障：

代碼中 apiVersion 和 kind 屬性都被 final 保護禁止被修改。但是 kind 因為屬性類型初始值不同而隱含一個錯誤，通過靜態類型檢查很容易在開發階段發現錯誤并改正。

2.2.2運行時類型和邏輯 check 驗證

KCL 的 schema 不僅僅是帶類型的結構體，也可以用于在運行時校驗存量的無類型的 JSON 和 YAML 數據。此外 schema 的 check 塊可以編寫語義檢查的代碼，在運行時實例化 schema 時會自動進行校驗。同時，基于 schema 的繼承和 mixin 可以產生跟多關聯的 check 規則。

比如以下的例子展示 check 的常見用法：

schema sample:foo: strbar: intfooList: [str]check:bar > 0 # minimum, also support the exclusive casebar < 100, "message" # maximum, also support the exclusive caselen(fooList) > 0 # min length, also support exclusive caselen(fooList) < 100 # max length, also support exclusive caseregex.match(foo, "^The.*Foo$") # regex matchisunique(fooList) # uniquebar?in?range(100)?#?rangebar in [2, 4, 6, 8] # enummultiplyof(bar, 2) # multipleOf

check 中每個語句都是一個可以產生 bool 結果的表達式和可選的錯誤信息組成（每個普通的 bool 表達式其實是 assert 語句的簡化而來）。通過內置的語法和函數可以實現在運行時對屬性值的邏輯驗證。

2.2.3 內置測試支持

單元測試是提升代碼質量的有效手段。KCL 基于已有的 schema 語法結構，配合一個內置 kcl-test 命令提供靈活的單元測試框架（結合 testing 包可指定面值類型的命令行參數）。

內置測試工具

schema TestPerson:a = Person{}assert a.name == 'kcl'schema TestPerson_age:a = Person{}assert a.age == 1

kcl-test 命令不僅僅執行單元測試，還會統計每個測試執行的時間，而且可以通過正則表達式參數選擇執行指定的測試。此外通過 kcl-test ./... 可以遞歸執行子目錄的單元測試，同時支持集成測試和 Plugin 測試。

2.3?高效是永恒的追求

KCL 代碼不僅僅通過聲明式的風格簡化編程，同時通過模塊支持、mixin 特性、內置的 lint 和 fmt 工具、以及 IDE 插件提供高效的開發體驗。

2.3.1 schema 中好用的語法

schema 是 KCL 編寫配置程序的核心語法結構，其中幾乎每個特性均是針對具體的業務場景提效而設計。比如在定義和實例化深層次嵌套的配置參數時，均可以直接指定屬性的路徑定義和初始化。

schema A:a: b: c: inta: b: d: str = 'abc'A {a.b.c: 5 }

同時為了安全，對于每個屬性默認都是非空的字段，在實例化時會自動進行檢查。

schema 不僅僅是一個獨立的帶類型注解的配置對象，我們也可以通過繼承的方式來擴展已有的 schema：

schema Person:firstName: strlastName: str# schema Scholar inherits schema Person schema Scholar(Person):fullName: str = firstName + '_' + lastNamesubject: strJohnDoe = Scholar {firstName: "John",lastName: "Doe",subject: "CS" }

代碼中 Scholar 從 Person 繼承，然后又擴展了一些屬性。作為子類的 Scholar 可以直接訪問父類中定義的 firstName 等屬性信息。

繼承是 OOP 編程中基礎的代碼復用手段，但同時也有多繼承導致的菱形繼承的技術問題。KCL 語言刻意簡化了繼承的語法，只保留了單繼承的語法。同時 schema 可以通過 mixin 特性混入復用相同的代碼片段，對于不同的能力配套，我們通過 mixin 機制編寫，并通過 mixin 聲明的方式“混入”到不同的結構體中。

比如通過在 Person 中混入 FullnameMixin 可以給 schema 增加新的屬性或邏輯（包括 check 代碼塊）：

schema FullnameProtocol:firstName : str = "default"lastName : strmixin FullnameMixin for FullnameProtocol:fullName : str = "${firstName} ${lastName}"schema relax Person:mixin [FullnameMixin]firstName : str = "default"lastName : str

通過 KCL 的語言能力，平臺側同學可以通過單繼承的方式擴展結構體，通過 mixin 機制定義結構體內屬性的依賴關系及值內容，通過結構體內順序無關的編寫方式完成聲明式的結構體定義，此外還支持如邏輯判斷、默認值等常用功能。

2.3.2 doc、fmt、lint 和外圍的 LSP 工具

在編程領域代碼雖然是最核心的部分，但是代碼對應的文檔和配套的工具也是和編程效率高度相關的部分。KCL 配置策略語言設計哲學并不局限于語言本身，還包括文檔、代碼格式化工具、代碼風格評估工具和 IDE 的支持等。

KCL 通過 kcl-doc 支持從配置代碼直接提取產生文檔，自動化的文檔不僅僅減少了手工維護的成本，也降低的學習和溝通成本。kcl-fmt 則很方便將當前目錄下的全部代碼（包含嵌套的子目錄）格式化為唯一的一種風格，而相同格式的代碼同樣降低的溝通和代碼評審的成本。

kcl-lint 工具則是通過將一些內置的風險監測策略對 KCL 代碼平行評估，方便用戶根據評估結果優化代碼的風格。

2.4?工程化的解決方案

任何語言想要在工程中實際應用，不僅僅需要很好的設計，還需要為升級、擴展和集成等常規的場景提供完整的解決方案。

2.4.1 多維度接口

KCL 語言設計通過在不同的抽象層次為普通用戶（KCL 命令行）、KCL 語言定制者（Go-API、Python-API）、KCL 庫擴展者（Plugin）和 IDE 開發者（LSP 服務）均提供了幾乎等價的功能界面，從而提供了最大的靈活度。

2.4.2 千人千面的配置 DB

KCL 是面向配置的編程語言，而配置的核心是結構化的數據。因此，我們可以將完整 KCL 代碼看做是一種配置數據庫。通過 KCL 的配置參數的查詢和更新（override/-O 命令）可以和對應的配置屬性路徑，可以實現對屬性參數的查詢、臨時修改和存盤修改。

將代碼化的配置作為 DB 的唯一源，不僅僅可以集成 DB 領域成熟的查詢和分析手段，而且可以通過配置代碼視角調整配置代碼的邏輯結構。特別是在自動化運維實踐中，通過程序自動生成的配置代碼修改的 PullRequest 可以方便引入開發人員進行代碼評審，很好地達到人機通過不同界面配合運維。

2.4.3 版本平滑升級

隨著業務和代碼的演化，相關模塊的 API 也會慢慢腐化。KCL 語言設計通過嚴格的依賴版本管理，然后結合語言內置的語法和檢查工具保障 API 平滑的升級和過渡，再配合代碼集成測試和評審流程提升代碼安全。KCL 語言通過 @deprecated 特性在代碼出現腐化早期給出提示，同時為用戶的過渡升級留出一定的時間窗口，甚至等到 API 徹底腐爛前通過報錯的方式強制要求同步升級相關的代碼。

比如在某次升級中，Name 屬性被 fullName 替代了，則可以通過 @deprecated 特性標志：

schema Person:@deprecated(version="1.1.0", reason="use fullName instead", strict=True)name: str... # Omitted contentsperson = Person {# report an error on configing a deprecated attributename: "name" }

這樣在實例化 Person 時，Name 屬性的初始化語句將會及時收到報錯信息。

2.4.4 內置模塊、KCL 模塊、插件模塊

KCL 是面向配置的編程語言，通過內置模塊、KCL 模塊和插件模塊提供工程化的擴展能力。

用戶代碼中不用導入直接使用 builtin 的函數（比如用 len 計算列表的長度、通過 typeof 獲取值的類型等），而對于字符串等基礎類型也提供了一些內置方法（比如轉化字符串的大小寫等方法）。

對于相對復雜的通用工作則通過標志庫提供，比如通過 import 導入 math 庫就可以使用相關的數學函數，可以通過導入 regex 庫使用正則表達式庫。而針對 KCL 代碼也可以組織為模塊，比如 Konfig 大庫中將基礎設施和各種標準的應用抽象為模塊供上層用戶使用。

此外還可以通過 Plugin 機制，采用 Python 為 KCL 開發插件，比如目前有 meta 插件可以通過網絡查詢中心配置信息，app-context 插件則可以用于獲取當前應用的上下文信息從而簡化代碼的編寫。

03

KCL語言的實現原理

3.1 整體架構

KCL 雖然作為一個專用于云原生配置和策略定義的語言，但是保持大多數過程式和函數式編程語言的相似實現架構，其內部整體架構組成也是經典的編譯器 “三段式” 架構。下面是 KCL 實現的架構圖：

主要有以下幾個關鍵模塊：

• 解析器 Parser：解析器分析 KCL 源代碼產生 AST（抽象語法樹）。

• 編譯器 Compiler：對 AST 進行多次遍歷，對 AST 進行語義檢查（比如進行類型檢查、無效代碼檢查）并對 AST 進行優化（合并常量表達式等），最終產生虛擬機可以執行的字節碼。

• 虛擬機 Virtual Machine (VM)：執行 Compiler 產生的字節碼，計算產生相應的配置結果，并將配置結果序列化為 YAML/JSON 進行輸出。

整體架構分為三段式的好處是可以把針對 KCL 源語言的前端和針對目標機器的后端組合起來，這種創建編譯器組合的方法可以大大減少工作量。

比如目前的 KCL 字節碼定義和后端虛擬機采用自研實現，KCL 虛擬機主要用于計算產生配置結果并序列化為 YAML/JSON 進行輸出。

如果遇到在其他特殊使用 KCL 的場景比如在瀏覽器中執行 KCL，則可以重寫一個適配 WASM 的后端，就可輕易將 KCL 移植到瀏覽器中使用，但是 KCL 本身的語法和語義不需要發生任何變化，編譯器前端代碼也無需任何改動。

3.2 Go 和 Python 通信原理

為了更好地釋放 KCL 配置策略語言的能力以及遍于上層自動化產品集成（比如著名的編譯器后端 LLVM 就因其 API 設計良好，開發人員可以利用其 API 快速地構建自己的編程語言），KCLVM 目前提供了 Python 和 Go 兩種語言的 API，使得用戶可以使用相應的 API 快速地構建語言外圍工具，語言自動化查詢修改工具等提升語言的自動化能力，并且進一步可以基于此構建服務化能力，幫助更多的用戶構建自己云原生配置代碼化應用或者快速接入基礎設施。

KCLVM 主體采用 Python 代碼實現，而很多的云原生應用以 Go 程序構建，因此為了更好地滿足云原生應用用戶訴求。KCLVM 首先基于 CGo 和 CPython 構建了 Go 程序和 Python 程序通信媒介，基于此設計了 Python 函數到 Go 函數的 RPC 調用，調用參數以 JSON 形式存儲，使得 KCLVM-Python 編譯器的能力平滑地過度到 Go 代碼中，通過 Go 一行 import 調用即可操作 KCL 代碼。

補充：在服務化實踐的過程中，基于 CGO 調用 Python 的方案也遇到了一些問題：首先是 Go + CGO + Python 導致交叉編譯困難，對 ACI 的自動化測試和打包產生了挑戰；其次是 CGO 之后的 Python 不支持多語言多線程并發，無法利用多核的性能；最后即使通過 CGO 將 Python 虛擬機編譯到了 Go 程序中，依然還是需要安裝 Python 的標準庫和第三方庫。

3.3 協同配置原理

當有了一個簡單易用并能夠保證穩定性的配置語言后，另一個面臨的問題是如何使用配置代碼化的方式提升協同能力?；诖?#xff0c;KCL 配置可分為用戶側和平臺側配置兩類，最終的配置內容由各自用戶側和平臺側的配置內容共同決定，因此存在兩個方面的協同問題：

• 平臺側配置與用戶側配置之間的協同；

• 用戶側配置之間的協同。

針對上述協同問題，KCL 在技術側提出了順序無關語法，同名配置合并等抽象模型來滿足不同的協同配置場景。

以上圖為例，首先 KCL 代碼在編譯過程中形成兩張圖（用戶不同配置直接的引用和從屬關系一般形式一張有向無環圖），分別對應結構體內部聲明代碼及結構體使用聲明代碼。編譯過程可以簡單分為三步：

• 首先定義平臺側的結構體并形成結構體內部聲明代碼圖；

• 其次聲明并合并不同用戶側配置代碼圖；

• 最后將用戶側配置代碼圖計算的結果代入平臺側結構體內部聲明代碼圖求解，最終得到完整配置圖定義。

通過這樣簡單的計算過程，可以在編譯時完成大部分代換運算，最終運行時僅進行少量計算即可得到最終的解。同時在編譯合并圖過程中仍然能夠執行類型檢查和值的檢查，區別是類型檢查是做泛化、取偏序上確界（檢查某個變量的值是否滿足既定類型或者既定類型的子類型），值檢查是做特化、取偏序下確界（比如將兩個字典合并為一個字典）

04

對未來的展望

KCL 語言目前依然處于一個高速發展的階段，目前已經有一些應用開始試用。我們希望通過 KCL 語言為 Kusion 技術棧提供更強的能力，在運維、可信、云原生架構演進方面起到積極的作用。同時對于一些特殊的非標應用提供靈活的擴展和集成方案，比如我們正在考慮如何讓后端支持 WebAssembly 平臺，從而支持更多的集成方案。

在合適的時間我們希望能夠開放 KCL 的全部代碼，為云原生代碼化的快速落地貢獻綿薄之力。

05

本周推薦文章

螞蟻集團萬級規模 K8s?集群 etcd 高可用建設之路

2021-07-29

我們做出了一個分布式注冊中心

2021-07-27

開啟云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生態

2021-07-06

MOSN 子項目 Layotto：開啟服務網格+應用運行時新篇章

2021-06-21

總結

以上是生活随笔為你收集整理的KCL：声明式的云原生配置策略语言的全部內容，希望文章能夠幫你解決所遇到的問題。

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