Por muito tempo, não descobri a diferença entre RPC (ou seja, chamada de procedimento remoto) e chamadas HTTP. Por favor, me permitam rir aqui~Ingênuo! Este artigo apresenta brevemente as duas formas de arquitetura C/S, primeiramente sua diferença mais essencial, ou seja, o RPC é baseado principalmente no protocolo TCP/IP, enquanto o serviço HTTP é baseado principalmente no protocolo HTTP; todos sabemos que o protocolo HTTP está sobre o protocolo da camada de transporte TCP, então, em termos de eficiência, o RPC é obviamente melhor! Vamos falar em detalhes sobre os serviços RPC e os serviços HTTP.
Modelo de sete camadas em rede OSI
Antes de falar sobre a diferença entre RPC e HTTP, sinto que é necessário entender o modelo de estrutura de rede de sete camadas do OSI (embora na prática seja basicamente cinco camadas), que pode ser dividido nas seguintes camadas: (de cima para baixo)
- A primeira camada: camada de aplicação. Interfaces para comunicação e transmissão de dados na rede são definidas;
- A segunda camada: a camada de representação. Definir o formato de transmissão, especificações de codificação e decodificação de dados em diferentes sistemas, etc.;
- A terceira camada: a camada de conversa. Gerencie as sessões dos usuários e controle o estabelecimento e a interrupção das conexões lógicas entre os usuários.
- A quarta camada: a camada de transporte. Ele gerencia a transmissão de dados de ponta a ponta na rede;
- Camada 5: Camada de rede. Defina como os dados são transferidos entre dispositivos de rede;
- Sexta camada: camada de link. Os pacotes de dados da camada de rede acima são encapsulados em quadros de dados para facilitar a transmissão da camada física.
- Camada 7: Camada física. Essa camada é principalmente sobre transmitir esses dados binários.
Na prática, não existe camada de apresentação e camada de sessão na estrutura de cinco camadas do protocolo. Deve-se dizer que eles se fundem com a camada de aplicação. Devemos focar na camada de aplicação e na camada de transporte. Porque HTTP é um protocolo da camada de aplicação, enquanto TCP é um protocolo da camada de transporte. Bem, agora que conhecemos o modelo de layering de rede, podemos entender melhor por que os serviços RPC são melhores do que os serviços HTTP!
Serviços RPC
Os serviços RPC são introduzidos sob três perspectivas: arquitetura RPC, chamadas assíncronas síncronas e frameworks RPC populares.
Arquitetura RPC
Vamos falar sobre a arquitetura básica dos serviços RPC. Permita-me roubar uma imagem vergonhosa~ Podemos ver claramente que uma arquitetura RPC completa contém quatro componentes principais, a saber: Cliente, Servidor, Cliente Stub e Server Stub, que podem ser entendidos como um stub. Vamos falar sobre esses componentes separadamente:
- Cliente, o chamador do serviço.
- Servidor, o verdadeiro provedor de serviço.
- O stub do cliente armazena a mensagem de endereço do servidor e então empacota os parâmetros de requisição do cliente em uma mensagem de rede, enviando-a remotamente para a parte do serviço através da rede.
- O stub do lado do servidor recebe mensagens enviadas pelo cliente, desembala as mensagens e chama métodos locais.
O RPC é usado principalmente em grandes empresas, porque grandes empresas possuem muitos sistemas, linhas de negócios complexas e vantagens de eficiência são muito importantes. Isso é feito no desenvolvimento real, e os projetos geralmente são gerenciados usando o Maven. Por exemplo, temos um serviço de sistema que processa ordens, primeiro declara todas as suas interfaces (aqui especificamente a interface em Java) e então empacota todo o projeto em um pacote jar. Por que fazer isso? O principal objetivo é reduzir o tamanho do pacote jar no lado do cliente, porque toda vez que um pacote é lançado, muitos pacotes jar sempre afetam a eficiência. Também desacopla o cliente e o servidor para melhorar a portabilidade do código.
Chamadas síncronas e assíncronas
O que é Chamada Síncrona? O que é uma chamada assíncrona? Uma chamada síncrona ocorre quando o cliente espera a execução da chamada e retorna o resultado. Chamadas assíncronas significam que o cliente não espera a execução da chamada e retorna o resultado, mas ainda pode receber a notificação do retorno do resultado por meio da função de retorno. Se o cliente não se importar com o resultado, pode se tornar uma decisão unilateral. Esse processo é um pouco semelhante às interfaces chamáveis e executáveis em Java; quando executamos assíncronamente, se precisarmos saber o resultado da execução, podemos usar a interface chamável e obter a informação do resultado da execução assíncrona através da classe Future. Se você não se importa com o resultado da execução, pode simplesmente usar a interface executável porque ela não retorna o resultado, claro, o modo de chamada também é possível, não precisamos de ver o futuro.
Framework RPC popular
Ainda existem muitos frameworks RPC de código aberto populares. Aqui estão três destaques:
- gRPC é um software open-source recentemente anunciado pelo Google, baseado no mais recente protocolo HTTP 2.0, e suporta muitas linguagens de programação comuns. Sabemos que o HTTP 2.0 é uma versão atualizada do protocolo HTTP baseada em binário, e navegadores importantes estão atualmente suportando isso rapidamente. Esse framework RPC é baseado no protocolo HTTP, e o subjacente utiliza o suporte do framework Netty.
- Thrift é um projeto de código aberto para o Facebook, principalmente um framework de desenvolvimento de serviços multi-idiomas. Ele possui um gerador de código para gerar automaticamente um framework de código de serviço para o arquivo de definição IDL que define. Os usuários só precisam realizar desenvolvimentos secundários antes disso, e a comunicação subjacente ao RPC é transparente. No entanto, para os usuários, ainda há um certo custo para aprender a linguagem de uma área específica.
- Dubbo é um framework RPC bem conhecido de código aberto do Alibaba Group, amplamente utilizado em muitas empresas de Internet e aplicações empresariais. Tanto protocolos quanto frameworks de serialização podem ser conectados. A mesma interface remota é baseada na Interface Java e depende do framework spring para facilitar o desenvolvimento. Ele pode ser facilmente empacotado em um único arquivo e executado de forma independente, o que é consistente com o conceito atual de microserviços.
Secretamente te dizer que o grupo não usa muito dubbo hoje em dia,O mais comumente usado atualmente é chamado HSF, também conhecido como "tão confortável". Pode haver open source depois, então vamos esperar para ver.
Serviço HTTP
Na verdade, há muito tempo, sempre caracterizei o modelo de desenvolvimento corporativo como desenvolvimento de interfaces HTTP, que é o que frequentemente chamamos de interfaces de serviço no estilo RESTful. De fato, é um método de comunicação frequentemente usado nos estágios iniciais da resolução de ilhas de informação, em casos de poucas interfaces e menor interação entre sistemas; As vantagens são simples, diretas e fáceis de desenvolver. Utilize o protocolo HTTP pronto para transmissão. Lembramos que, quando fazíamos desenvolvimento em segundo plano na empresa antes, desenvolvíamos principalmente interfaces, e também tínhamos que escrever um grande documento de interface, indicando estritamente quais eram as entradas e saídas. Explique o método de requisição de cada interface e os pontos que precisam ser observados nos parâmetros da solicitação. Por exemplo, o seguinte exemplo:
POSTARhttp://www.httpexample.com/restful/buyer/info/share
A interface pode retornar uma string JSON ou um documento XML. O cliente então processa essas informações retornadas, permitindo um desenvolvimento mais rápido. No entanto, para grandes empresas, quando há muitos subsistemas internos e muitas interfaces, as vantagens do framework RPC são evidentes: antes de tudo, é um link longo, e não há necessidade de apertar a mão três vezes como no http a cada vez, reduzindo a sobrecarga da rede; em segundo lugar, o framework RPC geralmente possui um centro de registro e monitoramento e gestão ricos; Publicação, interfaces offline, expansão dinâmica, etc., são operações não perceptivas e unificadas para o chamador.
resumo
De modo geral, os serviços RPC são principalmente para grandes empresas, enquanto os serviços HTTP são principalmente para pequenas empresas, porque o RPC é mais eficiente e as iterações de desenvolvimento de serviços HTTP serão mais rápidas. Em resumo, o tipo de framework a escolher não é determinado pelo que é popular no mercado, mas sim avaliar o projeto como um todo, para comparar cuidadosamente o impacto dos dois frameworks de desenvolvimento em todo o projeto e, finalmente, decidir qual é o mais adequado para o projeto. Não devemos usar RPC para todos os projetos apenas por usar RPC, mas nos adaptar às condições locais e analisar a situação específica.
|
Publicado em 01/04/2019 14:02:45
|
|
|
|
