五千年(敝帚自珍)

主题:【原创】云里雾里的云计算 [1] -- 邓侃

共:💬620 🌺1262
全看分页树展 · 主题 跟帖
家园 【原创】云里雾里的云计算 [4]

【5】是云计算,还是云存储?

Gadgets的目标是方便大家建网站。但是单靠gadgets,建网站的工作还是不够方便。

通常网站有三个组成部分,1. 网页,2. 业务逻辑, 3. 数据存储。如果说网页相当于商店,那么业务逻辑相当于车间,而数据存储相当于仓库。商店,车间和仓库三者中,技术含量最高的,当属车间。

点看全图

外链图片需谨慎,可能会被源头改

Manufacture in old time

Courtesy http://www.atlantic-cable.com/Cables/1857-58Atlantic/Cable-Manufacture.jpg

车间管理可以大致概括为两件事,1. 工艺流程,2. 资源调度。工艺流程关心的是,先做什么,后做什么,才能生产一个完整的产品。资源调度的问题是,哪个工人,用哪台机器,在哪个时间,做什么。

网站的业务逻辑处理,大致来说也分业务流程和资源调度两部分。

流程的设计,每个网站不尽相同。譬如有两个网站,一个招聘人才,另一个销售图书,它们的业务流程非常不一样。但是销售图书的网站,与销售电器的网站,它们两者的业务流程相对比较接近。

流程设计千变万化,而资源调度却有章可循。所谓计算机资源,无非是这五种东西,1. CPU,2. RAM,3. Disk,4. RAM-Disk IO,5. Network。资源调度,无非是优化使用这五种资源,使之在最短的时间内,完成分配来的工作。

优化使用这五种资源,目标挺明确,实施起来却相当不容易。一日偶遇一仙人,谈到计算资源调度优化的问题,仙人说,他有一套五行八卦的优化办法,用中国古代智慧,解决当今科技难题。我把仙人的办法概括为以下几个要点,

1. 五行相生相克,系统优化不能偏执单一资源的优化。

2. 系统的总体效率需要一个测度,这个测度被称为“阴阳度”。

3. 阴阳度不是五种资源的简单加权和。阴阳度与五行的关系是非线性的,这种非线性关系可以参照河图洛书来确定,譬如规定五行中土的阴阳度为0,河图数零点的阴阳度为-5,洛书数零点的阴阳度为-10。

4. 时刻监控系统总体的阴阳度,阴阳度变化的正常模式可以分为太极,太虚以及太一三种。

5. 当阴阳度的变化偏离了正常的模式,就需要对系统进行调整。调整的办法参见“说卦”中的六种范式,即洛书逆式,先天八卦,后天八卦,神也者,洛书顺式,和乾坤六子。

仙人的办法听上去很有美感,但是操作起来却有难度。正在困惑之时,听到Google宣布,“我有办法解决资源调度问题,你们只须专注于业务流程”,确实为之感召。

Google的解决办法,是AppEngine。

点看全图

外链图片需谨慎,可能会被源头改

Google AppEngine logo

Courtesy http://img.genbeta.com/2008/04/google-app-engine.png

问题是,Google AppEngine真得能够优化任何业务流程的资源调度吗?

譬如有人想建一个人才招聘网站,招聘的业务流程如下图所示。Google打算劝说这个人把网站建在Google云计算平台上,做为技术支持,AppEngine应该提供哪些功能?

点看全图

外链图片需谨慎,可能会被源头改

Recruiting process business logic

Courtesy http://www.infoq.com/resource/articles/seven-fallacies-of-bpm/en/resources/job_application_process.jpg

猛一看,觉得很容易,流程清楚,算法简单。只需要把流程中诸多环节,归并成几个模块,即大功告成。

再看看,事情没那么简单。整个流程不是从头到尾一次走完,譬如interview会有好几次,然后过几天才会发offer。所以,应当把整个流程的每个模块独立出来,封装成服务,每个服务能够独立运行。召之即来,来之能战。平时不用,不占资源。

SOA(Service Oriented Architecture)还有一个好处,是便于重组业务流程。譬如系统上线以后,发现在面试(interview)以前,还需要添加一个电话约谈(phone screen)的环节。如果流程中每个服务都能独立运行,添加新的服务就很容易,不至于造成牵一发动全身的局面。

SOA的结构设计,有很多优点,但是仍然有遗留问题。如果同时有很多人使用这个招聘网,系统的吞吐量需要随之加大,怎么办?增加系统吞吐量的办法,有两条思路。

第一种办法是购置多台机器,每台机器上安装所有服务。当很多人同时使用招聘网的时候,把他们的需求均匀转发到各个机器上去,这样每台机器的负载都不大,但是整个系统的吞吐量增加。

第二种办法的效率更高,它可以用少数机器,达到和第一种办法相同的吞吐量。或者,用相同数量的机器,在更短的时间内完成所有任务。这种办法首先分析每个服务耗费的资源,譬如CPU时间和RAM空间等等。然后给资源耗费量大的服务多分配几台机器,以免它们成为整个业务流程的瓶颈。

第二种办法虽然有很多好处,但是实现起来有些难处。首先是如何监控和分析每个服务的资源消耗,其次是如何自动把服务从一台机器转移到另一台机器去运行。

或许有人会问,为什么不提多线程的办法呢?所谓多线程是把多个任务交给多个线程去完成,这些线程交叉使用CPU,IO,Disk等等资源,减少使用这些资源前的排队时间。多线程的办法,关注的是每个服务的实现细节。而我们刚才讨论的,是服务与服务之间怎么整合的问题,所以,是不同层面的问题。

又有人问,为什么不提MapReduce之类并行处理的办法?与多线程一样,MapReduce关注的是每个服务的实现细节,是不同层面的问题。

回到前面的问题,如果Google打算劝说大家把网站建在Google云计算平台上,做为技术支持,AppEngine应该提供哪些功能?

1. 开放更底层的APIs,而不仅仅是Python的APIs。便于第三方开发人员,实现逻辑复杂的模块,资源使用方式复杂的模块。

2. 提供IDE,方便第三方开发人员把模块封装成符合Google云计算平台规范的服务。

3. 开发调度工具,用于监督各个服务资源消耗,分配合适的机器去负责各个服务运行等等。

4. 开发预警和修复工具。开放自己的平台,去运行第三方人员(外人)开发的服务。对于Google来讲,有理由提高戒备,预防云计算平台崩溃,万一崩溃了,能够迅速修复。

这四个功能,AppEngine目前都没有实现,所以云计算平台,对于第三方开发人员来说,暂时不是计算平台,而是存储平台。

关键词(Tags): #硅谷评论
全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河