微服务和分布式相关基础知识（Spring Could，fastDFS，RocletMQ，熔断机制，Docker容器）_微服务发现和熔断

Spring Clould简介

Spring Clould是微服务架构的集大成者，将一系列优秀的组件进行了整合，基于Spring boot构建

 

Spring clould 五大常用组件

1、服务发现——Netflix Eureka

实现服务治理（服务注册与发现）；

由Eureka服务端和客户端组成；

Eureka服务端用作服务注册中心，支持集群部署；

Eureka客户端是一个java客户端，用来处理服务注册与发现；

在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地；客户端和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

2、客服端负载均衡——Netflix Ribbon

主要提供客户侧的软件负载均衡算法；

Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netfilx Ribbon实现，通过spring clould的封装，可以让我们轻松的面向服务的REST模板请求自动转换成客户端负载均衡的服务调用，关键点是将外界的rest调用，根据负载均衡策略转换为微服务调用

1. 断路器——Netflix Hystrix

用于断路器，保护系统，控制故障范围

为了保证其高可用，单个服务通常会集群部署，由于网络原因或者自身原因，很多时候服务不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时如果有大量的请求涌入，Servlet容器的线程资源就会被消耗完毕，导致服务瘫痪。服务和服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，也就是服务故障的“雪崩”效应。

1. 服务网关——Netflix Zuul

用作Api网关，路由，负载均衡等多种作用

类似nginx，反向代理的功能，不过Netfilx自己增加了一些配合其他组件的特性。在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个api网关根据请求的URL，路由到相应的服务，当添加api网关后，在第三方调用和服务之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。

1. 分布式配置——Spring Cloud Config

用作配置管理

  提供服务器端和客户端，服务器存储后端的默认实现使用git，因此它轻松的支持标签版本的配置环境，以后可以访问用于管理内容的各种工具，并且是静态的，需要配合Spring Clould Bus实现动态的配置更新

 

FastDFS简介

开源的轻量级分布式文件系统，对文件进行管理，包括：文件存储、同步、访问（上传、下载）等，解决了大容量存储和负载均衡的问题；

适合以文件为载体的在线服务，如：相册、视频网站等

FastDFS服务端有两个角色：跟踪器（tracker）和存储节点（storage）

跟踪器主要做调度工作，在访问上起负载均衡的作用；

存储节点存储文件，完成文件管理的所有功能，所有文件的meta data相关属性都是以键值对的形式表示，文件属性列表可以包含多个键值对；

跟踪器和存储节点可以由一台或者多台服务器构成，跟踪器和存储节点的服务器可以随时增加或者减少，而不会影响线上服务；

为了支持大容量，存储节点服务器采用了分卷或分组的组织方式，存储系统由一个或多个卷组成，卷与卷之间的文件是独立的，所有卷的文件容量累加就是整个存储系统中的文件容量，同一个卷下的服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用

FastDFS中文件标识分为两部分：卷名和文件名，二者缺一不可

FastDFS上传交互过程

1、用户端(client)访问跟踪器(tracker)上传到存储节点(storage),不需要附加参数；

2、跟踪器(tracker)返回一台可用的存储节点(storage)；

3、用户直接和存储节点(storage)通讯完成文件上传。

FastDFS下载交互过程

1、用户询问跟踪器下载文件的存储节点，参数为文件标识(卷名和文件名)

2、跟踪器返回一个存储节点；

3、用户直接和存储节点通讯完成文件下载

需要注意的是，在fastDFS中用户端(client)也应该是一台服务器，用户端为fasfGFS的调用方，它对跟踪器和存储节点的调用均为服务器间。

消息队列MQ的简介

消息队列作为高并发系统的核心组件之一，能够帮助业务系统提升开发效率和系统稳定性；

1、MQ的优势：

削峰填谷（主要解决瞬时写压力大于应用服务能力导致消息丢失，系统崩溃等问题）

系统解耦（解决不同重要程度、不同能力级别系统之间依赖导致一死全死）

提升性能（当存在一对多调用时，可以发一条信息给消息系统，让消息系统通知相关系统）

蓄流压测（线上有些链路不好压测、可以通过堆积一定量消息在放开来压测）；

2、主流的MQ主要是Rocketmq、kafka、Rabbitmq，其中Rockermq相比另两种mq的优势特性有：

支持事务性消息（消息发送和DB操作保持两方的最终一致性，Rabbitmq和kafka则不支持）

支持结合Rockermq的多个系统之间数据最终一致性（多方事务、二方事务是前提）

支持18个级别的延迟消息（rabbitmq和kafka不支持）

支持指定次数和间隔时间的失败消息重发（kafka不支持，rabbitmq需要手动确定）

支持consumer端tag过滤，减少不必要的网络传输（rabbitmq和kafka不支持）

支持重复消费（rabbitmq不支持，kafka支持）

RocketMQ的工作原理

