SpringCloud 面试题_springcloud面试题

什么是微服务？

首先我们分为三个阶段：

• 1、单机版：也就是说把要做的所有应用程序放置在一个项目中， 最后将之后的war 或者jar部署在你的服务器，这种模式随着发展，终将会被淘汰，是因为出现的问题将随之而来，并发，耦合等问题，刻不容缓。
• 2、分布式：专业的事情交给专业的人去做，尽量降低耦合度（就是说每个模块是不受影响的 ）， 一个模块你只做一件小事情。
• 3、微服务：微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合，每一个微服务提供单个业务功能的服务,一个服务做一件事，从技术角度看就是一种小而独立的处理过程,类似进程概念，能够自行单独启动或销毁 ， 拥有自己独立的数据库。

什么是 spring cloud？

• Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

SpringBoot 和 SpringCloud 请你谈谈对他们的理解？

• 1）、SpringBoot 专注于快速方便的开发单个个体微服务。
• 2）、SpringCloud 是关注全局的微服务协调、整理、治理的框架，它将 SpringBoot 开发的单体整合并管理起来。
• 3）、SpringBoot 可以离开 SpringCloud 独立使用开发项目，但是 SpringCloud 离不开 SpringBoot，属于依赖关系。

Spring Cloud 和Dubbo的区别？

• 最大区别: Spring Cloudi抛弃了 Dubbo的RPC通信,采用的是基于HTP的REST方式。
• 严格来说,这两种方式各有优劣。虽然从一定程度上来说,后者牺牲了服务调用的性能,但也避兔了上面提到的原生RPC带来的问题。
• 而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。

什么是服务熔断？什么是服务降级？

• 熔断机制：应对雪崩效应的一种微服务链路保护机制。当查出链路中的某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常时则恢复调用链路。在SpringCloud 框架里熔断机制通过 Hystrix 实现，Hystrix 会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内调用20次，如果失败，就会启动熔断机制。熔断机制的注解是 @HystrixCommand
• 服务降级：一般是从整体负荷考虑。就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback 回调，返回一个缺省值。这样做，虽然水平下降，但好歹可用，比直接挂掉强。

微服务的优缺点是什么？说下你在项目开发中碰到的问题

• 优点：
  1）、每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求。
  2）、开发简单，开发效率提高，一个服务可能就是专一的只干一件事。
  3）、微服务能够被小团队开发，这个团队可以是2到5个开发人员组成。
  4）、微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
  5）、微服务能使用不同的语言开发。
  6）、易于第三方集成，微服务允许使用容易且灵活的方式集成自动部署，通过持续集成集成工具，如Jenkins、Hudson等。
  7）、微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作体现价值。
  8）、微服务允许你融合最新技术。
  9）、微服务知识业务逻辑代码，不会和 HTML 和 CSS 其他界面组件混合。
  10）、每个微服务都有自己的存储能力，可以有自己的数据库，也可以由统一的数据库。
• 缺点：
  1）、开发人员要处理分布式系统的复杂性。
  2）、多服务运维难度，随着服务的增加，运维的压力也在增加。
  3）、系统部署依赖。
  4）、服务间通讯成本。
  5）、数据一致性。
  6）、系统集成测试。
  7）、性能监控

微服务的技术栈（各项功能的实现所使用的技术）具体如下：

Eureka 和 Zookeeper 都可以提供服务注册与发现的功能，请说说两个的区别？

Zookeeper 保证了CP（C：一致性，P：分区容错性），Eureka保证了AP（A：高可用）

【1】当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息，但不能容忍直接 down 掉不可用。也就是说，服务注册功能对高可用性要求比较高，但 zk 会出现这样一种情况，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新选 leader。问题在于，选取 leader 时间过长，30 ~ 120s，且选取期间 zk 集群都不可用，这样就会导致选取期间注册服务瘫痪。在云部署的环境下，因网络问题使得 zk 集群失去 master 节点是较大概率会发生的事，虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可用是不能容忍的。
【2】Eureka 保证了可用性，Eureka 各个节点是平等的，挂掉几个节点不会影响正常节点的工作，剩余的节点仍然可以提供注册和查询服务。而 Eureka 的客户端向某个 Eureka 注册或发生连接失败，则会自动切换到其他节点，只要有一台 Eureka 还在，就能保证注册服务可用，只是查到的信息可能不是最新的。除此之外，Eureka 还有自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳，那么 Eureka 就认为客户端与注册中心发生了网络故障，此时会出现以下几种情况：
①、Eureka 不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务。
②、Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可用）
③、当网络稳定时，当前实例中新的注册信息会被同步到其他节点。
因此，Eureka 可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像 Zookeeper 那样使整个微服务瘫痪。