`
阅读更多

作者 吕维德 发布于 2009年3月28日 上午12时30分

缘起

最近因为工作需要,又再度开始接触 Amazon EC2/S3(早在2006初这个服务刚推出不久时曾用过一次,那时是RoR加一堆merb,不过后来随着项目结束也就渐渐忘了这事),结果这次随便查了些资料却发现“云计算”这个单词似乎已无所不在泛滥成灾,也让我一时兴起想了解一下到底现在大家口中所谓的“云计算”是在指什么。

之所以这样好奇主要的原因是在许多地方都看到有人自称在提供云计算服务,但这些服务间彼此的性质、形态与做法差异性却很大,例如EC2与GAE两者就不太一样,GAE与Salesforce又很不同,搞到最后,似乎处处是云端,人人在漫步

根据维基百科的定义,云计算最宽松的定义是这样的:

它是一种计算方式,通过互联网将资源“以服务”的形式提供给用户,而用户不需要了解、知晓或者控制支持这些服务的技术基础架构(“云”)。(It is a style of computing in which resources are provided “as a service” over the Internet to users who need not have knowledge of, expertise in, or control over the technology infrastructure (”in the cloud”) that supports them.)

如果你对这样的定义没问题,那非常好,不用再浪费时间看下去,去喝杯咖啡吧。

很可惜这样的定义在我听来似乎宽松的有点夸张了,因为这样说来,我在家里摆几支iPhone跑些服务并开放API给人用,其实也算是云计算喽?(还是高雅的Apple云哩)就因为这该死的好奇心,我花了几天时间调查并整理了些相关资料,现在总算比较有个头绪了。

请注意这只是我个人的心得整理,文中对于名词的定义与诠释,尤其是“云”,只是我个人的想法,如果有错欢迎各方大德赐教。

从主机服务到VPS,它是真正的云吗?

基本上,如果要细究到底云是什么,可能可以先吵上个三天三夜还没定论,因为根据众多前辈的说法,云这个字本来就是个流行词汇(Buzz Word),想用的人就随需取用好了,其实根本没啥定义好谈的啊。因此,我打算先跳过试图去定义这个字的破题法,从实际的部署方式来看这件事。

以往一般人要提供网络服务,大多是去租虚拟主机,有钱一点就丢机器到机房去,这是最常见也最传统的手法,这个手法最大的缺点在于:如果临时有大流量需求,例如办个活动,很难迅速扩充服务能量,不论是要搞到大量的机器,或无穷尽的带宽,都是个问题。

因此,这几年来比较流行的玩法是所谓的VPS/VDS(Virtual Private Server),透过类似XEN这样的软体,将一台实体服务器虚拟化(Virtualization)成多台虚拟机器然后出租,这样一来当临时有大流量需求时,可以很容易地加买几台虚拟机器就撑过去了。

前面开头谈到的EC2就是这样一个服务,另外这一两年颇受好评的Slicehost也是,在EC2的例子里,每一个虚拟出来的机器叫做一个实例(Instance),因此要应付大流量事件时,可以狂开Instance撑过去,这比狂买实体机器便宜多了。

由于VPS真的超方便而且很好用,因此迅速受到大家欢迎,久而久之,VPS这样的服务似乎也就跟云画上了等号,但这个等号里,有个地方却值得进一步讨论。

简单来说,今天一个人在EC2买了100个Instance,它们并不会自动联合起来工作,而是要靠人工去规划,例如最常见的是在前面放个逆向代理(Reverse Proxy),然后把请求平均导向到这100台机器上(轮询负载均衡,Round-robin Load Balancing),并且,更重要的是应用本身在撰写时就要考虑到将来能支持跑在多个分散的机器上,例如Session要怎么维持?全局内存(Global Memory)如何分享?数据库是否也要散聚在不同机器上?如果分散的话,要怎么维持资料同步?等等这一大堆相关的细节要处理,一个没弄好,呃,就成了 Twitter第二了。

从这个角度看来,VPS(不论是EC2还是Slicehost)提供的其实是虚拟化与负载均衡服务,至于在这个基础服务之上,用户要怎么玩就是各显神通。但负载均衡与云似乎并不尽然相同呀!

世界上还有其它种类的云吗?

有,例如 Google App Engine(简称GAE)提供的服务。

简单来说GAE是由三个东西组成的,分别是MapReduceBigTableGFS(Google File System),其中最重要的特色就是MapReduce。MapReduce可说是一个演算法,也可说是一个框架(看你读的文献来源),但它基本上是由Map与Reduce两者组合,运作方式也很简单:

  • Map:主节点将工作切割成许多小块丢给子节点去执行,子节点可能会再切割工作成各多的小块给其下的子节点去执行,因此这是一个树状的结构。当子节点完成计算后会将结果传回给主节点。
  • Reduce:主节点拿到子节点传回的结果后,将它组合起来,就完成工作了。

对MapReduce有兴趣又闲的发慌的朋友可以去看看Google发表的一篇论文与简报(保证会睡的很香甜:P)。

类似GAE这样的服务,它们最大的特色就是会将工作切割成很多小块,然后经由多台电脑联合起来一起运算,也因为要切割,因此通常会伴随者一个分布式文件系统(在GAE的例子里,叫做GFS),通常也会有一个分布式的文件库,例如GAE里叫Bigtable。

当然前面讲的都是针对底层架构的设计,但对最前端的开发者来说它代表什么意义呢?很简单,开发者可以完全不用管它有100台或10000台电脑在运作,只要照着GAE提供的SDK开发程序,将来布署到GAE上后就会自动去调用一堆电脑(而且很有可能是分布在世界各地数据中心里的)来发功,从这个角度来说,开发者要担心或处理的细节是比较少的,因此理论上上市时间也是比较短的。

如果不想用GAE还有其它选择吗?

有,Hadoop是Aapche基金会里一个基于Java的主要计划,基本上可视为开源版的GAE(很多关键技术是依据Google开放的学术论文来实现的,例如Map Reduce、分布式文件系统等),目前最力挺的开发者是Yahoo,用于该公司的搜索引擎上,而Hadoop的创始者目前也在Yahoo上班(今年红利会不会很伤?:P),这里有一篇iThome的中文报道值得一看。

Hadoop主要由下列三者组成(其它详细说明请看官网):

  • Hadoop Core:主要就是实现MapReduce;
  • HDFS(Hadoop Distributed File System):参考GFS而来的分布式文件系统;
  • HBase:基于HDFS的分布式资料库(功能等同于Google Bigtable)。

Hadoop/GAE与EC2是互斥的吗?

不见得,要看比较的面向为何?但实际上它们是可能合作的,其中最著名的例子是纽约时报在EC2上用Hadoop转了4TB的PDF(这篇文章超级精彩不看可惜)。

故事大略是这样:

NYT有一大票1851-1922年间扫描的一千一百万份文章要从TIFF图档格式转换为PDF,由于数量实在太庞大,转换起来不但耗时甚久,也需要极大数量的机器,就算有钱如NYT也不想当凯子爷投资这么多啊~~~(而且因为转换时间太久,也不太可能跑去BestBuy刷它个几千台PC回来,然后速速转完就退回去;P)

最后NYT的工程师将所有档案传到S3放着,然后到EC2开了100个Instance,再装个Hadoop利用这100台电脑跑分布运算,结果是只花了24小时和大约3000美金就搞定(由于处理速度实在太快,他们实际上还跑了两次吶……)

这个例子也正好带出下一个主题。

EC2到底是不是云?

这要看你怎么定义云这个字,以我而言,我倾向认为MapReduce与分布式文件系统是云计算的主要特色,因此在这个定义之上,EC2并不符合首要条件。

但如果我们把问题转成:EC2可以成为云吗?

那答案就是肯定的,从上面NYT的例子可以看出,EC2提供100个Instance只是基础架构,之后再上面跑Hadoop才是真正发功之所在。由此我们也可以得到另一个结论:硬件本身有无虚拟化并不重要(你可以买100台真的电脑连起来,也可以用EC2开100个Instance),重要的是在其上协同运算的方式(MapReduce是这里的关键)。

更简单的二分法则是这样:

  • Amazon只是把硬件虚拟化,然后卖入门级计算能力。
  • GAE/Hadoop则是提供分布式协同运算,打包的计算方案。

因此,或许我们可以把EC2视为云的前奏曲,拥有它之后,要不要做成云(例如装上Hadoop)则是个人选择。

何时选择使用EC2或云呢?

这是更重要也更实际的问题,而答案也很单纯,主要就是考虑下列因素:

1、你要解决的问题是否能符合MapReduce的矩阵分割方式?

或是更白话一点的讲,你要做的事能不能被切割成小小的一块块来各个击破?例如日志文件的分析就很适合,但Friend of Friend数据库就不见得适合。如果你的问题可切割成许多小块,那就可以考虑下一点。

2、Vendor Lock-in是否是个问题?

这个主要是针对GAE而来的,现在如果用了GAE,基本上它的Lock-in(Vendor Lock-in意思是你采用了一个技术,即将自己锁定在这家提供商身上,不能轻易转换提供商)特质非常强烈,例如一定要用Python与 Bigtable,整个资料库栏位的规划方式跟传统RDB完全不同,操作语法也不一样,将来几乎无法迅速移转到其它主机服务(虽然有人写了GAE to EC2 转换指南,但有没有胆量用是另外一回事)。喔,更别提市场上Python的人才有多贫乏这件事,会RoR的人搞不好还多一点。

当然这里可能的另一个选择就是效法NYT,用EC2+Hadoop搞定制化分布式运算,而且用的是Java,人才四处可得,相对门槛就低一点(但搞不定最后会死在MapReduce搞不定上:))

SaaS是云吗?

这也是个好问题。

现在很多Software as a Service的服务商,例如Salesforce也都宣称自已提供了云计算服务,这又是怎么回事?我认为比较合理的看法是将云分成三个层次来看:

  • 第一层是硬件层(100台真的电脑,或100个EC2 Instance)
  • 第二层是框架(Hadoop、GAE或者微软的AZure等)
  • 第三层才是服务(记账、PDF生成等)

在这样的架构下,SaaS是属于第三层服务这个范畴。

也就是服务商先搞定第一、二层后,在其上建构自已的专业服务,例如Salesforce的主力服务是CRM,因此它通过云提供一系列的CRM API给开发者使用。举个夸张的例子(注意,这例子是假想的),搞不好Salesforce也是租EC2然后搞了个Hadoop,接着在上面用Java写了一堆API给人调用。这时它就是三层皆备,可称云而无愧了。

另外类似的例子则是像Gmail、Google Reader等,这些都是基于GAE的软件服务(先搞定一、二层,然后建构第三层的专业服务)。

附录

原本我曾认为EC2的虚拟化可以做到将许多台实体电脑虚拟化成一台大的服务器,这样工程师就只需要针对一台“超级电脑”来写程式即可,如果是这样,那EC2其实也符合分布式运算的标准,但我查来查去只不断看到类似下面的解释:

EC2是为可以跨多台主机进行扩展的应用而设计的,而不是那些需要大量资源的更大的应用。(EC2 is more designed for applications that scale well across many hosts, rather than larger applications that require huge resources. )可扩展性:Amazon能让你方便地增加或者减少服务器,而不是为一台现有的服务器(Instance)增加更多的电力/内存/硬盘等。这在你的应用设计时就考虑可以跨多台服务器进行扩展,以支持增加的负载的时候效果最好。(Scalability: Amazon supports easily adding or removing servers, not adding more power/memory/disk to an existing server (instance). This works well when your application is architected to scale across multiple servers to support increased load.)

因此目前先初步认定EC2并没有提供这方面的能力,当然如果有错,欢迎指正。

后记

在研究期间叨扰了无数前辈,感谢他们牺牲周未时间情义相挺回答各种无趣的问题,在此致上最高谢意。

另外关于EC2 vs. Slicehost的成本或用哪家比较划算这档事,我也小小想了一下,从实际数据看来,如果只是小型的网站或是创业公司,从省钱的角度来看,应该要选 Slicehost,因为它的初始成本最低,例如花个$20美元就可以有颇大的空间与流量可上线运行了。

但EC2/S3的好处则是安全性、稳定性与扩充性,而它最大的缺点则是成本相对较高,一个Instance开着不用一个月就要$72美元,如果生意好流量大那要交的费用就更多。

目前台湾地区用EC2的网站似乎并不多(Pixnet把资料存在 s3的站就多一点),可能主要是连线反应时间不够快所以接受度不高吧,但我们服务的客户本来就多在北美,所以没差。

作者简介

吕维德,台湾Macromedia用户组发起人,RIA博客d.CAT站长。

分享到:
评论

相关推荐

    银行业:“七问七答”梳理银行基本面,及“我们怎么看”?.rar

    这份名为“银行业:“七问七答”梳理银行基本面,及“我们怎么看”?”的资料,旨在通过七个关键问题,全面剖析银行业的基本面,并提供对于银行业发展趋势的洞察。以下是这七个问题以及相关知识点的详细解释: 1. *...

    C2000系列DSP芯片串口读写方案与FlashPro2000编程器应用详解

    内容概要:本文详细介绍了基于TMS320F系列芯片的C2000串口读写方案及其编程器——FlashPro2000的功能特点和支持的接口模式。文中不仅涵盖了硬件连接的具体步骤,还提供了代码实例来展示Flash擦除操作,并对比了JTAG和SCI-BOOT两种模式的优缺点。此外,针对不同型号的C2000系列芯片,给出了详细的适配指导以及避免烧录过程中可能出现的问题的方法。 适合人群:从事DSP开发的技术人员,尤其是对TI公司C2000系列芯片有一定了解并希望深入了解其编程和烧录细节的人群。 使用场景及目标:适用于实验室环境下的程序调试阶段,以及生产线上的批量烧录任务。主要目的是帮助开发者选择合适的编程工具和技术手段,提高工作效率,减少因误操作导致设备损坏的风险。 其他说明:文中提供的代码片段和命令行指令可以直接用于实际项目中,同时附带了一些实用技巧,如防止芯片变砖的小贴士和自动化重试脚本,有助于解决常见的烧录难题。

    汉字字库存储芯片扩展实验通常是为了学习和理解如何在嵌入式系统或计算机硬件中增加或管理存储资源,特别是针对需要处理中文字符的应用 这类实验对于想要深入了解计算机体系结构、嵌入式开发以及汉字编码的学生和工

    汉字字库存储芯片扩展实验 # 汉字字库存储芯片扩展实验 ## 实验目的 1. 了解汉字字库的存储原理和结构 2. 掌握存储芯片扩展技术 3. 学习如何通过硬件扩展实现大容量汉字字库存储 ## 实验原理 ### 汉字字库存储基础 - 汉字通常采用点阵方式存储(如16×16、24×24、32×32点阵) - 每个汉字需要占用32字节(16×16)到128字节(32×32)不等的存储空间 - 国标GB2312-80包含6763个汉字,需要较大存储容量 ### 存储芯片扩展方法 1. **位扩展**:增加数据总线宽度 2. **字扩展**:增加存储单元数量 3. **混合扩展**:同时进行位扩展和字扩展 ## 实验设备 - 单片机开发板(如STC89C52) - 存储芯片(如27C256、29C040等) - 逻辑门电路芯片(如74HC138、74HC373等) - 示波器、万用表等测试设备 - 连接线若干 ## 实验步骤 ### 1. 单芯片汉字存储实验 1. 连接27C256 EPROM芯片到单片机系统 2. 将16×16点阵汉字字库写入芯片 3. 编写程序读取并显示汉字 ### 2. 存储芯片字扩展实验 1. 使用地址译码器(如74HC138)扩展多片27C256 2. 将完整GB2312字库分布到各芯片中 3. 编写程序实现跨芯片汉字读取 ### 3. 存储芯片位扩展实验 1. 连接两片27C256实现16位数据总线扩展 2. 优化字库存储结构,提高读取速度 3. 测试并比较扩展前后的性能差异 ## 实验代码示例(单片机部分) ```c #include <reg52.h> #include <intrins.h> // 定义存储芯片控制引脚 sbit CE = P2^7; // 片选 sbit OE = P2^6; // 输出使能 sbit

    测控装备干扰源快速侦测系统设计研究.pdf

    测控装备干扰源快速侦测系统设计研究.pdf

    嵌入式八股文面试题库资料知识宝典-【开发】嵌入式开源项目&库&资料.zip

    嵌入式八股文面试题库资料知识宝典-【开发】嵌入式开源项目&库&资料.zip

    嵌入式八股文面试题库资料知识宝典-百度2022年嵌入式面试题.zip

    嵌入式八股文面试题库资料知识宝典-百度2022年嵌入式面试题.zip

    少儿编程scratch项目源代码文件案例素材-空间站.zip

    少儿编程scratch项目源代码文件案例素材-空间站.zip

    基于关联规则的商业银行个性化产品推荐.pdf

    基于关联规则的商业银行个性化产品推荐.pdf

    嵌入式八股文面试题库资料知识宝典-Linux基础使用.zip

    嵌入式八股文面试题库资料知识宝典-Linux基础使用.zip

    MATLAB仿真轴棱锥生成贝塞尔高斯光束及环形光束光强图像分析

    内容概要:本文详细介绍了利用MATLAB进行轴棱锥生成贝塞尔高斯光束及环形光束光强图像的仿真研究。首先阐述了实验的背景与目标,强调了MATLAB在光学和计算科学领域的广泛应用。接着,具体描述了实验的方法与步骤,包括材料准备、仿真过程中的参数设定和光束生成代码编写。最后,对实验结果进行了深入分析,展示了贝塞尔高斯光束和环形光束的光强分布特点,验证了其光学性能的预期表现。文章还对未来的研究方向和技术改进提出了展望。 适合人群:从事光学、物理学及相关领域研究的专业人士,特别是对光束生成和光学性能分析感兴趣的科研工作者。 使用场景及目标:适用于需要进行光束生成和性能分析的实验室环境,旨在帮助研究人员更好地理解和优化光束特性和传播行为。 其他说明:本文不仅提供了详细的实验方法和步骤,还附有丰富的实验结果和数据分析,为后续研究提供了宝贵的参考资料。

    三电平NPC型APF模型预测控制中滞环控制模块的应用与开关频率优化研究

    内容概要:本文探讨了三电平NPC型有源电力滤波器(APF)的模型预测控制(MPC)中存在的开关频率过高问题及其解决方案。传统MPC方法会导致极高的开关频率,增加了系统的能耗和热量。通过引入滞环控制模块,可以在不大幅牺牲性能的情况下有效降低开关频率。具体来说,滞环控制通过在价值函数计算后增加一个判断条件,对状态切换进行惩罚,从而减少不必要的开关动作。实验结果显示,开关频率从4392Hz降至3242Hz,降幅达26.2%,虽然电流总谐波畸变率(THD)略有上升,但仍符合国家标准。此外,文中还提出了动态调整滞环宽度的方法,以进一步优化不同负载条件下的表现。 适合人群:从事电力电子、电力系统控制领域的研究人员和技术人员,特别是关注APF和MPC技术的人群。 使用场景及目标:适用于需要优化APF系统开关频率的研究和工程项目,旨在提高系统效率并降低成本。目标是在不影响系统性能的前提下,显著降低开关频率,减少能量损失和热管理难度。 其他说明:文章不仅提供了理论分析,还包括具体的实现代码片段,有助于读者理解和实践。同时,强调了在实际应用中需要注意的问题,如中点电位漂移等。

    计算流体力学中三维POD DMD程序的原网格处理方法及应用

    内容概要:本文介绍了三维POD DMD程序在处理原网格数据方面的独特优势和技术细节。首先阐述了该程序能读取结构化和非结构化网格数据及其拓扑关系,在生成模态数据过程中保持原始网格形态而不需要进行网格插值操作。接着展示了简化版本的Python代码片段,揭示了读取网格数据和生成模态数据的核心逻辑。最后提到提供的辅助学习资料如代码、视频教程、Word教程和实例数据,帮助用户深入理解并掌握该程序的应用。 适合人群:从事计算流体力学领域的研究人员和技术爱好者,尤其是那些希望提高数据处理效率的人群。 使用场景及目标:适用于需要处理复杂网格数据的研究项目,旨在简化数据处理流程,提升工作效率,同时保持数据的原始特性。 其他说明:文中不仅提供了理论性的讲解,还有具体的代码示例和丰富的学习资源,使读者可以边学边练,快速上手。

    融合双向路由注意力的多尺度X光违禁品检测.pdf

    融合双向路由注意力的多尺度X光违禁品检测.pdf

    嵌入式八股文面试题库资料知识宝典-Linux_Shell基础使用.zip

    嵌入式八股文面试题库资料知识宝典-Linux_Shell基础使用.zip

    嵌入式八股文面试题库资料知识宝典-联发科2021武汉嵌入式软件开发.zip

    嵌入式八股文面试题库资料知识宝典-联发科2021武汉嵌入式软件开发.zip

    基于有限体积法Godunov格式的管道泄漏检测模型研究.pdf

    基于有限体积法Godunov格式的管道泄漏检测模型研究.pdf

    嵌入式八股文面试题库资料知识宝典-ARM常见面试题目.zip

    嵌入式八股文面试题库资料知识宝典-ARM常见面试题目.zip

    基于LWR问题的无证书全同态加密方案.pdf

    基于LWR问题的无证书全同态加密方案.pdf

    嵌入式八股文面试题库资料知识宝典-符坤面试经验.zip

    嵌入式八股文面试题库资料知识宝典-符坤面试经验.zip

Global site tag (gtag.js) - Google Analytics