spring cloud 常见面试题 来理解微服务(通俗易懂)
发布日期:2021-06-21 02:42:24 浏览次数:5 分类:技术文章

本文共 4249 字,大约阅读时间需要 14 分钟。

转载:

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

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

 

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

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

1          单机版 

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

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

2         分布式

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

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

3        微服务 

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

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

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

     拥有自己独立的数据库

 

---------------------------------------------------------------------------------------------------------------------------------------------------

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

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

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

 

 

                          什么是微服务?

  

此链接是 马丁.富勒  在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/Klhz555/article/details/90719058 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:Eclipse 提示内存不足
下一篇:Oracle数据库服务启动和关闭的先后顺序

发表评论

最新留言

能坚持,总会有不一样的收获!
[***.219.124.196]2024年04月14日 00时45分02秒

关于作者

    喝酒易醉,品茶养心,人生如梦,品茶悟道,何以解忧?唯有杜康!
-- 愿君每日到此一游!

推荐文章

跟涛哥一起学习嵌入式 32:Linux内核编译和启动分析 2019-04-26
跟涛哥一起学习嵌入式 33:《嵌入式C语言自我修养》书稿V1.0版 2019-04-26
编译Linux内核出现错误:make vexpress_defconfig & menuconfig 2019-04-26
BILSTM-CRF-2 2019-04-26
BILSTM-CRF-4 2019-04-26
BiLSTM-CRF-3 2019-04-26
字符串相似度计算算法 2019-04-26
cw2vec: Learning Chinese Word Embeddings with Stroke n-gram Information 2019-04-26
Transformer:The base of BERT 2019-04-26
指数移动平均(EMA)的原理及PyTorch实现 2019-04-26
PAT甲级真题 1047 Student List for Course (25分) C++实现 (需用vector存储,用set遍历、插入均O(logn)会超时) 2019-04-26
PAT甲级真题 1056 Mice and Rice (25分) C++实现(数组模拟分组淘汰赛,map记录重量排名,题意分析) 2019-04-26
PAT甲级真题 1062 Talent and Virtue (25分) C++实现(同乙级1015,简单sort排序) 2019-04-26
PAT甲级真题 1064 Complete Binary Search Tree (30分) C++实现(二叉搜索树中序转层次,队列递归法) 2019-04-26
PAT甲级真题 1071 Speech Patterns (25分) C++实现(cctype判断字符属性、stringstream分割字符串、map计数) 2019-04-26
PAT甲级真题 1078 Hashing (25分) C++实现(Quadratic probing 平方探测法解决hash冲突) 2019-04-26
PAT甲级真题 1079 Total Sales of Supply Chain (25分) C++实现(带深度的DFS) 2019-04-26
PAT甲级真题 1087 All Roads Lead to Rome (30分) C++实现(Dijkstra+DFS,带权无向图最优最短路径) 2019-04-26
PAT甲级真题 1088 Rational Arithmetic (20分) C++实现(有理数四则运算,简单模拟,注意测试点2、3) 2019-04-26
PAT甲级真题 1089 Insert or Merge (25分) C++实现 (同乙级1035 插入与归并,注意测试点2、4) 2019-04-26