前言
对于一个微服务项目，我们需要学会哪些技术栈，以下是我学习微服务完成一个项目开发后的总结。
微服务有什么好处？
对于一个单体项目来说，有什么缺点呢？ 1、单体项目的多个模块部分作为一个服务来部署，多个模块之间会相互影响，如果有模块耗尽了系统资源，其他服务就会收到影响 2、单体项目含有多个模块，打包部署比较慢 3、团队协作成本高，所有人在一个项目中开发不同模块，可能会造成依赖冲突等一系列问题 而使用微服务可以解决这些问题 1、每个微服务独立部署，每个微服务之间做好线程隔离，防止微服务之间相互影响 2、每个微服务独立部署，即使代码变更，单个服务重新启动即可 3、每个团队负责一个服务，不会相互影响 但是微服务也带来了一些其他问题，例如跨微服务的业务、服务隔离、数据一致问题等
服务拆分
对于一个微服务架构的项目，我们有多种拆分的方式 1、将多个服务拆分为多个工程 2、将多个服务拆分为一个工程的多个模块 我们暂且选则第二种的拆分方式。 通用模块：服务拆分的原则是高内聚、低耦合，一般我们将多个服务的通用功能放入一个通用模块中； 远程调用模块 ：如果一个服务需要远程调用另一个服务，我们只能通过网络请求进行调用，配合发送请求的组件（OpenFeign）我们可以再设置一个发送网络请求的模块； 网关服务：每一个微服务的地址不同，那么前端发送请求过来，怎么到每一个微服务中呢，我们需要通过网关（GateWay）来根据每一个请求的url地址信息将请求发送到微服务中 因此，微服务的项目一般包括以下的组成部分：通用模块、远程调用模块、网关服务和根据拆分原则拆分的关于业务的服务
注册中心
对于服务之间的远程调用，我们只能通过发送网络请求的方式来实现，而对于一个网络请求，它的url是写死的，如果要被请求的服务部署了多个实例呢？如果有一个实例挂了，我们想要让这个请求到部署的另一个实例呢？ 我们通过注册中心来实现，在注册中心有三个角色，分别是：服务注册者、服务调用者、注册中心 原理：服务注册者与注册中心建立连接后，会在注册中心记录服务名称、实例以及地址信息，服务调用者想要远程调用时只用通过要调用的服务名称，在注册中心寻找服务，如果存在多份实例，会通过负载轮询算法挑选实例，服务注册者每隔一段时间通过发送心跳给服务注册者，当注册中心没有收到心跳时，就会觉得该实例挂掉了，就不会轮询到该实例。
注册中心如下：
随便查看一个服务：
Nacos除了可以作为注册中心之外，还有其他用处，例如抽取共享配置、配置热更新等，我们之后再详细讲。
OpenFeign（便捷构建请求发送）
远程调用需要我们手动发送请求，如果手动编写请求发送过于麻烦，我们引入了OpenFeign插件，通过OpenFeign可以快速发送请求。
我们通过debug查看其是怎么构建请求的。
这是我们封装的方法，可以看出这里提供了远程调用服务的名称、请求类型和部分请求路径和参数
进行debug：
我们发现生成了代理类：
继续往下走：
根据我们之前讲的：动态代理原理
我们可以知道生成代理类之后，调用代理类的方法会被中转到invocationHandler的invoke方法中，会在其中做增强处理。
我们发现进入了invoke方法中并且构建了网络请求的信息
服务保护
在微服务的架构中，服务之间可以进行远程调用，如果服务1包含服务2和服务3，服务1调用服务2，如果服务1调用服务2的并发量太高，不仅会影响性能，可能还会因为耗尽服务器资源从而影响服务1和服务3，造成雪崩。 因此我使用Sentinel对服务的调用做出一些保护措施。 请求限流：限制接口的每秒QPS阈值 线程隔离：设置服务调用不同服务的并发线程数量的阈值，防止远程调用使用过多线程导致系统资源耗尽 服务熔断：给服务设置熔断规则，当慢调用/异常数量/异常比例达到一个阈值之后，直接走降级措施（直接返回，提高调用性能）
分布式事务
对于一些业务，比如一个需要减少库存并且生成订单的业务，需要远程调用库存服务减少库存，并且再次调用到订单服务中生成库存，我们在单体项目中做这样的业务，都会开启事务，让他们具有一致性，但是在分布式系统中，怎么开启事务呢？ 我们使用Seata组件来实现分布式事务。 Seata中包含三个角色：TC、TM、RM TC：全局事务协调者，负责协调全局事务和分支事务，对全局事务进行提交或回滚 TM：全局事务管理，负责管理全局事务，开启、提交、回滚全局事务 RM：管理分支事务，注册并上报TC，驱动分支事务回滚或提交 Seata实现分布式事务的模式有两种：XA和AT XA： 第一阶段：当开启全局事务后，每个分支事务开始执行业务，分支事务执行业务结束后不会立刻提交，而是上报给事务协调者分支事务的状态。 第二阶段：事务协调者根据每个分支事务上报的状态，如果所有事务都执行正确，将会下达提交的指令，每个分支事务会进行提交。 优点：保证了数据的强一致性 缺点：锁定资源了一段时间，浪费性能。当事务提交之后才会释放锁，未提交事务导致分支事务一直锁定锁，在第二阶段才释放锁 AT： 第一阶段：每个分支事务执行业务结束后会直接提交事务，并且将事务记录在本地的undo log表中，并且上报给事务协调者状态 第二阶段：事务协调者如果收到失败的状态，会下令回滚的指令，每个分支事务通过undo log日志进行回滚 优点：性能较高，不会锁定资源 缺点：不能保证强一致性，只能保证最终一致性。分支事务在第一阶段提交后对其他事务可见，如果其他分支事务发生错误导致所有分支事务回滚就造成了数据不一致问题 场景应用：根据
