调整和扩展 ThingWorx Flow 引擎
ThingWorx Flow 引擎服务包含多个配置选项，它们可对 ThingWorx Flow 的性能及其工作流执行产生极大影响。这些选项可在引擎模块中的 deploymentConfig.json 文件内找到。如果对这些配置选项中的任何一个进行了更改，则需要使用操作系统的本机服务控制工具 (Windows 系统的“服务”或 sc；Red Hat 系统的 sysctl) 重新启动 ThingWorxFlow 服务。以下各部分将介绍每一种相关设置，并针对如何根据您的环境和系统资源对其进行配置提供建议。
执行吞吐量 (CHANNEL_MAX_FETCH)
• 类型 - 整数
• 默认值 - 10
• 单位 - 消息总数
用于控制引擎服务将处理的最大工作流执行消息数。每次执行工作流服务 (包括手动执行或通过触发器执行的独立工作流) 时，都会通过 ThingWorx Foundation 传输这些消息。降低此数字将限制引擎可同时执行的工作流数量。
开发环境应配置为与系统中的内核数相匹配。生产系统应配置为内核数的 50% 到 200% 之间，具体取决于同一台计算机上运行的其他服务数量。
工作器内存分配 (ENGINE_SIZE)
• 类型 - 整数
• 默认值 - 1802
• 单位 - 兆字节 (10242 字节)
这表示引擎工作器进程可为对象分配的最大内存量 (以兆字节为单位)。配置此值时，应考虑的因素包括：
• 工作流中的活动数
• 内联表达式或 Node.js 操作的复杂性
• 每个操作检索或处理的数据量
部署建议 - 建议在开发环境中将其保留为默认值。对于生产环境，针对 ENGINE_SIZE 配置的值应约等于系统 RAM 最大值除以 CHANNEL_MAX_FETCH 所使用设置值的商。
最大执行时间 (MAX_FLOW_RUN_TIME)
• 类型 - 整数
• 默认值 - 300000
• 单位 - 毫秒
控制每次运行允许工作流执行的总时间 (以毫秒为单位)。此设置将防止引擎工作器执行工作流时持续时间过长。此值将根据部署和网络环境的不同而有所不同。但是，建议始终为其提供一个较低的值，以防止工作器长时间不可用，因为这会导致工作流的整体性能下降。需要在以下两个方面之间进行适当的平衡：提供足够的时间，以允许工作流完成执行；以及保持足够低的值，以使引擎工作器尽快达到可用状态。
部署建议 - 对于开发环境，建议将其保留为默认值；但如需调试，则将其设置为较长的值。对于生产环境，建议将此值设置为在最长运行工作流的长度上另外增加 15%。
工作器恢复周期 (SLEEP_BETWEEN_FLOW_EXECUTION)
• 类型 - 整数
• 默认值 - 3000
• 单位 - 毫秒
在引擎工作器能够执行工作流之前，插入附加延迟 (以毫秒为单位)。这主要是为了让操作系统从已停止的引擎工作器中回收内存，从而提高不同工作流执行之间不需要共享内存空间的环境的安全性。
部署建议 - 对于开发环境和大多数生产环境，建议将该值设置为 0。对于包含不能混合的敏感信息的多用户环境，建议将其保留为默认值，或根据需要适当增加。不存在可以确保操作系统正确回收内存的值。
在执行工作流后停止引擎工作器 (KILL_WORKER_AFTER_RUN)
• 类型 - 布尔型
• 默认值 - false
每次执行工作流时，引擎服务都将创建一个工作器进程，用于处理实际执行的工作流 (值最高可达针对 CHANNEL_MAX_FETCH 设置的值)。默认情况下，工作器进程将保持活动状态，以便为其他执行请求提供服务。此设置会修改上述行为，这将使得在工作流执行完成后，工作器进程会终止。
部署建议 - 对于开发环境和大多数生产环境，建议将该值保留为其默认值。对于包含不能混合的敏感信息的多用户环境，建议将其设置为 true。
工作器可用性重试计数 (AVAILABLE_WORKER_CHECK_TRIES)
• 类型 - 整数
• 默认值 - 10
• 单位 - 重试次数
如果所有工作器进程正在使用中，但有一个工作流请求处于待处理状态，则引擎服务将继续重试工作器进程，直到达到所配置的次数。如果尝试的重试次数已达到最大值，则引擎将无法执行请求。
部署建议 - 对于开发环境，将此值保留为默认值已足够。对于生产环境，建议将此值设置为合理的值；与 AVAILABLE_WORKER_CHECK_INTERVAL 设置结合使用时，您不会希望总延迟大约超过总请求服务时间的一半。
工作器可用性重试延迟 (AVAILABLE_WORKER_CHECK_INTERVAL)
• 类型 - 整数
• 默认值 - 3000
• 单位 - 毫秒
用于确定在第一次尝试失败后，再次尝试工作流执行的工作器进程之前，引擎服务需等待的时间。
部署建议 - 对于开发环境，将此值保留为默认值已足够。对于生产环境，建议将此值设置为合理的值；与 AVAILABLE_WORKER_CHECK_TRIES 设置结合使用时，您不会希望总延迟大约超过总请求服务时间的一半。
工作器进程磁盘自动关闭延迟 (WORKER_DISMISS_INTERVAL)
• 类型 - 整数
• 默认值 - 1800
• 单位 - 秒
用于指定引擎服务在开始终止工作器进程之前，等待其他工作的时间。如果将 KILL_WORKER_AFTER_RUN 设置为 true，则此值没有任何意义。
部署建议 - 在本地部署环境中，通常将此值保持为默认值已足够。对于云部署或受内存约束的环境，可能需要降低此值，特别在仅偶尔使用此工作流的情况下更应如此。
引擎配置示例
示例引擎 deploymentConfig.json 文件如下所示：
{
"MAX_FLOW_RUN_TIME": 180000, // Only allows a workflow to run for up to 3 minutes.
"EXCHANGE_STATUS_CHECK_INTERVAL": 120000, // Checks if it can communicate with the Exchange service every 2 minutes.
"REFRESH_ON_INTERVAL_MINUTES": 60,
"ENGINE_PORT": 2006, // The port Engine will reserve for health check purposes
"ENGINE_HOST": "localhost", // The hostname Engine will reserve the port against
"SLEEP_BETWEEN_FLOW_EXECUTION": 3000, // Waits 3 seconds before a worker can execute the next workflow
"ENGINE_DATA_PATH": "C:/ThingWorxOrchestration/modules/cache", // Location where files are stored during workflow execution
"EXCHANGE": { // The host and port for the Exchange service that this Engine should communicate with
"HOST": "localhost",
"PORT": "7822"
},
"logLevel":"error", // valid levels are 'trace', 'debug', 'info', 'warn', and 'error'; default is 'error'
"QUEUE": {
"MAX_SOCKET": 100,
"QUEUE_CONSUMPTION_UNIT": {
"256": 1
},
"DEFAULT_FLOW_QUEUE": "256",
"ACTIVE_ADAPTER_DEFAULT": "amqp",
"ACTIVE_ADAPTER_FLOW": "amqp",
"ACTIVE_ADAPTER_STOP": "amqp",
"ACTIVE_ADAPTER_WEBHOOK": "amqp",
"ADAPTERS": {
"AMQP": {
"CONFIG": { // The host and port for the RabbitMQ server
"port": "5672",
"protocol": "amqp",
"host": "localhost",
"vhost": "orchestration",
"CHANNEL_MAX_FETCH": "5" // The maximum number of messages this Engine will fetch from the queue
},
"FLOW_QUEUE": {
"QUEUE_NAMES": {
"256m": "256mb"
},
"QUEUE_NAME": "256mb"
}
}
}
}
}