RPC is a Remote Procedure Call. Through RPC, we can call methods on other machines like local methods. Users will not feel the communication between servers. RPC plays a very important role in micro-service. Of course RPC is not a necessary way for micro-service. There are other ways to realize this remote call, such as RESTful API. If you have used SOAP, you will feel very similar when using RPC. You can directly call methods on other machines.
With the development of business, our project has gradually evolved from a simple single structure to a micro-service structure. Why should we split it into micro-services? Then let’s talk about the advantages and disadvantages of microservices and monolithic architectures. Let’s take a look at the single structure diagram.
Advantages of Monomer Architecture
- It is easy to deploy, such as projects written by php, as long as a folder is copied to the environment supporting php, java only needs a jar package
- The test is easy, and we can get the results of the whole project as soon as we change one place.
- Load balancing can be solved by quickly deploying multiple identical projects to run on different machines
Disadvantages of Monomer Architecture
- The deployment problem is good for php, but for java projects, it takes a long time to repackage the whole project.
- Code maintenance, because all codes are written in one 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, resulting in difficult maintenance, especially for new employees, this will be the most prone to problems.
- The development efficiency is low. With the continuous change of project requirements and the addition of new functions, the old code is afraid to be deleted casually, resulting in the bulkiness of the whole project, which will increase the time for you to read the code.
- Extensibility, under the condition of high concurrency, we often do not have every function of the whole project under the condition of high flow and high request. Most of the time, a certain function module is used by a large number of people. Under the single structure, we cannot realize distributed expansion for a single function, and we must deploy the whole project together.
It was proposed in 2014, and now many domestic companies have used it. Microservices are an architectural design, not a framework or a substitute. What microservices do is to split the services according to the granularity of the projects and take out 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 developed independently by different personnel without loose coupling, independent deployment can start a single service without relying on the overall project, and distributed management. Every service just needs to do its own thing. When designing microservices, it is also necessary to consider the problem of databases, whether all microservices use a common database or a single database for each service.
Advantages of microservices
- Split the business, divide the whole large project into different small projects and run them on different processes or machines to realize data isolation.
- Technology stack, each service can be developed by a different team or developer. External callers do not need to worry about how to implement it. They only need to pas s it according to the parameters given by the service provider like calling their own methods or interfaces.
- Deploy independently. Each service is deployed independently. Deploying one service will not affect the overall project. If the deployment fails, the most is the lack of functions of this service, which will not affect the use of other functions.
- Deploy on demand. According to different requirements, you can freely expand servers for different services, and deploy instances that meet the requirements according to the scale of services.
- Local modification, when a service has new requirements or other modifications, it is not necessary to modify the overall project as long as you manage your own service.
Shortcomings of microservices
- Operation and maintenance, micro-service may be deployed on different machines due to the division of business, so the cost of this part will increase for the management of operation and maintenance personnel.
- Interface adjustment, micro-services communicate through the interface. If the API of a microservice is modified, all microservices using the interface may need to be adjusted.
- Repeated labor, many services may use the same function. However, this function has not reached the level of decomposition into a micro-service. At this time, each service may develop this function, resulting in code duplication.
- Distributed, because different services will be deployed on different machines, it is a great challenge to call these services, fault tolerance, network delay, distributed transactions, etc. Of course, micro services may not all be deployed on different servers.
As shown in the above figure, RPC is used for communication between callers and services. RPC protocol can be implemented based on TCP, UDP or HTTP, but TCP is more recommended.
For example, the caller can call the commodity service through RPC or RESTful API, so what is the difference between RPC call and RESTful API?
- TCP’s support keeps the connection and does not require three-way handshake every time when calling the service. RPC has good advantages in terms of performance and network consumption.
- The RESTful API is based on HTTP, which means that every call to a service requires three-way handshake to establish communication before the call can be realized. When our concurrency is high, this wastes a lot of bandwidth resources.
- The RESTful API is more advantageous than RPC for external services, so it depends on whether your team’s services are internal or external.
RPC calling procedure
RPC is mainly used for service invocation
As the first use scenario of RPC, this paper describes the single architecture and micro-service. This is a usage scenario of RPC, and it is also the most commonly used usage scenario. Only when we know what RPC is used and in what scene can we use it better.
Swoft provides us with RPC’s underlying services. we don’t need to care about the underlying communication details and the calling process.
Swoft implements the interface by defining the interface and starts RPC Server to provide interface services. We only need to write several classes to implement a simple RPC module.