水分计厂家
免费服务热线

Free service

hotline

010-00000000
水分计厂家
热门搜索:
技术资讯
当前位置:首页 > 技术资讯

云端上的规模可扩充性

发布时间:2020-07-21 18:36:45 阅读: 来源:水分计厂家

想要获得云端动态而灵活的规模扩充性,并非只是把系统放到云上执行就能得到预期效益,应用程式执行的方式,可能也必须有所调整

在前文中我们谈到所谓的「规模可扩充性(scalability)」,一个系统有没有规模可扩充性,我们看的并不是单一计算节点上跑多快,而是当你增加计算资源(例如机器、频宽)时,能否通过增加计算资源,来换取更大规模的处理能力。

当在解决大型规模的计算问题时,人们关心能否通过增加伺服器、频宽、储存空间的方法,来服务更大规模的用量,更胜于在单一伺服器上可以执行多快。

要得到规模可扩充性,并不是一件容易的事情,但如果可以从平台本身获得支持,包括计算能力及资料存取等,对应用程式来说,会简单许多。而这也正是一些所谓「云端计算平台」的作用所在。

另一方面,我们谈到了「云端计算平台」,并不是建构在「云端计算平台」上的应用程式,就必然具备规模可扩充性。

例如,对于应用程式来说,它有可能是建构在IaaS(Infrastructure as a Service)的层次之上,或者,也可能是在PaaS(Platform as a Service)层次上所发展的。

通常,建立在IaaS上的应用程式,无法直接得到规模可扩充性,平台通常可以提供的部分,只是「依用量可随时动态弹性配置的资源」。就像在AWS的EC2上运行应用程式,并不能保证应用程式的规模可扩充性,充其量,只能在你需要伺服器、频宽、储存空间时,EC2能够尽可能地动态满足你的需要。

所以说,并不是把应用程式搬上了「云端」,就必然获得了规模可扩充性,当你只是在 IaaS 平台上开发时,是否具备规模可扩充性,仍旧取决于你的系统架构及特性。

不过,当你是在PaaS上开发时,情况又有所不同。PaaS平台本身,会处理掉许多和规模可扩充性相关的问题,就像是在Google的App Engine上面,它所提供的资料存取操作,就不同于传统的关联式资料库,而是以BigTable 为基础的操作模式,这使得它有能力处理海量资料的存取。而立足在App Engine之上的应用程式,自然而然,具备着更好的规模可扩充性。

因此,在一个专门为了更大规模而设计的平台上开发,对于想要得到规模可扩充性的应用程式开发者来说,可以省去不少的力气。其中像 Hadoop 便是一个为了大规模计算而设计出来的平台,其中,利用所谓MapReduce的计算方式,可以将计算量分散到各个能提供计算的机器之上,集合众多机器之力,因而在更短的时间内,解决想要解决的计算问题。而且,可以弹性投入所能配置的资源数量,投入的愈多,解决的愈快。例如,动用更多的伺服器,就能更快的解决计算问题。倘若预算不那么充分,也可以使用较少的机器,但耗费较多的时间,而这正是规模可扩充性的意义所在。

分散式计算的迷思

虽然说,分散式计算的目的之一,就是希望通过将计算量分散到多部、不同的机器上,来增加整体的计算能力,但是,并不是所有的应用程式都可以轻易拆散到多部机器之上去运行,而且更重要的是,并不是将应用程式拆分到多部机器之上,就必然带来整体计算量的提升。

举例来说,倘若你将你的应用程式拆成多份,并且同时传输至多部机器之上执行,而这几个程式之间需要沟通,也就是交换资料,它们之间甚至需要做同步(synchronization),以致于不同机器上的程式之间需要等待特定工作的完成,接着才能继续执行,那么,这样的应用程式就不见得具有规模可扩充性,因为,等待的环节,会造成规模无法随着计算资源投入而跟着成长的因素。

这说明了,即使试着将计算拆分成为多份,并且置于多部机器上执行,也不见得可以获得多倍的效能改进,很可能因为计算模式的特性所限,而仅能获得少数的效能成长,而且随着规模愈大,成长的比例愈低。因此,如何拆分计算工作,使得它们被散布到多部不同的机器后,可以得到对应的计算规模提升,就成了这件事情的核心议题。

通过分而治之的方式,将大问题拆开许多个小问题,个个击破,降低解决问题的难度

像Hadoop的MapReduce,就是一种拆分计算工作的方式。想要通过拆分工作来解决计算问题,传统的「分而治之(Divide and Conquer)」其实,就是一种可行的方式。所谓的「分而治之」,就是将一个大问题,拆解成多个小问题,而分别解决这些小问题的答案之后,再将这些答案通过某种方式合并起来,就可以得到大问题的答案。这种方式常常可以递回为之,也就是拆成比较小的问题之后,还可以接着再继续拆解,直到拆解至适合解决问题的规模为止。

如果,我们可以运用「分而治之」的方式来解决问题,就很容易得到规模可扩充性,因为,我们可以将原始的问题拆解成若干个较小规模的问题,然后把这些问题分别置放在不同的机器上解决,因为解决这些小问题的计算是互相独立的、它们之间也不需要沟通,所以,当可运用的机器数量变多时,就可以将问题的规模拆解的更小,使得在单一机器上解决它们的速度更快,更使得整体解决它们的时间可以缩短。而 MapReduce 正是此种「分而治之」的解题计算模式,当你运用MapReduce时,便得以此种方式来思考解决问题的方法。

函数式程式设计开始流行

在另一方面来看,你可能也会发现到,所谓「函数式(functional)」的程式设计方式,在这种「分而治之」的分散式计算模式里,开始受欢迎了起来。函数式的程式语言已经有几十年的历史,早期像 Lisp 的程式语言,主要是应用在人工智慧的领域。但是,为什么在这个应用领域里,反而流行起来了?

函数式的程式语言有一些特性,包括程式中是没有状态(stateless),而且每次函式之值被评估(或说被执行)时,是没有副作用的(side effect )。

所谓的副作用,代表的是函式被执行时,除了它主要应该达成的作用之外,还有一些其他附属的效果,此即其副作用。主要的作用,就像是函式的回传值,而副作用,则像是除了回传函式之值以外,还同时改变全域变数的值。你可以想像,函式的回传值,除了被其输入参数所影响之外,还同时被其他的状态,像是全域变数所影响时,会产生许多意想不到的结果。

但是如果我们从数学上的函数的角度来看,f(x) 之值,完全取决于 x ,没任何 f() 内部的状态或是外部的状态足以在 x 相同时,造成 f(x) 之值不同。而所谓的函数式程式设计方式,便是在特性上有着此种取向,因此,它没有状态、也没有副作用。

这种特性之所以能对分散式计算带来好处,我想是因为在有这样的特性之后,计算工作会更容易分配到不同的机器上去计算。正如数学的函数一样,只要给定相同的输入值,就一定会算出相同的输出值。计算工作之间的相依性降低了,不论在那部机器上算、在什么时间点算,都不会影响到计算的结果。因此,当以「分而治之」的原则来拆解计算工作,以进行分散式的计算时,更容易拆解工作、更容易合成计算结果,以成为最后的结果。

通过一个更高阶的云端计算平台,以及计算模式,其实,可以让程式设计者更容易的取得规模可扩充性。而从现在的趋势来看,函数式的设计方式,应该还会再流行好一阵子。

按钮 Button/ImageButton

Java 简介

18 Ruby 循环语句

08 最简单的爬虫案例开发

相关阅读