SOA, microsserviços, arquitetura sem servidor

Este artigo está reproduzido em: Arquitetura de Software Distribuído - Arquitetura SOA / Arquitetura de Microsserviços / Arquitetura Serverless

Apenas para registro.

---

Arquitetura SOA

Arquitetura Orientada a Serviços, arquitetura orientada a serviços. A arquitetura orientada a serviços é um padrão arquitetônico que resolve com sucesso os principais problemas dos serviços distribuídos de forma concreta e sistemática. Antes de compreender a arquitetura SOA, primeiro entenda os três padrões arquitetônicos representativos de divisão de serviços.Esses padrões arquitetônicos são os produtos intermediários do processo de evolução da SOA e os pré-requisitos necessários para o surgimento da arquitetura SOA.

Arquitetura de Chaminé (Arquitetura de Silo de Informação)

As chaminés de informação também são conhecidas como ilhas de informação, e os sistemas que utilizam essa arquitetura também são chamados de sistemas de informação isolados ou sistemas de informação em chaminé. Refere-se a um padrão de projeto que não interopera nem funciona em harmonia com outros sistemas de informação relacionados. Na verdade, esse sistema não possui nenhum "projeto de arquitetura". Seguindo o exemplo de uma empresa e de um departamento na secção anterior, se os dois departamentos realmente não interagem, não há razão para forçá-los a trabalhar no mesmo edifício; dois sistemas de informação que não interagem, deixe-os usar bancos de dados e servidores independentes para conseguir a divisão, mas o único problema, e o problema fatal, é: existe realmente um departamento na empresa que não interage de forma alguma ? Para os dois sistemas de informação, mesmo que não exista realmente nenhuma relação comercial, os dados mestre do sistema, como pessoal, organização, autoridade, etc. , serão completamente independentes, sem qualquer sobreposição? Tal sistema de “divisão independente” e “independente” é obviamente impossível para as empresas esperarem ver.

Arquitetura Microkernel

A arquitetura microkernel também é conhecida como arquitetura de plug-in (arquitetura de plug-in). Como na arquitetura chaminé, sistemas sem relações comerciais também podem precisar compartilhar alguns dados mestres públicos, como pessoal, organizações, permissões, etc., é aconselhável usar esses dados mestres, juntamente com outros serviços públicos que podem ser usados ​​por vários subsistemas, dados e recursos são reunidos para se tornarem um núcleo (Kernel, também conhecido como Core System) que é comumente usado por todos os sistemas de negócios. Existem sistemas de negócios específicos na forma de módulos de plug-in (Módulos de plug-in) , que também pode fornecer características funcionais estendidas, flexíveis e naturalmente isoladas, ou seja, a arquitetura do microkernel, são mostradas na figura.

Esse padrão é adequado para aplicativos de desktop e também é frequentemente usado em aplicativos da web. Qualquer sistema de computador é realizado por vários tipos de software trabalhando juntos para realizar funções específicas. O software realizado por diferentes arquiteturas listadas nesta seção pode ser considerado uma espécie de plug-in de todo o sistema. Para aplicações de plataforma, se quisermos adicionar novos recursos ou funções ao sistema em tempo hábil, a arquitetura microkernel será uma boa solução. A arquitetura do microkernel também pode ser incorporada em outros modelos de arquitetura e fornecer recursos de desenvolvimento personalizados para novas funções por meio de plug-ins. Se você planeja implementar um sistema de software que possa suportar o desenvolvimento secundário, o microkernel também será uma boa escolha. Porém, a arquitetura microkernel também tem suas limitações e pré-requisitos. Ela pressupõe que os módulos plug-in do sistema não se conhecem e é imprevisível quais módulos serão instalados no sistema. Portanto, esses plug-ins podem acessar alguns recursos públicos no kernel, mas não interagirão diretamente. No entanto, quer se trate de um sistema de informação empresarial ou de uma aplicação de Internet, esta premissa não se aplica a muitos cenários. Devemos encontrar uma forma não só de dividir sistemas independentes, mas também de permitir uma comunicação suave entre os subsistemas divididos. comunicar.

Arquitetura Orientada a Eventos (Arquitetura Orientada a Eventos)

Para permitir que os subsistemas se comuniquem entre si, uma solução viável é estabelecer um conjunto de pipelines de filas de eventos (Event Queues) entre os subsistemas. Mensagens de fora do sistema serão enviadas para o pipeline na forma de eventos. Obtenha o evento mensagens nas quais você está interessado e pode lidar, e você também pode adicionar ou modificar informações adicionais para o evento, e até mesmo publicar alguns novos eventos na fila do pipeline. Dessa forma, o processador de cada mensagem é independente, altamente desacoplado, mas pode interagir com outros manipuladores (se o manipulador de mensagens existir) por meio do pipeline de eventos, conforme mostrado na figura.

Exploração da Era da Arquitetura SOA

