【SpringCloud】一、入门概念基础小白篇

最新推荐文章于 2024-07-13 09:44:57 发布

_popo_

最新推荐文章于 2024-07-13 09:44:57 发布

阅读量569

点赞数

分类专栏： 2020 文章标签：分布式

本文链接：https://blog.csdn.net/qq_41864648/article/details/105956623

版权

本文是关于SpringCloud的入门介绍，从微服务面试题出发，深入探讨微服务概念、通讯方式、SpringCloud与Dubbo的区别，以及SpringBoot与SpringCloud的关系。内容涵盖微服务优缺点、服务熔断和降级，并比较了Eureka与Zookeeper的服务注册与发现功能。此外，还介绍了SpringCloud组件架构，以及如何构建REST微服务案例工程。

摘要由CSDN通过智能技术生成

文章目录

来自于尚硅谷2018版的学习笔记~每天进步一点，加油(ง •_•)ง

一、从面试题开始

1.1 什么是微服务？

微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行在其独立的自己的进程中，服务之间互相协调、互相配合
服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的 RESTfulAPI）
从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动
或销毁，拥有自己独立的数据库。
每一个微服务提供单个业务功能的服务，一个服务做一件事。围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的去集中化控制。

1.2 微服务之间是如何独立通讯的

同步通信：dubbo通过 RPC 远程过程调用、springcloud通过 REST接口json调用等。
异步：消息队列，如：RabbitMq、ActiveMq、Kafka 等。

1.3 springCloud和Dubbo有哪些区别？

摘自：https://blog.csdn.net/xuri24/article/details/89283802

整体比较

1、dubbo由于是二进制的传输，占用带宽会更少

2、springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大

3、dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决

4、springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级

5、dubbo的注册中心可以选择zookeeper,redis等多种，springcloud的注册中心只能用eureka或者自研

最大的区别:

Spring Cloud抛弃了Dubbo 的RPC通信，采用的是基于HTTP的REST方式。

严格来说，这两种方式各有优劣。虽然在一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适。

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

SpringCloud是基于SpringBoot的一套实现微服务的框架。
　　为微服务体系开发中的架构问题，提供了一整套的解决方案，它提供了微服务开发所需要的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。最重要的是，跟SpringBoot框架一起使用的话，会让开发微服务架构的云服务非常方便。
　　Spring Cloud是一个基于Spring Boot实现的云应用开发工具；Spring boot专注于快速、方便集成的单个个体，Spring Cloud是关注全局的服务治理框架；spring boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring boot来实现。

SpringCloud五大核心组件

服务注册发现-Netflix Eureka
配置中心 - spring cloud config
负载均衡-Netflix Ribbon
断路器 - Netflix Hystrix
路由(网关) - Netflix Zuul

Spring Boot的哲学就是约定大于配置。既然很多东西都是一样的，为什么还要去配置。

1. 通过starter和依赖管理解决依赖问题。
2. 通过自动配置，解决配置复杂问题。
3. 通过内嵌web容器，由应用启动tomcat，而不是tomcat启动应用，来解决部署运行问题。

Spring Cloud 与 SpringBoot的关系

SpringBoot专注于快速方便的开发单个个体微服务。
SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖的关系.
SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

1.5 Spring Cloud组件架构

在这里插入图片描述

通过上面SpringCloud架构图，我们看一下 Spring Cloud主要的组件,以及它的访间流程

  1、外部或者内部的非 Spring Cloud目都统一通过API网关(Zuul)来访可内部服务.
  2、网关接收到请求后,从注册中心( Eureka)获取可用服务
  3、由 Ribbon进行均负载后,分发到后端的具体实例
  4、微服务之间通过 Feign进行通信处理业务
  5、 Hystrix负责处理服务超时熔断
  6、 Turbine监控服务间的调用和焠断相关指标

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

扇出与雪崩响应：

多位微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他微服务，这就是所谓的”扇出”。如果扇处的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃—所谓的”雪崩效应”。

服务熔断：

熔断机制是应对雪崩效应的一种微服务链路保护机制！！！当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务调用的状况，当失败的调用到一定阈值就会启动熔断机制(默认是5秒内20次调用失败就会启动熔断机制)。但服务熔断来处理雪崩效应是非常可怕的，不可取的。第一如果有多个方法，对应的FallBack方法也会随之膨胀；第二异常处理与业务逻辑高耦合，完全不符合Spring AOP面向切面的思想。

服务降级：

整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。服务降级处理是在客户端(消费者)完成的与服务端没有关系。

个人感觉：

多个微服务之间进行调用，假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其他微服务，这就是所谓的“扇出”。如果扇出链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃—所谓的“雪崩效应”。

服务熔断和服务降级都是为了解决雪崩效应，只是二者实现方式不同：

服务熔断在服务提供端，进行服务降级，进而熔断该节点微服务的调用，快速返回“失败”的响应信息。当检测到该节点微服务调用响应正常恢复链路。当失败的次数达到一定阈值就会启动熔断机制服务降级，处理方式在客户端完成与服务端有没有关系，整体资源快不够了，忍痛将某些服务先关掉，待度过难关再开启回来。

服务监控：htstrix dashbord

1.6 微服务的优缺点分别是什么？说下你在项目开发中碰到的坑

优点：

每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求
开发简单、开发效率提高，一个服务可能就是专一的只干一件事。
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
微服务能使用不同的语言开发。
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo 。
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

缺点：

开发人员要处理分布式系统的复杂性
多服务运维难度，随着服务的增加，运维的压力也在增大
系统部署依赖
服务间通信成本
数据一致性
系统集成测试
性能监控……

1.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那样使整个微服务瘫痪。