nacos1

nacos 针对于我用户下单模块 单体的时候 
orderService--->shopService--->BillServoce
我们都是基于本地发起的调用  都是针对于本地数据库的操作
微服务架构 把我们的服务进行拆分
订单
库存
账户 拆出来
对于订单服务来说就有一个一个独立的进程
库存也是一个独立的进程
进程和进程之间就会有远程调用

对于我们用户下单 这个业务来说 我们需要多个微服务来完成这个功能
这就是属于一种微服务架构

微服务的理念就是将服务进行拆分，将单一的服务进行一个小型开发
每个微服务，都在自己的进程中运行，并且这些微服务 通过http或者dubbo 之类的进行通信
怎么去通信，基于业务发起的调用，比如说下单，这就是我们微服务的架构  order 服务-->user 服务--->Bill服务
这里就会涉及很多问题，比如说当我的链路越来越长，此时用户发起一个调用的时候
假设我微服务出问题了
订单---->库存---->账户
比如说我账户服务调用不通了， 导致我此时是不能下单的， 因为此时是独立的进程，是分布式部署的
服务和服务之间是存在网络抖动的
2. 很有可能就是如果我有大量请求进来的时候，比如就是订单服务，负载100%了，可能就拒绝服务，我们也的考虑这个问题 我们可以考虑限流方案
3。假设我们操作mysql 的时候 我出现慢sql, 导致下单链路很慢，这种情况下，我要排查问题的化，该怎么去排查 怎么去定位 到底是哪一个节点出问题了，对于我微服务来说会存在跨部门沟通，效率降低
可以通过skywalking来排查和定位问题
3. 还有分布式事务， 我单体架构的时候 我操作同一个库。同一个服务 同一个进程以内的我可以用@transactional来做事务
跨服务事务可能会用到分布式事务， 这个也就增加了我们的难度
真正让我们微服务架构落地的化  会去思考很多

注册中心到底有什么用  微服务架构  每个服务进行拆分

user--->order  2个Springboot项目
此时跨进程了 发起的调用
我通过user 
user--->order
Restemplate.getObject() user调用order
User 服务 调用order 服务
微服务最基本的需求就是服务之间的调用
就是使用restTemplate发起调用
但是这样会很完美的

1.Localhost:8020 调用我们的订单服务 这里是写死的
线上的订单服务很可能是多节点部署的
user--->(order1 order 2 order 3)
对于微服务来说可以对订单模块进行扩容的（增加了5倍的容量）

你此时在这边是写死的的
我们的微服务 调用不到 其他的order节点（集群的存在）
他感觉不到 服务的宕机 或者服务的增加
以及如果order集群增加或者删减节点的时候  user怎么感知到
这是我们要去解决的

微服务的调用关系  使用http没有办法感觉到集群的变化
现在我们利用restTemplate发起的调用  现在集群变更，我是没有办法处理的

2.我可以维护一个注册表（user------>order）
对于我会员来说我发起来一个调用的话  只需要从注册表中取过来
2个节点 我随便选取一个发起调用就可以

我们可以引入一个中间件叫做注册中心,注册中心维护一个注册表，我都可以吧对应的服务注册进去
对于我user  拉取我服务的话，我就可以发起来调用
我会员拉取我服务的时候  不需要非健康的实例  所以要有一个健康检查的功能

1. inseet  
2. select 

我们可以利用nginx 的upstream   在user层面发起调用的时候
这样的缺点就是 我比如说我发起调用的时候除了调用订单服务，我还要调用我的库存服务
我库存服务的信息也得写进去
在nginx中维护，所以用nginx代替注册中心是不现实的
我们肯定希望我启动的时候  往注册中心中插入数据  我们可以使用mysql

这个时候我们可以使用mysql 存储我们的服务注册信息， 订单服务启动的时候吧服务注册到mysql中
我可以实现基于Mysql的注册中心，吧服务实例注册在mysql中
就比如说我们订单服务 启动之后 发起一个请求  注册接口
会员服务也可以注册， 注册其实就是insert方法到mysql中插入一条记录(ip:port)
如果我下线之后  我注册中心还可以提供一个取消接口，还可以对这个服务进行delete
假设网络不通，对于注册中心来说，我的感知到订单服务和注册中心连不上了， 我可以将这个服务设置为down
down 代表非健康
up为健康

注册插入一条信息到mysql 就是一个Insert语句
针对于会员服务来说 我可以拉取信息

比如说我发起调用的时候  我可以先去注册中中心中去拉取服务
拉取完毕之后  select 
我会员服务从注册中心中拉取 service_name=orderService  发起一个远程调用
这就是我们的设计方案

注册中心有2个很重要的接口
服务注册和服务发现

这就是注册中心的核心功能 做服务注册和发现

服务注册 就是我们要吧这个服务注册在注册中心上
服务发现 就是user 调用的时候通过select 查询

如果order宕机之后  怎么知道 还需要做一个健康检查的接口

会员服务如果每次都查询注册中心的时候 就会影响性能
因为每次发起请求的时候都会调用一次注册中心，多了一次调用
其次如果注册中心挂了，rpc调用就会不通过 因为每次调用都是从注册中心拉取的服务
服务的调用严重依赖注册中心 但是从本质上来说
对于我们微服务来说
我即便注册中心挂掉了
我也可以调用到我们的订单服务
对于注册中心来说怎么去解决

