O que é realmente diferente entre SOA e microsserviços


10

aviso Legal

Espero não pisar nos pés de ninguém ou ofender os entusiastas de qualquer um dos conceitos

fundo

Eu tenho procurado diferenças reais entre arquitetura orientada a serviços e microsserviços, sem encontrar nenhuma resposta clara.

Eu li coisas como:

  • os efeitos colaterais da SOA
  • SOA sendo anti-padrão
  • Os microsserviços vieram corrigir as falhas da SOA
  • ESBs não são realmente ESBs, são EAIs
  • Dependência excessiva de Message Brokers
  • Os fornecedores estão abusando da noção de SOA e tentando vender seus produtos
  • SOA cresce incontrolavelmente

Mas, ainda assim, nada define claramente diferenças arquiteturais entre Arquitetura Orientada a Serviços (como conceito) e Microsserviços (como conceito)

De acordo com o que eu entendi, ambos têm:

  • Provedores de Serviços, fazendo apenas uma coisa
  • Service Gateway / ESB que expõe esses serviços aos consumidores
  • Consumidores de serviços, acessando serviços via ESB / Service Gateway

Questão

Então, há algo diferente além de re-rotular SOA em microsserviços? é uma restrição de tecnologia colocada para impedir que os microsserviços se tornem macro?

Nota: Não estou à procura de opiniões, apenas fatos concretos, espero que em pontos de bala

Referências

Atualizar

Parece que um debate semelhante ocorreu em uma questão de estouro de pilha , com opiniões divididas, independentemente de os microsserviços estarem disfarçados em arquitetura orientada a serviços.

Conclusão da pergunta SO:

  • MS é um caso especial de SOA
  • MS endossa tamanho menor de aplicativos que hospedam serviços
  • O MS depende da tecnologia (o uso de HTTP em vez de opções de protocolo aberto)
  • A Microsoft confia na tecnologia para impor disciplina (implantação automática de serviços)
  • O MS considera ESBs (mal), mas usa Gateways de API, que IMHO é um tipo de ESB

Isso conclui que o MS é SOA, se o seguinte for verdadeiro:

  • Os Estados-Membros apoiam a noção de orquestração? Um ou mais processos principais gerenciam fluxos de trabalho
  • Existe uma camada do intermediário de mensagens no MS? Um conjunto de adaptadores que traduzem formatos de mensagem do espaço de mensagem dos produtores de serviços para os consumidores de serviços
  • Os microsserviços podem ler dados de aplicativos corporativos monolíticos? Podem ser APIs de um aplicativo monolítico? ou deve ser aplicativos autônomos independentes, capazes de operar independentemente?

Se a resposta para a última pergunta for negativa, os microsserviços não serão capazes de lidar com sistemas complexos de fluxo de trabalho, por exemplo, sistemas de gerenciamento de cartão de crédito ou sistemas de reconciliação


Atualmente, a moda da computação distribuída é pequena "agentes" ou "módulos" tolerantes a falhas, pouco acoplados, descentralizados, que têm responsabilidades claras e específicas e são conectados por um protocolo de comunicação simples e direto. SOA é praticamente o oposto de tudo isso. Você está observando o monte de semelhanças superficiais e negligenciando a montanha das diferenças.
Robert Harvey

11
A SOA também não deve implementar pequenos componentes fracamente acoplados? Sei que, no back-end da SOA, são aplicativos multifuncionais, descritos principalmente como o "Melhor da categoria", fornecendo serviços para outros aplicativos e consumindo serviços de outros aplicativos, usando qualquer formato de mensagem, protocolo e acesso médio adequado a ele
A .Rashad

Deveria, mas como você apontou, normalmente não.
Robert Harvey

Martin Fowler's Site (I think he hates it big time)Não foram meus sentimentos quando fui à sua palestra em Barcelona. Ele está ciente das vantagens e desvantagens de como as pessoas mudaram para essa arquitetura cegamente, sem considerar que o MS não é adequado para todos.
LAIV

