Hi ecit.yande, Yep you are right. In this way, we can reduce the burden of k8s clusters.
However, there is a question I think we should resolve first. That is why we use Kubernetes as a registry. In my mind, we try to adapt to Kubernetes Native Service and to adapt to Cloud Native instructions. That means Dubbo should work as other Cloud Native instructions do. If we do not need to care about this, why not directly use other registries, since we can sure that Kubernetes API server is not efficient enough like other registries. Albumen On Thu, Apr 29, 2021 at 12:02 PM 闫 强 <[email protected]> wrote: > Hi Albumen, > In my option, provider interact with k8s is more stable than > consumers. The premise of this conclusion is the number of providers is > less than that of consumers. When provider do updates only the same > application providers receive the notify not consumers. On the other hand, > a consumer application may need interact with many different providers, > this further increases the burden of k8s clusters. > > 发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用 > > 发件人: Albumen Kevin<mailto:[email protected]> > 发送时间: 2021年4月29日 9:57 > 收件人: [email protected]<mailto:[email protected]> > 主题: Re: [Discuss] A new way for service discovery in k8s > > Hi ecit.yande, > > Such a solution is likely to combine current Kubernetes and DNS registry > solutions. > > Benefit from Service Discovery model, registries which want to assimilate > into Cloud Native instructions can work with it. > This means we can simply write rarely information to the registry or > even no need to write ( like the DNS registry ). > > For Kubernetes registry, providers just need to write its revision ( a MD5 > string, used to point out the provider's version ), > and consumers can use Kubernetes Native Service to perceive providers. > > For DNS registry, providers even no need to write anything to the registry, > and consumers will establish connections to providers to fetch theirs > revision. > > One thing needs to be sure is that a single provider cannot perceive other > providers without using registry. > So, it is not easy for a single provider to interact as a registry. If > using registry to perceive others, was this necessary? > > What do you think? > > Albumen > > > On Sun, Apr 25, 2021 at 1:16 PM 闫 强 <[email protected]> wrote: > > > Hi all, > > > > I will describe a new way for sevice discovery. I hope the experts will > > point out where this scheme is feasible. > > > > General speaking, the provider can be registry, service discovery in > > consumer can simple call provider method from k8s service just as meta > > service. > > > > How can a provider become registry? > > Provider can Interact with k8s, monitor endpoint changes. Doing so, the > > interaction with k8s moving from consumer to provider.The interact with > k8s > > from application will be more stable. > > > > What happened when consumer call list provider method from k8s service? > > The k8s service represents for cluster of provider and it will be > > responsibility for loadbalance. > > > >
