Estilo de arquitetura de microsserviçosMicroservices architecture style

Uma arquitetura de microsserviços consiste numa coleção de pequenos serviços autónomos.A microservices architecture consists of a collection of small, autonomous services. Cada serviço é autónomo e deve implementar uma única capacidade empresarial.Each service is self-contained and should implement a single business capability.

Diagrama lógico do estilo de arquitetura de microsserviços

Em vários aspetos, os microsserviços são a evolução natural das arquiteturas orientadas para serviço (SOA), mas existem diferenças entre os microsserviços e as SOA.In some ways, microservices are the natural evolution of service oriented architectures (SOA), but there are differences between microservices and SOA. Estas são algumas das características específicas de um microsserviço:Here are some defining characteristics of a microservice:

  • Numa arquitetura microsserviços, os serviços são pequenos, independentes e relativamente acoplados.In a microservices architecture, services are small, independent, and loosely coupled.

  • Cada serviço é um código base separado, que pode ser gerido por uma equipa de desenvolvimento pequena.Each service is a separate codebase, which can be managed by a small development team.

  • Os serviços podem ser implementados de forma independente.Services can be deployed independently. Uma equipa pode atualizar um serviço existente sem reconstruir e reimplementar toda a aplicação.A team can update an existing service without rebuilding and redeploying the entire application.

  • Os serviços são responsáveis pela persistência dos seus próprios dado ou estado externo.Services are responsible for persisting their own data or external state. Isto é diferente do modelo tradicional, em que uma camada de dados separada processa a persistência dos dados.This differs from the traditional model, where a separate data layer handles data persistence.

  • Os serviços comunicam entre si através de APIs bem definidas.Services communicate with each other by using well-defined APIs. Os detalhes internos da implementação de cada serviço estão ocultos de outros serviços.Internal implementation details of each service are hidden from other services.

  • Os serviços não precisam de partilhar a mesma pilha de tecnologia, bibliotecas ou estruturas.Services don't need to share the same technology stack, libraries, or frameworks.

Além dos próprios serviços, alguns outros componentes estão presentes numa arquitetura de microsserviços típica:Besides for the services themselves, some other components appear in a typical microservices architecture:

Gestão.Management. O componente de gestão é responsável por colocar os serviços em nós, identificando falhas, reequilibrando serviços em nós e assim sucessivamente.The management component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth.

Deteção de Serviço.Service Discovery. Mantém uma lista dos serviços e os nós em que estão localizados.Maintains a list of services and which nodes they are located on. Permite a pesquisa de serviço para localizar o ponto final de um serviço.Enables service lookup to find the endpoint for a service.

Gateway de API.API Gateway. O gateway da API é o ponto de entrada para os clientes.The API gateway is the entry point for clients. Os clientes não chamam os serviços diretamente.Clients don't call services directly. Em vez disso, podem chamar o gateway da API, que reencaminha a chamada para os serviços adequados no back-end.Instead, they call the API gateway, which forwards the call to the appropriate services on the back end. O gateway da API pode agregar as respostas de vários serviços e devolver a resposta agregada.The API gateway might aggregate the responses from several services and return the aggregated response.

As vantagens de utilizar um gateway de API incluem:The advantages of using an API gateway include:

  • Dissocia os clientes dos serviços.It decouples clients from services. Pode dar uma versão dos serviços e refatorizá-los, sem ser necessário atualizar todos os clientes.Services can be versioned or refactored without needing to update all of the clients.

  • Os serviços podem utilizar protocolos de mensagens que não são adequados para a Web, como o AMQP.Services can use messaging protocols that are not web friendly, such as AMQP.

  • O Gateway da API pode realizar outras funções transversais, como a autenticação, o registo, a terminação de SSL e o balanceamento de carga.The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.

Quando utilizar esta arquiteturaWhen to use this architecture

Considere este estilo de arquitetura para:Consider this architecture style for:

  • Aplicações grandes que requerem uma maior velocidade de lançamento.Large applications that require a high release velocity.

  • Aplicações complexas que têm de ser altamente dimensionáveis.Complex applications that need to be highly scalable.

  • Aplicações com domínios avançados ou muitos subdomínios.Applications with rich domains or many subdomains.

  • Uma organização que consiste de pequenas equipas de desenvolvimento.An organization that consists of small development teams.

