微服务框架及其中出现的各种问题和对应的解决方案/组件

从单体到集群到微服务

单体就是我们之前开发的
这里我们称服务器为节点，域名可以理解成IP地址的名字（好记的IP地址，比如www.baidu.com）

集群架构
单体应对高并发场景很吃力
说白了就把你的项目多部署到几台服务器上（复制处理的这个项目可以叫做副本）
然后通过一个网关（nignx）进行负载均衡，平均将请求分给每个服务器（他有自己的算法，可能也不是平均），网关就起到一个路由的作用
然后数据库的话也可以多搞几台部署在不同服务器上


微服务架构
就是把我们的功能单独出来做成微服务，同时我们数据库也可以拆分成不同的库（比如商品就用商品表和一些其他的表）
然后有重复业务，比如订单表要查商品的数据库，就去请求商品的微服务（远程调用），而不是直接去访问商品数据库

我们就可以将不同的服务部署在不同的服务器
如果一个服务请求多，可以多几个副本部署
接下来讲解我们的RPC
RPC即远程调用常见用http+json数据返回的形式，来进行业务之间的关联
用户的微服务要用到订单库，就请求订单的微服务嘛
那么用户微服务怎么知道订单微服务在哪个服务器呢？
就需要我们的注册中心，我们部署服务线进行服务注册，将自己所在服务器和什么微服务告诉注册中心
然后我们用户从拿着我要找订单服务区注册中心就能找到了，这个过程叫服务发现
（如果这个服务多个服务器都有，也可以做负载均衡，第一次请求0.4，第二次请求0.5）
让我注册中心一般有一个额外功能为配置中心
可以给所以注册的微服务进行配置且推送配置（不用重新打包部署，很方便）

下面讲一下其他概念
服务熔断和服务雪崩
我们的直播服务调用订单服务，订单服务调用支付服务
假设支付服务卡了，那么我们订单和直播服务也会卡等待支付服务
这样一个微服务卡顿，会导致整个微服务链的卡顿
最终导致服务雪崩
解决服务雪崩就需要服务熔断机制
比如用户调订单，订单卡了，就快速返回错误信息，就用户不等订单
什么时候不等什么时候等由熔断算法来判断
所谓熔断就是快速失败机制

网关
其实和之前一样，这次网关要从注册中心获取对应请求所在的服务器来转发请求，
分布式事务
比如我们下单这个操作是在订单服务中完成，但是这个还要调用户服务增加用户积分
这样的话就进行两次写操作，需要加事务保证安全性，但是两个数据库由是隔离开的（一个数据库事务好做）
所以就有了分布式事务

这就是我们对应要学习解决分布式问题的一些组件