Arquitetura de Microserviços em .NET

BOX 1. Aplicação Monolítica

O termo original é Aplicação com Arquitetura Monolítica e segundo Martin Fowler é uma aplicação onde há uma forte dependência entre seus módulos ou camadas. Quando um desses módulos para de funcionar, para toda a aplicação.

Tais módulos são disponibilizados em uma mesma instância no Servidor de Aplicação, não dando margem ao uso de Clusters ou balanceadores de carga, o que significa que quando cresce a demanda por ele, causa um grande ônus à infraestrutura e ao desenvolvimento de uma forma geral.

A aplicação que trataremos neste artigo e que será decomposta tem sua estrutura mostrada na Figura 1.

Motivação para a mudança de Arquitetura

A principal motivação para ir de uma arquitetura monolítica para uma arquitetura de Microserviços é a descentralização do código e a quebra da dependência, pois o microserviço abarca o acesso aos dados e a regra de negócio em um só lugar como um bloco.

Também é possível desenvolver um melhor redimensionamento da equipe de desenvolvedores, uma vez que com o microserviço podemos dividir a equipe por funcionalidades ou por contexto, como na Figura 2.

Normalmente, de acordo com o Scrum, uma Equipe Ágil precisa ter entre seis a 10 membros, logo, se nosso time de desenvolvimento tiver 20 profissionais, podemos dividir a equipe em dois e com isso trabalhar em duas sprints com funcionalidades distintas para um mesmo produto, que ao final da iteração é entregue funcionando e testável através de suas interfaces gráficas, por exemplo.

Em geral, quando tratamos de uma refatoração deste tamanho ou uma nova implementação, é uma boa prática se criar inicialmente uma sprint apenas de Spikes, onde a equipe irá verificar as necessidades de negócio e como isso será portado para microserviços.

Dessa forma a entrega do produto poderá seguir uma linha uniforme e as lições aprendidas poderão apoiar tanto o Product Owner quanto o Time no momento em que forem quantificar um trabalho, ou o Product Owner priorizar este ou aquele Backlog de produto ou História de Usuário.

Aplicação Monolítica de Exemplo

Nossa aplicação de exemplo é dividida em camadas e a persistência é feita pelo Entity Framework 6 com Fluent API, com tipos genéricos e interfaces seguindo todos os princípios SOLID. Na Figura 3 temos a estrutura dessa aplicação.

Podemos notar nitidamente que as camadas aplicação têm forte dependência entre si. A ideia então é transformar essa aplicação de arquitetura monolítica em uma aplicação servida pela arquitetura de microserviços, e o resultado deve ficar como na Figura 4.

Diminuímos bastante a dependência entre as camadas. O que fizemos foi concentrar os Bounded Contexts de Contato e Autenticação em microserviços, ou seja, encapsulamos o acesso aos dados e expusemos as regras de negócio como serviços RESTFul através da WebAPI 2.2. Na Figura 5, demonstramos como é a estrutura de cada microserviço.

Separando as Regras de Negócio para conversão

O que precisamos expor em nosso microserviço é justamente a camada que fica exposta para uso da Camada de Apresentação, ou seja, a Camada de Regra de Negócios, pois está entre a camada mais baixa, de Acesso a Dados, e a camada mais alta, a fronteira do sistema com o usuário. Na Tabela 1 temos todos os métodos que vamos transportar para o microserviço.

Já separamos os métodos para expô-los via REST, agora vamos explicar o motivo da escolha da Arquitetura. Anteriormente nesse artigo, informamos o que utilizaremos no que tange a arquitetura, mas nas próximas seções vamos aprofundar o motivo dessa escolha.

Porque a Performance importa

Quando trabalhamos com a arquitetura de microserviços, precisamos criar um banco de dados para cada um, mesmo que seja necessária a duplicação das tabelas entre microserviços.

Microserviço não se conecta diretamente a outro microserviço, porém, é importante que haja uma certa integração, não no exemplo deste artigo, mas em outro caso como um microserviço de controle de estoque e um microserviço de checkout.

Existe a necessidade de as informações trafegarem entre esses dois microserviços e para fazer essa interligação utilizamos mensageria assíncrona, normalmente com o protocolo AMQP.

Porém, caso não precisemos integrar os microserviços com informações em tempo real, podemos utilizar o Quartz.NET para tarefas agendadas e atualizações durante períodos em que as requisições são menores, normalmente na parte da madrugada.

Essas abordagens ajudam muito no quesito performance, mas um outro detalhe é também utilizar programação paralela.

Na internet existem muitos artigos, em sua grande maioria, explicando como criar serviços através da programação paralela em .NET, porém, não é o escopo deste artigo, e deixamos o código fonte do artigo disponível para que o leitor faça o download e o refatore à vontade.

Outro quesito importante sobre performance é qual o framework de persistência que iremos utilizar e neste artigo vamos utilizar o ADO.NET, este framework é muito performático no que tange a acesso direto ao banco de dados, e nos microserviços a curva de refactoring é muito pequena, ou seja, não há a necessidade de se criar uma arquitetura muito grande para reuso, pois utilizamos as inserções, seleções e atualizações simples, sem algo muito complexo. O ADO.NET é nestes casos é uma excelente saída para a performance.

Web API 2.2

De acordo com a própria Microsoft, o protocolo HTTP não é apenas para operar páginas web. É também uma plataforma poderosa para construir APIs que exponham serviços e dados. HTTP é simples, flexível e único.

Quase todas as plataformas que existem têm uma biblioteca que manipule o HTTP, então serviços baseados em HTTP podem atingir uma maior gama de clientes, incluindo navegadores, celulares e as aplicações de desktop.

