Dubbo(一)——初识Dubbo

一、前言

1. 什么是分布式框架
   分布式系统是若干独立系统的集合，但是用户使用起来像是在使用一套系统。
2. 为什么需要分布式系统
   规模的逐步扩大和业务的复杂，单台计算机扛不住双十一那样的流量，俗话说：三个臭皮匠抵一个诸葛亮
3. 应用架构的发展演变

• 单一架构
  当网站流量很小的时候，我们将所有的应用（业务）放到一台服务器上，打包运行公司管理系统/超市收银系统
  优点：开发简单，部署简单
  缺点：扩展不容易（怎么处理日益增长的流量），谁都改一个，维护不容易，性能提升难
• 垂直应用架构
  将大应用拆分成小应用（一般按照业务拆分），根据不同的访问频率决定各自业务部署的服务器数量。
  优点：扩展不容易
  缺点：页面一改，可能造成整个项目重新部署，业务和界面没有分离开，随着业务种类增加，怎么解决业务之间的互相调用问题，订单服务器和用户服务交互效率的问题。
• 分布式架构（基于RPC：远程过程调用）
  将业务拆分后，用某种方式实现各个业务模块的远程调用和复用，这时一个好的RPC框架就决定了你的分布式架构的性能，怎么调用，何时调用，服务器挂了怎么办…我们需要一个框架来帮我们解决这个问题。

二、初识Dubbo

1. 为什么Dubbo说自己性能高
   高性能要从底层的原理说起，既然是一个RPC框架，主要干的就是远程过程（方法）调用，那么提升性能就要从最关键、最耗时的两个方面入手：序列化和网络通信。

• 序列化：我们学习Java网络开发的时候知道，本地的对象要在网络上传输，必须要实现Serializable接口，也就是必须要序列化。我们序列化的方案很多：xml、json、二进制流…其中效率最高的就是二进制流（因为计算机就是二进制的）。然而Dubbo采用的就是效率最高的二进制。
• 网络通信： 不同于HTTP需要进行7步走（三次握手和四次挥手），Dubbo采用Socket通信机制，一步到位，提升了通信效率，并且可以建立长连接，不用反复连接，直接传输数据。

2. 别的RPC框架
   gRPC、Thrift、HSF、…
3. 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