Dubbo??????????????????????????
????????????????????????Dubbo?????????????????????????????????????????????????????????????????????????? ??????????????????????????????controller??service??????????????????????controller??????Dubbo??????RPC????service???????????????????????????????????? 1. ??????????????????Dubbo????????????RPC?????????????????????????????????????????????????????????????????????????????????????????????????????? 2. ????????RPC???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 3. ??????????????????web??service????????????????????????????????????????????service??????????????????????99%?????????????????????????????????????????????????????????????????????????????? ????????????????????????????????????????????????????????????????????SpringCloud????????????????????????????Dubbo?????????????????? ???????????????????????????????????????????????????????????????????????????????????????????0?5?? ?????????????????????????????? Dear members of the Dubbo development team, Greetings! Currently, our company is using Dubbo in our project. I have some questions regarding our current project architecture and would greatly appreciate official insights from your team. In our project architecture, we have separated the controller and service layers of a single service into two independent services. The controller layer uses Dubbo for remote RPC calls to the services. I have some concerns about this design: 1. Is this design necessary? Dubbo being a remote RPC framework should address inter-service communication. However, using this approach within a single service seems redundant. Is it an overcomplication? 2. Remote RPC calls do introduce additional network overhead. Network instability can lead to call failures. However, this could be avoided using local injection in cases of network instability. 3. By splitting a service into web and service components, doesn't it lead to extra server resource consumption? Moreover, most interfaces provided by the service are rarely called by other services. Registering these in the service registry, isn't this resource wastage? These are the aspects of the current architecture that I find puzzling. As I have previously worked more with Spring Cloud, I'm unsure if this architecture aligns with Dubbo's official recommendations. I hope to receive an official response. If my description is unclear in any way, please let me know. I'll do my best to provide a clear understanding. Thank you ?0?5! ??The example architecture code has been uploaded as an attachment.?? Zhao curryco...@qq.com
