虽然Debezium的UI是我们愿景的重要组成部分，但开发与Kafka Connect紧密绑定的UI并不是正确的方向。因此，决定冻结当前Web UI项目的开发。这个决定有两个主要原因：

• 团队没有足够的能力（也没有兴趣）开发一个与一些现有产品（如Lenses）相媲美的通用Kafka连接器UI。因此，我们的UI只能与Debezium连接器特定地配合使用。
• Debezium Server越来越受欢迎，我们希望提供一种用户友好的方式来管理这种Debezium的变种。不幸的是，Debezium Server的部署模型与作为连接器部署Debezium非常不同。

一、下一阶段工作

• 正如前面的段落提到的，当前的UI项目，我们并没有放弃这个想法，这可能不会让人感到意外。决策的一部分是探索创建一个新的UI的可能性，虽然仍然专注于Debezium，但逐步支持多种部署模型。这个想法是从在Kubernetes上部署Debezium Server开始，然后是在裸机上部署Debezium Server。在将来的某个时候，我们希望回到Kafka Connect，并支持将Debezium作为Kafka Connect连接器进行部署和操作。

二、设计新的UI

• 在设计新平台时，我们为自己设定的目标之一是简化对Debezium功能的理解。因此，我们将抽象出底层的部署模型。我们不再关注服务器和连接器，而是希望让用户以数据为中心来思考Debezium。因此，新一代的UI应该与数据流水线一起工作 - 您定义源、目标和任何数据转换。
• 然后，这些可以组合成可部署的数据流水线。根据目标环境（Kafka Connect、Kubernetes、裸机），将使用适当的部署方式。

当数据流水线部署到Kubernetes或裸机上时：

• 源是Debezium源连接器的配置
• 转换是常规的SMT
• 目标对应Debezium Server的Sink的配置。

当数据流水线部署到Kafka Connect时：

• 源是Debezium源连接器的配置
• 转换是常规的SMT
• 目标始终是一个Kafka主题。

在将来，当针对Kafka Connect进行定义时，我们还可以允许使用JDBC和MongoDB Sink连接器作为目标，从而实现真正的端到端定义的数据流水线。

三、目前阶段

• 我们正处于这一旅程的开始。尽管如此，还是有一个粗略的 PoC 原型可供您检查。
• 正如已经简要提到的，最初的计划是仅将 Kubernetes 作为受支持的部署环境，更具体地说，是 Kubernetes 上的 Debezium Server。这一选择使我们能够利用 Debezium Operator。

• 我们打算逐步引入配置和功能支持。因此，配置有意地具有明确的观点和简单性 - 目前所有的数据流水线只能使用临时存储。在这个早期版本中，您必须将所有配置属性设置为简单的键值对。我们计划在将来改变这一点，并且作为下一步，您可以期待属性名称的自动完成，最终，将呈现完全专门化的表单。

您可以在 GitHub 上查看代码库的当前状态：

• Debezium Platform Conductor (Backend)
• Debezium Platform Stage (Frontend)

四、更多内容

• Debezium系列之：Debezium UI部署详细步骤
• Debezium系列之：Debezium镜像仓库Quay.io，使用Debezium镜像仓库的方法和案例

更多Debezium技术文章请阅读：

• Debezium技术专栏