rpc in same zone or rpc in same cell

[carlvine500]

What is the purpose of the change

fix issue: #12763

most people depoy service in three zone for HA , we expect service rpc in same zone :

tag-subnets:

cn|shanghai|a:
- 172.37.66.0/24 #zone=cn-shanghai-a
- 172.37.67.0/24 #zone=cn-shanghai-a
cn|shanghai|b:
- 172.37.68.0/24 #zone=cn-shanghai-b
cn|shanghai|c:
- 172.37.69.0/24 #zone=cn-shanghai-c

some company's service are in a big zone , we expect service rpc in same cell :

tag-subnets:

cn|shanghai|a|cell-1:
- 172.31.35.0/24 #zone=cn-shanghai-a
cn|shanghai|a|cell-2:
- 172.31.36.0/24 #zone=cn-shanghai-a
cn|shanghai|a|cell-3:
- 172.31.37.0/24 #zone=cn-shanghai-a

some company's service are in serveral city, we expect service prefer rpc in same zone , and rpc special service across zone( such as stock quantity service):

tag-subnets:

cn|shanghai|a:
- 172.37.66.0/24 #zone=cn-shanghai-a
cn|hangzhou|b:
- 172.37.67.0/24 #zone=cn-hangzhou-b
cn|shenzhen|c:
- 172.37.68.0/24 #zone=cn-shenzhen-c
"":
- 172.37.69.0/24 #zone=cn-shanghai-d, as common service

Brief changelog

• add a configuration in configcenter: /dubbo/config/dubbo/tag.subnets , content is :

cn|shanghai|a:
- 172.37.66.0/24 #zone=cn-shanghai-a
cn|shanghai|b:
- 172.37.68.0/24 #zone=cn-shanghai-b
cn|shanghai|c:
- 172.37.69.0/24 #zone=cn-shanghai-c

• ServiceConfig.java will add a tag by subnet, such as :
  service on host 172.37.66.1 will add a dubbo.tag=cn|shanghai|a

• and then service in cn-shanghai-a will rpc same zone

• pull request tag support multi level #12673 will help to prefer rpc with long tag-level, for example:
  consumer rpc tag=cn|shanghai|a
  prefer1: service tag=cn|shanghai|a
  prefer2: service tag=cn|shanghai
  prefer3: service tag=cn
  prefer4: service tag=""

Verifying this change

Checklist

• Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
• Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Add some description to dubbo-website project if you are requesting to add a feature.
• GitHub Actions works fine on your own branch.
• If this contribution is large, please follow the Software Donation Guide.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
3 Code Smells

33.3% Coverage
0.0% Duplication

[codecov-commenter]

Codecov Report

Merging #12764 (f078030) into 3.2 (c54e1b6) will increase coverage by 2.45%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                3.2   #12764      +/-   ##
============================================
+ Coverage     66.87%   69.32%   +2.45%     
  Complexity        2        2              
============================================
  Files          1782     1649     -133     
  Lines         71677    68268    -3409     
  Branches      10243     9980     -263     
============================================
- Hits          47931    47329     -602     
+ Misses        19132    16374    -2758     
+ Partials       4614     4565      -49     

see 169 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[AlbumenJ]

Seems like a dynamic tag service?

[carlvine500]

Yes! subnets( 172.37.66.0/24,172.37.67.0/24) , they are allocated with zone in aws-VPC or aliyun-VPC , dubbo will generate a tag by these subnets .

some developer can debug these tag in a zone , eg: dubbo.tag=cn|shanghai|a|cell-1 .

developer in our company always forget to start dubbo with tag , we can add a default tag by subnet(192.168.0.0/16) .

Yes!
subnets( 172.37.66.0/24,172.37.67.0/24) , they are allocated with zone in aws-VPC or aliyun-VPC ,
dubbo will generate a tag by these subnets .

SRE will not pay more attension to add tag for deployment for multiple zone or cell .
and developer in our company always forget to start dubbo with tag , they can get a default tag with zookeeper config :
/dubbo/config/dubbo/tag.subnets

cn|shanghai|office-zone:
- 192.168.0.0/16 #zone=shanghai office zone
cn|beijing|office-zone:
- 10.8.0.0/16 #zone=beijing office zone

developer(192.168.1.223) in shanghai office zone will rpc in shanghai with dubbo.tag=cn|shanghai|office-zone ;
developer(10.8.1.172) in beijing office zone will rpc in beijing with dubbo.tag=cn|beijing|office-zone ;

[AlbumenJ]

Can this be split into an independent module in dubbo-spi-extensions?

[carlvine500]

Can this be split into an independent module in dubbo-spi-extensions?

OK , I will try to refactor .

@AlbumenJ is there any way to add dubbo.tag to registry in dubbo-spi-extensions ?
provider will generate dubbo.tag by subnets and store it in registry , consumer call provider by the dubbo.tag .

[carlvine500]

@AlbumenJ thanks for your suggestion, this pull request was migrated to dubbo-spi-extensions: 216

[AlbumenJ]

Let's working on apache/dubbo-spi-extensions#216