Diante disso, o ASP.NET Web API é um framework para construir APIs baseadas em Web com o .NET Framework. Do ponto de vista dos antigos Web Services ASMX e do WCF, a Web API se torna mais simples de ser manipulada, criamos um código fonte menor e conseguimos fazer muitas operações.

Como a Web API funciona não é o escopo deste artigo, para saber como que a Web API funciona, mas se o leitor tiver algum conhecimento de ASP.NET MVC, irá compreender os fundamentos da Web API.

Neste artigo não vamos utilizar os Models, pois de acordo com a Teoria da Arquitetura de Microserviços, faz-se necessária a passagem de objetos transitórios apenas para fazer o fluxo de entrada e saída, e com isso criaremos uma camada de DTOs (BOX 2) para que possamos receber e devolver os objetos.

Criando a Solução e Estrutura

Criaremos agora uma solução no Visual Studio com um projeto do tipo Class Library e no diretório que é criado com ela, devemos criar um novo diretório chamado Bin, que é onde colocaremos o assemblies após a compilação dos nossos projetos.

Para que o compilador coloque os assemblies em um diretório diferente dos Debug e Release habituais, devemos inserir instruções nos Build Events da Class Library em questão.

Após a criação de qualquer Class Library, devemos digitar o seguinte comando dentro do campo Build Events, com mostra a Figura 6: Copy “$(TargetPath)” “$SolutionDir)bin” /y.

Criando a Camada de DTOs

Vamos então criar a camada de DTO, que será disponibilizada aos clientes para facilitar a integração do sistema. Crie uma Class Library na solution com o nome de Dto no Namespace e Microservice.Dto no Assembly name. De acordo com os padrões de desenvolvimento, é uma boa prática criar uma classe em cada arquivo, na Listagem 1 está o código de todos os DTOs para fins didáticos.

Utilizamos Nullable nos Ids, como mostrado nas linhas 04, 16 e 36. Nullable é muito útil para assertivas em testes, pois tem a propriedade booleana HasValue e assim podemos montar um Assert(id.HasValue) que é muito mais limpo do que criar igualdades que possam realmente falhar, pois o teste nesse sentido é implementado para passar.

Vamos na próxima seção criar o serviço REST que irá interagir com o Dto e o Cliente.

Criando o Microserviço de Autenticação

Para criar nosso microserviço, precisamos criar um projeto ASP.NET MVC com um controller Web API. Neste Projeto precisamos instalar alguns pacotes via NuGet, e os pacotes selecionados são os da Figura 7.

Seus nomes são autoexplicativos e eles nos darão o suporte para que possamos utilizar a Web API sem quaisquer imprevistos.

Agora, criamos um controller Web API com o nome de AutenticacaoController e é aí que começamos a fazer com que o microserviço tome forma. Nos microserviços a conexão é feita diretamente no próprio método que é acessado via protocolo HTTP. Como foi dito anteriormente, estamos utilizando ADO.NET para efetuar as operações.

Criamos uma propriedade que recebe o valor da String de Conexão para que possamos utilizá-la em todos os métodos para a acesso ao banco de dados. Na Listagem 2 temos a criação dessa propriedade.

Devemos lembrar que o nome presente na linha 05 é o mesmo nome da string de conexão do arquivo app.config.

Vamos criar os métodos para persistência de nosso microserviço e vamos fazer um paralelo com o nosso sistema monolítico, começando pelo método de cadastro dos usuários, na Listagem 3.

Podemos notar que essa classe está ferindo já uma sugestão feita no padrão dos microserviços que solicita que cada microserviço deve ter no máximo 100 linhas de código. Porém, isso é uma recomendação, em sistemas mais complexos retiramos tal complexidade das camadas inferiores e os organizamos melhor em um microserviço. Mesmo assim conseguimos um melhor controle e melhor organização do projeto.

Na linha 01 utilizamos o attribute HttpPost pois não estamos utilizando prefixos que tenham o mesmo nome das ações do HTTP como Getxxx, Postxxx, Putxxx, Deletexxx.

Quando utilizamos quaisquer destes prefixos, automaticamente a Web API os identifica como tais ações do protocolo HTTP. O POST significa que vamos gravar os dados no destino onde essa requisição está sendo enviada, porém, não basta isso, pois também vamos precisar modificar a rota em seu lugar apropriado e será o que veremos mais adiante nesse artigo.

Na linha 02 passamos o attribute FromBody junto com o Dto como um parâmetro, isso significa que não passaremos um valor pela URL, mas sim dentro da requisição, ou seja, um dado encapsulado.

Mostraremos mais adiante essa abordagem quando efetuarmos testes com o microserviço.

Ainda na linha 02 utilizamos HttpResponseMessage, pois assim retornaremos os códigos numéricos de status do protocolo HTTP, que é o seu padrão, como retornar o código 200 para informar que a requisição foi executada com sucesso, 500 para erro interno do servidor ou 404 para não encontrado.

Porém, podemos utilizar os outros códigos caso precisemos, pois essa classe detém alguns códigos de saída padrão através de Enums, inclusive validação, se o cadastro do usuário foi feito com sucesso através do Enum Success, por exemplo.

Na linha 06 configuramos uma saída para que possamos ver o que está sendo feito dentro da Web API através do log na saída do Console. Para habilitar este rastreamento precisamos configurar na mesma classe responsável também pelo controle das rotas (veremos isso mais adiante no artigo).

Na linha 30 lançamos uma exceção personalizada para informar qual o erro que foi retornado. Diante disso, como o retorno é um valor numérico este será 500, porém, informará qual será o erro retornado e tipado com essa exceção personalizada.

O conteúdo dessa classe pode ser visto no código fonte deste artigo.