O conceito de SOA foi proposto pela primeira vez pelo Gartner em 1994. Naquela época, SOA não tinha condições de desenvolvimento. A situação não mudou até 2006. IBM, Oracle, SAP e outras empresas estabeleceram em conjunto a OSOA Alliance (Open Service Oriented Arquitetura). , usado para formular e promover em conjunto padrões da indústria relacionados à SOA. Em 2007, sob a iniciativa e apoio da Organização para o Avanço dos Padrões de Informação Estruturada (OASIS), a OSOA deixou de ser uma aliança frouxa de fornecedores de software para se tornar uma organização internacional que define padrões da indústria. Juntamente com a recém-criada organização Open CSA (Open Composite Services Architecture), esta é a organização oficial de gerenciamento de SOA.

A arquitetura de software chegou à era SOA e muitos conceitos e ideias já podem ser encontrados nos microsserviços atuais, como acoplamento flexível entre serviços, registro, descoberta, governança, isolamento, orquestração e assim por diante. A maioria desses conceitos substantivos familiares nos microsserviços atuais também são dificuldades previsíveis quando os serviços distribuídos foram propostos pela primeira vez. SOA realizou uma exploração mais sistemática e específica sobre essas questões, e até mesmo sobre a questão do próprio “desenvolvimento de software”.

1. Mais específico
   "Mais específico" reflete-se no fato de que, embora SOA em si ainda seja um conceito abstrato em vez de uma tecnologia específica, é mais operável do que a arquitetura monolítica e os três padrões arquitetônicos listados acima. Não pode ser simplesmente considerado como um estilo arquitetônico, mas pode ser chamada de plataforma básica para design de software. Possui Open CSA, uma organização que lidera o desenvolvimento de padrões técnicos; existem princípios orientadores claros para o design de software, como encapsulamento de serviço, autonomia, baixo acoplamento, reusabilidade, composibilidade, apatridia, etc.; Protocolo, contando com o protocolo SOAP família (WSDL, UDDI e um grande número de protocolos WS-*) para completar a publicação, descoberta e gerenciamento de serviços; usando um pipeline de mensagens chamado Enterprise Service Bus (Enterprise Service Bus, ESB) para implementar cada A comunicação e interação entre subsistemas permite que os serviços se comuniquem entre si sem interdependência sob o agendamento ESB, o que não apenas traz os benefícios de serviços fracamente acoplados, mas também facilita a implementação adicional do gerenciamento de processos de negócios (BPM) no futuro. Fornece a base; usa o objeto de dados de serviço ( Service Data Object, SDO) para acessar e representar dados, usar Service Component Architecture (Service Component Architecture, SCA) para definir a forma de encapsulamento do serviço e o contêiner no qual o serviço é executado, e assim por diante. Com o apoio de todo este conjunto de componentes técnicos que podem cooperar estreitamente entre si, se julgados apenas do ponto de vista da viabilidade técnica, a SOA pode ser considerada como resolvendo com sucesso os principais problemas técnicos no ambiente distribuído.

2. Mais sistemático
   "Mais sistemático" refere-se ao grande ideal da SOA. Seu objetivo final é resumir um conjunto de metodologias de desenvolvimento de software de cima para baixo, esperando que as empresas possam resolver o problema do software em um pacote apenas seguindo a ideia de SOA: Todos os problemas no processo de desenvolvimento, como como extrair requisitos, como decompor requisitos em capacidades de negócios, como organizar serviços existentes, como desenvolver, testar e implantar novas funções e assim por diante. As questões técnicas são de facto fundamentais e difíceis, mas são apenas uma delas.SOA não se concentra apenas na tecnologia, mas também nos requisitos, gestão, processos e organizações envolvidas no processo de I&D. Se esse objetivo puder realmente ser alcançado, o desenvolvimento de software poderá entrar no estágio de produção industrializada em massa. Imagine que um dia escrever software que atenda às necessidades do cliente será tão rastreável e baseado em leis quanto escrever ensaios estereotipados. Pode ser chato para desenvolvedores de software. , mas a eficiência da implementação da informatização em toda a sociedade será certamente muito melhorada.

SOA já foi popular nos primeiros dez anos do século 21, e muitos gigantes da indústria, como a IBM, gritaram por isso, atraindo muitos desenvolvedores de software, especialmente desenvolvedores de software de nível empresarial, mas finalmente morreram. Na seção posterior da invocação de serviço remoto, o autor mencionará a razão essencial pela qual o protocolo SOAP é gradualmente marginalizado: uma definição de especificação muito rigorosa traz complexidade excessiva. E muitas superestruturas como ESB, BPM, SCA e SDO construídas com base em SOAP agravam ainda mais esta complexidade. Afinal, o desenvolvimento de sistemas de informação não é feito de artigos estereotipados, pois processos e teorias excessivamente sofisticados também exigem profissionais que entendam conceitos complexos para poder controlá-los. Desde o dia em que SOA nasceu, ele estava condenado a ser um luxo requintado de alguns sistemas. Ele pode realizar a complexa integração e interação entre vários sistemas grandes e heterogêneos, mas é difícil de ser usado como um sistema amplamente aplicável. Promovendo um revolucionário estilo arquitetônico de software. A falha fatal do fracasso da SOA no final é exatamente a mesma do EJB daquela época. Apesar do apoio de gigantes como Sun Microsystems e IBM, o EJB ainda é derrotado pela "estrutura de base" representada por Spring e Hibernate. Ele pode veja-se que, uma vez separado do povo, acabará submerso no oceano das massas, mesmo a tecnologia da informação não é exceção.