1. 集群部署名称服务Name Server，
2. 中间人Broker和Name Server的所有节点建立长连接；
3. 生产者Producer随机选择一个Name Server的节点建立长连接获取路由信息，并和Broker中的Master建立长连接，获取Topic服务，向Broker发送消息；
4. 消费者Consumer也随机选择一个Name Server的节点建立长连接获取路由信息，并和Broker的Master、Slave建立长连接获取Topic服务，订阅消息，消费消息；

无论是谁和谁建立长连接都需要定时接发心跳，确保应用正常存活，保持消息系统的稳定性

RocketMQ部署结构：

1. Name Server（名称服务，是一个无状态无节点，可集群部署，节点之间无任何信息同步）
2. Broker（中间人，RocketMQ的核心，大部分“重量级”的工作都是由Broker完成，集群模式下Broker分为Master和Slave，一个Master可以对应多个Slave，但是一个Slave只对应一个Master，Master与Slave的对应关系通过指定相同的Broker Name，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave；每个Broker和Name Server集群中的所有节点建立长连接，定时[每隔30s]注册Topic信息到所有的Name Server，Name Server定期[每隔10s]扫描所有存活broker的连接，如果Name Server超过两分钟没有收到心跳，则Name Server断开与Broker的连接）
3. Producer（消息生产者，完全无状态，可集群部署，和Name Server中的一个节点[随机选择]建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳）
4. Consumer（消息消费者，和Name Server中的一个节点[随机选择]建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳，Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定）

发送消息方式三种：

1. 同步发送（消息发送方发出数据后，会在接收方发回响应之后才发下一个数据包的通讯方式）
2. 异步发送（发送方在数据发送后不等接收方响应，接着可以发送下一个数据包的通讯方式）
3. 单向发送（发送方只负责发送消息，不需要broker应答）

两种消费模式：

1、集群消费（多个消费者consumer平均消费主题topic下所有mq的消息，即某个消息在消息队列message queue中被一个消费者consumer消费后，其他消费者就不会消费到它）

2、广播消费（所有的消费者consumer可以消费到发到这个主题topic下的所有消息）

Redis中list的操作命令

Redis中的list在内存中是按照一个名称对应一个List来存储

1. lpush、rpush(name,values)——在name对应的list中添加元素，每个新元素都添加到列表的最左边(lpush)或者最右边(rpush)
2. Lpushx、rpushx(name,values)——在name对应的list中添加元素，只有在name存在时，值添加到列表的最左边(lpushx)或者最右边(rpushx)
3. llen(name)——name对应的list元素的个数
4. linsert(name,where,refvalue,value)——在name对应的列表的某一个值前或后插入一个新值（参数：name—redis的name；where—BEFORE或AFTER[小写也可以]；refvalue—标杆值，在它前后插入数据，如果存在多个标杆值，则找到的第一个为准；value—要插入的数据）
5. \r.lset(name,index,value)——对name对应的列表中某一个索引位置重新赋值
6. r.lrem(name,value,num)——在name对应的列表中删除指定的值（参数：value—要删除的值；num—num=0,删除列表中所有指定的值；num=2，从前到后，删除2个；num=-2，从后到前，删除2个）
7. lpop、rpop(name)——在name对应的列表的左侧获取第一个元素并在列表中移除，返回值则是第一个元素（lpop左侧，rpop右侧）
8. lindex(name,index)——在name对应的列表中根据索引获取列表元素
9. Lrange(name,start,end)——在name对应的列表分片获取数据（参数：start—索引起始位置；end—索引结束的位置）
10. Ltrim(name,staer,end)——在name对应的列表中移除没有在start—end索引之间的值（参数：end—大于列表长度，则代表不移除任何值）

Spring Clould熔断用的组件，熔断在服务中配置还是网关配置，使用熔断的原因

Spring Clould中使用的是Hystrix熔断机制

在网关中配置，相当于增加了一个过滤器，把一些程序出现的错误，及时处理，以免造成雪崩效应，影响其他程序的正常运行

熔断机制就相当于在我们的应用程序中增加了一个类似生活中见到的电路保险丝，出现问题之后，保险丝自动烧断，以保护我们电器，所以在程序中使用熔断机制就是为了保护我们的程序某一个地方出现错误，或者其他原因导致的错误发生时，而不至于由一个点影响到整个程序的正常运行

雪崩效应：一种因服务提供者的不可用导致服务调用者的不可用，并将不可用逐渐放大的过程

雪崩效应的形成过程：

1. 服务提供者的不可用
   • • 硬件故障：硬件损坏造成的服务器宕机，网络硬件故障造成的服务提供者的不可访问
     • 程序BUG
     • 缓存击穿：一般发生在缓存应用重启，所有缓存被清空时，以及短时间内大量缓存失败时，大量的缓存不命中，使请求直击后端，造成服务提供者超负荷运行，引起服务不可用
     • 用户大量请求：在秒杀和大促销开始前，如果准备不充分，用户发起大量请求也会导致服务提供者的不可用
2. 重试加大流量
   • • 用户重试：在服务提供者不可用后，用户由于忍受不了界面上长时间等待，而不断刷新页面甚至提交表单
     • 代码逻辑重试：服务调用端会存在大量服务异常后的重试逻辑
