简单聊一聊Dubbo

一、分布式系统

分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统，分布式系统（distributed system）是建立在网络之上的软件系统。

垂直应用架构

1. 做不到界面+业务逻辑实现分离
2. 应用不可能完全独立，大量的应用之间需要交互

分布式应用架构

1. 可以做到点后端分离
2. 应用之间的相互调用

二、RPC（远程过程调用）

什么叫RPC

RPC【Remote Procedure Call】是指远程过程调用，是一种进程间通信方式，他是一种技术的思想，而不是规范。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。

调用过程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bTYQ4ny5-1626053389052)(/Users/yuxiangrui/blog/source/picture/1.png)]

Dubbo中的序列化

1. Dubbo RPC是Dubbo体系最核心的一种高性能，高吞吐量的远程调用方式，可以称之为多路复用的TCP长连接调用
   • 长连接：避免了每次调用新建TCP连接，提高了调用的响应速度
   • 多路复用：单个TCP连接可以交替传输多个请求和响应的消息，降低了连接的等待闲置时间从而减少了同样并发数下的网络连接数，提高了系统吞吐量
   • Dubbo RPC 主要用于两个 Dubbo 系统之间的远程调用，特别适合高并发、小数据的互联网场景。而序列化对于远程调用的响应速度、吞吐量、网络带宽消耗等同样也起着至关重要的作用，是我们提升分布式系统性能的最关键因素之一。

Dubbo 中支持的序列化方式：

• dubbo 序列化：阿里尚未开发成熟的高效 java 序列化实现，阿里不建议在生产环境使用它

• hessian2 序列化：hessian 是一种跨语言的高效二进制序列化方式。但这里实际不是原生的hessian2 序列化，而是阿里修改过的 hessian lite，它是 dubbo RPC 默认启用的序列化方式

• json 序列化：目前有两种实现，一种是采用的阿里的 fastjson 库，另一种是采用 dubbo 中自己实现的简单 json 库，但其实现都不是特别成熟，而且 json 这种文本序列化性能一般不如上面两种二进制序列化。

• java 序列化：主要是采用 JDK 自带的 Java 序列化实现，性能很不理想。

  在通常情况下，这四种主要序列化方式的性能从上到下依次递减。对于 dubbo RPC 这种追求高性能的远程调用方式来说，实际上只有 1、2 两种高效序列化方式比较般配，而第 1 个 dubbo 序列化由于还不成熟，所以实际只剩下 2 可用，所以 dubbo RPC 默认采用 hessian2 序列化。

  但 hessian 是一个比较老的序列化实现了，而且它是跨语言的，所以不是单独针对 Java 进行优化的。而 dubbo RPC 实际上完全是一种 Java to Java 的远程调用，其实没有必要采用跨语言的序列化方式（当然肯定也不排斥跨语言的序列化）。

  最近几年，各种新的高效序列化方式层出不穷，不断刷新序列化性能的上限，最典型的包括：

• 专门针对 Java 语言的：Kryo，FST 等等

• 跨语言的：Protostuff，ProtoBuf，Thrift，Avro，MsgPack 等等
  这些序列化方式的性能多数都显著优于 hessian2（甚至包括尚未成熟的 dubbo 序列化）

  有鉴于此，我们为 dubbo 引入 Kryo 和 FST 这两种高效 Java 序列化实现，来逐步取代 hessian2。

  其中，Kryo 是一种非常成熟的序列化实现，已经在 Twitter、Groupon、Yahoo 以及多个著名开源项目（如 Hive、Storm）中广泛的使用。而 FST 是一种较新的序列化实现，目前还缺乏足够多的成熟使用案例。

吞吐量：吞吐量是指对网络、设备、端口、虚电路或其他设施，单位时间内成功地传送数据的数量（以比特、字节、分组等测量）。

在面向生产环境的应用中，目前更优先选择 Kryo。

Dubbo + Hystrix 实现服务熔断

熔断器简介

在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以通过 RPC 相互调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证 100% 可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet 容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩” 效应。

为了解决这个问题，业界提出了熔断器模型。

Netflix 开源了 Hystrix 组件，实现了熔断器模式，Spring Cloud 对这一组件进行了整合。在微服务架构中，一个请求需要调用多个服务是非常常见的，如下图：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2tTQwfGy-1626053389088)(https://www.funtl.com/assets/Lusifer201805292246007.png)]

较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值（Hystrix 是 5 秒 20 次） 熔断器将会被打开。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cGU5k9u5-1626053389091)(https://www.funtl.com/assets/Lusifer201805292246008.png)]
熔断器打开后，为了避免连锁故障，通过 fallback 方法可以直接返回一个固定值。