分布式解决方案（SpringCloud/Dubbo）

1、分布式架构想要高可用、高并发、高性能，会遇到什么问题？（4个） 

• 客户端如何访问这么多的服务？   API 网关
• 服务与服务之间如何通信？

        （1）同步通信

                HTTP（Apache HTTP Client）     RPC（Dubbo【JAVA】、Apache Thrift、gRPC）

        （2）异步通信

                消息队列（kafka、RabbitMQ、RocketMQ）

• 这么多服务，如何管理

        服务治理：服务注册与发现

                基于客户端的服务注册与发现：Apache Zookeeper

                基于服务端的服务注册与发现：Netflix Eureka

• 服务挂了怎么办

        重试机制、服务熔断、服务降级、服务限流

2、市面上的分布式解决方案有两种：

• SpringBoot  +  Spring Cloud
• SpringBoot  +  Dubbo  +  Zookeeper 

3、下面说明一下SpringCloud和Dobbo的区别 

3.1 SpringCloud与Dubbo的区别

两者都是现在主流的微服务框架，但却存在不少差异：

• 初始定位不同：SpringCloud定位为微服务架构下的一站式解决方案；Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用和治理
• 生态环境不同：SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。
• 调用方式：SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。
• 组件差异比较多，例如SpringCloud注册中心一般用Eureka，而Dubbo用的是Zookeeper

SpringCloud生态丰富，功能完善，更像是品牌机，Dubbo则相对灵活，可定制性强，更像是组装机。

相关资料：

SpringCloud：Spring公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案。

Dubbo：阿里巴巴开源的RPC框架，Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断

SpringCloudAlibaba

两者的生态对比：

Spring Cloud 的功能很明显比 Dubbo 更加强大，涵盖面更广，而且作为 Spring 的旗舰项目，它也能够与 Spring Framework、Spring Boot、Spring Data、Spring Batch 等其他 Spring 项目完美融合，这些对于微服务而言是至关重要的。

使用 Dubbo 构建的微服务架构就像组装电脑，各环节选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果使用者是一名高手，那这些都不是问题。

而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础原理有足够的了解。

3.2 dubbo和Feign远程调用的差异

Feign是SpringCloud中的远程调用方式，基于成熟Http协议，所有接口都采用Rest风格。因此接口规范更统一，而且只要符合规范，实现接口的微服务可以采用任意语言或技术开发。但受限于http协议本身的特点，请求和响应格式臃肿，其通信效率相对会差一些。

Dubbo框架默认采用Dubbo自定义通信协议，与Http协议一样底层都是TCP通信。但是Dubbo协议自定义了Java数据序列化和反序列化方式、数据传输格式，因此Dubbo在数据传输性能上会比Http协议要好一些。

不过这种性能差异除非是达极高的并发量级，否则无需过多考虑。

相关资料：

Dubbo采用自定义的Dubbo协议实现远程通信，是一种典型的RPC调用方案，而SpringCloud中使用的Feign是基于Rest风格的调用方式。

1）Rest风格

REST是一种架构风格，指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。

Rest的风格可以完全通过HTTP协议实现，使用 HTTP 协议处理数据通信。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。

因此请求和想要过程只要遵循http协议即可，更加灵活

SpringCloud中的Feign就是Rest风格的调用方式。

2）RPC

Remote Procedure Call，远程过程调用，就是像调用本地方法一样调用远程方法。
RPC一般要确定下面几件事情：

• 数据传输方式：多数RPC框架选择TCP作为传输协议，性能比较好。
• 数据传输内容：请求方需要告知需要调用的函数的名称、参数、等信息。
• 序列化方式：客户端和服务端交互时将参数或结果转化为字节流在网络中传输，那么数据转化为字节流的或者将字节流转换成能读取的固定格式时就需要进行序列化和反序列化

因为有序列化和反序列化的需求，因此对数据传输格式有严格要求，不如Http灵活

Dubbo协议就是RPC的典型代表。

我们看看Dubbo协议和Feign的调用区别：

3.3  Eureka和Zookeeper注册中心的区别

SpringCloud和Dubbo都支持多种注册中心，不过目前主流来看SpringCloud用Eureka较多，Dubbo则以Zookeeper为主。两者存在较大的差异：

• 从集群设计来看：Eureka集群各节点平等，没有主从关系，因此可能出现数据不一致情况；ZK为了满足一致性，必须包含主从关系，一主多从。集群无主时，不对外提供服务
• CAP原则来看：Eureka满足AP原则，为了保证整个服务可用性，牺牲了集群数据的一致性；而Zookeeper满足CP原则，为了保证各节点数据一致性，牺牲了整个服务的可用性。
• 服务拉取方式来看：Eureka采用的是服务主动拉取策略，消费者按照固定频率（默认30秒）去Eureka拉取服务并缓存在本地；ZK中的消费者首次启动到ZK订阅自己需要的服务信息，并缓存在本地。然后监听服务列表变化，以后服务变更ZK会推送给消费者。

