Dubbo基础专题——第一章（带你认识Dubbo）

前言：刚完成的Spring基础专题本想更新源码的，但是发现分布式非常火，而我喜欢玩这个，所以今年我希望把我的知识可以分享给正在奋斗中的互联网开发人员，以及未来想往架构师上走的道友们我们一起进步，从一个互联网职场小白到一个沪漂湿人，一路让我知道分享是一件多么重要的事情，总之不对的地方，多多指出，我们一起徜徉代码的海洋！
 
我这里做每个章节去说的前提，不是一定很标准的套用一些官方名词，目的是为了让大家可以理解更加清楚，如果形容的不恰当，可以留言出来，万分感激！

1、基础知识

1.1、分布式基础理论

互联网业内，不少人口中经常喜欢说，分布式系统，CAP理论，包括大厂中对于面试，实战，都会注重这方面的筛选，考核。那本章开始，真正带你走进分布式的世界，为什么要有分布式的存在，和我们目前主流的微服务之间，又有什么关系呢？

我先引经据典《分布式系统原理与范型》对于分布式的定义：

分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统。

首先，是若干个独立计算机，其次，对于用户来说，他在使用这个系统，就感觉像单个完整系统一样正常运行！

比如我们在用京东商城完成了你的购物需求，对于你来说你体验到了一个完整的京东商城系统，实际上京东商城后台有成千上万台独立的计算机，为我们提供服务，而这些计算机或者服务器，完整的构成了一整个京东商城系统！

为什么要有分布式系统呢？

实际上随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，于是想着，这么多的功能，模块，我是不是都可以单独拆出去作为一台计算机，去独立的提供自己的服务？通过服务之间的调用关系，是不是也可以用某些技术手段，来

进行统一的维护，治理这些偌大的服务模块呢？于是诞生了很多主流框架，比如本章的Dubbo，还有SpringCloud生态体系，SpringCloud Alibaba体系。所以分布式服务架构以及流动计算架构一定是当下的主流，亟需一个治理系统确保架构有条不紊的演进和

迭代发展！

1.2、发展的演变

上面我们提到垂直应用架构，这里我带你看看发展过程。

我先截个完整的发展图，再和你细分下过程！这张图来自Dubbo的官网，感兴趣可以看看。但是我觉得你一定不会去看官网的！

最开始，网站很小的时候，只需一个应用，就可以将所有功能（比如订单，商品，支付，用户，搜索等）都部署在一台服务器上，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键——形成单体应用架构

这个时候流量是没这么多的，而且这个产品也不大，互联网这个噱头早期的时候发展不明显，用户量非常小，单一的单体应用架构足以满足需求。

但是随着用户量增大，需求不断增加，要有更多的人来迭代这个产品，发展这个系统，从一个阿里的单体淘宝，再牛逼的服务器，一台肯定扛不住啊，那有人说搞多台（水平应用架构），就是一台A上面部署一整个完整的系统，A撑不住了，那就复制出来成为

B，B和A一毛一样，也是具有所有的功能模块，好了可以解决一些压力了，但是我今天要开始更新功能了，首先把A服务要停掉，更新个包上去，我只修改了订单功能，但是我整个项目要停了重启，也就意味着这段时间用户用不了，接着A好了，再替换B，替

换C等等，还有一点，你开发，我也开发，你开发商品，我开发订单，我要等你开发完了我的功能才能一起打包部署，极大的浪费彼此的时间，很多小公司会有“捆绑式加班”，你功能完了之后，等我写完了一起测，没问题了，你再走，哈哈！~

马总开始觉得，这个用户上来的话，开始扛不住了，成本啥的很高啊，离职率也....

缺点也暴露出来：

• 功能扩展比较难，单体的项目会越来越大，从几百兆会到几个G...
• 性能无法保证，一个几十兆的项目到几百兆甚至上G，你说启动要多久？一台服务器再好跑你的系统，cpu内存io，也扛不住啊。
• 协同开发问题，我开发好了，凭啥不能下班回家，非要等你写完一起打包测？
• 不利于升级维护，一个一个停服务，启服务，运维每次加班都是干这个事情，用户一会可以用，一会用不了，开发头发都干秃了...

于是演变成了垂直应用架构

访问量逐渐增大，单一应用增加机器带来的加速度会越来越小，这个时候，马爸爸要告诉下面的大牛们，你们要改下，这撑不住啊，于是大佬们开始将应用拆成互不相干的几个应用，分别部署在不同的服务器上，以提升效率。此时，用于加速前端页面开发的

Web框架(MVC)是关键。

订单拆出去，在一台服务器上，用户系统拆出去，也在一台服务器上，商品系统也是一样拆出去。所以这个称为垂直应用架构。

，

这个时候解决了单体，水平的局限性，如果订单访问量比较大，我可以把订单服务抽出来单独用一台服务器跑，或者多搞几台也是一样。对于用户系统，也是高频率使用，用户系统我也多做几台服务器，对于一些使用量不大的服务，那么我可以用很少的服务

器，来支撑这个服务的运行！！

所以上面的问题基本都可以得到比较好的解决：