Keycloak.X 更新

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

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

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

在当前 Keycloak 的配置方法中，围绕容器创建良好的体验是有问题的，因为容器必须从环境变量转换为复杂的 XML 配置文件。通过我们在 Quarkus 方面所做的工作，使用环境变量配置 Keycloak 成为了一种原生事物，从而可以更轻松地提供出色的容器体验。

同样，Operator 也可以变得更简单，因为它将更容易配置 Keycloak，并且从基本发行版中获得更好的有主见的配置，这从 Zip 发行版、容器最终传递到 Operator。为了更对齐代码库，我们还使用 Java SDK 和 Quarkus 从头开始重写 Operator。

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

在 GitOps 或 CI/CD 环境中，管理 Keycloak 内的运行时配置可能存在问题。由于所有配置（例如 realm 和客户端）都位于数据库中，并且只能通过 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 的某些部分分离到外部服务中。