Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the method of marking Dubbo static rules". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "what is the method of marking Dubbo static rules"?

1 apply the dimension registration model

After the new model release, we found that every URL publishing metadata in Provider registers ServiceInstance, which affects performance and needs to be optimized.

Our optimization plan is: remove the code to register ServiceInstance in ServiceDiscoveryRegistry, and register ServiceInstance in the loadProviderConfig method in config_loader. Specific steps: 1. Get all registered Registry, filter out ServiceDiscoveryRegistry, and get all ServiceDiscovery. 2. Create ServiceInstance. 3. Register ServiceInstance for each ServiceDiscovery.

Ensure that the metadata information is not exposed until the Provider is registered successfully.

2 supports Seata-based transactions

Based on Seata extension implementation. By adding filters, xid is received on the server side and combined with seata-golang to support distributed transactions. So that Dubbo-go in the distributed scenario, so that users have more choices, can adapt to more personalized scenarios.

We give transaction test cases in dubbo-samples.

3 load balancing of multi-registry clusters

For scenarios with multiple registry subscriptions, there is an extra layer of load balancing among registry clusters when selecting a location:

At the Cluster Invoker level, the location strategies we support are:

Specify priority

Same as zone priority

Weight polling

3 Transmission link security

This version makes an attempt on the security of the transmission link and provides a secure link transmission mechanism based on TLS for the built-in Dubbo getty Server.

To ensure the flexibility of application startup as much as possible, TLS Cert is specified through configuration files. For more information, please see Dubbo-go configuration read rules and TLS examples:

4 enhanced routing featur

This routing function focuses on supporting dynamic label routing and application / service-level conditional routing.

4.1 dynamic label routing

Label routing can achieve the purpose of traffic isolation by dividing one or more service providers into the same packet and constraining the flow of traffic only in the specified packet, which can be used as the capability basis for blue-green publishing, grayscale publishing and other scenarios.

Tag mainly refers to the grouping of application instances on the Provider side. At present, there are two ways to group instances, namely, dynamic rule marking and static rule marking, in which dynamic rules have higher priority than static rules. When the two rules exist at the same time and there are conflicts, dynamic rules will prevail.

4.1.1 dynamic rule marking

Label grouping rules can be issued at any time under the service governance console

# governance-tagrouter-provider application added two tag groups tag1 and tag2# tag1 including an instance 127.0.0.1 tag2 containing an instance 127.0.0.1 force: false runtime: true enabled: true key: governance-tagrouter-provider tags:-name: tag1 addresses: ["127.0.0.1 tag2: name: tag2 addresses: [" 127.0.0.1] : 20881 "]. 4.1.2 static rule marking

You can set it in the tag field of the server configuration file

Services: "UserProvider": registry: "hangzhouzk" protocol: "dubbo" interface: "com.ikurento.user.UserProvider" loadbalance: "random" warmup: "beijing" cluster: "failover" methods:-name: "GetUser" retries: 1 loadbalance: "random"

Consumer add tag to attachment

Ctx: = context.Background () attachment: = make (map [string] string) attachment ["dubbo.tag"] = "beijing" ctx = context.WithValue (ctx, constant.AttachmentKey, attachment) err: = userProvider.GetUser (ctx, [] interface {} {"A001"}, user)

The scope of the request tag is each invocation. Use attachment to pass the request tag. Note that the value saved in attachment will continue to be passed in a complete remote call. Thanks to this feature, we only need to pass the tag continuously through one line of code setting at the beginning of the call.

4.1.3 detailed explanation format of rules

Key makes it clear which application the rule body applies to. Required.

Whether the current routing rule of enabled=true takes effect, it can be left empty. It takes effect by default.

Whether force=false is enforced when the routing result is empty. If it is not enforced, the routing rule with empty routing result will automatically become invalid, but it can be left empty. The default is false.

Whether the runtime=false executes the routing rules on each call, otherwise the results are pre-executed and cached only when the provider address list changes, and the routing results are obtained directly from the cache when the call is made. If parameter routing is used, it must be set to true. It should be noted that the setting will affect the performance of the call. It can be left empty. The default is false.

The priority of the priority=1 routing rule, which is used for sorting. The higher the priority is, the higher the priority is, but it can be left empty. The default is 0.

Tags defines specific tag grouping content, which can define any n (n > = 1) tags and specify a list of instances for each tag. Required

Name, label name

Addresses, the list of instances contained in the current tag

Demotion agreement

When request.tag=tag1, the provider marked with tag=tag1 is preferred. If the service corresponding to the request tag does not exist in the cluster, the provider; with empty request tag will be demoted by default. If you want to change this default behavior, that is, if you cannot find a provider that matches the tag1, you need to set request.tag.force=true.

When request.tag is not set, only provider with empty tag will be matched. Even if there are available services in the cluster, they cannot be called if the tag does not match. Unlike Convention 1, requests with tags can be degraded to untagged services, but requests without tags / other kinds of tags will never be able to access services with other tags.

4.2 Application / Service level conditional routin

You can configure multiple conditional routes and their granularity in the routing rule configuration

Sample:

# dubbo router yaml configure filerouterRules:-scope: application key: BDTService priority: 1 enable: false force: true conditions: ["host = 192.168.199.208 = > host = 192.168.199.208"]-scope: service key: com.ikurento.user.UserProvider priority: 1 force: true conditions: ["host = 192.168.199.208 = > host = 192.168.199.208"] 4.2.1 rules explain the meaning of each field

Scope indicates the granularity of routing rules, and the value of scope determines the value of key. Required.

Service service granularity

Application application granularity

Key makes it clear which service or application the rule body acts on. Required.

When scope=service, the value of key is the combination of [{group} /] {service} [: {version}]

When scope=application, the value of key is application name.

Whether the current routing rule of enabled=true takes effect, it can be left empty. It takes effect by default.

Whether force=false is enforced when the routing result is empty. If it is not enforced, the routing rule with empty routing result will automatically become invalid, but it can be left empty. The default is false.

Whether the runtime=false executes the routing rules on each call, otherwise the results are pre-executed and cached only when the provider address list changes, and the routing results are obtained directly from the cache when the call is made. If parameter routing is used, it must be set to true. It should be noted that the setting will affect the performance of the call. It can be left empty. The default is false.

The priority of the priority=1 routing rule, which is used for sorting. The higher the priority is, the higher the priority is, but it can be left empty. The default is 0.

Conditions defines specific routing rule content. Required.

5 Review and prospect

Dubbo-go is in a stable and mature state. At present, the new version is in an attempt to move to the cloud native direction, and the application service dimension registration is the first feature, which is a new registration model that is completely different from the previous model. This version is the key version for us to take a new step towards cloud native. In addition, there are some of the optimizations mentioned earlier in this version.

In the next version v1.5.2, this time the focus is on the improvement of the communication model. In addition, the compatibility, ease of use and quality assurance with 2.7.x are also the information of this concern. **

In service discovery, more ways are supported, such as files and Consul. So that Dubbo-go in the service discovery scenario, so that users have more choices, can adapt to more personalized scenarios.

In addition, ease of use and quality assurance are mainly focused on samples and automation construction. It can reduce the difficulty for users to use Dubbo-go and improve the code quality.

At present, the next version is in full swing, and the specific planning and to-do list [1] have been reflected on Github.

At this point, I believe that everyone on the "Dubbo static rules marking method is what" have a deeper understanding, might as well to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.