分布式微服务中的整体总结

在整个分布式的项目中，用户请求数据，会通过网关来确实是否可以进入业务中，后通过负载均衡，均匀的分布在每个分布式服务器上，相关服务器通过MQ异步通知到其他服务器，进行处理，接着到数据库缓存查找数据，数据库查找数据，最后进行返回。
在项目启动时，会通过注册中心来注册服务器,以及配置的中心进行分布式服务器的配置。

微服务技术栈统计

Dubbo: Dubbo是微服务未成为主流时，Dubbo就已经出现，Dubbo在注册中心主要是依靠zookeeper和redis，其重要的功能还是为Dubbo的服务远程调用协议，配置中心和服务网关都未做处理

Spring Cloud: Cloud将所有的分布式技术做整合，成为了一个完整的分布式体系，注册中心Eureka、Consul，远程调用基于HTTP协议的Feign(成本低)，配置中心采用springcloudconfig，服务网关采用的是springcloudGeteway和zuul，前者是现在较好的技术，采用了响应式编程，提高吞吐量，监控的保护采用Hystrix

Spring CloudAlibaba:在注册中心采用Eureka、Nacos，服务远程调用采用的是，之前Dubbo和SpringCloud整合(Feign)，配置中心除了SpringCloudConfig以外，还有Nacos，服务监控采用的是Sentinel

Eureka

注册中心，拉取服务，服务提供者和服务消费者的记录信息(服务器)，并提供了负载均衡，每30秒进行心跳契约并及时提更新服务器列表。
实现细节:搭建eureka-server相关依赖-添加@EnbleEurekaServer相关注解，通过springboot 利用工厂模式，提取一个Bean(HTTP协议调用，可利用URL进行远程调用)，搭配eureka地址
注册服务:引入eureka-client相关依赖并注册地址
服务发现:引入eureka-client先关依赖并注册地址，利用RestTemplte添加LoadBalanced(利用Ribbon实现)注解，用服务者的服务的远程名称远程调用(并可以利用eureka的负载均衡)。

Ribbon

服务端开始远程调用请求时(RestTemplte方式)，会通过LoadBalanced注解进行拦截并解析url地址，通过服务名称向eureka进行服务拉取，拉取完毕以后、利用负载均衡的规则进行分配，并远程调用某个服务器。
轮询规则: 1.默认的规则
2.对某些情况的忽略规则(超过3次的连接失败，并发过高)
3.权重选择(通过相应时间判定的权重)
4.分类选择
5.优先选择并发性低的服务器
6.随机选择
7.重试机制的选择逻辑
配置机制:
1.利用创建Bean，并创建并返回负载均衡的对象Irule对象
2.利用yml配置文件
倆者的区别:一个为全局，一个为某个

Nacos注册中心

Nacos使用
1.在父工厂添加spring-cloud-alilbaba管理依赖
2.注释掉其他的的注册中心依赖
3.下载nacos的客户端依赖
Nacos在进行远程调用的时候会在直接调服务器之前有一个集群的步骤，也就是指调用服务器之前要指定那个集群(配置在yml配置文件中进行配置)，然后在指定的集群上，指定服务器
NacosRule负载均衡:是优先采用本地集群，利用随机访问本地服务器，本地没有会跨域访问，并在控制台反馈一个警告。
根据权重负载均衡:1.在Nacos控制台进行设置实例权重值

Nacos注册中心的原理，大致与eureka是一样的，单nacos分为临时实例和非临时实例，临时实例采用的是和eureka相同的心跳机制，而非临时实例采用的是nacos主动询问并且，nacos在检测到非临时实例有问题的时候不会剔除，而是标记不健康了，并等待其被修正。
与eureka不同点: 1.主动推送变更消息使消费者在调用时会更准确，发现服务器有问题 会立即推送
2.分为临时实例和非临时，临时采用心跳，则非临时采用主动询问， 并且不会剔除有问题的服务器。
Nacos配置管理
1.通过Nacos管理页面配置
2.在微服务中引入nacos的config依赖
3.将nacos地址提前放到yml之前的bootstrp.yml配置文件中，使其在springboot加 载时先加载到nacos地址配置中心

Nacos改为热部署
方式一:在value注入的变量所在类上加RefreshScope注解完成刷新
方式二:在@configuarationProperties注解实现自动刷新

nacos的多环境配置
nacos在被加载时，会加载多个配置文件，读取规则是，服务名-环境名-配置文件格式，可以通过创建服务名-匹配文件格式，来达到多环境的共享配置。

nacos配置文件加载的优先级 服务名-profile.yaml>共享服务名.yaml>本地配置

Feign远程调用

RestTemplate存在问题:
1.代码可读性差，编程体验不统一
2.参数复杂url无法维护
feign客户端的使用
1.引入依赖
2.在对应的启动类上添加@EnableFeignClients注解而开启Feign功能
3.添加接口并基于MVC形式配置请求，在服务层直接注入并调用对应方法
Feign在内部以及实现了Ribbon

Feign的性能优化
一.底层实现1.URLconnection默认实现，不支持连接池(性能差) 2.Apache HttpClient支持连接池(支持使用)3.OKHTTP支持连接池(支持使用)
引入依赖并配置对应文件指定对对应连接池的支持
二.日志尽量使用默认

Gateway统一网关

  1.  网关的主要目的:1.身份验证和权限校验  2.服务路由，负载均衡 3.请求限流<br />网关的俩个技术实现:gateway，zuul<br />俩个差别:zuul是基于servle编程的阻塞式编程，gateway是基于spring5中提供的WebFlux，响应式编程，具有更好的性能<br />Gateway网关断言工厂提供了多种判断用户请求的反馈结果或筛选<br />Gateway过滤器工厂，执行顺序为:用户请求到网关-过滤器-服务器-过滤器-用户<br />SpringGateway提供了31种过滤器。<br />网关执行顺序:用户-默认过滤器-路由过滤器-全局过滤器-服务器-全局-路由-默认-用户<br />跨域问题:采用CORS方案

MQ

事件驱动优势:1.服务解耦，解除了直接调用的关系 2.性能提升，提高吞吐量 3.服务没有强依赖，不用担心联机失败问题 4.流量削峰
MQ四种各自区别
RabbitMQ使用Erlang语言，其他是JAVA语言Kafka采用Scala语言
RabbitMQ协议支持多
单机吞吐量，kafka最高，消息延迟rabbitMQ最好，可靠性也是
简单队列:三个角色，服务者向队列发送消息，消费者直接按照对应的队列直接接收