微服务
微服务将单体应用分割成更小的的独立服务，部署在不同的服务器上。服务间的关联通过暴露的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注解