浅谈应用框架演进

浅谈应用框架演进

原文地址：浅谈应用框架演进

背景

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

上图就展示了发展的四个阶段，分别是单一应用架构，垂直应用架构，分布式服务架构，流动计算架构。下面就浅谈一下自己对于这四个阶段的理解。

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

这种架构的优点就是小以及部署方便。如果网站的并发量并不是很大，那么可以通过多部署几台服务器来分摊并发压力。但随着网站逐渐做大以后，单一的增加服务器带来的效果式微，这时候就需要更换架构来提高效率。

如果不好理解就那饭店来做例子

单一应用架构就像开了一家小饭店，但小饭店就那么大，只有十张桌子和两个厨子（一个厨子只能应付五张桌子，一张桌子只能坐一个人），在桌子没坐满之前饭店能正常运转。但饭店味道很好，饭钱也便宜，回头客很多，饭店一到饭点，来了几十张桌子的人，这时候饭店的服务就炸了。老板就需要另外想办法来满足来吃饭客户的需求，于是就把旁边店给买下来扩张成了二十张桌子和四个厨子。但过了段时间，还是不够，每天来吃饭的有几百张桌子的人，这种单纯的增加桌子的方法就效果越来越低效了（10张桌子变20张桌子，效率提高一倍 。二十张变三十张效率提高一半，随着本身拥有的桌子越多，每次提高的效率就越低）。

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

也就是将我们的服务分拆。比如将注册相关的业务，下单的业务，商品展示的业务分成三个工程。那么这样每个业务之间彼此独立，哪个业务需要的资源多，我们就把相对多的资源分配给这项业务，这样就能保证我们整个业务的正常运行。

接着上面的例子

这时候老板就想啊，我前台有三十张桌子，后厨现在有六个厨子，但人一多，店就炸锅了。但我每加十张桌子和两个厨子越到后面提升的效率越低，要怎么提升才最经济最好呢。于是想了几天几夜后，老板突然得到天启。老板一翻点菜流水，发现客人会点荤菜和素菜的比例大概是一比二（这里的客人饭量小，每个人都只点一份菜）。于是老板就把厨子分为两批，四个的厨子做素菜，两个的厨子做荤菜。这样，就算后来客人人数没变但口味变化了。比如说后面客人口味变化了，点荤素菜的比例变为了一比五。那么我可以把六个厨子分配成五个厨子做素菜，一个厨子做荤菜。再比如后面的客人人数增加了，而且发现增加的客人都喜欢点素菜，那么我就直接增加做素菜的厨子即可。

但这里就会有一个问题，也就是业务冗余。比如说我现在将整个工程分为了用户业务，订单业务，登录业务。其中订单业务和登录业务都需要去调用用户业务，那么其实对订单业务和登录业务来说，就存在冗余。

就比如一道菜，土豆炒肉丝。荤素都有，那么既需要我素菜的厨子来炒土豆丝还要会炒肉丝，我荤菜的厨子来炒肉丝还要会炒土豆丝，这就是冗余。

总的来说，我觉得我举饭店的例子有点不太好，但是我想表达的意思就是单一的增加机器是整体的增加，有些我不需要的服务也是在增加的，但垂直应用架构更灵活，缺什么补什么。

这里是我觉得写得不错的一篇文章，我觉得解释得不错，划个重点，其实应用服务是分类别的，有些服务是计算密集型的，有些服务是IO密集型，所以我们需要垂直应用架构来分层。但总体来说，硬件还是硬通货，如果我们不分层，就需要同时满足IO密集型和计算密集型的需求，这对于企业来说，大大的增加了成本。

https://blog.csdn.net/weixin_33446857/article/details/104170471

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

具体来讲，就是我们将前端和后端进行分离。在垂直应用架构中，我们已经将服务进行了分离，但是对于单个服务来讲，前后端还是在一体的，有些服务还是会用到另外的服务的一些东西造成冗余。那么我们现在就将单个服务的前后端进行了分离。就像背景里那张图的RPC那样。蓝色代表前端，绿色代表后端。那么现在要解决的一个问题就是远程调用的问题。因为我将业务进行了拆分，那么我该如何从一个服务调用另外一个服务呢？

就比如说我把用户的服务进行了拆分，把用户的Web层部署在杭州的一台机器上，把用户的Service和Dao部署到北京的一台机器上，那么这个时候，我用户的Web层该怎么去调用用户的Service和Dao呢？

这就需要我们的分布式服务框架(RPC)了，中间由RPC来管理，Service和Dao的工程注册到RPC框架中，Web层需要时，就由RPC框架来调用即可。

RPC的介绍

流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

简单来说，现在就是有了一个交警，站在马路中间来给你疏通拥塞的车流。因为随着我们服务越做越大，RPC就会显得混乱不堪，所以我们需要SOA来进行统一的协调。

你也可以简单的理解为，在分布式服务架构上加了一个治理者来分配资源和调度服务

SOA