我正在使用Mircosoft Orleans作为基础的工作流引擎,因为它提供了许多有用的功能,例如自动分配工作和处理故障转移。
我有三种类型的谷物:
我的问题是当运行大量当前执行时,即> 1000表现真的很糟糕。我做了一些分析,并将其缩小到谷物之间发生的沟通。无论如何我还能改进这个吗?
以下是我的代码概述以及颗粒如何相互作用
执行粒子处于循环中,从工作流中获取下一个工作块,然后在工作块上调用execute。谷物之间的这种不断调用导致我的一个测试工作流程的执行时间从运行单次执行的10秒变为运行超过1000的大约5分钟。这可以改进或者我应该重新构建解决方案去除谷物沟通?
[StorageProvider(ProviderName = "WorkflowStore")]
[Reentrant]
[StatelessWorker]
public class Workflow : Grain<WorkflowState>, IWorkflow
{
public Task<BlockRef> GetNext(Guid currentBlockId, string connectionName)
{
//Lookup the next work block
}
}
[Reentrant]
[StatelessWorker]
public class WorkBlock : Grain<WorkBlock State>, IWorkBlock
{
public Task<string> Execute(IExecution execution)
{
//Do some work
}
}
[StorageProvider(ProviderName = "ExecutionStore")]
public class Execution : Grain<ExecutionState>, IExecution, IRemindable
{
private async Task ExecuteNext(bool skipBreakpointCheck = false)
{
if (State.NextBlock == null)
{
await FindAndSetNext(null, null);
}
...
var outputConnection = await workblock.Execute();
if (!string.IsNullOrEmpty(outputConnection))
{
await FindAndSetNext(State.NextBlock.Id, outputConnection);
ExecuteNext().Ignore();
}
}
private async Task FindAndSetNext(Guid? currentId, string outputConnection)
{
var next = currentId.HasValue ? await _flow.GetNextBlock(currentId.Value, outputConnection) : await _flow.GetNextBlock();
...
}
}
答案 0 :(得分:5)
这里有几个问题:
1)Workflow是StatelessWorker并使用StorageProvider似乎不对。 StorageProvider意味着它具有过于关注的状态,StatelessWorker意味着它没有任何状态。而是使用常规的非StatelessWorker谷物。
2)让我们自上而下地看一下建模:工作流程只是关于工作流程和要执行的代码的数据,WorkBlock是多块工作流程的一个块(多步骤工作流程的一步),对吗?在这种情况下,它们都不应该是谷物。他们只是国家。执行是唯一需要粮食的。执行接收工作流,工作流在其数据内编码下一个块,执行只执行块。
3)从可扩展性的角度来看,你只需要大量的执行粒度。如果工作流具有id,则可以为每个Workflow id使用Execution grain。如果要并行多次执行相同的工作流程(具有相同的ID),现在它取决于。如果不是太平行,也许一个执行谷物就足够了。如果没有,您可以使用X执行粒度池(执行粒度的ID将是“WorkflowId-NumberBetween0AndX”)。
答案 1 :(得分:1)
在我看来,这些功能不应该是独立的谷物,聚合它们将消除昂贵的粒间通信。
如果您将工作区重命名为活动并将执行重命名为 WorkflowInstance ,您的概念会变得非常相似到微软的Workflow Foundation。我已经在GitHub(Orleans.Activities)上启动了一个项目,在奥尔良上运行WF4工作流程。虽然它不是生产就绪,但没有性能测试,但至少有效。也许你应该试一试。