02、尚硅谷_Dubbo_概念_应用的架构演变.avi原创

好，前面呢，我们说了一下分布式的定义，接下来呢，我们来看一下我们应用架构的发展演变，这呢有一张非常经典的图来自于我们double的官网，它解释了我们整个应用架构的一个发展路线图，如何从一个单一的小型应用变成一个分布式的大型应用。首先呢，我们来看第一阶段，哎，我们叫单一的应用架构，也就是说当我们网站的流量很小，访问量很少的时候，我们只需要呢一个应用，将这些所有的功能呢，我们都放在这个应用中，将整个应用呢打包部署，放在服务器上对外提供服务就行了，比如我们公司的一些管理系统，或者呢，我们超市的一些收银系统，一些小型的网站应用等等等等，那我们来举一个例子，那我们呢，有一个小型的购物网站，好，它呢只给少量的人来提供服务，流量很小，那比如网站里边呢，有非常多的功能，有跟用户相关的功能，有和咱们这个订单相关的功能。

也有和我们这个商品相关的功能，由于我们这个网站呢，访问量还是很小的，我们没必要把它做成一个大型的分布式应用，所以呢，我可以将所有的功能都放在一个应用里边，我们将这个整个应用呢，我们可以打包部署，放在我们的服务器里边，哎，我来画一个服务器，这样呢，开发简单，我们部署呢也简单，我们只需要将应用打包给服务器上一塞就行了。接着说呢，某一天我们这个访问量有点大，一个服务器呢受不了了，那我们可以再来一个服务器，哎，同样都来跑这个应用，两个服务器呢一起来分担流量压力，那么第一个第二个合起来，那我们也能提供大量的服务，但是呢，单一应用它会带来一些缺点，比如第一个问题就是我们扩展不容易，我们要对应用里边某一个功能修改。或者。

啊，添加某一个功能都会呢，导致我们要把整个应用重新打包，重新放在这些服务器上，哎，这可能还有多台，所以呢，我们这个扩展不容易，第二个呢，我们这个协同开发也不容易，大家都去改这一个应用，有可能会改乱，哎，不利于我们的维护。而且呢，当我们应用的规模不断扩大，比如我们以前的应用只有10MB，我们应用不断的扩大到了500MB，那还是单体应用放在一个服务器里边，那么单台服务器跑这么大的程序，压力也是很大的，光靠增加每一个服务器，每一个服务器已经不能带来性能上的极大提升了，那么接下来我们就应该重新考虑一下我们应用的架构方式，那么我们可以来到第二阶段，我们叫垂直的应用架构，这种架应用架构呢，我们可以将刚才那个大的一个单体的应用我们拆成。

几个互不相干的小应用，这小应用呢，独立部署到每一个服务器上，哎，哪一个小应用功能啊，要增加了，我们只改这个小应用，包括呢，这个小应用啊，流量很大了，我们把它多放在几台服务器上，就像是这样，我们将刚才的那个大应用拆成了三个独立的小应用，而且呢，每一个应用呢，都是从头到尾完整的，从页面到我们的业务逻辑程序到我们的数据库，哎，都是完整的。当某一块的应用访问量比较大，比如用户经常访问这个应用，那我们把这个应用呢多放几台，哎，我们经常的商品访问量也比较大，那商品呢，我们也可以多放几台，这样做的好处呢也有很多，第一个我们分工合作很容易，每一个人呢，负责开发和维护不同的应用，这样呢就互不干扰。

第二个我们这个性能扩展也是很容易的，比如我们这个用户，这个应用它的访问量增大了，我们就把它呢多放上几台服务器，哎，三五台服务器一起来跑，那这个扩展呢是非常容易的，不像是之前一扩展呢，都是带着整个应用扩展，然后我们这个只是一个小应用，想要扩展哪一部分，只来扩展这一个应用就行了，哎其他的呢可以不用动，但是呢，即使是这样架构也是有一些缺点的，诶比如呢，我们来说第一个我们每一个应用呢，它从头到尾都是完整的，包含界面，包含业务逻辑，包含数据库等等，但是呢，我们市场上对界面的要求会经常发生变化，美工呢天天会改这些页面，一个页面一改都可能导致我们整个应用呢，要重新部署，也就说呢，现在没法做到第一个。

