1. Why are there RPC in ten million traffic distributed and microservice architectures?
Protocol structure
The remote Procedure Call (RPC) message protocol consists of two different structures: call message and reply message. The information flow is as follows:
RPC: Remote procedure call flow
RPC call information: Each remote procedure call information includes the following unsigned integer fields to independently identify the remote procedure:
Program Number
Program Version Number
Procedure Number
The main form of RPC call information is as follows:
struct call_body {
unsigned int rpcvers;
unsigned int prog;
unsigned int vers;
unsigned int proc;
opaque_auth cred;
opaque_auth verf;
1 parameter
2 parameter..};
RPC reply message: The reply message of the RPC protocol changes depending on whether the network server accepts or rejects the call message. Responses to requests for information include information that distinguishes between:
The RPC successfully executed the call message. .
The remote implementation of RPC is not protocol Version 2 and returns the lowest and highest version numbers supported by RPC.
Remote programs are not available on remote systems.
The requested version number is not supported by the remote program. Returns the lowest and highest version numbers supported by the remote program.
The requested procedure number does not exist. Usually there is a caller protocol or program error.
The form of RPC reply information is as follows:
enum reply_stat stat
{MSG_ACCEPTED = 0,
MSG_DENIED = 1};
2. What is RPC?
RPC stands for Remote Procedure Call, which translates to “Remote Procedure Call”. It is a protocol that requests services from remote computer programs over a network, without the need to understand the underlying network technology. The RPC protocol assumes the existence of some transport protocol, such as TCP or UDP, to carry information data between communication programs. In the OSI network communication model, RPC spans both the transport layer and the application layer. RPC makes it easier to develop applications including network distributed multiprograms.
3. Differentiate RPC from HTTP
4. What problems do we need to solve to implement RPC framework?
Specific problems specific analysis, each solution and implementation!
The working principle of
At runtime, a client-to-server RPC call has roughly the following ten steps:
1. Invoke the client handle. Execute transfer parameters
2. Invoke the local kernel to send network messages
3. The message is sent to the remote host
4. The server handle gets the message and the parameters
5. Run the remote procedure
6. The executed procedure returns the result to the server handle
7. The server handle returns the result and invokes the remote system kernel
8. The message is sent back to the local host
9. The client handle receives messages from the kernel
10. The client receives the data returned by the handle
6, to cope with tens of millions of flows, is that enough? Reflect on our implementation.
Which is better, Dubbo or SpringCloud?
Dubbo is an open source distributed service framework of Alibaba. Its most prominent feature is that it is structured in a hierarchical manner, which can be decoupled (or loosened as much as possible) between layers. From the perspective of the service model, Dubbo adopts a very simple model, in which either the Provider provides the service or the Consumer consumes the service, so the roles of Provider and Consumer can be abstracted based on this.
Spring Cloud is an ordered collection of frameworks. It takes advantage of the development convenience of Spring Boot to subtly simplify the development of distributed system infrastructure, such as service discovery registry, configuration center, message bus, load balancing, circuit breakers, data monitoring, etc., which can be started and deployed with one click using Spring Boot’s development style. Spring Cloud does not remanufacture the wheel. It just combines the mature and practical service frameworks developed by various companies and encapsulates them in the Spring Boot style, masking the complex configuration and implementation principles. Finally, a simple and easy to understand, easy to deploy and easy to maintain distributed system development kit was set aside for developers.
8. Class q&A and summary.
Course link: https://ke.qq.com/course/284963
Need to get more video information, source code details, notes, video. Dubbo, Redis, Design Pattern, Netty, ZooKeeper, Spring Cloud, distributed, high concurrency and other architecture technology information