spring cloud 常见面试题来理解微服务（通俗易懂）

你的名字 2022-02-19 12:23 228阅读 0赞

# **更多微服务知识访问 [www.itkc8.com][]** #

**为什么要谈 这些理论知识呢   **

**                                           理论知识 = 面试时候的谈资 ！！！   
 **

** 你只有 进去公司 才有资格 去做一个码农 ok 话不多说  **

** 经历如此漫长的互联网发展  以本人的拙见 软件开发 粗略的 分为 三个阶段 **

**1          单机版 **

**     也就是说把 要做的所有应用程序 放置在一个 项目中 最后 将之后的war 或者jar  部署在你的服务器**

**     这种模式 随着发展  终将会被淘汰 是因为出现的问题 将随之而来  并发 耦合 等 问题 刻不容缓**

**2         分布式**

**     如何理解 ： 专业的事情 交给专业的人去做 尽量降低 耦合度（就是说 每个模块 是不受影响的 ）**

**     一个模块你只做一件小事情**

**3        微服务 **

**     微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合,**

**     每一个微服务提供单个业务功能的服务,一个服务做一件事,**

**     从技术角度看就是一种小而独立的处理过程,类似进程概念,能够自行单独启动或销毁 **

**     拥有自己独立的数据库**

** **

**---------------------------------------------------------------------------------------------------------------------------------------------------**

**对于 发展到现在如此艰难的 软件之路  我觉得 不要 只会用  所谓的技术！！！  **

**不要满足于 在 idea eclipse 等等 的开发工具中 按照  超级强大的提示  点一下点 然后出现一个方法去调用此方法 **

**到那时候 你还是所谓的 工程师 吗？ **

** **

**                          什么是微服务?**

** https://martinfowler.com/articles/microservices.html **

**此链接是 马丁.富勒  在2014年 左右 发表 微服务论点**

** 就目前而言,对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style, ）**

**      随着时间的推移  现在或许各有论点  ，对于以后 肯定会有一种统一的说法 （最终的说法）**

**翻译 ：**

**但通常而言,微服务架构是—种架构模式或者说是一种架构风格,它提倡将单一应用程序划分成-一组小的服务,每个服务运行在其独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的REST ful API)。毎个服务都围绕着貝体业务进行构建,并且能够被独立地部罟到生产环境、类生产环境等另外,应尽量避免统一的、集中式的服务管理机制,对具体的\_个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建,可以有一个非常轻量级的集中式管理来协调这些服务,可以使用不同的语言来编写服务,也可以使用不同的数据存储。 **

** **

**     微服务  强调的是服务的大小,它关注的是某一个点,是具体解决某一个问题/提供落地对应服务的一个服务应用**

**狭意的看,可以看作 Eclipse!里面的个个微服务工程/或者 Module**

**为什么  马丁.福勒 说 没有统一的定义说法呢 问题就在下面 如下图 **

** **

**       **

**根据业务   其实 对于拆分维度 到底该按什么拆分呢   我想 仁者见仁 智者见智 吧   **

**                 本人拙见  ：大多的公司应该是按照 业务来拆分  **

** 如果我去面试 这就是我的答案  **

**                 微服务之间是如何独立通讯的spring Cloud和 Dubbo有哪些区別?（很多 面试管会问） **

**本质区别： **

**dubbo 是 基于 RPC 远程 过程调用 **

**cloud 是基于 http  rest api 调用 **

**                                                       dubbo                                       spring cloud **

** **

**最大区别: Spring Cloudi抛弃了 Dubbo的RPC通信,采用的是基于HTP的REST方式。**

**严格来说,这两种方式各有优劣。虽然从一定程度上来说,后者牺牲了服务调用的性能,但也避兔了上面提到的原生RPC带来的问题。**

**而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适 **

**很明显, Spring Cloud的功能比 DUBBO更加强大,涵盖面更广,而且作为 Spring的挙头项目,它也能够与 Spring FrameworkSpring Boot.、 Spring Data、 Spring Batch等其他 Springi项目完美融合,这些对于微服务而言是至关重要的。使用 Dubbo构建的微服务架构就像组装电脑,各环节我们的选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了,总是让人不怎么放心,但是如果你是一名高手,那这些都不是问题;而 Spring Cloud就像品牌机,在 Spring Source的整合下,做了大量的兼容性测试,保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西,就需要对其基础有足够的了解。 **

**              Spring Boot和 Spring Cloud,请你谈谈对他们的理解 什么是服务熔断?**