Na linha 37 informamos o Id que é retornado após o INSERT, isso pode ser útil caso precisemos devolver o DTO devidamente preenchido e com o novo Id retornado após a criação do usuário.

Na linha 45 criptografamos a senha utilizando métodos próprios, porém, criamos um Salt aleatório e o algoritmo de criptografia é o SHA3, que é o último algoritmo de criptografia seguro criado.

Para que possamos utilizá-lo, precisamos instalá-lo via NuGet, fazendo uma busca por SHA3 e instalar o pacote.

Na Listagem 4 mostramos como foi criado o método Autenticar, que é o que nos dará permissão para a entrada em qualquer sistema, pois faz o confronto da senha de texto puro com essa mesma senha transformada em hash.

Se a validação da senha retornar positivo, então o usuário teria o acesso ao sistema e o retorno desta é um DTO que retorna o código do usuário e outras informações que o cliente pode utilizar para gravar em sessão ou persistir de outra maneira.

Na linha 1 temos um attribute ResponseType(typeof(AutenticacaoDto)) que informa à Web API que o objeto retornado ao executar esse método é um objeto AutenticacaoDTO.

A resposta para o cliente será esse objeto convertido em JSON e com os valores preenchidos, pois essa é a saída padrão da Web API, mas se quisermos utilizar outra saída como XML ou outro parser personalizado, a Web API também o permite.

A linha 02 mostra como qual o tipo de método HTTP a Web API irá tratar essa action. Utilizamos o GET pois precisamos consultar e retornar os valores e o HttpGet equivale à uma consulta retornando apenas um objeto ou uma lista deles.

Na linha 03 passamos os parâmetros de forma distinta da Listagem 3, pois utilizamos o attribute FromUri, o que significa que podemos passar esses parâmetros pela URL sem a necessidade de preencher algum objeto para envio.

Na linha 13 utilizamos um outro método dentro de nosso próprio microserviço para que possamos confrontar os valores recebidos.

Se a validação da linha 16 retornar positivo, então o objeto preenchido com alguns dados do usuário é retornado para tratamento.

Na Listagem 5 vemos a criação do método para a troca de senha.

Como podemos ver, o uso do ADO.NET aumentou o número de linhas de código, mas manteve o acesso a dados bastante coeso e em um ponto único.

Também pode ser feita uma refatoração como forma de melhorar e diminuir a extensão do código, mas isso deixamos como desafio ao leitor.

Na Listagem 6 temos o último método deste contexto, o que faz a busca de um usuário por seu Login.

Agora podemos configurar as rotas para que nosso serviço funcione corretamente. Se quisermos publicá-lo em nosso IIS, Microsoft Azure ou Microsoft Katana, ele irá publicar sem qualquer problema, mas no momento em que fizermos o teste de consumo, receberemos sempre o erro 404, dando a entender que o método não foi encontrado.

Diante disso, precisamos configurar uma nova rota. A forma é muito similar ao ASP.NET MVC, porém é uma outra classe, pois estamos na Web API, que se chama WebApiConfig em App_Start. A Listagem 7 nos mostra o conteúdo dessa classe.

Nas linhas 06 até 10 temos a configuração do Logger para a console que vimos no início dos métodos do microserviço de autenticação.

Na linha 21 temos uma nova configuração de rota padrão. Esta nova configuração faz com que a nossa Uri fique da seguinte forma: http://dominio.com.br/api/autenticacao/BuscarUsuarioPorLogin?id=1, pois a variável não será confundida com a variável Id da action BuscarUusarioPorLogin.

Criando o Microserviço para Controle de Contatos

Vamos então criar os microserviços de contatos, o mesmo é muito similar ao microserviço de autenticação, tanto nos pacotes instalados quanto na sua sintaxe, diferindo-se apenas por ter de adicionar o método HTTP DELETE quando vamos excluir um contato.

O procedimento de criação do mesmo é idêntico ao de autenticação, apenas criamos um controller com o nome de ContatoController. Na Listagem 8 criamos o método ou action para cadastro de usuários utilizando o método HTTP POST, pois estamos fazendo o envio e gravação no destino.

Na linha 85 utilizamos o ExecuteScalar do ADO.NET para que possamos receber o id gravado.

Nas linhas 91 e 97 informamos através dos códigos de retorno HTTP se a gravação foi executada com sucesso (código 200), se lançou alguma exceção (código 500) ou se foi feito alguma coisa errada e erramos o nome do action (código 404).

Na Listagem 9 mostramos como criar a action AlterarContato, na qual utilizaremos o método HTTP PUT, pois estamos fazendo uma modificação no destino.

Essa action ficou bem extensa devido à quantidade de validações que são necessárias para que não haja nenhum problema no momento da gravação do contato.

Na Listagem 10 criamos a action para apagar um contato. Como vamos fazer uma exclusão, vamos utilizar o método HTTP DELETE.

Até o momento já vimos a maioria dos métodos utilizados nessa listagem, portanto não são necessários comentários adicionais nesse ponto. Na Listagem 11 temos uma consulta para listar contatos pelo IdUuario.

Para concluir esse conjunto de funcionalidades principais do nosso microserviços de contatos, na Listagem 12 temos uma action que faz a busca de um contato por seu Id.

Arquiteturas baseadas em microserviços estão se tornando uma realidade e a tendência que passemos a encontrá-las com mais frequência. A própria Microsoft ao criar o ASP.NET vNext e o Projeto Katana estão transformando o ASP.NET de uma arquitetura monolítica para algo mais leve e bastante funcional.

Relacionado

