SpringCloud 微服务基本概念

SpringCloud 微服务基本概念

微服务和分布式的区别：

微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势， 不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。
（引用别人的，意思就是微服务比分布式分的更细，更松耦合，更快捷灵敏，出错了影响的更少）。

首先一个问题，啥是微服务啊？ 这都是啥啥啥啊，俺都看不懂 -0.0||。
俺去查了一下资料：
1、每个服务可独立运行在自己的进程中。
2、一系列独立运行的微服务共同构建整个系统。
3、每个服务为独立的业务开发，一个微服务只关注某个特定的功能，例如订单管理、用户管理。
4、微服务之间通过轻量级的通信机制进行通信，例如Restful API进行调用。
5、可以使用不同的语言与数据存储技术开发。

哎呀！！！ 我有点晕 0o0||

插入一个概念：单体应用。

单体应用：

在项目完成以后会达成war包发布到系统中进行运行，这个war包中包含了整个应用程序的所有文件（jsp页面、java代码、配置文件等），这样的应用被称为单体应用。
可以简单的理解单体应用就是一个文件在系统中跑，所有的功能模块都在这个war包中。

这样有什么弊端呢？
1、太复杂了（耦合度太高）：定时炸弹。（你想想所有的模块都在一个包里能不耦合么）
2、技术债务：no broken don’t fix 不换不休。（只要程序没问题不换，一般不会去修理维护和更新，因为动一个地方，其它很多地方都有可能报错）
3、可靠性差：单个bug，导致整个系统瘫痪（耦合度太高了，一个地方有问题，可能整个应用程序都跑不了了）

为了解决这样的弊端，社会上现在有两款架构比较流行：

1、阿里系的：Dobbo、Zookeeper、SpringMVC or SpringBoot 等其他技术支持。

2、Spring Cloud系：Spring Cloud Netflix Eureka、SpringBoot等其他技术支持。

简单来理解就是，以前在一个war包中耦合度太高了（突然想起来，还记得那个梗么？哈哈）。
既然模块太耦合那咱就解耦合呗，把每个模块单独拎出来放到单独的服务器中，如果需要调用或者传参就用类似于Restful API来相互传值，这样就解决了耦合问题。

修改代码和bug，再也不用担心对整个应用的破坏了，So Easy！！！

引入主题：SpringCloud
（各位乡亲们请注意！！！ 我要上硬菜了！！！）

简单介绍一下SpringCloud。（这又是啥呀。）

什么是SpringCloud？？？

Spring Cloud是一个含概多个子项目的开发工具集,集合了众多的开源框架,他利用了Spring Boot开发的便利性实现 了很多功能,如服务注册,服务注册发现,负载均衡等.Spring Cloud在整合过程中主要是针对Netflix(耐非)开源组件的 封装
NetFlix 是美国的一个在线视频网站,微服务业的翘楚,他是公认的大规模生产级微服务的杰出实践者,NetFlix的开源 组件已经在他大规模分布式微服务环境中经过多年的生产实战验证,因此spring cloud中很多组件都是基于NetFlix组 件的封装。
（还记得权力的游戏么？龙妈太漂亮了，可惜自从消灭了冰冻人之后感觉有点烂尾就没有追了，这个电视剧就是NetFlix 开发的，当然还有其它的影视剧，又一个被影视剧耽搁的程序开发公司）

SpringCloud的出现真正简花了分布式架构的开发。
SpringCloud是对Netflix开源组件的封装，也就是SpringCloud封装了Netflix。
SpringCloud整合了开发分布式需要用到的一套技术，也就是SpringCloud封装了一整套开发技术。
用SpringBoot作为底层，通过SpringBoot的自动配置简化分布式的开发。
（感觉SpringCloud就像一个组装电脑。东拿过来一点东西，西拿过来一点东西，拼出来一整套电脑）。

SpringCloud组成由两部分：

1、注册中心(Eureka)：里边保存的是所有服务器的服务列表。也就是地址ip，作用就是统一管理（管理员）。

2、客户端：各种服务器（上边已经说了微服务就是讲不同模块解耦合，把不同模块放到不同的服务器）。

