微软新奥尔良谷物通信性能

Question

我正在开发一个工作流引擎，使用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();
        ...
    }
}

Answer 1

这里有几个问题：

1)工作流是一个StatelessWorker并使用StorageProvider似乎是不对的。StorageProvider意味着它已经声明它太关心持久化，StatelessWorker表示它没有任何状态。相反，使用常规的非StatelessWorker谷物。

2)自上而下的建模:工作流只是关于工作流的数据和要执行的代码，WorkBlock是多块工作流的一个块(多步工作流的一个步骤)，对吗？在这种情况下，它们都不应该是谷物。他们只是国家。执行是唯一需要谷物的。Execution接收Workflow，Workflow在其数据中编码下一个块，而执行只执行该块。

3)从可伸缩性的角度来看，您只需要大量的执行粒度。如果一个工作流有一个id，那么您可以对每个工作流id使用一个执行粒度。如果您希望并行执行相同的工作流(具有相同的id)多次，则现在取决于此。如果没有太多的并行，也许一种执行谷物就足够了。如果不是，您可以使用X执行谷物池(执行粒度的id为“WorkflowId-NumberBetween0AndX”)。

Answer 2

在我看来，这些功能不应该是独立的谷物，聚集它们将消除昂贵的谷物间通信。

如果您将Workflow重命名为Activity为WorkflowInstance，则您的概念将非常--非常类似于微软的工作流基础。我在GitHub (Orleans.Activities)上启动了一个项目，在新奥尔良运行WF4工作流。虽然它还没有准备好生产，没有性能测试，但至少可以工作。也许你应该试试。