apache/dubbo-go: a Go RPC framework that speaks the Java Dubbo wire protocol

What dubbo-go solves that a plain Go RPC library does not

Most Go RPC stacks assume both ends are Go. Dubbo-go assumes they are not. It is the Go implementation of Apache Dubbo and, per the README, is "compatible with other Dubbo language implementations", with full compatibility with Apache Dubbo (Java) through Triple protocol generic calls, group and version wildcard matching, and a redesigned TLS API.

The audience is specific: teams that already run Dubbo Java services and are adding Go services that must register in the same registry, be discovered by Java consumers, and appear in the same governance tooling. If you have no Dubbo estate, the interoperability features are dead weight and you are paying for a large dependency graph to get an RPC server you could build on gRPC alone.

The second audience is narrower but real: teams that want one server port serving both RPC and HTTP JSON. The README's own quick example starts a Triple server and then calls it with cURL, which means the same endpoint that a Go or Java client reaches over the Triple protocol also answers an HTTP POST with a JSON body.

The mechanism: registry, protocol and the Triple HTTP surface

The repository layout maps closely to the architecture. Top-level directories include registry/, protocol/, cluster/, filter/, config_center/, metadata/, metrics/, otel/, proxy/, remoting/, tls/ and graceful_shutdown/. The README's feature list names the pieces inside them: service discovery over Nacos, Zookeeper, Etcd and Polaris-mesh; load balancing strategies named Adaptive, Random, RoundRobin, LeastActive and ConsistentHash; HA strategies named Failover, Failfast, Failsafe/Failback, Available, Broadcast and Forking.

Configuration comes from a YAML file or from dynamic configuration through Nacos, Apollo or Zookeeper. The tools/dubbo-go-schema tool provides JSON Schema completion and validation for that YAML, which is a practical detail: the config surface is wide enough that editor validation matters more than it would in a smaller framework.

Triple is the part worth understanding before adopting. It is gRPC-compatible and HTTP-friendly, and the README shows a request against it as an ordinary HTTP POST with Content-Type: application/json to a path derived from the protobuf service and method name. That is what makes the cURL example work without a generated client. HTTP/3 support is described as experimental, and the go.mod lists github.com/quic-go/quic-go, so the QUIC path is compiled in rather than bolted on separately.

Installing dubbo-go and calling a Triple service with cURL

The README states the prerequisite plainly: Go 1.24 or later. The go.mod in the repository declares go 1.25.0, so a toolchain at 1.24 may need to be raised before the module resolves. Installation is a single module fetch:

go get dubbo.apache.org/dubbo-go/v3@latest

The README's quick example defines a service implementation, registers it on a server with the Triple protocol on port 20000, and serves:

srv, _ := server.NewServer(
	server.WithServerProtocol(
		protocol.WithPort(20000),
		protocol.WithTriple(),
	),
)

_ = greet.RegisterGreetServiceHandler(srv, &GreetTripleServer{})

if err := srv.Serve(); err != nil {
	logger.Error(err)
}

The handler itself is an ordinary Go method that takes a context and a generated request type and returns a generated response type. Once the server is running, the README says the service can be called without a generated client:

curl \
    --header "Content-Type: application/json" \
    --data '{"name": "Dubbo"}' \
    http://localhost:20000/greet.GreetService/Greet

What you should see is a JSON response carrying the greeting field. A Go client against the same service is three calls: client.NewClient with client.WithClientURL("127.0.0.1:20000"), greet.NewGreetService(cli), then svc.Greet with a GreetRequest. The README points to the helloworld sample in dubbo-go-samples as the full walkthrough, and that is where you should go next, because the snippet above elides error handling on the client constructors.

The 3.3.2 config removal is the upgrade hazard

The release notes for 3.3.2 lead with a breaking change: the config package has been removed, and callers should use the global package instead. The repository has a top-level global/ directory and no config/ directory, which is consistent with that. This is not a deprecation with a compatibility shim; the release notes describe it as completing the removal of the legacy config package.

The practical consequence is that any dubbo-go code written against an older tutorial will fail to compile after the upgrade, and the failure will point at an import path rather than at behavior. If you are evaluating dubbo-go from blog posts or Stack Overflow answers, check the date before you trust the import list. The README directs readers to dubbo-go-samples for current usage rather than documenting the migration inline.

The same release also lists fixes for races, stale-snapshot issues and resource leaks, and the Makefile carries a RACE_SKIP_TESTS list of tests skipped under the race detector because of known data races or test design defects. That list is a useful signal about where concurrency in service discovery and routing has historically been fragile, and it is worth reading before you assume the registry path is settled.

Where dubbo-go is the wrong tool

If your services are all Go and you have no Dubbo Java consumers, the interoperability machinery buys you nothing. The dependency graph in go.mod is large: Hessian2 serialization, a forked gRPC, Nacos and Polaris SDKs, Apollo, Zookeeper, Sentinel, QUIC, Prometheus, OpenTelemetry and a JavaScript interpreter (goja). That is a lot of transitive surface to audit for a service that only ever talks to other Go services.

The configuration model is the second friction point. A YAML file plus dynamic config centers plus a JSON Schema tool implies a configuration surface wide enough to need its own tooling. Teams used to configuring a Go server in code will find that a step backwards.

HTTP/3 is marked experimental in the README, so it should not be the reason you pick this project. And the console situation is worth noting: the README lists dubbo-admin and dubbo-go-extensions as under development, so if you expect a mature admin UI for the Go side, verify what actually exists before planning around it.

dubbo-go against gRPC and against Dubbo Java

Against gRPC, the difference is not the wire format. Triple is gRPC-compatible, so a gRPC client can reach a Triple service. The difference is what sits around the call: registry abstraction across Nacos, Zookeeper, Etcd and Polaris-mesh; the HA strategies listed in the README; traffic management features named as traffic split, timeout, rate limiting and canary release; and script routing plus multi-destination conditional routing introduced in 3.3.0. Plain gRPC leaves all of that to you or to a service mesh. The cost is that dubbo-go's governance features are configured through its own model, and the 3.3.2 config change shows that model is still moving.

Against Dubbo Java, dubbo-go is not an alternative, it is a peer. The README frames the relationship as compatibility: generic calls over Triple, group and version wildcard matching, TLS API redesign. If you are choosing between writing a new service in Go or in Java inside an existing Dubbo estate, the honest answer from the README is that both are supported paths, and the choice comes down to your team rather than to a capability gap the README documents. The Go side does not have a documented equivalent of every Java-side feature; the README notes the console and extensions repositories are under development.

Maintenance, licence and the cost of staying current

The repository is not archived, and the last push was on 2026-09-22. Releases are cut per tool as well as per framework: the three most recent are tools/protoc-gen-triple-openapi/v3.3.2, tools/protoc-gen-go-triple/v3.3.2 and tools/imports-formatter/v1.0.11, all dated 2026-08-05. That tagging scheme means a tool can move on its own version line, so pinning dubbo-go does not pin the code generators you use with it.

Licensing is Apache-2.0, and the repository carries the standard Apache layout: LICENSE, NOTICE, .asf.yaml, .licenserc.yaml and a Makefile whose header is the ASF boilerplate. The NOTICE file matters if you redistribute binaries, since Apache-2.0 requires propagating it. That is a description of the files present, not legal advice; check with your own counsel for your distribution model.

Upgrade cost is dominated by the config package removal and by the fact that the project ships its own protoc plugins. Regenerating bindings after a plugin bump is a separate step from bumping the framework, and the two version lines can drift.

Editorial conclusion

Adopt dubbo-go if you already run Dubbo Java and need Go services on the same registry and Triple protocol, or if you want an RPC server that answers plain HTTP JSON on a single port. Do not adopt it as a general-purpose Go microservice framework if you have no Dubbo estate: the config surface is large, and the 3.3.2 release deleted the config package, so any tutorial written before that release will not compile. Before writing code, check your Go version against the go.mod requirement (go 1.25.0), confirm whether your existing code imports the removed config package, and read the helloworld sample in dubbo-go-samples rather than the README snippet, which omits error handling and the server lifecycle.

Frequently asked questions

Official sources

1. apache/dubbo-go on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases