Restful foi usado demais. Existe uma sensação de estar sobrecarregado com a interface? A interface ainda não está pronta, é só esperar. Foda-se peixe e pegue camarão, pergunte aos irmãos se acabou, a resposta não é boa, nada é feito hoje, 1, 2, 3, 4, sexta está tudo bem, você está louco para testar um monte de perguntas aqui, ok , fazer hora extra nos fins de semana, isso é normal.
RPC é uma abreviatura de Remote Procedure Call. O princípio da chamada RPC do sistema SAP é realmente muito simples. Existem alguns sistemas C / S semelhantes à arquitetura de três camadas. O programa cliente de terceiros chama o padrão interno SAP ou funções personalizadas por meio da interface e obtém os dados retornados por a função a ser exibida ou exibida após o processamento. RPC é principalmente para resolver o problema de chamada entre software e processos múltiplos, e para resolver a comunicação entre software e hardware, CORBA ( CORBA (Common ObjectRequest Broker Architecture) é uma organização padrão orientada a objetos desenvolvida pela organização OMG . Sistema de programa de aplicação Em outras palavras, a estrutura do sistema CORBA é uma solução proposta pela Organização de Gerenciamento de Objetos (OMG) para resolver a interconexão de sistemas de hardware e software no Ambiente de Processamento Distribuído (DCE); a organização OMG é uma organização internacional sem fins lucrativos , sua responsabilidade é fornecer uma estrutura pública para o desenvolvimento de aplicativos , formular diretrizes da indústria e especificações de gerenciamento de objetos e acelerar o desenvolvimento de tecnologia de objetos. ).
índice
Por que o RPC substitui a chamada de serviço da interface RESTFul
princípio
Por meio do IPC e do RPC, os programas podem usar outros programas ou processos de computador. A computação de modelo cliente / servidor usa chamada de procedimento remoto junto com outras tecnologias (como passagem de mensagens) como um mecanismo de comunicação entre sistemas. Os clientes executam suas próprias tarefas, mas contam com o servidor para fornecer serviços de arquivo de back-end. O RPC fornece um mecanismo de comunicação para os clientes solicitarem serviços do servidor back-end, conforme mostrado na Figura R-4. Se você pensar em um aplicativo cliente / servidor como um programa separado, o servidor pode executar a parte de acesso aos dados porque é o mais próximo dos dados, e o cliente pode executar a parte front-end da apresentação de dados e interação do usuário. Desta forma, a chamada de procedimento remoto pode ser considerada como um componente que reorganiza o programa dividido através da rede. LPC às vezes é chamado de mecanismo de acoplamento (Coupling).
A divisão do programa dessa forma elimina a necessidade de copiar todo o banco de dados ou a maioria de seus programas para o sistema do usuário sempre que o usuário desejar acessar os dados. Na verdade, o servidor apenas processa a solicitação e até mesmo executa apenas alguns cálculos de dados e, em seguida, envia os resultados ao usuário. Como a sincronização do banco de dados é fácil de conseguir quando os dados são armazenados em um lugar, vários usuários podem acessar os mesmos dados ao mesmo tempo.
O ambiente de computação distribuída é um cluster de computador conectado por um sistema de comunicação - uma rede . É fácil pensar nessa rede como uma plataforma de computação.Se for um método ponto a ponto, qualquer computador pode se tornar um cliente ou um servidor. Algumas tarefas de processamento podem ser divididas em programas independentes em execução para serem processados em paralelo em diferentes computadores da rede , e os programas independentes são entregues ao computador mais adequado para essa tarefa para processamento. Essa estratégia pode fazer uso de recursos ociosos do computador e melhorar a eficiência da rede. Uma rede corporativa típica inclui muitos sistemas de computador heterogêneos executando diferentes sistemas operacionais.
Com o surgimento das redes corporativas, os desenvolvedores devem compilar programas que podem ser executados em vários protocolos de comunicação de rede e computador . Agora as pessoas estão tentando tornar as chamadas de procedimento remoto independentes, o que significa que os desenvolvedores não precisam considerar a rede subjacente e o protocolo usado para a transmissão de dados na rede. A seguir está descrito o RPC no ambiente de computação distribuída Open Software Fund (OSF) (DCC) Métodos de implementação relacionados. O RPC funciona em uma variedade de ambientes de computação distribuída.
inscrição
RPC tem uma ampla gama de aplicativos na construção de ambiente de sistema e design de aplicativo em sistemas distribuídos, e seus aplicativos incluem o seguinte:
- Comunicação entre processos de sistema operacional distribuído
A comunicação entre processos é um dos recursos básicos que o sistema operacional deve fornecer. O sistema operacional distribuído deve fornecer um mecanismo de comunicação entre processos em máquinas de nós heterogêneos. RPC é um dos meios para realizar a comunicação distribuída entre processos da mensagem modo de transmissão.
- Construindo um ambiente de software para computação distribuída
Devido à distribuição geográfica do próprio ambiente de software distribuído, há um grande número de interações e comunicações entre seus vários componentes, e o RPC é um de seus métodos básicos de implementação. Os dois ambientes de software de computação distribuída populares, ONC + e DCE, são construídos usando RPC, e alguns outros ambientes de software distribuído também usam RPC.
- Serviço de banco de dados remoto
Em um sistema de banco de dados distribuído, o banco de dados geralmente reside no servidor e o cliente acessa o servidor de banco de dados por meio da função de serviço de banco de dados remoto.O serviço de banco de dados remoto existente usa o modo RPC. Por exemplo, Sybase e Oracle fornecem um mecanismo de procedimento armazenado.O sistema e os procedimentos armazenados definidos pelo usuário são armazenados no servidor de banco de dados, e o usuário usa o modo RPC para chamar o procedimento armazenado no cliente.
- Design de aplicativo distribuído
O mecanismo RPC e as ferramentas RPC fornecem meios e conveniência para o design de aplicativos distribuídos.Os usuários podem usar diretamente as ferramentas RPC para criar aplicativos distribuídos sem conhecer a estrutura da rede e os detalhes do protocolo.
- Depuração de programas distribuídos
O RPC pode ser usado para depurar programas distribuídos. Use RPC reverso para tornar o servidor um cliente e emitir RPC para seu processo cliente, que pode depurar programas distribuídos. Por exemplo, se você executar um depurador remoto no servidor, ele receberá continuamente o RPC do cliente. Quando encontrar um ponto de interrupção do depurador, ele enviará de volta um RPC ao cliente para notificar que o ponto de interrupção foi atingido. Este também é o RPC usado para o processo. Exemplos de comunicação.
quadro
Existem principalmente as seguintes estruturas RPC de código aberto vinculadas à plataforma de linguagem.
- RMI: Implementado usando o pacote java.rmi, baseado no Java Remote Method Protocol (Java Remote Method Protocol) e serialização nativa do Java.
- Hessian: Uma ferramenta remota leve em HTTP que fornece funções RMI de uma maneira simples. Baseado no protocolo HTTP, usando codec binário.
- Protobuf: biblioteca de classes Java que fornece uma estrutura para invocação de método remoto com base no protocolo de buffers de protocolo do Google. Com base na tecnologia NIO subjacente da Netty. Suporta reutilização / keep-alive de TCP, criptografia SSL, operação de cancelamento de chamada RPC, log integrado e outras funções.
- Dubbo: O primeiro framework RPC de código aberto na China, desenvolvido pela Alibaba e de código aberto no final de 2011, oferece suporte apenas à linguagem Java.
- Motan: O framework RPC usado internamente pelo Weibo teve o código aberto em 2016 e suporta apenas a linguagem Java.
- Tars: O framework RPC usado internamente pela Tencent foi de código aberto em 2017 e suporta apenas a linguagem C ++.
- Spring Cloud: a estrutura RPC de código aberto estrangeiro da Pivotal em 2014, que oferece suporte apenas à linguagem Java
A estrutura RPC de código aberto de plataforma cruzada tem principalmente os seguintes tipos.
- gRPC: framework RPC de código aberto entre linguagens do Google em 2015, com suporte a vários idiomas.
- Thrift: originalmente era um framework RPC cross-language para sistemas internos desenvolvido pelo Facebook. Em 2007, ele contribuiu para a Apache Foundation e se tornou um dos projetos de código aberto Apache, com suporte a vários idiomas.
Se o seu cenário de negócios estiver limitado a apenas um idioma, você pode escolher uma das estruturas RPC vinculadas ao idioma;
Se envolver chamadas mútuas entre plataformas de vários idiomas, uma estrutura RPC de plataforma cruzada deve ser escolhida.
Framework RPC, qual é a diferença específica entre eles?
Dubbo
Vamos falar primeiro sobre o Dubbo. Pode-se dizer que o Dubbo foi o primeiro framework RPC de código aberto na China. Atualmente, ele suporta apenas a linguagem Java. Sua arquitetura pode ser mostrada na figura a seguir.
Como você pode ver na figura, a arquitetura do Dubbo contém principalmente quatro funções, entre as quais Consumidor é o consumidor do serviço, Provedor é o provedor do serviço, Registro é o centro de registro e Monitor é o sistema de monitoramento.
O processo de interação específico é que, após o lado do Consumidor obter o nó do Provedor por meio da central de registro, ele estabelece uma conexão com o Provedor por meio do SDK do cliente do Dubbo e inicia uma chamada. O Provedor recebe a solicitação do Consumidor por meio do SDK do servidor Dubbo e retorna o resultado ao Consumidor após o processamento.
gato
Motan é outro framework RPC de código aberto bem conhecido na China. Ele também suporta apenas a implementação da linguagem Java. Sua arquitetura pode ser descrita na figura a seguir.
Motan e Dubbo têm arquiteturas semelhantes, e ambos precisam introduzir SDK no lado do cliente (consumidor de serviço) e no lado do servidor (provedor de serviço). O framework Motan inclui principalmente os seguintes módulos funcionais.
registrar: Usado para interagir com o centro de registro, incluindo funções como serviço de registro, serviço de assinatura, notificação de mudança de serviço e envio de pulsação de serviço.
protocolo: usado para descrever o serviço RPC e configurar o gerenciamento do serviço RPC.Esta camada também pode adicionar filtros com diferentes funções para completar funções como estatísticas e restrições de simultaneidade.
serializar: serializar e desserializar os parâmetros, resultados e outros objetos na solicitação RPC
transporte: Usado para comunicação remota.O modo de link longo TCP do Netty NIO é usado por padrão.
cluster: Ao solicitar, um servidor disponível será selecionado para iniciar chamadas remotas de acordo com diferentes estratégias de alta disponibilidade e balanceamento de carga.
Tars
Tars é um projeto de código aberto resumido pela Tencent com base na prática interna de uso de arquitetura de microsserviços por muitos anos. Ele suporta apenas a linguagem C ++. Seu diagrama de arquitetura é o seguinte.
A interação da arquitetura do Tars inclui principalmente os seguintes processos:
Processo de liberação do serviço: carregue o pacote de liberação do servidor para o patch no sistema da web. Depois que o upload for bem-sucedido, envie a solicitação do servidor de liberação na web, que é comunicada ao nó pelo serviço de registro e, em seguida, o nó puxa o servidor libere o pacote para o local para iniciar o serviço do servidor.
Processo de comando de gerenciamento: no sistema da web, você pode enviar solicitações de comando de serviço do servidor de gerenciamento, que são transmitidas pelo serviço de registro ao serviço do nó e, em seguida, o nó envia comandos de gerenciamento ao servidor.
Processo de relatório de pulsação: depois que o serviço do servidor estiver em execução, ele relatará periodicamente a pulsação ao nó e, em seguida, o nó relatará as informações de pulsação do serviço ao serviço de registro, que é gerenciado pelo registro.
Processo de relatório de informações: depois que o serviço do servidor é executado, ele reporta estatísticas periodicamente para stat, imprime logs remotos para registrar, relata regularmente informações de atributo para prop, relata informações de exceção para notificar e extrai informações de configuração de serviço da configuração.
Processo de servidor de acesso do cliente: O cliente pode acessar o servidor indiretamente por meio do nome de objeto Obj do servidor. O cliente obterá as informações de roteamento do servidor (como informações de IP e porta) do registro e, em seguida, de acordo com as características específicas do negócio ( síncrono ou assíncrono, TCP ou UDP) Método) Acessar o servidor (Obviamente, o cliente também pode acessar diretamente o servidor via IP / Porta).
Spring Cloud
Spring Cloud usa recursos do Spring Boot para integrar componentes excepcionais na indústria de código aberto e fornece um conjunto de soluções de governança de serviço na arquitetura de microsserviço como um todo.
Suporta apenas a plataforma da linguagem Java, e seu diagrama de arquitetura pode ser descrito pelo diagrama a seguir.
Pode-se ver que a arquitetura de microsserviço do Spring Cloud é composta por vários componentes, e o processo de interação de cada componente é o seguinte.
As solicitações de acesso unificado a serviços internos por meio do gateway de API Zuul, primeiro passam por Token para autenticação de segurança.
Depois de passar pela autenticação de segurança, o gateway Zuul obtém a lista de nós de serviço disponíveis do centro de registro Eureka.
Selecione um nó disponível a partir dos nós de serviço disponíveis e, em seguida, distribua a solicitação para este nó.
Durante todo o processo de solicitação, o componente Hystrix é responsável por lidar com a fusão do tempo limite do serviço, o componente Turbina é responsável por monitorar as chamadas e combinar indicadores relacionados entre os serviços, o componente Sleuth é responsável pelo monitoramento da cadeia de chamadas e ELK é responsável pela análise de log .
gRPC
Primeiro, olhe para gRPC, seu princípio é definir os parâmetros e tipos de valor de retorno da interface de serviço por meio de arquivos IDL (Interface Definition Language) e, em seguida, gerar o código de implementação específico do servidor e do cliente por meio do programa de geração de código, para que no gRPC, o cliente O aplicativo pode chamar o método correspondente em outro servidor da mesma forma que chama um objeto local.
Suas principais características incluem três aspectos.
O protocolo de comunicação usa HTTP / 2, porque HTTP / 2 fornece mecanismos para multiplexação de conexão, streaming bidirecional, push de servidor, prioridade de solicitação, compactação de cabeçalho, etc.
O IDL usa o ProtoBuf. O ProtoBuf é um protocolo de serialização de dados desenvolvido pelo Google. Ele tem uma eficiência de compressão e transmissão extremamente alta e uma sintaxe simples.
Suporte multilíngue, capaz de gerar automaticamente o código do cliente e do servidor do idioma correspondente com base em vários idiomas.
Thrift
Vamos examinar o Thrift novamente. O Thrift é uma solução leve de comunicação RPC entre linguagens que oferece suporte a até 25 linguagens de programação. Para oferecer suporte a várias linguagens, como gRPC, Thrift também tem seu próprio conjunto de linguagem de definição de interface IDL. O gerador de código pode ser usado para gerar códigos SDK para o cliente e servidor de várias linguagens de programação, de modo a garantir que diferentes linguagens Podem comunicar uns com os outros. Comunique-se uns com os outros. Seu diagrama de arquitetura pode ser descrito com a figura a seguir.
Você pode ver as características da estrutura Thrift RPC nesta imagem.
Suporta vários formatos de serialização: como binário, compacto, JSON, multiplexado, etc.
Suporta vários métodos de comunicação: como Socket, Framed, File, Memory, zlib, etc.
O servidor suporta vários métodos de processamento: Simples, Thread Pool, Non-Blocking, etc.
Por que o RPC substitui a chamada de serviço da interface RESTFul
========== Considerações de segurança: =================
1. A ocultação do endereço RPC, sem necessidade de expor o endereço da API, apenas o público nível de código é necessário, a interface do usuário
2, HTTP inseguro, devemos usar os protocolos de segurança baseados em HTTPS
3, convenção de comunicação interna, API de gerenciamento complicado, atualizações de documentação não são oportunas para publicação de BUG de segurança do aplicativo (problema de incompatibilidade de versão, o subjacente difícil de encontrar )
========== Considerações sobre custos de manutenção: =============
1. Fornece interfaces em vez de implementação, o que essencialmente restringe o comportamento das interfaces sem prestar atenção à implementação interna
2. As mudanças de nível das interfaces podem ser encontradas e ajustadas a tempo, e os problemas
podem ser resolvidos no nível do código. 3. O RPC pode ajustar o endereço de acesso do serviço a qualquer momento. Ele tem recursos de balanceamento de carga natural e é adequado para sistemas distribuídos.
4. RPC tem a capacidade de chamar em ambas as direções. Certos comportamentos não precisam ser reescritos. O código pode ser usado para chamar
5. Você pode deixar de lado um determinado sistema e usar apenas parte de seus recursos sem desenvolvimento secundário. O projeto está pronto para usar (usando configuração de dependência e endereço de serviço RPC de configuração para resolver)
========== Chamada de serviço cruzado: =================
1. No momento, a maioria dos aplicativos está se desenvolvendo na direção de microsserviços. As chamadas serão mais frequente e difundido.
2. É difícil garantir as solicitações entre serviços. Em essência, a camada inferior do HTTP também é implementada pelo protocolo TCP. Ele também estabelecerá uma conexão e aguardará a resposta do serviço. Chamadas de alto desempenho .
3. Evite indivisa serviços entre os serviços e as chamadas cadeias. o serviço está indisponível
4. Apenas é necessária a capacidade do serviço, e sem implantação separada é necessária, enquanto RESTFUL exige uma certa habilidade para ser implantada separadamente
5. Não há necessidade de resolver problemas de domínio cruzado, não há necessidade de o Nginx ser um bando de agentes
Ponto problemático: um serviço principal é chamado por vários sistemas de negócios e diferentes serviços são implantados a cada vez para se adaptar às diferenças do projeto. No projeto, chamadas RestTemplate ou HttpClient são usadas todas as vezes. As chamadas de interface precisam ser comunicadas para serem implementadas. projeto principal é devido ao design irracional é freqüentemente reclamado por várias equipes de projeto.A cada vez que uma atualização é lançada, é necessário baixar todos os service packs e substituir os arquivos um por um, o que é muito complicado. Abandone ou mude o método, se não puder ser abandonado: sugiro remover a interface Restful e usar RPC diretamente para definir a chamada da interface. A concepção dos comportamentos de um serviço é clara, estas interfaces podem ser desenvolvidas e invocadas depois de definidas. Porque não? A comunicação é sempre o maior custo, mas é também a melhor forma de reduzir custos.