Tenho certeza de que o título gerou uma reação saudável - "lá vamos nós de novo..." Mas permita-me capturar sua atenção por 5-10 minutos, e eu tentarei não desapontar suas expectativas.
A estrutura do artigo será a seguinte: um estereótipo é analisado e a "natureza" da sua origem é revelada. Espero que isso permita olhar para a escolha da paradigma de troca de dados em seus projetos sob uma nova perspectiva.
Para esclarecimento sobre o que é RPC, sugiro considerar o padrão . Com o REST não há clareza. E não deveria haver. Tudo o que você precisa saber sobre o REST é que ele é indistinguível de .
As solicitações RPC são mais rápidas e eficientes, pois permitem fazer solicitações em lote.
A questão é que no RPC é possível chamar várias funções em uma única solicitação. Por exemplo, criar um usuário, adicionar um avatar e, na mesma solicitação, inscrevê-lo em alguns tópicos. Uma única solicitação, e quanta utilidade!
De fato, se você tiver apenas um nó de backend, isso parecerá mais rápido em uma solicitação em lote. Porque três solicitações REST exigirão três vezes mais recursos de um único nó para estabelecer conexões.
Observe que a primeira solicitação no caso do REST deve retornar o identificador do usuário para realizar as solicitações subsequentes. O que também impacta negativamente no resultado geral.
Mas tais infraestruturas só podem ser encontradas, no máximo, em soluções internas e Enterprise. No pior dos casos, em pequenos projetos WEB. Mas soluções WEB completas, e ainda nomeadas como HighLoad, não devem ser construídas assim. Sua infraestrutura deve atender aos critérios de alta disponibilidade e carga. E o cenário muda.
Os canais de atividade da infraestrutura estão destacados em verde no mesmo cenário. Observe como o RPC se comporta agora. A solicitação utiliza a infraestrutura apenas por um lado do balanceador até o backend. Enquanto o REST ainda perde na primeira solicitação, mas se recupera usando toda a infraestrutura.
Basta introduzir no cenário não duas solicitações de enriquecimento, mas, digamos, cinco ou dez... e a resposta à pergunta "quem está vencendo agora?" se torna não tão óbvia.
Vamos ampliar a perspectiva sobre o problema. No diagrama, vemos como os canais da infraestrutura são utilizados, mas a infraestrutura não se limita apenas aos canais. Uma parte importante de uma infraestrutura de alta carga são os caches. Vamos agora gerar algum artefato do usuário. Várias vezes. Digamos, 32 vezes.
Veja como a infraestrutura no RPC evoluiu significativamente para atender às exigências de alta carga. A questão é que o REST aproveita todo o potencial do protocolo HTTP, ao contrário do RPC. No diagrama apresentado, esse potencial é realizado através do método de requisição — GET.
Os métodos HTTP, entre outras coisas, possuem estratégias de cache. Você pode conhecê-las na documentação em . Para o RPC, são utilizados pedidos POST, que não são considerados idempotentes, ou seja, a repetição de um mesmo pedido POST pode retornar resultados diferentes (por exemplo, após cada envio de um comentário, uma nova cópia desse comentário aparecerá) ().
Portanto, o RPC não consegue utilizar efetivamente os caches de infraestrutura. Isso resulta na necessidade de "importar" caches de software. No diagrama, o Redis está representado nesse papel. O cache de software, por sua vez, exige do desenvolvedor uma camada de código adicional e mudanças significativas na arquitetura.
Vamos agora contar quantas requisições o REST e o RPC geraram na infraestrutura em questão?
Consultas
Entrantes
para o backend
para o SGBD
para o cache de software (Redis)
TOTAL
REST
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
[*] no melhor dos casos (se o cache local for utilizado) 1 requisição (uma!), e no pior 32 requisições entrantes.
Comparado ao primeiro diagrama, a diferença é marcante. Agora, fica claro o ganho do REST. Mas não vamos parar por aqui. Uma infraestrutura desenvolvida inclui CDN. Muitas vezes, ela também resolve a questão de combate a ataques DDoS e DoS. Vamos ver:
Aqui, para o RPC, a situação se torna bastante lamentável. O RPC simplesmente não consegue delegar o trabalho com a carga para o CDN. Resta esperar apenas que sistemas de combate a ataques sejam eficazes.
Podemos encerrar aqui? E novamente, não. Os métodos HTTP, como mencionado acima, têm sua "magia". E não é à toa que o método GET é amplamente utilizado na Internet. Note que este método pode acessar partes do conteúdo, pode impor condições que serão interpretadas pelos elementos de infraestrutura ainda antes de passar o controle para o seu código, etc. Tudo isso permite a criação de infraestruturas flexíveis e gerenciáveis, capazes de lidar com grandes fluxos de requisições. E no RPC, esse método... é ignorado.
Mas por que o mito de que as requisições em lote (RPC) são mais rápidas persiste? Pessoalmente, acho que a maioria dos projetos simplesmente não alcança um nível de desenvolvimento em que o REST pode mostrar sua força. Além disso, em projetos menores, ele tende a revelar suas fraquezas.
A escolha entre REST e RPC não é uma decisão pessoal de alguém em um projeto. Essa escolha deve atender aos requisitos do projeto. Se o projeto consegue extrair tudo o que o REST realmente pode oferecer e isso é realmente necessário, então o REST será uma excelente escolha.
Mas se para aproveitar todos os benefícios do REST for necessário contratar devops para escalabilidade operacional da infraestrutura, administradores para gerenciar a infraestrutura, um arquiteto para projetar todas as camadas do serviço WEB... e o projeto, por sua vez, vende três pacotes de margarina por dia... eu optaria pelo RPC, pois esse protocolo é mais utilitário. Ele não exige conhecimentos profundos sobre como funcionam caches e infraestrutura, e foca o desenvolvedor em chamadas simples e claras das funções de que precisa. O negócio ficará satisfeito.
As requisições RPC são mais confiáveis porque podem executar requisições em lote dentro de uma única transação.
Esta característica do RPC é indiscutivelmente uma vantagem, pois facilita a manutenção do banco de dados em um estado consistente. Já com o REST, a situação é mais complicada. As requisições podem chegar de forma não sequencial em diferentes nós do backend.
Essa "desvantagem" do REST é o lado oposto de sua vantagem mencionada acima — a capacidade de utilizar todos os recursos da infraestrutura de forma eficaz. Se a infraestrutura for mal projetada, especialmente se a arquitetura do projeto e do banco de dados em particular forem mal elaboradas, isso realmente se torna uma grande dor.
Mas quão confiáveis são as requisições em lote como parecem? Vamos analisar um caso: criamos um usuário, enriquecemos seu perfil com alguma descrição e enviamos um SMS com um segredo para concluir o registro. Ou seja, três chamadas em uma única requisição em lote.
Vamos considerar o diagrama. Nele está apresentada a infraestrutura com elementos de alta disponibilidade. Há dois canais de comunicação independentes com os gateways de SMS. Mas… o que vemos? Ao enviar um SMS ocorre um erro 503 — serviço temporariamente indisponível. Como o envio de SMS está empacotado em uma requisição em lote, toda a requisição deve ser revertida. As ações no SGBD são anuladas. O cliente recebe um erro.
A próxima tentativa é uma loteria. Ou a requisição vai novamente para o mesmo nó e retorna o erro novamente, ou teremos sorte e ela será executada. Mas o principal é que, pelo menos uma vez, nossa infraestrutura já trabalhou em vão. Havia carga, mas não houve lucro.
Bem, vamos imaginar que nos esforçamos (!) e pensamos em uma opção onde a requisição pode ser executada parcialmente com sucesso. E o restante, tentaremos executar novamente após algum intervalo de tempo (Qual? O frontend decide?). Mas a loteria permanece. A requisição para envio de SMS tem 50/50 de chance de falhar novamente.
Concorda que, do ponto de vista do cliente, o serviço não parece tão confiável quanto se gostaria… e quanto ao REST?
O REST novamente usa a “mágica” do HTTP, mas agora com códigos de resposta. Quando ocorre o erro 503 no gateway de SMS, o backend transmite esse erro para o balanceador. O balanceador, ao receber esse erro e sem desconectar do cliente, redireciona a requisição para outro nó que executa a requisição com sucesso. Ou seja, o cliente recebe o resultado esperado, enquanto a infraestrutura confirma seu alto título de “alta disponibilidade”. O usuário fica feliz.
E novamente, isso não é tudo. O balanceador não apenas recebeu o código de resposta 503. Esse código, conforme o padrão, deve ser acompanhado por um cabeçalho “Retry-After”. O cabeçalho informa ao balanceador que não deve incomodar esse nó por essa rota durante o tempo determinado. E as próximas requisições para envio de SMS serão direcionadas imediatamente para o nó que não possui problemas com o gateway de SMS.
Como vemos, a confiabilidade do JSON-RPC é superestimada. De fato, é mais fácil organizar a consistência no banco de dados. Mas a vítima, nesse caso, será a confiabilidade do sistema como um todo.
A saída é em muitos aspectos semelhante à anterior. Quando a infraestrutura é simples, a clareza do JSON-RPC é, sem dúvida, uma vantagem. Se o projeto requer alta disponibilidade com alta carga, o REST parece ser a escolha mais apropriada, embora seja uma solução mais complexa.
A barreira de entrada para o REST é menor
A análise acima, que desmistifica os estereótipos estabelecidos sobre RPC, mostra claramente que a barreira de entrada para o REST é, sem dúvida, maior do que para o RPC. Isso se deve à necessidade de um entendimento profundo do funcionamento do HTTP, além da necessidade de ter conhecimentos suficientes sobre os elementos de infraestrutura existentes que podem e devem ser aplicados em projetos WEB.
Então, por que muitos pensam que o REST será mais fácil? Minha opinião pessoal é que essa aparente simplicidade vem dos próprios manifestos do REST. Ou seja, o REST não é um protocolo, mas uma concepção... o REST não tem um padrão, existem algumas recomendações... o REST não é mais complexo que o HTTP. A aparente liberdade e anarquia atraem "artistas livres".
Sem dúvida, o REST não é mais complexo que o HTTP. Mas o próprio HTTP é um protocolo bem pensado, que comprovou sua eficácia ao longo das décadas. Se não houver um entendimento profundo do próprio HTTP, então não se pode avaliar o REST.
Mas quanto ao RPC — isso é possível. Basta consultar sua especificação. Então, você realmente precisa de um ? Или все же хитрый REST? Решать вам.
Espero sinceramente que eu não tenha desperdiçado seu tempo.
Fonte: habr.com
