chegamos a um círculo completo com microsserviços, voltando a abordagens muito antigas?


9

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 é 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?


4
Votação para fechar. Não está claro o que você está perguntando e por que está perguntando. A arquitetura de microsserviço é apenas outra arquitetura. Nada mais nada menos.
Davidk01 11/03/2015

11
Você também pode encontrar este artigo interessante: devweek.com/blog/microservices-the-good-the-bad-and-the-ugly
davidk01

11
Eu prefiro "Então, agora eles têm centenas de pequenos serviços falsos e, em vez de um monólito, precisam se preocupar com o que acontece quando alguém quer alterar o contrato de um desses serviços. Um novelo de lã com um nome diferente. de se perguntar se o código será compilado se fizerem uma alteração, eles se perguntam se ele será executado, na prática ". - microsserviços para isenção de responsabilidade de gravatas mal-humoradas : não, eu não sou uma gravata, é apenas um artigo de humor.
Thufir

"Em vez de se perguntar se o código será compilado ... eles se perguntam se ele será executado ..." Na verdade, isso não é um problema. Simplesmente porque se um desenvolvedor altera um contrato sem notificar todas as partes envolvidas - esse desenvolvedor deve ser espancado com muita força. Literalmente. Se usarmos contrato por prazo, imagine se sua operadora de telefonia móvel alterar os termos do contrato sem perguntar / informar? É por isso que é contrato - todas as partes envolvidas devem estar cientes / concordar com as alterações contratuais e, quando essa alteração ocorrer (assumindo um fluxo de desenvolvimento adequado), todas deverão ser testadas e executadas sem problemas.
Alexey Kamenskiy

11
@ Thufir Como foi dito antes, a MS é apenas outra abordagem, ela terá seus benefícios e suas desvantagens. Na verdade, trabalhei com essa abordagem (mesmo antes de saber que ela tem um nome especial) em vários projetos. Como uma nota lateral - não é uma cachoeira, é o que você faz. Como eu trabalhei em um projeto que desenvolvia (em equipe) parte do sistema operacional móvel, essa abordagem é a única maneira de 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.
Alexey Kamenskiy

Respostas:


2

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:

  • Os serviços sabem que suas dependências são estáveis ​​e tiveram tempo para assar
  • Permitir implantações contínuas de novas versões
  • Permita que os componentes sejam revertidos sem afetar as camadas superiores.

Contras:

  • Você não pode usar os recursos novos e brilhantes de suas dependências.
  • Você nunca pode quebrar a compatibilidade com versões anteriores da API (ou pelo menos não por muitos ciclos de desenvolvimento).

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.


"O MS pode ser descartado e reescrito do zero, desde que a API seja preservada." - nada de novo por lá, mas tudo bem. Em termos de desempenho, no extremo oposto do espectro, como todos esses EM se comparam a um aplicativo / serviço / sistema monolítico? Em termos de distribuição, parece , e por favor me corrija se estiver errado, que há um potencial ganho de desempenho ao colocar n MS em uma única máquina ... virtualizados em um mainframe? É quase como quanto mais você dimensiona o MS horizontalmente, mais simples se torna dimensioná-lo verticalmente ...? Os pontos de bónus para não ler a minha pergunta :)
Thufir

11
Como em qualquer camada de indireção, você está sofrendo um impacto no desempenho em comparação com uma grande bola de barro. No caso da MS, é particularmente caro, pois você faz uma ida e volta à rede em todas as chamadas. O uso de virtualização ou contêineres torna essa ida e volta significativamente mais curta, pois a chamada nunca sai da máquina. Isso também significa que você ganha mais isolamento (um serviço descontrolado não pode prejudicar seus pares) com um custo de hardware menor.
Konstantin Tarashchanskiy

5

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.


11
"Se essas três tarefas estiverem todas ligadas em um grande blob ..." Eu só tenho uma perspectiva Java sobre isso, mas eu diria "não", má idéia, não faça isso. Crie uma biblioteca, API nº 1, API nº 2, etc., para atingir seu ponto exato de "..a tarefa C nunca deve se preocupar com alterações em A", porque C é um cliente apenas de B e não de A . A esse respeito, não vejo isso como algo novo, perdão. Eu sei que a pergunta que fiz foi confusa. É uma pergunta confusa porque sou confusa sobre o que se trata. Toda e qualquer resposta tem sido útil para mim, apenas para ajudar no meu vocabulário.
Thufir

11
@Thufir Se todas as bibliotecas estiverem vinculadas dinamicamente e todas as tarefas executadas exatamente no mesmo conjunto de máquinas, então você está certo, isso realmente permitiria o lançamento em separado. Mas os microsserviços permitem descartar até mesmo essas suposições, se você quiser ir tão longe com a dissociação. É inteiramente razoável não fazê-lo.
Ixrec 12/03/2015

O CORBA é (era) uma tecnologia distribuída que permitia arquiteturas distribuídas em uma época (final de 1990) quando ainda não havia nomes comuns para defini-las. Você estava livre para implementar sistemas baseados em CORBA de granulação grossa ou granular, terminando no que mais tarde seria chamado de SOA ou Microsserviços. O CORBA não sobreviveu, mas estamos fazendo isso de novo, apenas com uma tecnologia diferente. O problema, no entanto, não era tecnologia. Então, sim, estamos fazendo um círculo completo. Espero que tenhamos aprendido algo no processo.
xtian

4

De que maneira é melhor que esses serviços estejam espalhados por diferentes máquinas?

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 ? "

Por que a escala horizontal é tão predominante ou pelo menos desejável?

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:

  1. use a maioria dos servidores que você tem, deixando pouco a "desperdiçar".
  2. meça os elementos individuais de desempenho do seu software.
  3. reduzir o tempo de implantação / inatividade causado por liberações.

Ter implantações muito granulares facilita / melhora essas duas coisas (além de ajudar a impor uma melhor separação de preocupações).


Ok, eu posso ver a vantagem. Há uma baixa barreira à entrada, mas pode aumentar. Suponho que o que mais me impressiona é quando você dimensiona horizontalmente n MS, parece ... muito ... retro? Alguma coisa. Não sei dizer por que parece errado.
Thufir

O dimensionamento de aplicativos é um problema que não precisa necessariamente de microsserviços: você pode aumentar o poder de uma VM com muita facilidade na AWS (mesmo sob demanda) ou adicionar mais VMs atrás de um balanceador de carga em uma arquitetura tradicional.
Xtian

@xtian - claro, mas muitas vezes você está escalando as coisas erradas e gastando mais dinheiro do que precisa. A idéia por trás microservices é você apenas dimensionar o que você precisa (CPU, memória, disco, rendimento, gpu)
Telastyn
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.