我们这个界面和我们这个业务逻辑的实现，我们要分离开，要不然的话呢，我们界面可能天天在美化，天天在改，我们难道一改就要把整个应用部署起来吗？这是第一个问题，第二个问题，我们应用呢，后来也会逐步的增多，我们垂直应用会越来越多，还有用户模块，订单模块，商品模块，可能还有我们继续来到支付，我们支付模块包括有物流模块等等等等。那么这样子情况下呢，我们不可能完全理想化的应用跟应用之间会互相独立，那我们呢，订单可能要用到用户，诶我们要创建订单的时候呢，我们要查询用户的一些信息，哎，我们订单呢要用到用户，包括呢，我们订单呢还要用到一些商品的信息。

包含呢，我们这个物流支付可能要用一些订单的内容，包括呢，我们物流可可能要看一些订单的信息等等等等，我们会发现我们这个应用之间他们可能也会交互的，那应用不可能，哎，应用不可能我们完全独立，独立我们应用之间，大量的应用之间应用。之间需要交互，那接下来怎么办呢？哎，我们可以采取分布式的服务架构，当我们这个垂直应用呢，越来越多，因为之间还想要交互，我们呢就可以把它们的核心业务单独抽取出来，比如像是这样，哎，我将我们之前的这个用户应用，我抽取成了用户的界面，哎这个web界面和这个用户的我们核心业务逻辑每一个呢都一样，订单的界面和订单的业务逻辑，商品的界面和商品的业逻辑等等等等，那这样做的好处是什么呢？哎，当我们业务逻辑不变的情况下，如果我们只想改界面，那我们就把这个界面一改，那么界面的这个服务器呢，可以重新启动一下，我们核心的业务逻辑还在其他的服务器上，那么比如我们这个用户界面，哎，它要展示我们这个用户。

信息，包括他还要查出一些订单，查出一些商品，那就去调其他服务器的各个业务就行了，包括业务之间也可能需要糊掉，哎，我们这个用户的业务要调我们商品的，商品的要调订单的等等等等等等，但是呢，现在还有一个最大的问题，什么问题呢？我们这个用户的web可能在A服务器上，用户的业务呢，可能我们放在B服务器上，订单呢，我们放在C服务器上，De，那我们如果A服务器要去来调B服务器的功能，如果我们以前写在一个应用里边，A调B，那直接方法A调B的方法，我们直接调用就行了，我们这我们叫进程内通讯，哎，因为他们都在一个服务器上，都是同一个他们开的同一个进程内通讯，但是呢，我们现在发现A跟B已经分割异地了，它在两处了。这两。

当初我们代码之间如何互调呢？我们把这个调用我们称为RPCRPC的全称呢，我们叫远程过程调用，后来呢，我们还会仔细的来去说它，我们先在这儿呢，来给大家把这个概念来解释一下，叫远程过程调用，也要说啊，分布式服务的这个架构下，最核心的难点就是如何进行远程过程调用，以及如何拆分业务，提升我们业务的复用程度，那么此时呢，一个好的分布式服务框架，分布式服务框架也就是来帮我们来解决远程过程调用的这个框架，就能极大的简化我们的开发，那这样的架构是不是就高枕无忧呢？来我们来说，后来随着我们业务不断的增多，我们分拆的服务呢也越来。

越多有成千上万的服务器再来跑各种不同的服务，而出现的一些资源浪费情况就尤为严重，比如我们这个用户业务这一块呢，我们这个访问量比较小，结果呢，它有100台服务器在跑，而我们的商品业务它的访问量比较大，却呢只有十台服务器在跑，那我们呢，就应该有一个能基于我们访问压力的这个调度中心，能帮我们实时的来监控这些数据，来动态的调度，提高我们这个资源的利用率。诶，你跑的服务器有点多了，我们来捡上几台，让更多的服务器呢去来跑业务量更大的这些业务，这个时候呢，我们就可以采用我们说的流动计算架构，我们引入我们这个调度中心，他呢负责维护我们这些服务之间的复杂关系，以及实时管理。我们整个服。

服集群，比如说A服务器访问量大了，我给A多来几台，哎，我们动态的多来几台，而且呢，假设这么几台，第一台呢有100个请求，第二台呢有两个请求，第三台呢有1万个请求，那么下一次请求进来呢，我们就应该找比较闲的服务器，我们来处理请求，以此来提高我们整个服务的利用率，这儿就是我们整个应用架构的一个发展路线图，架构的变化必然也会引起很多技术的兴起，我们分布式架构下呢，也会有非常多的集数，我们后来呢一点一点的去来探索。