3.4  SpringCloud中的常用组件有哪些？

Spring Cloud的子项目很多，比较常见的都是Netflix开源的组件：

• Spring Cloud Config
• 集中配置管理工具，分布式系统中统一的外部配置管理，默认使用Git来存储配置，可以支持客户端配置的刷新及加密、解密操作。
• Spring Cloud Netflix
• Netflix OSS 开源组件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件。

1. Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；
2. Ribbon：负载均衡的服务调用组件，具有多种负载均衡调用策略；
3. Hystrix：服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力；
4. Feign：基于Ribbon和Hystrix的声明式服务调用组件；
5. Zuul：API网关组件，对请求提供路由及过滤功能。

• Spring Cloud Bus            用于传播集群状态变化的消息总线，使用轻量级消息代理链接分布式系统中的节点，可以用来动态刷新集群中的服务配置。
• Spring Cloud Consul       基于Hashicorp Consul的服务治理组件。
• Spring Cloud Security      安全工具包，对Zuul代理中的负载均衡OAuth2客户端及登录认证进行支持。
• Spring Cloud Sleuth        Spring Cloud应用程序的分布式请求链路跟踪，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟踪。
• Spring Cloud Stream        轻量级事件驱动微服务框架，可以使用简单的声明式模型来发送及接收消息，主要实现为Apache Kafka及RabbitMQ。
• Spring Cloud Task            用于快速构建短暂、有限数据处理任务的微服务框架，用于向应用中添加功能性和非功能性的特性。
• Spring Cloud Zookeeper         基于Apache Zookeeper的服务治理组件。
• Spring Cloud Gateway             API网关组件，对请求提供路由及过滤功能。
• Spring Cloud OpenFeign          基于Ribbon和Hystrix的声明式服务调用组件，可以动态创建基于Spring MVC注解的接口实现用于服务调用，在Spring Cloud 2.0中已经取代Feign成为了一等公民。

3.5  微服务调用关系复杂，如何做监控和错误排查？

企业中对于微服务监控有一套东西，叫做APM。比如：SpringCloudSeluth+Zipkin，Pinpoint、Skywalking，可以实现性能监控、链路跟踪（精确到某个代码，某条sql）、CPU运行情况，链路运行耗时。

当然， 还可以借助于分布式日志管理系统。把项目运行的日志收集，形成统计报表，放入elasticsearch，便于搜索查看。比如：ELK技术栈、GrayLog

3.6  Hystix的作用是什么？

Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。比较常用的手段就是线程隔离和服务熔断。

第三节原文链接：https://blog.csdn.net/weixin_51291483/article/details/109212137

4、下面介绍Dubbo+Zookeeper的解决方案

我们重新回顾一下分布式架构遇到的4个问题：然后看看在Dubbo+Zookeeper中是通过什么样的机制或组件来解决的。

• 客户端如何访问这么多的服务？   API 网关
• 服务与服务之间如何通信？          Dubbo基于Netty的通信框架解决、Kryo实现告诉的序列化
• 这么多服务，如何管理                 通过Zookeeper的服务注册与发现，Dubbo Admin管理台
• 挂了怎么办                                   Hystrix实现服务的熔断

下面我们可以展开分别讲讲：

• 0、使用ZooKeeper实现服务的注册与发现，Dubbo Admin管理后台

        Zookeeper一般用作两个事情：

        （1）、实现的分布式锁来解决分布式中多个进程（服务）之间的同步控制，使其有序的访问某些临界资源，而在单体应用并发中需要的是多个线程之间的同步控制，可以用锁或者同步代码块来实现，所以可知分布式锁控制的是进程，和线程无关。分布式锁可以看另一篇文章

        （2）、服务的注册与发现

        （3）、Dubbo OPS或者Dubbo Admin管理后台，下载之后部署Dubbo OPS，进入管理端

 

• 1、Dubbo使用Kryo实现高速的序列化（二进制序列化或者JSON序列化）

        Dubbo RPC是Dubbo体系中最核心的一种高性能、高吞吐量的远程过程调用方式，可以称之为多路复用的TCP长连接调用。长连接：避免每次新建TCP连接（3次握手、4次挥手），提高调用响应速度。在众多的序列化和反序列化工具中，Kryo是专门针对Java的高速序列化工具。

• 2、Dubbo使用Hystrix实现服务的熔断

        Hystrix是SpringCloud中的一个熔断机制的组件，熔断器应用的颗粒度是方法，可以应用在所有的方法中，直接在方法上加注解即可，在注解中可以配置熔断阀值。当出现配置下的熔断场景时，请求会执行进入到重写的熔断函数（在此函数中可以直接返回提示信息），这样整个分布式服务就不会持续堵塞在一个地方导致整个服务发生问题，后续排查解决即可，并且可以通过熔断器仪表盘来查跟踪监控某一处熔断的发生情况。

• 3、Dubbo可以支持负载均衡，支持各个粒度的负载均衡，包括方法、服务、实例的负载均衡