What is a distributed system?

  1. A distributed system is a collection of independent computers that act as a single related system to the user
  2. A distributed system is a group of computer nodes that communicate through a network and coordinate their work to accomplish a common task.
  3. The emergence of distributed systems is to use cheap, ordinary machines to complete a single computer can not complete the computation, storage tasks. The aim is to use more machines to process more data

Second, the evolution of current system architecture

With the development of the Internet, the scale of web applications is constantly expanding, and the conventional vertical application architecture has been unable to cope with it. The distributed service architecture and mobile computing architecture are imperative, and only a governance system is needed to ensure the orderly evolution of the architecture.

1. Single application architecture

When site traffic is low, only one application is needed to deploy all functions together to reduce deployment nodes and costs. At this point, data access frameworks (ORM) that simplify the work of adding, deleting, modifying and reviewing are key.

Suitable for small websites, small management systems, all functions are deployed into one function, simple to learn disadvantages:

  • Performance scaling is difficult
  • Collaborative development issues
  • Adverse to Upgrade and Maintenance

2. Vertical application architecture

As traffic increases, the acceleration caused by a single application increases less and less. One way to improve efficiency is to break the application into several unrelated applications to improve efficiency. At this point, a Web framework (MVC) for accelerating front-end page development is key.

Independent deployment of each module is realized through business segmentation, which reduces the difficulty of maintenance and deployment. It is easier for teams to perform their own duties, and performance expansion is more convenient and targeted. Disadvantages:

  • Common modules can not be reused, wasteful development

3. Distributed service architecture

With the increasing number of vertical applications, the interaction between applications is inevitable. Core businesses are extracted as independent services, gradually forming a stable service center, so that front-end applications can respond to changing market demands more quickly. At this point, the ** distributed Services framework (RPC)** for improving business reuse and integration is key.

4. Mobile computing architecture

As the number of services increases, problems such as capacity evaluation and waste of small service resources gradually emerge. In this case, a scheduling center needs to be added to manage cluster capacity in real time based on access pressure to improve cluster utilization. At this point, a resource scheduling and Governance center (SOA) for improving machine utilization is key.

Second, the RPC

There is a story that has been circulating on the Internet, so take a look at this story to give you a better understanding of RPC

How to explain RPC to your wife?

One sunny morning, my wife was reading my subscription to a technology magazine.

“Husband, what is RPC ah, why do you programmer so much slang!” The wife is as curious as ever. “RPC stands for Remote Procedure Call,” I answered carelessly while reading the book. “What? What are you talking about? Who doesn’t know what it means to translate into Chinese? Go wash the dishes, you loser!” “I’ll go…” , I woke up like a dream, I sat opposite is not a programmer, in order not to wash the dishes, I instantly mobilize all brain cells, the stars of the sea in my mind together, inspiration……

“Well, remote procedure call, as opposed to local procedure call.” “Well, tell me what a local procedure call is.” “Local procedure calls are like when you’re at home, and you want to do the dishes, you just put them in the dishwasher, turn them on and do them. This is called a local procedure call.”

“Oh, no, what is a remote procedure call?” A remote procedure call is when you’re out with your sisters and you notice the dishes haven’t been washed, you call me and ask me to do the dishes.

“Oh! I see, “the wife began to pack her bag. “What are you doing?” “Me? I’m on my way out, and I’ll receive my remote call later. Oh, no, let’s be professional. I should say, I’ll receive my RPC later.” .

Okay, back to the point, you must have a certain impression

What is the RPC

  • Remote Procedure Call (RPC) is a method of communication between processes. It is a technical idea, not a specification. It allows a program to call a procedure or function in another address space, usually on another machine on a shared network, without the programmer explicitly coding the details of this remote call. That is, programmers write essentially the same calling code whether they call local or remote functions.
  • It is a protocol that requests services from remote computer programs over a network, without the need to understand the underlying network technology. In other words, two servers A and B have one application deployed on server A. If they want to call the method provided by the application on server B, they cannot call it directly because they do not have the same memory space. Therefore, they need to express the call semantics and transfer the call data over the network

Working Principle of RPC

There are two types of RPC calls:

  • Synchronous invocation: The client waits for the invocation to complete and returns the result.
  • Asynchronous invocation: the client does not have to wait for the execution result to return after the invocation, but can still get the return result through callback notification. If the client does not care about the return of the call, it becomes a one-way asynchronous call, and the one-way call does not return the result.

A complete RPC call flow (synchronous call, asynchronous call separately) is as follows:

1) Service consumer (Client) invocation invokes the service in a local invocation mode;

2) After receiving the call, the Client stub is responsible for assembling methods and parameters into a message body capable of network transmission;

3) The client stub finds the service address and sends the message to the server.

4) The Server Stub decodes the message after receiving it.

5) The Server Stub invokes the local service according to the decoding result;

6) The local service executes and returns the result to the server stub;

7) The Server Stub packages the returned result into a message and sends it to the consumer;

8) The Client stub receives the message and decodes it.

9) The service consumer gets the final result.

The goal of the RPC framework is to encapsulate steps 2 through 8 and make these details transparent to the user.