How services communicate under different service governance frameworks

[anorqiu9]

我们目前遇到一个架构方面的问题，就是原基于dubbo的服务和现在基于springcloud的服务互调如何做？ 一种方案设计服务同时开启两个服务框架的服务接口为两个框架的服务同时提供服务 另一种方案是异构系统基于网关交互 这两种方案有什么优缺点？大家有没有碰到过类似的场景，是如何处理的？谢谢！

[sofastack-bot[bot]]

Hi @anorqiu9, we detect non-English characters in the issue. This comment is an auto translation by @sofastack-robot to help other users to understand this issue.

We encourage you to describe your issue in English which is more friendly to other users.

We are currently experiencing an architectural problem, how to do the intermodulation between the original dubbo-based service and the current springcloud-based service? One kind of scheme design service opens the service interface of two service frameworks at the same time. It provides services for the services of two frameworks at the same time. Have you ever encountered a similar scenario and how did you handle it? Thank you!

[NameHaibinZhang]

我们目前遇到一个架构方面的问题，就是原基于dubbo的服务和现在基于springcloud的服务互调如何做？ 一种方案设计服务同时开启两个服务框架的服务接口为两个框架的服务同时提供服务 另一种方案是异构系统基于网关交互 这两种方案有什么优缺点？大家有没有碰到过类似的场景，是如何处理的？谢谢！

dubbo 和spring cloud 互相调用，需要使用的是http接口来调用，个人推荐用网关来做交互，这样api的管理上更方便，当然也可以通过sidecar来解决

[anorqiu9]

我们目前遇到一个架构方面的问题，就是原基于dubbo的服务和现在基于springcloud的服务互调如何做？ 一种方案设计服务同时开启两个服务框架的服务接口为两个框架的服务同时提供服务 另一种方案是异构系统基于网关交互 这两种方案有什么优缺点？大家有没有碰到过类似的场景，是如何处理的？谢谢！

dubbo 和spring cloud 互相调用，需要使用的是http接口来调用，个人推荐用网关来做交互，这样api的管理上更方便，当然也可以通过sidecar来解决

是的，我也倾向于网关交互，由网关完成协议的转换，进行包括流量控制、安全访问控制等在内的API管理工作。如果一个服务同时处于两种服务框架治理之下，就意味着对这个服务的治理（如限流、熔断及安全访问等）必须在两个地方进行，这将会是一个挑战。 当然，如果使用service mesh架构，通过sidecar如sofamon来实现多RPC协议的支持，同时又能通过service mesh的控制平面实现服务治理的统一，这样就不存在上述说的挑战。 上述是我的理解，有不对的地方，欢迎指纠正及讨论， 谢谢！