微服务

微服务将单体应用分割成更小的的独立服务，部署在不同的服务器上。服务间的关联通过暴露的api接口来实现

优点：高内聚低耦合，一个模块有问题不影响整个应用，增加可靠性，更新技术方便
缺点：增加运维难度，分布式系统复杂，测试开发部署较于单体应用不便

常见微服务架构的技术栈

1.Dubbo 阿里出品，后捐赠Apache
2.SpringCloud Netfilx （逐渐淘汰）
3.SpringCloud Spring官方
4.SpringCloudAlibaba

注册中心

微服务通过http协议使不同的服务进行通信，这些服务需要放在一个池子里进行管理，这就是服务的注册中心，并且其本身也是一个微服务

特点

1.可以对所有微服务信息存储，IP地址端口号，名称
2.查询可用的微服务和对应的网络地址进行服务的调用（进网吧分配机子）
3.对微服务进行心跳检测，如果某个微服务宕机，从注册表中移除

常用的注册中心

Eureka
Consul
Zookeeper
Nacos

CAP定理：不能同时满足以下三原则

C：一致性，数据的一致，所有节点的数据副本都是最新的
A：可用性，一定时间内保证获取数据，即使某些结点发生故障，及时反馈
P：分区容错性，必须满足的条件

为了保证一致性，所有数据一致，发生网络故障就需要阻塞相关资源，也满足不了可用性，因此两者矛盾

Eureka：

1.向服务端和客户端分别引入各自依赖
2.配置文件中向注册中心中注册
3.服务端取消迫切注册，取消自身注册
4.客户端需要加上@EanableEurakaClient注解，表示是客户端
5.服务端有自我保护机制，心跳检测，90秒是否在线，也可以关闭
6.不能保证数据一致性，逐渐被淘汰

Consul:

1.用于代替Eureka，它保证了一致性和分区容错性 
2.启动consul，默认端口是8500
3.注册客户端，引入consul依赖同时引入健康检查依赖，否则即使服务可用，consul也获取不到状态

微服务中模块间相互调用

1.必须在注册中心注册过
2.使用RestTemplate调用接口
3.服务间其实是跨域请求，但是因为在注册中心注册过，可以接受请求

负载均衡

将请求通过特定的算法（默认是轮询策略），均匀的分配到服务器集群中，优化资源的使用，提升可靠性

OpenFeign

一种解决集群负载均衡的技术，相较于RestTemlpate + Ribbon这种实现，它不需要具体的发送http请求，简化操作

1.引入OpenFeign依赖，在主启动类加上@EnableFeignClients注解
2.创建接口，在接口上加上@FeignClient注解，写上集群的名称
3.创建请求方法，与对应请求服务的路径一致，之后在其他服务中注入该接口调用方法
4.get请求传参即使只有一个参数也要加上@RequstParam注解