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

许多讨论微服务架构中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、有必要都用上吗？以便两者都可以调用？

参考：https://bbs.csdn.net/topics/396520807

===============================================================

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

===============================================================

疑问：

为什么要使用springCloud直接使用RestTemplate不行吗？