Compilar microsserviços no AzureBuilding microservices on Azure

Microsserviços são um estilo popular de arquitetura para compilar aplicativos resilientes, altamente escalonáveis, implantáveis independentemente e capazes de evoluir rapidamente.Microservices are a popular architectural style for building applications that are resilient, highly scalable, independently deployable, and able to evolve quickly. Mas, uma arquitetura de microsserviços bem-sucedida exige uma abordagem diferente ao projeto e à compilação de aplicativos.But a successful microservices architecture requires a different approach to designing and building applications.

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

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

O que são microsserviços?What are microservices?

  • Os microsserviços são pequenos, independentes e fracamente acoplados.Microservices are small, independent, and loosely coupled. Uma única equipe pequena de desenvolvedores pode escrever e manter um serviço.A single small team of developers can write and maintain a service.

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

  • Os serviços podem ser implantados de maneira independente.Services can be deployed independently. Uma equipe pode atualizar um serviço existente sem recompilar e reimplantar o aplicativo inteiro.A team can update an existing service without rebuilding and redeploying the entire application.

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

  • Os serviços comunicam-se entre si por meio de APIs bem definidas.Services communicate with each other by using well-defined APIs. Detalhes da implementação interna de cada serviço ficam ocultos de outros serviços.Internal implementation details of each service are hidden from other services.

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

Além para os próprios serviços, alguns outros componentes aparecem em uma arquitetura de microsserviços típica:Besides for the services themselves, some other components appear in a typical microservices architecture:

Gerenciamento/orquestração.Management/orchestration. Esse componente é responsável por colocar serviços em nós, identificar falhas, rebalancear serviços entre nós e assim por diante.This component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth. Normalmente, esse componente é uma tecnologia pronta para uso, como Kubernetes, em vez de algo criado de maneira personalizada.Typically this component is an off-the-shelf technology such as Kubernetes, rather than something custom built.

Gateway de API.API Gateway. O gateway de API é o ponto de entrada para os clientes.The API gateway is the entry point for clients. Em vez de chamar serviços diretamente, os clientes chamam o gateway de API, que encaminha a chamada para os serviços adequados no back-end.Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end.

As vantagens de usar um gateway de API incluem:Advantages of using an API gateway include:

  • Desacoplar os clientes dos serviços.It decouples clients from services. Os serviços podem ter controle de versão ou ser refatorado sem necessidade de atualizar todos os clientes.Services can be versioned or refactored without needing to update all of the clients.

  • Os serviços podem usar protocolos de mensagens que não sejam amigáveis à Web, como AMQP.Services can use messaging protocols that are not web friendly, such as AMQP.

  • O Gateway de API pode executar outras funções abrangentes, como autenticação, registro em log, terminação SSL e balanceamento de carga.The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.

BenefíciosBenefits

  • Agilidade.Agility. Já que os microsserviços são implantados de forma independente, é mais fácil gerenciar correções de bugs e lançamentos de recursos.Because microservices are deployed independently, it's easier to manage bug fixes and feature releases. Você poderá atualizar um serviço sem reimplantar o aplicativo inteiro e, em seguida, reverter uma atualização se algo der errado.You can update a service without redeploying the entire application, and roll back an update if something goes wrong. Em muitos aplicativos tradicionais, quando um bug é encontrado em uma parte do aplicativo, ele pode bloquear todo o processo de lançamento.In many traditional applications, if a bug is found in one part of the application, it can block the entire release process. Novos recursos poderão ser mantidos em espera até uma correção de bug ser integrada, testada e publicada.New features may be held up waiting for a bug fix to be integrated, tested, and published.

  • Equipes pequenas e focadas.Small, focused teams. Um microsserviço deve ser pequeno o suficiente para que possa ser criado, testado e implantado por uma única equipe de recurso.A microservice should be small enough that a single feature team can build, test, and deploy it. Tamanhos pequenos de equipe promovem maior agilidade.Small team sizes promote greater agility. Grandes equipes costumam ser menos produtivas, porque a comunicação é mais lenta, a sobrecarga de gerenciamento aumenta e a agilidade diminui.Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.

  • Base de código pequena.Small code base. Em um aplicativo monolítico, há uma tendência de que, ao longo do tempo, certas dependências de código fiquem entrelaçadas; Adicionar um novo recurso requer a alteração do código em vários lugares.In a monolithic application, there is a tendency over time for code dependencies to become tangled Adding a new feature requires touching code in a lot of places. Não compartilhando código nem armazenamentos de dados, uma arquitetura de microsserviços minimiza as dependências, o que torna mais fácil adicionar novos recursos.By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features.

  • Combinação de tecnologias.Mix of technologies. Equipes podem escolher a tecnologia mais adequada para seu serviço, usando uma combinação de pilhas de tecnologia conforme apropriado.Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.

  • Isolamento de falha.Fault isolation. Se um microsserviço individual se tornar não disponível, ele não interromperá o aplicativo inteiro, desde determinados microsserviços upstream sejam projetados para lidar com falhas corretamente (por exemplo, implementando a interrupção do circuito).If an individual microservice becomes unavailable, it won't disrupt the entire application, as long as any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).

  • Escalabilidade.Scalability. Os serviços podem ser dimensionados independentemente, permitindo que você escale horizontalmente subsistemas que exigem mais recursos, sem necessidade de escalar horizontalmente o aplicativo inteiro.Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application. Usando um orquestrador, como o Kubernetes ou o Service Fabric, você pode empacotar uma densidade maior de serviços em um único host, que permite a utilização mais eficiente de recursos.Using an orchestrator such as Kubernetes or Service Fabric, you can pack a higher density of services onto a single host, which allows for more efficient utilization of resources.

  • Isolamento de dados.Data isolation. É muito mais fácil executar atualizações de esquema, porque apenas um microsserviço é afetado.It is much easier to perform schema updates, because only a single microservice is affected. Em um aplicativo monolítico, atualizações de esquema podem se tornar muito difíceis porque todas as diferentes partes do aplicativo podem tocar os mesmos dados, o que torna a realização de qualquer alteração no esquema algo arriscado.In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky.

