Spring Cloud是一套微服务生态---完整的解决方案，Dubbo只是一个远程调用的框架

Dubbo有一个自定义的通信协议，效率是高很多的，但是一般服务之间的调用就正HTTP调用页无伤大雅

1. 网关gateway

权限校验、限流、路由分发、负载均衡

2. 注册中心(Nacos，consul,eureka)

生产者和消费者通过注册中心来相互调用，里面注册了每个服务的信息，只是起到一个信息交互的作用。消费者有一个自己的额本地消息缓存，比卖你经常性的去注册中心调用，增加RPC调用的消耗

ZK能承受的并发能力相对较低

微服务组件 分布式（一种设计思想，需要考虑CAP理论，Base理论）

• 分布式id
• 分布式事务
• 分布式链路追踪
• 分布式数据库

分布式

MVC分层架构，Spring MVC----MVC思想通过spring的一个实现

• M:Model---模型层

模型层主要是做一个数据的转化，一般业务接口都是基于数据库进行将开发的。实体跟数据库表是一一对应的，如果数据库中的字段全部返回给前端，是有一定的危险性的，为了避免一些敏感的字段被前端看到，比如ID,CODE.....因此会做一些模型的转化。因此游客业务中常见的PO,BO,VO,DTO.这个过程还需要进行业务逻辑的处理，因此延伸出了Service层,DAO层

- dao层对数据库的一个查询通过 ORM或者JDBC也好，将数据库查询出来交给service层
- service层中在业务比较复杂的时候，也会完成一些结构模型的转化比如：DTO--VO的转化

• V:视图层（一般在前后端分离架构中，由前端进行开发）
• C:Controller层---控制层（负责业务请求的路由）

通过@RequestBody,@ResponseBody接受请求体,响应体返回出去

单体问题：

耦合度比较高，某个模块失效导致整个模块出现问题

分布式/微服务

大的单体项目拆分成多个子模块/子系统，之间通过中间件或者某种组件继续进行关联实现整合，在逻辑上是一个整体，但是在物理层面是有多个子服务的。人员分组，降低耦合度，减少开发的成本

Spring cloud其实就是给我们提供的一个分布式框架，提供一些组件帮我们解决分布式中遇到问题，比如说网络延迟怎么办，服务之间怎么调用的，服务的注册与发现

服务的注册与发现

公共管理各个服务的端口，ip。屏蔽掉一些底层实现.Eureka(Spring cloud),Nacos(Springcloud Alibaba)

负载均衡-Ribbon/与Nginx

将负载请求交给具体的模块去管理

• Nginx

服务端的负载均衡，在请求的时候直接发请求，先打到Nginx再有Nginx通过负载均衡的一些算法，负载均衡到服务器上

• Ribbon

客户端负载均衡，从注册中心拿到请求之后，就知道了选择哪个服务端实例，我们是有目的性的请求，在发送请求之前就通过Ribbon负载均衡器确定好了要选择哪一个，将请求打到某个服务器

服务端的时候就是先发请求再均衡，客户端的话就是先均衡再发请求

远程调用RPC------Feign/OpenFegin

请求调用的方式也抽象组件化,就不需要调用HTTP请求了，fegin/openFegin可以通过动态代理的方式，反射，实现目标接口不用考虑方法实现。在接口上面添加@OpenFeign注解就可以，我们实现目标接口，不用谢具体的方法实现，openFeign根据动态代理的机制构建代理调用，简化了请求处理的过程。

雪崩效应

• 服务的熔断与降级
• 快速失败机制

把服务的调用失败给提前,比如服务被堵塞了，设置一个服务超时时间，5s内请求未被返回就返回错误信息，提前暴露问题

• 降级FallBack函数，超时之后直接调用FallBack兜底

适用于高并发的场景

可用性，限流 令牌桶算法，漏桶算法，滑动窗口算法

配置中心Nacos

把配置文件进行统一的管理

网关Gateway

把请求路由到对应的微服务 统一鉴权，限流，缓存，控制幂等性