Proposal for Dubbo-go registry plugins

[justxuewei]

As of today, Dubbo-go has become a powerful RPC Golang library. However, it is a heavy and complex framework. The Dubbo-go team is working on simplifying the architecture.

We are planning to introduce Dubbo-go plugins, see apache/dubbo-go-contrib. The core library, this repo, defines interfaces for key capabilities such as the registry and config center. The plugins will be installed on demand and will be responsible for providing specific implementations based on these interfaces.

Here is a snippet of pseudocode that gives an example of starting a server:

import (
    // core library
    dubbo "dubbo.apache.org/dubbo-go/v3"
    // nacos plugin
    "github.com/apache/dubbo-go-contrib/registry/nacos"
)

fn main() {
    registry := nacos.NewRegistry(...)
    server := dubbo.Init(dubbo.WithRegistry(registry), ...)
    server.Run()
}

With this architecture, functionalities that users don't depend on are not imported and do not affect the user's business. Additionally, we are planning to refactor the API exposed to the users to make it more user-friendly. Our team will focus on improving stability, maintainability, and user experience.

The proposal for plugins can be referenced to #2326.

Please leave a comment if you have any ideas or would like to contribute.

[ev1lQuark]

Before implementing specific development tasks, I believe we should establish a development plan. Below is a rough outline I have prepared based on recent meeting discussions:

1. Starting with the registry center, Polaris, we will separate the registry center's related interfaces and method declarations from the specific implementations associated with Polaris. The interfaces will be kept in the dubbo-go repository, while the specific implementations will be refactored into the dubbo-go-contrib repository. We will create a sample directory restructuring process for the first specific functional module. In this step, the code content should not be modified, focusing solely on the restructuring of the specific implementation code location.
2. We will examine the service registration interface and its method declarations, perform lightweight refactoring of the interface definitions, and address any potential legacy issues. This step should comprehensively consider the specific implementations of the interfaces, as they will serve as references for other specific implementations once defined.
3. We will synchronize the other implementations of the service registration interface, complete the full refactoring of the service registration module, and summarize the refactoring experience.
4. Following the refactoring process of the service registration module, other modules will undergo refactoring and migration work to achieve a comprehensive refactoring of dubbo-go.

Objectives:

• For open-source contributors, the organization and structure of the dubbo-go repository code will become more concise and clear. The core functionality implementation will be oriented towards interface programming, while specific implementations will be decoupled into dubbo-go-contrib, improving code readability and maintainability.
• For users, we will provide more concise, user-friendly, and easily understandable dubbo-go APIs.

---

落实到具体的开发工作之前，我认为我们应该确定一个开发计划，下面是我结合最近的会议内容整理出的大致方案：

1. 以注册中心 Polaris 为起点，将注册中心相关接口和方法声明与 Polaris 相关的具体实现相分离，接口保留在 dubbo-go 仓库内，具体实现重构到 dubbo-go-contrib 仓库中，创建第一个具体的功能模块目录重构的过程示例。本步骤原则上不应该修改代码内容，仅是具体实现代码位置的重构。
2. 对于服务注册接口及接口的方法声明进行检查，对于接口定义进行轻量级重构，以及修复可能存在的遗留问题。该步骤应全面结合接口的各个具体实现，一旦定义好之后将被其他具体实现的参考。
3. 同步服务注册接口的其他实现，完成服务注册模块的完整重构，并总结重构经验。
4. 其他各模块根据服务注册模块的重构流程进行重构迁移工作，完成 dubbo-go 的全面重构。

目标：

• 对于开源贡献者，dubbo-go 仓库代码的组织和结构将更加简洁清晰，内核侧功能实现均面向接口编程，具体实现解耦到 dubbo-go-contrib 中，提高代码可读性和可维护性。
• 对于用户，将会提供更加简洁友好、易于理解的 dubbo-go APIs。

[justxuewei]

I can't agree more. The first plugin we are going to refactor is Polaris registry. The first thing is to define the registry interface. @jasondeng1997 @ev1lQuark Could you elaborate more details about your work?

In my option, the BaseRegistry struct should be removed. Instead, the core library provides some foundational functions. The interface could be designed to follow the "watch-and-list" model as what Kubernetes do. The final interface will look like:

type Registry interface {
    Register()
    Unregister()
    GetService()
    ListServices()
    Watch()
}

EDIT1: This is at a very early stage. We should discuss the feasibility of this design first, and then we can continue to further enrich the details. We should maintain both the old registry and the new registry for a while until we confirm that the new one functions properly.

[jasondeng1997]

What are the benefits of this change

[justxuewei]

Don't you think the current subscribing model is too heavy to maintain? We have tons of concepts, like "Directory", "Node", etc. The objective is to streamline our framework, not just by moving the code outside Dubbo-go, but also by simplifying the design.

EDIT1: Btw, we need a more modern architecture. To achieve this, it requires to give up some out-of-date and over-complex concepts and architectures.

[DMwangnima]

Don't you think the current subscribing model is too heavy to maintain? We have tons of concepts, like "Directory", "Node", etc. The objective is to streamline our framework, not just by moving the code outside Dubbo-go, but also by simplifying the design.

EDIT1: Btw, we need a more modern architecture. To achieve this, it requires to give up some out-of-date and over-complex concepts and architectures.

I agree with you about simplifying the design and using list-and-watch model. For now, RegistryDirectory is responsible for caching and filtering. Maybe we could split these two parts? For caching part, turn RegistryDirectory into RegistryCache. RegistryCache also needs to implement Registry interface and is responsible for processing events from the registry with starting a loop. For filtering part, Directory implementation class relies on Registry interface directly.

[willcfyang2]

when will this Proposal publish
这个特性什么时候发布

[justxuewei]

when will this Proposal publish

这个特性什么时候发布

This is in planning stage. We don't confirm the time those features are available. So stayed tuned. If you are interested, please feel free to let me know.