小时候出去春游，大家都会分工合作，有人带水，有人带主食，有人带零食，有人带工具等等。

小朋友多了管理就是个麻烦事了，有时候一个老师还管理不过来。

微服务也是这么一个概念，每个服务负责自己的事；但是当服务多了，协调服务就是个麻烦事了。

SpringCloud就是为了解决这一问题而诞生的。

注册中心

谁来了，谁不在，他都知道；他会给你一个通信录，这样你就可以联系到所有人。

服务注册中⼼本质上是为了解耦服务提供者和服务消费者。

消费者和提供者的角色是互相转换的，实际上下图的消费者和提供者都是微服务。当他成为消费者要找服务的时候，他能知道服务的地址。

主流的：Zookeeper，Eureka，Nacos，其他没用过的就不讲了。

Zookeeper：依靠监听实现；Zookeeper本质就是 存储 + 监听通知；依靠消费端创建节点来监听注册进来的服务。

Eureka：依靠心跳包实现；需要有Eureka Server微服务模块，其他的微服务作为（提供者和消费者都是客户端）Eureka Client，启动时去注册，Eureka Client会向Eureka Server发送心跳包，续约的同时拉取注册中心信息（默认30s，超过90s没续约，将会剔除服务）；Eureka已经不更新了。是Netflix的产品。

Nacos：原理和Eureka差不多也是通过心跳包，但是多了配置中心功能，操作更简单；目前最好用的，注册中心+配置中心的功能。

除了单个的服务，还有集群服务，我觉得主要还是为了集群服务，单个服务可以直接写配置文件里。

网关

你只需要问他你们组谁带了锅？他就会把那个带锅的小朋友找出来；和注册中心不一样，网关会帮你找到，而不是自己去找。

网关和负载均衡一样也是反向代理，网关是按功能路由，负载均衡是按性能分发。如果只是路由的话自己写都行，SpringCloud插件功能一定不止这点。

Spring Cloud GateWay它基于Spring5.0+SpringBoot2.0+WebFlux，除了路由还能拦截。

看上去和注册中心差不多，都是找服务的；由于网关的反向代理，可以使用同一个端口去访问整个微服务。感觉像nginx就能做的事；nginx是在服务器上的，网关是在项目里的，如果又多个项目要部署在同一个服务器上nginx就不够用了，而且也不好修改。

还有过滤器功能，

网关要不要依靠注册中心工作？

路由到集群又是怎么工作的？

网关项目为什么要和主项目平级？因为gateway和web包冲突，需要引用webflux；如果有冲突要剔除web包。

分布式配置中心

有些东西大家都要用的，就交给他拿。nacos包含配置中心。点击发布可以直接刷新配置。

消息总线

通知所有微服务，像广播一样。

除了用来刷新配置还能干嘛？网上大多也是拿来刷新spring cloud config 配置中心，但是现在用nacos，自带配置中心。

发现其他用处再更新//todo

消息驱动总线

消息队列专家，无差别的使用任何消息队列。

Spring Cloud Stream 消息驱动组件帮助我们更快速，更⽅便，更友好的去构建消息驱动微服务的

就像Hibernate屏蔽掉了具体数据库的差异（Mysql和Oracle），Spring Cloud Stream也屏蔽掉了消息队列的差异（RabbitMQ和Kafka）。

使用消息队列可以优化性能，创建一个缓冲区，服务器处理不了的消息就可以先去队列排队，而不至于直接卡死，等服务器空闲了，再去队列拉取消息；就是常说的削峰填谷。

熔断器

负责安全，将受伤的小朋友带到安全的地方。

SpringCloud两个熔断器插件比较

Hystrix（豪猪）：

1）⾃⼰搭建监控平台 dashboard

2）没有提供UI界⾯进⾏服务熔断、服务降级等配置（⽽是写代码，⼊侵了我们源程序环境）

Sentinel（哨兵）：

1）独⽴可部署Dashboard/控制台组件

2）减少代码开发，通过UI界⾯配置即可完成细粒度控制（⾃动投递微服务）

Hystrix需要自己搭建项目，Sentinel只需要引入Jar包，还自带UI；方便很多。

sentinel怎么使用？

java -jar sentinel-dashboard-（版本号）.jar &

使用8080端口访问

账号密码都是sentinel

项目需要引入sentinel包，在网关模块引入就可以管理所有连接了。

配置文件加上，spring-cloud标签下

界面，需要接口被调用过才会出现

QPS是什么？

QPS：（每秒钟请求数量）当调⽤该资源的QPS达到阈值时进⾏限流

负载均衡

