springcloud和dubbo分别调用controller层和service层是两种微服务架构的最大区别？

[berg369]

许多讨论微服务架构中springcloud和dubbo区别的文章中，主要强调dubbo只是springcloud的子集，只是服务治理工具，不是完整解决方案。但是看了一下两者，感觉完全无法兼容，理念完全不同啊。
springboot开发的典型应用目录如下：

分Controller、service接口、Serviceimpl实现、dao等层次。
1、sprinbcloud是用http调用controller层的REST接口，就像App或前端页面访问一个REST接口一样，只是用RestTemplate封装简化了http调用的代码（httpClient的写法过于复杂）；sprinbcloud无法调用Service接口，Feign方式是在消费端加一个特别的接口类，看似以java API方式写调用，实际与restTemplate是一样的调用的controller层。
2、而Dubbo则需要提供接口类，是调用的Service层接口，把服务端的Service接口打成共享包，客户端导入就可以像写本地代码一样调用了。但是dubbo无法调用Controller，Controller类没有接口！客户端无法以java API方式调用。

那么哪种更好呢？springcloud可以通用于任何语言，因为全是http调用的json数据，不需要按照java API方式来写。这种方式耦合度小，可以与不同语言的第三方应用进行服务调用；Dubbo则与本地调用写法相似，java的标准写法（近年也已经支持了node.js和python等语言），更适合java技术栈，也更适合同构的微服务组件不需要与其它语言第三方应用整合的情况。个人感觉，service接口的意义，就是为了封装业务逻辑，controller只和于处理请求和返回，那么微服务调用service更合理，毕竟是后台调用，特别是微服务都是自己团队开发的，是一个业务应用的拆解，调用controller意义不大，很多情况下前端可以直接调用不同微服务的controller，干嘛在后端再调用一遍呢，除非是调用第三方的某个服务。
调用第三方的某个服务，一般用于应用整合比较松散的，按照第三方接口文档用restTemplate直接调用就行了，不像一个应用拆解为多个微服务之间的耦合，往往也很难要求第三方应用采用相同的服务注册中心。所以我倾向于用dubbo。

我的看法，请大家讨论！
以下是几个问题：
1、微服务应用调用controller还是service?
2、springcloud能调用service接口吗？
3、Dubbo能调用controller吗？怎么调用呢？
4、有必要都用上吗？以便两者都可以调用？

[berg369]

引用 1 楼 月光下的大D丶 的回复:

都是个人看法 1、微服务应用调用controller还是service? 根据业务来，如果系统划分比较多，那就用controller，前端通过路由来对应多个后台感觉比较合适（但是服务间调 用需要考虑 参数的 序列化和反序列化，较大的参数影响性能） 如果业务多，但是系统划分的少，那就用service ，需要改的只是后端 2、springcloud能调用service接口吗？ 不知道，只用它调用controller 3、Dubbo能调用controller吗？怎么调用呢？ 不知道，只用它调过service 4、有必要都用上吗？以便两者都可以调用？ 如果系统划分比较多，类似多平台，那么多平台可以使用 springcloud，平台的内部调用使用dubbo

从你的实践来看用法确实不同，分别调用controller和service。1回答没看明白，前端调用直接请求后端吧，微服务之间的调用应该是后端调用吧。

[月光下的大D丶]

引用 2 楼 berg369 的回复:

[quote=引用 1 楼 月光下的大D丶 的回复:] 都是个人看法 1、微服务应用调用controller还是service? 根据业务来，如果系统划分比较多，那就用controller，前端通过路由来对应多个后台感觉比较合适（但是服务间调 用需要考虑 参数的 序列化和反序列化，较大的参数影响性能） 如果业务多，但是系统划分的少，那就用service ，需要改的只是后端 2、springcloud能调用service接口吗？ 不知道，只用它调用controller 3、Dubbo能调用controller吗？怎么调用呢？ 不知道，只用它调过service 4、有必要都用上吗？以便两者都可以调用？ 如果系统划分比较多，类似多平台，那么多平台可以使用 springcloud，平台的内部调用使用dubbo

