Keycloak.X 更新

如前所述，我们将更加关注您使用 Keycloak 的体验。考虑到这一点，我们确定了几个我们认为涵盖了各种不同用例的体验。

我们正在切换到 Quarkus 作为构建 Keycloak 的平台。与 WildFly 相比，这可以缩短启动时间并降低内存占用。它还提供了一种更简单的方法来配置 Keycloak，使用命令行参数和环境变量而不是复杂的 XML 文件。Quarkus 的另一个优点是它让我们可以更好地控制发行版中包含的外部库，包括更快地升级依赖项，这将显着改善 CVE 问题。

作为 Keycloak.X 的一部分，我们正在对存储层进行重大重新架构，以解决当前架构中发现的一些缺陷。零停机升级、可扩展性和可用性将成为这种新架构的关键主题，并且从长远来看，它将更容易支持额外的存储类型。

使用 Keycloak 的当前配置方法，创建围绕容器的良好体验是有问题的，因为容器必须将环境变量转换为复杂的 XML 配置文件。随着我们围绕 Quarkus 所做的工作，使用环境变量配置 Keycloak 成为一项原生功能，这使得提供出色的容器体验变得更加简单。

同样，操作员也可以变得更简单，因为它将更容易配置 Keycloak，并且可以从基本发行版获得更好的意见性配置，这些配置会从 Zip 发行版流向容器，最后流向操作员。为了更好地对齐代码库，我们还将使用 Java SDK 和 Quarkus 从头开始重写操作员。

指标、跟踪、日志记录和运行状况检查都是云原生应用程序的重要方面。这些都是管理和调试生产环境中 Keycloak 的重要功能，尤其是在 Kubernetes 或 OpenShift 上运行时。

在 GitOps 或 CI/CD 环境中，管理 Keycloak 中的运行时配置可能会有问题。由于所有配置（如领域和客户端）都驻留在数据库中，并且只能通过 REST API 进行管理，因此很难可靠地作为 GitOps 过程的一部分进行管理。

随着存储层重新架构，出现了一种非常强大的功能，可以从多个来源联合配置，我们计划利用这种功能，使用基于文件的存储，Keycloak 可以从文件系统（当然是用 YAML）读取更多静态/不可变的配置，并将此与来自数据库的动态/可变配置相结合。

此外，这使您能够在 Git 存储库中签入静态配置，并在需要时将其部署到开发、测试和生产环境中。

Keycloak 今天有大量的扩展点，称为 SPI。使用 Java（在某些情况下使用 JavaScript），可以使用这些 SPI 的自定义提供程序自定义 Keycloak。尽管功能强大且灵活，但这在现代以 Kubernetes 为中心的架构中并不理想。由于扩展与 Keycloak 位于同一位置，因此更难部署、升级和扩展扩展。扩展也不能使用任何语言或框架编写，这使得非 Java 开发人员扩展 Keycloak 的成本更高。

考虑到这一点，我们计划更加关注通过远程扩展扩展和与 Keycloak 集成的能力，并且正在研究 REST、gRPC、Knative、Kafka 等作为实现这一目标的工具。此外，我们还希望能够使用 "无头" Keycloak，允许您以任何您想要的方式构建前端，这将是对当前主题自定义 UI 方法的极大补充。

最后但并非最不重要的一点。我们还计划分解 Keycloak，以及在 Keycloak 的代码库和功能方面提供更好的隔离。我们不打算在这里采用完全的微服务架构，而是采用一种明智的折衷方案，使所有内容都能够作为一个单一进程运行，并且能够将 Keycloak 的某些部分分离到外部服务中。