SpringCloud微服务面试题（一）

辉博士

已于 2024-02-29 20:18:55 修改

阅读量944

点赞数 19

分类专栏： Spring Cloud 文章标签： spring cloud

于 2024-02-28 13:53:42 首次发布

本文链接：https://blog.csdn.net/qq_39365155/article/details/136334677

版权

Spring Cloud 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

话不多说，直接上干货。

1：什么是服务雪崩和服务限流

1.1、服务雪崩

当A服务调用服务B,服务B调用服务C，此时大量的请求突然请求服务A，假如服务A本身扛得住这些请求，服务C扛不住，导致服务C请求堆积，从而服务B请求堆积，从而服务A不可用，这就是服务雪崩。

解决方案：服务降级和服务熔断。

1.2、服务限流

服务限流是指高并发请求下，为了保护系统，可以对访问服务的请求进行数量上的限制，从而防止系统被大量的请求压垮，在秒杀中，限流非常重要。

2：服务熔断和服务降级的区别

2.1、服务熔断

服务熔断指当服务A调用服务B时，服务B不可用，上有服务A为了保证自己不受影响，从而不再调用服务B，直接返回结果，减轻服务A和服务B的压力，直到服务B恢复。

2.2、服务降级

服务降级指，当发现系统压力过载时，可以通过关闭某个服务，或限流某个服务来减轻系统压力，这就是服务降级。

相同点：

1：都是为了防止系统崩溃

2：都让用户体验到某些功能暂时不可用

不同点：

熔断是下游服务触发的，降级是为了降低系统负载。

3：微服务的优缺点

微服务是由Martin Flowler大师提出的。微服务是一种架构风格，通过将大型的单体应用划分为较小的服务单元，从而降低整个系统的复杂度。

优点：

1、服务部署更灵活：每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性降低。

2、技术更新灵活：在大型答题应用住，技术要进行更新，往往非常困难。而微服务可以根据业务特点，灵活选择技术栈。

3、应用性能提高：大型单体应用肿，往往启动就会成为一个很大的难题，耗时长，异常诱因多。二采用微服务之后，整个系统的性能是能够得到提高的。

4、团队组合容易：在单体应用时，团队成员往往需要多系统各部分深入了解，门槛很高，采用微服务之后，可以给每个微服务组件专门的团队。

5、代码复用：很多底层服务可以以REST API的方式对外提供统一服务，所有的基础服务可以在整个微服务系统中通用。

缺点：

1、服务调用的复杂性增高：网络问题，容错问题，负载问题，高并发问题。。。。

2、分布式事务：尽量不要使用微服务事务。

3、测试难度提升了

4、运维难度提升：单体架构只维护一个环境，而微服务是很多个环境，并且运维方式还不一样。所以对部署，监控，告警等要求会变得非常困难。

4：如何保证微服务的敏捷开发

单体架构：固定时间发布新版本，以分支的形式保存到代码库中，多需求情况下发布难。

微服务：服务应用功能单一，可以快速入职。

方法：

采用任务看板，站立会议的形式，避免无效的沟通。

团队人员灵活流动，同时形成各个专家代表。

测试变的复杂，之前统一的测试环境，微服务需要测试环境SIT，集成测试环境，压测环境STR，预投产环境，生产环境PRD。

敏捷讲究文档优先，可以通过晨会，周会，需求拆分会等形式根据项目任务进度。

5：链路追踪

1、基于日志，形成全局事务ID，落地到日志文件，filebeat-logstash-Elasticsearch形成大型报表。

2、基于MQ，往往需要架构支持，经过流式计算形成一些可视化的结果。

6：持续继承

SpringBoot maven pom-->build -->shell;

Jenkins通过git+shell命令自动拉取提交的最新代码，发布到测试环境。

7：AB发布

1、蓝绿发布，红黑发布。特点就是老版本和新版本是同时存在的。

2、灰度发布，金丝雀发布。（部分发布）

8：怎么拆分微服务

拆分微服务的时候，为了尽量保证微服务的稳定，会有一些基本的准则：

1、微服务之间尽量不要有业务交叉

2、微服务之间只能通过接口进行服务调用，而不能绕过接口直接访问对方的数据库

3、做到高内聚，低耦合。

9：怎么设置高内聚、低耦合的微服务

高内聚低耦合，是一种自上而下知道微服务设计的方法。

实现高内聚低耦合的工具主要有同步的接口调用和异步的事件驱动（MQ)两种方式。

10：DDD领域驱动设计是什么

传统的设计像是一个大泥团，把所有的业务，层级都揉合在一起。

在此大泥团结构之上拆分出来的微服务依然存在泥团结构。当业务逐渐负责，这个泥团又会膨胀成为大泥团。

DDD领域驱动设计是一种方法论，没有一个稳定的技术框架。DDD要求领域是跟技术无关，存储无关，通信无关的。

11：什么是中台

中台的概念，是由阿里在2015年提出的“小前台，大中台”战略思想。

“小前台，大中台”战略思想，启发于superCell这样的公司，主要是阿里旗下做游戏的公司，比如《皇室战争》《部落冲突》。

所谓中台，就是将各个业务线中可以复用的一些功能抽取出来，剥离个性，提取共性，形成一些可复用的组件，如盒马鲜生，团购等。

分类：大体上中台可以分为三类，业务中台，数据中台和技术中台。

大数据杀熟——数据中台

技术中台——电商，收银中台，支付风控中台

中台和DDD领域驱动设计结合：DDD会通过界限上下文将系统拆分成一个一个的领域，而这种限界上下文，天生就成了中台之间的逻辑屏障。

DDD领域驱动设计在技术与资源调度方面都能够给中台建设提供不错的指导。

DDD分为战略设计和战术设计，上层的张略设计能够很好的知道中台划分，下层的战术设计能够很好的知道微服务的搭建。

在目前阶段，DDD领域驱动设计都处在小范围的实验阶段。

12：注册中心的核心功能

注册中心又Eureka，Nacos。

以Nacos为例：

服务注册：当服务启动，通过Rest请求的方式向Nacos Server注册自己的服务

服务心跳：Nacos Client会维护一个定时心跳持续通知Nacos Server，默认5s一次，如果nacos client超过15s没有收到心跳，会将服务健康状态设置为false（拉取的时候会忽略），如果Nacos Client超过30s没有接收心跳，剔除服务。

服务发现：NacosClient会有一个定时任务，实时去Nacos Server拉取健康服务

服务停止：NacosClient会主动通过Rest请求NacosServer发送一个注销的请求。

13：谈谈配置中心

Nacos有一个配置中心。

原理：

Nacos服务端创建相关配置项后，客户端就可以进行监听。

客户端通过一个定时任务来检查自己监听的配置项的数据，一旦服务端的数据发生变化时，客户端就会获取最新的数据，并将最新的数据保存在一个CacheData对象中，然后重新计算CacheData的md5属性值，此时会对该CacheData所绑定的Listener触发receiveConfigInfo（接收配置信息）回调。

拉的优势：

拉去服务端数据与服务端推送给客户端数据相比，优势？为什么不采用推送数据的形式？

如果采用推送的方式，服务端需要和客户端建立长连接，需要消耗大量的资源，并且还需要考虑链接的有效性，例如需要通过心跳来维持两者直接的链接。

而用拉取的方式，客户端只需要通过一个无状态的http请求即可获得服务端的数据。