07月 15, 2010

【2】三段论

网站的架构设计,传统的做法是三段论。所谓“传统的”,并不等同于“过时的”。大型网站的架构设计,强调实用。新潮的设计,固然吸引人,但是技术可能不成熟,风险高。所以,很多大型网站,走的是稳妥的传统的路子。

2006年5月Twitter刚上线的时候,为了简化网站的开发,他们使用了Ruby-On-Rails工具,而Ruby-On-Rails的设计思想,就是三段论。

1. 前段,即表述层(Presentation Tier) 用的工具是Apache Web Server,主要任务是解析HTTP协议,把来自不同用户的,不同类型的请求,分发给逻辑层。

2. 中段,即逻辑层 (Logic Tier)用的工具是Mongrel Rails Server,利用Rails现成的模块,降低开发的工作量。

3. 后段,即数据层 (Data Tier) 用的工具是MySQL 数据库。

先说后段,数据层。

Twitter 的服务,可以概括为两个核心,1. 用户,2. 短信。用户与用户之间的关系,是追与被追的关系,也就是Following和Be followed。对于一个用户来说,他只读自己“追”的那些人写的短信。而他自己写的短信,只有那些“追”自己的人才会读。抓住这两个核心,就不难理解 Twitter的其它功能是如何实现的[7]。

围绕这两个核心,就可以着手设计Data Schema,也就是存放在数据层(Data Tier)中的数据的组织方式。不妨设置三个表[8],

1. 用户表:用户ID,姓名,登录名和密码,状态(在线与否)。

2. 短信表:短信ID,作者ID,正文(定长,140字),时间戳。

3. 用户关系表,记录追与被追的关系:用户ID,他追的用户IDs (Following),追他的用户IDs (Be followed)。

再说中段,逻辑层。

当用户发表一条短信的时候,执行以下五个步骤,

1. 把该短信记录到“短信表” 中去。

2. 从“用户关系表”中取出追他的用户的IDs。

3. 有些追他的用户目前在线,另一些可能离线。在线与否的状态,可以在“用户表”中查到。过滤掉那些离线的用户的IDs。

4. 把那些追他的并且目前在线的用户的IDs,逐个推进一个队列(Queue)中去。

5. 从这个队列中,逐个取出那些追他的并且目前在线的用户的IDs,并且更新这些人的主页,也就是添加最新发表的这条短信。

以上这五个步骤,都由逻辑层(Logic Tier)负责。前三步容易解决,都是简单的数据库操作。最后两步,需要用到一个辅助工具,队列。队列的意义在于,分离了任务的产生与任务的执行。

队列的实现方式有多种,例如Apache Mina[9]就可以用来做队列。但是Twitter团队自己动手实现了一个队列,Kestrel [10,11]。Mina与Kestrel,各自有什么优缺点,似乎还没人做过详细比较。

不管是Kestrel还是Mina,看起来都很复杂。或许有人问,为什么不用简单的数据结构来实现队列,例如动态链表,甚至静态数组?如果逻辑层只在一台服务器上运行,那么对动态链表和静态数组这样的简单的数据结构,稍加改造,的确可以当作队列使用。Kestrel和Mina这些“重量级”的队列,意义在于支持联络多台机器的,分布式的队列。在本系列以后的篇幅中,将会重点介绍。

最后说说前段,表述层。

表述层的主要职能有两 个,1. HTTP协议处理器(HTTP Processor),包括拆解接收到的用户请求,以及封装需要发出的结果。2. 分发器(Dispatcher),把接收到的用户请求,分发给逻辑层的机器处理。如果逻辑层只有一台机器,那么分发器无意义。但是如果逻辑层由多台机器组成,什么样的请求,发给逻辑层里面哪一台机器,就大有讲究了。逻辑层里众多机器,可能各自专门负责特定的功能,而在同功能的机器之间,要分摊工作,使负载均衡。

访问Twitter网站的,不仅仅是浏览器,而且还有手机,还有像QQ那样的电脑桌面工具,另外还有各式各样的网站插件,以便把其它网站联系到Twitter.com上来[12]。因此,Twitter的访问者与Twitter网站之间的通讯协议,不一定是HTTP,也存在其它协议。

三段论的Twitter架构,主要是针对HTTP协议的终端。但是对于其它协议的终端,Twitter的架构没有明显地划分成三段,而是把表述层和逻辑层合二为一,在Twitter的文献中,这二合一经常被称为“API”。

