Quando a Microsoft anunciou que o .NET seria aberto à comunidade em 2015, ela abriu várias bibliotecas, entre elas há o Microsoft Orleans, que é o tema deste artigo.
Este é o primeiro artigo sobre este framework, onde conheceremos a sua estrutura. No próximo artigo o utilizaremos em uma aplicação.
Curso C# (C Sharp) - Introdução ao ASP.NET Core
Conhecer o cursoO que é o Microsoft Orleans?
O Orleans é um framework que permite a criação de aplicações distribuídas e escalares de forma simples e direta. Sem a necessidade de aprender ou se preocupar com as complexidades de concorrência ou escalabilidade.
Atualmente na versão 2.0, este framework é utilizado por várias equipes da Microsoft, mas principalmente na área de games, onde foi utilizado para implementar os recursos de cloud de jogos como Halo 4 e 5 e Guild Wars 2.
O problema camada intermediária
Aplicações, ou serviços “cloud”, são inerentemente paralelas e distribuídas. Elas também são interativas e dinâmicas; frequentemente requerendo interação em tempo real com outras entidades.
Caso esses aplicativos tenham uma grande demanda, a sua cria criação pode ser bem complexa. Criar uma aplicação com este comportamento de forma otimizada, demanda um grande nível de conhecimento dos programadores e várias interações entre as equipes de design e arquitetura.
Atualmente, a criação de uma aplicação escalável é feita como uma composição de camadas “stateless”, onde a lógica de negócio é centrada em uma camada intermediária:
Por mais que seja possível escalar esta camada intermediária, será necessário se preocupar com o banco de dados. Pois a aplicação terá que manter os dados da camada intermediária sincronizados. Caso acesse muito o banco de dados para fazer isso, a performance do banco pode ser um gargalo para a aplicação.
Caso mantenha muitos dados na memória, durante uma atualização, os dados em algumas instâncias desta camada podem ficar defasados. Além de adicionar possíveis problemas de cache.
Orleans na camada intermediária
Orleans procura resolver os problemas que vimos acima com os seus atores virtuais. Ele permite, de maneira intuitiva, a criação de várias entidades de domínio – atores virtuais, que aparentam ser objetos .NET de várias aplicações distribuídas e insoladas dentro de um cluster (silo):
Essas entidades de domínio são chamadas pelo Orleans de grãos (grains) e trata-se de classes .NET simples, que implementam um ou mais interfaces da biblioteca, que as definem como uma classe “grão”.
Grãos individuais são instâncias de classes “grãos” definidas pela aplicação, que são criadas automaticamente pelo Orleans em tempo de execução, conforme as solicitações. Esses grãos podem ser qualquer tipo de entidade, como: pessoa, pedido, cliente, etc; só é requerido que ele tenha um código de identificação, que pode ser definido, como: um e-mail, um código ou uma identificação do banco. O Orleans garante que cada grão será executado em uma thread separada, que o protegerá de problemas de concorrência ou conflito.
No mundo dos microservices, Orleans é utilizado como uma estrutura para implementar um microservice que pode ser implementado e gerenciado por uma solução de microservice escolhida pelo desenvolvedor.
Grãos e silos
Um grão pode persistir seu estado na memória ou no banco ou em uma combinação de ambos. Dentro do silo – que é o nome dado para o servidor criado pelo Orleans ao executar a aplicação – um grão pode chamar qualquer outro grão ou pode ser chamado pelo cliente (frontend) utilizando apenas o seu identificador, sem a necessidade de criar ou instanciá-lo.
Não importando onde esteja salvo o estado do grão, o framework fará parecer que ele esteve o tempo todo em memória. Mas na realidade, caso um grão fique muito tempo inativo, ele é removido da memória e seu estado é salvo no banco.
Todo este ciclo é transparente para o código, o que libera o programador de se preocupar com esses detalhes.
Outra vantagem deste comportamento é que o Orleans consegue lidar com uma falha de forma automática. Ao notar que um nó falou, ele reinstala nos demais nós os dados presentes no nó que falhou.
Todos esses detalhes podem parecer complexos em um primeiro momento. No próximo artigo, quando codificaremos uma aplicação simples, eles ficarão mais claros.
Até lá.