Microserviços estão revolucionando cada vez mais a forma com vemos nossas aplicações, fazendo com que estas possam ser portadas, adicionadas a uma Web Farm com alta disponibilidade, clusters e outras partes de infraestrutura que outrora se mostravam impraticáveis pela forma estática como eram distribuídas as camadas e como suas dependências eram geridas dentro da aplicação.

Arquitetura de Microserviços em .NET – Parte 2

Nesta segunda parte da série o leitor terá a oportunidade de conhecer os processos de publicação dos microserviços, seja no IIS ou via Microsoft Katana, uma implementação da Microsoft para o padrão OWIN.

Poderá criar uma API e posteriormente seu Gateway, que será a camada intermediária entre o microserviço e o cliente.

Com o OWIN, o leitor terá um deploy rápido preparando suas aplicações para Integração e Entrega Contínuas.

Ao fim desse processo, o leitor terá uma aplicação com arquitetura mais flexível e escalável, diferente da arquitetura monolítica da qual partimos no início desta série.

Na primeira parte desta série vimos como escalar e dividir uma aplicação monolítica, mesmo com todas as suas limitações, para uma Arquitetura de Microserviços.

Selecionamos os métodos mais importantes e que poderíamos, inclusive, disponibilizar para que terceiros utilizem em seus sistemas, tal como uma antiga camada de autenticação que foi melhorada e convertida em microserviço.

Agora, veremos como consumir tais serviços, mas para que isso seja possível precisamos hospedar nossa aplicação.

Nessa segunda e última parte da série vamos hospedar nossos microserviços no IIS (Internet Information Service) e efetuar os spikes (BOX 1) de consumo dos microserviços rumo à criação de nossa Gateway API, que irá funcionar como um catálogo dos microserviços criados e centralizar o acesso pelo cliente.

Entendemos “cliente” como qualquer aplicação que fará uso do microserviço, ou seja, é a camada que faz a fronteira entre a aplicação e o usuário.

Publicando no IIS

A publicação no IIS requer um grau de complexidade baixo, uma vez que um projeto Web API é um projeto ASP.NET MVC, porém focado em métodos HTTP. Vamos criar um domínio fictício em nosso sistema operacional para que possamos utilizar um nome distinto de Localhost.

Abra o arquivo hosts do seu sistema operacional (localizado em C:\WINDOWS\System32\drivers\etc) e adicione a seguinte linha:

Em [Seu IP] deve ser colocado o IP da sua máquina e não o endereço de loopback que normalmente é 127.0.0.1 em IPv4 e ::1: em IPv6. Feito isso, para verificar se nossos endereços estão respondendo como devem, precisamos executar um ping no endereço e obter um resultado como o que é apresentado na Figura 1.

Por questões de didática, a criação das demais classes não será apresentada neste artigo, mas o código fonte completo encontra-se para download junto com esse artigo no site da DevMedia.

Vamos abrir a nossa solução dos microserviços, como mostra a Figura 2.

Devemos então clicar com a direita sobre o projeto Microservice.Autenticacao e em seguida clicar em Publish. Na tela que se abre, criamos o profile chamado Microservico, como vemos na Figura 3.

Clicamos em Next ou em Connection e marcamos o Publish Method como File System e informamos o caminho. Vemos na Figura 4 como ficou a nossa configuração.

Não é necessário que se copie a mesma localização, pode ser qualquer uma escolhida pelo leitor. Neste artigo, colocamos na raiz da solution em um diretório de nome Publish.

Nas configurações de publicação, devemos selecionar as opções mostradas na Figura 5.

Agora podemos clicar em Publish e, caso tudo dê certo, o diretório informado na configuração deve estar como mostra a Figura 6.

Já temos o nosso diretório publicado, agora vamos efetuar a configuração do IIS. Ao abrir o Console de Configuração do IIS, vamos criar um novo Web Site, como pode ser visto na Figura 7.

Na tela de configuração, colocamos o nome no site de autenticacao, selecionamos o mesmo endereço IP e o nome de host do arquivo de configuração descrito anteriormente. Na Figura 8 vemos essa configuração.

Feito isso, nosso microserviço de autenticação já está hospedado no IIS. Vamos configurar então o Pool de aplicativos, pois sem essa configuração não vamos conseguir fazer o acesso necessário ao site configurado. A Figura 9 mostra como deve ser configurado e o nome de nosso Pool de aplicativo.

Após configurar o pool, devemos ir nas configurações avançadas de nosso site criado e selecionar o pool de aplicativos criado.

Configuração de permissão do Pool no SQL Server

Pode ocorrer um problema quando acessamos alguma action do microserviço, podemos receber um erro de falta de permissão para a conexão com o nosso banco de dados para o pool configurado, nesse caso, o pool Microservico.

Para evitar esse problema, precisamos configurar o acesso ao usuário do IIS que tem o mesmo nome do pool de aplicativo com o prefixo, IIS APPPOOLMicroservico, dentro dos bancos de dados dos nossos microserviços.

Normalmente, utilizamos o Microsoft SQL Server Management Studio, mas podemos utilizar qualquer console que acesse a base de dados do SQL Server (neste artigo foi utilizada a versão Express).

Para tal, selecionamos o nosso banco de dados do microserviço de autenticação, clicamos em Segurança e em seguida criamos o usuário do IIS e lhe aplicamos as permissões necessárias, como mostra a Figura 10.

Testando o Microserviço no navegador

Para efetuar o primeiro teste, vamos utilizar o browser e utilizar o método BuscarUsuarioPorLogin e em seguida vamos utilizar o Fiddler para todos os outros testes. Vamos acessar a seguinte URL no navegador e devemos obter o resultado mostrado na Listagem 1:

Testando o microserviço com Fiddler