DesafiosChallenges

Os benefícios de microsserviços têm um ônus.The benefits of microservices don't come for free. Veja alguns dos desafios a serem considerados antes de embarcar em uma arquitetura de microsserviços.Here are some of the challenges to consider before embarking on a microservices architecture.

  • Complexidade.Complexity. Um aplicativo de microsserviços tem mais partes móveis que o aplicativo monolítico 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 testing. Escrever um pequeno serviço que precise de outros serviços dependentes exige uma abordagem diferente da escrita de um aplicativo monolítico ou em camadas tradicional.Writing a small service that relies on other dependent services requires a different approach than a writing a traditional monolithic or layered application. As ferramentas existentes nem sempre são projetadas para funcionar com dependências de serviço.Existing tools are not always designed to work with service dependencies. Refatorar entre limites de serviços pode ser difícil.Refactoring across service boundaries can be difficult. Também pode ser um desafio testar as dependências de serviço, especialmente quando o aplicativo está evoluindo rapidamente.It is also challenging to test service dependencies, especially when the application is evolving quickly.

  • Falta de governança.Lack of governance. A abordagem descentralizada para compilar microsserviços tem vantagens, mas também pode causar problemas.The decentralized approach to building microservices has advantages, but it can also lead to problems. Você pode acabar com muitos idiomas e estruturas diferentes que tornem difícil a manutenção do aplicativo.You may end up with so many different languages and frameworks that the application becomes hard to maintain. Pode ser útil estabelecer alguns padrões para todo o projeto, sem restringir excessivamente a flexibilidade das equipes.It may be useful to put some project-wide standards in place, without overly restricting teams' flexibility. Isso se aplica especialmente a funcionalidades abrangentes como registro em log.This especially applies to cross-cutting functionality such as logging.

  • Latência e congestionamento de rede.Network congestion and latency. O uso de muitos serviços granulares pequenos pode resultar em mais 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ço ficar muito longa (o serviço A chamada o B, que chama o C…) a latência adicional poderá se tornar 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. Você precisará projetar APIs com cuidado.You will need to design APIs carefully. Evite APIs excessivamente prolixas, pense em formatos de serialização e procure locais para usar 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 de dados.Data integrity. Cada microsserviço deve ser responsável pela própria persistência de dados.With each microservice responsible for its own data persistence. Assim, a consistência dos dados pode ser um desafio.As a result, data consistency can be a challenge. Adote consistência eventual quando possível.Embrace eventual consistency where possible.

  • Gerenciamento.Management. Ter êxito com microsserviços requer uma cultura DevOps madura.To be successful with microservices requires a mature DevOps culture. Registro em log correlacionado entre serviços pode ser desafiador.Correlated logging across services can be challenging. Normalmente, o registro em log deve correlacionar várias chamadas de serviço para uma operação de um único usuário.Typically, logging must correlate multiple service calls for a single user operation.

  • Controle de versão.Versioning. As atualizações de um serviço não devem interromper os serviços que dependerem delas.Updates to a service must not break services that depend on it. Vários serviços podem ser atualizados a qualquer momento, portanto, sem design cuidadoso, você pode ter problemas com compatibilidade com versões anteriores ou futuras.Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility.

  • Conjunto de qualificações.Skillset. Os microsserviços são sistemas altamente distribuídos.Microservices are highly distributed systems. Avalie cuidadosamente se a equipe tem as habilidades e a experiência para ser bem-sucedida.Carefully evaluate whether the team has the skills and experience to be successful.

Processar a criação de uma arquitetura de microsserviçosProcess for building a microservices architecture

Os artigos listados aqui apresentam uma abordagem estruturada para projetar, criar e operar uma arquitetura de microsserviços.The articles listed here present a structured approach for designing, building, and operating a microservices architecture.

Análise de domínio.Domain analysis. Para evitar algumas armadilhas comuns ao projetar microsserviços, use a análise de domínio para definir os limites do microsserviço.To avoid some common pitfalls when designing microservices, use domain analysis to define your microservice boundaries. Siga estas etapas:Follow these steps:

  1. Usar análise de domínio para microsserviços de modelo.Use domain analysis to model microservices.
  2. Usar DDD tático para projetar microsserviços.Use tactical DDD to design microservices.
  3. Identificar limites de microsserviço.Identify microservice boundaries.

Projetar os serviços.Design the services. Os microsserviços exigem uma abordagem diferente para o design e criação de aplicativos.Microservices require a different approach to designing and building applications. Para obter mais informações, confira Projetar uma arquitetura de microsserviços.For more information, see Designing a microservices architecture.

Operar na produção.Operate in production. Como as arquiteturas de microserviços são distribuídas, você deve ter operações robustas para implantação e monitoramento.Because microservices architectures are distributed, you must have robust operations for deployment and monitoring.

Arquiteturas de referência de microsserviços para o AzureMicroservices reference architectures for Azure