Por que os fluxos são transmitidos Orleans?

Já existe uma ampla gama de tecnologias para a criação de sistemas de processamento de fluxo. Eles incluem sistemas para armazenar dados de fluxo de maneira durável (por exemplo, Hubs de Eventos e Kafka) e sistemas para expressar operações de computação em dados de fluxo (por exemplo, Stream Analytics do Azure, Apache Storm e Apache Spark Streaming). Esses são ótimos sistemas que permitem criar pipelines eficientes de processamento de fluxo de dados.

Limitações de sistemas existentes

No entanto, esses sistemas não são adequados para computação de forma livre refinada em dados de fluxo. Os sistemas de computação de streaming mencionados acima de tudo permitem que você especifique um grafo unificado de fluxo de dados de operações aplicadas da mesma forma a todos os itens de fluxo. Esse é um modelo poderoso quando os dados são uniformes e você deseja expressar o mesmo conjunto de operações de transformação, filtragem ou agregação sobre esses dados. Mas outros casos de uso exigem a expressão de operações fundamentalmente diferentes em itens de dados diferentes. Em alguns desses casos, como parte do processamento, talvez você precise fazer uma chamada externa, como invocar uma API REST arbitrária. Os mecanismos de processamento de fluxo de dados unificado não dão suporte a esses cenários, dão suporte de forma limitada e restrita, ou são ineficientes ao dar suporte. Isso ocorre porque eles são inerentemente otimizados para um grande volume de itens semelhantes e geralmente são limitados em termos de expressividade e processamento. Orleans Os fluxos são direcionados a esses outros cenários.

Motivação

Tudo começou com solicitações dos Orleans usuários para dar suporte ao retorno de uma sequência de itens de uma chamada de método granular. Como você pode imaginar, que era apenas a ponta do iceberg; eles precisavam de muito mais.

Um cenário típico para Orleans o Streams é quando você tem fluxos por usuário e deseja executar um processamento diferente para cada usuário dentro do contexto desse usuário individual. Você pode ter milhões de usuários, mas alguns estão interessados em clima e assinam alertas meteorológicos para um local específico, enquanto outros estão interessados em eventos esportivos; outra pessoa pode estar acompanhando o status de um voo específico. O processamento desses eventos requer uma lógica diferente, mas você não deseja executar duas instâncias independentes de processamento de fluxo. Alguns usuários podem estar interessados apenas em um estoque específico e somente se uma determinada condição externa se aplicar — uma condição que pode não necessariamente fazer parte dos dados de fluxo (e, portanto, precisa de verificação dinamicamente no runtime como parte do processamento).

Os usuários alteram seus interesses o tempo todo, de modo que suas assinaturas para fluxos de eventos específicos venham e vão dinamicamente. Assim, a topologia de streaming muda dinamicamente e rapidamente. Além disso, a lógica de processamento por usuário evolui e muda dinamicamente com base no estado do usuário e em eventos externos. Eventos externos podem modificar a lógica de processamento para um determinado usuário. Por exemplo, em um sistema de detecção de fraude de jogos, quando um novo método de trapaça é descoberto, a lógica de processamento precisa ser atualizada com a nova regra para detectar essa violação. Isso deve ser feito, é claro, sem interromper o pipeline de processamento em andamento. Os mecanismos de processamento de fluxo de dados em massa não foram projetados para dar suporte a esses cenários.

É quase desnecessário dizer que esse sistema deve ser executado em vários computadores conectados à rede, não apenas em um único nó. Portanto, a lógica de processamento deve ser distribuída de forma escalonável e elástica em um cluster de servidores.

Novos requisitos

Quatro requisitos básicos foram identificados para um sistema de Processamento de Fluxo para direcionar os cenários acima:

1. Lógica de processamento de fluxo flexível
2. Suporte para topologias altamente dinâmicas
3. Granularidade de fluxo refinado
4. Distribuição

Lógica de processamento de fluxo flexível

