Pkl 是。Pkl(发音为 “Pickle”)是苹果公司在 “配置即代码” 领域的一项创新尝试。它介于传统格式(如 JSON)和全功能编程语言(如 Python)之间,致力于让配置变得更加可靠和易于维护。Pkl 之所以吸引我,是因为它并不试图成为一种通用的编程语言,而是聚焦于解决一个核心问题:让配置不再麻烦。
作为一个曾多次与 YAML 缩进问题和 JSON 缺少注释功能作斗争的人,我非常期待苹果通过 Pkl 提供的改进。
一.Pkl 的独特之处
配置文件通常从简单的初始状态开始,但随着需求变化逐渐变得复杂。以一个典型的部署配置为例:起初可能只包含几个环境变量,但最终会发展为跨越多个服务的数百行代码。YAML 和 JSON 在处理这种复杂性时表现乏力,而通用编程语言则可能显得大材小用。Pkl 并非仅仅是另一种配置格式。它将静态配置格式(如 JSON 和 YAML)的特点与编程语言的能力相结合。可以将其视为具有 YAML 简洁性的同时,在需要时能够提供更多功能支持。
// Basic config
name = "My Service"
port = 8080
// Template for shared settings
baseService {
image = "nginx:1.19"
healthCheck = true
}
// Reuse template for specific services
webService = new baseService {
port = 80
}
apiService = new baseService {
port = 3000}
上面的代码展示了 Pkl 的混合特性。它像 YAML 一样简洁易读,但同时支持类似编程语言的抽象和重用功能。
Pkl 强制实施不可变性 —— 一旦定义某个值,就无法修改。这一特性有效避免了因值被意外更改而导致的一系列配置错误。Pkl 还通过模式提供内置验证功能:
class DatabaseConfig {
host: String
port: Int
function validate() {
port > 0 && port < 65536
}}
模式会在评估配置时对其进行验证,从而在问题进入生产环境前及时发现。Pkl 的设计旨在无缝融入现有工作流。它支持输出到 JSON、YAML、XML 和 Java Properties 文件。这意味着,你可以使用 Pkl 为需要这些格式的工具生成配置。Pkl 还为多种编程语言提供了集成库:
.JVM(Java 和 Kotlin)
.Swift
.Go
这些库使得应用程序可以直接读取和解析 Pkl 配置,无需借助中间格式的 JSON 或 YAML 文件。考虑典型的微服务架构,每个服务可能需要类似但稍有不同的配置。在 YAML 中,这种需求通常会导致复制粘贴相似的配置块,并进行细微修改。而 Pkl 通过继承和组合功能,更优雅地解决了这一问题。
// Base application config with shared defaults
class AppConfig {
port: Int = 8080
logLevel: String = "INFO"
timeout: Duration = Duration.seconds(30)
}
// 堆代码 duidaima.com
// Specific service config
api = new AppConfig {
port = 3000
timeout = Duration.minutes(2)}
二.我们真的需要另一种语言吗?
对 Pkl 的一些保留意见值得探讨。首先,即便是领域特定语言的引入,也不可避免地增加了学习成本。每个新团队成员都需要学习 Pkl,每个工具链都需要适配它,每个 CI/CD 管道也需要支持它。对于配置这样基础的任务来说,这无疑增加了许多摩擦。JVM 集成也引发了一些担忧。虽然 Pkl 自称轻量,但如果需要一个 JVM 运行时来管理配置,对于那些简单服务或容器化环境来说,这显得有些麻烦。在这样的环境中,每一兆字节的资源都弥足珍贵,这种需求可能成为 Pkl 被采用的障碍。
另一个值得注意的问题是苹果的长期承诺。苹果曾推出过多款开发者工具,但随后又放弃支持(还记得 WebObjects 吗?)。虽然 Pkl 是开源项目,但它的开发显然以苹果为主导。如果苹果不再对其感兴趣,社区力量或许不足以维持其发展。Pkl 的语法虽清晰简洁,却引入了另一种新的配置方式。当前,市场上已有 YAML、TOML、JSON5 和 HCL 等多种格式,每种格式都曾试图解决配置问题,如今又多了 Pkl。这种碎片化可能并不会让配置管理更轻松,反而可能加剧混乱。
Pkl 的验证功能固然强大,但这类功能完全可以通过 JSON Schema 或 OpenAPI 规范实现。而这两者已经在业界得到了广泛的应用和支持。Pkl 是否真正解决了现有工具无法处理的问题,仍需进一步探讨。
从苹果自己的生态系统来看,有趣的是它们目前主要依赖 Information Property List 和 JSON 进行配置。如果 Pkl 真是一个重大的改进,为什么它没有在苹果的产品中得到更广泛的应用?这些顾虑并非要全盘否定 Pkl 的创新性,而是提醒我们在决定采用时需要慎重,尤其是当项目的复杂性并未达到像苹果那种规模时。
我同样对 Pkl 在企业级场景的适用性持保留态度。大公司通常对新语言和工具的引入有严格要求。即使 Pkl 是苹果推出的,要让企业的安全团队批准这一新配置语言,也会面临不小的挑战。对于很多企业来说,权衡风险与收益,最终可能觉得现有的解决方案 —— 尽管不完美 —— 更安全和可靠。
三.结束语
配置管理领域长期以来由设计于数十年前的格式主导,缺乏创新。Pkl 的出现是一种积极的新尝试,它承认了配置从简单键值对到复杂任务关键代码的演变趋势。