微服务基础内容：

在微服务中，首先学习了微服务的横向拆分与纵向拆分，纵向拆分指按照功能拆分模块，横向拆分指将高复用的模块单独拆分，使纵向拆分的模块去调用这部分内容。

学习了基本拆分后，需要知道微服务之间的关系是多对多的消费者生成者模型，每个模块互为消费者与生产者，为了微服务之间传递的可靠性，需要用到nacos组件。nacos组件的主要充当一个中介——注册中心，nacos与生产者间通过心跳协议维护一张服务表单，当消费者需要生产者的调用时，nacos会给消费者提供相应的生产者表单，这个表单维护了多个完成消费者服务的端口号，消费者根据负载均衡选择一个端口号进行建立连接，从而调用生产者。

学习了基本拆分与nacos后，拿到了具体的生产者的端口号，引入了openfeign组件，这个组件实际上就是http转发工具，因为不同微服务之间是相互隔离的，拥有自己的数据库与服务器，所以不同微服务之间的调用需要采用网络请求，openfeign的作用就是这个。通过端口号以及对应的openfeign转发，从而构建不同微服务之间的连接与调用。

学习了上述内容之后，开始思考如何进行鉴权。还是由于微服务的隔离性，不同服务之间如何拿到鉴权信息？回顾单体架构的鉴权方式，使用的是springmvc拦截器，通过在拦截器中获取http.request.header中的授权信息后，在后端将授权信息比对，从而将需要的权力信息（比如userInfo）存储在ThreadLocal中，然后在线程执行期间就可以随时在鉴权页面拿到想要的内容。

在微服务架构中采用网关来实现上述操作，不仅如此，网关还可以解决前后端端口号不一致的矛盾。前端只会访问网关，网关来负责转发给不同的微服务。

以鉴权举例，网关通过拦截器拿到userInfo，存储在threadLocal中，当本次调用的微服务要调用下一个微服务，并且需要userInfo时，会使用openfeign工具，将userInfo存储在这个网络请求的请求头中，转发的请求仍然再一次访问网关，网管拦截器拿到userInfo，提取出放入该微服务执行线程的threadlocal中。从而实现，多个微服务之间的数据传递。

开始：

上述内容都是微服务的基本内容，现在需要考虑微服务的一些弊端。

一、首先微服务显然会出现雪崩的场景，当某个微服务A宕机后，后续调用该微服务B调用A时也会卡在请求A的过程中，后续又有C调用B，C也卡住（继续向后叠加奖池）从而造成A/B/C的资源一直在请求中无法释放，最终造成服务器资源耗尽而崩溃。

sentinel组件就是用于解决这个问题的，sentinel组件也是alibaba旗下的，与nacos配合服用。

sentinel的操控在控制台中，只需要导包与配置，方便快捷，在管理面板添加相应的配置项后，甚至可以免服务部署来更新对应的参数。说一说sentinel的作用，sentinel的作用主要分为限流与熔断。

1.限流包含限制访问请求数以及为微服务分配的线程数，限制请求数就是限定QPS，这个很好理解。

2.限制线程数为每个微服务分配固定的线程数，请求到了微服务，首先去线程池中取线程，如果没有线程，那么就会返回报错。

3.针对返回报错导致用户体验不好的弊端，在openfeign中又定义了一个错误处理，这个可以理解为单体架构中的异常处理，代码案例如下：

@Slf4j
public class CartToItemFallback implements FallbackFactory<ItemClient>{@Overridepublic ItemClient create(Throwable cause) {return new ItemClient() {@Overridepublic List<ItemDTO> queryItemById(Collection<Long> ids) {log.error("查询商品失败",cause);return CollUtils.emptyList();}@Overridepublic void deductStock(List<OrderDetailDTO> items) {log.error("扣减库存失败",cause);throw new RuntimeException(cause);}};}
}

这个内容会被对应的ItemClient生成注解并标记。需要理解的是，我们进行fallback处理的是微服务调用之间的问题，而宕机的微服务不是通过fallback进行处理的。当微服务A调用宕机微服务B时，A这个时候因为限流没有拿到B的资源，这时直接fallback返回，不会出现报错，A中的其余项目继续处理即可。

4.sentinel中除了限流还有熔断机制，限流只是为了防止未出现故障的微服务A调用已经宕机的微服务B而造成整个系统崩溃，但是A还是会去调用B，只不过A没有调用成功而已，这个请求的过程仍然在耗费资源。

而使用熔断机制后，能够直接不让A发送请求。熔断机制会监控一段时间或一定次数内的调用失败率（或错误次数），比如在sentinel中就有TTL，当连接响应超过设置的TTL以及持续多少秒后（达到阈值），就将熔断器置为 Open 状态，此时所有对微服务 B 的调用都会被短路快速失败，不再真正发送请求。经过一个休眠时长后，熔断器进入 Half-Open，允许少量请求恢复探测；如果恢复良好，则关闭熔断器，否则继续保持 Open。

二、在学习了sentinel后知道了如何处理单个微服务的崩溃问题，继续学习微服务中的事务问题。

微服务的事务问题和单体架构的事务问题很相似，举个例子：

支付操作：对用户扣款，将订单状态修改为已支付。

这个例子中，用户服务会去调用订单服务，如果用户扣款服务正常执行，但是执行订单状态修改时出现了问题，从而导致数据库不一致。

这个解决的方案就是使用seata组件，来对事务进行控制。

想要进行事务，简单分析就是让多个微服务进行提交的同步或者回滚的同步，就如同数据库中的提交与回滚类似，只不过在这里的事务不完全保证原子性（如AT方法）

seata组件支持两种方式来进行事务控制，分别是XA和AT：

XA方式：

XA方式是最早的传统方式，方式比较粗暴，首先RM注册分支事务到TC（也就是告诉TC我是一个多服务时间，需要XA管理），然后RM去执行对应的sql操作，但是此时不进行提交，RM 向 TC 发送服务运行结果，TC比对这个时间所有RM的执行结果，进行统一的提交和回滚。
显然这个方式很好的保证了多个微服务的sql操作同步性，但是弊端也比较明显，这种方式即使对应的微服务已经完成工作并且发送给TC其成功状态，仍然还需要等待其余RM执行完毕，造成资源的浪费。优点是不会出现数据库的不一致，保证结果的完全可靠。

TA方式：

TA方式是现在国内用的比较多的一种方式，TA方式不同点在于 所有RM注册后，会对当前的环境生成相应的快照undo-log，说白了就是备份当前数据库环境。
然后每个RM分别执行自己的，执行完后自行提交，提交由RM自行完成，提交完后向TC报告执行状态。

当所有RM进行报告后，TC会来验收，如果有RM出现故障，就会回滚到最初的快照状态。
TA方式优势很明显，每个RM结束后就会立刻释放资源，不会造成资源的浪费。
缺点也比较明显，TA方式会导致短暂的数据不一致（在RM提交后到TC检查到错误并回滚之前）