3. 服务调用者的不可用
   • • 同步等待造成的资源耗尽：当服务调用者使用同步调用时，会产生大量的等待线程占用系统资源，一旦线程资源被耗尽，服务调用者提供的服务也将处于不可用状态，于是服务雪崩效应产生了

熔断机制Hystrix的概念

1、服务熔断：

一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断也称为过载保护；很多时候刚开始可能只是局部或者小规模出现了故障，然而由于种种原因，故障影响的范围越来越大，最终导致了全局性的后果。

1. 使用场景：

防止应用程序直接调用那些很可能会调用失败的远程服务或共享资源

1. 服务降级

当服务器剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心业务的正常运行

熔断机制Hystrix的工作原理

1. 隔离

Hystrix隔离方式采用线程/信号的方式，通过隔离限制依赖的并发量和阻塞扩散

1. 线程隔离
   1. 熔断机制在用户请求和服务之间加入了线程池
   2. 为每一个依赖调用分配一个小的线程池，如果线程池已满，调用将被立即拒绝，默认不采用排队，加速失败判定时间，线程数是可以设置的

原理：用户的请求将不再直接访问服务，而是通过线程池的空闲线程访问服务，如果线程池满了，则采取降级处理，用户的请求不会被阻塞，至少看到一个执行结果，而不是无休止的等待或者看到系统崩溃

隔离前：如有三项服务，共一百个线程，用户请求访问时，在某时间段内，可能全是访问某一项服务的，由于请求量过大，程序运行超负荷；

隔离后：三项服务，还是一百个线程，但是被按比例分配到三项服务上，当一项服务请求访问过大时，也只是该项服务程序超负荷，在对其控制，不会影响到其他服务的正常运行

1. 信号隔离
   1. 信号隔离也可以用于限制并发访问，防止阻塞扩散，与线程隔离最大的不同在于执行依赖代码的线程依然是线程（该线程需要通过信号申请，如果客户端是可信的，可以使用信号隔离替换线程隔离，降低开销，信号量的大小可以动态调整，而线程池大小不可以）

1. 熔断

如果某个目标服务调用慢或者有大量超时，此时，熔断服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源，如果目标服务情况好转则恢复调用

熔断器Circuit Breaker

熔断器位于线程池之前的组件，用户请求某一个服务时，Hystrix熔断机制会先经过熔断器，此时如果熔断器是打开状态，则说明已经熔断，这时将进行降级处理，不会继续将请求发到线程池，熔断器Circuit Breaker相当于在线程池之前的一道屏障

熔断器的状态机

1. Closed：熔断器关闭状态，调用失败次数积累，到了阈值（或者一定的比例）则启动熔断机制
2. Open：熔断器开启状态，此时对下游的调用都是内部直接返回错误，不走网络，但设计了一个时钟选项，默认的时钟达到一定时间（一般设置为平均故障处理时间），进入半熔断状态
3. Half-Open：半熔断状态，允许定量的服务请求，如果调用都成功（或一定比例），则认为恢复了，关闭熔断器，否则认为还没好，又回到熔断器打开的状态

Docker常用命令

Docker容器信息

docker version

查看容器版本

docker info

查看容器信息

docker -help

查看容器帮助

进入Docker容器内部查看日志

docker logs redis

查看redis容器日志，默认参数

docker logs -f -t --tail=20 redis

查看redis容器日志，参数：-f—跟踪日志输出，-t—显示时间戳，--tail—仅列出最新N条容器日志

docker logs --since=”2020-4-17” --tail=10 redis

查看redis容器日志，参数：--since—日期时间

启动容器命令

docker run -i -t --name mycentos

新建并启动容器，参数：-i—以交互模式运行容器，-t—为容器重新分配一个伪输入终端，--name—为容器指定一个名称

docker run -d mycentos

后台启动容器，参数：-d—以守护方式启动容器

docker start redis

启动一个或多个已经被停止的容器

docker restart redis

重启容器

拉取镜像

docker pull [options] name [:tag]

从仓库拉取/下载镜像，options是参数，tag是版本

docker pull redis

下载Redis官方最新镜像，相当于：docker pull redis:latest

docker pull -a redis

下载仓库所有Redis镜像，参数 -a—所有

docker search mysql

搜索仓库所有mysql镜像

使用Docker的原因

Docker是世界领先的软件容器平台，目标是实现轻量级的操作系统虚拟化解决方案，Docker的基础是Linux容器（LXC）等技术

开发人员利用Docker可以消除协作编码时”在我机器上可正常工作”的问题；

运维人员利用Docker可以在隔离容器中并行运行和管理应用，获得更好的计算密度；

企业利用Docker可以构建敏捷的软件交付管道，以更快的速度，更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能

Docker可以将一整套环境打包封装成镜像，无需重复配置环境，解决环境带来的种种问题；Docker容器间是隔离的，相互独立的，相互不影响；Docker具有更高效的利用系统资源、虚拟化；更快速的启动时间、项目交付和部署；一致的运行环境；持续交付和部署；更轻松的迁移、维护和扩展；更简单的管理