O sistema deve dar suporte a diferentes maneiras de expressar a lógica de processamento de fluxo. Os sistemas existentes mencionados acima exigem que os desenvolvedores escrevam um grafo de computação declarativo de fluxo de dados, geralmente seguindo um estilo de programação funcional. Isso limita a expressividade e a flexibilidade da lógica de processamento. Orleans os fluxos são indiferentes à forma como a lógica de processamento é expressa. Ele pode ser expresso como um fluxo de dados (por exemplo, usando extensões reativas (Rx) no .NET), um programa funcional, uma consulta declarativa ou uma lógica imperativa geral. A lógica pode ser com estado ou sem estado, pode ou não ter efeitos colaterais e pode disparar ações externas. Toda a energia vai para o desenvolvedor.

Suporte para topologias dinâmicas

O sistema deve permitir topologias em evolução dinâmica. Os sistemas existentes mencionados acima geralmente são limitados a topologias estáticas corrigidas no momento da implantação que não podem evoluir em runtime. No exemplo a seguir de uma expressão de fluxo de dados, tudo é agradável e simples até que você precise alterá-la:

Stream.GroupBy(x=> x.key).Extract(x=>x.field).Select(x=>x+2).AverageWindow(x, 5sec).Where(x=>x > 0.8) *

Altere a condição de limiar no filtro Where, adicione uma instrução Select ou adicione outra ramificação no grafo de dados de fluxo e produza um novo fluxo de saída. Em sistemas existentes, isso não é possível sem derrubar toda a topologia e reiniciar o fluxo de dados do zero. Na prática, esses sistemas verificam a computação existente e podem ser reiniciados do ponto de verificação mais recente. Ainda assim, essa reinicialização é disruptiva e dispendiosa para um serviço online que produz resultados em tempo real. Essa reinicialização torna-se especialmente impraticável ao lidar com um grande número dessas expressões executadas com parâmetros semelhantes, mas diferentes (por usuário, por dispositivo, etc.) que mudam continuamente.

O sistema deve permitir a evolução do grafo de processamento de fluxo em runtime adicionando novos links ou nós ao grafo de computação ou alterando a lógica de processamento dentro dos nós de computação.

Granularidade de fluxo refinado

Em sistemas existentes, a menor unidade de abstração geralmente é todo o fluxo (topologia). No entanto, muitos cenários-alvo exigem que um nó/link individual na topologia seja uma entidade lógica por si só. Dessa forma, cada entidade pode potencialmente ser gerenciada de forma independente. Por exemplo, em uma topologia de fluxo grande que compreende vários links, links diferentes podem ter características diferentes e ser implementados em diferentes transportes físicos. Alguns links podem passar por soquetes TCP, enquanto outros usam filas confiáveis. Links diferentes podem ter garantias de entrega diferentes. Diferentes nós podem ter diferentes estratégias de ponto de verificação, e sua lógica de processamento pode ser expressa em diferentes modelos ou até mesmo em línguas diferentes. Essa flexibilidade geralmente não é possível em sistemas existentes.

A unidade de abstração e do argumento de flexibilidade é semelhante à comparação entre SOA (Arquiteturas Orientadas a Serviços) e Atores. Os sistemas de atores permitem mais flexibilidade, uma vez que cada ator é essencialmente um "pequeno serviço" gerenciado de forma independente. Da mesma forma, o sistema de fluxo deve permitir esse controle refinado.

Distribuição

E, claro, o sistema deve ter todas as propriedades de um "bom sistema distribuído". Isso inclui:

1. Escalabilidade: dá suporte a um grande número de fluxos e elementos de computação.
2. Elasticidade: permite que a adição/remoção de recursos cresça/diminua com base na carga.
3. Confiabilidade: resiliente a falhas.
4. Eficiência: usa recursos subjacentes com eficiência.
5. Capacidade de resposta: habilita cenários quase em tempo real.

Esses eram os requisitos para desenvolver Orleans Streaming.

Esclarecimento: Orleans atualmente não dá suporte diretamente à gravação de expressões declarativas de fluxo de dados, como no exemplo acima. As APIs de Streaming atuais Orleans são mais blocos de construção de baixo nível, conforme descrito nas Orleans APIs de streaming.

Consulte também

Orleans APIs de Programação de Fluxos