SpringCloud教程-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_44518089/article/details/109558043

微服务架构的四个问题：
1.很多服务，客户端符合访问
2.这么多服务？如何通信，Http，RPC
3.这么多服务？如何管理，
4.服务崩了，怎么办

解决方案：

SpringCloud 生态， 基于springboot
1.SpringCloud NetFix 一站式解决方案
	使用了api网关，zuul组件
	feign--httpclient-----http通信方式，同步阻塞
	服务注册与发现 Eureka
	熔断机制：Hystrix
2.apache dubbo zookeeper  半自动，需要整合别人的
	API：没有，找第三方组件。或者自己实现
	dubbo：基于java的rpc通信框架
	zookeeper：服务注册与发现
	没有熔断机制Hystrix
	 
	 方案不完善
	 
3.springcloud alibaba 最新一站式解决方案，更简化
	
新概念：服务网格，Server Mesh
	istio

综合问题核心：
	API、HTTP/RPC、注册与发现、熔断机制
解决：路由、通信、高可用、服务降级，防止服务雪崩

归其本质：网络不可靠。

SpringCloud面试题
·什么是微服务
微服务之间是如何独立通信的
SpringCloud和Dubbo的区别
SpringBoot和SpringCloud，谈谈你的理解
什么是服务熔断，服务降级
微服务的优缺点，你在项目开发中遇到的坑
你所知道的微服务技术栈有哪些，列举一二，
euraka和zookeeper都可以提供服务注册与发现的功能，说说区别

什么是微服务

提倡将单一的应用程序划分为一组小的服务，彻底解耦，每一个微服务都是提供一个单个的业务功能的服务，一个服务做一个事情，能够自行运行和销毁，拥有独立的数据库.

微服务优缺点：单一职责原则，每个服务足够小、代码容易理解，开发简单、效率高，松耦合，各自服务有各自的数据库，微服务只有逻辑业务程序，没有html、css代码，
缺点：开发人员要处理分布式系统的复杂性，多服务运维难度大大增加，系统部署依赖，
在这里插入图片描述

微服务优缺点

在这里插入图片描述

为什么选择SpringCloud作为微服务架构
1.选型依据
整体解决方案和成熟程度
社区热度、可维护性、学习曲线
2.现在互联网巨头用的微服务架构
阿里：dubbo+HFS
京东：JSF
新浪：Motan
当当网：DubboX

SpringCloud

是基于springboot提供了一套微服务的解决方法，包括服务注册与发现、配置中心、全链路监控、服务网关、负载均衡、熔断器等，除了基于NetFix组件做高效封装以外，还有一些中立的开源组件。
给开发人员提供了快速构建分布式系统的一些工具，包括：配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等

SpringBoot和SpringCloud的关系

SpringBoot专注于快速方便的开发单个个体微服务
SpringCloud注重于全局的微服务的协调和治理，将SpringBoot开发的单个微服务整理并管理，为各个微服务之间通过：配置管理、服务发现、断路器、路由、韦迪阿里、事件总线、全局锁、决策竞选、分布式会话等，SpringBoot可以脱离SpringCloud单独开发，但是反之不能，属于依赖关系

项目构架图（应用服务化拆分+消息中间件）

在这里插入图片描述

技术选型

在这里插入图片描述

Dubbo和Spring区别

最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用了基于HTTP的REST方式
品牌与装机区别
社区支持与更新区别

SpringCloud能做什么

Distributed/vjersioned configuration (分布式/版本控制配置)
Service registration and discovery (服务注册与发现)
Routing (路由)
Service-to-service calls (服务到服务的调用)
Load balancing (负载均衡配置)
Circuit Breakers (断路器)
Distributed messaging (分布式消息管理)

Eureka服务注册与发现

Netflix在设计Eureka的时候，遵循AP原则
Eureka是Netflix的核心模块之一，Eureka是基于REST服务的，用于定位服务的，以实现云端中间层服务和故障转移。服务注册与发现对于微服务异常重要，有了服务注册与发现，只需要使用服务的标识符，就可以访问服务，不需要修改服务的配置文件。类似于Dubbo的注册中心，比如Zookeeper
Eureka三大角色
EurekaServer：提供服务的注册与发现相等于zookeeper
ServiceProvider：将自己注册到注册到Eureka中，给消费者使用，
ServiceConsumer：从Eureka内获取注册服务列表，消费服务

Eureka自我保护机制

自我保护机制，即好死不如赖活着，总结：某个时刻微服务因为某种原因，不工作了。Eureka不会立刻清理，依旧会存储微服务的信息。当服务再次存活起来之后，就会取消EurekaServer自我保护机制，宁可保存错误的信息，也不让健康的微服务注销。所以自我保护机制是一种应对网络异常的安全措施，他的架构哲学就是宁可保存所有服务，也不注销，使用自我保护机制，可以让集群更加安全、健康和稳定。

CAP和Zookeeper区别