Depois de ler isto, você também pode pensar na questão "como usar vários serviços distribuídos independentes para construir conjuntamente um sistema maior" e, em seguida, relembrar a essência do design do serviço distribuído proposto pelo Unix DCE na seção "Era Distribuída Original " : "Deixe os desenvolvedores não se importarem se o serviço é remoto ou local e possam chamar serviços ou acessar recursos de forma transparente." Após 30 anos de progresso tecnológico, os sistemas de informação experimentaram padrões arquitetônicos como pedregulhos, chaminés, plug-ins, eventos, SOA, etc., mas as aplicações são cada vez mais prejudicadas pela complexidade da arquitetura, e a palavra "transparência" está mais longe e mais longe. Está ficando cada vez mais longe. Isso conta como um esquecimento inconsciente da intenção original do ano? A era dos microsserviços da qual falaremos a seguir parece ter sido aberta com essas questões introspectivas.

arquitetura de microsserviços

Na verdade, o termo “microsserviço” foi proposto e usado pelo Dr. Peter Rodgers na Cloud Computing Expo de 2005 (Web Services Edge 2005). O termo na época era "Micro-Web-Service", referindo-se a um serviço Web refinado, independente de linguagem e focado em responsabilidade única (Granular Web Services). O termo “microsserviço” não é um conceito criado por Peter Rodgers diretamente do nada. Pode-se dizer que os primeiros microsserviços são produtos que nasceram durante o desenvolvimento da SOA, assim como as estruturas Spring e Hibernate nasceram durante a promoção do EJB. Os microsserviços, neste estágio, são propostos como uma solução leve para SOA. Até hoje, na versão em inglês da Wikipedia, as pessoas ainda definem microsserviços como uma variante de SOA. Portanto, é completamente compreensível que os microsserviços estejam envolvidos em conceitos como SOA e Web Service durante seu nascimento e estágio inicial de desenvolvimento.

O que são microsserviçosMicrosserviços são uma técnica de desenvolvimento de software - uma variante do estilo estrutural da arquitetura orientada a serviços （SOA）.—— Wikipedia, Microserviços

Mas quando olhamos agora, a definição de microsserviços da Wikipedia está um pouco desatualizada. Depois que o conceito de microsserviços foi proposto, ele não recebeu muita atenção nos últimos 10 anos. Se for apenas um remendo na arquitetura SOA existente, é realmente difícil despertar mais entusiasmo entre o pessoal técnico. No entanto, nos últimos 10 anos, os próprios microsserviços também têm pensado e mudado.
Em 2012, na "33ª Conferência de Grau" realizada em Cracóvia, Polônia, James Lewis, Consultor Chefe da Thoughtworks, fez um discurso intitulado "Microserviços - Java, o Estilo Unix", que mencionou responsabilidade de serviço único, Lei de Conway, expansão automática , design orientado a domínio e outros princípios, mas não mencionou SOA, mas defendeu que a filosofia de design do Unix (As Well Behaved Unix Services) deveria ser recuperada, o que parece ser o mesmo que o autor disse na seção anterior .Auto-exame” ecoa de longe. Os microsserviços mal podem esperar para romper com o vassalo da SOA e se tornar um estilo arquitetônico independente. Talvez também seja um revolucionário da SOA.

A verdadeira ascensão dos microsserviços ocorreu em 2014. Acredito que a maioria dos leitores que leram este artigo também aprenderam sobre microsserviços pela primeira vez no artigo "Microsserviços: uma definição deste novo termo arquitetônico" co-escrito por Martin Fowler e James Lewis, e Isso não significa que você deva ter lido este artigo, ou para ser mais preciso, o “microsserviço” que você conhece hoje é o “microsserviço” proposto neste artigo. Neste artigo, o conceito de microsserviços modernos é definido: "Microsserviços são um estilo arquitetônico para construir um único aplicativo por meio da composição de muitos pequenos serviços, que são construídos em torno de capacidades de negócios e não de padrões técnicos específicos. Serviços individuais podem usar diferentes linguagens de programação ​​e diferentes tecnologias de armazenamento de dados são executadas em diferentes processos. O serviço adota um mecanismo de comunicação leve e um mecanismo de implantação automatizado para realizar comunicação, operação e manutenção." Além disso, o artigo lista nove características técnicas e comerciais essenciais dos microsserviços, que o autor lista e interpreta da seguinte forma:

1. Organizado em torno de Capacidades de Negócios (Organizado em torno de Capacidades de Negócios)
   aqui enfatiza mais uma vez a importância da Lei de Conway: uma equipe com qualquer estrutura, tamanho e capacidades produzirá produtos com estruturas, escalas e capacidades correspondentes . Esta conclusão não é uma coincidência encontrada por uma determinada equipa ou por uma determinada empresa, mas sim um resultado inevitável da evolução. Se as funções que deveriam pertencer ao mesmo produto forem divididas em equipes diferentes, ocorrerá inevitavelmente uma grande quantidade de comunicação e colaboração entre equipes. Cruzar os limites da equipe terá custos mais elevados em termos de gerenciamento, comunicação e organização de trabalho. equipe Será naturalmente melhorado.Quando a equipe e o produto estiverem ajustados e estabilizados, a equipe e o produto terão uma estrutura consistente.
