Dubbo is a microservices development framework that provides two key capabilities: RPC communication and microservices governance. In daily development, we use RPC communication capability provided by Dubbo more than the service governance capability provided by Dubbo. This article will focus on service governance. The Dubbo framework provides rich service governance capabilities such as flow control, dynamic configuration, service Mock, service testing, and so on. The role of Dubbo -admin is to provide an out-of-the-box platform for service governance capabilities provided by the Dubbo framework. This article introduces the functionality provided by Dubbo-Admin to give you a quick understanding and use of Dubbo-Admin and a preliminary understanding of the service governance capabilities provided by Dubbo.
The authors introduce
Cheng Lu, Java development engineer, middleware development enthusiast, focus on service governance. Yan Hao is a Dubbo contributor who focuses on RPC and service governance.
preface
Dubbo is a microservices development framework that provides two key capabilities: RPC communication and microservices governance. In daily development, we use RPC communication capability provided by Dubbo more than the service governance capability provided by dubbo. This article will focus on service governance. The Dubbo framework provides rich service governance capabilities such as flow control, dynamic configuration, service Mock, service testing, and so on. The role of Dubbo -admin is to provide an out-of-the-box platform for service governance capabilities provided by the Dubbo framework. This article introduces the functionality provided by Dubbo -admin to give you a quick understanding and use of dubbo-admin and a preliminary understanding of the service governance capabilities provided by Dubbo.
Service details
Service details will display the service information provided by the Dubbo service in terms of the interface, including service provider information, consumer information, and service metadata information such as provided method names and parameter lists. The application level discovery model provided by Dubbo 3.0 is supported in the latest version, with application level/interface level differentiation in registry sources.
Dynamic routing
Dubbo-admin supports three types of routing, namely conditional routing, label routing, and Mesh routing. The functions provided by dubbo-Admin can easily implement service governance demands such as whitelist and blacklist, cluster isolation, and Canary publishing. Here are some examples of the functions of this section.
Conditions for routing
Conditional routing you can customize routing rules to meet service governance requirements, such as blacklist and whitelist and read/write separation. Routing rules filter the target server address before an RPC call. The filtered address list is used as the alternative address for the consumer to initiate an RPC call.
The following figure shows the implementation of a simple blacklist function. The definition of the routing rule is to prohibit the consumer whose IP address is 172.22.3.91 from invoking the service HelloService. The format of the conditional routing rule is as follows: [Service consumer matching condition] => [Service provider matching condition].
Label routing
Label routing divides one or more service providers into the same group to restrict traffic flow only in the specified group, thus achieving traffic isolation. It can be used as the basis for blue-green and grayscale advertising. Create rules at the provider application level. The corresponding static labels are dubo.provider. tag=tag1 and @dubboService (tag = “tag2”).
Mesh routing
Mesh routing is a new routing rule introduced in Dubbo 3.0. It is extremely powerful. Using Mesh routing can cover the function scenarios of two types of routing and combine more complex routing scenarios.
Mesh routing divides traffic management into VirtualService and DestinationRule. VirtualService matches inbound traffic, and DestinationRule matches egress traffic. In the following case, the hi method of the service HelloService is routed through the input parameter number, so that the requests with even input parameters are routed to the service with label v1, and the requests with odd input parameters are routed to the service with label v2.
public interface HelloService {
String hi(Integer number);
}
The service implementation returns the service provider port.
public class HelloServiceImpl implements HelloService {
@Value(“${dubbo.protocol.port}”)
private String port;
@Override
public String hi(Integer number) {
return “hi ” + number + “, my port is :” + port;
}
}
The first step: Start two service providers parameters respectively for the port = 20883, dubbo. Application. The parameters. The test – version = v1 and port = 20884 , dubbo. Application. The parameters. The test – version = v2, through dubbo. Application. The parameters of the definition of parameters will be exposed to the URL of the service.
dubbo.application.parameters.test-version = v1
dubbo.protocol.port=20883
Step 2: Create a mesh routing rule that defines VirtualService and DestinationRule. The DestinationRule section divides the service URL parameters test-version=v1 and test-version=v2 into service v1 and v2, respectively. VirtualService will match the service HelloService#hi method and route the even numbers to the v1 service and the odd numbers to the service whose label is v2.
apiVersion: service.dubbo.apache.org/v1alpha1
kind: VirtualService
metadata:
name: demo/oddEvenRouter
spec:
dubbo:
– routedetail:
– match:
– method:
argc: 1
args:
– index: 0
num_value:
oneof:
– the exact: 0.0
Mod: 2.0
type: int
name_match:
exact: hi
name: even-route
route:
– destination:
host: demo
subset: v1
– match:
– method:
argc: 1
args:
– index: 0
num_value:
oneof:
– the exact: 1.0
Mod: 2.0
type: int
name_match:
exact: hi
name: odd-route
route:
– destination:
host: demo2
subset: v2
services:
– exact: org.test.apache.dubbo.interfaces.HelloService
—
apiVersion: service.dubbo.apache.org/v1alpha1
kind: DestinationRule
metadata:
name: test-route
spec:
host: demo
subsets:
– name: v1
labels:
test-version: v1
– name: v2
labels:
test-version: v2
Step 3: Start the consumer test and see the result returned as we expected, through the appeal case to implement A simple grayscale function, of course, can easily implement A/B testing, canary publishing and other functions.
Dynamic configuration
Dynamic configuration provides the ability to dynamically adjust the behavior of RPC calls without a restart. For example, modify the timeout period, weight, load balancing policy, and service degradation. Instead of having to restart the service in order to adjust the Dubbo parameters, some common parameter adjustments are shown below.
- The timeout period is adjusted to 6000 ms
ConfigVersion: v2.7
enabled: true
configs:
– addresses: [0.0.0.0] # 0.0.0.0 for all addresses
side: consumer # effective side, consumer or addresses
parameters:
timeout: 6000 # dynamic config parameter
- Weight adjustment
ConfigVersion: v2.7
scope: application
key: demo-provider
enabled: true
configs:
– addresses: [10.20.153.10:20880 “”]
side: provider
parameters:
weight: 200
- Load policy Adjustment
ConfigVersion: v2.7
scope: application
key: demo-consumer
enabled: true
configs:
– side: consumer
parameters:
loadbalance: random
Documentation and Tests
Interface documentation
Dubbo-api-docs is a tool for displaying Dubbo interface documentation, testing interfaces, and doing what Swagger does for RESTful Web services. Using this feature requires the Dubbo service to introduce the related packages, Annotations (Dubbo-apI-doc-Core), to describe interface and parameter information in the form of annotations.
org.apache.dubbo
dubbo-api-docs-annotations
${dubbo-version}
org.apache.dubbo
dubbo-api-docs-core
${dubbo-version}
The renderings are as follows
Service test
Compared to Dubo-api-docs, the dubbo service can be tested without introducing any dependencies, making it easy to quickly adjust and verify the Dubbo service.
The service Mock
The service Mock intercepts the Consumer’s request to the Provider in a codeless way and dynamically permits the Consumer’s request or returns user-defined Mock data. This solves the problem of blocking Consumer developers when the Provider they rely on is not ready in early development.
There are only two steps to enjoy the convenience of service Mock:
Step 1: The Consumer application introduces the service Mock dependency by adding the JVM startup parameter -denable.dubo.admin. Mock =true to enable the service Mock function.
org.apache.dubbo.extensions
dubbo-mock-admin
last
Step 2: Configure the corresponding Mock data in Dubbo Admin.
summary
This article covers most of the functionality of Dubo-Admin, covering the entire development, testing, and online phases. I hope this article can bring some help to use and start dubbo-admin. For details, please refer to the official website. I also hope that Dubbo -admin can bring dubbo users a new experience, more convenient and fast to use the service governance capabilities provided by Dubbo.
The original link
This article is the original content of Aliyun and shall not be reproduced without permission.