11
Microsserviços é um monte de marketing. Não há diferença. As pessoas estavam fazendo isso anos atrás e agora alguém colocou um nome nele e agora algo novo. Você está certo de que o MS é um caso (NÃO ESPECIAL) de SOA. Por favor, pare de tentar fazer algo com isso.
Kyle Johnson

Respostas:


12

Provedores de Serviços, fazendo apenas uma coisa

A principal diferença, que tem conseqüências generalizadas do projeto, é que, com os microsserviços, esses provedores de serviços são implantáveis ​​e escalonáveis ​​independentemente .

Isso é ótimo, porque você pode ser mais ágil. Se um serviço precisar ser alterado, você apenas altera esse, nenhum de seus parentes. Se você quiser experimentar uma nova estrutura ou linguagem, faça um substituto para esse serviço. Se você precisar repentinamente de 100x de capacidade, instale novas máquinas com esse serviço para lidar com esse fluxo. Se você quiser fazer uma versão de alguma coisa, apenas faça a versão sem tocar no aplicativo inteiro . E torna as coisas mais fáceis de monitorar, instrumentar, dividir entre equipes, obsoletas ...

Mas vem com algumas implicações de heafty:

  • Seu processo de liberação precisa mudar, porque a implantação de alguns serviços é muito diferente da implantação de algumas dezenas de serviços.
  • Seu processo de liberação precisa mudar, porque implantar um serviço em uma máquina é muito diferente de implantar em algumas dezenas de máquinas.
  • O design, o uso e a implantação do banco de dados precisam ser alterados, porque não faz sentido implantar um serviço se for necessário implantar esse grande banco de dados compartilhado para funcionar (interrompendo todos os outros serviços).
  • Seu design e uso de bibliotecas precisam ser alterados, porque não faz sentido implantar um serviço se ele precisar atualizar essa biblioteca compartilhada (interrompendo todos os outros serviços).
  • Seu logging / autorização / gerenciamento de sessão / etc precisa mudar porque é muito fácil de coisas share quando você é apenas um serviço, mas diferente quando você tem um monte de serviços de pequenos independentes que compõem o produto - e eles estão indo para quer compartilhar coisas. Ah, e todo esse material compartilhado precisa lidar com o potencial de estar em versões diferentes.
  • Sua comunicação precisa mudar. Com poucos serviços, você pode dividir as coisas em linhas onde a comunicação não ocorre com frequência e / ou pode ocorrer lentamente. Com os microsserviços, eles conversam muito e a alta latência não é suficiente.

11
É por todos esses motivos que vejo os microsserviços como uma solução específica para um problema específico (dimensionamento via computação distribuída), e não como uma arquitetura geral de aplicativos.
Robert Harvey

11
Enh, eles têm um impacto amplo o suficiente para que eu deva ser visto como uma arquitetura de aplicativo com escalabilidade / computação distribuída como uma vantagem (com complexidade e outras desvantagens como compensação).
Telastyn

11
Portanto, do ponto de vista da arquitetura, os microsserviços são microssistemas independentes fazendo uma coisa, enquanto SOA são aplicativos monolíticos com vários serviços expostos aos consumidores?
precisa saber é o seguinte

11
Estou mais confuso agora! É possível que um aplicativo monolítico exponha microsserviços? ou tem que ser micro aplicações independentes?
precisa saber é o seguinte

11
Dê uma olhada neste artigo em DZone Microservices vs SOA .
LAIV

2

Aqui está o resultado final A única diferença óbvia entre SOA e microsserviços é a noção de

Tubos burros inteligentes de pontos finais

Diferentemente da SOA , isso dependeria de consumidores e produtores de serviços alheios, delegando o gerenciamento de tráfego, a tradução do formato da mensagem e a orquestração de serviços para sistemas externos, por exemplo, ESB, Service Orchestrator, Message broker.

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.