2. Governança descentralizada (Governança Descentralizada)
   Isto é para expressar o significado de "cujo filho está no comando".A equipe de desenvolvimento correspondente ao serviço é diretamente responsável pela qualidade da operação do serviço, e também deve ter o poder de controlar todos os aspectos do serviço sem interferência externa, como escolher tecnologias heterogêneas com outros serviços para implementar seus próprios serviços. Há alguma margem de manobra para este ponto na prática. A maioria das empresas não usará Java para um serviço, Python para outro e Golang para o próximo. Elas geralmente unificam as linguagens convencionais e até têm uma pilha de tecnologia unificada ou plataformas de tecnologia proprietárias. . Os microsserviços não defendem nem se opõem a esse tipo de "unificação", desde que a equipe responsável por fornecer e manter a pilha de tecnologia básica tenha a consciência de que todas as partes confiam e deva estar mentalmente preparada para "muitas vezes ser acordada pelo despertador às 3 da manhã", ótimo. Os microsserviços enfatizam mais que quando a heterogeneidade técnica é realmente necessária, eles devem ter o direito de escolher "não uniformidade".Por exemplo, Node.js não deve ser forçado a desenvolver páginas de relatório, e Python deve ser capaz de escolher ao fazer inteligência artificial cálculos, etc. espere.
3. A razão pela qual a Componentização via Serviços
   enfatiza a construção de componentes através de "Serviço" em vez de "Biblioteca" é que a biblioteca de classes está estaticamente ligada ao programa em tempo de compilação. As funções são fornecidas através de chamadas locais, enquanto os serviços são componentes fora do processo que fornecer funções por meio de chamadas remotas. No artigo anterior analisamos que embora os serviços remotos tenham custos de invocação mais elevados, este é um preço necessário para trazer isolamento e autonomia aos componentes.
4. O pensamento de produto (produtos e não projetos)
   evita o desenvolvimento de software como um processo de melhoria e melhoria contínua. Por exemplo, a operação e a manutenção não devem ser consideradas como o trabalho da equipe de operação e manutenção, mas o desenvolvimento deve ser considerado como o trabalho da equipe de desenvolvimento. A equipe deve ser responsável por todo o ciclo de vida do produto de software. Os desenvolvedores devem não apenas saber como o software é desenvolvido, mas também saber como ele é desenvolvido. Como funciona, como os usuários dão feedback e como é realizado o trabalho de suporte pós-venda. Os usuários atendidos aqui podem não ser necessariamente usuários finais, mas podem também será outro serviço que consome esse serviço. No passado, sob a arquitetura monolítica, a escala do programa determinava que era impossível para todo o pessoal prestar atenção ao produto completo.Os membros da organização que tinham uma divisão detalhada de trabalho, como desenvolvimento, operação e manutenção, e suporte focado apenas no próprio trabalho, mas sob microsserviços, é aconselhável esperar que todos na equipe tenham pensamento de produto.
5. Os microsserviços de Gerenciamento Descentralizado de Dados (Gerenciamento Descentralizado de Dados)
   defendem claramente que os dados devem ser gerenciados, atualizados, mantidos e armazenados de forma descentralizada. Em um único serviço, cada módulo funcional de um sistema geralmente utiliza o mesmo banco de dados. É verdade que centralizado o armazenamento é inerentemente É mais fácil evitar problemas de consistência, mas a forma abstrata da mesma entidade de dados é muitas vezes diferente da perspectiva de diferentes serviços. Por exemplo, o livro no aplicativo Livraria concentra-se no preço no campo de vendas, na quantidade de estoque no campo de armazenamento e nas informações de introdução dos livros no campo de exibição de mercadorias. Se for usado como armazenamento centralizado, todos esses campos Todos devem ser modificados e mapeados para a mesma entidade, o que faz com que diferentes serviços possam afetar-se entre si e perder independência. Embora seja muito difícil lidar com o problema de consistência em um ambiente distribuído, o processamento tradicional de transações não pode ser usado para garanti-lo em muitos casos, mas o menor dos dois males, existem alguns custos necessários que vale a pena pagar.
6. Smart Endpoints e Dumb Pipes (Smart Endpoints e Dumb Pipes)
   Weak Pipes (Dumb Pipes) são quase diretamente opostos aos complexos mecanismos de comunicação de SOAP e ESB pelo nome. ESB pode lidar com processamento de codificação de mensagens, conversão de regras de negócios, etc.; BPM pode orquestrar centralmente os serviços de negócios corporativos; o SOAP tem dezenas de famílias de protocolos WS-* que lidam com uma série de tarefas, como transações, consistência, autenticação e autorização, e essas funções construídas em canais de comunicação podem ter alguns serviços em um determinado sistema. mas é um fardo imposto para mais serviços. Se um serviço precisar de uma das funções ou capacidades acima, ele deverá ser resolvido no próprio Endpoint do serviço, em vez de processamento completo no canal de comunicação. Os microsserviços defendem um método de comunicação simples e direto semelhante aos filtros Unix clássicos, e a comunicação RESTful é uma escolha mais adequada para microsserviços.
