Springcloud、分布式和微服务经典面试题

1.什么是分布式

根据功能进行拆分，分散压力。

2.什么是微服务

根据业务进行拆分，分散能力

3.分布式和微服务的区别

架构不同：微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务。微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。

作用不同：分布式：不同模块部署在不同服务器上，分布式主要解决的是网站高并发带来问题。微服务：各服务可独立应用，组合服务也可系统应用。

粒度不同：微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势， 不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。

4.单体架构和微服务的优缺点

• 上手难度
  • 微服务架构：API接口调用
  • 单体架构：数据库共享或本地程序调用
  • 结论：单体架构胜
• 开发效率
  • 微服务架构：早期设计和沟通的工作量加大，随着项目规模和时间的推移，效率变化不大
  • 单体架构：早期工作量小，随着项目规模和时间的推移，效率大幅度下降
  • 结论：对于简单项目单体架构胜,对于复杂项目微服务架构胜
• 系统设计（高内聚，低耦合）
  • 微服务架构：
    • 每个业务单独包装成一个微服务,数据和代码都从物理上隔离开来，实现高内聚低耦合相对容易
  • 单体架构：
    • 以包的形式对代码进行模块划分,控制得当即可实现高内聚
    • 最终都是在数据层面将整个系统耦合在一起
  • 结论：微服务架构胜
• 系统设计（扩展性）
  • 微服务架构：独立开发新模块,通过API与现有模块交互
  • 单体架构：在现有系统上修改,与现存业务逻辑高度耦合
  • 结论：微服务架构胜
• 需求变更响应速度
  • 微服务架构：各个微服务组件独立变更,容易实施敏捷开发方法
  • 单体架构：需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败
  • 结论：微服务架构胜
• 系统升级效率
  • 微服务架构：各个微服务组件独立升级,上手和开发效率高，影响面小
  • 单体架构：需要了解整个系统才可以正确修改,容易导致不相关模块的意外失败
  • 结论：微服务架构胜
• 运维效率
  • 微服务架构：
    • 大系统被拆分为多个小系统,部署和运维难度加大,但可以利用Devops等方式将运维工作自动化
  • 单体架构：简单直接
  • 结论：单体架构胜
• 代码复用性
  • 微服务架构：微服务组件可以在新项目中直接复用，包括前端页面
  • 单体架构：一般以共享库的形式复用后台代码
  • 结论：微服务架构胜
• 硬件需求
  • 微服务架构：按需为不同业务模块伸缩资源节点，一个系统需部署多个微服务，需要启动多个运行容器
  • 单体架构：整个系统只需要一个运行容器，为整个系统分配资源
  • 结论：对于简单项目单体架构胜,对于复杂项目微服务架构胜
• 项目成本
  • 微服务架构：项目早期和后期，成本变化曲线平缓
  • 单体架构：项目早期成本低，后期成本大
  • 结论：对于简单项目单体架构胜,对于复杂项目微服务架构胜
• 非功能需求
  • 微服务架构：为单独的微服务按需调优,甚至更换实现方式和程序语言
  • 单体架构：为整个系统调优，牵―发而动全身
  • 结论：微服务架构胜

5.SOA优缺点

SOA的优点：

1. 简单化系统的开发：
   由于soa具有组合性，可以利用现有的SOA资源，根据同样的开放标准，在不受平台限制的基础上，可以直接利用现有的资源进行组合，让后在按照自己的客户需求，进行进一步的开放。

2. 面向企业商业流程
   SOA是基于服务的构造，所以开放的出发点，就是如何解决企业流程中出现的问题。

3. 更好的适应性和扩展性
   由于soa的组件性，和优良的扩展性以及其组件性等待特征，SOA可以更具不同的需求，进行重新的组合和构造。

4. 互用性

5. 对系统的升级，分布，和维护有个更多的优化

6. 简化了提供，寻找和使用服务的过程

7. 通过共同资源的利用，减少了开支

SOA的缺点：

1. 减低了系统的性能
2. 在向标准化过度的转换过程，增加了简介费用
3. 很多没有太多意义的文件型信息
4. 对商业流程的计划要求甚高

6.微服务的注册中心和ESB的SOA的区别

• ESB：垄断，类似于中介
• 注册中心：只负责记录，跟返回地址，类似于114

7.什么业务适合缓存

8.什么业务适合本地缓存

本地缓存一般适合于缓存只读数据，如统计类数据。或者每个部署节点独立的数据，如长连接服务中，每个部署节点由于都是维护了不同的连接，每个连接的数据都是独立的，并且随着连接的断开而删除

9.什么业务适合远程缓存

如果数据在集群的不同部署节点需要共享和保持一致，则需要使用分布式缓存来统一存储，实现应用集群的所有应用进程都在该统一的分布式缓存中进行数据存取即可。

10.SpringBoot和SpringCloud的关系

SpringBoot、SpringCloud、SpringCloudAlibaba之间的关系？

• Spring Boot 是 Spring 的一套快速配置脚手架，可以基于Spring Boot 快速开发单个微服务
• Spring Cloud关注全局的微服务治理框架
• Spring Cloud是一个基于Spring Boot实现的开发工具
• Spring Boot专注于快速、方便集成的单个微服务个体
• Spring Boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置
• Spring Cloud很大的一部分是基于Spring Boot来实现，必须基于Spring Boot开发

总结：可以单独使用Spring Boot开发项目，但是Spring Cloud离不开 Spring Boot

11.SpringCloud和SpringCloudAlibaba的关系

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1B5S7stb-1648713457508)(C:\Users\20967\AppData\Roaming\Typora\typora-user-images\image-20220330210944756.png)]

总结：SpringCloud部分组件闭源，不再更新，阿里基于SpringCloud整合其中组件

12.SpringCloud和Double的区别

Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，基于RPC调用，对于目前使用率较高的Spring Cloud Netflix来说，它是基于HTTP的，所以效率上没有Dubbo高，但问题在于Dubbo体系的组件不全，不能够提供一站式解决方案，比如服务注册与发现需要借助于Zookeeper等实现，而Spring Cloud Netflix则是真正的提供了一站式服务化解决方案，且有Spring大家族背景。

前些年，Dubbo使用率高于SpringCloud，但目前Spring Cloud在服务化/微服务解决方案中已经有了非常好的发展趋势

人话：常用的组件：Dubbo自己集成，SpringCloud集成好了

13.CAP

CAP定理：三者不可同时获得，P一定要满足

• 一致性（C）：
  • 在分布式系统中的所有数据备份，在同一时刻是否同样的值
    • 所有节点在同一时间的数据完全一致，越多节点，数据同步越耗时
• 可用性（A）：
  • 负载过大后，集群整体是否还能响应客户端的读写请求
    • 服务一直可用，而且是正常响应时间
• 分区容错性（P）：
  • 分区容错性，就是高可用性，一个节点崩了，并不影响其它的节点
    • 100个节点，挂了几个，不影响服务，越多机器越好

分布式系统中P，肯定要满足，所以我们只能在一致性和可用性之间进行权衡

如果要求一致性，则选择zookeeper，如金融行业

如果要求可用性，则Eureka，如教育、电商系统

14.什么是自我保护

如果在15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制

15.心跳

在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除(默认90秒)