Tenho certeza de que a manchete causou uma reação saudável - “bem, começou de novo...” Mas deixe-me chamar sua atenção por 5 a 10 minutos e tentarei não decepcionar suas expectativas.
A estrutura do artigo será a seguinte: toma-se uma afirmação estereotipada e revela-se a “natureza” do surgimento deste estereótipo. Espero que isso permita que você veja a escolha do paradigma de troca de dados em seus projetos sob um novo ângulo.
Para deixar claro o que é RPC, proponho considerar o padrão . Com REST não há clareza. E não deveria ser. Tudo o que você precisa saber sobre REST - é indistinguível de .
As solicitações RPC são mais rápidas e eficientes porque permitem fazer solicitações em lote.
A questão é que no RPC você pode chamar vários procedimentos ao mesmo tempo em uma solicitação. Por exemplo, crie um usuário, adicione um avatar a ele e, na mesma solicitação, inscreva-o em alguns tópicos. Apenas um pedido e quanto benefício!
Na verdade, se você tiver apenas um nó de backend, parecerá mais rápido com uma solicitação em lote. Porque três solicitações REST exigirão três vezes mais recursos de um nó para estabelecer conexões.
Observe que a primeira solicitação no caso de REST deve retornar o ID do usuário para que as solicitações subsequentes sejam feitas. O que também afeta negativamente o resultado geral.
Mas essas infraestruturas só podem ser encontradas em soluções internas e empresariais. Como último recurso, em pequenos projetos WEB. Mas não vale a pena construir soluções WEB completas, mesmo aquelas chamadas HighLoad. A sua infraestrutura deve atender aos critérios de alta disponibilidade e carga. E o quadro está mudando.
Os canais de atividade de infraestrutura no mesmo cenário estão marcados em verde. Observe como o RPC se comporta agora. A solicitação usa a infraestrutura em apenas um trecho do balanceador até o backend. Embora o REST ainda perca na primeira solicitação, ele compensa o tempo perdido usando toda a infraestrutura.
Basta inserir no roteiro não dois pedidos de enriquecimento, mas, digamos, cinco ou dez... e a resposta à pergunta “quem ganha agora?” torna-se obscuro.
Proponho dar uma olhada ainda mais ampla no problema. O diagrama mostra como os canais de infraestrutura são usados, mas a infraestrutura não está limitada aos canais. Um componente importante de uma infraestrutura de alta carga são os caches. Vamos agora pegar algum tipo de artefato do usuário. Repetidamente. Digamos 32 vezes.
Veja como a infraestrutura RPC melhorou significativamente para atender às demandas de alta carga. O problema é que o REST usa todo o poder do protocolo HTTP, ao contrário do RPC. No diagrama acima, esse poder é realizado através do método de solicitação – GET.
Os métodos HTTP, entre outras coisas, possuem estratégias de cache. Você pode encontrá-los na documentação em . Para RPC são utilizadas solicitações POST, que não são consideradas idempotentes, ou seja, repetições repetidas das mesmas solicitações POST podem retornar resultados diferentes (por exemplo, após o envio de cada comentário, aparecerá outra cópia deste comentário) ().
Conseqüentemente, o RPC não consegue usar caches de infraestrutura de maneira eficaz. Isso leva à necessidade de “importar” caches de software. O diagrama mostra o Redis nessa função. O cache do software, por sua vez, exige que o desenvolvedor adicione uma camada adicional de código e mudanças perceptíveis na arquitetura.
Vamos agora contar quantas solicitações REST e RPC “deram origem” na infraestrutura em consideração?
pedidos
Caixa de entrada
para back-end
para o SGBD
para cache suave (Redis)
TOTAL
DESCANSO
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Comparado com o primeiro esquema, a diferença é impressionante. Agora o benefício do REST fica claro. Mas sugiro não parar por aí. A infraestrutura desenvolvida inclui um CDN. Freqüentemente, também resolve o problema de combate aos ataques DDoS e DoS. Nós temos:
É aqui que as coisas ficam realmente ruins para o RPC. O RPC simplesmente não é capaz de delegar a carga de trabalho a um CDN. Só podemos confiar em sistemas para combater ataques.
É possível terminar aqui? E novamente, não. Os métodos HTTP, como mencionado acima, têm sua própria “mágica”. E não é à toa que o método GET é amplamente utilizado na Internet. Observe que esse método é capaz de acessar uma parte do conteúdo, definir condições que os elementos da infraestrutura podem interpretar antes que o controle seja transferido para o seu código e assim por diante. Tudo isso permite criar infraestruturas flexíveis e gerenciáveis que podem lidar com fluxos de solicitações realmente grandes. Mas no RPC este método... é ignorado.
Então, por que o mito de que as solicitações em lote (RPC) são mais rápidas é tão persistente? Pessoalmente, parece-me que a maioria dos projetos simplesmente não atinge um nível de desenvolvimento onde o REST seja capaz de mostrar a sua força. Além disso, em pequenos projetos, ele está mais disposto a mostrar seus pontos fracos.
A escolha de REST ou RPC não é uma escolha volitiva de um indivíduo em um projeto. Esta escolha deve atender aos requisitos do projeto. Se um projeto for capaz de extrair tudo o que realmente pode do REST e realmente precisar disso, o REST será uma excelente escolha.
Mas se para obter todos os benefícios do REST você precisar contratar especialistas devops para o projeto escalar rapidamente a infraestrutura, administradores para gerenciar a infraestrutura, um arquiteto para projetar todas as camadas do serviço WEB... e o projeto , ao mesmo tempo, vende três pacotes de margarina por dia... eu ficaria com o RPC, porque... este protocolo é mais utilitário. Não exigirá conhecimento profundo de como funcionam os caches e a infraestrutura, mas focará o desenvolvedor em chamadas simples e compreensíveis para os procedimentos de que necessita. Os negócios ficarão felizes.
As solicitações RPC são mais confiáveis porque podem executar solicitações em lote em uma única transação
Esta propriedade do RPC é uma vantagem definitiva, porque É fácil manter o banco de dados consistente. Mas com REST fica cada vez mais complicado. As solicitações podem chegar de forma inconsistente a diferentes nós de back-end.
Essa “desvantagem” do REST é o outro lado da vantagem descrita acima – a capacidade de usar com eficiência todos os recursos da infraestrutura. Se a infraestrutura for mal projetada, e ainda mais se a arquitetura do projeto e o banco de dados em particular forem mal projetados, isso será realmente um grande problema.
Mas as solicitações em lote são tão confiáveis quanto parecem? Vejamos um caso: criamos um usuário, enriquecemos seu perfil com alguma descrição e enviamos um SMS com um segredo para completar o cadastro. Aqueles. três chamadas em uma solicitação em lote.
Vejamos o diagrama. Apresenta uma infraestrutura com elementos de alta disponibilidade. Existem dois canais de comunicação independentes com gateways SMS. Mas... o que vemos? Ao enviar um SMS ocorre o erro 503 - o serviço está temporariamente indisponível. Porque O envio de SMS é empacotado em uma solicitação em lote e, em seguida, toda a solicitação deve ser revertida. As ações no DBMS são canceladas. O cliente recebe um erro.
A próxima tentativa é na loteria. A solicitação atingirá o mesmo nó repetidamente e retornará um erro ou você terá sorte e ela será executada. Mas o principal é que pelo menos uma vez nossa infraestrutura já funcionou em vão. Houve uma carga, mas nenhum lucro.
Ok, vamos imaginar que nos esforçamos (!) e pensamos na opção quando a solicitação poderia ser parcialmente concluída com sucesso. E tentaremos completar o resto novamente após algum intervalo de tempo (Qual? A frente decide?). Mas a loteria permaneceu a mesma. A solicitação para enviar SMS tem 50/50 de chance de falhar novamente.
Concordo, do lado do cliente, o serviço não parece tão confiável quanto gostaríamos... e quanto ao REST?
REST usa a magia do HTTP novamente, mas agora com códigos de resposta. Quando ocorre um erro 503 no gateway SMS, o backend transmite esse erro para o balanceador. O balanceador recebe este erro e sem interromper a conexão com o cliente, envia a solicitação para outro nó, que processa a solicitação com sucesso. Aqueles. o cliente recebe o resultado esperado e a infraestrutura confirma seu elevado título de “altamente acessível”. O usuário está feliz.
E, novamente, isso não é tudo. O balanceador não recebeu apenas um código de resposta 503. Ao responder, de acordo com a norma, é aconselhável fornecer este código com o cabeçalho “Retry-After”. O cabeçalho deixa claro ao balanceador que ele não deve perturbar este nó nesta rota por um tempo especificado. E as próximas solicitações de envio de SMS serão enviadas diretamente para um nó que não tenha problemas com o gateway SMS.
Como podemos ver, a confiabilidade do JSON-RPC é superestimada. Na verdade, é mais fácil organizar a consistência no banco de dados. Mas o sacrifício, neste caso, será a confiabilidade do sistema como um todo.
A conclusão é em grande parte semelhante à anterior. Quando a infraestrutura é simples, a obviedade do JSON-RPC é definitivamente uma vantagem. Se o projeto envolve alta disponibilidade com alta carga, REST parece uma solução mais correta, embora mais complexa.
O limite de entrada para REST é menor
Penso que a análise acima, desmascarando os estereótipos estabelecidos sobre o RPC, mostrou claramente que o limite para entrar no REST é, sem dúvida, maior do que no RPC. Isto se deve à necessidade de um profundo entendimento de como funciona o HTTP, bem como à necessidade de ter conhecimento suficiente sobre os elementos de infraestrutura existentes que podem e devem ser utilizados em projetos WEB.
Então, por que muitas pessoas pensam que REST será mais simples? Minha opinião pessoal é que essa aparente simplicidade vem das próprias manifestações REST. Aqueles. REST não é um protocolo e sim um conceito... REST não tem um padrão, existem algumas diretrizes... REST não é mais complicado que HTTP. A aparente liberdade e anarquia atraem “artistas livres”.
Claro, REST não é mais complicado que HTTP. Mas o próprio HTTP é um protocolo bem projetado que provou seu valor ao longo de décadas. Se não houver um conhecimento profundo do próprio HTTP, o REST não poderá ser julgado.
Mas sobre RPC - você pode. Basta levar sua especificação. Então você precisa ? Ou ainda é REST complicado? Você decide.
Espero sinceramente não ter perdido seu tempo.
Fonte: habr.com