A arquitetura de microsserviços
- A)é uma estrutura em que um aplicativo é separado em serviços menores e cada um desses serviços pode executar um processo exclusivo e, ainda, gerenciar seu próprio banco de dados.
Correta, porque descreve a divisão do sistema em serviços independentes, com execução própria e até banco de dados próprio por serviço.
- B)é um estilo arquitetônico em que todos os componentes fazem parte de uma única unidade, sendo todos desenvolvidos e implantados em conjunto para que formem barramentos de serviços.
Errada, porque descreve um modelo monolítico, em que tudo é desenvolvido e implantado junto, o oposto de microsserviços.
- C)é uma estrutura que não necessita de clientes, pois os aplicativos se conectam à estrutura por meio de application programming interface (API) aos barramentos de serviços.
Errada, porque microsserviços continuam tendo clientes e se comunicam com APIs ou mensagens; além disso, não dependem de barramento de serviços central.
- D)possui como vantagem a alta disponibilidade, pois o barramento de serviços une todos os componentes, tornando-os uma única unidade, contudo, os aplicativos executados nessa arquitetura são menos eficientes, no que se refere à velocidade, do que a monolítica.
Errada, porque mistura conceitos de barramento e unidade única, que não combinam com microsserviços, e ainda faz uma comparação simplista de desempenho.
- E)é formada por componentes, acessados por meio de mensagens, que podem ser desenvolvidos separadamente, contudo, por serem stateless, ao serem reimplantados, ou se houver a necessidade de alteração de um serviço na arquitetura, é cogente reimplantar um aplicativo inteiro.
Errada, porque microsserviços não exigem reimplantar o sistema inteiro quando um serviço muda; a ideia é justamente permitir alteração e deploy isolados.
Gabarito: A
Microsserviços são uma forma de organizar o sistema em partes menores e independentes, em vez de colocar tudo dentro de um grande bloco só. A ideia é que cada serviço cuide de uma capacidade de negócio específica, possa ser desenvolvido, testado e implantado separadamente e fale com os outros por APIs ou mensagens. Isso dá mais autonomia para as equipes e costuma facilitar evolução e escalabilidade. O ponto mais cobrado em prova é que, em microsserviços, cada serviço é independente e pode até ter seu próprio banco de dados, quando isso fizer sentido. Não existe a exigência de um barramento central mandando em tudo, porque isso já puxa a arquitetura para outros modelos, como SOA mais tradicional. Também não faz sentido dizer que tudo precisa ser implantado junto, porque isso seria quase a negação da proposta de microsserviços. Por isso o gabarito é a letra A: ela descreve corretamente a separação do aplicativo em serviços menores, com execução independente e possibilidade de cada serviço gerenciar seu próprio banco de dados. Essa autonomia é justamente uma marca forte da arquitetura de microsserviços, muito associada na doutrina de arquitetura de software à descentralização e à implantação independente. Em resumo: se a alternativa fala em serviços pequenos, independentes, com deploy separado e comunicação por API, desconfie menos. Se ela fala em unidade única, barramento central e tudo sendo reimplantado junto, o cheiro de pegadinha aumenta bastante.