前言

什么是分布式框架

分布式系统是若干独立系统的集合, 但是用户使用起来像是在使用一套系统.

为什么需要分布式系统

规模的逐步扩大和业务的复杂，单台计算机扛不住双十一那样的流量，俗话说：三个臭皮匠抵一个诸葛亮。

应用架构的发展演变

单一架构

当网站流量很小的时候,我们将所有的应用(业务)放到一台服务器上, 打包运行公司管理系统/超市收银系统.

优点: 开发简单,部署简单 缺点: 扩展不容易(怎么处理日益增长的流量),谁都改一个,维护不容易,性能提升难

垂直应用架构

将大应用拆分成为小应用(一般按照业务拆分),根据不同的访问频率决定各自业务部署的服务器数量

优点: 扩展容易 缺点: 页面一改, 可能造成整个项目重新部署, 业务和界面没有分离开, 随着业务种类增加, 怎么解决业务之间的互相调用问题, 订单服务器和用户服务器交互效率的问题

分布式架构

基于 RPC: 远程过程调用

将业务拆分后, 用某种方式实现各个业务模块的远程调用和复用, 这时一个好的 RPC 框架就决定了你的分布式架构的性能, 怎么调用, 何时调用, 服务器挂了怎么办......我们需要一个框架来帮我们解决这个问题(当然大大神可以自己写一个, 但是应对大流量的成功者莫过于中国的阿里巴巴公司, 顶住了淘宝双十一的流量, 反观一些学校内部的选课系统, 对于大流量时只有两个字--宕机).

这时, 我们本套课程的主人公就出现了: Dubbo, Dubbo 是一个高性能的 RPC 框架, 解决了分布式中的调用问题.

优点: 解决了分布式系统中互相调用的问题 缺点: 假设有 100 台服务器, 50 台用户业务服务器, 50 台订单业务服务器,但是在上线后发现, 用户服务器使用率很小, 但是订单服务器压力很大, 最佳配比应该是 1:4, 这时候就要求我们还有一个统一管理的调度中心

为什么 Dubbo 说自己性能高

高性能要从底层的原理说起，既然是一个 RPC 框架, 主要干的就是远程过程(方法)调用, 那么提升性能就要从最关键, 最耗时的两个方面入手: 序列化和网络通信.

序列化: 我们学习 Java 网络开发的时候知道, 本地的对象要在网络上传输, 必须要实现 Serializable 接口, 也就是必须序列化.

我们序列化的方案很多: xml, json, 二进制流…其中效率最高的就是二进制流(因为计算机就是二进制的). 然而 Dubbo 采用的就是效率最高的二进制.

网络通信: 不同于 HTTP 需要进行 7 步走(三次握手和四次挥手), Dubbo 采用 Socket 通信机制, 一步到位, 提升了通信效率, 并且可以建立长连接, 不用反复连接, 直接传输数据.

别的 RPC 框架

gRPC, Thrift, HSF ...

Dubbo 的前世今生

dubbo 之前一直都作为 Alibaba 公司内部使用的框架.

2011 年,dubbo 被托管到了 GitHub 上(开源)

2014 年 11 月发布 2.4.11 版本后宣布停止更新; 此后一段时间很多公司开源了自己基于 Dubbo 的变种版本(例如当当网的 Dubbo X,网易考拉的 Dubbo K)

2017 年 SpringCloud 横空出世, Dubbo 感觉到压力后连续更新了几个版本

2018 年 1 月,阿里公司联合当当网将 Dubbo 和 Dubbo X 合并,发布了 2.6 版本

2018 年除夕夜阿里将 Dubbo 贡献给了 Apache 基金会

2018 除夕夜至今,Apache 维护和更新 Dubbo