No mundo da moda, onde as tendências mudam como uma lanterna giratória, haverá um estilo retrô a cada poucos anos. O famoso estilista Andre Leon Talley, conhecido como o "Padrinho da Moda", disse uma vez: "A moda está sempre em busca de novas inspirações e direções, e o retrô é uma das fontes importantes".
Coincidentemente. No campo de alta tecnologia em constante mudança, também haverá um ressurgimento de tecnologias reconhecidamente "desatualizadas", que provocarão ondas na indústria não menos que avanços em tecnologias emergentes. Recentemente, o "contra-ataque" de aplicações monolíticas a microsserviços tem atraído muita atenção.
As últimas "notícias explosivas" são bastante atraentes: uma equipe de projeto de uma conhecida empresa de streaming de mídia divulgou um estudo de caso: "Eles abandonaram a arquitetura sem servidor e de microsserviços e a substituíram por um único aplicativo, o que economizou 90% dos clientes operacionais custos e melhorar a experiência do usuário".
A primeira estratégia sem servidor é reconhecida como a direção futura, e há muitas práticas no campo da arquitetura orientada a eventos (EDA) e microsserviços no setor. Do ponto de vista da lógica básica de negócios, é difícil para nós retornar à era dos aplicativos monolíticos, então qual é o significado profundo por trás disso?
É aconselhável primeiro restaurar o processo de seleção de solução da equipe em um cenário específico e, em seguida, classificar a trajetória de desenvolvimento de aplicativos monolíticos para SOA para microsserviços e, finalmente, fazer um julgamento sobre a direção da evolução da arquitetura evolutiva que pode resistir ao teste de tempo.
Interesses do cliente em primeiro lugar: explore o caminho ideal "lutando para a esquerda e para a direita"
Ao restaurar o processo de seleção de soluções de computação distribuída e de aplicativo único no caso de serviços de streaming de mídia, podemos não apenas ver sua adesão ao conceito de "interesses do cliente em primeiro lugar", mas também descobrir que a capacidade da Amazon Cloud Technology de se adaptar a diversas necessidades é o seu "ousar" Lutar a torto e a direito".
No projeto inicial da solução, um sistema distribuído com componentes sem servidor costuma ser uma boa opção para a criação rápida de serviços. No entanto, na operação real, a arquitetura encontra um gargalo de dimensionamento - o fluxo de trabalho executa várias transições de estado a cada segundo, que logo atinge o limite superior da Conta, e cobranças são cobradas para cada transição de estado.
A questão do custo não para por aí. Para reduzir o dispendioso trabalho de conversão de vídeo, a equipe do projeto criou um microsserviço que divide o vídeo em quadros e carrega imagens temporárias em um sistema de armazenamento antes de baixar e processar as imagens usando serviços relacionados. No entanto, os encargos para serviços de armazenamento e invocação ainda não são baixos e o cálculo geral ainda é difícil de atender às expectativas.
Esta estrada está bloqueada, então por que não encontrar outro caminho? As empresas de streaming tomaram a ousada decisão de agrupar todos os componentes em um único processo. Isso elimina a necessidade de armazenamento intermediário de quadros de vídeo, a transferência de dados é feita na memória e componentes como conversão de mídia, detectores e orquestração são executados em uma única tarefa do Amazon ECS.
Vale ressaltar que na nova arquitetura, o número de detectores só pode ser expandido verticalmente, e a equipe de projeto precisa adicionar mais detectores ao serviço regularmente, o que coloca muita pressão na capacidade de uma única instância . Para resolver isso, a equipe usa um subconjunto diferente de detectores para parametrizar cada réplica e distribuir as solicitações do cliente com uma camada de orquestração leve.
O valor central deste caso é quebrar o "culto da fé" dos microsserviços e afirmar que a arquitetura monolítica pode atender a alguns requisitos de aplicativos. No entanto, se tirarmos a conclusão de que a arquitetura monolítica será totalmente "restaurada", é um pouco exagero.
Na verdade, não há certo ou errado simples para escolher um caminho com base em um cenário específico. Se um cliente está disposto a adotar uma arquitetura monolítica ou uma solução de microsserviço depende de vários fatores, como definição de metas, recursos existentes e condições da equipe O ajuste de algumas variáveis pode levar a uma mudança na escolha. Por exemplo, se a granularidade da segmentação de vídeo em quadros no projeto não for muito fina, a frequência das transições de estado será significativamente reduzida, o custo das chamadas de armazenamento também se tornará razoável e espera-se que as vantagens da solução de microsserviço sejam novamente destacado.
Não se desvie do canal principal: Serverless e EDA impulsionam a evolução contínua dos microsserviços
O julgamento racional é inseparável da análise comparativa baseada em experimentos e também vem de uma visão profunda das leis do desenvolvimento. Somente examinando as trajetórias de evolução de diferentes arquiteturas no longo rio da história podemos entender melhor o processo de evolução de aplicativos monolíticos para arquitetura orientada a serviços (SOA) e depois para microsserviços, para não cair na armadilha do relativismo ou niilismo armadilha.
O software na "era antiga" escrevia todas as funções juntas, e todo o software parecia ser uma máquina integrada, daí o nome da arquitetura monolítica. Com o aumento das funções do software, a arquitetura monolítica tornou-se cada vez mais complexa e muitas deficiências foram expostas.
A velocidade de desenvolvimento de grandes aplicativos monolíticos é lenta. Ao implantar e executar, o servidor precisa ter memória suficiente e recursos relacionados, e o aplicativo deve ser replicado em vários servidores para alcançar a expansão horizontal. A capacidade de expansão é obviamente limitada; ao mesmo tempo, esses aplicativos Os vários componentes funcionais do programa estão fortemente acoplados, tornando bastante difícil a manutenção e atualização.
Para enfrentar os desafios acima, é necessário alterar o estado fortemente acoplado do código e dividir o software em unidades funcionais, e a "Arquitetura Orientada a Serviços" (SOA) surgiu. Na arquitetura SOA, cada serviço assume de forma independente suas próprias funções, e os serviços são interligados por meio de protocolos de comunicação, podendo cada serviço ser desenvolvido em diferentes linguagens e ferramentas, podendo ser implantado em um ambiente de sistema diferenciado.
No contexto da nuvem redefinindo tudo, o rápido ataque da tendência de conteinerização tornou possível o SOA mais leve, e os microsserviços gradualmente ocuparam a "posição C". Em um ambiente de contêiner, cada serviço não precisa ocupar um servidor e vários contêineres podem ser executados em um servidor, e até mesmo a evolução sem servidor pode ser alcançada com o suporte da arquitetura Serverless. Os usuários não precisam gastar tempo e energia com manutenção e atualizações de infraestrutura e podem se concentrar mais na lógica de negócios.
Se o Serverless pressionou a tecla de movimento rápido para a evolução dos microsserviços, a arquitetura orientada a eventos (EDA) é a arma definitiva para os microsserviços se adaptarem a ambientes incertos.
O EDA permite que cada módulo na arquitetura seja executado de forma flexível na ordem dos eventos e pode usar o resultado da execução como um novo evento para conduzir a operação do próximo módulo. O relatório "Top Ten Strategic Technology Trends" do Gartner mostra que, até 2022, mais de 50% das organizações participarão do ecossistema de serviços digitais orientado a eventos, e a EDA será a principal força motriz para o crescimento futuro dos microsserviços.
Obviamente, com a sinergia de Serverless e EDA, os microsserviços se tornaram o principal canal na área de águas profundas da transformação digital. Embora os aplicativos monolíticos também tenham valor indispensável em cenários específicos, a julgar pela lógica subjacente e pelos requisitos práticos da evolução da arquitetura do aplicativo, é impossível para eles substituir a posição dominante dos microsserviços.
Arquitetura sob demanda: guia baseado em cenários e evolutivo para a direção futura
De uma perspectiva de longo prazo, a atualização iterativa da arquitetura do aplicativo é infinita. Com a generalização da inteligência artificial e a aceleração do processo de elementos de produção de dados, as plataformas de computação em nuvem precisam fornecer a vários tipos de empresas soluções de arquitetura de aplicativos sob demanda e de múltipla escolha. arquiteturas.
Como líder no mercado global de serviços em nuvem, a Amazon Cloud Technology sempre desempenhou um papel de liderança na mudança. Por meio da inovação contínua de produtos e serviços, oferece aos clientes de vários setores opções de arquitetura que atendem às características de diferentes cenários. Tome o Amazon S3 como exemplo: de alguns microsserviços lançados em 2006 para mais de 300 microsserviços posteriormente, ele continua a melhorar em dimensões como métodos de armazenamento e mecanismos de política e cresce junto com os clientes.
Na área de Serverless e EDA, que ajudam a ampliar o “canal principal”, a tecnologia de nuvem da Amazon é a primeira a dar o exemplo. O Amazon Lambda, lançado em 2014, soou o chamado para a popularização do modelo de computação sem servidor. integração de pilha; ao mesmo tempo, a tecnologia de nuvem da Amazon construiu um O sistema de serviço completo da arquitetura orientada a eventos, incluindo Amazon EventBridge, Amazon Step Functions, etc., não apenas melhora a agilidade de desenvolvimento e economiza custos, mas também atende melhor aos necessidades de cenários de aplicativos corporativos por meio da combinação gratuita desses serviços e maximiza as vantagens da arquitetura.
Em 2023, a Amazon Cloud Technology inovará e explicará o conceito "Primeiro sem servidor" e manterá a bandeira de promover a modernização de aplicativos. No auge da rapidez, o "Serverless first" defendido pela Amazon Cloud Technology não é igual a "Serverless only". A escolha do caminho da arquitetura não pode ser separada das reais demandas e condições reais dos clientes. A premissa de ter um futuro é viver no presente.
Como disse Russell, a diversidade é a fonte da felicidade. É natural que uma empresa iniciante com um negócio simples e apenas alguns desenvolvedores escolha uma arquitetura de aplicativo diferente de uma empresa de grande e médio porte com muitas filiais e dezenas de engenheiros. Você pode saber onde está o alvo quando sobe alto e olha para longe, mas não se esqueça da terra sob seus pés.