menu ChaYedan
浅谈应用框架演进
516 浏览 | 2020-04-25 | 阅读时间: 约 5 分钟 | 分类: Java | 标签: 框架
请注意,本文编写于 887 天前,最后修改于 887 天前,其中某些信息可能已经过时。

背景

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

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

单一应用架构

当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(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

知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议

发表评论

email
web

全部评论 (暂无评论)

info 还没有任何评论,快来留言吧!