Architecture evolution

  • All interfaces and services are in the same process

  • Mvc-based views are separated from services, but they are still in the same application, but more finely divided at the functional level

  • It is more granular, shred and deployed separately for different functional services

  • Service-oriented architecture connects different functional units of an application (called services) through well-defined interfaces and contracts between these services

  • Micro service

    Image display is not supported here, imagine by yourself!!

With the increase of business volume and users, the architecture is also moving from a single system to a distributed system. I can think of the main problems solved by the evolution of this architecture:

  • Through the separation of business modules, the responsibilities of each module are more clear, but the division of responsibility boundaries of modules is often very painful.
  • Meticulous division makes the project management more aspects, from the perspective of code, development and maintenance costs will also be reduced, not because of a bug to run the entire project.
  • It improves the fault tolerance rate of the system. If a single system goes down, it is really GG. In addition, problems in a single link will also lead to the normal operation of the project (such as database problems). For distributed systems, redundancy is generally used to improve availability. My personal understanding is that multiple services can be provided, and they can be switched between them.
  • One of the problems with distributed systems is cost, hardware cost, operation cost.

Introduction to RPC and common RPC frameworks

With the transformation from centralized architecture to distributed architecture, service invocation and communication between application systems become the primary demand to be solved.

The main goal of RPC is to make it easier to build distributed computing (applications) without losing the semantic simplicity of local calls while providing powerful remote call capabilities. To achieve this goal, the RPC framework needs to provide a transparent call mechanism so that consumers do not have to explicitly distinguish between local and remote calls.

The following code:

@Autowired private GlRpcAgent glRpcAgent; @override public List<OrderInfo> queryOrdersByUserId(Map<String, Object> param) {// Create the remote calling proxy (fully qualified name of the class of the remote service) OrderConsumeAgent orderConsumer= glrpcAgent.getAgent ("com.glmapper.rpc.interface.OrderConsumeInterface"); / / get through agent returns the result GetOrders here for com on the remote server. The glmapper.. RPC interface. OrderConsumeInterface methods on the interface, Param = Map<String,Object> resultMap=(Map)orderConsumer.call("getOrders",param); List<OrderInfo> Orders = parseResultMap(resultMap);return orders;
	}
Copy the code

Why do I get it by a fully qualified name? We’ll talk about that later.

What is the RPC

In distributed computing a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in another address space(commonly on another computer on a shared network), which is coded as if it were a normal (local) procedure call, Without the discrimination coding the details for the remote interaction It is a form of interprocess communication. It allows a program to call a procedure or function on another process, usually 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.

From the definition, RPC solves three main things:

  • Interprocess communication
  • Provides the same invocation mechanism as a local method invocation
  • Shielding programmers from detailed implementation of remote calls

The first is the communication between processes. For the distributed environment, RPC can help us solve the communication and data transmission problems between different servers, that is, to convert method calls to data, and then use the network for data transmission. ** THE RPC client initiates a remote service call to the RPC server, through request encapsulation, parameter encapsulation, serialization, encoding, protocol transmission, request parsing, request processing, encapsulation of returned message data, serialization, encoding of returned data, and return to the client over the network. Moreover is provided and the invocation mechanism of local method calls, why do you say that, for the business system, we more focus is on how to solve the problem of the actual business requirements, and don’t want to spend more time and energy in such as the process of network transmission and the decoding process, so for the RPC, These codecs, protocols, network transmission, etc. need to be packaged as a whole, and then only provide the simplest call method to the business system. Last shielding programmers detail implementation of a remote call, actually is also the second point mentioned the function of packaging, we don’t have to relate to how the RPC, also need not care about how it works, for business development staff, through the agreed way similar to the form of local method calls to invoke the remote service interface. So how do you implement transparent remote calls? What kind of internal encapsulation would make it feel like a local call to a remote service? For Java, this means using a proxy. Java proxies come in two forms: 1) JDK dynamic proxies (interface proxies); 2) Cglib proxy (subclass proxy). Although bytecode generation is more powerful and efficient, the code is not easy to maintain, and most companies still choose dynamic proxy when implementing RPC frameworks. This part will also be discussed in subsequent chapters.

Basic RPC Principles

As mentioned above, RPC needs to encapsulate some internal implementation of remote calls. We talked about the following points:

  • serialization
  • codec
  • agreement
  • network

The general process from initiating the remote call to receiving the data and returning the result 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.

RPC then encapsulates the steps of step2-step8. Here’s a picture from the Internet to help us understand the process.

The RPC model

For the figure above, we further disassemble and get (from the network) :

From the above analysis, this includes the following core components:

  • RpcServer used to expose the service interface
  • RpcClient for discovering service interfaces
  • The proxy of the remote interface implements RpcProxy
  • The RPC Protocol that is responsible for the protocol encoding and decoding (there are many different implementations available in real RPC frameworks)
  • Network connector (read a previous article about 9 components, for our purposes, some modules can be integrated into the client and server)

Common RPC frameworks

At present, the common distributed RPC frameworks are as follows:

  • Dubbo Alibaba is an open source Java high-performance service framework, enabling applications to achieve the output and input functions of services through high-performance RPC, which can be seamlessly integrated with the Spring framework
  • Motan sina Weibo open source Java framework. It started late, in 2013, and opened in May 2016. Motan is already widely used on the microblogging platform, making nearly 100 billion calls a day to hundreds of services.
  • Dubbo of the RPCX Go language ecosystem is lighter than Dubbo and implements many features of Dubbo. Thanks to the excellent concurrency features and concise syntax of Go, distributed RPC services can be implemented with less code.
  • GRPC is a high-performance, general open source RPC framework developed by Google. It is mainly designed for mobile application development and based on HTTP/2 Protocol standards. It is based on the Protocol Buffers (ProtoBuf) serialization Protocol and supports many development languages. It is not distributed per se, so further development is required to implement the functionality of the framework above.
  • Thrift Apache is a cross-language high-performance service framework

RPC and MQ

Message queue (MQ) message queues, to some extent, can also achieve the function of RPC. In terms of functionality, MQ can store messages, while RPC cannot. A simple comparison of MQ and RPC is made, as shown in the figure below:

conclusion

In this paper, the basic principles, characteristics and basic components of RPC are simply explained, so that we can have a basic understanding of RPC. We also have a basic understanding of common RPC frameworks. For these excellent frameworks, we can learn some patterns and technologies from these frameworks when implementing our own RPC. Finally, we explained why we used RPC instead of MQ in a distributed architecture. For MQ, handling synchronous calls does not meet the actual production needs, while RPC is more suitable for the actual needs of distributed applications.