认识微服务
1.单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署
优点：架构简单
部署成本低
缺点：耦合度高
2.分布式架构：根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务
优点：降低服务耦合度
有利于服务升级拓展
缺点：配置环境增多
考虑问题：服务拆分粒度
服务集群地址维护
服务之间的远程调用
服务健康状态感知
3.微服务：经过良好的架构设计的分布式架构方案
特征：单一职责：微服务拆分粒度更小，每一服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
面向服务：微服务对外暴露业务接口
自治：团队独立、技术独立、数据独立、部署独立
4.微服务结构
请求路由负载或均衡
用户——>服务网关——————————>服务集群
SpringCloud
1.国内使用最广泛
集成了各种微服务功能的组件，并基于SpringCloud实现组件的自动装配
2.组件： 服务注册发现 统一配置管理
服务远程调用 统一网关路由
服务链路监控 流控、降级、保护
3.服务拆分及远程调用
注：不同微服务，不需要重复开发相同业务
微服务数据独立，不访问其他微服务数据库
微服务将自己的业务暴露为接口，供其他为服务调用
4.远程调用方式分析：基于RestTemplate发起的http请求实现远程调用（说明url路径）
http请求做远程调用是与语言无关的调用，只要知道对方的ip、端 口、接口路径、请求参数即可
-
注入RestTemplate
-
在Service类中使用restTemplate.queryOrderById（url，返回值类型）方法
5.服务远程调用：提供者与消费者
服务提供者：一次业务中，被其他微服务调用用的服务。（提供接口给其他微服务）
服务消费者：一次业务中，调用其他微服务的服务。（调用其他微服务提供的接口）
一个服务可以既是提供者又是消费者
6.服务调用的问题：消费者如何获取提供者的地址信息
若有多个提供者，消费者如何选择
消费者如何得知提供者的健康状态
Eurka
1.Eurka注册中心（对应上述问题）：
-
提供者启动时向eurka注册自己的信息（心跳机制，每30秒一次）
eurka保存这些信息
消费者根据服务名称向eurka拉取提供者信息
-
消费者利用负载均衡算法，从服务列表中挑选一个
-
服务提供者每隔30秒向EurkaServer发送心跳请求，报告健康状态
eurka会更新记录服务列表信息，心跳不正常会被剔除
消费者可以拉取到最新的信息
2.搭建EurkaServer服务步骤：
-
创建项目，引入eurka-server依赖
-
编写启动类，添加注解@EnableEurkaServer
-
添加文件application.yml，编写配置文件eurka地址(http://127.0.0.1:10086/eureka)
3.服务注册(将客户端注册进eurka)
将user-service服务注册到EurkaServer中
-
引入依赖eurka-client
-
在application.yml文件，编写配置eurka地址
4.在order-service完成服务拉取（服务发现）
服务拉取是基于服务名称获取服务列表，然后对服务列表做负载均衡
-
修改order-service代码，修改访问url的路径，用服务名代替ip、端口
String url = "http://userservice/user/" + order.getUserId();
-
在order-service项目的启动类OrderAppilation中的RestTemplate添加负载均衡注解
@LoadBalenced
服务发现步骤
-
引入依赖eurka-client
-
在application.yml文件，编写配置eurka地址
-
在RestTemplate中添加@LoadBalanced注解
-
给服务提供者的服务名称远程调用
负载均衡
1.负载均衡流程
-
order-service向Ribbon负载均衡发起请求
-
Ribbon拉取eurka-server
-
eurka-server返回服务列表给Ribbon
-
Ribbon轮询到端口号
2.负载均衡策略
修改负载均衡策略（两种）
-
代码方式(全局）：在order-service中的OrderApplication类中，定义一个新的IRule（规则接口）
@Bean
public IRule randomRule(){
return new RandomRule();
}
-
配置文件方式（某个微服务）：在order-service中的application.yml文件中，添加新的配置
userservice:
ribbon:
NFLoadBalanceRuleClassName: com.netflix.loadbalancer.RandomRule
3.饥饿加载
Ribbon默认采用懒加载，第一次访问时才会创建LoadBalanceClient，请求时间很长。
饥饿加载是在项目启动时创建，降低第一次访问的耗时，通过修改配置开启饥饿加载
ribbon:
eager-load:
enabled:ture #开启饥饿加载
clients: userservice #指定饥饿加载的服务名称（可有多个）
Nacos
1.认识Navos
是SpringCloud的一个组件，功能比Eurka更多
2.服务注册到Navos
-
在cloud-demo父工程中添加spring-cloud-alibaba的管理依赖
-
注释掉原有的eureka依赖
-
添加nacos的客户端依赖
-
修改application.yml文件，配置nacos地址（localhost：8848）
3.Nacos服务分级存储模型
-
服务--->集群（按地域划分）----->实例
-
服务跨集群调用问题
服务调用尽可能选择本地集群的服务，跨集群调用延迟较高
本地集群不可访问时，再去访问其他集群，会报警告
确定了可用的实例列表后，再采用随机负载均衡挑选实例
-
服务集群属性
discovery
cluster-name:HZ #配置集群的位置eg：HZ杭州
4.根据集群负载均衡
-
修改order-service中的application.yml文件，设置集群为HZ
-
在order-service中设置负载均衡的IRule为NacosRule，这个规则会优先寻找与自己相同的集群服务
-
将user-service的权重都设置为1
5.根据权重负载均衡
通过改变权重可以控制访问频率，权重越大则访问频率越高
-
在Nacos控制台设置实例权重值（0-1），选中实例后的编辑按钮
-
将权重设置为0.1，测试发现访问频率降低
6.环境隔离-namespace
对服务做出隔离，每个namespace都有唯一id，不同namespace下的服务不可见
-
在控制台创建namespace，填写新的命名空间信息，得到命名空间的id
-
修改order-service中的application.yml文件，添加namespace（id）
Eurka和Nacos区别
1.共同点：
都支持服务注册 和服务拉取
都支持服务提供者心跳方式做健康检测
2.区别：
Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
临时实例心跳不正常会被剔除，非临时实例 则不会被剔除
Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式：Eureka采用AP模式
