⼩⽩新⼿SpringCloud开发简单总结（⼀）-SpringCloud概念⽬录
前⾔
拓展下⾃⼰的知识库。
⼀⼏个常见概念
1.集
为了更⾼的效率，通过多台计算机完成同⼀个⼯作，这些计算机运⾏的内容完全⼀致。本来是⽤⼀台计算机来处理Client的访问，转换成多台计算机同时在处理这些访问。如果其中⼀台出现问题，其他的仍然可以起作⽤。
该集系统中的每台计算机成为⼀个节点。通过局域⽹或者其他可能的⽅式连接。
总结为：同⼀个业务部署到多台服务器上，不同的服务器运⾏的是相同的代码。
是⼀种物理形态。通过负载均衡设备共同对Client提供服务。
2.分布式
将⼀个⽹站系统分为不同独⽴的模块，每个模块完成独⽴的功能，按模块访问量⾼低配置不同性能的服务器，合理利⽤资源。在使⽤的时候将这些模块组合成⼀个系统。
总结为：⼀个业务拆成多个独⽴的⼦业务，部署在不同的服务器，不同的服务器运⾏不同的代码。
是⼀种⼯作⽅式。解决⾼并发问题。
3.SOA
⼀个业务拆分成多个组件，每个组件相互独⽴，通过组合实现业务流程。
更注重的是前端、后端、数据库等的划分。
4.微服务
更注重的根据业务拆分，每个⼦业务完成⼀定的功能。
⼆ SpringCloud
在分布式和微服务的概念中，会把⼀个业务拆分成多个⼦业务，通过将这些⼦业务组合来完成功能。⽽拆分之后就会各种各样的问题，所以SpringCloud就是为了解决这些问题。
微服务框架。对优秀组件进⾏整合。基于Springboot进⾏构建各种服务（SpringCloud主要侧重的服务治理，⾥⾯的各种服务都是有SpringBoot开发）。
构建服务的过程基础功能：
（1）服务发现注册  Eureka
（2）客户端负载均衡 Ribbon
（3）服务器熔断器 Hystrix
（4）声明式服务调⽤ Feign
（5）API⽹关服务 Zuul
（6）分布式配置中⼼ Config
另外还有⼀些⾼级功能如消息总线 Bus、消息驱动的微服务 Stream、分布式服务跟踪 Sleuth。
1. SpringCloud之 Eureka
服务的发现和注册，是⼀个服务治理框架。⽤于解决每个服务之间的远程调⽤问题。
传统的服务之间调⽤都是通过IP地址来调⽤，⽽Eureka是通过服务名来实现调⽤。简单的理解梳理下Eureka的思想：
将每个服务都注册到服务注册中⼼；
每个服务可以拿到这个服务注册中⼼的注册清单，在这个服务清单中会有服务名和IP地址之间的关系；
每个服务可以通过服务名来调⽤，最后通过服务名到对应的IP地址（IP地址会变，但是服务名不会变）。
（1）两个组件
Eureka主要有两个组件组成：Eureka Server和Eureka Client。
Eureka Server⼜称为服务注册中⼼。专门⽤于注册其他服务，维护服务实例，不需要检索服务。本⾝也是⼀个服务。⼀般情况下在application.properties对该服务配置如下：
#false：不会向注册中⼼注册⾃⼰
register-with-eureka=false
#false：表⽰该服务为注册中⼼
fetch-registry=false
Eureka Client⼜分为服务消费者和服务提供者。⼀个服务即可以是服务消费者也可以是服务提供者。注意下⾯的⼏个问题点：
1）如果是单纯的消费者，可以不对外提供服务，⽆需注册到Eureka注册中⼼（即register-with-eureka设置为false），但是可以获取到服务注册中⼼的注册清单；
2）服务提供者必须注册到注册中⼼才可以对外提供功能。
（2）治理机制
该治理机制主要服务提供者、服务消费者以及服务注册中⼼三者相互配合，实现服务治理。
Eureka Client端：
服务提供者的主要作⽤就是对外提供服务。主要功能如下：
1）服务注册Register：服务提供者启动的时候，就会通过发送REST请求将⾃⼰的⼀些元数据（如IP
地址、端⼝号、运⾏状况指⽰符URL等信息）注册到服务注册中⼼Eureka Server；
2）服务续约Renew：在完成注册服务之后，服务提供者每隔⼀定时间（默认为30s）发送⼼跳来续约，告诉服务注册中⼼Eureka Server该服务提供者还存活；当Eureka Server在规定时间（默认90s）没有收到续约信息，就会将该服务实例从注册表中剔除；
3）服务下线Cancel：当该服务实例正常关闭时，会触发⼀个服务下线的REST请求发送给服务注册中⼼Eureka Server，告知下线。
服务注册中⼼Eureka Server就会从注册表中将该实例删除。该下线请求需要服务提供者主动调⽤（代码为
服务消费者的主要作⽤就是获取注册列表信息，到对应的服务，使⽤服务。主要需要功能如下：
1）获取服务Fetch：服务消费者启动的时候，会发送REST请求给到服务注册中⼼Eureka Server，获取服务注册清单，缓存在本地，该注册清单信息定期（默认30s）会更新。
2）调⽤服务：服务消费者获取到服务清单，通过服务名获取到该服务的实例和实例的元数据（⾥⾯含有IP地址），从⽽调⽤到服务提供者
Eureka Server端
服务注册中⼼的主要作⽤：服务提供者去注册服务，⽽服务消费者去寻服务提供者。
1）服务剔除Eviction：如果服务注册清单中的服务实例超过规定时间（默认为90s）没有接收到续约，则服务注册中⼼Eureka Server就会将该服务从服务注册列表中剔除；
2）⾃我保护：通常由于⽹络不稳在15分钟内⼼跳失败的⽐例超过85%，那么Eureka Server就会将当前的实例注册信息保护起来，让
这些实例不会过期。
感觉这个过程和Android的系统服务的概念差不多：
1）system进程的各种系统服务如AMS、WMS等，主要是提供服务，对⽐服务提供者；
2）Client进程通过远程调⽤来访问这些系统服务，对⽐服务消费者；
3）ServiceManager⽤来注册和查询服务，对⽐服务注册中⼼
后⾯在去学习在代码中怎么去设置。
（3）⼩结
2.SpringCloud之RestTemplate分布式和微服务的关系
Eureka为服务治理框架，通过服务名就可以获取到对应的服务实例以及服务的IP地址，那么这些服务实例之间的远程调⽤不需要⼿动创建HttpClient，⽽是之间通过Spring封装的RestTemplate。在Eureka中的续约、注册以及查都是使⽤的RestTemplate。
RestTemplate就是⼀个Http请求⼯具。提供了常见的REST请求⽅案的模版。简单的看⼀个⽅法：
（1）GET请求
GET请求的⼀些⽅法如下：
第⼀个参数：REST请求的url地址；
第⼆个参数：请求参数；
第三个参数：Http响应转换成的对象类型
（2）POST请求
POST请求的⼀些⽅法如下：
⽅法参数含义同GET请求。
其他⽅法等⽤的时候在具体去看，现在先简单的了解下。
3.SpringCloud之Ribbon
为了能够使整个系统的⾼可⽤，前⾯在中的⼏个概念介绍中，可以知道我们需要将服务提供者集，这样就可以在不同的服务器中运⾏相同的代码来解决分担同⼀时间对该功能的访问。
如果没有负载均衡，就可能会出现仅有⼀台服务器来处理这些访问，⽽其他的服务器并没有起作⽤，造成了资源没有合理利⽤。所谓的负载均衡就是让不同的服务器能够合理分摊⽤户的请求，⽽如何解决这个服务提供者集的负载均衡，那就是Ribbon。
（1）Ribbon概念
Ribbon就是为了解决Eureka的Client的负载均衡的问题。Ribbon⼯作原理：Client的服务消费者从Eureka Server服务注册中⼼获取服务注册清单，通过负载均衡算法在多个服务提供者之间选⼀个在进⾏发送请求。
（2）Ribbon的负载均衡算法
Ribbon默认的策略为轮询，即RoundBobinRule。该策略就是经过⼀轮没有到可⽤的provider，其最多轮询10轮。若最终没有到，则返回null。
当然也可以设置其他的负载均衡算法，在配置⽂件中修改NFLoadBalancerRuleClassName的值即可，其他算法如下：
1）RadomRule：随机策略。从所有可⽤的provider中随机选择⼀个；
2）RetryRule：重试策略。先按照RoundBobinRule策略获取provider，若获取失败，则指定的时间内重试。默认为500ms。
3）BestAvailableRule：最低并发策略。逐个考察provider，若其断路器打开，则忽略。在选择其中并发连接最低的provider。
4）AvailabilityFilteringRule：可⽤过滤策略。过滤⼀直连接失败并标记为circuit tripped的provider以及过滤那些⾼并发连接的provider；
5）ResponseTimeWeightedRule：响应时间加权策略。根据响应时间分配加权权重。响应时间越长，权重越低，被选择到的概率越低；
6）ZoneAvoidanceRule：区域权衡策略。综合判断provider所在区域的性能和可⽤性轮询选择。
也⽀持⾃定义负载均衡算法，需要实现IRule接⼝。
（3）与Nginx区别
Nginx是集中式的负载均衡器。就是将所有的请求集中起来在进⾏负载均衡。也就是所有的请求先进⼊负载均衡器，然后在分配给对应的服务；⽽Ribbon是先在负载均衡在发送请求给到对应的服务提供者。区别如图：
从图中可以看出：Nginx会接收所有的请求，通过负载均衡调度，到可⽤的服务器；⽽Ribbon会在发出请求之前就知道该请求具体发向哪台服务器，然后直接将该请求发向对应的服务器。
4.SpringCloud之Feign
通过Eureka可以让服务消费者根据服务名到对应的服务器实现远程调⽤，在Eureka中通过RestTemplate封装Http实现远程调⽤服务。通过Ribbon可以实现Client的负载均衡。 ⽽Feign进⾏了声明式、模板化，将上⾯的两个流程进⾏简化：
1）只需要创建⼀个接⼝并注解的⽅式来配置它，就可以完成服务提供者的接⼝绑定；
2）集成Ribbon，利⽤Ribbon维护服务列表，通过轮询⽅式实现Client的负载均衡，不需要额外声明Ribbon
该Feign还整合了后⾯要介绍的Hystrix。
5.SpringCloud之Hystrix
前⾯通过Ribbon解决集中的负载均衡问题，但是在⽹络原因或者系统本⾝问题，导致服务出现异常，不能及时返回信息。如果这个时候有⼤量的访问进⼊，会使服务器处于负载保护状态，造成系统瘫痪。服务与服务之间⼜有相互依赖关系，从⽽引起整个微服务系统的雪崩效应。那么就出现了“救星”Hystrix。
Hystrix称为断路器。能够保护系统，控制故障范围。具有下⾯的特点：
1）请求熔断：⼀旦出现服务不可⽤，断路器会直接断开请求链，避免发送⼤量⽆效请求影响系统的吞吐量，具有⾃我检测并恢复的能⼒；
2）依赖隔离：通过线程池实现资源隔离。为每个依赖服务创建⼀个独⽴的线程池，如果某个依赖服务出现延迟过⾼，只会对该依赖服务的调⽤产⽣影响，不会影响到其他依赖服务；
3）服务降级：给定某个操作实现⼀个fallback⽅法，当请求服务出现异常的时候，可以通过该fallback返回默认值或者缓存，并且通知后⾯的请求该服务不可⽤。
4）请求缓存：会缓存之前的请求，再来相同的请求的时候，⽽是把缓存内容返回给当前请求。
5）请求合并：多次相同的请求可以合并成⼀个请求，最后同时处理⼀次数据库
Hystrix还有⼏个关键参数：滑动窗⼝⼤⼩（20）、断路器开关间隔（5s）、错误率（50%）：
1）每当20个请求中，有50%失败，断路器会⾃动打开，若在调⽤该服务，会直接返回失败；
2）5s之后，会重新检测该触发条件，判断断路器是否关闭还是继续打开。
6.SpringCloud之Zuul
在微服务框架中，后端服务通常不会直接暴露给web前端、移动端等，⽽是通过⼀个API⽹关根据请求的url，进⾏签名校验、登录校验等冗余问题，然后路由到对应的服务。⽽Zuul具有API⽹关、路由负载均衡等作⽤。
通过与Eureka进⾏整合，将⾃⾝注册为Eureka下的应⽤，同时从Eureka中获取到所有服务的实例。外
层调⽤必须通过API⽹关，⽽服务实例的维护还是有Eureka完成。实现对微服务接⼝进⾏前置过滤，实现拦截和检验。
Zuul本⾝拥有线程隔离和断路器的⾃我保护功能，以及对Client负载均衡功能。⽀持Hystrix和Ribbon。
（1）与Feign区别
前⾯的Feign也有Hystrix实现断路器和Ribbon实现Client的负载均衡，和Zuul有什么区别呢？
Zuul是对外暴露的唯⼀接⼝，相当于路由的是controller的请求；⽽Ribbon和Feign路由的是选择哪个服务提供者去请求；
Zuul是做外层的请求的负载均衡；⽽Ribbon和Feign是对微服务系统的服务提供者的负载均衡。
所以Zuul更偏向于web应⽤层调⽤⽅的路由以及负载均衡；⽽Ribbon和Feign是针对于业务层的微服务系统。
7.SpringCloud之Config
随着业务增多，就会有存在很多微服务，那么每个服务都会有⼀个配置⽂件。如果每个服务分别维护⼀个配置⽂件，会造成如果⼀个修改的话，要对所有的服务的配置⽂件都进⾏修改。那么就有了Config，通过把配置⽂件放在统⼀的位置进⾏管理。
Config主要包括两⽅⾯的配置：Server主要配置⽂件的存储、以接⼝的形式将配置⽂件的内容提供出去；⽽Client通过接⼝获取数据，初始化应⽤。
三总结

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。