Last year, I saw an issue in the community, but I didn’t try to solve it until now. And take the opportunity to understand dubbo3’s new feature, application-level address push. It also lays a foundation for sorting out the source code details of Dubbo-Go-Pixiu

Issue – 9194: github.com/apache/dubb… Issue gist: Service mapping fails in multiple registries

The students in charge of dubbo3 development in the community believe that it should be a matter of consistency between the group attribute of the configuration center and metadata center configuration. But tracing calls down the chain is actually more than that. The next step is to expand the invocation link on the provider side to verify the requirement that the development group attribute be consistent

Dubbo3 address push validation documentation: www.yuque.com/apache-dubb…

This is a bit confusing, because there are some nouns that you haven’t seen before 2.7

This paper will be divided into three parts

  • Address push design for connecting to K8S
  • In the service registration of the specific implementation of the timing detail
  • How to locate and solve the grouping function of the related tag routing according to the environment (dev/prod/test) isolation service publication (in progress, currently write the implementation idea and code location)

Let’s think about what a simple RPC framework would look like. There are no more than three components: service provider, registry, and service consumer. But for companies with ever larger volumes of data, microservices are bound to break down into ever smaller particles. In other words, the number of service providers and service consumers will increase.

Then the problem comes, the mediation bridge registry responsible for RPC calls (assume ali’s NACOS here, please see my other article on Consistency analysis of ZooKeeper for the selection of the registry).

  • Does the pressure to read and write addresses increase as multiple service instances go online and offline?
  • If we partition only at the service level, then one day service interface A’ in application A calls service interface B’ in application B. Is it possible to make cross-application calls when registering different interfaces?
  • If one day your company tells you that you need to split different proportions of traffic according to the business domain of the service, how do you do it?

In response to the first issue, Dubbo 3.0 split the metadata center. Users have two options: setting the three central configuration options in dubbo-admin, or using XML, such as configuring the Dubbo-Demo-API module under the Dubbo source project

File path: ~ / dubbo dubbo – demo/dubbo – demo – XML/dubbo – demo – XML – the provider/SRC/main/resources/spring/dubbo – provider. XML

<? The XML version = "1.0" encoding = "utf-8"? > <! -- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You are under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xmlns="http://www.springframework.org/schema/beans" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"> <dubbo:application name="demo-provider" metadata-type="remote"> <dubbo:parameter key="mapping-type" value="metadata"/> </dubbo:application> <dubbo:config-center Address = "zookeeper: / / 127.0.0.1:2181" / > < dubbo: metadata - report address = "zookeeper: / / 127.0.0.1:2181" / > < dubbo: registry Id = "registry1" address = "zookeeper: / / 127.0.0.1:2181" group = "dubbo" / > < dubbo: protocol name = "dubbo port =" 1 "/" > < bean id="demoService" class="org.apache.dubbo.demo.provider.DemoServiceImpl"/> <bean id="greetingService" class="org.apache.dubbo.demo.provider.GreetingServiceImpl"/> <dubbo:service interface="org.apache.dubbo.demo.DemoService" timeout="3000" ref="demoService" registry="registry1"/> <dubbo:service Version = "1.0.0" group = "greeting" timeout = "5000" interface = "org. Apache. Dubbo. Demo. GreetingService" ref="greetingService"/> </beans>Copy the code

File path: ~ / dubbo dubbo – demo/dubbo – demo – XML/dubbo – demo – XML – consumer/SRC/main/resources/spring/dubbo – consumer. XML

<? The XML version = "1.0" encoding = "utf-8"? > <! -- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You are under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xmlns="http://www.springframework.org/schema/beans" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"> <dubbo:application name="demo-consumer" > <dubbo:parameter key="mapping-type" value="metadata"/> <dubbo:parameter key="enable-auto-migration" value="true"/> </dubbo:application> <dubbo:metadata-report address="zookeeper://yuluo-13:2181"/> <dubbo:registry address="zookeeper://yuluo-13:2181"/> <dubbo:reference id="demoService" check="true" interface="org.apache.dubbo.demo.DemoService"/> <dubbo:reference Version = "1.0.0" group = "greeting" id = "greetingService check" = "false" interface = "org. Apache. Dubbo. Demo. GreetingService" / > </beans>Copy the code

Dubbo :application,dubbo:metadata-report,dubbo:config-center, and dubbo: Registry are application-level address labels, metadata centers, and configuration centers respectively. What does the documentation say

The three central document: dubbo.apache.org/zh/docs/con…

How is the pressure on the registry to bring services offline resolved

The provider file provides two instances, demoService and GreetingService, when multiple service instances come online and offline, that is, service providers frequently register service instances during startup or publication

If there is a bug online at this point that requires multiple services to roll to the previous version before publishing, then you need a hub with the information to hold the metadata of the record registry. At this point, you need to select the type based on the different business interface, zK for consistency and NACOS for usability. For example, service interfaces A and B use ZK, and service interfaces C and D use NACOS. Different registries need a place to set the heartbeat lifetime, retry times, and so on. That’s what metadata centers do

Division of application-level service interfaces

If we partition only at the service level, then one day service interface A’ in application A calls service interface B’ in application B. Whether cross-application calls can be implemented when the registered interface is different

It’s important to explain what apps are, and as I mentioned, you might have a set of apps that use Zk1, a set of apps that use ZK2, and a set of apps that use NAOCS1. In this case, it is found that each set of services needs to be isolated and each set of services is exposed and discovered based on a metadata center

How to connect Kuberbenetes to Dubbo3 shows the service introspection structure of Dubbo3

Revision basically means grouping service instances, which is an application made up of a set of services.

Continue.. QwQ