7. O design tolerante a falhas (Design for Failure)
   não busca mais ilusoriamente a estabilidade eterna dos serviços, mas aceita a realidade de que os serviços sempre darão errado.É necessário que no design de microsserviços haja um mecanismo automático para detecção rápida de falhas. dos serviços dos quais depende. Isole quando o erro persistir e reconecte quando o serviço for restaurado. Portanto, instalações como "disjuntores" não são componentes periféricos opcionais para microsserviços no ambiente de produção real, mas um ponto de suporte necessário.Se não houver um design tolerante a falhas, o sistema será facilmente danificado devido a uma ou duas avalanches. efeito provocado pelo colapso de um serviço é superado. Sistemas confiáveis ​​​​podem ser compostos inteiramente de serviços propensos a erros. Este é o maior valor dos microsserviços e também é o significado do título deste documento de código aberto "O Projeto Fenix".
8. Design Evolucionário (Design Evolutivo)
   O design tolerante a falhas admite que os serviços falharão, e o design evolutivo admite que os serviços serão obsoletos. Um serviço bem projetado deve poder ser descartado, em vez de ser desenvolvido por um longo tempo.Se existe um serviço insubstituível e insubstituível em um sistema, isso não significa quão importante é o serviço, mas um sistema O desempenho da fragilidade no design, a independência e autonomia trazidas pelos microsserviços, é também uma manifestação de oposição a esta fragilidade.
9. Automação de infraestrutura (automação de infraestrutura)
   A automação de infraestrutura, como o rápido desenvolvimento de CI/CD, reduziu significativamente a complexidade dos trabalhos de construção, liberação e operação e manutenção. Como o número de serviços a serem operados e mantidos aumenta em uma ordem de grandeza em comparação com a arquitetura monolítica, as equipes que utilizam microsserviços são mais dependentes da automação da infraestrutura, e é impossível para humanos operar e manter centenas de milhares ou mesmo milhares. de serviços.

A descrição das características dos microsserviços no artigo "Microsserviços" é bastante específica. Além de definir o que são microsserviços neste artigo, ele também declara especificamente o que os microsserviços não são - os microsserviços não são variantes ou derivados de SOA e devem ser claramente definido. Desenhe uma linha clara com SOA e não rotule mais nenhum SOA. Desta forma, o conceito de microsserviços pode ser considerado um estilo arquitetônico verdadeiramente completo, independente e específico, estabelecendo uma base teórica para que brilhe como uma estrela no cenário tecnológico nos próximos anos.

Microsserviços e SOA
Esta manifestação comum de SOA levou alguns defensores de microsserviços a rejeitar inteiramente o rótulo SOA, embora outros considerem os microsserviços como uma forma de SOA, talvez uma orientação de serviço bem feita. é valioso ter um termo que defina esse estilo de arquitetura de forma mais precisa.
Devido à sua expressão consistente com SOA, isso torna mais urgente que os defensores dos microsserviços se recusem a ser rotulados como SOA, embora algumas pessoas insistam que os microsserviços são a essência da SOA. ser verdade do lado orientado a serviços, mas em qualquer caso, SOA e microsserviços são duas coisas diferentes e, como tal, usar um nome diferente para definir concisamente esse estilo arquitetônico é ainda mais necessário.
- Martin Fowler/James Lewis, Microsserviços

A partir das definições e características dos microsserviços acima, pode-se sentir claramente que os microsserviços buscam um estilo arquitetônico mais livre, abandonando quase todas as restrições e regulamentações que podem ser descartadas na SOA e defendendo "padrões práticos" em vez de "padrões normativos". ". **No entanto, se não houver especificação e restrição unificadas, os problemas de serviços distribuídos resolvidos pela SOA não reapareceriam de repente? **Na verdade, descoberta de registro de serviço, governança de rastreamento, balanceamento de carga, isolamento de falhas, autenticação e autorização, escalonamento, transmissão e comunicação, processamento de transações, etc., esses problemas, não haverá mais uma solução unificada em microsserviços, mesmo que apenas Discuta os microsserviços que serão utilizados no escopo do Java. Apenas um problema de comunicação entre serviços pode ser incluído na lista de soluções candidatas: RMI (Sun/Oracle), Thrift (Facebook), gRPC (Google), Motan2 (Sina ), Finagle (Twitter), Arvo (Hadoop), JSON-RPC, REST, etc.; apenas um problema de descoberta de serviço, você pode escolher: Eureka (Netflix), Consul (HashiCorp), Zookeeper (Apache), Etcd (CoreOS) , CoreDNS (CNCF), etc. A situação noutros campos é semelhante a esta, em suma, é uma situação em que os Oito Imortais atravessam o mar e cada um mostra os seus poderes mágicos.

