一、spring cloud和k8s区别
1、k8s是无侵入性的
2、springcloud是侵入性的
3、k8s可以检测到服务的性能使用,而springcloud不能.可以自动扩展
k8s和springcloud的出发点不同，一个是基于容器管理的概念，一个是基于程序的注册与发现（我个人认为Netflix的核心在于注册中心）。二者都可以达到我们的目的。就拿实现一个高可用的注册中心Eureka来说，单纯从Netflix的设计思想来说，eureka是一个AP系统，要保证数据的同步，可以采用注册中心（Eurekaserver）相互注册的方案，实现一个集群，但是集群每加入一个节点，要更新所有的client的配置。常规的思想，我们可以通过负载均衡的轮询算法实现，然而这个思路正是k8s的出发点。可能SpringCloud+K8s二者皆用是一个最好的方案，但是二者择其一一样可以达到目的。
二、springcloud面试很难吗
SpringCloud面试相对来说比较有挑战性。首先，SpringCloud是一套涵盖了众多微服务组件的框架，涉及的知识点非常广泛，包括微服务架构、服务注册与发现、负载均衡、断路器、配置中心等等。
其次，面试官可能会针对具体的组件进行深入的技术细节和实践经验的提问，对面试者的理解和应用能力进行考察。因此，准备充分、对SpringCloud的各个组件和原理有深入掌握，并且有实际项目经验的面试者在面试中会有更大的优势。
三、微服务框架spring cloud和dubbo有什么区别
首先，从严格意义上来说，Dubbo和SpringCloud的定位是不一样的。Dubbo是一个高性能的、基于java的开源RPC框架，注意它的定位是是高性能和RPC框架。SpringCloud提供了一系列通用工具来帮助开发者在分布式系统里快速构建一些常见模式，比如分布式配置管理、服务发现、熔断降级、智能路由、微代理、控制总线、一次性令牌、全局锁、分布式选主、分布式session等一些列解决方案，它的设计目标是提供一整套服务治理能力，它具有一套完整的微服务解决方案体系。
dubbo只是一个分布式的RPC框架，如果一定要按照分布式系统架构里的功能来定义的话，只是解决了服务发现、服务路由、服务降级和负载均衡方面的能力，新版本里也提供了动态配置中心和服务治理相关的能力，但相比SpringCloud而言，还是差了相当一部分的能力。
从功能支持上来说，dubbo的角色定位可能更像是另外一个大名鼎鼎的框架，那就是gRPC，而且两者在使用的方式以及工作原理上都非常相似，都是基于序列化协议来解决分布式系统中的远程调用问题，在使用上可以通过约定接口或者通过proto文件生成代码文件来“提升用户的使用”。
如果你在系统设计之初就已经考虑到了后续可能会涉及到各种服务治理能力，比如分布式配置、全局锁、分布式session等常见需求，那么使用SpringCloud将会减少你很多的工作，因为这些基本上都是"套件"，相互配合使用会非常顺畅。如果你想要的只是解决分布式架构后的远程调用问题，那么Dubbo是一个不错的选择。
SpringCloud和Dubbo的基本差异大概就是如上所述，如果你不知道该如何做选择，这里再补充几个比较关键的差异点，希望能帮助你更好的结合自身业务做出选择：
能力支持方面
上文也提到，SpringCloud提供了一整套微服务治理的功能组件，很多组件基本上都是"开箱即用"的，并且相互之间能很好的兼容，举个例子，如果要在SpringCloud里实现服务发现、负载均衡和熔断降级，你只需要引用SpringCloud的依赖组件即可，直接通过注解便可使用，基本上零配置；而dubbo框架，除了上述提到的能力支持之外，如果想要使用熔断降级，那你可能需要额外引用hystrix或者resilience4j来实现；温馨提示，hystrix官方目前也已经宣布不再更新，并且推荐使用resilience4j。
协议兼容方面
SpringCloud里并没有限制服务之间的通信协议，但是主流的一些客户端比如restTemple、feign等都是直接支持使用Ribbon来做服务注册发现和智能路由的，其底层通信的协议都是HTTP；而dubbo框架缺省是基于NIO异步传输使用TCP长连接并采用Hessian二进制序列化方式通信的；
这会涉及后续系统在扩展上的兼容性问题，比如需要调用一个三方系统或者是被第三方系统调用，相比而言HTTP协议可能更加通用。
模型定义方面
dubbo在模型设计上将一个接口定义为一个服务，而SpringCloud里则是将一个应用定义为一个服务，这两者在模型上是存在很大差异的，你也许会奇怪，这个对使用会有影响吗？从现有使用方面来说是没有什么影响的，但是你如果有关注ServiceMesh最新微服务技术的话，目前对Dubbo协议这块可能支持暂时还不完善，其中很大一部分原因就是因为在服务模型上与K8S的服务模型有差异；
调用性能方面
如果分布式系统中比较关注远程调用的性能，那Dubbo可能是一个较好的选择，基于NIO和TCP长连接的通信传输方式，在性能上相比HTTP协议是有绝对优势的；当然基于SpringCloud你也可以使用gRPC协议来解决性能问题，那就是另外一个问题了。
四、springcloud七大组件
SpringCloud七大组件：
1、Eureka组件，描述了服务如何进行注册，注册到哪里；
2、Ribbon组件；
3、Feign组件，一个声明web服务客户端；
4、Hystrix组件，容错管理工具；
5、Config组件，配置管理开发工具包；
6、Zuul组件，边缘服务工具；
7、Bus组件，事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化。
OK，本文到此结束，希望对大家有所帮助。
