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