CAP原则：
RDBMS（mysql、SQL server、oracle）遵循ACID四大特性：原子性、一致性、隔离性、持久性
遵循CAP原则：NoSQL（redis、mongdb）
CAP是：强一致性、可用性和分区容错性，CAP符合三进二原则：要么CA、AP、CP
CAP理论核心：
	分布式系统不可能满足三者，只能满足其中的两项，根据CAP原理，将nosql数据库分成了满足CA原则满足CP原则以及AP原则：
		CA：单点集群，满足一致性，通常扩展性比较差
		CP：满足一致性，分区容错系统，通常性能不是特别高
		AP：满足可用性，分区容错系统，通常对一致性要求不是特别高
    根据CAP原理，P是必须要的，也就是只能在A和C中权衡：其中Zookeeper保证了CP，Eureka保证了AP。
    ![在这里插入图片描述](https://img-blog.csdnimg.cn/20201204222033414.png)

在这里插入图片描述
因此Eureka可以很好的应对网络故障导致部分节点无法使用的情况，而不像zookeeper那样会把整个注册中心瘫痪。

Ribbon

SpringCloud Ribbon是基于Netflix Ribbon是实现一套**客户端负载均衡的工具**
Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将NetFlix的中间层服务连接在一起，Ribbon的客户端组件提供一系列完整的配置项，如：连接超时，重试等，就是在配置文件中列出LoadBalancer（简称LB：负载均衡）后面所有的机器，Ribbon会自动的帮助你基于某种规则（比如轮询，随机连接等）去连接这些机器，也很容易的使用ribbon实现自定义的负载均衡算法。
	**LB：负载均衡（LoadBalance），在微服务分布式集群中经常使用的一种应用。**
		负载均衡就是将用户的请求平摊到多个服务上，从而达到系统得分HA（高可用）
		常见的负载均衡软件有Nginx，Lvs等
		dubbo、springcloud中提供了负载均衡，SpringCloud中的负载均衡算法可以自定义
		负载均衡简单分类：
			集中式LB：
				在服务的消费方法和 提供方之间使用独立的LB设施，比如Nginx，反向代理服务器，由该设施负责把访问请求通过某种策略发到服务器的提供方
			进程式LB：
				将LB逻辑集成到消费方，消费方从服务注册中心湖区哦有哪些地址可用，然后自己再从浙西地址中选出一个适合的服务器，Ribbon就属于进程内LB，是一个类库，集成于消费方进程，消费方通过他来获取到服务器提供方的地址。

熔断器 Hystrix

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统中不可避免的会调用失败，超时、异常等等，Hystrix可以保证分布式系统在出现依赖问题的情况下，不会导致系统整体服务失败，避免联级故障，提高系统的弹性。
断路器是指一种开关装置，当单个服务出现故障之后，通过断路器的故障监控，向调用方返回一个服务预期的可处理的备选响应（FallBack）而不是长时间的等待或者抛出方法的处理异常，保证了调用方的线程不会长时间的等待，不必要的占用，避免故障在分布式系统中蔓延，甚至雪崩。
作用：服务限流、服务熔断、服务降级，监控
服务熔断：熔断机制是对雪崩效应的一个有效的保护机制，
当扇出链路的某一个服务不可达或者响应时间太长的时候，会进行服务的降级，对应该节点的微服务的调，快速的返回失败的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路，在springcloud框架中熔断机制通过Hystrix实现，Hystrix会监控微服务间条用的状况，当失败的调用到一定的阈值，缺省5秒内20次调用失败就会启动熔断机制，熔断机制的注解是@HystrixCommand

服务熔断：服务端，某个服务超时或者异常，保险丝
服务降级：客户端，从整体网站请求负载考虑，当某个服务熔断熔断或者关闭之后，服务将不再被调用，此时在客户端，我们可以准备一个FallbackFactory，返回一个默认的值（缺省值），整体服务水平下降了，但是也好比挂掉的好。

Zuul网关

Zuul包含了对请求的路由和过滤两个主要的功能：
其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础，而过滤器功能则负责对清风求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。

配置zuul
application.yml文件：

server:

port: 9527
spring:
application:
name: springcloud-zuul

eureka:
client:
service-url:
defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/
instance:
prefer-ip-address: true
instance-id: zuul9527.com

info:
app.name: ty-study-springcloud
company.name: ty # http://www.ty.springcloud.com:9527/springcloud-provider-dept

#zuul路由网关自己的配置
zuul:
routes:
mydept.serviceId: springcloud-provider-dept
mydept.path: /mydept/**
ignored-services: "" # 隐藏所有，微服务 # springcloud-provider-dept # 这个地址不能再使用了
prefix: /ty # 设置公共的前缀

启动类
@SpringBootApplication
@EnableZuulProxy //开启路由代理 zuul
public class ZuulApplication9527 {
public static void main(String[] args) {
SpringApplication.run(ZuulApplication9527.class,args);
}
}