Restful has been used too much, is there a feeling of being overwhelmed by the interface? The interface is not ready yet, just wait. Fuck fish and catch shrimps, ask the brothers if you’re done, the answer is not good, nothing is done today, 1, 2, 3, 4, Friday is all right, you are crazy to test a bunch of questions here, ok, work overtime on weekends, this It's normal.
RPC is an abbreviation of Remote Procedure Call. The principle of SAP system RPC call is actually very simple. There are some C/S systems similar to the three-tier architecture. The third-party client program calls SAP internal standard or custom functions through the interface, and obtains the data returned by the function to display or display after processing. print. RPC is mainly to solve the problem of calling between software and multiple processes, and to solve the communication between software and hardware, CORBA ( CORBA (Common ObjectRequest Broker Architecture) is a standard object-oriented organization developed by the OMG organization. Application program system specification. In other words, the CORBA system structure is a solution proposed by the Object Management Organization (OMG) to solve the interconnection of hardware and software systems in the Distributed Processing Environment (DCE); the OMG organization is an international Non-profit organization , its responsibility is to provide a public framework for application development, formulate industry guidelines and object management specifications, and accelerate the development of object technology. ).
table of Contents
Why RPC replaces the RESTFul interface service call
principle
Through IPC and RPC, programs can use other programs or computer processes. Client/server model computing uses remote procedure call together with other technologies (such as message passing) as a mechanism for communication between systems. Clients perform their own tasks, but rely on the server to provide back-end file services. RPC provides a communication mechanism for clients to request services from the back-end server, as shown in Figure R-4. If you think of a client/server application as a separate program, the server can run the data access part because it is the closest to the data, and the client can run the front-end part of data presentation and user interaction. In this way, the remote procedure call can be regarded as a component that reorganizes the divided program through the network. LPC is sometimes called a coupling (Coupling) mechanism.
By dividing the program in this way, when the user wants to access the data, there is no need to copy the entire database or most of its programs to the user system every time. In fact, the server only processes the request, and even only performs some data calculations, and then sends the results to the user. Because database synchronization is easy to achieve when data is stored in one place, multiple users can access the same data at the same time.
The distributed computing environment is a computer cluster connected by a communication system-a network . It is easy to think of this network as a computing platform . If it is a peer-to-peer method, any computer can become a client or a server. Some processing tasks can be divided into independent running programs to be processed in parallel on different network computers , and the independent programs are handed over to the computer most suitable for this task for processing. This strategy can make use of computer idle resources and improve the efficiency of the network. A typical enterprise network includes many heterogeneous computer systems running different operating systems.
With the emergence of enterprise networks, developers must compile programs that can run in various computer and network communication protocols . Now people are trying to make remote procedure calls independent, which means that developers do not need to consider the underlying network and the protocol used for data transmission on the network. The following describes the RPC in the Open Software Fund (OSF) distributed computing environment (DCC) Related methods of implementation. RPC works in a variety of distributed computing environments.
application
RPC has a wide range of applications in system environment construction and application design in distributed systems, and its applications include the following:
- Interprocess communication of distributed operating system
Inter-process communication is one of the basic facilities that the operating system must provide. The distributed operating system must provide a communication mechanism between processes on heterogeneous node machines. RPC is one of the means to realize the distributed inter-process communication of the message transmission mode. .
- Constructing a software environment for distributed computing
Due to the geographical distribution of the distributed software environment itself, there are a large number of interactions and communications among its various components, and RPC is one of its basic implementation methods. The two popular distributed computing software environments, ONC+ and DCE, are constructed using RPC, and some other distributed software environments also use RPC.
- Remote database service
In a distributed database system, the database generally resides on the server, and the client accesses the database server through the remote database service function. The existing remote database service uses the RPC mode. For example, both Sybase and Oracle provide a stored procedure mechanism. The system and user-defined stored procedures are stored on the database server, and the user uses the RPC mode to call the stored procedure on the client.
- Distributed application design
RPC mechanism and RPC tools provide means and convenience for distributed application design. Users can directly use RPC tools to design distributed applications without knowing the network structure and protocol details.
- Debugging of distributed programs
RPC can be used to debug distributed programs. Use reverse RPC to make the server a client and issue RPC to its client process, which can debug distributed programs. For example, if you run a remote debugger on the server, it continuously receives the client's RPC. When it encounters a debugger breakpoint, it sends back an RPC to the client to notify that the breakpoint has been reached. This is also the RPC used for the process. Examples of communication.
frame
There are mainly the following open source RPC frameworks bound to the language platform.
- RMI: Implemented using the java.rmi package, based on Java Remote Method Protocol (Java Remote Method Protocol) and Java's native serialization.
- Hessian: A lightweight remoting onhttp tool that provides RMI functions in a simple way. Based on HTTP protocol, using binary codec.
- Protobuf: Java class library that provides a framework for remote method invocation based on Google's Protocol Buffers protocol. Based on the underlying NIO technology of Netty. Support TCP reuse/keep-alive, SSL encryption, RPC call cancel operation, embedded log and other functions.
- Dubbo: The earliest open source RPC framework in China, developed by Alibaba and open sourced at the end of 2011, only supports the Java language.
- Motan: The RPC framework used internally by Weibo was open sourced in 2016 and only supports the Java language.
- Tars: The RPC framework used internally by Tencent was open sourced in 2017 and only supports the C++ language.
- Spring Cloud: The foreign open source RPC framework of Pivotal in 2014, which only supports Java language
The cross-language platform open source RPC framework mainly has the following types.
- gRPC: Google's open source cross-language RPC framework in 2015, supporting multiple languages.
- Thrift: It was originally a cross-language RPC framework for internal systems developed by Facebook. In 2007, it contributed to the Apache Foundation and became one of the Apache open source projects, supporting multiple languages.
If your business scenario is limited to only one language, you can choose one of the language-bound RPC frameworks;
If it involves mutual calls between multiple language platforms, a cross-language platform RPC framework should be chosen.
RPC framework, what are the specific differences between them?
Dubbo
Let's talk about Dubbo first. Dubbo can be said to be the earliest open source RPC framework in China. Currently, it only supports the Java language. Its architecture can be shown in the following figure.
As you can see from the figure, Dubbo's architecture mainly contains four roles, among which Consumer is the service consumer, Provider is the service provider, Registry is the registration center, and Monitor is the monitoring system.
The specific interaction process is that after the Consumer side obtains the Provider node through the registration center, it establishes a connection with the Provider through Dubbo's client SDK and initiates a call. The Provider receives the Consumer's request through Dubbo's server SDK, and returns the result to the Consumer after processing.
tomcat
Motan is another well-known open source RPC framework in China. It also only supports Java language implementation. Its architecture can be described in the following figure.
Motan and Dubbo have similar architectures, and both need to introduce SDK on the Client side (service consumer) and Server side (service provider). The Motan framework mainly includes the following functional modules.
register: Used to interact with the registration center, including functions such as registration service, subscription service, service change notification, and service heartbeat sending.
protocol: Used to describe the RPC service and configure the management of the RPC service. This layer can also add filters with different functions to complete functions such as statistics and concurrency restrictions.
serialize: serialize and deserialize the parameters, results and other objects in the RPC request
transport: Used for remote communication. The TCP long link mode of Netty NIO is used by default.
cluster: When requesting, an available Server will be selected to initiate remote calls according to different high availability and load balancing strategies.
Tars
Tars is an open source project summarized by Tencent based on the internal practice of using microservice architecture for many years. It only supports the C++ language. Its architecture diagram is as follows.
Tars' architecture interaction mainly includes the following processes:
Service release process: upload the server release package to the patch on the web system. After the upload is successful, submit the release server request on the web, which is communicated to the node by the registry service, and then the node pulls the server release package to the local to start the server service.
Management command process: On the web system, you can submit management server service command requests, which are transmitted by the registry service to the node service, and then the node sends management commands to the server.
Heartbeat reporting process: After the server service is running, it will periodically report the heartbeat to the node, and then the node will report the service heartbeat information to the registry service, which is managed by the registry.
Information reporting process: After the server service runs, it will periodically report statistics to stat, print remote logs to log, regularly report attribute information to prop, report exception information to notify, and pull service configuration information from config.
Client access server process: The client can access the server indirectly through the object name Obj of the server. The client will pull the server's routing information (such as IP and Port information) from the registry, and then according to the specific business characteristics (synchronous or asynchronous, TCP or UDP) Method) Access the server (Of course, the client can also directly access the server via IP/Port).
Spring Cloud
Spring Cloud uses Spring Boot features to integrate outstanding components in the open source industry, and provides a set of service governance solutions in the microservice architecture as a whole.
Only supports the Java language platform, and its architecture diagram can be described by the following diagram.
It can be seen that the Spring Cloud microservice architecture is composed of multiple components, and the interaction process of each component is as follows.
Requests for unified access to internal services through the API gateway Zuul, first go through Token for security authentication.
After passing the security authentication, the gateway Zuul obtains the list of available service nodes from the registration center Eureka.
Select an available node from the available service nodes, and then distribute the request to this node.
During the entire request process, the Hystrix component is responsible for handling service timeout fusing, the Turbine component is responsible for monitoring the calls and fusing related indicators between services, the Sleuth component is responsible for call chain monitoring, and ELK is responsible for log analysis.
gRPC
First look at gRPC, its principle is to define the parameters and return value types of the service interface through IDL (Interface Definition Language) files, and then generate the specific implementation code of the server and the client through the code generation program, so that in gRPC, the client The application can call the corresponding method on another server just like calling a local object.
Its main characteristics include three aspects.
The communication protocol uses HTTP/2, because HTTP/2 provides mechanisms for connection multiplexing, bidirectional streaming, server push, request priority, header compression, etc.
IDL uses ProtoBuf. ProtoBuf is a data serialization protocol developed by Google. It has extremely high compression and transmission efficiency and simple syntax.
Multi-language support, able to automatically generate the client and server code of the corresponding language based on multiple languages.
Thrift
Let's look at Thrift again. Thrift is a lightweight cross-language RPC communication solution that supports up to 25 programming languages. In order to support multiple languages, like gRPC, Thrift also has its own set of interface definition language IDL. The code generator can be used to generate SDK codes for the Client and Server of various programming languages, so as to ensure that different languages can communicate with each other. Communicate with each other. Its architecture diagram can be described with the following figure.
You can see the characteristics of the Thrift RPC framework from this picture.
Support multiple serialization formats: Binary, Compact, JSON, Multiplexed, etc.
Support multiple communication methods: such as Socket, Framed, File, Memory, zlib, etc.
The server supports multiple processing methods: Simple, Thread Pool, Non-Blocking, etc.
Why RPC replaces the RESTFul interface service call
==========Security considerations: =================
1. The concealment of the RPC address, no need to expose the API address, only the public code level needs to be provided the user interface
2, HTTP unsafe, we must use the HTTPS-based security protocols
3, internal communication convention, cumbersome management API, documentation updates are not timely publishing application security BUG (version mismatch problem, the underlying hard to find)
==========Maintenance cost considerations: =============
1. Provide interfaces instead of implementation, which essentially constrains the behavior of interfaces without paying attention to internal implementation
2. Interfaces Level changes can be found and adjusted in time, and problems
can be solved at the code level. 3. RPC can adjust the service access address at any time. It has natural load balancing capabilities and is suitable for distributed systems.
4. RPC has the ability to call in both directions. Certain behaviors do not need to be rewritten. The code can be used to call
5. You can put aside a certain system and only use part of its capabilities without secondary development. The project is ready to use (using dependency configuration and configuration RPC service address to solve)
==========Cross-service call: =================
1. At present, most applications are developing in the direction of microservices. Calls will be more frequent and widespread.
2. It is difficult to guarantee the requests between services. In essence, the bottom layer of HTTP is also implemented by the TCP protocol. It will also establish a connection and wait for the service response. High-performance calls.
3. Avoid undivided services between services and chain calls. The service is unavailable
4. Only the ability of the service is required, and no separate deployment is required, while RESTFUL requires a certain ability to be deployed separately
5. No need to solve cross-domain problems, no need for Nginx to be a bunch of agents
Pain point: A core service is called by multiple business systems, and different services are deployed each time to adapt to project differences. In the project, RestTemplate or HttpClient calls are used every time. Interface calls need to be communicated to be implemented. This core project is due to Unreasonable design is often complained by multiple project teams. Every time an upgrade is released, it is necessary to download all the service packs and replace the files one by one, which is very cumbersome. Either abandon or change the method, if it cannot be abandoned: I suggest to remove the Restful interface and directly use RPC to define the interface call. The design of the behaviors of a service is clear. These interfaces can be developed and invoked after they are defined. Why not do it? Communication is always the biggest cost, but it is also the best way to reduce costs.