** spring boot 是一个快速整合第三方框架   关注的是 微观 具体关注快速方便的开发单个个体的 服务 **

** spring cloud 关注的是 宏观  具体关注全局的微服务协调整理治理框架 将spring boot 开发的一个个单体服务整合 并管理起来**

**它为各个微服务之间提供 配置管理 服务发现 断路器路由 微代理 全局锁 分布式会话 等 集成服务**

**举个例子 ： 一所医院  boot 是 一个一个科室    cloud 是把一个一个科室 组合起来 对外称之为 医院**

**存在依赖关系  cloud   离不开boot **

**hystrix 断路器 **

** 服务熔断 是指    由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。 **

**                      什么是服务降级 微服务的优缺点分別是什么?**

** 用 通俗易懂的来说  ： 整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。**

**微服务的优缺点 ： **

**                     说下你在项目开发中碰到的坑你所知道的微服务技术栈有哪些?**

**微服务技术栈 ： 多种技术的结合体   **

**我们在讨论分布式的微服务架构的时候  它需要有哪些维度？ **

**1 服务治理   2 服务注册 3 服务调用 4 负载均衡 5 服务监控  **

**这五点称为落地维度   为什么叫落地  呢 ？**

**天上飞的理念 肯定要有落地的实现 **

**也就是说  分布式微服务架构    当作 天上飞的理念 **

**落地的实现 可以总结为**

**1 服务开发 ：spring boot spring mvc  spring **

**2  服务的配置与管理 ： netfix 公司 archaius 阿里的diamond等**

**3  服务的注册于发现 ：spriing cloud 所采用的 eureka ，consul,zookeeper 等**

**4 服务的调用:rest GRPC RPC **

**5 服务的熔断器 ：hystrix envoy等**

**6 负载均衡 ：ribbon .nginx**

**7 服务接口调用(客户端调用服务的简化工具) Feign等消息队列Kafka、 Rabbitmq、 Activemq等**

**8 服务配置中心管理Spring Cloud Config、Chef等服务路由(API网关)Zuu等**

**9 服务监控Zabbix、 Nagios、 Metrics、 Spectator等**

**10 全链路追踪Zipkin, Brave、 Dapper等**

**11 服务部罟Docker、 Open Stack、 Kubernetes等**

**12 数据流操作开发包Spring Cloud Stream(封装与 Redis, Rabbit、 Kafka等发送接收消息)**

**13 事件消息总线Spring Cloud Bus**

**请说说eureka和 zookeeper,两个的区別?**

**首先 说CAP 是什么  所谓的CAP  C强一致性  A可用性 P 分区容错性  
 **

**著名的CAP理论指出,**

**                     一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。 **

** **

**zookeeper 遵守 CP **

**当向注册中心查询服务列表时,    我们可以容忍注册中心返回的是几分钟以前的注册信息, 但不能接受服务直接down掉不可用。**

**也就是说,服务注册功能对一致性的要求要高于可用性。**

**但是zookeeper 会出现这样一种情况,   当 master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行 leader选举。**

**问题在于,选举 leader的时间太长,30~120s,目选举期间整个zookeeper 集群都是不可用的,这就导致在选举期间注册服务瘫痪。**

**在云部署的环境下,因网络问题使得zookeeper 集群失去 master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。 **

**或许  这个回答太过于抽象  用一种其他说法来说 就是 ：**

**   当有一个zookeeper  挂了  那其他的zookeeper 会进行 一次选举 （强一致性 ： 我一定要保持数据一致性）  而在此选举期间  zookeeper  是不可用的   而当前 有用户正在使用 用户就不爽了 。**

** eureka 遵守 AP  **

**     Eureka:看明白了这一点,因此在设计时就优先保证可用性。**

**Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。**

**而 Eureka的客户端在向某个 Eureka注册或时如果发现连接失败,则会自动切换至其它节点 **

**只要有一台 Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的不保证强一致性)。**

**除此之外, Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么 Eurekas就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:**

**1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务**

**2. Ureka仍然能够接受新服务的注册和査询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)**

**3.当网络稳定时,当前实例新的注册信息会被同步到其它节点中**

**因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情況,而不会像 zookeeper那样使整个注册服务瘫痪。 **

[https://blog.csdn.net/qq\_35906921/article/details/84032874][https_blog.csdn.net_qq_35906921_article_details_84032874]

[www.itkc8.com]: http://www.itkc8.com
[https_blog.csdn.net_qq_35906921_article_details_84032874]: https://blog.csdn.net/qq_35906921/article/details/84032874