Table of contents
2.1 Introduction to the basic concept of RPC
2.1.3 The difference between RPC and HTTP, TCP/UDP, Socket
1. Architecture Evolution
The evolution of the architecture is as follows:
1.1 Monolithic Architecture
Assume here that A, B, C, and D are four modules
When the website traffic is small, only one application is needed to deploy all functions together to reduce deployment nodes and costs. ORMAt this time, the data access framework ( ) used to simplify the workload of adding, deleting, modifying and checking is the key.
Advantages:
Simple: Development and deployment are very convenient, preferred for small projects
Disadvantages:
Slow project startup. Poor reliability, poor scalability,
poor scalability and maintainability, low performance
1.2 Vertical Architecture
When the number of visits gradually increases, the acceleration brought by the addition of machines for a single application becomes smaller and smaller, and the application is split into several independent applications to improve efficiency. WebAt this point, the framework ( ) for accelerating front-end page development MVCis the key.
Vertical architecture refers to the splitting of multiple modules in a monolithic architecture into multiple independent projects. Form multiple independent monolithic architectures. Problems with vertical architecture: • Too many duplicate functions.
1.3 Distributed architecture
Distributed architecture means that on the basis of vertical architecture, public business modules are extracted and used as independent services for other callers to consume, so as to realize the sharing and reuse of services.
RPC: Remote Procedure Call remote procedure call. There are many protocols and technologies that implement the RPC process. For example: HTTP REST style, JavaRMl specification, WebService SOAP protocol. Hession and so on.
The problem with the distributed architecture: Once the service provider changes, all consumers need to change.
1.4 SOA architecture
SOA : (Service-Oriented Architecture, Service-Oriented Architecture) is a component model that splits different functional units (called services) of an application and connects them through well-defined interfaces and contracts.
ESB : (Enterparise Servce Bus) Enterprise Service Bus, service intermediary. It mainly provides a service for interaction between services. ESB includes functions such as: load balancing, flow control, encryption processing, service monitoring, exception handling, monitoring emergency, etc.
1.5 Microservice Architecture
The microservice architecture is the sublimation of SOA. One of the key points emphasized by the microservice architecture is that "business needs to be thoroughly componentized and serviced". The original single business system will be split into multiple small application. These small applications complete interaction and integration through services. Microservice architecture = 80% SOA service architecture idea + 100% component architecture idea + 80% domain modeling idea.
Features:
1. Componentization of services: developers can freely choose development technologies. There is also no need to coordinate other teams.
2. The interaction between services generally uses REST API.
3. Decentralization, each microservice has its own private database to persist business data.
4. Automated deployment, splitting applications into independent individual services to facilitate automated deployment, testing, and operation and maintenance.
2. RPC framework
2.1 Introduction to the basic concept of RPC
2.1.1 RPC protocol
Remote procedure call protocol, which is a protocol for requesting services from remote computer programs over the network without the need to understand the underlying network technology. The RPC protocol assumes the existence of some transport protocol, such as TCP or UDP, to carry information data between communication programs. In the OSI network communication model, RPC spans the transport layer and the application layer. RPC makes it easier to develop applications including network distributed multiprogramming.
The OSI reference model is as follows:
RPC adopts the client/server model. A requester is a client, and a service provider is a server. First, the client calling process sends a call message with process parameters to the service process, and then waits for a reply message. On the server side, the process stays asleep until the call message arrives. When a call message arrives, the server obtains the process parameters, calculates the result, sends a reply message, and then waits for the next call message. Finally, the client call process receives the reply message, obtains the process result, and then the call execution continues.
2.1.2 RPC framework
In the stand-alone era, a computer runs multiple processes, and the processes cannot communicate with each other. Obviously, this will waste a lot of resources. Therefore, IPC (Inter-process communication: mutual communication between processes running on a stand-alone machine) appeared later, which allows Communication between processes. For example, if process A in a computer writes a method of eating, if there is a method of eating in process B in the past, it must be created in process B, but with After RPC, B only needs to call the program of A process to complete it. Later, with the emergence of the Internet era, everyone’s computers are connected. At this time, can it call processes on other computers? Of course, so the RPC framework appears. Strictly speaking: In the Unix ecosystem, RPC can be performed on different processes on the same computer, or on different computers; while in Windows, the communication between different processes on the same computer can also use LPC (local access) . To sum up: RPC or LPC is the superstructure, and IPC is the underlying foundation.
There are many RPC frameworks: such as JAVA RMT, Thrift, Dubbo, grpc, etc.
2.1.3 The difference between RPC and HTTP, TCP/UDP, Socket
TCP/UDP : Both are transport protocols. The main difference is that tcp protocol connection requires 3 handshakes, and disconnection requires 4 handshakes. It is transmitted through streams, that is, after the connection is confirmed, the information is sent all the time, and it is disconnected after transmission. UDP does not need to connect, and directly encapsulates the information into multiple messages and sends them directly. So udp writes faster, but does not guarantee data integrity.
Http : Hypertext Transfer Protocol is an application layer protocol, built on top of the TCP protocol
Socket : is the encapsulation and application of the TCPIP protocol at the application level. In fact, it is a call interface, which is convenient for programmers to use the TCPIP protocol stack. Programmers use the tcp/ip protocol through sockets. But the socket does not have to use the tcp/ip protocol. When the Socket programming interface is designed, it is hoped that it can also adapt to other network protocols.
RPC is a protocol for requesting services from remote computer programs over a network without requiring knowledge of the underlying network technology. Therefore, the implementation of RPC can be realized through different protocols, for example, http, RMl, etc. can be used.
2.1.4 RPC operation process
First of all, to solve the problem of communication, mainly by establishing a TCP connection between the client and the server, all exchanged data of remote procedure calls are transmitted in this connection. The connection can be an on-demand connection, which will be disconnected after the call is completed, or a long connection, where multiple remote procedure calls share the same connection.
Second, to solve the problem of addressing, that is to say, how does the application on the A server tell the underlying RPC framework, how to connect to the B server (such as the host or IP address) and the specific port, what is the name of the method, This completes the call. For example, based on the RPC of the Web service protocol stack, it is necessary to provide an endpoint URI, or to search from the UDD (a directory service through which service registration and search are performed). If it is an RMI call, an RMl Registry is also required to register the address of the service.
Third, when the application on server A initiates a remote procedure call, the parameters of the method need to be passed to server B through the underlying network protocol such as TCP. Since the network protocol is based on binary, the value of the parameter in memory must be serialized into binary Form, that is, serialize (Serialize) or marshal (marshal), send the serialized binary to the B server through addressing and transmission.
Fourth, after server B receives the request, it needs to deserialize the parameters (the inverse operation of serialization), restore the expression in memory, and then find the corresponding method (part of addressing) to call locally, and then get return value.
Fifth, the return value must be sent back to the application on server A, and it must also be sent in a serialized manner. After server A receives it, it will deserialize it, restore it to the expression in memory, and hand it over to the application on server A
as the picture shows:
2.1.5 Why RPC is needed
In terms of complexity, the RPC framework is definitely higher than the simple HTTP interface. But there is no doubt that because the HTTP interface is limited by the HTTP protocol, it needs to carry HTTP request headers, resulting in less efficient or less secure transmission than RPC.
Now the question is, what kind of bottleneck is encountered before it is necessary or more suitable to use RPC (for example, with such a large amount of concurrent requests as Ali, simple HTTP will definitely not meet expectations), but the problem is that such a large amount like Ali is relatively Less, or even 1/1000 of the amount may not be, so do we still need to use RPC? The technology should not be used for the use of new technologies, but should be because there are certain bottlenecks in the old technology, which are difficult to support or more scalable. After the problems such as getting old and getting worse are exposed, new technologies are used to solve them.
What is the biggest advantage of RPC, or what are its advantages and business scenarios that are more suitable for it compared to the simple HTTP interface? What is the disadvantage of simple HTTP, and which scenarios are obviously not suitable?
The http interface is a communication method that is often used in the initial stage of solving information when there are not many interfaces and less interaction between systems. The advantage is that it is simple, direct, and easy to develop. Use the ready-made http protocol for transmission. However, if it is a large-scale website with many internal subsystems and many interfaces, the benefits of the RPC framework will be revealed. The first is the long link. It is not necessary to shake hands three times like HTTP every time. , reducing network overhead (this problem has been solved in http2.0 and is no longer a problem); secondly, the RPC framework generally has a registration center with rich monitoring and management; publishing, offline interfaces, dynamic expansion, etc. On the other hand, it is a non-perceptual and unified operation. The third is security. The last is the popular service-oriented architecture and service-oriented governance. The RPC framework is a strong support.
RPC is a concept, and http is also a way of implementing RPC. Interaction with http actually belongs to RPC. The RPC framework can be flexibly deployed and decoupled. When the system gets bigger, it is definitely necessary to do microservices. This is how we do e-commerce now. We have a separate order system, payment system, commodity system, and user system. They are all deployed separately and launched separately.
RPC: Remote Procedure Call . The core of RPC is not what protocol to use. The purpose of RPC is to allow you to call a remote method locally, but this call is transparent to you, and you don't know where the called method is deployed. RPC can decouple services, which is the real purpose of using RPC. The principle of RPC mainly uses the dynamic proxy mode. As for the http protocol, it is just a transmission protocol.
RPC is a software structure concept and the theoretical basis for building distributed applications. It's like why your home can use electricity from a power plant? It's because electricity can be transmitted. As for whether to use copper wire or iron wire or other types of wires, it is a question of whether to use http or other protocols. This depends on the scene and the performance requirements. For example, the most basic in java is RMI technology, which is the native application layer distributed technology of java. We can be sure that in terms of transmission performance, the performance of RMI is better than HTTP. Then why is this technology rarely used? That is because there are many limitations in using this technology. First of all, it must ensure that both ends of the transmission must be implemented in java, and both sides need to have the same object type and proxy interface, and no container is required. , but it increases the difficulty of programming, and you can still see him among the various subsystems inside the application. For example, EJB is based on rmi technology. This is very different from the current bs architecture software. To use http, the server must be located in the http container, which reduces the development of network transmission and only needs to focus on business development.
2.2 Dubbo
2.2.1 Overview of Dubbo
Dubbo is a distributed service framework dedicated to providing high-performance and transparent RPC remote service invocation solutions and SOA service governance solutions. Simply put, dubbo is a service framework.
dubbo provides three core capabilities:
- Interface-oriented remote method invocation;
- Intelligent fault tolerance and load balancing;
- and service auto-registration and discovery;
The dubbo architecture diagram is as follows:
Node role description:
Description of calling relationship
1. The service container is responsible for starting, loading, and running the service provider.
2. When the service provider starts, it registers the services it provides with the registration center.
3. When the service consumer starts, it subscribes to the registration center for the services it needs.
4. The registration center returns the service provider address list to the consumer. If there is a change, the registration center will push the change data to the consumer based on the long connection.
5. The service consumer, from the provider address list, selects a provider to call based on the soft load balancing algorithm, and if the call fails, select another provider to call.
6. Service consumers and providers accumulate call times and call time in the memory, and regularly send statistical data to the monitoring center every minute.
2.2.2 Dubbo combat
Here we set up an order microservice and a user microservice, and return the order information by querying the order. There is user information in the order. All users need to call the user microservice to query according to the user id in the order and then assign the value to return the order information. Here, nacos and The way Dubbo is combined.
2.2.2.1 Producer (user module microservice) and consumer (order module microservice) import dependencies
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-dubbo</artifactId>
</dependency>2.2.2.2 Common modules
Set the interface for querying user information
public interface UserService {
public User queryUserId(Long id);
}
2.2.2.3 Producer (User Module Microservice)
application.yml file configuration
spring:
cloud:
nacos:
server-addr: localhost:8848
discovery:
cluster-name: SH
dubbo:
#服务名称
application:
name: dubbo-user
#注册中心
registry:
address: nacos://127.0.0.1:8848
protocol:
#协议名称
name: dubbo
#协议端口号
port: 20880
scan:
base-packages: com.example.user.Imp #扫描包的位置
Create the DubboUserServiceImpl class in com.example.user.Imp and inherit the UserService class, the code is as follows;
package com.example.user.Imp;
import com.example.entity.JieKou.UserService;
import com.example.entity.entities.User;
import org.apache.dubbo.config.annotation.Service;
@Service(version = "1.0")
public class DubboUserServiceImpl implements UserService {
public User queryUserId(Long id) {
User user=new User();
user.setId((long) 3);
user.setUsername("admin");
user.setAddress("ShanDon");
return user;
}
}2.2.2.4 Consumer (order module microservice)
The application.yml file is configured as follows:
dubbo:
protocol:
port: 20881
name: dubbo
registry:
address: nacos://localhost:8848The business logic code of the Controller class is as follows:
@RestController
@RefreshScope
public class UserController {
@Autowired
OrdersMapper ordersMapper;
@Reference(version = "1.0",parameters = {"unicast","false"}) //服务提供的可以被多个消费者消费
UserService userService;
@GetMapping("/order1/{id}")
public Orders orders1(@PathVariable("id") Long id){
Orders orders = ordersMapper.selectById(id);
User user = userService.queryUserId(orders.getUserId());
orders.setUser(user);
return orders;
}
}
At this point, the code is basically completed, and the running results are as follows:
