Master Dubbo: 8 Classic Interview Questions with Answers

Q1 – Core Architecture and Registry Failure

Dubbo consists of four roles: Provider (service provider that registers its address), Consumer (service consumer that subscribes to addresses), Registry (maintains the address book and pushes changes), and Monitor (collects call statistics asynchronously).

When the registry goes down, ongoing calls still work because:

Consumers keep a TCP long‑connection directly to Providers; the registry does not forward traffic.

Consumers cache the Provider address list locally and use it when the registry is unavailable.

Only discovery‑related capabilities are affected: new services cannot be discovered, Provider up/down events are not pushed, and monitoring may be interrupted. The registry is therefore a “soft” dependency.

Q2 – dubbo vs. triple Protocol

Comparison across key dimensions:

Transport : dubbo uses TCP long‑connection; triple uses HTTP/2.

Serialization : dubbo defaults to Hessian2; triple defaults to Protobuf (compatible with Hessian2).

Connection model : single long‑connection vs. multiplexed streams.

Cross‑language support : dubbo is weak; triple is strong (compatible with gRPC).

Streaming : dubbo does not support; triple supports unary, server‑stream, client‑stream, and bi‑stream.

Mesh / gateway friendliness : dubbo is unfriendly; triple is friendly.

Version : dubbo protocol is default in 2.x; triple is promoted in 3.x.

For new projects, the triple protocol is recommended because it avoids head‑of‑line blocking with HTTP/2 multiplexing, is gRPC‑compatible, offers strong streaming capabilities for AI or long‑running tasks, works well with service mesh and cloud‑native environments, and aligns with the community’s future direction.

Legacy pure‑Java systems that demand extreme throughput and do not need mesh support may still use the dubbo protocol.

Q3 – Built‑in Load‑Balancing Strategies

Dubbo provides five built‑in strategies:

Random (weighted) – default; selects a Provider randomly according to weight.

RoundRobin (weighted) – weight‑based round‑robin.

LeastActive – chooses the Provider with the fewest active requests.

ConsistentHash – routes the same parameter consistently to the same Provider.

ShortestResponse – selects the Provider with the shortest recent response time (available in Dubbo 3.x).

The default is @DubboReference(loadbalance = "random") or the global property dubbo.consumer.loadbalance. LeastActive is suitable when Provider capacities differ greatly, such as mixed‑generation machines, heterogeneous business loads, or mixed long/short tasks.

Q4 – Cluster Fault‑Tolerance Strategies

Six strategies are defined:

Failover (default) – retries other Providers up to 2 times; suited for idempotent reads.

Failfast – fails immediately without retry; required for non‑idempotent writes.

Failsafe – ignores failures, logs only; for non‑critical operations like logging.

Failback – asynchronous retry with scheduled re‑send; for low‑real‑time consistency scenarios.

Forking – parallel calls to multiple Providers, returns on first success; for ultra‑low‑latency reads.

Broadcast – calls all Providers; any failure aborts the whole call; for cache refreshes.

Non‑idempotent interfaces must use Failfast for two reasons:

It prevents duplicate execution (e.g., double order placement or double stock deduction).

It avoids retry‑induced load spikes (“retry storm”) that could overwhelm downstream services.

Dubbo only retries on network errors; business exceptions are not retried. For non‑idempotent calls, the safest configuration is

@DubboReference(cluster = "failfast", retries = 0, timeout = 3000)

.

Q5 – Dubbo SPI vs. Java SPI and @Adaptive

Java SPI drawbacks include eager loading of all implementations, lack of DI, no AOP, and rigid configuration via META-INF/services.

Dubbo SPI improves on these by:

Loading implementations on demand using a key=implementationClass map.

Supporting IOC so that an extension can have other extensions injected.

Allowing AOP via wrapper classes.

Providing @Adaptive for runtime selection based on URL parameters.

The @Adaptive mechanism works as follows: an interface method annotated with @Adaptive("loadbalance") triggers Dubbo to generate a dynamic proxy. At invocation time, the proxy reads the loadbalance parameter from the current URL, uses it as the SPI key, loads the corresponding implementation (e.g., RoundRobinLoadBalance), and delegates the call.

Example: @DubboReference(loadbalance = "roundrobin") results in the URL containing loadbalance=roundrobin, which the adaptive proxy uses to load RoundRobinLoadBalance.

Q6 – Application‑Level vs. Interface‑Level Service Discovery

Key differences:

Data volume : interface‑level stores interface × instance ; application‑level stores application × instance , dramatically reducing registry size.

Push granularity : interface‑level pushes on any interface change; application‑level pushes only when an application instance changes.

Address model : Dubbo’s own model vs. alignment with Spring Cloud/Kubernetes.

Cross‑ecosystem interoperability : difficult with interface‑level; easy with application‑level.

Reasons for the change:

Large‑scale applications generate massive registry data; application‑level discovery reduces storage and push pressure.

Aligns Dubbo with mainstream ecosystems (Spring Cloud, K8s) for smoother integration.

Push efficiency improves because only instance up/down events trigger updates.

Facilitates cloud‑native deployment (Service Mesh, Kubernetes).

The trade‑off is that Consumers must map application → instance to interface → instance locally, which Dubbo handles transparently via a MetadataCenter.

Q7 – Timeout Cascade Fault Scenario and Configuration Principles

Scenario: Consumer A → Service B → Service C, each with a 3 s timeout. If C’s downstream DB stalls for exactly 3 s, C times out, B waits 3 s for C, then times out, and finally A times out, resulting in a total latency of ~9 s and potential thread‑pool exhaustion. Adding Failover retries would exacerbate the problem.

Correct principle: use a “funnel” timeout where upstream timeouts are longer than downstream ones (e.g., A(timeout 6s) → B(timeout 3s) → C(timeout 1s)). Reasons:

Downstream failures surface first, allowing upstream to react quickly.

Upstream timeout must exceed the sum of downstream timeouts (including retries) to avoid premature cutoff.

Non‑idempotent interfaces should not retry; idempotent retries should be limited.

Practical tip: keep a 1.5–2× buffer between adjacent layers (e.g., downstream 1 s, upstream 1.5–2 s).

Q8 – Coexistence of Dubbo and Spring Cloud in Spring Boot 3 + Nacos

Registry : Both Dubbo 3 (application‑level discovery) and Spring Cloud share the same Nacos registry and configuration center, using a unified address book.

Protocol :

Internal Java services communicate via Dubbo triple (HTTP/2 + Protobuf) for high performance and mesh friendliness.

External entry points (frontend, third‑party, Spring Cloud services) use Spring Cloud Gateway + OpenFeign (HTTP/REST).

Dubbo services can expose both triple (internal) and REST (external) endpoints, achieving “high‑performance internally, universally accessible externally”.

Governance :

Rate limiting and circuit breaking are unified with Sentinel (Dubbo uses sentinel‑apache‑dubbo3‑adapter, Spring Cloud uses sentinel‑spring‑cloud‑starter).

Distributed tracing is shared (e.g., SkyWalking or Sleuth + Zipkin) so trace IDs flow across Dubbo and OpenFeign calls.

Configuration (timeouts, retries, load‑balancing) is pulled dynamically from Nacos Config via @DubboService / @DubboReference parameters.

In short, sharing Nacos for registry and config, using triple for internal RPC and REST for external access, and consolidating governance with Sentinel and a common tracing solution enables Dubbo and Spring Cloud to coexist smoothly on the same infrastructure.