我们的微服务架构 我们的微服务架构和单体架构的区别
什么是微服务架构
微服务就是吧我们传统的单体服务分成 订单模块 库存模块 账户模块
单体模块 是本地调用 从订单模块 调用到库存模块 再到账户模块 这三个模块都是调用的同一个数据库 这就是我们的单体架构
微服务 就是把我们的订单模块,库存模块 账户模块拆出来 作为 订单服务，库存服务
账户服务
基于订单模块我就可以有独立的进程了
用户在下单的时候 此时涉及到远程调用
我们此时有独立的数据库，针对我用户下单这个业务来说 需要我们3个微服务来完成
可能别的功能需要多个微服务来完成
这个就属于微服务架构
整个系统的业务可能有几百个 甚至上千个微服务去完成 这种架构就是微服务架构
微服务 在自己的进程中运行 并且这些微服务通过rpc调用,比如说http.dubbo进行通信
他们是基于某一个业务来调用的比如说用户下单.就需要我们的订单 库存 账户
给予我们的业务功能来构建
这种就是我们的微服务架构,会有很多问题随着链路增大,当我发起请求调用的时候.假设出问题了
比如说账户服务调不通 就会导致我用户是没有办法下单的
微服务是独立进程，分布式部署，就会存在网络抖动，网络不通又是怎么去解决
如果有大量请求 很有可能就是你订单服务扛不住，负载直接飙升到90%
直接就拒绝服务了 这个问题我们也得去解决 我们还得需要有一些限流方案
还有 假设操作mysql 我在账户服务出现了慢查询，此时我的下单链路就会很慢
这种情况下我的排查问题， 我该怎么去排查，到底是哪一个节点出现问题了。
因为对于我微服务而言，此时可能会涉及到跨部门沟通，效率低，我们这个慢操作到底出现在那个环节上
是不是此时还有个链路追踪组件，
是不是还会涉及到分布式事务
单体架构在同一个进程内 用的本地事务
此时就涉及到跨服务 只能用分布式事务，就会增加我们的难度
真正保证分布式的稳定性 我们要有很多的方案 真正的想让微服务架构落地的时候要学习很多
1. 注册中心
2. 注册中心有什么用
我此时springboot的2个应用 我用户和订单模块 我通过url发起的调用
我此时涉及到跨应用和跨进程
我可以基于resttemplate 进行发起调用
我 user--->>>>>>order 服务 就可以 通过restTemplate 就可以发起调用
这就是完成我们微服务最基本的需求 就是我们服务之间如何调用
使用restTemplate 这样是有问题的
比如说 我 user--->order 我此时订单服务是有多节点部署的
User------->order (扩容)
现在如果扩容了 假设 我启动一个 8021
根本原因就是我们吧这里写死的，
微服务里面的调用关系 如果使用http框架 没有办法感知到我们
这个就是我们急需去思考的问题
我们现在基于restTemplate发起的调用， 我扩容的时候 就没有办法了
我吧这个服务节点注册进来 我会员发起调用的时候 我发起调用
我从List中去取一个 随机get(0)一个 我们可以引入一个中间件 --》》》》注册中心
我consumer就可以拉取到 这个列表
就是我现在写死是不行的 我就得写活 我可以使用zk 或者redis 去存储
我某一个服务宕机了 我又能怎么感知到
我们的会员服务 不需要非健康的实例，所以我们需要一个健康检查的功能
我们可以用nginx配置一个upstream来做
比如说 我 服务很多 我就的维护很多,我们采用nginx 做注册中心肯定是不现实的
所以我们希望我们的服务启动起来的时候直接在nginx中插入数据
我们就想到mysql
我们就可以使用mysql 存储我们的服务注册信息 我们可以基于mysql 来实现我们的注册信息
就可以把服务的实例注册在mysql中
就吧服务的实例存储在Mysql 就比如说订单服务启动之后就可以发起个请求，
在mysql中注册一条信息 进行注册 就比如说
如果你意外下线的化可以来一个取消接口把服务进行删除
假设我网络不通 我可以把状态设置为down down 就代表非健康
对于我会员服务来说 我就可以拉取信息
我调用的时候 我就可以从注册中心中去拉取 这样来的化
我发起请求的时候就可以从注册中心去拉取对应的服务的Ip 和port
我拉过来之后我就可以get(0) 进行拉取了 我就可以发起本地远程调用了
我们的注册中心 他有2个很重要的接口 1. 注册接口 2。获取服务的接口
获取服务的接口 我要拉取所有的订单信息 这是最核心的接口
这就是注册中心要实现的核心功能，服务注册和发现
服务注册 就是需要吧我们的服务注册在 注册中心上
服务发现 就是我们调用模块 做发现
服务发现 不仅仅做新增和删减
很有可能就是你宕机的时候可能就挂了， 还需要做一个健康检查
不能每次发起远程调用的时候都过注册中心 其次如果注册中心挂了
发现此时会员服务是没有办法掉通的
服务的调用严重依靠注册中心
即便你注册中心挂了， 我也能调用到你订单服务
我需要做一个心跳接口 就是说我可以在我每一个微服务中启动一个定时任务 定期发心跳
假设5s发一次心跳，比如说ping3306
叫做服务的续约
告诉注册中心我还活着
最后一次发心跳的时间、 最后一次服务续约的时间
我可以基于中台的功能去看 先看有什么模块 尽可能的了解业务
我记录下来
对于我注册中心来说 会检查 假设到11s 上一次还是01s
隔了10s 你还没有发送心跳过来
就代表i已经挂了
我就给你设置为down
他此时还没有删除 假设30s 的化 还没有做 我就可以认为你已经挂掉了 这个服务如果干掉的化 对于我们会员服务来说拉取我们服务的时候只会去取一个 通过心跳的机制感知到服务的增减
对于会员服务来说 你不能因为 我注册中心挂了 我就不能发起调用
服务的调用严重依赖于你注册中心
即便你注册中心挂了 我也能调用到你的订单服
我需要一个心跳接口，我可以在每个微服务中 启动一个定时任务 假设每5s 我发一次心跳
告诉注册中心 我还活着 假设最后一次发心跳的时间 我记录下来，
最后一次服务的续约时间
对于我们注册中心来说 会检查 假设到11s, 上一次还是01s 隔了10s 你还没有发送心跳过来
就代表你已经挂了
我给你设置为down
我需要通过心跳机制来感知服务的增减
对于会员服务来说 你不能因为 我注册中心挂了 我就不能调用
我可以缓存起来 然后利用负载均衡算法 get(0) 发起调用 解决了每次调用之前我都的从服务器拉取的一些问题
以及我注册中心挂了就不能发起调用了
缓存起来的好处就是客户端发起调用的时候 我只需要从本地缓存中去读取就可以了
注册中心 如果自己去实现的化 让自己去设计的化 有什么思路
微服务中为什么要有这个注册中心
核心作用就是服务注册和服务发现
注册中心的实现
注册中心的技术选型
CP+ap
Cp 就是说他的服务实例在内存中
Ap 就是说服务实例会持久到磁盘 重启的化 会从磁盘中进行加载
微服务的技术栈 主讲就是nacos alibaba这一套
openApi 针对于我api来说我可以通过api来查询他的功能
我就可以支持异构
nacos的2.0的底层通信变了
以前是基于Mvc的http 接口
2.0 变了 变成grpc了
要学会看待自己的不足 我们做技术选型的时候优先选择nacos
nacos的架构
1、基于目前情况分析目前的原因
2、出解决方案 进而改进
服务的提供者和消费者
User--->Order
NacosClient
NacosServer
Client 在启动的时候会发起一个 服务注册的接口 去进行服务注册,在2.1 版本就会基于grpc发起通信
当我们user-->order的时候 ，服务发现从nacos中拉取服务， 然后借助ribbon发起负载均衡调用
我们的注册中心的概念
流量的打标 在元数据中达标 灰度
注册中心的核心功能
服务注册和服务发现
服务心跳
服务同步 数据的一致性 （nacos的）
加入pom 引入依赖 注意springBoot和springcloud的版本依赖 做统一的版本管理 以及兼容性问题