O Fiddler é a ferramenta que utilizaremos para outros testes mais profundos, pois vão existir métodos em que precisamos enviar um objeto complexo populado para a aplicação e fazer isso diretamente do browser é difícil de se fazer.

Para tal, é necessário efetuar o download do Fiddler no site indicado na seção Links deste artigo. Em seguida, com o Fiddler instalado, efetuaremos o mesmo teste que efetuamos no navegador.

Montamos esse teste no Fiddler através de sua ferramenta chamada Composer, na qual selecionamos o método HTTP que enviaremos a requisição e também podemos enviar um objeto completo populado, caso seja essa a necessidade do método.

A action BuscarUsuarioPorLogin utiliza um método GET por se tratar de uma consulta para recuperação de informações, essa action retorna um DTO, mas com a Web API ele retorna um objeto JSON que é serializado e quando efetuamos o consumo desse microserviço, o desserializamos novamente para o DTO.

Isso faz da Web API seja uma solução bem robusta para tráfego de informações e excelente para uma arquitetura para microserviços, facilitando inclusive a integração entre microserviços utilizando um protocolo de mensageria, normalmente o AMQP.

Como já tem a experiência nativa de transmitir objetos através do corpo da mensagem, sua solução é facilmente acoplada ao protocolo AMQP.

Na Figura 11 temos o teste do action pelo Fiddler.

Observamos pelo Fiddler que recebemos um erro 500 que informa um erro interno no servidor. Tal erro é ocasionado pela falta de permissão de nosso pool de aplicativo ao SQL Server, como foi explicado anteriormente.

Para identificar o motivo do erro, clicamos sobre o resultado e depois clicamos em Raw e recebemos a seguinte mensagem:

Note que é a mesma informação comentada anteriormente sobre a criação de um usuário com permissão no SQL Server e esse usuário deve ter o mesmo nome do pool. Para resolver esse problema, basta seguirmos o que já foi explicado, porém para o usuário IIS APPPOOL\Microservicos.

Após essa configuração, já podemos repetir o teste no Fiddler e ver o sucesso da consulta, como mostra na Figura 12.

O Fiddler é capaz de identificar o formato de retorno, que nesse caso é JSON e pode ser visto na Listagem 2.

Nosso microserviço já está hospedado e funcional, doravante, vamos criar os testes unitários para que possamos consumir esses microserviços para certificar de seu correto funcionamento antes de desenvolver o Gateway de nossa API, que disponibilizaremos para consumo por parte do cliente.

A partir do procedimento que realizamos, o leitor pode realizar a hospedagem do microserviço para controle dos contatos.

Criando os Testes unitários para Autenticação

Para os nossos testes unitários, vamos utilizar o MS Test Framework que vem com o próprio Visual Studio, apenas para fins didáticos, mas isso não impede o uso de qualquer outro framework de testes. Também não utilizaremos nenhum framework para Mock. Cada método criará a instância do objeto e a tratará localmente.

Para o teste do microserviço de autenticação utilizaremos o projeto Teste.Microservice.Autenticacao. Além de adicionarmos como referência o assembly do projeto Microservice.Dto.

A partir do Nuget devemos então instalar os pacotes ilustrados na Figura 13.

Crie então uma classe de testes chamada WebApiTeste e criamos um atributo como uma constante onde guardaremos o endpoint da API, conforme o código a seguir:

Ainda na classe de teste criada, adicionaremos em cada método de teste o sufixo necessário para interação com o microserviço de autenticação.

Vamos então testar a primeira action, que valida o cadastro de usuário. Na Listagem 3 temos o código do método de teste, que é autoexplicativo.

Neste exemplo de consumo enviamos uma mensagem contendo um objeto complexo no corpo, que é a forma mais segura, pois de outra forma o conteúdo fica exposto a ataques externos.

Na linha 30 informamos ao microserviço que estamos enviando uma requisição via método POST e adicionamos ao endpoint o conteúdo do DTO, que será serializado na mensagem e enviado ao microserviço e processado.

Terminado o cadastro do usuário, vamos validar se sua senha é válida autenticando o mesmo, o que significa consumir a action AutenticarUsuario.

O correto para essa action é passar um DTO para encapsular o nome de usuário e a senha como forma de segurança, e isso ficará como um desafio ao leitor, agora que sabe como passar um objeto complexo para o microserviço.

Aqui enviaremos as informações pela URL, por se tratar de um método GET, mesmo não sendo a forma mais segura.

Na Listagem 4 temos a estrutura do nosso teste de consumo para autenticar o usuário cadastrado.

Na linha 18 enviamos a informação através de um método GET e a URL junto com o endpoint. Com o novo usuário autenticado, pode ser que haja a necessidade da troca de senha, então na Listagem 5, temos a implementação do método de teste de consumo da action TrocarSenha.

Já nessa action utilizamos as boas práticas e enviamos a informação via POST no corpo da mensagem através de um DTO, por se tratar de uma ação de persistência.

Na linha 27 enviamos o conteúdo da mensagem via POST, uma vez que essa action resulta em um método inserção no banco de dados.

Terminando nosso microserviço de autenticação, temos uma busca de usuário que pode auxiliar em outras ações dentro de um sistema. Como no nosso modelo de dados informamos que o Login e o E-mail são únicos, fazemos a busca pelo Login.

Na Listagem 6 temos o teste de consumo da action BuscarUsuarioPorLogin. Essa action também tem um funcionamento que devemos ressaltar: a mesma está retornando junto com o DTO a senha criptografada, isso é uma falha grave de segurança e a melhoria dessa action fica como mais um desafio ao leitor.

