|
|
Publicado em 25/09/2019 16:11:58
|
|
|
|
Tradicionalmente, um sistema que lida com um bilhão de transações por dia poderia exigir centenas de VMs, o PayPal faz tudo isso com apenas 8 VMs e entrega resposta rápida com 90% de uso de CPU, uma densidade de transações que o PayPal nunca havia alcançado antes, e o processo leva 1/10 do tempo para ser alcançado, ajudando a organização a acompanhar o crescimento sem precisar ampliar sua infraestrutura computacional enquanto reduz custos. Como isso é feito?
O PayPal migrou seu sistema para o modo Actor baseado em Akka. No artigo Squbs: PayPal adota uma nova abordagem reativa para construir aplicativos (O login do hiperlink está visível.O PayPal explica todos os detalhes do processo. Agora eles disponibilizaram Squbs em código aberto e o publicaram no GitHub (O login do hiperlink está visível.)。
Quando um projeto precisa adotar uma abordagem prática, o modelo de serviço com estado ainda não recebe atenção suficiente. Para saber mais sobre serviços com estado, recomendamos ler os motivos para continuar construindo serviços escaláveis com estado agora (O login do hiperlink está visível.), este artigo é baseado em um discurso de Caitie McCaffrey. Se este artigo não te convencer, também existe o WhatsApp, que usa o concorrente da Akka, Erlang, para um fluxo extremamente alto: a arquitetura WhatsApp do Facebook, de US$ 19 bilhões (O login do hiperlink está visível.)。
A razão para recomendar o artigo acima é que o PayPal não oferece uma introdução detalhada à arquitetura, mas dedica mais tempo aos motivos pelos quais escolheram Akka e aos benefícios de migrar para Akka. Mas este artigo ainda oferece um incentivo valioso e uma demonstração para a prática de "sair do caminho batido".
Qual o problema de usar um grande número de máquinas virtuais para um serviço?
- Rodar o serviço com máquinas virtuais de muito baixo débito e extremamente pequenas. A maior vantagem dos sistemas reativos baseados em atores é que eles podem fazer uso mais eficiente dos recursos computacionais, o que pode reduzir muito o tamanho do sistema e evitar a escalonabilidade automática "simples e rudimentar" das práticas tradicionais.
- Isso coloca muita pressão na sua rede e infraestrutura de roteamento. Como os serviços tendem a ser mais interconectados, as requisições podem precisar passar por um grande número de saltos de rede, o que aumenta a latência e degrada a experiência do usuário.
- Quanto maior ela é, mais cara ela fica. Serviços com centenas de máquinas virtuais têm altos custos inerentes em termos de gerenciamento, monitoramento e cache ineficaz.
- Quanto menor ele é, mais ágil ele é. Implantar serviços para centenas de máquinas virtuais é um processo demorado.
- Aproveite mais o CPU de cada máquina virtual. Como as CPUs não podem ser aceleradas ainda mais, a infraestrutura precisa ser capaz de fazer uso mais eficiente de mais CPUs em cada máquina virtual.
- Os microserviços precisam ser construídos com NanoServices fracamente acoplados, fáceis de manter e rápidos de desenvolver. Ninguém quer lidar com um sistema complexo com muitas camadas, e você precisa de mais visibilidade sobre o papel dos diferentes serviços sem precisar se aprofundar em camadas de código.
Com esses fatores em mente, o PayPal quis construir um sistema que:
- Escalável, não apenas para escalar horizontalmente para centenas de nós, mas também para escalar para mais processadores e alcançar o objetivo de processar bilhões de requisições por dia.
- Baixa latência e pode ser controlada com granularidade extremamente fina.
- Seja resiliente diante das falhas.
- Ajuste flexível dos limites dos serviços.
- Promover escalabilidade e simplicidade por meio de modelos e culturas de programação, bem como mecanismos mais simples de tratamento de falhas e erros.
Não há dúvida de que o PayPal quer usar uma pilha mais "fina", e não quer que sua pilha contenha muita tecnologia e peças móveis em diferentes níveis. Em geral, sistemas Akka e baseados em estados são bem adequados para essa necessidade, o que permite que a pilha de grandes componentes seja "dividida" em uma única tecnologia. O PayPal escolheu a Akka em vez da Erlang porque tem mais experiência com Java, que roda sobre o Java. Para muitas pessoas, aprender Erlang do zero não é realista.
Com Akka, eles podem:
- Escreva código que seja mais fácil de explicar
- Escreva código que seja mais fácil de testar
- Cenários de erro e falha são tratados de forma mais natural do que os modos tradicionais usando a JVM
- Escreva código mais rápido, resiliente e simples para lidar com erros de forma mais fluente e reduzir o número de bugs
O PayPal imediatamente criou seu próprio framework baseado no Akka, chamado Squbs, usado para rimar com "Cubes". Isso permite criar uma camada de tecnologia modular para a construção de um NanoService chamada "Cubo". Os cubos são simétricos, e as dependências entre diferentes cubos também são simétricas e frouxas, expondo apenas as interfaces de mensagens que Akka já fornece.
Também descreve as dificuldades que programadores podem enfrentar ao adotar código AKKA, já que você pode precisar contratar alguém treinado em Akka/Scala.
Como a maioria dos serviços tem propósitos semelhantes: receber requisições, chamar e ler e escrever bancos de dados, chamar outros serviços, chamar motores de regras, obter dados de caches, gravar em caches... Como resultado, os serviços podem ser abstratos por meio de padrões como Orchestrator Pattern e Perpetual Stream.
O squbs se tornou uma prática padrão do PayPal para criar aplicações reativas baseadas no Akka. Se sua equipe ainda não considerou sistemas com estado, provavelmente vale a pena tentar, pois funciona bem no PayPal, Facebook, Uber e Microsoft.
|
Anterior:Três fatores que me fazem desvalorizar o ChromePróximo:vs criar uma pasta, e ao gerar a solução, não há ninguém no arquivo bin
|
