第 16 章 Red Hat OpenShift Container Platform 上的高可用性事件驱动的决定

使用决策引擎在 Red Hat OpenShift Container Platform 上实施高可用性事件驱动的决定。

事件 模型了在特定时间点出现的事实。决策引擎提供了一组广泛的临时运算符来比较、关联和累积事件。在事件驱动决策中，决策引擎根据事件处理复杂的决策。每个事件都可以更改引擎的状态，影响后续事件的决策。

您不能在 Red Hat OpenShift Container Platform 上使用 Red Hat Process Automation Manager 的标准部署，如 使用 Operator 在 Red Hat OpenShift Container Platform 4 上部署 Red Hat Process Automation Manager 环境 中所述，来运行高度可用的事件驱动的决定。部署包括 KIE 服务器 pod，在扩展时相互独立。pod 的状态没有同步。因此，只能可靠地处理无状态调用。

复杂事件处理(CEP) API 对于通过决策引擎进行事件驱动的决定非常有用。决策引擎使用 CEP 检测和处理事件集合中的多个事件，以取消事件之间存在的关系，以及推断事件及其关系的新数据。有关决策引擎中 CEP 的更多信息，请参阅 Red Hat Process Automation Manager 中的 决策引擎。

根据 Red Hat Process Automation Manager 提供的参考，在 Red Hat OpenShift Container Platform 上实施高可用性事件驱动的决定。这种实施提供了一个具有安全故障转移的环境。

在这种参考实施中，您可以使用处理代码扩展 pod。pod 的副本不独立。其中一个副本会自动指定 领导。如果领导正常工作，则另一个副本会自动进行领导，处理将继续中断或数据丢失。

领导选举机制使用 Kubernetes ConfigMap 实施。领导与其他副本的协调通过 Kafka 交换信息来执行。领导始终是处理事件的第一个。处理完成后，领导会通知其他副本。不属于领导的副本仅在领导完全处理后才会执行事件。

当新副本加入集群时，此副本会从领导请求当前 droalal 会话的快照。如果 Kafka 主题中有最新的快照，领导可以使用最新的快照。如果最近快照不可用，领导会根据需要生成新的快照。在收到快照后，新副本会反序列化它，并在开始处理与领导协调中的新事件前执行快照中不包含的最后事件。

使用默认实现方法，该服务作为 fat KJAR 内置在 HA CEP 服务器中。在这种情况下，请再次构建和部署服务器，以更改服务的版本。当您切换到新版本时，工作内存的内容将会丢失。有关默认实现方法的步骤，请参考 第 17 章 实施 HA CEP 服务器。

如果您需要在不丢失工作内存内容的情况下升级服务的版本，请使用备用实现方法，并在 Maven 存储库中提供 KJAR 和所有依赖项。在这个实现方法中，使用来自客户端代码的 UpdateKJarGAV 调用来触发新的 KJAR 版本的部署。此调用由领导(leader)处理，然后其他副本，每个 pod 都加载新的 KJAR。工作内存的内容保留原位。有关这个实现方法的步骤，请参考 第 18 章 使用 Maven 存储库实施 HA CEP 服务器以更新 KJAR 服务。