springCloud个人总结

• 微服务的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。

 

• 但通常而言,微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分成一组小的服务,每个服务运行在其独立的自己的进程中,服务之间互相协调、互相配合,为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通( 通常是基干HTTP的RESTful API) 。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境类生产环境等 。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建,可以有一个非常轻量级的集中式管理来协调这些服务,可以使用不同的语言来编写服,也可以使用不同的数据存储

 

• 微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合,每一个微服务提供单个业务功能的服务,一个服务做一件事,从技术角度看就是一种小而独立的处理过程,类似进程概念,能够自行单独启动或销毁,拥有自己独立的数据库。

 

微服务架构提出者马丁福勒论文阅读（一篇论文https://blog.csdn.net/shanshan_blog/article/details/72769960）

 

All In One单机系统

可以看作eclipse里面的一个大工程

所有模块功能都在一起，形成一个war包

 

-----分布式系统

优点：

各个模块/服务，各自独立出来，各自微小的进程，让专业的人来做专业的模块

独立部署，服务与服务之间通过restAPI方式进行访问

拆分 各自独立的进程 拥有自己的数据库

微服务只是业务逻辑代码，不会和HTML,CSS或其他页面组件混合

每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库

缺点：

开发人员要处理分布式系统的复杂性

多服务运维难度，随着服务的增加，运维的压力也在增大

系统部署依赖

服务间通信成本

数据一致性

系统集成测试

性能监控......

 

 

------SpringCloud微服务技术栈：多种技术的集合体（是一个完整的微服务架构）

我们在讨论一个分布式的微服务架构的话，它需要哪些维度？

服务治理

服务注册

服务调用

服务负载均衡

服务监控......

SpringCloud，基于SpringBoot提供了一套微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件

SpringCloud利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等，它们都可以用SpringBoot的开发风格做到一键启动和部署

SpringBoot并没有重复制造轮子，她只是将目前各家公司开发的比较成熟，经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂 的配置和实现原理，最终给开发者留出了一套简单易懂，易部署和易维护的分布式系统开发工具包

springCloud=分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶

 

 

------SpringBoot与SpringCloud的区别（面试题）

SpringBoot可以不依赖SpringCloud单独使用，但是SpringCloud必须依赖于SpringBoot才可以使用

SpringBoot专注于快速方便的开发当个个体微服务

SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务

 

------SpringCloud和Dubbo的区别

 

	Dobbo	SpringCloud
服务注册中心	Zookeeper	Spring Cloud Netflix Eureka
服务调用方式	RPC	REST API
服务网监控	Dubbo-monitor	Spring Boot Admin
断路器	不完善	Spring Cloud Netflix Hystrix
服务网关	无	Spring Cloud Netflix Zuul
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task

• 最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式

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

 

• 通过<dependency>

<groupId>org.projectlombok</groupId>

<artifactId>lombok</artifactId>

</dependency>

依赖取代传统的set/get toString 构造方法

 

 

 

------SpringCloud注解

• @Configuration: //boot -->spring applicationContext.xml --- @Configuration配置 ConfigBean = applicationContext.xml

 

• @LoadBalanced: //Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。

 

• @Autowired

private RestTemplate restTemplate;提供了多种便捷访问远程Http服务的方法，是一种简单便捷的访问restful服务模板类是Spring提供的用于访问Rest服务的客户端模板工具集

使用restTemplate访问restful接口非常的简单粗暴无脑。 (url, requestMap,ResponseBean.class)这三个参数分别代表 REST请求地址、请求参数、HTTP响应转换被转换成的对象类型。

 

 

 

-----Eureka是什么

​​

• Euerka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。服务注册与发现对于微服务架构来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。功能类似于dubbo的注册中心，比如Zookeeper

 

 

• Eureka包含两个组件：Eureka Server和Eureka Client

Eureka Server提供服务注册服务

各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到

 

EurekaClient是一个Java客户端，它简化了Eureka服务器交互，客户端还内置了一个负载均衡器，使用循环负载算法。应用程序启动后，如果Eureka服务器在多个心跳周期内没有连接，则会将心跳发送到Eureka服务器(默认周期为30秒)。从节点接收心跳，EurekaServer将从服务注册中心删除服务节点(默认90秒)

 

​​

 

 

 

 

• EurekaClient自我保护机制（“好死不如赖活着”）

某时刻某一个微服务不可用了，eureka不会立刻清理，依旧会对该微服务的信息进行保存

​​

 

默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务的心跳，EurekaServer将会注销该实例(默认90秒)。但是当网络分区故障发生时，微服务与EurekaServer之前无法正常通信，以上行为可能变得非常危险了-----因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过‘自我保护模式’来解决这个问题----当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入自我保护模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该EurekaServer节点会自动退出自我保护模式。

在自我保护中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该EurekaServer节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。

在SpringCloud中，可以使用eureka.server.enable-self-preservation = false 禁用自我保护模式

紧急!EUREKA可能错误地声称实例已经出现，而实际上并没有。续期比阈值小，因此这些实例不是为了安全而过期的

 

 

 

在分布式数据库中CAP原理CAP+BASE

​​

 

• 作为服务注册中心，Eureka比Zookeeper好在哪里

著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)，A(可用性)和P(分区容错性)。由于分区容错性P是在分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡

 

Zookeeper保证的是CP