BenefíciosBenefits

  • Implementações independentes.Independent deployments. Pode atualizar um serviço sem implementar novamente toda a aplicação e reverter ou efetuar o rollforward de uma atualização caso algo corra mal.You can update a service without redeploying the entire application, and roll back or roll forward an update if something goes wrong. As correções de erros e os lançamentos de funcionalidades são mais fáceis de gerir e menos arriscados.Bug fixes and feature releases are more manageable and less risky.

  • Desenvolvimento independente.Independent development. Uma única equipa de desenvolvimento pode criar, testar e implementar um serviço.A single development team can build, test, and deploy a service. O resultado é a inovação contínua e uma cadência mais rápida de lançamento.The result is continuous innovation and a faster release cadence.

  • Equipas pequenas e direcionadas.Small, focused teams. As equipas podem concentrar-se num serviço.Teams can focus on one service. O âmbito mais pequeno de cada serviço facilita a compreensão da base de código e a incrementação por novos membros da equipa.The smaller scope of each service makes the code base easier to understand, and it's easier for new team members to ramp up.

  • Isolamento de falhas.Fault isolation. Se um serviço ficar inativo, não irá remover a aplicação completa.If a service goes down, it won't take out the entire application. No entanto, isso não significa que obtém a resiliência gratuitamente.However, that doesn't mean you get resiliency for free. Terá na mesma de seguir as melhores práticas de resiliência e padrões de conceção.You still need to follow resiliency best practices and design patterns. Veja Estruturar aplicações resilientes para o Azure.See Designing resilient applications for Azure.

  • Pilhas de tecnologia mista.Mixed technology stacks. As equipas podem escolher a tecnologia que melhor se adequa ao seu serviço.Teams can pick the technology that best fits their service.

  • Dimensionamento granular.Granular scaling. Os serviços podem ser dimensionados de forma independente.Services can be scaled independently. Ao mesmo tempo, a densidade superior de serviços por VM significa que os recursos da VM são utilizados totalmente.At the same time, the higher density of services per VM means that VM resources are fully utilized. Ao utilizar as restrições de posicionamento, um serviço pode ser correspondido a um perfil de VM (CPU elevada, memória elevada, etc.).Using placement constraints, a services can be matched to a VM profile (high CPU, high memory, and so on).

DesafiosChallenges

  • Complexidade.Complexity. Uma aplicação de microsserviços tem mais partes em movimento do que a aplicação monolítica equivalente.A microservices application has more moving parts than the equivalent monolithic application. Cada serviço é mais simples, mas o sistema como um todo é mais complexo.Each service is simpler, but the entire system as a whole is more complex.

  • Desenvolvimento e teste.Development and test. A programação com dependências de serviço requer uma abordagem diferente.Developing against service dependencies requires a different approach. As ferramentas existentes não foram necessariamente concebidas para funcionar com as dependências do serviço.Existing tools are not necessarily designed to work with service dependencies. Refatorizar através de limites de serviço pode ser difícil.Refactoring across service boundaries can be difficult. Testar as dependências do serviço também é particularmente desafiante, especialmente quando a aplicação está a evoluir rapidamente.It is also challenging to test service dependencies, especially when the application is evolving quickly.

  • Falta de governação.Lack of governance. A abordagem descentralizada da criação de microsserviços tem vantagens, mas também pode provocar problemas.The decentralized approach to building microservices has advantages, but it can also lead to problems. Pode ficar com tantas linguagens e estruturas diferentes que se torna difícil gerir a aplicação.You may end up with so many different languages and frameworks that the application becomes hard to maintain. Poderá ser útil implementar alguns padrões em todo o projeto, sem restringir excessivamente a flexibilidade das equipas.It may be useful to put some project-wide standards in place, without overly restricting teams' flexibility. Isto aplica-se especialmente a funcionalidades transversais, como o registo.This especially applies to cross-cutting functionality such as logging.

  • Congestionamento e latência de rede.Network congestion and latency. A utilização de muitos serviços pequenos e granulares pode originar uma maior comunicação entre serviços.The use of many small, granular services can result in more interservice communication. Além disso, se a cadeia de dependências de serviços ficar muito longa (o serviço A chama o serviço B, que chama o C, etc.), a latência adicional pode tornar-se um problema.Also, if the chain of service dependencies gets too long (service A calls B, which calls C...), the additional latency can become a problem. Terá de estruturar as APIs cuidadosamente.You will need to design APIs carefully. Evite APIs excessivamente comunicativas, considere os formatos de serialização e procure locais para utilizar padrões de comunicação assíncrona.Avoid overly chatty APIs, think about serialization formats, and look for places to use asynchronous communication patterns.

  • Integridade dos dados.Data integrity. Com cada microsserviço responsável pela sua própria persistência de dados.With each microservice responsible for its own data persistence. Como resultado, a consistência dos dados pode ser um desafio.As a result, data consistency can be a challenge. Adote a consistência eventual sempre que possível.Embrace eventual consistency where possible.

  • Gestão.Management. O êxito dos microsserviços requer uma cultura DevOps madura.To be successful with microservices requires a mature DevOps culture. O registo correlacionado entre serviços pode ser um desafio.Correlated logging across services can be challenging. Normalmente, o registo tem de correlacionar várias chamadas de serviço para uma única operação de utilizador.Typically, logging must correlate multiple service calls for a single user operation.

  • Controlo de versões.Versioning. As atualizações de um serviço não podem interromper os serviços que dependem dele.Updates to a service must not break services that depend on it. Vários serviços poderiam ser atualizados num determinado momento pelo que, sem uma estrutura cuidadosa, poderia ter problemas de retrocompatibilidade ou compatibilidade com as versões seguintes.Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility.

  • Competências.Skillset. Os microsserviços são sistemas altamente distribuídos.Microservices are highly distributed systems. Avalie cuidadosamente se a equipa tem as competências e a experiência para o êxito.Carefully evaluate whether the team has the skills and experience to be successful.

