lengmodkx commented on issue #13584:
URL: https://github.com/apache/dubbo/issues/13584#issuecomment-4881470203
I can confirm this is a real and blocking gap. Here is a concrete use case:
We have a Python-based OMR (Optical Mark Recognition) service that needs to
be called by Java microservices (Spring Boot 3 + Dubbo 3.3.6, Nacos service
discovery).
**What we tried**:
- Registered the Python service to Nacos via `nacos-sdk-python`, manually
constructing all Dubbo 3 metadata fields (`interface`, `path`, `methods`,
`category`, `service-name-mapping`, `metadata-type`, `prefer.serialization`,
etc.) to match what a Java Dubbo provider would emit
- Aligned protocol (`tri`), version (`""`), and migration mode
(`APPLICATION_FIRST`) on both sides
**The exact roadblock**: Dubbo 3 consumer-side `InterfaceRouter` requires
`MetadataService.getServiceMapping()` to resolve `interface → application`
mapping. Since Python has no MetadataService implementation (and no protobuf
spec to implement against), the consumer fails with:
> `No interface-apps mapping found in local cache`
Manually seeding `~/.dubbo/.mapping.{app}.dubbo.cache` worked as a hack, but
this is not production-viable.
**The broader issue**: Even with the protobuf definition provided in the
comment above, implementing MetadataService in a non-Java language still
requires:
1. A clear spec of which metadata fields are mandatory for application-level
vs interface-level discovery
2. The `service-name-mapping` protocol between MetadataService and Nacos
registration
3. Consistent behavior across Dubbo versions (we found that
`FORCE_INTERFACE` vs `APPLICATION_FIRST` migration modes have different
metadata requirements)
**Current status**: We abandoned the Dubbo approach and fell back to raw
HTTP calls, which works but loses all Dubbo benefits (load balancing, circuit
breaking, grayscale routing via `dubbo.tag`).
Happy to contribute testing or documentation if this moves forward.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
