Quando e como você deve usar uma arquitetura de microsserviços

o arquitetura de microserviços tem recebido muita atenção ultimamente, E isso não é por acaso. Existem algumas grandes empresas como Netflix e Amazon que explicaram como estão a usar um arquitetura de microserviços para poder escalar os seus serviços e garantir que conseguem fornecê-los de forma contínua e sem interrupções.

Uma arquitetura de microserviços faz mais sentido em comparação com o design de aplicações monolíticas.

No design arquitetónico monolítico, criamos uma aplicação enorme e pesada com todos os módulos estreitamente acoplados dentro de um único executável que, de forma geral, se implementa num servidor web ou de aplicações. Apesar disto, este design arquitetónico tem algumas desvantagens que permitiram que o uso do arquitetura de microserviços se tornasse popular:

• Não há atualizações fáceis e frequentes.

• Problemas de distribuição contínua.

• Difícil de gerir equipa e projeto.

• Desempenho e escalabilidade dispendiosos.

• Falta de diversidade tecnológica.

• Não é fácil substituir os componentes.

O que é uma arquitetura de microserviços?

Um estilo de arquitetura de microserviços consegue uma configuração onde os componentes da aplicação são aplicações independentes. Estes componentes independentes da aplicação comunicam-se entre si através de RMI (Invocação de método remoto), Serviços Web Restful ou Push Messaging.

Ao conceber sistemas numa arquitetura de microserviços, devemos identificar os componentes independentes. Estes componentes serão miniaplicações, que serão desenvolvidas de forma separada. Seguirão o seu próprio ciclo de desenvolvimento e implementação.

Numa configuração geral podemos ter cenários em que precisamos de dados de vários componentes para um único pedido. Idealmente, teremos um gateway de API ou um controlador frontal que agregue os dados desses componentes e os devolva.

Além disso, devemos ter comunicação entre os componentes. Os componentes podem comunicar-se através de API REST, mensagens ou RMI (invocação de método remoto).

As características de uma aplicação baseada em arquitetura de microserviços são as seguintes:

• Serviço habilitado, execução independente de componentes.

• Execução independente de componentes em torno de algumas capacidades de negócio.

• Mentalidade de produto em vez de projeto.

• Componentes inteligentes que utilizam canais de comunicação simples, como o protocolo RESTish simples ou a fila de mensagens leve.

• Normas descentralizadas. Cada componente independente pode usar a sua própria norma exclusiva para desenvolvimento e implementação.

• Gestão descentralizada de dados. Cada componente individual tem o seu próprio armazenamento de dados.

• Gestão automatizada da infraestrutura. Para a implementação de componentes independentes, devemos confiar na gestão automatizada da infraestrutura para reduzir a complexidade.

• Desenho da aplicação com falhas em mente. Existem várias partes móveis independentes nas aplicações. Caso o recetor não obtenha resposta, deve ser gerido corretamente.

• Desenho evolutivo para obter o melhor sistema de decomposição viável, que pode ser substituído e atualizado sem afetar o seu ambiente.

Quando utilizar uma arquitectura de microserviços

Devemos usar uma arquitectura de microserviços para qualquer produto ou projecto com estas duas abordagens:

• Só monolítico ou com uma primeira abordagem monolítica. Regularmente, quando uma aplicação monolítica tem sucesso ou precisa de ajuda para escalar e melhorar o desempenho, podemos optar por uma arquitectura de microserviços de duas formas:
• Expanda os componentes modulares bem concebidos da aplicação monolítica.
• Crie a aplicação de microserviços a partir do zero e transfira a aplicação monolítica existente para ela.
• Uma primeira abordagem de microserviços. Debemos decantarse por el primer enfoque de microservicios cuando:
• La modularidad y la descentralización son un aspeto importante desde el inicio de cualquier proyecto.
• Anticipamos que la aplicación tendrá un gran volumen de transaciones o tráfico.
• Tenemos preferencia por los beneficios a largo plazo sobre los a corto plazo.
• Contamos com o conjunto de personas adecuado para diseñar, desarrollar e poner en práctica aplicaciones rápidamente, especialmente durante la etapa inicial.
• Estamos comprometidos com el uso de herramientas y tecnologías de vanguardia.

Cómo utilizar una arquitetura de microservicios

Infelizmente, La mayor parte de la información disponible sobre la arquitetura de microservicios explica por qué deben usarse, pero no cómo.. Es bueno saber que los microservicios podrían revolucionar el diseño, la implementación y el funcionamiento de las aplicaciones. Mas, ¿cómo se construye exatamente un único microservicio? Debe comprender los componentes fundamentales de un microservicio si desea que la salida funcione corretamente y no termine luciendo como la misma aplicación monolítica con una nueva capa de pintura.

Estes são os Cinco ítems que necesitará un microservicio antes de que pueda usarse en una arquitetura de aplicación distribuida:

1. Funcionalidad con alcance adecuado. El primer elemento de un microservicio es establecer qué debe hacer. Una forma de establecer el alcance adecuado es dividir los servicios en función de la funcionalidad lógica. Outra abordagem de alcance é refletir a estrutura da organização de desenvolvimento. Uma terceira abordagem é minimizar um serviço à quantidade de código que a equipa poderia reintroduzir num período de duas semanas.
2. Prepara uma API. Uma vez que dividimos uma aplicação em múltiplos serviços cooperativos, como é que esses serviços devem comunicar entre si? Regularmente, isso é feito com chamadas à API do serviço web REST, ainda que também possam ser utilizados outros mecanismos de transporte. Uma boa ideia é evitar saltar para a codificação da API de imediato. Em vez de, é melhor trabalhar em papel ou no quadro para estabelecer o que um serviço específico deve expor para funcionar corretamente.
3. A gestão do tráfego. Do ponto de vista do serviço de chamadas, deve sempre acompanhar as suas chamadas e estar pronto para terminar se a solução demorar demasiado. Do ponto de vista do serviço chamado, o design da API deve incluir a capacidade de enviar uma resposta a indicar sobrecarga. Os serviços, além disso, devem ser capazes de gerar e eliminar novas instâncias de serviço conforme necessário para se adaptarem às variações na carga de tráfego.
4. Download de dados. Ter a necessidade de um funcionamento contínuo é muito diferente do que as aplicações tradicionais precisam, que muitas vezes deixam de funcionar se a infraestrutura subjacente falhar. Para garantir que os utilizadores possam continuar a trabalhar quando uma instância falha, os dados específicos do utilizador podem ser migrados fora das instâncias de serviço para um sistema de armazenamento redundante partilhado acessível a todas as instâncias de serviço. Outra abordagem para descarregar o armazenamento é inserir um recurso de cache partilhado baseado em memória entre um serviço específico e o armazenamento associado a esse serviço.
5. Vigilância. O sistema de monitorização de uma aplicação baseada numa arquitetura de microserviços deve permitir a alteração contínua de recursos, poder capturar dados de monitorização numa localização central e apresentar informações que reflitam a natureza em constante mudança das aplicações de microserviços.