A liberdade trazida pelos microsserviços é uma faca de dois gumes. Quando os arquitetos de software empunham essa espada, uma ponta aponta para os complexos padrões técnicos definidos pela SOA e, no mesmo momento em que recuperam o poder de escolha, a outra ponta foi também refletindo uma luz fria para si. Na era dos microsserviços, deve-se dizer que a complexidade do desenvolvimento de software em si foi reduzida.Um serviço simples pode não enfrentar necessariamente todos os problemas distribuídos ao mesmo tempo, e não há necessidade de carregar o pesado saco de tesouros de SOA .Bagagem técnica. Seja qual for o problema que precisa ser resolvido, introduza qualquer ferramenta; seja qual for a tecnologia com a qual a equipe esteja familiarizada, use qualquer estrutura. Além disso, um conjunto de ferramentas familiares estilo cola, como Spring Cloud, protege ainda mais a complexidade de ferramentas e estruturas específicas por meio de interfaces, declarações e configurações consistentes, reduzindo o custo de alternar entre diferentes ferramentas e estruturas. como um programador "parafuso", a arquitetura de microsserviços é amigável. No entanto, os microsserviços são cheios de malícia para os arquitetos, e os requisitos para capacidades arquitetônicas foram elevados a um nível sem precedentes. O autor enfatizou repetidamente em muitos lugares deste documento que a primeira responsabilidade dos arquitetos técnicos é tomar decisões. é necessário para as desvantagens, e os trade-offs são necessários para os trade-offs. Se o conhecimento do próprio arquiteto não for suficiente para cobrir o conteúdo da tomada de decisão necessária, e ele não tiver clareza sobre os prós e os contras, ele poderá inevitavelmente cair no dilema das dificuldades de escolha.

A era dos microsserviços é cheia de liberdade e a era dos microsserviços é cheia de escolhas confusas. A arquitetura de software não vai parar na liberdade, e os microsserviços ainda não são o fim da exploração da arquitetura.Se houver uma próxima era, espero que os sistemas de informação possam ter a liberdade dos microsserviços ao mesmo tempo e construir seus próprios serviços em torno das capacidades de negócios sem ser restringido por especificações técnicas. Mas, ao mesmo tempo, isso não precisa ser feito às custas de você mesmo assumir a responsabilidade pela solução de problemas distribuídos. Quem se importa com suas compensações! As crianças só fazem questões de múltipla escolha, mas todos os adultos fazem!

era pós-microsserviço

Na arquitetura de microsserviços, haverá alguns problemas que deverão ser resolvidos, como descoberta de registros, gerenciamento de rastreamento, balanceamento de carga, comunicação de transmissão, etc. Mas esses problemas sempre existiram na era distribuída original. Qual é a solução mais comum:

• Se um sistema precisa ser dimensionado e expandido , normalmente adquirimos novos servidores e implantamos vários conjuntos de instâncias de réplica para compartilhar a pressão;
• Se um sistema precisa resolver o problema de balanceamento de carga , geralmente organizamos um balanceador de carga e escolhemos um algoritmo de balanceamento apropriado para desviar o tráfego;
• Se for necessário resolver o problema de transmissão segura , geralmente organizamos um link de transmissão TLS e configuramos um certificado CA para garantir que a comunicação não será interceptada e adulterada;
• Se precisarmos resolver o problema de descoberta de serviço , geralmente configuramos o servidor DNS para que o acesso ao serviço dependa de nomes de registro estáveis ​​em vez de endereços IP voláteis;
• … …

Na era dos microsserviços, a razão pela qual temos que resolver esses problemas distribuídos no nível do serviço de aplicação, e não no nível da infraestrutura, é inteiramente porque a infraestrutura composta por hardware não consegue acompanhar a flexibilidade dos serviços de aplicação compostos por software .

A solução para problemas como descoberta de registro, governança de rastreamento, etc., depende da tecnologia de virtualização e da tecnologia de conteinerização. As conquistas na era dos microsserviços são inseparáveis ​​das grandes contribuições das primeiras tecnologias de conteinerização representadas pelo Docker .

guerras de contêineres

O contêiner inicial era simplesmente considerado um ambiente operacional de serviço de início rápido, e o objetivo de usá-lo era facilitar a distribuição e implantação de programas. Portanto, o contêiner para um único serviço na fase inicial não participava realmente da solução dos problemas distribuídos.

2017 pode ser considerado um ano marcante na história do desenvolvimento ecológico de contêineres.

Docker Swarm, Apache Mesos e Kubernetes são os principais concorrentes na “guerra de contêineres”. O Kubernetes finalmente se destacou de muitos sistemas de gerenciamento de containers e “coroado”, o que representou o fim de uma era no desenvolvimento de containers. E posso dizer que a infraestrutura virtualizada que ela traz, como redes entre contêineres, serviços, balanceamento de carga e configuração, também será a chave para a próxima era de desenvolvimento de arquitetura de software.

Para o mesmo problema de serviço distribuído, compare as soluções em nível de aplicativo fornecidas pelo Spring Cloud e as soluções em nível de infraestrutura fornecidas pelo Kubernetes. Embora os pontos de partida do Spring Cloud e do Kubernetes sejam diferentes, e os métodos e efeitos de resolução de problemas também sejam diferentes, o Kubernetes fornece uma ideia nova e mais promissora de resolução de problemas.

