Ambos parecem ser uma rede paralela de processos de comunicação MPI. Eu identifico atores com serviços. Os atores são mais dinâmicos (você pode criá-los e matar como a respiração, enquanto a rede de serviços é mais estática) ou o quê?
Respostas:
Modelo de ator - é um modelo matemático para cálculos simultâneos e microsserviços - uma implementação da arquitetura orientada a serviços. As semelhanças são bastante coincidentes.
Certamente é possível construir microsserviços com base em algum modelo de ator e modelar alguma arquitetura de microsserviço com o modelo de ator, mas isso não significa que eles sejam equivalentes. Substitua "sistema de microsserviço" por "sistema de email", e isso ainda será verdadeiro. Substitua "modelo de ator" por "Comunicando processos sequenciais" (CSP) e também será "verdadeiro", porque os sistemas de modelo de ator e de CSP podem ser modelados um pelo outro.
Dado o modelo de ator, você pode implementá-lo usando microsserviços, SOA ou até e-mail, mas isso não significa que eles estejam no mesmo nível de abstração para realmente comparar.
Além disso, o modelo de ator enfatiza os buffers (podem ser vistos como filas de mensagens no mundo dos microsserviços); portanto, alguns atores / microsserviços podem não estar prontos enquanto a comunicação inerentemente assíncrona ainda é possível.
Em outras palavras, a comparação com o modelo de ator pode trazer algumas idéias criativas com um nível muito alto de consideração, mas principalmente são maçãs versus laranjas.
Se o objetivo é comparar o modelo matemático de SOA / microsserviços ao modelo Actor, também não é trivial, porque: 1) não há um modelo matemático acordado para SOA; 2) o modelo geralmente inclui o objetivo. E a modelagem de SOA / microsserviços provavelmente será diferente da finalidade do modelo de ator. Um exemplo de tentativa de modelar SOA aqui .
Obviamente, é possível criar um sistema de modelo de ator com microsserviços e chamar cada serviço de ator (consulte a definição estrita do que é modelo de ator). Mas isso não significa que exista qualquer relação significativa entre os dois no sentido geral.
Os microsserviços são uma maneira de organizar o software dividindo cada área de preocupação em seu próprio artefato implementável (executável, script, JAR, WAR, etc.). Isso oferece flexibilidade, por exemplo, permitindo escalar implementando mais instâncias onde elas são necessárias. Digamos que os usuários passem mais tempo olhando seu catálogo do que adicionando itens a um carrinho de compras; um artefato implementável lida com funções de catálogo, outro lida com funções de carrinho de compras - você pode executar mais cópias dos serviços de catálogo para lidar com a carga.
Também os isola de mudanças internas. Digamos que você mude de um banco de dados relacional para um banco de dados de documentos para armazenar dados do produto - é provável que seus serviços de carrinho de compras não precisem ser alterados.
O modelo de ator é um nível inferior ao artefato implementável, mais sobre com que tipos de objetos você implementou o serviço. Continuando com o exemplo acima, você pode ter os carrinhos de compras em seu sistema representados por atores, portanto, o carrinho de cada usuário é um ator distinto, e as mensagens dizem para ele adicionar itens, remover itens, responder com o conteúdo atual, adicionar remessa, verificar , etc. Nesse caso, você ainda possui um microsserviço, que é implementado com o modelo de ator.
Eu diria que a principal diferença é a granularidade.
Para o modelo de ator, é relativamente refinado, pois um ator tende a representar o equivalente a um objeto no OOP.
Para microsserviços, é relativamente granular, pois um único microsserviço pode consistir em um grande número de atores ou objetos.
Observe que você realmente não precisaria exagerar muito sua imaginação para dizer que a web moderna é exatamente a mesma coisa com uma granularidade ainda maior ("macro-serviços"); e que (por exemplo) um servidor HTTP é um serviço de macro, um servidor de banco de dados é um serviço de macro, um navegador da web é um serviço de macro etc.
É praticamente o mesmo - peças isoladas que se comunicam. É apenas o tamanho das peças (e, portanto, o número de peças) que muda.
Os microsserviços são escalonados horizontalmente, criando várias réplicas, cada uma capaz de atender solicitações devido à natureza sem estado do serviço. Eles são resistentes ao fracasso em virtude de sua natureza apátrida.
Os atores são escalonados, movendo-os para partições com menos carga ou mais recursos disponíveis. Eles são stateful . Eles são resistentes ao fracasso porque - dependendo da estrutura do ator - outro ator pode ser ativado dinamicamente ou um backup quente do ator pode ser mantido o tempo todo para lidar com a falha do ator principal.
Novamente, os microsserviços também podem ter um estado, mas isso contraria os princípios de design dos microsserviços.