Hello, community
We have previously roughly discussed the problems with Dubbo's metadata in GitHub issues and mailing list, here when saying metadata I mainly refer to URL in Dubbo. Now I think it's time to bring the discussion onto the table and consider solving it. Below is the proposal I've drafted:
Problems
URL works as the carrier for Dubbo internal data transfer at runtime, and is also works as a protocol integrating with the external system: registration center, service query, service management, etc., resulting in serious coupling between the configuration and the registration center, and the data load pushed by the registration center is too large.
Targets
- Keep URL unchanged at runtime, and even enrich the runtime URL; Keep the immutability of the URL during a single invoke from start to end.
- Simplify Registry url as much as possible.
- Refactor the way of doing service configuration, rely on Registry currently, switch to third-party Config Center while keeping compatible with old Overrides protocol.
- Some data in URL are for service query purpose, we should register this part to another place instead of Registry. And it should be realized as extensible and users can decide to enable it or not.
Solutions
Here is a typical URL in Registry:
dubbo://10.122.111.22:20880/com.xxx.compose.ic.service.vas.ValueAddServiceCompose?anyhost=true&application=goods-compose&default.actives=400&default.delay=-1&default.dispatcher=all&default.group=online&default.loadbalance=leastactive&default.service.filter=-monitor&default.threads=400&default.timeout=2000&default.version=1.0&delay=1&dubbo=2.6.2&environment=product&interface=com.xxx.compose.ic.service.vas.ValueAddServiceCompose&logger=slf4j&methods=queryValueAddServiceEditVOs,auditPassByValueAddServiceIdList,getValueAddServiceVOByServiceIds,getValueAddServiceInfoByGoodsIdList,getRuleMatchVOByGoodsIdList,getValueAddServiceEditVOById,getValueAddServiceEditVOByIds,queryValueAddServiceVOs,disableValueAddService,auditRejectByValueAddServiceIdList,saveValueAddServiceEditVO,enableValueAddService&organization=someorg&owner=somebody&pid=54812&revision=1.18.0628.3&side=provider×tamp=1530671441040
We can see this URL showed here is really long and redundant, here are my suggestions to refactor it step by step:
- Only keep necessary part in Registry
For example:
dubbo://10.122.111.22:20880/com.xxx.compose.ic.service.vas.ValueAddServiceCompose?timeout=1000&group=online&version=1.0&weight=100×tamp=1530671441040
- Find a new place for those parameters only for query purpose
For example:
delay=1&dubbo=2.6.2&interface=com.xxx.compose.ic.service.vas.ValueAddServiceCompose&logger=slf4j&methods=queryValueAddServiceEditVOs,auditPassByValueAddServiceIdList,getValueAddServiceVOByServiceIds,getValueAddServiceInfoByGoodsIdList,getRuleMatchVOByGoodsIdList,getValueAddServiceEditVOById,getValueAddServiceEditVOByIds,queryValueAddServiceVOs,disableValueAddService,auditRejectByValueAddServiceIdList,saveValueAddServiceEditVO,enableValueAddService&organization=someorg&owner=somebody&pid=54812&revision=1.18.0628.3&side=provider
- Deprecate the Override protocol in Registry
Typical Override protocol to change timeout value at runtime:
override://0.0.0.0/com.xxx.compose.ic.service.vas.ValueAddServiceCompose?category=configurators&dynamic=false&application=foo&timeout=1000
We can instead integrate with thirdparty Config Center to do that, like Apollo, Archaius, Diamond and so on, these systems are more likely to be used in a miscroservice architecture.
Furthermore, we can also consider separate the routing rule config from Registry and switch to Config Center, using Config Center to dynamically add new group policies that can group service instances into different groups according to environments.
Kindly ask for your suggestions, don't hesitate to let us know if you have any different ideas.
Hello, community
We have previously roughly discussed the problems with Dubbo's metadata in GitHub issues and mailing list, here when saying metadata I mainly refer to URL in Dubbo. Now I think it's time to bring the discussion onto the table and consider solving it. Below is the proposal I've drafted:
Problems
URL works as the carrier for Dubbo internal data transfer at runtime, and is also works as a protocol integrating with the external system: registration center, service query, service management, etc., resulting in serious coupling between the configuration and the registration center, and the data load pushed by the registration center is too large.
Targets
Solutions
Here is a typical URL in Registry:
We can see this URL showed here is really long and redundant, here are my suggestions to refactor it step by step:
For example:
For example:
Typical Override protocol to change timeout value at runtime:
We can instead integrate with thirdparty Config Center to do that, like Apollo, Archaius, Diamond and so on, these systems are more likely to be used in a miscroservice architecture.
Furthermore, we can also consider separate the routing rule config from Registry and switch to Config Center, using Config Center to dynamically add new group policies that can group service instances into different groups according to environments.
Kindly ask for your suggestions, don't hesitate to let us know if you have any different ideas.