Agora que criamos os testes, vamos executá-los e verificar seus resultados. Caso todo o processo tenha corrido como esperado, devemos ter todos os métodos executados com sucesso, como vemos na Figura 14.

Nosso microserviço de autenticação está pronto para ser acoplado à nossa API. Podemos agora criar o nosso Gateway da API.

Criando as chamadas da API

Criaremos duas Camadas em nossa API, Autenticação e Contato, segregadas por Interfaces que vão funcionar como uma Camada de Proxy ou Serviço para encapsular as actions dos microserviços e forçar a passagem do DTO ao mesmo. O conceito de microserviço reza que precisamos de um DTO para passar e receber os valores entre o cliente e o microserviço.

Primeiramente vamos criar a Camada de Serviços para o microserviço de autenticação, e é nesse momento em que transformaremos os testes como base para criarmos nossos métodos de serviço.

É muito importante organizar o nosso código em responsabilidades e com isso, nos projetos de Serviço de Autenticação e Contato vamos utilizar interfaces que serão separadas das implementações com diretórios. Também criamos exceções separadas para cada serviço,

Também existe uma outra abordagem onde podemos unir todos os microserviços em apenas uma Camada de Serviço. No caso de uma aplicação interna, não tem problema algum, mas se ela for utilizada por muitos clientes, isso pode se tornar muito oneroso, porém o tipo de projeto é que irá nos informar qual a melhor abordagem.

Para esse artigo utilizaremos as Camadas de Serviço e colocaremos encapsuladas no Gateway de APIs, que nada mais é do que uma camada de proxy dessas duas primeiras.

Inicialmente, vamos criar a Camada de Serviço para encapsular o microserviço de autenticação.

Camada de Serviços para Autenticação

Utilizaremos a camada de DTO do projeto, Microservicos.Dto, como responsável pelos objetos de troca de informações.

Existe alguma codificação nessas camadas que se repetem, então, vamos utilizar essa camada em específico para mostrar e na camada de serviços de contatos mostraremos apenas o que é pertinente para evitar duplicação de conteúdo.

Também devemos instalar os pacotes presentes na Figura 13 para que não tenhamos quaisquer problemas com dependências, com exceção do pacote SHA3, que não é necessário neste ponto.

Começaremos pela exceção personalizada. Essa classe nada mais é do que uma extensão da Classe System.Extension. Crie uma pasta no projeto chamada Excecao e nela adicione uma nova classe com o nome de AutenticacaoServicoException, cujo código é apresentado na Listagem 7.

Após criar o tratamento para os erros, vamos criar a interface que nos permitirá segregar o código e forçar o cliente e utilizar o que for disponibilizado. Crie mais uma pasta com o nome de Interfaces e nela adicione uma nova interface chamada IAutenticacaoServico, adicionando a ela o código presente na Listagem 8.

Nessa listagem já podemos notar que a forma de implementação é bem diferente do que fora visto até então. Estamos utilizando os DTOs para passagem de todos os valores aos microserviços, retornado Boolean para as operações de persistência e retornando um DTO para as buscas.

Agora, vamos implementar as interfaces. Crie agora a pasta Implementacao e adiciona uma classe chamada AutenticacaoServico, com o código da Listagem 9.

Essa classe foi criada com base no que fizemos nos testes unitários, dali identificamos os trechos de códigos que se repetiam e a partir disso criamos propriedades que visam facilitar o desenvolvimento.

Na linha 6 criamos um atributo que pega do arquivo de configuração o endpoint. Na linha 7 criamos um atributo que será acessado via propriedade de mesmo nome na qual já deixamos o objeto pronto com a configuração do objeto de saída, que é o JSON e com o endpoint configurado, isso já economiza algumas linhas de código repetitivas.

Na linha 23 temos a propriedade que acessa tal atributo. Na linha 8 configuramos o formato da mensagem que é o JSON.

Já vimos a estrutura da classe, agora veremos como essa estrutura é utilizada nos métodos subsequentes. Os métodos a seguir foram baseados nos testes que executamos anteriormente. Na Listagem 10 temos o método CadastrarUsuario com sua implementação bem enxuta.

Com os atributos criados podemos economizar muito em linhas de código, essa listagem e as que virão a seguir comprovarão isso. Na Listagem 11 temos o método TrocarSenha.

Nossos métodos carregam apenas o método HTTP correspondente, serializam ou desserializam os objetos e os retornam.

Na Listagem 12 temos o método AutenticarUsuario recebendo um DTO. Apesar de internamente estarmos enviando as informações via GET diretamente na URL, para o cliente externo isso não será visível, pois ele estará passando um DTO para o método de autenticação.

Por fim, na Listagem 13 temos o método de BuscarUsuarioPorLogin, fechando o serviço de autenticação.

Na linha 10 fazemos uma serialização entre o objeto JSON e o DTO correspondente para retornar o resultado ao cliente.

Camada de Serviços para Controle de Contatos

O microserviço de controle de contatos é o que reúne todas as formas de trabalho da Web API com o protocolo HTTP, pois tem um CRUD completo que nos permitirá utilizar os métodos HTTP POST, GET, PUT e DELETE, relacionando-os com as operações de Create, Read, Update e Delete, respectivamente.

O projeto deste serviço é o MicroserviceContato.Servico e nele devemos criar a mesma estrutura das pastas do projeto anterior (Interfaces, Excecao e Implementacao).

Teremos aqui as classes e interface responsáveis por expor o serviço de contatos para o cliente.

Adicione a interface IContatoServico na pasta Interfaces e deixe seu código igual ao da Listagem 14 onde temos as assinaturas dos métodos que permitirão a interação com as funcionalidades de CRUD dos contatos.

Após ter criado a interface, adicione na pasta Implementacao a classe ContatoServico que deve implementar a interface IContatoServico, assim como foi feito no serviço de autenticação.

A seguir veremos a implementação de alguns métodos dessa classe, porém outros serão omitidos para fins de simplificação deste artigo, mas podem ser implementados seguindo a mesma lógica da classe AutenticacaoServico.

Na Listagem 15 temos o método AlterarContato, que utiliza o método PUT e serve para alterar dados no servidor, por isso utilizamos o método PutAssync do objeto HttpClient.

Em seguida temos o método ApagarContato, que como o nome sugere faz exclusão de um contato e por isso utiliza o método HTTP GET. Na Listagem 16 vemos a implementação desse método, que na linha 4 usa o DeleteAssync do HttpClient e retorna um booleano indicando o sucesso da operação.

O outro método que merece destaque é o ListaContatosDoUsuario, que deve retornar uma lista de objetos a partir do método GET equivalente na API. O código desse método é apresentado na Listagem 17.

Caso haja alguma dúvida com relação a esses métodos, basta verificar no código fonte disponibilizado com este artigo, pois foram criados testes unitários específicos para essas camadas de serviço.

Em seguida, vamos mostrar como criar um Gateway e unir essas camadas de serviço em apenas uma API.

Criando o Gateway da API

De acordo com a Arquitetura de Microserviços, uma Gateway API é o ponto de junção de todos os endpoints, agindo como uma camada intermediária entre o microserviço e o cliente.

Esse conceito é muito abrangente, muitos projetos englobam uma infraestrutura como DMZ – Zona Desmilitarizada, balanços de carga, DNSs reversos, etc.

Aqui em nosso artigo, nosso gateway servirá para receber a camada de serviços e dispor de uma implementação com injeção de dependências feita de forma manual.

Não utilizaremos nenhum framework para tal, porém, é possível utilizar sem a necessidade de instâncias.

Com as interfaces criadas nas camadas de serviço, o cliente pode utilizar uma fachada que podemos disponibilizar, se possível, para deixar nossa estrutura de microserviços a mais personalizada possível e de acordo com as necessidades de nossos clientes.

O projeto de nosso Gateway se chama Microservice.GatewayApi, nele temos as abordagens informadas anteriormente, porém, vamos utilizar a mais simples e didática.

As outras abordagens deixaremos para que o leitor analise, porém é necessária cautela, pois as outras abordagens desfazem a necessidade de utilizar uma camada de serviços para acessar diretamente o gateway e então gerarmos toda a programação existente na camada de serviços, só que em apenas um local.

A abordagem que utilizaremos é apenas centralizar o uso das camadas de serviço.

Deixamos a cargo do Gateway a correta configuração do endpoint e com isso não há qualquer necessidade dessa configuração via código. Então, o que precisamos é apenas expôr os serviços através da instânciação do Gateway e para isso fizemos de duas formas: instanciação direta, classe GatewayApiProxy, ou instância via injeção de dependências, classe Gateway

Para fins de comparação, mostraremos as duas classes e em seguida mostraremos um teste unitário mostrando cada implementação.

As interfaces também nos permitem apontar assinaturas das propriedades e é apenas isso que implementamos na em GatewayApiProxy.

Na Listagem 18 temos a implementação da classe GatewayApiProxy.

Nesta classe vamos precisar criar a injeção de dependências diretamente no cliente. Isso não é um problema, porém em alguns projetos pode ser que gere um trabalho a mais e mais algumas linhas de código.

Caso prefira, o leitor pode criar a injeção de dependências diretamente na classe, deixamos isso a cargo deste.

Vamos criar então um novo projeto de testes unitários para o Gateway, nomeando-o como TesteGatewayApi. Na Listagem 19 temos um trecho da classe de testes que deve ser adicionada nesse projeto, destacando o método que testará a autenticação do usuário.

Quando executarmos o teste, o mesmo passará sem problemas. Porém podemos também precisar em algum projeto de apenas utilizar o Gateway sem instanciá-lo, para esse propósito criamos a classe <GatewayApiInstancia, na qual temos métodos estáticos, como vemos na Listagem 20.

Como podemos ver, essa é uma “implementação limpa”, ou seja, basta adicionar como referência e então utilizar o Gateway sem qualquer impedimento.

Criamos testes unitários que comprovam o funcionamento desta classe. Não há a necessidade de criação de propriedades para injeção de dependências, como podemos ver na Listagem 21.

Como podemos notar, não precisamos fazer ou criar nada, apenas utilizar os métodos estáticos necessários, como mostrado na linha 16.

Já temos o nosso Gateway API criado, ou seja, já temos a última fronteira. Para utilizá-lo, basta fazer como nos testes unitários, abrir o controller e substituir o método de negócio pelo método do Gateway API.

Utilizaremos agora o OWIN através do Projeto Katana da Microsoft, que é uma implementação do OWIN pela Microsoft e que substitui o IIS por uma implementação direta e sem a necessidade de utilizar todas as bibliotecas padrão, utilizando apenas o suficiente para manter a aplicação no ar e com o mínimo de dependências.

Implementando o Microserviço com Katana

É sabido e notado que o ASP.NET é muito pesado, lento e completamente dependente de seus assemblies entre si. Tanto é verdade que quando “subimos” uma aplicação web, seja ela com MVC ou Web API, há uma grande demora no deploy, dado esse peso de assemblies e dependências.

Com o advento da computação em nuvem, foi necessário deixar tal modelo monolítico de lado e criar algum esforço que apenas utilizasse, como módulos, o que fosse necessário e o mínimo possível para manter a aplicação funcionando sem onerar os recursos e a disponibilidade de uma aplicação web.