把工作平均分配。主要就那几种分配方式。nginx也可以做负载均衡，还有其他的很多工具都可以，为什么要用Ribbon？

应该是历史原因：之前Eureka和Ribbon是配套使用。

Ribbon利⽤从Eureka中读取到服务信息，在调⽤服务提供者提供的服务时，会根据⼀定的算法进⾏负载。

Ribbon和Nginx处理负责均衡的方式不同：

Nginx是服务端选择一个好的服务器给你连接，Ribbon则是在客户端选好服务器在连接。

一个负载均衡算法在服务端执行，一个负载均衡算法在客户端执行。

Ribbon的几种策略

RoundRobinRule：轮询策略

默认超过10次获取到的server都不可⽤，会返回⼀个空的server

RandomRule：随机策略

如果随机到的server为null或者不可⽤的话，会while不停的循环选取

RetryRule：重试策略

⼀定时限内循环重试。默认继承RoundRobinRule，也⽀持⾃定义注⼊，RetryRule会在每次选取之后，对选举的server进⾏判断，是否为null，是否alive，并且在500ms内会不停的选取判断。⽽RoundRobinRule失效的策略是超过10次，RandomRule是没有失效时间的概念，只要serverList没都挂。

BestAvailableRule：最⼩连接数策略

遍历serverList，选取出可⽤的且连接数最⼩的⼀个server。该算法⾥⾯有⼀个LoadBalancerStats的成员变量，会存储所有server的运⾏状况和连

接数。如果选取到的server为null，那么会调⽤RoundRobinRule重新选取。1（1） 2（1）3（1）

AvailabilityFilteringRule：可⽤过滤策略

扩展了轮询策略，会先通过默认的轮询选取⼀个server，再去判断该server是否超时可⽤，当前连接数是否超限，都成功再返回。

ZoneAvoidanceRule：区域权衡策略（默认策略）

扩展了轮询策略，继承了2个过滤器：ZoneAvoidancePredicate和AvailabilityPredicate，除了过滤超时和链接数过多的server，还会过滤掉不符合要求的zone区域⾥⾯的所有节点，AWS --ZONE 在⼀个区域/机房内的服务实例中轮询

远程调用

小朋友直接传话的技术。feign和dubbo就像手机和对讲机一样。

模块和模块之间的方法调用。

Feign：是Netflflix开发的⼀个轻量级RESTful的HTTP服务客户端（⽤它来发起请求，远程调⽤的），是以Java接⼝注解的⽅式调⽤Http请求，⽽不⽤像Java中通过封装HTTP请求报⽂的⽅式直接调⽤，Feign被⼴泛应⽤在Spring Cloud 的解决⽅案中。

Dubbo：是基于RPC的，性能上就比基于HTTP的Feign快。不需要通过controller层来调用。私人定制和模板货（RPC和Http的区别）

//todo  dubbo原理解析

通过中间模块创建接口，然后实现模块和引用模块都调用中间模块的接口；实现模块的@Service需要使用dubbo的注解；controller调用需要用@Reference注解，而不是@Autowired。

链路追踪

记录大家工作，是谁犯错了，他都清楚。

说白了就是记录日志和分析日志。

Sleuth +Zipkin

Spring Cloud Sleuth （追踪服务框架）可以追踪服务之间的调⽤，Sleuth可以记录⼀个服务请求经过哪些服务、服务处理时⻓等，根据这些，我们能够理清各微服务间的调⽤关系及进⾏问题追踪分析。

Trace（踪迹）：一次请求

Trace ID：一次请求的id，整个链的id

Span（跨度） ID：请求到达模块时的id，每次调用内部接口生成一个id

通过span的时间戳判断调用延迟。span之间的时间戳相减。

不会全部采集分析，抽样采集，可以配置比例。全部分析太消耗性能了。

Zipkin（记录日志）

端口9411，可以直接查看。

包括Zipkin Server和 Zipkin Client两部分，Zipkin Server是⼀个单独的服务，Zipkin Client就是具体的微服务。

保存在数据库中。

一个分析一个记录。

具体使用//tido

统一认证

工牌，证明你可以和小朋友说话。

Spring Cloud OAuth2 +JWT

OAuth（开放授权）是⼀个开放协议/标准，允许⽤户授权第三⽅应⽤访问他们存储在另外的服务提供者上的信息，⽽不需要将⽤户名和密码提供给第三⽅应⽤或分享他们数据的所有内容。

JWT是一种加密规则，将token和验证信息加密后一起发送，然后直接在微服务模块自行验证；而不需要拿到token之后再次调用OAuth的方法来验证。