Dubbo's learning notes introduction to Dubbo

1 Overview

1.1 what is a distributed system?

"A distributed system is a collection of several independent computers that are like a single related system to users."
——Distributed system principles and Paradigms
distributed system is a software system based on network.

1.2 distributed service architecture

When there are more and more vertical applications, the interaction between applications is inevitable. Extract the core business as an independent service, and gradually form a stable service center, so that the front-end application can respond to the changing market demand more quickly. At this time, the distributed service framework (RPC) used to improve business reuse and integration is the key.

1.3 RPC (distributed service framework)

What is RPC

RPC [Remote Procedure Call] refers to Remote Procedure Call. It is a way of inter process communication. 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 sharing a network) without the programmer explicitly encoding the details of the remote call. That is, whether programmers call local or remote functions, the calling code written by programmers is basically the same.

2 dubbo core concepts

2.1 introduction

Apache Dubbo is a high-performance and lightweight open source Java RPC framework. It provides three core capabilities: interface oriented remote method invocation, intelligent fault tolerance and load balancing, and automatic service registration and discovery.

2.2 basic concepts

Service Provider: the service Provider that exposes the service. When the service Provider starts, it registers the service it provides with the registry.
Service Consumer: the service Consumer who calls the remote service. When starting, the service Consumer subscribes to the service required by the registry. The service Consumer selects one provider from the list of provider addresses based on the soft load balancing algorithm to call. If the call fails, select another one to call.
Registry: the registry returns the address list of service providers to consumers. If there is any change, the registry will push the change data to consumers based on the long connection
Monitor ing center: service consumers and providers accumulate call times and call times in memory, and regularly send statistical data to the monitoring center every minute

3 Introduction to Dubbo

Suppose the system, the order service needs to call the user service to obtain all addresses of a user;
Create two service modules for testing
modular function
Order web module (order web) Create orders, etc
User service module (order user) Query user address, etc

In addition to the above, order interface and public interface layer are also required

3.1 take order user as the provider

3.1.1 introduction of dubbo

<!-- introduce dubbo --> 
<!-- Due to use zookeeper As a registry, you need to operate zookeeper dubbo 2.6 Introduction of previous versions zkclient operation zookeeper dubbo 
2.6 And later versions curator operation zookeeper The next two zk Client based dubbo Select 1 for version 2
--> <dependency> <groupId>com.101tec</groupId> <artifactId>zkclient</artifactId> <version>0.10</version> </dependency> <!-- curator-framework --> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-framework</artifactId> <version>2.12.0</version> </dependency>

3.1.2. Configure the provider in the spring configuration file

<!--Name of the current application --> 
<dubbo:application name="gmall-user">
<!--Specify the address of the registry --> 
<dubbo:registry address="zookeeper://" /> 
<!--use dubbo Protocol, exposing services to port 20880 --> 
<dubbo:protocol name="dubbo" port="20880" /> 
<!-- Specify the services that need to be exposed --> 
<dubbo:service interface="com.atguigu.gmall.service.UserService" ref="userServiceImpl" />

3.1.3 start service

public static void main(String[] args) throws IOException { 
    ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("classpath:spring-beans.xml"); 

3.2 order web as a service consumer

3.2.1 introduction of dubbo

<!-- introduce dubbo --> 
<!-- Because we use zookeeper As a registration center, it needs to be introduced zkclient and curator operation zookeeper --> 
<!-- curator-framework --> 

3.3.2 configuring consumer information

<!-- Application name -->
<dubbo:application name="gmall-order-web"></dubbo:application>
<!-- Specify registry address -->
<dubbo:registry address="zookeeper://" />
<!-- Generate a remote service proxy, which can communicate with local bean Same use demoService -->
<dubbo:reference id="userService"

4. Integrate SpringBoot

4.1 introduce spring boot starter and dependency of dubbo and curator

Note starter version adaptation:

Application configuration properties

Provider configuration:
application.name It's just the service name. It can't be compared with anything else dubbo Duplicate provider
registry.protocol Is the designated registry agreement
registry.address Is the address of the registration center plus the slogan
protocol.name Yes distributed fixed yes dubbo,Don't change.
base-package Annotate the package to be scanned
Consumer configuration:

4.3 dubbo notes

@Service exposes service annotations (not @ service in Spring) and @ Reference consumes service annotations (instead of @ Autowired)
[if dubbo.scan.base-package is not written in the configuration, you also need to use @ EnableDubbo annotation]

5. dubbo configuration

5.1 configuration principle

JVM startup - D parameter takes precedence, which enables users to rewrite parameters during deployment and startup, such as changing the port of the protocol during startup.
XML takes the second place. If there is a configuration in XML, Dubbo The corresponding configuration item in properties is invalid.
Finally, Properties is equivalent to the default value. Only when XML is not configured, Dubbo The corresponding configuration item of Properties will take effect. It is usually used to share public configuration, such as application name.

5.2 number of retries

Failure automatically switches. When failure occurs, retry other servers, but retry will bring longer delay. You can set the number of retries (excluding the first time) through retries="2".
The number of retries is configured as follows: 
<dubbo:service retries="2" />
<dubbo:reference retries="2" />
  <dubbo:method name="findFoo" retries="2" />

5.3 timeout

Because the network or server is unreliable, it will lead to an uncertain intermediate state (timeout) in the call. In order to prevent the timeout from causing the client resource (thread) to hang and run out, the timeout time must be set.

5.3.1 consumer end of Dubbo

Global timeout configuration
<dubbo:consumer timeout="5000" />
Specify the interface and specific method timeout configuration
<dubbo:reference interface="com.foo.BarService" timeout="2000">
<dubbo:method name="sayHello" timeout="3000" />

5.3.2 Dubbo server

Global timeout configuration
<dubbo:provider timeout="5000" />
Specify the interface and specific method timeout configuration
<dubbo:provider interface="com.foo.BarService" timeout="2000">
<dubbo:method name="sayHello" timeout="3000" />

5.3.3 configuration principle

dubbo recommends configuring as many Consumer attributes as possible on the Provider:
1. As a service provider, it knows more about service performance parameters than the service user, such as call timeout, reasonable retry times, and so on
2. After the Provider is configured, if the Consumer is not configured, the configuration value of the Provider will be used, that is, the Provider configuration can be used as the default value of the Consumer. Otherwise, the Consumer will use the global settings on the Consumer side, which is uncontrollable and often unreasonable for the Provider

5.3.4 version number

In case of incompatible upgrade of an interface implementation, the version number can be used for transition. Services with different version numbers do not refer to each other.
The following steps can be followed for version migration:
During the low pressure period, upgrade half of the providers to the new version
Then upgrade all consumers to the new version
Then upgrade the remaining half of the providers to the new version
Old version service provider configuration:
<dubbo:service interface="com.foo.BarService" version="1.0.0" />
New version service provider configuration:
<dubbo:service interface="com.foo.BarService" version="2.0.0" />
Old version service consumer configuration:<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
New version service consumer configuration:
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />
If you do not need to distinguish between versions, you can configure it in the following way:
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />




Tags: Dubbo

Posted by daredevil14 on Sun, 15 May 2022 16:11:52 +0300