Quando a infraestrutura virtualizada começa a evoluir de um único contêiner de serviço para um cluster de serviços composto por vários contêineres, bem como todos os recursos de comunicação e armazenamento exigidos pelo cluster, as fronteiras entre software e hardware começam a se confundir.

Uma vez que o hardware consiga acompanhar a flexibilidade do software, então esses problemas técnicos que não têm nada a ver com o negócio provavelmente serão separados do nível do software e resolvidos silenciosamente dentro da infraestrutura de hardware, permitindo que o software se concentre apenas no nível do software. negócios, verdadeiramente "construir equipes e produtos em torno das capacidades de negócios". Portanto, o problema da arquitetura distribuída só pode ser resolvido no nível do software, então há outra solução: o código do aplicativo e o software e hardware da infraestrutura são integrados e trabalham juntos para lidar com isso.

Com isso, chegamos à era do “nativo da nuvem”, frequentemente mencionado em artigos da mídia.

O Kubernetes se tornou o vencedor da guerra dos contêineres, marcando o início da era pós-microsserviço, mas o Kubernetes não resolve todos os problemas distribuídos perfeitamente .

Do ponto de vista de funções flexíveis e poderosas, o Kubernetes não é tão bom quanto a solução Spring Cloud anterior. Isso ocorre porque alguns problemas estão no limite do sistema e da infraestrutura de aplicativos, e é difícil para nós resolvê-los completamente no nível da infraestrutura.

Por exemplo, o microsserviço A chama dois serviços publicados no microsserviço B, nós os chamamos de B1 e B2, assumindo que B1 se comporta normalmente, mas B2 tem um erro contínuo de 500, após um certo limite, B2 deve ser fundido para evitar um efeito avalanche .

Na verdade, esse tipo de problema não é difícil de lidar em microsserviços implementados por código de aplicativo como Spring Cloud. De qualquer forma, o código (ou configuração) é usado para resolver o problema. Desde que seja lógico, qualquer função pode ser usada, mas será limitada a imaginação e capacidade técnica do desenvolvedor. No entanto, a infra-estrutura é gerida como um todo para todo o contentor e a sua resistência é relativamente difícil. Na verdade, situações semelhantes não ocorrem apenas em disjuntores: serviços como monitoramento, autenticação, autorização, segurança e balanceamento de carga exigem gerenciamento detalhado. Por exemplo, o balanceamento de carga durante a chamada de serviço muitas vezes precisa ajustar o nível e o algoritmo de balanceamento de carga com base nas características do tráfego. Embora o DNS possa atingir um certo grau de balanceamento de carga, geralmente não consegue atender a esses requisitos adicionais.

Para resolver este tipo de problema, a infraestrutura de microsserviços rapidamente passou por uma segunda evolução, introduzindo o “Sidecar Proxy” (Sidecar Proxy) que hoje chamamos de “Service Mesh ” .

Especificamente em nosso contexto atual, “sidecar” significa que a infraestrutura de microsserviços injetará automaticamente um servidor proxy de comunicação (equivalente ao sidecar) no contêiner de recursos do serviço (referente ao Pod do Kubernetes) pelo sistema, usando um método semelhante ao ataque man-in-the-middle na segurança da rede para sequestrar o tráfego e assumir silenciosamente todas as comunicações externas do aplicativo sem que o aplicativo perceba.

Além de implementar chamadas de serviço normais (chamadas de comunicação de plano de dados), este agente também aceita instruções do controlador (chamadas de comunicação de plano de controle) e analisa o conteúdo da comunicação de plano de dados de acordo com a configuração no plano de controle para alcançar várias funções adicionais. como fusível, autenticação, medição, monitoramento, balanceamento de carga, etc.

Dessa forma, ele atinge o objetivo de não exigir código adicional no nível do aplicativo, mas também de fornecer recursos de gerenciamento precisos que são quase tão bons quanto o código do aplicativo.

Embora seja difícil para nós determinar conceitualmente se um serviço de proxy executado no mesmo contêiner de recursos que o sistema de aplicação deve ser considerado software ou infraestrutura, desde que seja transparente para a aplicação, não há necessidade de alterar qualquer código de software. pode alcançar a governança de serviços, e isso é suficiente.

sem era de serviço

Finalmente, vamos falar sobre a “arquitetura sem servidor” que só surgiu nos últimos um ou dois anos. Na indústria, em 2012, a iron.io assumiu a liderança ao propor o conceito de “serverless” (Serverless, que deveria ser traduzido como “serverless”, mas agora se tornou um hábito usar “serviceless”); desde 2014, AWS lançou um aplicativo comercial sem servidor chamado Lambda, que foi gradualmente reconhecido pelos desenvolvedores nos anos seguintes e desenvolvido na maior plataforma operacional sem servidor do mundo; em 2019, o Alibaba Cloud da China, fornecedores como Tencent Cloud também lançaram produtos sem serviços. "Sem serviço" tornou-se uma das "novas celebridades da Internet" no recente círculo tecnológico.

O pano de fundo da evolução da arquitetura sem servidor também está evoluindo através de vários estágios, conforme mencionado acima. O desenvolvimento de computadores também passou por mainframes, minicomputadores, PCs, máquinas virtuais e servidores em nuvem (a maioria dos servidores em nuvem também são máquinas virtuais)

Na era da computação em nuvem, os fornecedores de serviços em nuvem fornecem recursos IaaS, PaaS e SaaS para realizar hospedagem gratuita e recursos prontos para uso, de hardware a software.

A arquitetura sem servidor não é tão complicada quanto a arquitetura de microsserviços e a arquitetura SOA. Sua maior característica é a simplicidade. Apenas as instalações de backend (Backend) e funções (Function) estão envolvidas.

BaaS (Backend como serviço, backend como serviço)

Os recursos de back-end referem-se a bancos de dados, filas de mensagens, logs, armazenamento, etc., que são usados ​​para dar suporte à operação da lógica de negócios, mas não têm significado comercial. Esses recursos de back-end estão todos rodando na nuvem. É " Backend como serviço" (Backend como serviço, BaaS).

FaaS (Função como Serviço, função como serviço)

Funções referem-se a códigos de lógica de negócios. O conceito e a granularidade das funções aqui já estão muito próximos das funções do ponto de vista da codificação do programa. A diferença é que as funções sem serviço são executadas na nuvem sem considerar o poder de computação ou o planejamento de capacidade (de Você pode ignorá-lo do ponto de vista técnico, mas ainda precisa pesá-lo do ponto de vista do faturamento), e é chamado de "Função como Serviço" (Função como Serviço, FaaS) em sem serviço.

A visão do serverless é permitir que os desenvolvedores se concentrem exclusivamente nos negócios .

1. Não há necessidade de considerar componentes técnicos, sem problemas de compra, direitos autorais e seleção de modelo;
2. Não há necessidade de considerar como implantar, o processo de implantação é totalmente hospedado na nuvem e concluído automaticamente pela nuvem;
3. Não há necessidade de considerar o poder computacional, com o suporte de todo o data center, o poder computacional pode ser considerado ilimitado;
4. Não há necessidade de se preocupar com o sabor, é responsabilidade do provedor de serviços em nuvem manter a operação contínua e estável do sistema;

Diferente da arquitetura monolítica e da arquitetura de microsserviços, algumas características inerentes à arquitetura sem servidor, como inicialização a frio, sem estado, tempo de execução limitado, etc., determinam que não é um modelo arquitetônico universal.

Se a arquitetura de microsserviços é o objetivo final do sistema distribuído, então a arquitetura sem servidor pode ser o ponto de partida do sistema de nuvem “não distribuído”.

Só podemos ver uma curta distância à frente, mas podemos ver muito que precisa ser feito.
– Alan Mathison Turing, Computing Machinery and Intelligence, 1950 – Turing, Máquinas de Computação e Inteligência, 1950

IaaS/PaaS/SaaS

As definições de IaaS, PaaS e SaaS na arquitetura sem servidor são as seguintes,

Infraestrutura como serviço IaaS (Infraestrutura como Serviço)

Fornecer a infraestrutura de computação (servidores, tecnologia de rede, armazenamento e espaço de data center) como um serviço aos clientes. Também inclui o fornecimento de sistemas operacionais e tecnologias de virtualização para gerenciar recursos. Os consumidores podem obter serviços de uma infra-estrutura informática bem estabelecida através da Internet.

vantagem:

• Não há necessidade de se preocupar com o princípio subjacente da estrutura de hardware;
• Dimensione a infraestrutura sob demanda para suportar cargas de trabalho em constante mudança;
• Serviços flexíveis, inovadores e sob demanda.

PaaS (Plataforma como serviço) plataforma como serviço

Os provedores de plataforma como serviço hospedam hardware e software em sua própria infraestrutura e entregam essa plataforma aos usuários por meio de uma conexão com a Internet como uma solução integrada, pilha de soluções ou serviço.

Voltada principalmente para desenvolvedores e programadores, a PaaS permite que os usuários desenvolvam, executem e gerenciem seus próprios aplicativos sem a necessidade de construir e manter a infraestrutura normalmente associada ao processo.

Os desenvolvedores simplesmente escrevem código, criam e gerenciam aplicativos sem o incômodo de atualizações de software ou manutenção de hardware. O sistema fornecerá um ambiente de construção e implantação.

vantagem:

• Desenvolva aplicativos e entregue-os com mais rapidez;
• Implante novos aplicativos web na nuvem em minutos;
• Reduza a complexidade com middleware como serviço.

SaaS (software como serviço) software como serviço

Software como serviço fornece um produto completo que é executado e gerenciado pelo provedor de serviços. O que as pessoas costumam chamar de software como serviço são os aplicativos de usuário final. Ao usar produtos SaaS, os usuários não precisam se preocupar com a manutenção dos serviços e o gerenciamento da infraestrutura subjacente. Os usuários só precisam considerar como usar o software SaaS.

vantagem:

• Aplicativos de negócios inovadores podem ser registrados e usados ​​rapidamente;
• Aplicativos e dados podem ser acessados ​​em qualquer computador conectado;
• Os dados ficam na nuvem e não serão perdidos caso o computador falhe;
• Este serviço pode ser expandido dinamicamente de acordo com as necessidades de utilização.

a diferença entre os três