1.健康检查机制---》心跳接口
我可以在每一个微服务中启动一个TimeTask 定时任务

可以和注册中心通信  定期发心跳 比如说5s 发一次 告诉注册中心 我还活着
给注册中心发心跳 叫做服务的续约
每隔5s续约一次
对于注册中心来说 看下 上一次发心跳距离现在相差几秒 比如说超过5s
就有可能你宕机   假设你10s没有发心跳的时候我可以吧状态改了down

服务状态设置为down以后  对于我会员服务  拉取的时候 就拉取不到订单服务了。
只会拉取到可用的服务

怎么感知服务的递减，通过心跳机制 专业点叫做健康检查

对于我会员来说,不能注册中心挂了 我就没有办法调用我订单服务了
我远程调用之前不用都查询一下
我可以启动一个TaskTime  假设每次隔5s 拉取一个服务列表进行缓存
然后发起调用的时候 基于缓存去查询，之后再根据负载均衡算法去发起调用


用户发请求的时候 此时不用再查询注册后中心了  只需要从cache拿到数据就可以了

所以注册中心的作用
注册
发现
心跳
健康检查
注册中心这边保证高可用 你不能单节点  可能还得做集群
集群中间可能还得做服务的数据同步 这都是要考虑的
微服务中为什么要有这个注册中心了 核心作用就是
服务注册和服务发现

nacos还可以做配置中心
CP 就是 服务注册表在内存中 就是你重启之后会丢失
AP 就是持久化到磁盘就是重启之后会从磁盘进行加载
nacos  可以做服务发现也可以做我们的配置中心来管理我们的微服务
配置中心就是我们的  统一管理微服务的配置  可以吧一些redis的配置 缓存的配置 
统一管理

Nacos 有官方文档
Config Service   配置中心的核心服务
Naming Service  注册中心的核心服务
openApi 开放性api 层面
对于我注册中心来说可以查询你的实例列表
nacos的核心api 在官网暴露出来了 也就是说可以支持异构
如果有一个服务 他不属于springcloud体系    我就可以通过他的接口注册到注册中心
支持异构

然后重点讲一下 我们ancos 2.1.0   这是最新的版本
Nacos 2,0的版本 底层通信方式变化了
之前是http  是底层mvc形式的接口
2.1.0 底层变了 变成了 grpc

Nacos 是经过阿里的双11 检验的
所以我们选型注册中心的话  优先nacos

呢么我们接下来看下nacos的架构和我们之前的mysql这种架构有什么出入

这些user,order微服务统称为client  注册中心是service端
微服务启动的时候 nacos-client中的Jar,启动期间可以调用我们的服务注册接口进行注册
底层通过grpc(2.1版本的) 进行远程通信
ordr服务会注册2个节点
当我们会员调用订单服务的时候
服务发现接口  定时拉取服务列表（在本地进行缓存）
借助我们的负载均衡器 从缓存中拉取列表之后发起调用
nacos的服务注册  
临时实例存储在内存中
持久实例存储在本地磁盘中
服务心跳 每次隔5s的时候client 就会发送心跳到service中
服务同步  集群中间会进行服务同步 保证信息的一致性  当然此时一致性不是强一致性 而是最终一致性
心跳机制 nacos超过15s的没有收到心跳的话 就会将healthy的状态从up设置为down
 

启动nacos  
user服务导入nacos-client的jar就可以了 （springboot以及cloud 以及alibaba的版本依赖问题）
我需要对我的springcloud做我们的版本管理  springcloudAlibaba的boot
版本

引入nacos之后配置地址

服务起来的时候帮我们注册了  然后我们在nacos 的控制台就可以看到
可以通过nacos 的api可以验证  

我们也可以基于namingService将我们的服务进行注册
基于namingService可以注册我们的服务 同时也可以拉取我们的服务
怎么从注册中心拉取服务  基于namingingService拉取
集群名字是test1

我们可以通过nameservice的api将这些我们自定义的服务注册上来

此时是有2个集群的 代表有2个机房

服务名称  集群名称 

基于服务名称进行注册  在不同的集群很正常  很有可能订单服务在上海机房也有
在北京机房也有 （1中心 2中心）
因为用户的请求处理会采用就近原则	 比如说 我在华东地区进行处理 
尽可能提升用户的额体验
我们原来调用的时候 @RestTemplate
现在再调用的时候 加上@LoadBalced 就可以了
他会帮助我们去调用

然后基于服务名称发起的调用
我们引入@LoadBanaced 这个注解 实际上就是把我们底层的 mail-order 替换ip:port
这样就可以发起微服务调用

Nacos 底层模型是从服务 到集群 到实例的模式

服务----》集群---》实例 

服务就是 user服务
集群就是机房 比如说上海 北京
这样做 便于对他进行扩展

比如说订单服务 有上海机房 有北京机房

上海机房有很多实例 
北京机房也有很多实例

同集群优先调用  怎么控制  

nacos的命名空间（nameSpace）可以做环境隔离 比如说prod dev

nacos的集群需要配置 外部数据源

Nacos 集群启动有3个节点 可以看到
官方建议（sprigboot的yaml） 我们使用nginx 做反向代理
Yaml (nginx)=====>集群
不要让我们的微服务的具体ip port 暴露到外网上 如果暴露在外网上是有安全隐患的