Easily understand distributed RPC

        Before getting to know the RPC framework, please allow me to introduce a process of the framework used by the project from small to large. This is why more and more companies choose to use microservices and distributed architecture development in today's era. This is my experience in the development process.

  1. Many years ago, it was possible that the amount of project data was not large and the functional modules were not complicated. In order to reduce deployment cost and nodes. Most will choose single application framework (ORM) development

 

Single application frameworks are suitable for small projects (applications, management systems, etc.). Put all functional modules in one system.

advantage:

        1. Simple structure.

        2. Convenient testing and deployment.

        3. The development cost is not high, suitable for small-cost projects.

shortcoming:

        1. Difficult to maintain and develop.

        2. When multiple people develop, it is easy to cause code confusion and bloated code.

        3. Because it is a single computer, the performance of the server is not high.

2. With the continuous development of computers, the number of website views is also gradually increasing. Monolithic application frameworks are no longer sufficient for the current status quo. An application is split into multiple applications, so a vertical application architecture (MVC) appears. Will be each. The application is segmented and deployed independently, and each team is responsible for its own functional modules. This improves the independence of each functional module. The performance of each module is improved, and the maintenance work of developers is also convenient .

 advantage:

        1. The system application is split, which plays a role of shunting and avoids concurrency problems.

        2. It is convenient for the members of each group to develop and maintain the modules they are responsible for.

        3. Each application does not affect each other, and new services are easy to increase.

shortcoming:

        1. The calling methods between services are not uniform.

        2. The system is not convenient for unified monitoring.

        3. Each application in the system calls each other. If one party's IP or routing address and port number change, developers need to manually adjust the system.

        4. Because each application is highly independent, it is difficult to maintain the interaction of each application module.

3. With more and more vertical application architectures, interaction becomes very difficult. In order to make the front-end page respond faster, and to support multiple needs and changeable conditions, extract the core business module as an independent service, and gradually form a stable service center, then how to improve the business integration function, the distributed service framework ( RPC) is extremely critical. Among them, communication and interaction are performed through RPC or webService.

Distributed has two split methods, one is horizontal split and the other is vertical split

1. Split horizontally into . We can split the project into presentation layer (Rest layer can also be called JSP+ServerLet), business layer (Service), and data access layer (DAO). Each layer is then deployed on a different server. This deployment method is a distributed deployment but not a microservice deployment.

2. Vertical splitting is to split an entire business into multiple functional modules such as the user module and log module mentioned above. Then deploy to different servers respectively. This is considered a microservice architecture design, and it also uses distributed deployment.

 At the end of the discussion, some people must have doubts. What is the difference between distributed and microservices? Is it a thing?

Here I want to say that they are not a concept, and they must not be confused.

Distributed means that services are deployed on different servers, and one service can provide multiple functions. It is a system deployment method. Microservices are just an architectural design method. Microservices can be very small services, even a function as small as a microservice, and this service is so powerful that it can be deployed independently and called between different services through RPC.

Distributed deployment is not necessarily a microservice architecture, and microservice applications are not necessarily deployed in a distributed manner. But in actual development, distributed deployments are generally microservice projects.

Then microservices and microservice architecture

The microservices are introduced above, so I won’t make much introduction here.

Here we mainly focus on the microservice architecture, which is divided by architects according to the size of the requirements. If it is an application with a small amount of access, it is enough to develop the architecture with a single body. If there is a large amount of browsing and a large amount of calculation, we need to split the application at this time. This is the microservice architecture.

Having said so much, it is finally time for us to talk about the content today - RPC framework

What are RPCs?

RPC is a protocol for requesting services from remote computer programs over a network without requiring knowledge of the underlying network technology. Simply put, it is because RPC thinks that it is calling a local object, so communication protocols such as HTTP/HTTPS are not needed. And the caller does not need to care about the format of the data passed.

Use an example in life: Your superior calls you to ask for the demand. Then you communicate with your superiors by phone, and this communication method is RPC.

Its advantages:

        1. Cross language

        2. The protocol is private and highly secure

        3. High data transmission efficiency

        4. Support dynamic expansion

shortcoming:

        1. RPC needs to be continuously improved, a typical example is Dubbo

        2. Need a professional team for maintenance

Standards applied to RPC include Dubbo, Thrift, GRPC, and Hetty.

Several core technical points implemented by the RPC framework:

(1) The callee needs to provide information related to service invocation in some form, including but not limited to service interface definition, data structure, or intermediate service definition file. For example, the IDL file of Facebook's Thrift and the WSDL file of Web service; the caller needs to obtain the information related to the remote service call through a certain scene.

(2) Remote proxy object: The service used by the caller is actually the local proxy of the remote service. It is achieved through dynamic proxy.

(3) Communication: The RPC framework has nothing to do with specific network communication protocols.

Expansion: The difference between RPC and other frameworks:

MVC architecture: When the business scale is small, all functions are deployed in the same process, and debt distribution is realized through dual-machine or load balancer; at this time, the MVC architecture that separates front-end and back-end logic is the key.

RPC architecture: When there are more and more vertical applications in the distributed system, and the interaction between applications increases, the core and public services are extracted and used as independent services to realize the logic separation of the front and back. At this time, the RPC framework for improving business reuse and splitting is the key.

SOA architecture: With business development, the number of services is increasing, and service lifecycle control and operational state governance become bottlenecks. At this time, SOA service governance for improving service quality is the key.

Microservice Architecture: Split the application into multiple services.

Guess you like

Origin blog.csdn.net/weixin_51220967/article/details/128370714