Pensando nisso, foi criado o padrão aberto OWIN, que significa Open Web Interface for .NET, que foi inspirado em uma comunidade de outra linguagem de programação, o Ruby on Rails. Não vamos nos aprofundar muito na parte teórica do assunto, pois foge do escopo deste artigo, então vamos apenas criar um novo projeto.

Esse novo projeto irá hospedar o endpoint de nossa web api contendo os nossos microserviços localmente, porém não precisaremos alterar nada, a não ser o endpoint no arquivo de configuração no Gateway API.

O projeto que criaremos, chamado Microservicos.Owin e que é uma aplicação Console cuja estrutura final é mostrada na Figura 15, é uma mostra de como uma aplicação web pode funcionar com um novo padrão mais dinâmico e mais leve, sem a necessidade de todos os assemblies que não utilizamos e que sempre causam lentidão no deploy.

Como podemos notar, o projeto é de console, mas existe uma estrutura bem semelhante à de uma aplicação MVC, sem os models e as views.

Precisamos criar essa estrutura e baixar os pacotes necessários para que possamos transformar uma aplicação console em uma aplicação ASP.NET MVC Web API e isso é feito pela classe Inicializacao, criada no diretório de infraestrutura, que garantirá que tudo isso funcione e seja montado dentro do método Main em Program.cs

Aqui também precisamos instalar alguns pacotes pertinentes, principalmente os pacotes do OWIN para a implementação do Web API, como mostra a Figura 16.

O pacote Microsot.AspNet.WebApi.Owin nos permite, através do método UseWebApi(), e com um mínimo esforço, criar uma aplicação auto hospedada, ou seja, sem a necessidade de utilização de um servidor web externo.

Uma aplicação auto hospedada contém uma codificação para receber requisições HTTP, como se agisse como um servidor web embarcado, o que permite que possamos utilizar a Web API em uma aplicação sem a dependência de System.Web.

O pacote Microsoft.AspNet.WebApi.OwinSelfHost instala algumas referências novas em nosso projeto, dentre eles os pacotes Microsoft.Owin.Hosting e Microsoft.Owin.Host.HttpListener. Com essas duas bibliotecas, nossa aplicação pode funcionar como seu próprio host e receber requisições HTTP sobre uma porta específica que configuramos em nossa aplicação.

Então basta executar o projeto, que por ser um console gerará um executável e com ele nossa aplicação estará no ar sem a necessidade do IIS.

Tivemos de criar a mesma estrutura existente nos projetos Web API mostrados na primeira parte deste artigo, porém, ao invés de criarmos dois projetos criamos um projeto só com todos os métodos.

Copiamos e colamos os conteúdos dos controllers dos microserviços da primeira parte, quanto a isso, não há a necessidade de reproduzir os códigos pois são os mesmos, mas mostraremos toda a infraestrutura por trás desse projeto e destacaremos duas classes importantes: Inicializacao e Program, esta última onde está localizado o método Main.

A classe Inicializacao, como o nome já diz, é responsável pela configuração das rotas. Na Listagem 22 temos o conteúdo dessa classe, que é bem pequeno comparado ao que teríamos que fazer.

Com podemos ver, tudo o que estamos fazendo é configurar a nossa rota padrão aqui, muito parecido ao que nós fazemos no projeto original que é criado pelo Visual Studio quando selecionamos o projeto Web API.

Porém ao invés de adicionarmos rotas específicas para a coleção de rotas no ASP.NET, estamos passando HttpConfiguration como um argumento ao método aplicacao.UseWebApi(microservicoStack), que podemos ver na linha 08.

Para finalizar nosso microserviço auto hospedado, tudo o que vamos precisar é configurar tudo o que fizemos na Listagem 22 dentro do método Main() para iniciar a funcionalidade de servidor permitida por HttpListener. Vemos essa implementação e configuração final na Listagem 23.

Agora, basta rodar o projeto e veremos uma aplicação de console como mostrado na Figura 17.

Caso queiramos utilizá-lo, basta modificar o enpoint no Gateway ou acessar via Fiddler que temos o mesmo comportamento que outrora, a diferença é que o tempo de resposta será muito menor se comparado ao hospedado via Web API real.

E com isso temos o nosso Projeto de Microserviços com consumo e testes unitários completo. Mas a arquitetura não para por aí, muitos itens podem ser adicionados a esse projeto.

Microserviços é uma arquitetura que não é nova, mas que agora está tendo um grande destaque por causa da arquitetura em nuvem e, com isso, quebrar camadas de acesso a dados e regras de negócio em microserviços tem se tornado muito comum, de forma que em um futuro próximo, só deveremos encontrar uma arquitetura monolítica apenas em projetos onde essa arquitetura seja realmente muito necessária.

Podemos melhorar nossos microserviços adicionando autenticação a eles através de OData ou OAuth 2, como fazem Facebook, Twitter, e outros serviços conhecidos. Podemos acoplar ainda o Log4Net em nossos microserviços e gravar os logs no banco de dados para depois minerar os dados para identificar erros de estrutura ou outros.

Outra possibilidade seria refazer a engenharia e acoplar nossas necessidades em nossos microserviços, pensando também em utilizar o NoSQL como alternativa para bases de dados que não necessitem de padrão relacional, como o nosso microserviço de autenticação, e quem sabe criar um microserviço para gerenciar as exceções e gravá-las em um Cassandra, CouchBase ou MongoDB.

Rapidamente surgem muitas ideias para evoluir nossos microserviços criados, e o principal conceito dessa arquitetura é justamente esse: arquitetura evolutiva e sem os problemas de engessamento de projeto que uma arquitetura monolítica dispõe.

Confira também