Os componentes de arquitetura de uma aplicação podem ser categorizados como frontend ou backend. Em alguns cenários, estes componentes podem ser alojados para funcionar a partir de diferentes ambientes de computação. Como parte do padrão de arquitetura híbrida hierárquica, os ambientes de computação estão localizados num ambiente de computação privado no local e em Google Cloud.
Os componentes da aplicação de front-end são expostos diretamente aos utilizadores finais ou aos dispositivos. Como resultado, estas aplicações são frequentemente sensíveis ao desempenho. Para desenvolver novas funcionalidades e melhorias, as atualizações de software podem ser frequentes. Uma vez que as aplicações de frontend dependem normalmente de aplicações de backend para armazenar e gerir dados, e possivelmente lógica empresarial e tratamento de introdução do utilizador, são frequentemente sem estado ou gerem apenas volumes limitados de dados.
Para serem acessíveis e utilizáveis, pode criar as suas aplicações de front-end com várias frameworks e tecnologias. Alguns fatores importantes para uma aplicação de frontend bem-sucedida incluem o desempenho da aplicação, a velocidade de resposta e a compatibilidade com o navegador.
Normalmente, os componentes da aplicação de back-end focam-se no armazenamento e na gestão de dados. Em algumas arquiteturas, a lógica de negócio pode ser incorporada no componente de back-end. As novas versões das aplicações de back-end tendem a ser menos frequentes do que as versões das aplicações de front-end. As aplicações de back-end têm os seguintes desafios de gestão:
- Processar um grande volume de pedidos
- Processar um grande volume de dados
- Proteger os dados
- Manter os dados atuais e atualizados em todas as réplicas do sistema
A solução de app Web de três camadas é uma das implementações mais populares para criar aplicações Web empresariais, como Websites de comércio eletrónico que contêm diferentes componentes de aplicações. Esta arquitetura contém os seguintes níveis. Cada nível funciona de forma independente, mas estão estreitamente ligados e funcionam todos em conjunto.
- Nível de apresentação e front-end da Web
- Nível de aplicação
- Acesso aos dados ou camada de back-end
Colocar estas camadas em contentores separa as respetivas necessidades técnicas, como os requisitos de escalabilidade, e ajuda a migrá-las de forma faseada. Além disso, permite-lhe implementá-los em serviços na nuvem independentes da plataforma que podem ser portáteis em vários ambientes, usar a gestão automatizada e dimensionar com plataformas geridas na nuvem, como o Cloud Run ou a edição Enterprise do Google Kubernetes Engine (GKE). Além disso, as bases de dados geridas, como o Cloud SQL, ajudam a fornecer o back-end como a camada de base de dados.Google Cloud
O padrão de arquitetura híbrida em camadas foca-se na implementação de componentes de aplicações de front-end existentes na nuvem pública. Neste padrão, mantém todos os componentes da aplicação de back-end existentes no respetivo ambiente de computação privado. Consoante a escala e o design específico da aplicação, pode migrar os componentes da aplicação de front-end caso a caso. Para mais informações, consulte Migrar para Google Cloud.
Se tiver uma aplicação existente com componentes de back-end e front-end alojados no seu ambiente no local, considere os limites da sua arquitetura atual. Por exemplo, à medida que a sua aplicação é dimensionada e as exigências sobre o respetivo desempenho e fiabilidade aumentam, deve começar a avaliar se as partes da sua aplicação devem ser refatoradas ou movidas para uma arquitetura diferente e mais otimizada. O padrão de arquitetura híbrido hierárquico permite-lhe transferir algumas cargas de trabalho e componentes da aplicação para a nuvem antes de fazer uma transição completa. Também é essencial considerar o custo, o tempo e o risco envolvidos numa migração deste tipo.
O diagrama seguinte mostra um padrão de arquitetura híbrido hierárquico típico.
No diagrama anterior, os pedidos do cliente são enviados para o frontend da aplicação que está alojado em Google Cloud. Por sua vez, o front-end da aplicação envia dados de volta para o ambiente no local onde o back-end da aplicação está alojado (idealmente através de um gateway de API).
Com o padrão de arquitetura híbrido hierárquico, pode tirar partido da Google Cloud infraestrutura e dos serviços globais, conforme mostrado na arquitetura de exemplo no diagrama seguinte. O front-end da aplicação pode ser acedido através de Google Cloud. Também pode adicionar elasticidade ao front-end através do ajuste de escala automático para responder de forma dinâmica e eficiente à procura de ajuste de escala sem aprovisionar em excesso a infraestrutura. Existem diferentes arquiteturas que pode usar para criar e executar apps Web escaláveis no Google Cloud. Cada arquitetura tem vantagens e desvantagens para diferentes requisitos.
Para mais informações, veja o vídeo Três formas de executar apps Web escaláveis no Google Cloud YouTube. Para saber mais sobre as diferentes formas de modernizar a sua plataforma de comércio eletrónico no Google Cloud, consulte o artigo Como criar uma plataforma de comércio digital no Google Cloud.
No diagrama anterior, o front-end da aplicação está alojado no Google Cloud para oferecer uma experiência do utilizador multirregional e otimizada a nível global que usa o equilíbrio de carga, o dimensionamento automático e a proteção contra DDoS através do Google Cloud Armor.
Ao longo do tempo, o número de aplicações que implementa na nuvem pública pode aumentar até ao ponto em que pode considerar mover os componentes da aplicação de back-end para a nuvem pública. Se espera publicar um tráfego elevado, optar por serviços geridos na nuvem pode ajudar a poupar esforços de engenharia na gestão da sua própria infraestrutura. Considere esta opção, a menos que as restrições ou os requisitos exijam a alojamento de componentes da aplicação de back-end no local. Por exemplo, se os dados de back-end estiverem sujeitos a restrições regulamentares, é provável que tenha de manter esses dados no local. No entanto, quando aplicável e em conformidade, a utilização de capacidades de proteção de dados confidenciais, como técnicas de desidentificação, pode ajudar a mover esses dados quando necessário.
No padrão de arquitetura híbrida hierárquica, também pode usar o Google Distributed Cloud em alguns cenários. A nuvem distribuída permite-lhe executar clusters do Google Kubernetes Engine em hardware dedicado fornecido e mantido pela Google e separado do Google Cloud centro de dados. Para garantir que o Distributed Cloud cumpre os seus requisitos atuais e futuros, conheça as limitações do Distributed Cloud em comparação com uma zona do GKE convencional baseada na nuvem.
Vantagens
Focar-se primeiro nas aplicações de front-end tem várias vantagens, incluindo as seguintes:
- Os componentes de front-end dependem dos recursos de back-end e, ocasionalmente, de outros componentes de front-end.
- Os componentes de back-end não dependem dos componentes de front-end. Por conseguinte, o isolamento e a migração de aplicações de front-end tendem a ser menos complexos do que a migração de aplicações de back-end.
- Como as aplicações de front-end são frequentemente sem estado ou não gerem dados por si próprias, tendem a ser menos difíceis de migrar do que os back-ends.
- Os componentes de front-end podem ser otimizados como parte da migração para usar a arquitetura sem estado. Para mais informações, veja o vídeo Como portar apps Web com estado para o Cloud Run no YouTube.
A implementação de aplicações de front-end existentes ou recentemente desenvolvidas na nuvem pública oferece várias vantagens:
- Muitas aplicações de front-end estão sujeitas a alterações frequentes. A execução destas aplicações na nuvem pública simplifica a configuração de um processo de integração contínua/implementação contínua (CI/CD). Pode usar a CI/CD para enviar atualizações de forma eficiente e automática. Para mais informações, consulte CI/CD no Google Cloud.
- Os front-ends sensíveis ao desempenho com carga de tráfego variável podem beneficiar substancialmente do equilíbrio de carga, das implementações multirregionais, da colocação em cache do Cloud CDN, das capacidades sem servidor e de escalamento automático que uma implementação baseada na nuvem permite (idealmente com uma arquitetura sem estado).
A adoção de microsserviços com contentores através de uma plataforma gerida na nuvem, como o GKE, permite-lhe usar arquiteturas modernas, como o microfrontend, que estendem os microsserviços aos componentes de front-end.
A extensão de microsserviços é usada frequentemente com interfaces que envolvem várias equipas a colaborar na mesma aplicação. Este tipo de estrutura de equipa requer uma abordagem iterativa e manutenção contínua. Seguem-se algumas das vantagens de usar microfrontends:
- Pode ser transformado em módulos de microserviços independentes para desenvolvimento, testes e implementação.
- Oferece separação, em que as equipas de desenvolvimento individuais podem selecionar as suas tecnologias e código preferidos.
- Pode fomentar ciclos rápidos de desenvolvimento e implementação sem afetar os restantes componentes de front-end que podem ser geridos por outras equipas.
Quer estejam a implementar interfaces do utilizador ou APIs, ou a processar a introdução de dados da Internet das Coisas (IoT), as aplicações de front-end podem beneficiar das capacidades dos serviços na nuvem, como o Firebase, o Pub/Sub, o Apigee, o Cloud CDN, o App Engine ou o Cloud Run.
Os proxies de API geridos na nuvem ajudam a:
- Desacople a API virada para a app dos seus serviços de back-end, como os microsserviços.
- Proteja as apps contra alterações ao código de back-end.
- Suporte as suas arquiteturas de front-end existentes baseadas em APIs, como back-end para front-end (BFF), micro front-end e outras.
- Exponha as suas APIs no Google Cloud ou noutros ambientes através da implementação de proxies de API no Apigee.
Também pode aplicar o padrão híbrido em camadas de forma inversa, implementando back-ends na nuvem e mantendo os front-ends em ambientes de computação privados. Embora seja menos comum, esta abordagem é melhor aplicada quando está a lidar com um frontend pesado e monolítico. Nestes casos, pode ser mais fácil extrair a funcionalidade de back-end de forma iterativa e implementar estes novos back-ends na nuvem.
A terceira parte desta série aborda possíveis padrões de rede para ativar essa arquitetura. O Apigee Hybrid ajuda como plataforma para criar e gerir proxies de API num modelo de implementação híbrido. Para mais informações, consulte o artigo Arquitetura com acoplamento fraco, incluindo arquiteturas hierárquicas monolíticas e de microsserviços.
Práticas recomendadas
Use as informações nesta secção ao planear a sua arquitetura híbrida hierárquica.
Práticas recomendadas para reduzir a complexidade
Quando aplica o padrão de arquitetura híbrido hierárquico, considere as seguintes práticas recomendadas que podem ajudar a reduzir a complexidade geral de implementação e operacional:
- Com base na avaliação dos modelos de comunicação das aplicações identificadas, selecione a solução de comunicação mais eficiente e eficaz para essas aplicações.
Uma vez que a maioria das interações dos utilizadores envolve sistemas que se ligam em vários ambientes de computação, a conetividade rápida e de baixa latência entre esses sistemas é importante. Para cumprir as expetativas de disponibilidade e desempenho, deve criar em função da alta disponibilidade, da baixa latência e dos níveis de débito adequados. Do ponto de vista da segurança, a comunicação tem de ser detalhada e controlada. Idealmente, deve expor os componentes da aplicação através de APIs seguras. Para mais informações, consulte o artigo Saída controlada.
- Para minimizar a latência de comunicação entre ambientes, selecione uma Google Cloud região geograficamente próxima do ambiente de computação privado onde os componentes de back-end da sua aplicação estão alojados. Para mais informações, consulte o artigo Práticas recomendadas para a seleção de regiões do Compute Engine.
- Minimize as dependências elevadas entre sistemas que estão a ser executados em ambientes diferentes, especialmente quando a comunicação é processada de forma síncrona. Estas dependências podem abrandar o desempenho, diminuir a disponibilidade geral e, potencialmente, incorrer em custos adicionais de transferência de dados de saída.
- Com o padrão de arquitetura híbrido em camadas, pode ter volumes maiores de tráfego de entrada de ambientes no local que entram noGoogle Cloud em comparação com o tráfego de saída que sai Google Cloud. No entanto, deve conhecer o volume de transferência de dados de saída previsto Google Cloud. Se planeia usar esta arquitetura a longo prazo com volumes elevados de transferência de dados de saída, considere usar o Cloud Interconnect. O Cloud Interconnect pode ajudar a otimizar o desempenho da conetividade e pode reduzir os custos de transferência de dados de saída para o tráfego que cumpre determinadas condições. Para mais informações, consulte os preços do Cloud Interconnect.
- Para proteger informações confidenciais, recomendamos que encriptem todas as comunicações em trânsito. Se a encriptação for necessária na camada de conetividade, pode usar túneis de VPN, VPN de alta disponibilidade através do Cloud Interconnect e MACsec para o Cloud Interconnect.
Para superar as inconsistências nos protocolos, APIs e mecanismos de autenticação em vários backends, recomendamos, quando aplicável, que implemente um gateway de API ou um proxy como uma fachada unificadora. Este gateway ou proxy funciona como um ponto de controlo centralizado e toma as seguintes medidas:
- Implementa medidas de segurança adicionais.
- Protege as apps de cliente e outros serviços contra alterações ao código de back-end.
- Facilita as pistas de auditoria para a comunicação entre todas as aplicações em vários ambientes e os respetivos componentes separados.
- Atua como uma camada de comunicação intermédia entre os serviços antigos e modernizados.
- O Apigee e o Apigee Hybrid permitem-lhe alojar e gerir gateways híbridos e de nível empresarial em ambientes nas instalações, na periferia, noutras nuvens e emGoogle Cloud ambientes.
Para facilitar o estabelecimento de configurações híbridas, use o Cloud Load Balancing com conetividade híbrida. Isto significa que pode estender as vantagens do Cloud Load Balancing aos serviços alojados no seu ambiente de computação no local. Esta abordagem permite migrações de cargas de trabalho faseadas para o Google Cloud com uma interrupção mínima ou nula do serviço, o que garante uma transição suave para os serviços distribuídos. Para mais informações, consulte o artigo Vista geral dos grupos de pontos finais de rede de conetividade híbrida.
Por vezes, a utilização de um gateway de API ou um proxy e um Application Load Balancer em conjunto pode oferecer uma solução mais robusta para gerir, proteger e distribuir o tráfego da API em grande escala. A utilização do Cloud Load Balancing com gateways de API permite-lhe realizar o seguinte:
- Forneça APIs de elevado desempenho com o Apigee e a RFC do Google Cloud, para reduzir a latência, alojar APIs globalmente e aumentar a disponibilidade para temporadas de pico de tráfego. Para mais informações, veja o vídeo Fornecer APIs de alto desempenho com o Apigee e o Cloud CDN no YouTube.
- Implemente a gestão avançada de tráfego.
- Use o Cloud Armor como um serviço de proteção contra DDoS e de segurança de rede para proteger as suas APIs.
- Faça a gestão do balanceamento de carga eficiente em gateways em várias regiões. Para mais informações, veja o vídeo Proteger APIs e implementar a comutação por falha multirregião com o Private Service Connect e o Apigee no YouTube.
Use a gestão de APIs e a malha de serviços para proteger e controlar a comunicação e a exposição de serviços com a arquitetura de microsserviços.
- Use a Cloud Service Mesh para permitir a comunicação entre serviços que mantém a qualidade do serviço num sistema composto por serviços distribuídos onde pode gerir a autenticação, a autorização e a encriptação entre serviços.
- Use uma plataforma de gestão de APIs, como a Apigee, que permite à sua organização e a entidades externas consumir esses serviços expondo-os como APIs.
Estabelecer uma identidade comum entre ambientes para que os sistemas possam autenticar em segurança nos limites dos ambientes.
Implemente sistemas de CI/CD e de gestão de configuração na nuvem pública. Para mais informações, consulte o artigo Padrão de arquitetura de rede espelhada.
Para ajudar a aumentar a eficiência operacional, use ferramentas consistentes e pipelines de CI/CD em todos os ambientes.
Práticas recomendadas para a carga de trabalho individual e as arquiteturas de aplicações
- Embora o foco esteja nas aplicações de front-end neste padrão, tenha em atenção a necessidade de modernizar as suas aplicações de back-end. Se o ritmo de desenvolvimento das aplicações de back-end for substancialmente mais lento do que o das aplicações de front-end, a diferença pode causar complexidade adicional.
- Tratar as APIs como interfaces de back-end simplifica as integrações, o desenvolvimento de front-end, as interações de serviços e oculta as complexidades do sistema de back-end. Para resolver estes desafios, o Apigee facilita o desenvolvimento e a gestão de gateways/proxies de API para implementações híbridas e em várias nuvens.
- Escolha a abordagem de renderização para a sua aplicação Web de front-end com base no conteúdo (estático versus dinâmico), no desempenho da otimização do motor de pesquisa e nas expetativas sobre as velocidades de carregamento das páginas.
- Quando seleciona uma arquitetura para aplicações Web orientadas por conteúdo, estão disponíveis várias opções, incluindo arquiteturas monolíticas, sem servidor, baseadas em eventos e de microsserviços. Para selecionar a arquitetura mais adequada, avalie cuidadosamente estas opções em função dos requisitos atuais e futuros da aplicação. Para ajudar a tomar uma decisão arquitetónica que esteja alinhada com os seus objetivos empresariais e técnicos, consulte Comparação de diferentes arquiteturas para backends de aplicações Web orientadas por conteúdo e Principais considerações para backends Web.
Com uma arquitetura de microsserviços, pode usar aplicações em contentores com o Kubernetes como a camada de tempo de execução comum. Com o padrão de arquitetura híbrida em camadas, pode executá-lo num dos seguintes cenários:
Em ambos os ambientes (Google Cloud e os seus ambientes no local).
- Quando usa contentores e o Kubernetes em vários ambientes, tem a flexibilidade de modernizar as cargas de trabalho e, em seguida, migrar para o Google Cloud em alturas diferentes. Isto ajuda quando uma carga de trabalho depende muito de outra e não pode ser migrada individualmente, ou a usar a portabilidade de cargas de trabalho híbridas para usar os melhores recursos disponíveis em cada ambiente. Em todos os casos, o GKE Enterprise pode ser uma tecnologia de ativação fundamental. Para mais informações, consulte o artigo Ambiente híbrido do GKE Enterprise.
Num Google Cloud ambiente para os componentes da aplicação migrados e modernizados.
- Use esta abordagem quando tiver backends antigos no local que não tenham suporte de contentorização ou exijam um tempo e recursos significativos para modernizar a curto prazo.
Para mais informações sobre a conceção e a refatoração de uma app monolítica para uma arquitetura de microsserviços de forma a modernizar a arquitetura da sua aplicação Web, consulte o artigo Introdução aos microsserviços.
Pode combinar tecnologias de armazenamento de dados consoante as necessidades das suas aplicações Web. A utilização do Cloud SQL para dados estruturados e do Cloud Storage para ficheiros multimédia é uma abordagem comum para satisfazer diversas necessidades de armazenamento de dados. No entanto, a escolha depende muito do seu exemplo de utilização. Para mais informações sobre as opções de armazenamento de dados para backends de aplicações baseadas em conteúdo e modalidades eficazes, consulte o artigo Opções de armazenamento de dados para apps Web baseadas em conteúdo. Consulte também o artigo As suas Google Cloud opções de base de dados, explicadas.