RPC is a Remote Procedure Call. Through RPC, we can call methods on other machines just like calling local methods. Users will not feel the communication between the server and the server. RPC plays a considerable role in microservices. Of course, RPC is not a way of microservices. There are other ways to implement remote calls such as RESTful APIs. If you have used SOAP then you will feel very similar to using RPC, you can directly call methods on other machines.
As the business develops, our project evolves from a simple single structure to a micro-service structure. Why do we split it into micro-services? Then let's talk about the advantages and disadvantages of microservices and single architecture. Let's take a look at the single architecture diagram.
Single architecture advantages
- Easy to deploy, such as php to write a project, as long as a folder is copied to the environment that supports php, java only needs a jar package
- Testing is easy, we can test the results as soon as we change a whole project.
- Load balancing can be solved, quickly deploying multiple identical projects and running offloads on different machines.
Disadvantages of single architecture
- Deployment problem, this is fine for php, but for java projects, the time it takes us to repackage the entire project is very long.
- Code maintenance, because all the code is written in a project, if you want to modify a certain function point, you need to have a deep understanding of the overall logic and design of the project. Otherwise, the code coupling is serious, which makes maintenance difficult, especially for new recruits. This is the place where employees are the most prone to problems.
- The development efficiency is low. As the project requirements change and new functions are added, the old code does not dare to delete it casually, which causes the whole project to become cumbersome, which will increase the time for reading the code.
- Scalability, in the case of high concurrency, we often do not have every function of the entire project in the case of high traffic and high requests. In many cases, the number of users using a certain functional module is relatively large. Under the single structure, we There is no way to implement distributed extensions for a single function, and the entire project must be deployed together.
It was proposed in 2014 and is now used by many companies in China. Microservices are an architectural design, not a framework or a replacement. What microservices do is split the service according to the granularity of the project, and take the modules separately to make each individual small project. The main features of microservices are: each functional module is a small project, running independently on different processes or machines, different functions can be different, and different developers can develop independent development. Independent deployment can start a single without relying on the overall project. Service, distributed management. Every service just needs to do its own thing. When designing microservices, you also need to consider the database problem, whether all microservices use a common database or a single database for each service.
- Split the business, split the whole big project into different small projects and run on different processes or machines to achieve data isolation
- Technology stack, each service can be developed by different teams or developers, external callers do not need to worry about how to achieve specific, just need to call their own methods or interfaces to pass the parameters given by the service provider
- Independent deployment, each service is deployed independently, deploying a service does not affect the overall project. If the deployment fails, the function of the service is missing, and the use of other functions is not affected.
- Deploy on demand, freely expand servers for different services for different needs, and deploy instances that meet the needs according to the scale of the service.
- Partial modification, when a service has new requirements or other modifications, it is not necessary to modify the overall project as long as it manages its own services.
- Operation and maintenance, micro-services can be deployed on different machines because of the fine separation of services. Therefore, for the management of operation and maintenance personnel, the cost of this part will increase.
- Interface adjustment, micro-service communication through the interface. If you modify the API of a microservice, all microservices that use this interface may need to be adjusted;
- Repeated labor, many services may use the same function. And this function does not reach the degree of decomposition into a micro-service, at this time, each service may develop this function, resulting in code duplication.
- Distributed, because different services are deployed on different machines, calls to these services, fault tolerance, network latency, distributed transactions, etc. are all big challenges. Of course, microservices are not all deployed in different ways. On the server
As shown in the figure above, RPC is used for communication between the caller and the service. The RPC protocol can be implemented based on TCP, UDP or HTTP, but TCP is more recommended.
For example, if the caller needs to call the service of the product, it can be called through RPC or RESTful API. So what is the difference between RPC call and RESTful API?
- TCP supports long connections. It is not necessary to perform a three-way handshake every time when calling a service. RPC has a good advantage in terms of performance and network consumption.
- The RESTful API is based on HTTP, which means that each call to the service requires a three-way handshake to establish communication before the call can be made. This wastes a lot of bandwidth resources when our concurrency is high.
- If the service is external, the RESTful API will have more advantages than RPC, so whether the service of the team is internal or external
RPC calling process
The main role of RPC is for service calls.
This article is a pioneering use of RPC, and a description of the single architecture and microservices. This is a usage scenario for RPC and one of the most common usage scenarios. Everyone can only understand how RPC is used in what scenarios to use.
Swoft provides us with the underlying services of RPC, we don't need to care about the underlying communication details and the calling process.
Swoft implements the interface by defining an interface, and starts the RPC Server to provide interface services. We only need to write a few classes to implement a simple RPC module.