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

Question

许多讨论微服务架构中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。但如果是一个组织技术能力弱更多依赖第三方开发团队，它的微服务技术架构选springcloud能够不限制开发语言，这也是一种考量。如果以自己团队为主，统一的开发平台更省成本。

我的看法，请教各位，感谢！
1、微服务应用调用controller还是service?
2、springcloud能调用service接口吗？
3、Dubbo能调用controller吗？怎么调用呢？
4、有必要都用上吗？以便两者都可以调用？