综上所述,一个能够完成Twitter基本功能的,简单的架构如Figure 1 所示。或许大家会觉得疑惑,这么出名的网站,架构就这么简单?Yes and No,2006年5月Twitter刚上线的时候,Twitter架构与Figure 1差距不大,不一样的地方在于加了一些简单的缓存(Cache)。即便到了现在,Twitter的架构依然可以清晰地看到Figure 1 的轮廓。

解剖Twitter 【2】三段论

Figure 1. The essential 3-tier of Twitter architecture
Courtesy http://farm3.static.flickr.com/2683/4051785892_e677ae9d33_o.png

Reference,

[7] Tweets中常用的工具 (http://www.ccthere.com/article/2383833)
[8] 构建基于PHP的微博客服务 (http://webservices.ctocio.com.cn/188/9092188.shtml)
[9] Apache Mina Homepage (http://mina.apache.org/)
[10] Kestrel Readme (http://github.com/robey/kestrel)
[11] A Working Guide to Kestrel. (http://github.com/robey/kestrel/blob/master/docs/guide.md)
[12] Alphabetical List of Twitter Services and Applications (http://en.wikipedia.org/wiki/List_of_Twitter_services_and_applications)

时常听到“浮躁”这个词,批评现代人不求甚解,缺乏严谨踏实的作风。这种批评有狭隘之嫌。每代人所处的环境不同,面临的问题不同,所以逐渐养成一种风气,去适应新的环境,解决新的问题。

几百年前,人们读长篇小说,看歌剧,听交响乐。到了二十世纪,大家读杂志报纸,看电影电视,听流行歌曲。信息时代,人们上网,读博客,看视频。在这些表象的背后,促成这些风气进化的,是信息的产量与传播速度的激增。面对海量而且迅速更新的信息,人人捧读红楼梦,一唱三咏的局面是难以想象的。取而代之的,是要求信息的篇幅简短,而重点突出。

随着信息爆炸的加剧,微博客网站Twitter横空出世了。用横空出世这个词来形容Twitter的成长,并不夸张。从2006年5月Twitter上线,到2007年12月,一年半的时间里,Twitter用户数从0增长到6.6万。又过了一年,2008年12月,Twitter的用户数达到5百万。[1]

Twitter用户数的急剧攀升,与几次重大事件有关,2007年3月美国SXSW音乐节,2008年11月印度孟买的恐怖事件,2009年1月奥巴马总统就职,2009年6月伊朗选举危机等等。重大事件的报导,特点是读者多,更新快。所以,Twitter网站的成功,先决条件是能够同时给千万用户提供服务,而且提供服务的速度要快。 [2,3,4]

有观点认为,Twitter的业务逻辑简单,所以竞争门槛低。前半句正确,但是后半句有商榷余地。Twitter的竞争力,离不开严谨的系统架构设计。

【1】万事开头易

Twitter的核心业务逻辑,在于Following和Be followed。[5]

进入Twitter个人主页,你会看到你following的那些作者,最近发表的微博客。所谓微博客,就是一则短信,Twitter规定,短信的长度不得超过140个字。短信不仅可以包含普通文字信息,也可以包含URL,指向某个网页,或者照片及视频等等。这就是following的过程。

当你写了一则短信并发表以后,你的followers会立刻在他们的个人主页中看到你写的最新短信。这就是be followed的过程。

实现这个业务流程似乎很容易。

1. 为每一个注册用户订制一个Be-followed的表,主要内容是每一个follower的ID。同时,也订制一个Following的表,主要内容是每一个following作者的ID。

2. 当用户打开自己的个人空间时,Twitter先查阅Following表,找到所有following的作者的ID。然后去数据库读取每一位作者最近写的短信。汇总后按时间顺序显示在用户的个人主页上。

3. 当用户写了一则短信时,Twitter先查阅Be-followed表,找到所有followers的IDs。然后逐个更新那些followers的主页。

如果有follower正在阅读他的Twitter个人主页,主页里暗含的JavaScript会自动每隔几十秒,访问一下Twitter服务器,检查正在看的这个个人主页是否有更新。如果有更新,立刻下载新的主页内容。这样follower就能读到最新发表的短信了。

从作者发表到读者获取,中间的延迟,取决于JavaScript更新的间隔,以及Twitter服务器更新每个follower的主页的时间。

从系统架构上来说,似乎传统的三段论(Three-tier architecture [6]),足够满足这个业务逻辑的需要。事实上,最初的Twitter系统架构,的确就是三段论。

Reference,

[1] Fixing Twitter. (http://www.bookfm.com/courseware/coursewaredetail.html?cid=100777)
[2] Twitter blows up at SXSW conference. (http://gawker.com/tech/next-big-thing/twitter-blows-up-at-sxsw-conference-243634.php)
[3] First Hand Accounts of Terrorist Attacks in India on Twitter and Flickr. (http://www.techcrunch.com/2008/11/26/first-hand-accounts-of-terrorist-attacks-in-india-on-twitter/)
[4] Social Media Takes Center Stage in Iran. (http://www.findingdulcinea.com/news/technology/2009/June/Twitter-on-Iran-a-Go-to-Source-or-Almost-Useless.html)
[5] Twitter的这些那些. (http://www.ccthere.com/article/2363334) (http://www.ccthere.com/article/2369092)
[6] Three tier architecture. http://en.wikipedia.org/wiki/Multitier_architecture

(阅读全文……)

07月 8, 2010

经过上次高峰论坛的洗礼,使得我对IBM的云计算解决方案有了新的深入,虽然有很多闪光点,但是瑕不掩瑜,的确也有瑕疵的存在,那么在进行深入分析之前,先和大家聊聊在会场上我和一位IBM销售的争论,他是负责IBM XIV系统存储产品的销售,因为我在网上已经听到很多对XIV不利的评论,所以我特地将这样问题(比如Double Disk Failure和低利用率等)抛给他,想看一下他是怎么应对的,虽然他被我这几个略带挑拨性的问题给略微激怒了,但是他还是给出了明确并合理的答复,最后,还说了一句值得我回味的话,“对于用户而言,一个产品,比如存储设备,用户不会care什么架构和低利用率的,用户只会关心什么价格和能存多少东西“。所以本来主要会试着从用户这个角度来分析IBM的云计算解决方案。

 

6+1解决方案

IBM Cloud

图1. IBM 云计算 6+1解决方案

该方案能够帮助企业提供6+1种情景的云环境,包括物联网云,分析云,平台云,IDC云,开发测试云,基础架构云,一个能够快速部署云计算环境的设备,也就是CloudBurst,并结合IBM在各个行业累计的经验,使其能帮助各类企业和机构解决其所需计算资源的问题,如果大家对其细节感兴趣的话,可以看一下这篇文章和jinzi的chart。接下来就是总体分析一下这些解决方案的优点和不足之处。

 

优点

IBM的云计算解决方案的优势主要体现在下面这五个方面:

  1. 品牌:这绝对是IBM的核心竞争力,虽然现在已经没有七八十年代这么响亮了,但是还是有一定含金量的。
  2. 服务:虽然在服务方面,肯定无法和奥美等本事就身处服务行业的公司相比,但是在IT领域还是独树一帜的。
  3. 行业经验:由于IBM本身有很多来自各行各业的客户,使其累计很多相关经验,这将会用助于今后云的建设。
  4. 丰富的产品线:不仅IBM有上面这六种云计算解决方案,而且其在软硬件各个方面都有丰富的产品线,比如硬件有大型机,Power系列和X86这三条产品线,而软件方面,则有DB2和WebSphere为代表的五大品牌。
  5. 充足的人力资源:身为一个曾经在IBM工作过三年的人,不得不感叹IBM的人才资源之丰富,从全球而言,有Erich Gamma和Grady Booch这样的泰斗(这两个人大家都应该认识吧),在国内也有一批顶尖的人才,比如云计算中心的jinzi和方兴,CDL的毛新生等。

 

不足之处

其瑕疵主要集中于下面这三点:

  1. 摊子太大:虽然上面提到了IBM有丰富的产品线和充足的人力资源,但是要想一下子把多个有一定差别的云计算解决方案做好,做精那是很不容易的。
  2. 缺乏独创性的技术和产品:这点主要是和现在私有云技术领先者Cisco和VMware相比,虽然IBM通过ex5架构对Cisco UCS做了一定的回击,但IBM很难撼动Cisco,VMware和EMC这对黄金组合在私有云上的技术优势和整合优势。总体而言,IBM的云计算解决方案基本是对之前一些解决方案的更新,而不是革命。
  3. 高层的质疑:由于众所周知的原因,使得IBM的解决方案收到了质疑,虽然我个人觉得有点多虑,但是高层的看法肯定有他自己的见地。

有些朋友会提到其价格高,但我个人觉得价格高不是大问题,只要它能做到一分钱一分货就行。

 

最后,将和开头呼应,来聊聊那些用户会比较青睐IBM的云计算解决方案,首先,由于其价格的因素,IBM的解决方案肯定是属于中高端,同时,由于其主推私有云解决方案,而在全球私有云界IBM最强大的竞争对手VCE(VMware,Cisco,EMC)联盟还没进入中国市场,使得对于那些需要私有云和相关云服务的政府和大中型企业会等中高端用户而言,IBM的云计算方案应该是一个不错的选择,毕竟品牌,服务,丰富的经验和充足的资源都是其亮点,但希望它能在其不足的地方进行补强,比如提供领先的产品和解决方案,并做精,同时扫除高层的质疑。

DPI(Deep Packet Inspection)总的来说就是一个协议识别技术,是要增加网络的visibility。一般用的的技术有以下几类:
1)Signature
这是最基本的技术。如何定义一个协议的signature?开始大家都是用port来定义(这是指udp或者tcp的port,ip层可以用协议号来标识)。一些常见的port,比如21,80之类的,是由协议规定的。如果大家都守规矩,用port来标识还是比较准确的。
如果协议是跑在http之上,用80端口就无法标识。这就需要定义更复杂的signature,比如:
figure3
在payload这个层面,需要对包reassemble之后(这是tcp reassemble,当然之前需要做ip reassemble)才能match,问题是需要reassemble多少包?match可以用正则表达式,也可以用DFA engine。match可以是协议无关的,但是reassemble却不能,不同的协议,需要reassemble的包多少不同。如果不需要reassemble,直接把packet输入到状态机,那么这些包是发走,还是缓存起来。这里就是DPI和IDP的区别,DPI的用途是识别协议,而IDP是用于防护,所以DPI应该不需要缓存packet,而IDP需要。Signature定义是个技术活。Signature的大小直接影响到match的效率,而signature的准确性也影响识别的准确性。识别不可能是100%准确,对于那些没有被识别的,或者是被错误识别的stream如何处理,也是一个需要慎重考虑的问题。

2)Behavior

协议的behavior可以理解为行为,对运营商来说于行为分析是最有价值的商业分析,这里有一个图:
figure5

就是说,不同协议的packet行为是不同的。比如p2p多用小包,而http多用大包。这个需要对不同协议有一个统计的特征,然后用这个特征去匹配每个stream。这个看起来和语音识别所用的技术差不多。但是协议的bahavior不像语音那么稳定,如果协议bahavior变了,需要更新特征协议库,协议库的更新现在已经做到了无损升级。

对于加密的stream,signature的用途就小很多,但是任何加密的stream,都需要一个密钥协商的过程。从密钥协商的过程来进行识别也是一个可行的方法。Bahavior的方法应该不管是不是加密,所以用途会更广泛一点。

在应用DPI技术之前,有几个前提:

1)stream。用五元组{proto, saddr, daddr, sport, dport}标识的stream是基础,这就是常说的session或者flow based, signature没有跨session的,目前没有,当然将来可以做。

2)有些协议有多个session,比如ftp。识别ftp control很容易,但是识别ftp data就比较困难。但是由于ftp data是从ftp control派生来到,所以能过把ftp control识别的结果带到ftp data上,然后在ftp data应用基于DPI的一个控制,比如QoS之类的,就比较容易。很多其他的协议也有类似的情况(基本上需要ALG的协议都是这样)。

DPI技术可以有很多应用,比如access control, QoS,log等等。这也算是网络安全领域一个热点技术,这个技术和病毒识别的思路是差不多的,只不过出现地比较晚一点。

本文原载于InfoQ中文站,版权所有,原文为从技术角度剖析云计算的架构,如需转载,请务必附带本声明,谢谢。在这里也要稍微谢谢InfoQ霍主编,如果不是他的坚持,这篇文章也不会像现在这样成熟,还有,InfoQ本身也是一个比较高端的技术网站,为Java、.NET、Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如QCon、免费迷你书下载如《架构师》等,大家如果没去过的话,请点击

在写《剖析云计算》(编者注:InfoQ中文站随后推出该Minibook)一书的时候,我发现虽然云计算本身有三层之分,也就是SaaS,PaaS和IaaS,但这种分层本身主要是从用户体验的角度来而言,比如,SaaS主要将应用作为服务提供给客户,IaaS是主要是将虚拟机等资源作为服务提供给用户。而本文将从技术角度来分析和总结云计算的架构。

综述

基于对现有的一些云计算产品的分析和我个人的一些经验,总结出一套云计算的架构,具体请看下图:

Cloud Arch

图1. 云计算的架构

这套架构主要可分为四层,其中有三层是横向的,分别是显示层、中间件层和基础设施层,通过这三层技术能够提供非常丰富的云计算能力和友好的用户界面,还有一层是纵向的,称为管理层,是为了更好地管理和维护横向的三层而存在的。接下来将一个个地给大家介绍每个层次的作用和属于这个层次的主要技术。

显示层

这层主要是用于以友好的方式展现用户所需的内容,并会利用到下面中间件层提供的多种服务,主要有五种技术:

  1. HTML:标准的Web页面技术,现在主要以HTML4为主,但是将要推出的HTML5会在很多方面推动Web页面的发展,比如视频和本地存储等方面。
  2. JavaScript:一种用于Web页面的动态语言,通过JavaScript,能够极大地丰富Web页面的功能,最流行的JS框架有jQuery和Prototype。
  3. CSS:主要用于控制Web页面的外观,而且能使页面的内容与其表现形式之间进行优雅地分离。
  4. Flash:业界最常用的RIA(Rich Internet Applications)技术,能够在现阶段提供HTML等技术所无法提供的基于Web的富应用,而且在用户体验方面,非常不错。
  5. Silverlight:来自业界巨擎微软的RIA技术,虽然其现在市场占有率稍逊于Flash,但由于其可以使用C#来进行编程,所以对开发者非常友好。

在显示层,大多数云计算产品都比较倾向HTML,、JavaScript和CSS这对黄金组合,但是Flash和Silverlight等RIA技术也有一定的用武之地,比如VMware vCloud就采用了基于Flash的Flex技术,而微软的云计算产品肯定会在今后使用到Silverlight。

中间件层

这层是承上启下的,它在下面的基础设施层所提供资源的基础上提供了多种服务,比如缓存服务和REST服务等,而且这些服务即可用于支撑显示层,也可以直接让用户调用,并主要有五种技术:

  1. REST:通过REST技术,能够非常方便和优雅地将中间件层所支撑的部分服务提供给调用者。
  2. 多租户:就是能让一个单独的应用实例可以为多个组织服务,而且保持良好的隔离性和安全性,并且通过这种技术,能有效地降低应用的购置和维护成本。
  3. 并行处理:为了处理海量的数据,需要利用庞大的X86集群进行规模巨大的并行处理,Google的MapReduce是这方面的代表之作。
  4. 应用服务器:在原有的应用服务器的基础上为云计算做了一定程度的优化,比如用于Google App Engine的Jetty应用服务器。
  5. 分布式缓存:通过分布式缓存技术,不仅能有效地降低对后台服务器的压力,而且还能加快相应的反应速度,最著名的分布式缓存例子莫过于Memcached。

对于很多PaaS平台,比如用于部署Ruby应用的Heroku云平台,应用服务器和分布式缓存都是必备的,同时REST技术也常用于对外的接口,多租户技术则主要用于SaaS应用的后台,比如用于支撑Salesforce的Sales Cloud等应用的Force.com多租户内核,而并行处理技术常被作为单独的服务推出,比如Amazon的Elastic MapReduce。

基础设施层

这层作用是为给上面的中间件层或者用户准备其所需的计算和存储等资源,主要有四种技术:

  1. 虚拟化:也可以理解它为基础设施层的“多租户”,因为通过虚拟化技术,能够在一个物理服务器上生成多个虚拟机,并且能在这些虚拟机之间能实现全面的隔离,这样不仅能减低服务器的购置成本,而且还能同时降低服务器的运维成本,成熟的X86虚拟化技术有VMware的ESX和开源的Xen。
  2. 分布式存储:为了承载海量的数据,同时也要保证这些数据的可管理性,所以需要一整套分布式的存储系统,在这方面,Google的GFS是典范之作。
  3. 关系型数据库:基本是在原有的关系型数据库的基础上做了扩展和管理等方面的优化,使其在云中更适应。
  4. NoSQL:为了满足一些关系数据库所无法满足的目标,比如支撑海量的数据等,一些公司特地设计一批不是基于关系模型的数据库,比如Google的BigTable和Facebook的Cassandra等。

 

现在大多数的IaaS服务都是基于Xen的,比如Amazon的EC2等,但VMware也推出了基于ESX技术的vCloud,同时业界也有几个基于关系型数据库的云服务,比如Amazon的RDS(Relational Database Service)和Windows Azure SDS(SQL Data Services)等。关于分布式存储和NoSQL,它们已经被广泛用于云平台的后端,比如Google App Engine的Datastore就是基于BigTable和GFS这两个技术之上的,而Amazon则推出基于NoSQL技术的Simple DB。

管理层

这层是为横向的三层服务的,并给这三层提供多种管理和维护等方面的技术,主要有下面这六个方面:

  1. 帐号管理:通过良好的帐号管理技术,能够在安全的条件下方便用户地登录,并方便管理员对帐号的管理。
  2. SLA监控:对各个层次运行的虚拟机,服务和应用等进行性能方面的监控,以使它们都能在满足预先设定的SLA(Service Level Agreement)的情况下运行。
  3. 计费管理:也就是对每个用户所消耗的资源等进行统计,来准确地向用户索取费用。
  4. 安全管理:对数据,应用和帐号等IT资源采取全面地保护,使其免受犯罪分子和恶意程序的侵害。
  5. 负载均衡:通过将流量分发给一个应用或者服务的多个实例来应对突发情况。
  6. 运维管理:主要是使运维操作尽可能地专业和自动化,从而降低云计算中心的运维成本。

现在的云计算产品在帐号管理,计费管理和负载均衡这三个方面大都表现地不错,在这方面最突出的例子就是Amazon 的EC2,但可惜的是,大多数产品在SLA监控,安全管理和运维管理等方面还有所欠缺。

举例

接下来,将以Salesforce的Sales Cloud和Google的App Engine这两个著名的云计算产品为例,来帮助大家理解本文所提到的云计算架构:

Salesforce Sales Cloud

也就是之前的Salesforce CRM(客户关系管理),属于云计算中的SaaS层,主要是通过在云中部署可定制化的CRM应用,来让企业用户在很低初始投入的情况下使用上CRM,并且可根据自身的流程来进行灵活地定制,而且只需接入网络就能使用。下图为其在技术层面上大致的架构:

salesforce arch

图2.  Salesforce Sales Cloud

采用的主要技术:

  1. 显示层:基于HTML、JavaScript和CSS这对黄金组合。
  2. 中间件层:在此层,Salesforce引入了多租户内核和为支撑此内核运行而经过定制的应用服务器。
  3. 基础设施层:虽然在后端还是使用在企业环境中很常见的Oracle数据库,但是其为了支撑上层的多租户内核做了很多的优化。
  4. 管理层:在安全管理方面,Salesforce提供了多层保护,并支持SSL加密等技术,除此之外,其还在帐号管理、计费管理和负载均衡这三方面有不错地支持。

 

 

Google App Engine

App Engine属于云计算中的PaaS层,其主要提供一个平台,来让用户在Google强大的基础设施上部署和运行应用程序,同时App Engine会根据应用所承受的负载来对应用所需的资源进行调整,并免去用户对应用和服务器等的维护工作,而且支持Java和Python这两种语言。由于App Engine属于PaaS平台,所以关于显示层的技术选择由应用的自身需要而定,与App Engine无关,关于App Engine在技术层面上大致的架构,具体请看下图:

google app engine

图3. Google App Engine

采用的主要技术:

  1. 中间件层:既有经过定制化的应用服务器,比如上面已经提到过的Jetty,也提供基于Memcached的分布式缓存服务。
  2. 基础设施层: 在分布式存储GFS的基础上提供了NoSQL数据库BigTable来对应用的数据进行持久化。
  3. 管理层:由于App Engine是基于Google强大的分布式基础设施,使其在运维管理技术方面非常出色,同时其计费管理能做到非常细粒度的API级计费,而且App Engine在帐号管理和负载均衡这两方面都有非常好地支持。

虽然用一张这样简单的图和两个简短的例子来描述庞大的云计算整体架构的确是略显寒酸,但是应该能让大家从技术角度对云计算的架构有一个大致的了解。

  今天是离开华为后的第一周,在此开博记录我的成长道路,结交更多的朋友