Melhores práticasBest practices

  • Serviços de modelo em todo o domínio empresarial.Model services around the business domain.

  • Decentralize tudo.Decentralize everything. Equipas individuais são responsáveis pela conceção e criação de serviços.Individual teams are responsible for designing and building services. Evite a partilha de código ou esquemas de dados.Avoid sharing code or data schemas.

  • O armazenamento de dados deve ser privado para o serviço que detém os dados.Data storage should be private to the service that owns the data. Utilize o melhor armazenamento para cada serviço e tipo de dados.Use the best storage for each service and data type.

  • Os serviços comunicam através de APIs devidamente estruturadas.Services communicate through well-designed APIs. Evite a fuga de detalhes da implementação.Avoid leaking implementation details. As APIs deve modelar o domínio, não a implementação interna do serviço.APIs should model the domain, not the internal implementation of the service.

  • Evite o acoplamento entre serviços.Avoid coupling between services. As causas de acoplamento incluem esquemas de bases de dados partilhados e protocolos de comunicação rígidos.Causes of coupling include shared database schemas and rigid communication protocols.

  • Não descarregue as preocupações transversais, como a autenticação e a terminação SSL, para o gateway.Offload cross-cutting concerns, such as authentication and SSL termination, to the gateway.

  • Mantenha os conhecimentos do domínio fora do gateway.Keep domain knowledge out of the gateway. O gateway deve processar e encaminhar os pedidos de cliente sem qualquer conhecimento das regras de negócio ou lógica de domínio.The gateway should handle and route client requests without any knowledge of the business rules or domain logic. Caso contrário, o gateway torna-se uma dependência e pode provocar o acoplamento entre serviços.Otherwise, the gateway becomes a dependency and can cause coupling between services.

  • Os serviços devem ter um acoplamento alargado e uma coesão altamente funcional.Services should have loose coupling and high functional cohesion. As funções que se prevê serem alteradas em conjunto devem ser compactadas e implementadas em conjunto.Functions that are likely to change together should be packaged and deployed together. Se residirem em serviços separados, esses serviços acabam por ser estreitamente acoplados, porque uma alteração de um serviço irá necessitar de atualizar o outro serviço.If they reside in separate services, those services end up being tightly coupled, because a change in one service will require updating the other service. A comunicação excessivamente ativa entre dois serviços pode ser um sintoma de acoplamento estreito e baixa coesão.Overly chatty communication between two services may be a symptom of tight coupling and low cohesion.

  • Isole as falhas.Isolate failures. Utilize as estratégias de resiliência para impedir falhas em cascata dentro de um serviço.Use resiliency strategies to prevent failures within a service from cascading. Veja [Padrões de resiliência] resiliency-patterns e Estruturar aplicações resilientes.See Resiliency patterns and Designing resilient applications.

Passos SeguintesNext steps

Para obter documentação de orientação detalhada sobre como criar uma arquitetura de microsserviços no Azure, veja Estruturar, criar e utilizar microsserviços no Azure.For detailed guidance about building a microservices architecture on Azure, see Designing, building, and operating microservices on Azure.