从你的实践来看用法确实不同，分别调用controller和service。1回答没看明白，前端调用直接请求后端吧，微服务之间的调用应该是后端调用吧。[/quote] 其实我的意思就是 场景需要调用的service 数量多时就用 dubbo，数量少 就用 spring-cloud， 针对前端， 不同的请求调用不同的服务， 针对后台，一个请求 一个服务接收，多个服务处理 可以把这个两个框架的开发环境都搭建一下，毕竟每个人的习惯 和 业务的侧重点是不一样的。。。。

[berg369]

网上看不到有人说springcloud无法调用Service层接口，或Dubbo无法调用Controller接口这种说法，请熟悉的高手来解答一下吧。

[月光下的大D丶]

都是个人看法 1、微服务应用调用controller还是service? 根据业务来，如果系统划分比较多，那就用controller，前端通过路由来对应多个后台感觉比较合适（但是服务间调 用需要考虑 参数的 序列化和反序列化，较大的参数影响性能） 如果业务多，但是系统划分的少，那就用service ，需要改的只是后端 2、springcloud能调用service接口吗？ 不知道，只用它调用controller 3、Dubbo能调用controller吗？怎么调用呢？ 不知道，只用它调过service 4、有必要都用上吗？以便两者都可以调用？ 如果系统划分比较多，类似多平台，那么多平台可以使用 springcloud，平台的内部调用使用dubbo

[weixin_44057095]

1、微服务应用调用controller还是service? 你如果指的是微服务与微服务之间的调用，那么肯定是直接调用dubbo的service 2、springcloud能调用service接口吗？ 如果你指的是对前端提供接口的话，你可以在controller中调用dubbo的service，前端肯定是无法rpc远程调用的。。 3、Dubbo能调用controller吗？怎么调用呢？ dubbo本身就是一个rpc服务框架，为什么要调用controller？ 4、有必要都用上吗？以便两者都可以调用？ 首先你要明确一个事情，dubbo的service适用于微服务之间的调用，第二，dubbo分提供方和消费方，至于消费方你要封装成controller给前端调也是可以的，或者你在其它微服务的业务层中直接调用dubbo的service也可以 基于以上的解答，不知道楼主明白了没有呢？

[KeepSayingNo]

你的概念都是错的，导致你找不到问题的答案。首先你拿出来的一张图不是spring cloud的代码结构，那是spring boot。 在我看来spring cloud是给微服务提供了一套完整的解决方案。 dubbo 是RPC的一个实现方案，它能提供的是RPC接口。如果要让它和你说的controller比，那应该是和restful接口比，restful接口是一类http接口。

[a863922230]

六楼正解，说的很到位，就是这样的。cloud 是restful 调用，或者说HTTP调用，同时 cloud有一整套的微服务治理方案。而dubbo 是rpc的一个实现方案，只能提供rpc接口。

[zhijiesmile]

最近正在研究服务的拆分，看到楼主的想法，有相同的感觉。
我觉得问题出现在我们对微服务的定义上
1、拆分是拆分的web服务还是拆分模块？
2、服务间的调用是高频还是低频？
使用feign或者dubbo只是表现形式上的不同。
比如：
1、拆分的是web服务，像淘宝和支付宝间的调用，是低频的，而且客户端在调用是，调用的都是各自的服务，那么这时候，应该选择springcloud的默认方式，如果淘宝有使用到支付宝的业务数据，通过feign进行调用；
2、拆分是按照模块拆分的，像淘宝内的商品模块，订单模块，库存模块，淘宝用户在下单时，调用淘宝web层接口，web层通过rpc方式调用订单service，库存service，然后返回结果，调用是高频的。
只是本人的一些见解，不知道是否正确。既然是一年前的文章，相信楼主已经成长为大佬了，望告知和指点！
本人在研究gateway进行dubbo的改造，如果楼主已经知道如何改造了，也请告知！