当一个springboot单体架构项目拆分为一个springcloud微服务项目时，难免会遇到很多问题

一.各个服务之间单独部署，可以理解为各个服务自己就是一个单体架构项目，那么如何建立联系呢？

引入nacos注册中心，服务提供者去进行服务注册，服务调用者去进行服务发现，并且nacos支持多实例注册，比如流量较高的模块我们可以多次服务注册

nacos还支持配置管理，对于一些共享的配置信息我们写到nacos中，减少在项目程序中书写太过重复的配置，然后微服务启动时去nacos拉取即可。

为了我们方便编写程序，又引入了openfeign，方便进行服务之间的远程调用

openfeign需要有一个配置类（比如配置日志级别，以及在调用其他微服务时，要编写过滤器从当前的ThreadLocal中携带上用户信息以便其他微服务的springmvc拦截器可以拿到用户信息以便其他微服务能够识别哪个用户来调用了，某些业务场景需要用户信息，比如id）

还有每个openfeign的client我们为其编写fallback逻辑，程序出现异常时，不是直接抛出异常信息，而是走此退路，以便用户有更好的体验

二. 每个微服务之间都有自己的ip端口等等信息，前端难道就要对每个微服务的ip端口熟悉吗？单体架构时我们只需要springmvc的拦截器完成一次用户登录、身份校验，就可以在所有业务中获取到用户信息，难道现在每个微服务都需要编写登录校验、用户信息获取的功能吗  ？

为了解决这个问题，我们引入了网关，网关可以给前端暴露一个ip和端口，前端只需要知道所有的请求往网关发送即可，无需关注我各个微服务的ip和端口，这样对前端用户来说，微服务整体项目就是一个黑盒，本身就是一个对微服务的保护

我们只需要在网关模块自定义权限过滤器，解析用户token，并且拿到用户id，再转发给相应的微服务，而我们需要在common模块为除网关之外的其他微服务编写一个springmvc拦截器，这时无需校验信息了，因为网关以及校验完成，只需要将网关携带的id放到自己的ThreadLocal中以便后续使用

谈到网关，不得不谈论路由配置信息，我们可以将所有路由信息放到nacos进行配置管理，并且编写动态路由加载器，一旦路由信息发生变化，那么网关就可以监听到路由信息，并且进行修改，无需重启服务，称为热更新

三.各个微服务怎么做服务保护？

引入Sentinel图形化界面便于进行服务保护

1.请求限流

限制或控制接口访问的并发流量，避免服务因流量激增而出现故障。

2.线程隔离

假设高并发情况下，购物车服务需要调用商品服务，然而商品服务出现了问题或者请求处理不过来，商品服务崩溃，然而大量请求仍然在购物车服务调用商品服务，就会耗尽购物车服务tomcat连接池的资源，导致级联崩溃，严重进而导致雪崩问题

我们可以把购物车业务中查询商品的部分隔离起来，限制可用的线程资源，防止因为商品服务崩溃导致级联崩溃，进而影响购物车模块其他功能

3.服务熔断

在某个微服务慢请求或者异常请求比例过高时，直接熔断服务，比如上述场景，商品服务慢请求或者异常请求比例过高，熔断商品服务，那么购物车服务的itemClient不再进行远程调用商品服务，直接走fallback，熔断时间结束后，尝试放行一次请求，看看能否正常响应，根据结果做不同的处理

四. 单体架构项目下，一个方法中多次调用数据库，我们直接加一个@Transactional注解即可保证事务的ACID原则

微服务架构下会相互调用服务，各服务会操作自己对应的数据库，这称为分布式事务
如何保证事务的acid原则？

引入Seata

seata提供XA模式和AT模式，由于这属于共享配置，写到nacos配置管理，各个服务自己去拉取即可，再程序中引入jar包，再使用seata提供的注解即可保证事务acid，要么全都成功，要么都回滚

五. OpenFeign的远程调用，调用者发起请求后需要等待服务提供者执行业务返回结果后，才能继续执行后面的业务。也就是说调用者在调用过程中处于阻塞状态，因此我们称这种调用方式为同步调用，也可以叫同步通讯

假设支付服务完成自己支付相关核心业务时，需要调用其他服务完成某些和自己不是那么相关的业务，并且很有可能扩展，越来越多这种不是很相关的业务

面对这种场景，我们就不要使用openfeign的同步调用了，我支付服务可能还要处理高并发的支付请求，不能说阻塞在这里等待这种其他服务完成这些业务，长时间等待，在高并发的情况下还有可能导致支付服务崩溃甚至引发雪崩，于是我们引入了Rabbitmq进行异步调用，支付服务只需要向其他服务发生消息即可，无需在这里阻塞等待，有更多时间来处理自己的核心业务，消息接收者也只需要监听消息并完成业务。

既然引入了mq，我们就要保证消息的可靠性，从三个角度出发

1.生产者（消息发送者）2.mq（中间人，用来存储消息并转发）3.消费者（消息接收者）

六. 海量数据的检索与查询，我们使用了ElasticSearch