我们应用程序的一部分用作“规则引擎”。可以根据两个因素配置规则：进程状态和时间。规则可以简单也可以复杂。每条规则都有一个状态 - True 或 False
一个典型的规则如下所示：
时间 9:00 到 11:00 之间的时间和进程 1 状态打开。
And
时间在 4:00 到 6:00 之间，Process-2 状态为关闭。
所以，这条规则需要在 9:00、11:00、4:00 和 6:00，当 process-1 状态改变，或者 process-2 的状态改变时检查和评估。在评估规则状态是否更改（从之前的状态）之后，我们会引发一个事件。存储新结果，以便下次评估此规则时，可以比较其结果。如果新结果与前一个结果相同，则不会发生任何事情。
我们在应用程序中使用了 3 个不同的组件来实现这一点：
1) Web UI - 创建规则、更改流程状态等。每当流程状态或规则配置发生更改时，它都会引发事件。
2）调度程序 - 这是一个工作角色（窗口服务），每分钟运行一次作业，它检查是否存在开始时间或结束时间是当前时间的任何规则，如果找到，它将向队列提出事件。
3) 规则引擎 - 这个引擎是工作角色（窗口服务），它监听 3 种事件：规则定义更改事件、流程状态更改事件和时间事件。如果发生任何流程状态更改或时间规则事件，它会找出所有以此为条件的规则，触发这些规则并进一步引发事件作为“规则状态更改”。
该解决方案基于 Window Azure 云平台构建。以下是更多设计决策：
1）规则的定义存储在sql server中。如前所述，规则本质上可以是分层的（复杂的）并且由多个条件组成。
2）由于从数据库中按时间或Process1提取规则可能是一项耗时的操作，我们从sql数据库中一次性获取所有这些数据并存储在Redis缓存中。制作密钥以便我们可以通过时间或进程 ID 找到我们的所有规则。此操作在规则引擎启动时完成。所有进程的状态也存储在数据库和缓存中。
3) Azure 服务总线用于将消息从一个组件传递到另一个组件。
4) 每当从 Web UI 更改任何主数据时，都会在队列上传递一个事件，并且规则引擎会更新缓存。
系统的设计考虑了自动缩放。如果工作量增加，队列深度会增加，我们可以向规则引擎添加更多实例。
如果您发现上述设计有任何改进，请提出建议。
以下是我们在高可用性和组件故障方面面临的问题：
使用了多个 azure 服务，它们都可能在不同的时间失败（即使使用了多个实例）：
1) Web UI（Web 角色）99.95 可用性 - 目前这不是问题。
2）调度程序（工人角色）99.95可用性
3) 规则引擎（工人角色）99.95 可用性
4) Azure 服务总线 99.9 可用性
5) Redis Cache 99.9 可用性（数据无 SLA）
假设一切正常，突然出现以下任何一种情况：
问题 1：用户从 UI 更改规则的定义，系统将此数据添加到 sql 数据库，但服务总线没有响应。我们无法将此更改传达给规则引擎，因此系统将不同步。- 一种解决方案可能是回滚数据库操作并告诉用户一段时间后重试。- 另一种选择可能是进行两阶段提交。如果服务总线没有响应，请在数据库中维护一个标志。运行一个后台进程，该进程在队列可用时将此更改推送到队列。
问题 2：用户正在更改任何进程的状态，系统将其添加到 sql 数据库，但服务总线没有响应。此流程状态更改无法与规则引擎通信。规则引擎将不同步。- 与上一个相同。
问题 3：调度程序引擎出现故障：未引发时间事件，因此规则引擎将无法处理这些事件。- 我们可以记录调度程序运行作业的时间。无论何时调度程序，它都应该首先引发所有错过的事件，然后开始执行新的事件。
问题 4：处理来自规则引擎的消息时，缓存出现故障。规则引擎无法处理队列中的消息。这应该没问题，因为我们不会丢失任何消息。但万一缓存回来，它也可能会丢失所有缓存数据。规则引擎将不得不重建缓存（就像在规则引擎启动时所做的那样）。
谢谢你的时间。如果您能添加任何建议，我将不胜感激。