Em termos de arquitetura e design de software, como os microsserviços "se comparam" (trocadilhos) com o middleware? Eu sou proveniente de Java e parece que à medida que você se afasta do REST direto como uma API e abstrai diferentes camadas e parâmetros de conexão, pelo menos em Java, você quase volta a algumas ideias da velha escola . Voltamos à virtualização ... onde a JVM já é virtual.
De uma maneira agnóstica, você pode, e eu argumentaria as vantagens de, abstrair uma API RESTful para CORBA. Ou, de uma maneira mais centrada em java, JMS ou MDB.
Ao mesmo tempo, o EJB era um grande negócio em Java, depois foi reconhecido como um efeito de cluster, mas, agora, estamos de volta ao começo?
Ou os microsserviços oferecem algo que falta ao CORBA, ou melhor ainda, ao MDB? Quando eu leio (TLDR) Martin Fowler explicando microsserviços, isso me parece uma boa solução para um problema ruim, se você quiser. Ou melhor, uma abordagem de mente fechada, que introduz um nível de complexidade que apenas impulsiona o problema. Se os serviços realmente são micro e são numerosos, cada um tem um custo em dólares para executá-lo e mantê-lo.
Além disso, se um microsserviço entre muitos altera sua API, tudo depende desse serviço é interrompido. Não parece fracamente acoplado, parece o oposto de ágil. Ou estou usando mal essas palavras?
Obviamente, há uma quantidade indeterminada de opções entre esses extremos.
Tubarão contra gorila ... vai! (Para o pedante, isso deve ser irônico, e não é minha intenção. A pergunta deve ser feita pelo valor de face. Se a pergunta puder ser melhorada, faça-o ou comente e eu vou corrigir. )
Visualize uma infinidade de microsserviços executando no docker, todos em uma máquina, conversando entre si ... loucura. Difícil de manter ou administrar, e quase impossível mudar alguma coisa, porque qualquer alteração ocorrerá em cascata e causará erros imprevisíveis. De que maneira é melhor que esses serviços estejam espalhados por diferentes máquinas? E, se forem distribuídos, certamente algumas técnicas da escola muito, muito antiga resolveram, pelo menos até certo ponto, a computação distribuída.
Por que a escala horizontal é tão predominante ou pelo menos desejável?
giant blobfazê-lo, pois o sistema operacional não pode ser criado , pois ele precisa ter interfaces, portanto, cada parte que começa no kernel é uma espécie de MS, e a primeira coisa antes qualquer equipe que começou a escrever o código concordou com as especificações v0.0.1.Respostas:
TL; DR. Tive o prazer de beber muito Kool-Aid com sabor de Microserver, para que eu possa falar um pouco sobre as razões por trás deles.
Prós:
Contras:
Eu acho que você basicamente não entende como uma arquitetura de microsserviço deve funcionar. A maneira como deve ser executado é que todo microsserviço (referido daqui em diante como MS) possui uma API rígida com a qual todos os seus clientes concordam. É permitido ao MS fazer as alterações desejadas desde que a API seja preservada. O MS pode ser descartado e reescrito do zero, desde que a API seja preservada.
Para auxiliar no acoplamento flexível, todo MS depende da versão n-1 de suas dependências. Isso permite que a versão atual do serviço seja menos estável e um pouco mais arriscada. Ele também permite que as versões saiam em ondas. O primeiro servidor 1 é atualizado, depois a metade e, finalmente, o restante. Se a versão atual desenvolver algum problema sério, o MS poderá ser revertido para uma versão anterior sem perda de funcionalidade em outras camadas.
Se a API precisar ser alterada, ela deverá ser alterada de uma maneira que seja compatível com versões anteriores.
fonte
Todas as técnicas de desenvolvimento de software que já inventamos tratam de alguma forma o gerenciamento da complexidade. Uma grande parte deles tem sido e continua sendo sobre abstração, encapsulamento e acoplamento flexível. Os microsserviços são outra maneira de fazer essas coisas, e é provavelmente por isso que se assemelha a muitas técnicas mais antigas em um alto nível teórico, mas isso não a torna menos útil ou relevante.
Em relação ao acoplamento flexível, acho que você entendeu um pouco o objetivo. Se a tarefa A precisar chamar a tarefa B, nunca haverá uma maneira de separar A e B 100%. Isso nunca vai acontecer. O que você pode fazer é garantir que, se a tarefa B chamar a tarefa C, a tarefa C nunca precisar se preocupar com as alterações em A. Se essas três tarefas estiverem todas ligadas em um grande blob, passando estruturas entre si, haverá um chance significativa de que todos eles tenham que mudar se algum deles mudar. Mas se todos os três forem microsserviços, você tem basicamente a garantia de que uma alteração em A forçará apenas a atualização de B (a menos que seja uma alteração tão grande na funcionalidade principal de A que você provavelmente deveria ter feito dele um serviço totalmente novo). Isso é especialmente verdadeiro se todas as atualizações de microsserviço forem feitas de uma maneira compatível com versões anteriores, como deveriam ser.
Com relação ao comentário ágil, posso dizer por experiência pessoal que nosso código de microsserviço-y é muito melhor com o ágil do que o código "vinculado a um grande blob". Neste último caso, sempre que alguém corrige um bug em uma função de baixo nível, ele literalmente precisa enviar um e-mail para todo o departamento de P&D dizendo "por favor, vincule novamente suas tarefas ou elas falharão na sexta-feira". Temos alguns desses toda semana . Se o código dele estivesse em um microsserviço, todos nós nos beneficiaríamos automaticamente da correção assim que ele implantasse uma nova versão.
Não entendo completamente o comentário sobre COBRA e MDB, pois eles não parecem arquiteturas de software, mas componentes de uma; no meu entender, são formas possíveis de definir os protocolos de mensagens de seus microsserviços e / ou implementar esses microsserviços, não por si só alternativas aos microsserviços.
fonte
Por causa da nuvem.
Já riu? Sério, porém - para muitas empresas, o maior custo do software não é mais o software. É a largura de banda, o hardware, os custos de CDN etc. Agora que todo mundo tem um dispositivo móvel, há muito mais tráfego. E isso só vai piorar à medida que sua torradeira obtém sua própria conectividade com a Internet.
Portanto, as empresas buscam gerenciar esses custos. Especificamente, eles estão tentando lidar com o problema de negócios de "se isso acontecer, como posso atender milhões de pessoas recebendo / usando meu software - sem pagar antecipadamente que os servidores atendam milhões de pessoas recebendo / usando meu software ? "
Porque responde a este (enorme e crescente) problema de negócios.
Quando você tem uma dúzia de usuários, pode lançar todos os serviços em uma caixa. Isso é bom, pois você só quer pagar por uma caixa. E você também não deseja pagar por alterações no aplicativo para dividir os vários serviços quando a sua empresa crescer. Hoje em dia, você não tem tempo para fazer isso antes que a multidão de clientes acenda seus servidores de qualquer maneira.
Também é bom porque permite manipular alocações de servidor para que você possa:
Ter implantações muito granulares facilita / melhora essas duas coisas (além de ajudar a impor uma melhor separação de preocupações).
fonte