Detailed explanation of using Dubbo in Spring Boot
Dubbo is the core framework of Alibaba's SOA service-based governance solution, providing 3,000,000,000+ visits per day for 2,000+ services, and is widely used in various member sites of Alibaba Group. Dubbo is a distributed service framework dedicated to providing high-performance and transparent RPC remote service invocation solutions, as well as SOA service governance solutions.
Introduction to Dubbo
What is Dubbo?
Dubbo is a distributed service framework dedicated to providing high-performance and transparent RPC remote service invocation solutions, as well as SOA service governance solutions. Simply put, dubbo is a service framework. If there is no distributed demand, it is actually unnecessary. Only when it is distributed, there is a demand for a distributed service framework like dubbo, and it is essentially a service call. Dongdong, to put it bluntly, is a distributed framework for remote service calls
Its core parts include:
1. Remote communication: Provides abstract encapsulation of various NIO frameworks based on persistent connections, including various thread models, serialization, and information exchange methods in the "request-response" mode.
2. Cluster fault tolerance: Provides transparent remote procedure calls based on interface methods, including multi-protocol support, and cluster support such as soft load balancing, failure tolerance, address routing, and dynamic configuration.
3. Automatic discovery: Based on the registry directory service, the service consumer can dynamically find the service provider, making the address transparent, so that the service provider can smoothly increase or decrease the machine.
What can Dubbo do?
1. Transparent remote method call, just like calling a local method to call a remote method, just simple configuration, without any API intrusion.
2. Soft load balancing and fault tolerance mechanism can replace hardware load balancers such as F5 in the intranet, reduce costs and reduce single points.
3. The service is automatically registered and discovered, and it is no longer necessary to write the address of the service provider. The registration center queries the IP address of the service provider based on the interface name, and can smoothly add or delete service providers.
Dubbo's Architecture
Node role description
| node | Role description |
|---|---|
| Provider | The service provider that exposes the service |
| Consumer | Service consumer calling the remote service |
| Registry | Registry for Service Registration and Discovery |
| Monitor | A monitoring center that counts the invocation times and invocation time of services |
| Container | service running container |
Dubbo provides three key features including interface-based remote calling, fault tolerance and load balancing, and automatic service registration and discovery
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 service it provides with the registry.
3. When the service consumer starts, it subscribes to the registration center for the services it needs.
4. The registry returns the service provider address list to the consumer. If there is a change, the registry will push the change data to the consumer based on the persistent 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 the number of calls and call time in the memory, and regularly send statistical data to the monitoring center every minute.
Dubbo Features
The Dubbo architecture has the following characteristics, namely connectivity, robustness, scalability, and upgradeability to future architectures
connectivity
- The registration center is responsible for the registration and search of service addresses, which is equivalent to a directory service. Service providers and consumers only interact with the registration center at startup. The registration center does not forward requests, so the pressure is small.
- The monitoring center is responsible for counting the number of calls and calling time of each service. The statistics are first aggregated in memory and then sent to the monitoring center server every minute, and displayed in a report.
- The service provider registers the services it provides with the registration center, and reports the calling time to the monitoring center, which does not include network overhead
- The service consumer obtains the address list of service providers from the registration center, directly calls the provider according to the load algorithm, and reports the calling time to the monitoring center, which includes network overhead.
- The registration center, service provider, and service consumer are all long-term connections, except for the monitoring center
- The registration center perceives the existence of the service provider through the long connection. If the service provider is down, the registration center will immediately push the event to notify the consumer
- The registration center and monitoring center are all down, which does not affect the running providers and consumers. The consumer caches the provider list locally.
- The registration center and monitoring center are optional, and service consumers can directly connect to service providers
fitness
- The downtime of the monitoring center does not affect the use, but only part of the sampled data is lost
- After the database is down, the registry can still provide service list query through the cache, but cannot register new services
- Registry center peer-to-peer cluster, after any one goes down, it will automatically switch to another
- After all the registries are down, service providers and service consumers can still communicate through the local cache
- The service provider is stateless. After any one goes down, it will not affect the use.
- After all service providers are down, the service consumer application will be unavailable, and will reconnect infinite times waiting for the service provider to recover
Scalability
- The registry is a peer-to-peer cluster, which can dynamically increase machine deployment instances, and all clients will automatically discover the new registry
- Service providers are stateless and can dynamically add machine deployment instances, and the registry will push new service provider information to consumers
Upgradability
When the scale of the service cluster is further expanded and the IT governance structure is further upgraded, dynamic deployment and mobile computing need to be implemented, and the existing distributed service architecture will not bring resistance. The following figure is a possible architecture in the future:
Node role description
| node | Role description |
|---|---|
| Deployer | Local proxy for auto-deployment services |
| Repository | The repository is used to store service application release packages |
| Scheduler | The dispatch center automatically increases or decreases service providers based on access pressure |
| Admin | Unified management console |
| Registry | Registry for Service Registration and Discovery |
| Monitor | A monitoring center that counts the invocation times and invocation time of services |
quick start
Dubbo adopts the full Spring configuration method to transparently access the application without any API intrusion to the application. You only need to use Spring to load the configuration of Dubbo, and Dubbo is loaded based on Spring's Schema extension.
Environment installation
choose one
CentOs7.3 builds ZooKeeper-3.4.9 stand-alone service
CentOs7.3 builds ZooKeeper-3.4.9 Cluster cluster service
Github code
I have put the code on Github, import the ymq-dubbo-spring-boot project
github github.com/souyunku/ym…
Maven dependencies
Add dubbo dependencies to the project
<dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId> <version>2.5.6</version> </dependency>define service interface
project:ymq-dubbo-api
public interface DemoService { String sayHello(String name); }service provider
Project: ymq-dubbo-provider, implement the interface on the service provider
@Service("demoService") public class DemoServiceImpl implements DemoService { @Override public String sayHello(String name) { System.out.println("[" + new SimpleDateFormat("HH:mm:ss").format(new Date()) + "] Hello " + name + ", request from consumer: " + RpcContext.getContext().getRemoteAddress()); return "Hello " + name + ", response form provider: " + RpcContext.getContext().getLocalAddress(); } }load dubbo configuration
@Configuration @PropertySource("classpath:dubbo.properties") @ImportResource({"classpath:dubbo/*.xml"}) public class PropertiesConfig { }Add exposed service configuration on the provider side: <dubbo:service>
dubbo-provider.xml
<!-- 声明需要暴露的服务接口 --> <dubbo:service interface="io.ymq.dubbo.api.DemoService" ref="demoService"/>service consumer
Item: ymq-dubbo-consumer , consuming consuming remote methods
@Service("consumerDemoService") public class ConsumerDemoService { @Autowired private DemoService demoService; public void sayHello(String name) { String hello = demoService.sayHello(name); // 执行消费远程方法 System.out.println(hello); // 显示调用结果 } }load dubbo configuration
@Configuration @PropertySource("classpath:dubbo.properties") @ImportResource({"classpath:dubbo/*.xml"}) public class PropertiesConfig { }Add the reference service configuration on the consumer side: <dubbo:reference>
dubbo-consumer.xml
<!-- 增加引用远程服务配置 可以和本地bean一样使用demoService --> <dubbo:reference id="demoService" check="false" interface="io.ymq.dubbo.api.DemoService"/>Remote Service Dubbo Configuration
Project:ymq-dubbo-provider , the ymq-dubbo-consumer same configuration
dubbo.xml
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:context="http://www.springframework.org/schema/context" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd"> <!-- 提供方应用信息，用于计算依赖关系 --> <dubbo:application name="${spring.application.name}" /> <!-- 使用multicast广播注册中心暴露服务地址 --> <dubbo:registry protocol="zookeeper" address="${zookeeper.connect}" file="${dubbo.cache}"/> <!-- 用dubbo协议在20880端口暴露服务 --> <dubbo:protocol name="dubbo" port="${dubbo.protocol.port}" threadpool="${dubbo.protocol.threadpool}" threads="${dubbo.protocol.threads}"/> <!-- 提供方的缺省值，当ProtocolConfig和ServiceConfig某属性没有配置时，采用此缺省值，可选。--> <dubbo:provider connections="${dubbo.provider.connections}" timeout="${dubbo.provider.timeout}" retries="${dubbo.provider.retries}" version="${dubbo.provider.version}" /> <!-- 消费方缺省配置，当ReferenceConfig某属性没有配置时，采用此缺省值，可选。--> <dubbo:consumer version="${dubbo.provider.version}" /> <!-- 监控中心配置，用于配置连接监控中心相关信息，可选。--> <dubbo:monitor protocol="registry"/> </beans>dubbo.properties
######################################################### # dubbo config #暴露服务端口 dubbo.protocol.port=20880 #提供方超时时间 dubbo.provider.timeout=10000 #提供方版本 dubbo.provider.version=1.0 #表示该服务使用独的五条条长连 dubbo.provider.connections=5 # 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省) dubbo.protocol.threadpool=fixed # 线程数量 dubbo.protocol.threads=500 #配置重试次数，最好只用于读的重试，写操作可能会引起多次写入 默认retries="0" dubbo.provider.retries=0 # dubbo缓存文件 dubbo.cache=/data/dubbo/cache/ymq-dubbo-provider ######################################################### # zookeeper config zookeeper.connect=127.0.0.1:2181Test Dubbo
- This interface needs to be packaged separately and shared between the service provider and the consumer↩
- Hide the implementation from the service consumer ↩
- It is also possible to use IoC injection ↩
Start ZooKeeper
start the service
/opt/zookeeper-3.4.9/bin/zkServer.sh startStart the provider service
package io.ymq.dubbo.provider.run; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.context.annotation.ComponentScan; /** * 描述:启动提供方服务 * * @author yanpenglei * @create 2017-10-27 11:49 **/ @SpringBootApplication @ComponentScan(value = {"io.ymq.dubbo"}) public class Startup { public static void main(String[] args) { SpringApplication.run(Startup.class, args); } }Test consuming a remote service
package io.ymq.dubbo.test; import io.ymq.dubbo.consumer.run.Startup; import io.ymq.dubbo.consumer.service.ConsumerDemoService; import org.junit.Test; import org.junit.runner.RunWith; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.test.context.junit4.SpringRunner; /** * 描述: 测试消费远程服务 * * @author yanpenglei * @create 2017-10-27 14:15 **/ @RunWith(SpringRunner.class) @SpringBootTest(classes = Startup.class) public class ConsumerTest { @Autowired private ConsumerDemoService consumerDemoService; @Test public void sayHello(){ consumerDemoService.sayHello("Peng Lei"); } }response:
[15:54:00] Hello Peng Lei, request from consumer: /10.4.82.6:63993I have put the code on Github, import the ymq-dubbo-spring-boot project
github github.com/souyunku/ym…
- Author: Peng Lei
- Source: Segment Fault PengLei `Blog column
- The copyright belongs to the author, please indicate the source when reprinting