1.微服务概念
单体架构：
优点：架构简单，部署成本低，适合小项目
缺点：耦合太高，不好维护和升级
分布式架构：
优点：降低了服务的耦合度，有利于服务升级和拓展
缺点：架构复杂，难度大
微服务：一种良好的分布式架构方案
优点：职责单一 ，什么都是独立的，一个功能就是一个项目，可以做到高内聚，低耦合
缺点：架构比较复杂，运维和监控部署等 难度比较高
微服务 、SpringBoot 、SpringCloud 三者间的关系：
微服务是：一种架构风格，可以把一个大的项目拆分成若干个小项目，每个小项目都拥有独立的接口，数据库等，相互之间可以调用。
SpringCloud是：微服务的一站式解决方案，里面集成了各种微服务功能组件。
SpringBoot是：SpringCloud整合技术的时候，是基于SpringBoot整合的，他们两个版本互相兼容，我们常用的版本为，SpringCloud：Hoxton，SpringBoot：2.3.X。
微服务的拆分和远程调用：
拆分：
1.微服务需要根据业务模块拆分，做到单一职责，不能重复开发相同业务
2.微服务可以将业务暴露为接口，供其他微服务使用
3.不同微服务都应该有自己独立的数据库
远程调用方式：
1.基于RestTemplate发起的http请求实现远程调用
2.http请求做远程调用是与语言无关的调用，只要知道对方的ip、端口、接口路径、请求参数即可。
服务调用关系：
1.服务提供者：暴露接口给其他微服务调用
2.服务消费者：调用其他微服务提供的接口
3.提供者与消费者角色是相对的
4.一个服务可以同时拥有提供者和消费者两种角色
Eureka注册中心：
基础架构：
1.eureka-server
2.eureka-client:有提供者和消费者
微服务如何得知提供者地址？
1.提供者启动，必须立即注册自己的信息到eureka
2.eureka会保存服务名称及实例ip和端口的映射关系
3.消费者去eurek根据服务名称拉取服务实例列表
消费者如何在多个服务中选择一个？
如何感知服务故障？
1.提供者会向eureka持续发送心跳，默认30秒一次
2.eureka会自动定时检测心跳，如果超时未心跳，就会认为是服务宕机，就会被剔除
如何搭建Eurekaserver？
服务注册：
服务发现：
1.引入eureka-client依赖
2.在yml配置中配置eureka地址
3.给RestTemplate添加@LoadBalanced注解
4.用服务提供者的服务名称远程调用
Ribbon负载均衡
Ribbon负载均衡规则：
1.规则接口是IRule
2.默认实现是ZoneAvoidanceRule，根据zone选择服务列表，然后轮询
负载均衡自定义方式
1.代码方式：配置灵活，但修改时需要重新打包发布
2.配置方式：直观，方便，不用重新打包发布，但是无法做到全局配置
饥饿加载
Nacos注册中心：
Nacos服务搭建：
1.下载安装包
2.解压
3.在解压文件里面开启dos窗口，然后运行指令：startup.cmd -m standalone
Nacos服务注册或发现
1.引入nacos.discovery依赖
2.配置nacos地址spring.cloud.nacos.server-addr
Nacos服务分级存储模型
1.一级是服务，例如：userservice
2.二级是集群，例如：杭州或上海
3.三级是实例，例如：上海的某台部署了userservice的服务器
如何设置实例的集群属性
1.修改yml文件，添加spring.cloud.nacos.discovery.cluster-name属性即可
NacosRule负载均衡策略
1.优先选择同集群服务实例列表
2.本地集群找不到提供者，才去其他集群寻找，并且会报警告
3.确定了可用实例列表后，再采用随机负载均衡挑选实例
实例的权重控制
1.Nacos控制台可以设置实例的权重值，0~1之间
2.同集群内的多个实例，权重越高被访问的频率越高
3.权重设置为0则完全不会被访问
环境隔离
1.每个namespace都有唯一id
2.服务设置namespace时要写id而不是名称
3.不同namespace下的服务互相不可见
Nacos注册中心与Eureka注册中心的共同点
1.都支持服务注册和服务拉取
2.都支持服务提供者心跳方式做健康检测
Nacos注册中心与Eureka注册中心的区别
1.Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
2.临时实例心跳不正常会被剔除，非临时实例则不会被剔除
3.Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
4.Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
若有收获，就点个赞吧
0 人点赞