在向注册中心查询服务列表时，我们可以容忍注册中心几分钟前返回注册信息，但不能接受服务直接宕机。换句话说，服务注册功能对可用性的要求高于一致性。但是在zk会出现这样的情况。当主节点因网络故障与其他节点失去联系时，剩余节点将再次进行leader选举。问题是，选举领袖太长，30-120s，整个zk集群在选举期间无法使用，导致选举期间注册服务崩溃。在云部署环境中，zk集群更有可能因为网络问题而丢失 主节点。虽然服务最终可以恢复，但是由于选举时间造成的长注册时间是不能容忍的

 

Eureka保证的是AP

Eureka非常清楚地看到了这一点，因此在设计时优先保证可用性。Eureka节点都是相等的，多个节点的丢失并不影响正常节点的工作，其余节点仍然提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，则会自动切换到其他节点。只要有一个Eureka存在，注册服务就保证可用(保证可用性)，只不过查到的信息可能不是最新(没有强一致性的保证)。除此之外, Eureka还有一个自我保护机制。如果超过85%的节点在15分钟内没有正常心跳，Eureka认为客户机和注册表之间存在网络故障。

有以下n种情况:

1. Eureka不再从注册列表中移除因为长时间没收到心跳而改过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会同步到其他节点(确保当前节点仍然可用)。
3. 当网络稳定时，当前实例的新注册信息将同步到其他节点

 

 

-----Ribbon负载均衡

• Spring Cloud Ribbon是一套基于Netflix Ribbon实现的客户端 负载均衡工具。
• 其主要功能是提供客户端软件负载均衡算法，连接Netflix的中间层服务。Ribbon客户机组件提供一组完整的配置项，比如连接超时、重试等等。简单地说，通过在配置文件中列出负载均衡器(LB)后面的所有机器，Ribbon会根据某些规则(简单轮询、随机连接等)自动帮助您连接到这些机器。使用Ribbon实现自定义负载平衡算法也很容易

 

LB，即负载均衡(Load Balance), 在微服务或分布式集群中经常用的一种应用。

负载均衡简单的说就是将用户的请求平摊的分配到多个服务器上，从而达到系统的HA。

常见额负载均衡有Nginx，LVS, 硬件F5等。

相应的在中间件，例如：dubbo和SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡可以自定义

 

• 集中式LB

是指消费者和服务提供者之间使用单独的LB设施(硬件，如F5，或软件，如nginx)，后者负责通过策略将访问请求转发给服务提供者;

• 进程内LB

将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器

Ribbon就属于进程内LB，它是一个类库，集成于消费方进程，消费方通过它来获取服务提供方的地址

Ribbon和Eureka整合后Consumer可以直接调用服务而不用再关心地址和端口号

 

 

• Ribbon在工作总分为两个步骤:

第一步是选择EurekaServer，它为同一区域负载较少的服务器提供优先级。

第二步根据用户指定的策略，在从server渠道的服务注册列表中选择一个地址

​​

Ribbon其实就是软负载均衡的客户端组件，他可以和其他所需求的客户端结合使用，和eureka结合只是其中一个实例

 

 

Ribbon的核心组件IRule自带7种算法

1、RoundRobinRule：轮询

2、RandomRule：随机

3、AvaliabilityFilteringRule：会先过滤掉由于多次访问故障而处于熔断器跳闸状态的服务，还有并发的连接数量超过阈值的服务，然后对剩余的服务列表按照轮询策略进行访问

4、WeightedResponseTimeRule：根据平均响应时间计算所有服务的权重，响应时间越快权重越大被选中的概率就越高，刚启动时统计信息不足时，则使用RoundRobinRule策略，等统计信息足够，则会切换到WeightedResponseTimeRule

5、RetryRule：先按照roundRobinRule的策略获取服务，如果获取失败则会在指定时间内进行重试，获取可用服务。

6、BestAvailableRule：会过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务。

7、ZoneAvoidanceRule：默认规则，复合判断server所在区域的性能和server的可用性选择器

 

Ribbon自定义的负载均衡：

在启动该微服务的是很好就能去加载我们的自定义Ribbon配置类，从而使配置生效：如下 @RibbonClient(name="MICROSERVICECLOUD-DEPT",configuration=MySelfRule.class)

 

 

-----Feign负载均衡

简介： Feign是一个声明式WebService客户端。使用Feign能让编写WebService客户端更加简单，他的使用方法时定义一个接口，然后在上面添加注解，同时也支持JAX-RS标准的注解。Feign也支持柯拔插式的编码器和解码器。Spring Cloud对Feign进行了封装，使其支持了Spring MVC标准注解和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。

Feign是一个声明式的 web服务客户端，使得编写web服务客户端变得非常容易

只需要创建一个接口，然后在上面添加注解即可

 

Feign的目标是让编写Java Http客户机变得更容易。

前面在使用Ribbon+RestTemplate时，利用RestTemplate对http请求的封装处理，形成了一套模板化的调用方法。然而，在实际开发中，由于对服务依赖项的调用可能不止一个位置，往往接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义。在Feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它(以前是Dao接口上面标注Mapper注解，现在是微服务上标注一个Feign注解即可)，即可完场读物提供放的接口绑定，简化了使用Spring Cloud Ribbon时，自动封装服务调客户端的开发量。