（说明下：其实客户端又分为客户端和服务端，但是不同模块之间调用这次我调用别人，我就是客户端，但是下次别人调用我，我就变成服务端了。所以只能说在某个调用或者请求中分客户端和服务端，整体他们都属于客户端）。

SpringCloud执行流程：

首先所有的客户端的地址信息都保存在注册中心里，一个模块请求或者调用另一个模块，需要先查看注册中心来获取是否有这个服务器，如果有就访问。
这里牵扯到一个负载均衡：就是如果访问的服务端有两个或者是一个集群，那么在发出访问的哭护短需要有一个负载均衡器Ribbon(这个很简单，只需要在发出请求的客户端导入依赖，然后在方法上边加入 @LoadBalanced即可。

还有一个点，上边说道每个服务器都要向注册中心发请求，在注册中心留下自己的信息，供别人调用，那么怎样确定某个服务器是正常运行的，那个已经宕机了呢？
这又出来了一个机制：心跳机制。服务器会定时（比如30s）向祖册中心发一个信息，祖册中心收到信心就说明服务器没有问题正常运行，超过90s没有发请求则判定该服务器有问题出异常了。注册中心就会剔除掉这个地址，这样其它服务器来访问时就不会有这个服务器的地址了。

这就是SpringCloud的基本操作流程。
（当然还有很多东西，比如有的是超过80%就会停掉祖册中心，宁可访问不到数据，也不能让数据出错）。

Eureka组件（注册中心）：

Eureka是Netflix开源的服务发现软件，本身基于rest的服务，它包含了client（客户、用户）和server（服务端与客户相对应的）两部分。这两种部分是服务和使用服务的关系（先解释到这其实里边水挺深的）。
Spring Cloud将他集成在子项目Spring Cloud Netfilx中，从而实现服务的注册和发现。

Eureka Server:

各个微服务启动时，会向Eureka Server注册自己的信息（如id，端口号，服务名称等）。Eureka会存储这些信息。

Eureka Client：

是一个java的客户端用来简化Eureka Server的交互。
微服务启动后会周期性的（默认30秒）向Eureka Server发送心跳，如果Eureka在规定的时间没有收到心跳， 则会注销该实例（默认90秒） Eureka Client会缓存服务注册表中的信息。这种方式有一定的优势首先可以降低Eureka Server的压力，其次 当所有的Eureka Server宕机服务调用方依然可以完成调用

服务消费者 ：

获取服务：

为了性能考虑，EurekaServer会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30秒更新一 次。

服务调用：

服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。因为有这些服 务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例，在Ribbon中会默认采用轮询的方式 进行调用，从而实现客户端的负载均衡

服务下线：

当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给EurekaServer,告诉服务注册中心:“我要 下线了”。服务端在接收到请求之后，将该服务状态置为下线(DOWN),并把该下线事件传播出去

失效服务剔除：

超过90秒 没有心跳的客户端会被踢出

Eureka的自我保护机制：

如果Eureka首页出现警告，则说明出现了问题。
默认情况下，如果Eureka Server在一定时间内没有接受到服务实例的心跳，Eureka将会注销该实例(默认90秒).但 是当网络分区发生故障时，微服务和Eureka Server 无法正常通信.以上行为可能变得特别危险了-因为微服务本身 是健康的，此时不能注销该服务实例. Eureka通过自我保护机制来解决这个问题，当Eureka Server在短时间丢失过多的服务实例（可能发生了网络分区 的故障，那么这个节点进入自我保护模式，一旦进入此模式，Eureka Server将会保护服务注册表中的信息，不再 删除服务注册表中的数据（也就是不再注销任何的服务实例），当网络故障恢复后，Eureka会自动退出自我保护模 式。
综上，自我保护模式是一种应对网络故障的安全保护措施，它的架构哲学是宁可同时保留所有的微服务，也不盲目 注销任何健康的微服务，使用自我保护模式可以让Eureka，更加健壮，稳定。

（翻译成人话就是：各个客户端超过90秒没有触发心跳机制，则会剔除掉这个客户端的实例，来保证其它模块访问的是正常运行的，但是像网络波动一样短时间内出现大量的客户端宕机，也就是注册中心短时间接收不到大象的客户端信息，那么注册中心不会剔除掉没有访问的客户端，反而会保护注册表中的信息，故障恢复后，Eureka会推出自我保护模式，这个有弊端，其它客户机来访问故障的库户籍会出现错误）。

Spring Cloud 可以通过关闭保护机制来实现数据通过。
#关闭自我保护机制 默认开启
eureka.server.enable-self-preservation=false

如果想及时剔除失效的eureka服务除了关闭自我保护机制外，可以调低eureka的心跳值
eureka-server服务端 配置文件中我们添加如下配置
#关闭保护机制，以确保注册中心将不可用的实例正确剔除 eureka.server.enable-self-preservation=false #（代表是5秒，单位是毫秒,清理失效服务的间隔 ） eureka.server.eviction-interval-timer-in-ms=5000

心跳检测检测与续约时间

测试时将值设置设置小些，保证服务关闭后注册中心能及时踢出服务

lease-renewal-interval-in-seconds 每间隔10s，向服务端发送一次心跳，证明自己依然”存活“

lease-expiration-duration-in-seconds 告诉服务端，如果我20s之内没有给你发心跳，就代表我“死”了， 将我踢出掉。

eureka.instance.lease-renewal-interval-in-seconds=10
eureka.instance.lease-expiration-duration-in-seconds=20

服务调用分为两种：

一种是 Ribbon负载均衡

一种是 Feign 声明式服务调

Ribbon负载均衡：

Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，要比nginx更简单易上手。

ribbon提供了很多的负载均衡算法

RoundRobinRule(轮询算法) RandomRule(随机算法) AvailabilityFilteringRule(过滤失效服务 再轮询)：会先过滤由于多次访问故障而处于断路器跳闸状态的服 务，还有并发的连接数量超过阈值的服务，然后对剩余的服务列表按照轮询策略进行访问 WeightedResponseTimeRule(权重)：根据平均响应的时间计算所有服务的权重，响应时间越快服务权重越大 被选中的概率越高，刚启动时如果统计信息不足，则使用RoundRobinRule策略，等统计信息足够会切换到 WeightedResponseTimeRule RetryRule(先轮询 调用失败 使用重试机制)：先按照RoundRobinRule的策略获取服务，如果获取失败则在制 定时间内进行重试，获取可用的服务 BestAviableRule(过滤失效服务 再请求并发量最小的服务)：会先过滤掉由于多次访问故障而处于断路器跳闸 状态的服务，然后选择一个并发量最小的服务
在SpringCloud中，当ribbon和Eureka配和使用时ribbon可以自动获取服务注册列表，并基于负载均衡算法，请求 其中的一个服务提供实例

服务提供者只需要启动多个服务实例并注册到一个注册中心或是多个相关联的服务注册中心。
服务消费者直接通过调用被@LoadBalanced注解修饰过的RestTemplate 来实现面向服务的接口调用。

Feign 声明式服务调：

用Ribbon可以实现客户端的调用为什么还有Feign？
之所以使用Feign是因为，它是用接口来传值的。相对上边的负载均衡更多变。

Hystrix实现微服务的容错处理 ：

如果服务提供者响应的速度特别慢，那么消费者对提供者的请求就会强制等待，直到提供者响应或者超时。在高负 载的情况下，如果不做任何处理，此类问题可能会导致服务消费者的资源耗尽甚至整个系统的崩溃。

如何容错：

想要避免这种雪崩效应的故障可以使用：
1、为网络请求设置超时。
2、使用断路器模式。

正常情况下断路器关闭可正常请求服务，当一定时间内请求达到了一定的阈(yu)值（错误率达到百分之50或者 100次/分钟），断路器就会打开此时不会再去请求依赖服务，断路器打开一段时间之后，会自动进入半开的 状态。此时断路器允许一个请求请求服务实例，如果该服务可以调用成功，则关闭断路器，否则继续保持打 开状态。

而通用方式是整合Hystrix（Ribbon整合Hystrix）。
用Hystrix来实现容错。
（有时间再补代码，先理解下流程知道该干嘛，下一步该怎么做，然后再实现代码）。