Arch 类别下的文章

按:此为客座博文系列。投稿人吴朱华曾在IBM中国研究院从事与云计算相关的研究,现在正致力于研究云计算技术。

本篇将首先介绍App Engine的一些设计理念,接着将对App Engine的组成部分等进行介绍。

设计理念

App Engine在设计理念方面,主要可以总结为下面这五条:

  • 重用现有的Google技术:大家都知道,重用是软件工程的核心理念之一,因为通过重用不仅能减低开发成本,而且能简化架构。在App Engine开发的过程中,重用的思想也得到了非常好的体现,比如Datastore是基于Google的bigtable技术,Images服务是基于Picasa的,用户认证服务是利用Google Account的,Email服务是基于Gmail的等。
  • 无状态:为了让更好地支持扩展,Google没有在应用服务器层存储任何重要的状态,而主要在datastore这层对数据进行持久化,这样当应用流量突然爆发时,可以通过为应用添加新的服务器来实现扩展。
  • 硬限制:App Engine对运行在其之上的应用代码设置了很多硬性限制,比如无法创建Socket和Thread等有限的系统资源,这样能保证不让一些恶性的应用影响到与其临近应用的正常运行,同时也能保证在应用之间能做到一定的隔离。
  • 利用Protocol Buffers技术来解决服务方面的异构性:应用服务器和很多服务相连,有可能会出现异构性的问题,比如应用服务器是用Java写的,而部分服务是用C++写的等。Google在这方面的解决方法是基于语言中立,平台中立和可扩展的Protocol Buffer,并且在App Engine平台上所有API的调用都需要在进行RPC(Remote Procedure Call,远程方面调用)之前被编译成Protocol Buffer的二进制格式。
  • 分布式数据库:因为App Engine将支撑海量的网络应用,所以独立数据库的设计肯定是不可取的,而且很有可能将面对起伏不定的流量,所以需要一个分布式的数据库来支撑海量的数据和海量的查询。

组成部分

GAE ARCH.jpg

图1. GAE的架构图(图源自参[6])

简单而言,其架构可以分为三个部分:前端,Datastore和服务群:

前端

共包括四个模块:

  • Front End:既可以认为它是Load Balancer,也可以认为它是Proxy,它主要负责负载均衡和将请求转发给App Server(应用服务器)或者Static Files等工作。
  • Static Files:在概念上,比较类似于CDN(Content Delivery Network,内容分发网络),用于存储和传送那些应用附带的静态文件,比如图片,CSS和JS脚本等。
  • App Server:用于处理用户发来的请求,并根据请求的内容来调用后面的Datastore和服务群。
  • App Master:是在应用服务器间调度应用,并将调度之后的情况通知Front End。

Datastore

它是基于BigTable技术的分布式数据库,虽然其也可以被理解成为一个服务,但是由于其是整个App Engine唯一存储持久化数据的地方,所以其是App Engine中一个非常核心的模块。其具体细节将在下篇和大家讨论。

服务群

整个服务群包括很多服务供App Server调用,比如Memcache,图形,用户,URL抓取和任务队列等。

Python版和Java版App Engine在实现方面的区别

因为大多数服务都可以被这两个版本共享,所以两者之间的区别主要集中在App Server端,Python版App Server应该是经过Google修改的Python Runtime,版本号应该是2.5.2,而Java版App Server是基于Jetty 6的,因为它的体积和最常用的Tomcat相比更娇小,这样能使得一台服务器支持更多的应用,而且其应该经过Google的一定的修改。

流程

在这里举一个普通的HTTP请求的处理流程为例:

  • 用户发送一个HTTP请求。
  • Front End接受这个请求,并将这个请求转发给一个空闲的App Server。
  • App Server会处理这个请求。
  • 检查用于处理这个请求的Handler是不是已经被初始化了,如果没有的话,需要对这个Handler进行初始化。
  • 调用服务群的用户认证服务来对用户进行认证,如果失败的话,需要终止整个请求的处理工作,并返回用户无法被认证的信息。
  • 查看这个请求所需的数据是否已经缓存在Memcahe中,如果没有的话,将对Datastore发出查询请求来得到数据。
  • 通过整合上步得到数据来生成相关的HTML,并返回给用户。
  • 由于HTML里面会包含对一些静态文件的引用,比如图片和CSS等,所以当用户收到HTML之后,还会通过Front End对Static Files里面存储的静态文件进行读取。

本篇结束,下篇将关注App Engine最核心的Datastore的设计。

--EOF--

按:此为客座博文系列。投稿人吴朱华曾在IBM中国研究院从事与云计算相关的研究,现在正致力于研究云计算技术。

通过前面两篇介绍,大家应该对Google强大的基础设施有一定的了解。本篇开始介绍构筑在这强大基础设施之上的Google App Engine。

Google App Engine的介绍

由于发布S3和EC2这两个优秀的云服务,使得Amazon已经率先在云计算市场站稳了脚跟,而身为云计算这个浪潮的发起者之一的Google肯定不甘示弱,并在2008年四月份推出了Google App Engine这项PaaS服务,虽然现在无法称其为一个革命性的产品,但肯定是现在市面上最成熟,并且功能最全面的PaaS平台。

Google App Engine 提供一整套开发组件来让用户轻松地在本地构建和调试网络应用,之后能让用户在Google强大的基础设施上部署和运行网络应用程序,并自动根据应用所承受的负载来对应用进行扩展,并免去用户对应用和服务器等的维护工作。同时提供大量的免费额度和灵活的资费标准。在开发语言方面,现支持Java和Python这两种语言,并为这两种语言提供基本相同的功能和API。

功能

在功能上,主要有六个方面:

  • 动态网络服务,并提供对常用网络技术的支持,比如SSL等 。
  • 持久存储空间,并支持简单的查询和本地事务。
  • 能对应用进行自动扩展和负载平衡。
  • 一套功能完整的本地开发环境,可以让用户在本机上对App Engine进行开发和调试。
  • 支持包括Email和用户认证等多种服务。
  • 提供能在指定时间和定期触发事件的计划任务和能实现后台处理的任务队列。

使用流程

整个使用流程主要包括五个步骤:

  • 下载SDK和IDE,并在本地搭建开发环境。
  • 在本地对应用进行开发和调试。
  • 使用GAE自带上传工具来将应用部署到平台上。
  • 在管理界面中启动这个应用。
  • 利用管理界面来监控整个应用的运行状态和资费。

由于本系列是专注于GAE的实现和设计两方面,所以不会对GAE的使用有非常深入地介绍,如果希望大家对GAE的使用方面有更深的理解,具体可以参看一下GAE的官方文档

Google App Engine的主要组成部分

主要可分为五部分:

  • 应用服务器:主要是用于接收来自于外部的Web请求。
  • Datastore:主要用于对信息进行持久化,并基于Google著名的BigTable技术。
  • 服务:除了必备的应用服务器和Datastore之外,GAE还自带很多服务来帮助开发者,比如:Memcache,邮件,网页抓取,任务队列,XMPP等。
  • 管理界面:主要用于管理应用并监控应用的运行状态,比如,消耗了多少资源,发送了多少邮件和应用运行的日志等。
  • 本地开发环境:主要是帮助用户在本地开发和调试基于GAE的应用,包括用于安全调试的沙盒,SDK和IDE插件等工具。

应用服务器

应用服务器依据其支持语言的不同而有不同的实现。

Python的实现

Python版应用服务器的基础就是普通的Python 2.5.2版的Runtime,并考虑在在未来版本中添加对Python 3的支持,但是因为Python 3对Python而言,就好比Java2之于Java1,跨度非常大,所以引入Python3的难度很大。在Web技术方面,支持诸如Django,CherryPy,Pylons和Web2py等Python Web框架,并自带名为"WSGI"的CGI框架。虽然Python版应用服务器是基于标准的Python Runtime,但是为了安全并更好地适应App Engine的整体架构,对运行在应用服务器内的代码设置了很多方面的限制,比如不能加载用C编写Python模块和无法创建Socket等。

Java的实现

在实现方面,Java版应用服务器和Python版基本一致,也是基于标准的Java Web容器,而且选用了轻量级的Jetty技术,并跑在Java 6上。通过这个Web容器不仅能运行常见的Java Web 技术,包括Servlet,JSP,JSTL和GWT等,而且还能跑大多数常用的Java API(App Engine有一个The JRE Class White List来定义那些Java API能在App Engine的环境中被使用)和一些基于JVM的脚本语言,例如JavaScript,Ruby或Scala等,但同样无法创建Socket和Thread,或者对文件进行读写,也不支持一些比较高阶的API和框架,包括JDBC,JSF,Struts 2,RMI,JAX-RPC和Hibernate等。

Datastore

Datastore提供了一整套强大的分布式数据存储和查询服务,并能通过水平扩展来支撑海量的数据。但Datastore并不是传统的关系型数据库,它主要以"Entity"的形式存储数据,一个Entity包括一个Kind(在概念上和数据库的Table比较类似)和一系列属性。

Datastore提供强一致性和乐观(optimistic)同步控制,而在事务方面,则支持本地事务,也就是在只能同一个Entity Group内执行事务。

在接口方面,Python版提供了非常丰富的接口,而且还包括名为GQL的查询语言,而Java版则提供了标准的JDO和JPA这两套API。

而且Google已经在今年的Google I/O大会上宣布将在未来的App Engine for Business套件中包含标准的SQL数据库服务,但现在还不确定这个SQL数据库的实现方式,是基于开源的MySQL技术,还是基于其私有的实现,这是一个问题。

服务

Memcache

Memcache是大中型网站所备的服务,主要用来在内存中存储常用的数据,而App Engine也包含了这个服务。有趣的是App Engine的Memcache也是由Brad Fitzpatrick开发。

URL抓取(Fetch)

App Engine的应用可以通过URL抓取这个服务抓取网上的资源,并可以这个服务来与其他主机进行通信。这样避免了应用在Python和Java环境中无法使用Socket的尴尬。

Email

App Engine应用使用这个服务来利用Gmail的基础设施来发送电子邮件。

计划任务(Cron)

计划服务允许应用在指定时间或按指定间隔执行其设定的任务。这些任务通常称为Cron job。

图形

App Engine 提供了使用专用图像服务来操作图像数据的功能。图像服务可以调整图像大小,旋转、翻转和裁剪图像。它还能够使用预先定义的算法提升图片的质量。

用户认证

App Engine的应用可以依赖Google帐户系统来验证用户。App Engine还将支持OAuth。

XMPP

在App Engine上运行的程序能利用XMPP服务和其他兼容XMPP的IM服务(比如Google Talk)进行通信。

任务队列(Task Queue)

App Engine应用能通过在一个队列插入任务(以Web Hook的形式)来实现后台处理,而且App Engine会根据调度方面的设置来安排这个队列里面的任务执行。

Blobstore

因为Datastore最多支持存储1MB大小的数据对象,所以App Engine推出了Blobstore服务来存储和调用那些大于1MB但小于2G的二进制数据对象。

Mapper

Mapper可以认为就是"Map Reduce"中的Map,也就是能通过Mapper API对大规模的数据进行平行的处理,这些数据可以存储在Datastore或者Blobstore,但这个功能还处于内部开发阶段。

Channel

其实Channel就是我们常说的"Comet",通过Channel API能让应用将内容直接推至用户的浏览器,而不需常见的轮询。

除了Java版的Memcache,Email和URL抓取都是采用标准的API之外,其他服务无论是Java版还是Python版,其API都是私有的,但是提供了丰富和细致的文档来帮助用户使用。

管理界面

用了让用户更好地管理应用,Google提供了一整套完善的管理界面,地址是http://appengine.google.com/ ,而且只需用户的Google帐户就能登录和使用。下图为其截屏:

Dashboard.PNG 图1. 管理界面(点击看大图)

使用这个管理界面可执行许多操作,包括创建新的应用程序,为这个应用设置域名,查看与访问数据和错误相关的日志,观察主要资源的使用状况。

本地开发环境

为了安全起见,本地开发环境采用了沙箱(Sandbox)模式,基本上和上面提到的应用服务器的限制差不多,比如无法创建Socket和Thread,也无法对文件进行读写。Python版App Engine SDK是以普通的应用程序的形式发布,本地需要安装相应的Python Runtime,通过命令行方式启动Python版的Sandbox,同时也可以在安装有PyDev插件的Eclipse上启动。Java版App Engine SDK是以Eclispe Plugin形式发布,只要用户在他的Eclipse上安装这个Plugin,用户就能启动本地Java沙箱来开发和调试应用。

编程模型

因为App Engine主要为了支撑Web应用而存在,所以Web层编程模型对于App Engine也是最关键的。App Engine主要使用的Web模型是CGI,CGI全称为"Common Gateway Interface",它的意思非常简单,就是收到一个请求,起一个进程或者线程来处理这个请求,当处理结束后这个进程或者线程自动关闭,之后是不断地重复这个流程。由于CGI这种方式每次处理的时候,都要重新起一个新的进程或者线程,可以说在资源消耗方面还是很厉害的,虽然有线程池(Thread Pool)这样的优化技术。但是由于CGI在架构上的简单性使其成为GAE首选的编程模型,同时由于CGI支持无状态模式,所以也在伸缩性方面非常有优势。而且App Engine的两个语言版本都自带一个CGI框架:在Python平台为WSGI。在Java平台则为经典的Servlet。最近,由于App Engine引入了计划任务和任务队列这两个特性,所以App Engine已经支持计划任务和后台进程这两种编程模型。

限制和资费

首先,谈一下App Engine的使用限制,具体请看下表:

类别 限制
每个开发者所拥有的项目 10个
每个项目的文件数 1000个
每个项目代码的大小 150MB
每个请求最多执行时间 30秒
Blobstore(二进制存储)的大小 1GB
HTTP Response的大小 10MB
Datastore中每个对象的大小 1MB

表1. App Engine的使用限制

虽然这些限制对开发者是一种障碍,但对App Engine这样的多租户环境而且却是非常重要的,因为如果一个租户的应用消耗过多的资源的话,将会影响到在临近应用的正常使用,而App Engine上面这些限制就是为了是运行在其平台上面应用能安全地运行着想,避免了一个吞噬资源或恶性的应用影响到临近应用的情况。除了安全的方面考虑之后,还有伸缩的原因,也就是说,当一个应用的所占空间(footprint)处于比较低的状态,比如少于1000个文件和大小低于150MB等,那么能够非常方便地通过复制应用来实现伸缩。

接着,谈一下资费情况,App Engine的资费情况主要有两个特点:其一是免费额度高,现有免费的额度能支撑一个中型网站的运行,且不需付任何费用。其二是资费项目非常细粒度,普通IaaS服务资费,主要就是CPU,内存,硬盘和网络带宽这四项,而App Engine则除了常见的CPU和网络带宽这两项之外,还包括很多应用级别的项目,比如:Datastore API和邮件API的调用次数等。具体资费的机制是这样的:如果用户的应用每天消费的各种资源都低于这个额度,那们用户无需支付任何费用,但是当免费额度被超过的时候,用户就需要为超过的部分付费。因为App Engine整套资费标准比较复杂,所以在这里就主要介绍一下它的免费额度,具体请看下表:

类型 数量(每天)
邮件API调用 7000次
传出(outbound)带宽 10G
传入(inbound)带宽 10G
CPU时间 46个小时
HTTP请求 130万次
Datastore API 1000万次
存储的数据 1G
URL抓取的API 657千次

表2. App Engine的免费额度表

从上面免费额度来看,除了存储数据的容量外,其它都是非常强大的。

本篇结束,下篇将对App Engine的架构进行介绍。

--EOF--

按:此为客座博文系列。投稿人吴朱华曾在IBM中国研究院从事与云计算相关的研究,现在正致力于研究云计算技术。

本文是基于现有的公开资料和个人的经验来对Google的整体架构进行总结和猜想。

在软件工程界,大家有一个共识,那就是"需求决定架构",也就是说,架构的发展是为了更好地支撑应用。那么本文在介绍架构之前,先介绍一下Google所提供的主要产品有哪些?

产品

对于Google和它几个主要产品,比如搜索和邮件等,大家已经非常熟悉了,但是其提供服务的不只于此,并主要可分为六大类:

  • 各种搜索:网页搜索,图片搜索和视频搜索等。
  • 广告系统:AdWords和AdSense。
  • 生产力工具:Gmail和Google Apps等。
  • 地理产品:地图,Google Earth和Google Sky等。
  • 视频播放:Youtube。
  • PaaS平台:Google App Engine。

设计理念

根据现有的资料,Google的设计理念主要可以总结出下面这六条:

  • Scale,Scale,Scale Scale:因为Google大多数服务所面对的客户都是百万级别以上的,导致Scale也就是伸缩已经深深植入Google的DNA中,而且Google为了帮助其开发人员更好地开发分布式应用和服务,不仅研发了用于大规模数据处理MapReduce框架,还推出了用于部署分布式应用的PaaS平台Google App Engine。
  • 容错:一个分布式系统,就算是构建在昂贵的小型机或者大型机之上,也会不时地出现软件或者硬件方面的错误,何况Google的分布式系统还是浇筑在便宜的X86服务器之上,即使其设备标称的MTBF(平均故障间隔时间)很高,但是由于一个集群内的设备极多,导致其错误发生的几率非常高,比如李开复曾经提过这样一个例子:在一个拥有两万台X86服务器的集群中,每天大约有110台机器会出现宕机等恶劣情况,所以容错是一个不可被忽视的问题,同时这点也被Google院士Jeffrey Dean在多次演讲中提到。
  • 低延迟:延迟是影响用户体验的一个非常重要的因素,Google的副总裁Marissa Mayer曾经说过:"如果每次搜索的时间多延迟半秒的话,那么使用搜索服务的人将减少20%",从这个例子可以看出,低延迟对用户体验非常关键,而且为了避免光速和复杂网络环境造成的延时,Google已在很多地区设置了本地的数据中心。
  • 廉价的硬件和软件:由于Google每天所处理的数据和请求在规模上是史无前例的,所以现有的服务器和商业软件厂商是很难为Google"度身定做"一套分布式系统,而且就算能够设计和生产出来,其价格也是Google所无法承受的,所以其上百万台服务器基本采用便宜的X86系统和开源的Linux,并开发了一整套分布式软件栈,其中就包括上篇提到的MapReduce,BigTable和GFS等。
  • 优先移动计算:虽然随着摩尔定律的不断发展,使得很多资源都处于不断地增长中,比如带宽等,但是到现在为止移动数据成本远大于移动计算的成本,所以在处理大规模数据的时候,Google还是倾向于移动计算,而不是移动数据。
  • 服务模式:在Google的系统中,服务是相当常用的,比如其核心的搜索引擎需要依赖700-1000个内部服务,而且服务这种松耦合的开发模式在测试,开发和扩展等方面都有优势,因为它适合小团队开发,并且便于测试。

整体架构的猜想

在整体架构这部分,首先会举出Google的三种主要工作负载,接着会试着对数据中心进行分类,最后会做一下总结。

三种工作负载

对于Google而言,其实工作负载并不仅仅只有搜索这一种,主要可以被分为三大类:

  • 本地交互:用于在用户本地为其提供基本的Google服务,比如网页搜索等,但会将内容的生成和管理工作移交给下面的内容交付系统,比如:生成搜索所需的Index等。通过本地交互,能让用户减少延迟,从而提高用户体验,而且其对SLA要求很高,因为是直接面对客户的。
  • 内容交付:用于为Google大多数服务提供内容的存储,生成和管理工作,比如创建搜索所需的Index,存储YouTube的视频和GMail的数据等,而且内容交互系统主要基于Google自己开发那套分布式软件栈。还有,这套系统非常重视吞吐量和成本,而不是SLA。
  • 关键业务:主要包括Google一些企业级事务,比如用于企业日常运行的客户管理和人力资源等系统和赚取利润的广告系统(AdWords和AdSense),同时关键业务对SLA的要求非常高。

两类数据中心

按照2008年数据,Google在全球有37个数据中心,其中19个在美国,12个在欧洲,3个在亚洲(北京、香港、东京),另外3个分布于俄罗斯和南美。下图显示其中36个数据中心在全球的分布:

pingdom_google_map_worldwide.jpg 图1. 2008年Google全球数据中心分布图

根据 Jeffrey Dean 在2009年末的一次演讲和最近几期季报可以推测出Google并没有在2009年过多地增加全球数据中心的数量,总数应该还是稍多于36个,但很有可能在台湾、马来西亚、立陶宛等地增加新的数据中心。

虽然Google拥有数据中心数量很多,但是它们之间存在一定的差异,而且主要可以分为两类:其一是巨型数据中心,其二是大中型数据中心。

巨型数据中心:服务器规模应该在十万台以上,常坐落于发电厂旁以获得更廉价的能源,主要用于Google内部服务,也就是内容交付服务,而且在设计方面主要关注成本和吞吐量,所以引入了大量的定制硬件和软件,来减低PUE并提升处理量,但其对SLA方面要求不是特别严厉,只要保证绝大部分时间可用即可。下图是Google巨型数据中心的一个代表,这个数据中心位于美国俄勒冈州北部哥伦比亚河畔的Dalles市,总占地面积接近30英亩,并占用了附近一个1.8GW水力发电站的大部分电力输出,当这个数据中心全部投入使用后,将消耗103兆瓦的电力,这相当于一个中小型城市的整个生活用电。

google DC.jpg

图2. Google在美国俄勒冈州哥伦比亚河畔的巨型数据中心近景图

大中型数据中心:服务器规模在千台至万台左右,可用于本地交互或者关键业务,在设计方面上非常重视延迟和高可用性,使得其坐落地点尽可能地接近用户而且采用了标准硬件和软件,比如Dell的服务器和MySQL的数据库等,常见的PUE大概在1.5和1.9之间。本来坐落于北京朝阳区酒仙桥附近的"世纪互联"机房的Google中国数据中心也属于大中型数据中心这类,其采用的硬件有DELL的工作站和Juniper的防火墙等,下图为其一角。

2008421124418.jpg

图3. Google前中国数据中心的一角(参[26])

关于两者的区别:具体请查看下表:

  巨型数据中心 大中型数据中心
工作负载 内容交付 本地交互/关键业务
地点 离发电厂近 离用户近
设计特点 高吞吐,低成本 低延迟,高可用性
服务器定制化
SLA 普通
服务器数量 十万台以上 千台以上
数据中心数量 十个以内 几十个
PUE估值 1.2 1.5

表1. 巨型与大中型数据中心的对比表

总结

最后,稍微总结一下,首先,普通的用户当访问Google服务时,大多会根据其请求的IP地址或者其所属的ISP将这个请求转发到用户本地的数据中心,如果本地数据中心无法处理这个请求,它很有可能将这个请求转发给远端的内容交互中心。其次,当广告客户想接入Google的广告系统时,这个请求会直接转发至其专业的关键业务数据中心来处理。

google architecture.PNG

图4. 总结

因为本文是基于现有的公开资料和个人的经验的总结和猜想,所以和Google实际的运行情况没有任何联系。

本篇结束,下篇将对Google App Engine及其主要组成部分进行介绍。

--EOF--

按:此为客座博文系列。投稿人吴朱华曾在IBM中国研究院从事与云计算相关的研究,现在正致力于研究云计算技术。

本系列文章基于公开资料对Google App Engine的实现机制这个话题进行深度探讨。在切入Google App Engine之前,首先会对Google的核心技术和其整体架构进行分析,以帮助大家之后更好地理解Google App Engine的实现。

本篇将主要介绍Google的十个核心技术,而且可以分为四大类:

  • 分布式基础设施:GFS、Chubby 和 Protocol Buffer。
  • 分布式大规模数据处理:MapReduce 和 Sawzall。
  • 分布式数据库技术:BigTable 和数据库 Sharding。
  • 数据中心优化技术:数据中心高温化、12V电池和服务器整合。

分布式基础设施

GFS

由于搜索引擎需要处理海量的数据,所以Google的两位创始人Larry Page和Sergey Brin在创业初期设计一套名为"BigFiles"的文件系统,而GFS(全称为"Google File System")这套分布式文件系统则是"BigFiles"的延续。

首先,介绍它的架构,GFS主要分为两类节点:

  • Master节点:主要存储与数据文件相关的元数据,而不是Chunk(数据块)。元数据包括一个能将64位标签映射到数据块的位置及其组成文件的表格,数据块副本位置和哪个进程正在读写特定的数据块等。还有Master节点会周期性地接收从每个Chunk节点来的更新("Heart-beat")来让元数据保持最新状态。
  • Chunk节点:顾名思义,肯定用来存储Chunk,数据文件通过被分割为每个默认大小为64MB的Chunk的方式存储,而且每个Chunk有唯一一个64位标签,并且每个Chunk都会在整个分布式系统被复制多次,默认为3次。

下图就是GFS的架构图:

Google-file-system.png

图1. GFS的架构图(参片[15])

接着,在设计上,GFS主要有八个特点:

  • 大文件和大数据块:数据文件的大小普遍在GB级别,而且其每个数据块默认大小为64MB,这样做的好处是减少了元数据的大小,能使Master节点能够非常方便地将元数据放置在内存中以提升访问效率。
  • 操作以添加为主:因为文件很少被删减或者覆盖,通常只是进行添加或者读取操作,这样能充分考虑到硬盘线性吞吐量大和随机读写慢的特点。
  • 支持容错:首先,虽然当时为了设计方便,采用了单Master的方案,但是整个系统会保证每个Master都会有其相对应的复制品,以便于在Master节点出现问题时进行切换。其次,在Chunk层,GFS已经在设计上将节点失败视为常态,所以能非常好地处理Chunk节点失效的问题。
  • 高吞吐量:虽然其单个节点的性能无论是从吞吐量还是延迟都很普通,但因为其支持上千的节点,所以总的数据吞吐量是非常惊人的。
  • 保护数据:首先,文件被分割成固定尺寸的数据块以便于保存,而且每个数据块都会被系统复制三份。
  • 扩展能力强:因为元数据偏小,使得一个Master节点能控制上千个存数据的Chunk节点。
  • 支持压缩:对于那些稍旧的文件,可以通过对它进行压缩,来节省硬盘空间,并且压缩率非常惊人,有时甚至接近90%。
  • 用户空间:虽然在用户空间运行在运行效率方面稍差,但是更便于开发和测试,还有能更好利用Linux的自带的一些POSIX API。

现在Google内部至少运行着200多个GFS集群,最大的集群有几千台服务器,并且服务于多个Google服务,比如Google搜索。但由于GFS主要为搜索而设计,所以不是很适合新的一些Google产品,比YouTube、Gmail和更强调大规模索引和实时性的Caffeine搜索引擎等,所以Google已经在开发下一代GFS,代号为"Colossus",并且在设计方面有许多不同,比如:支持分布式Master节点来提升高可用性并能支撑更多文件,Chunk节点能支持1MB大小的chunk以支撑低延迟应用的需要。

Chubby

简单的来说,Chubby 属于分布式锁服务,通过 Chubby,一个分布式系统中的上千个client都能够对于某项资源进行"加锁"或者"解锁",常用于BigTable的协作工作,在实现方面是通过对文件的创建操作来实现"加锁",并基于著名科学家Leslie Lamport的Paxos算法。

Protocol Buffer

Protocol Buffer,是Google内部使用一种语言中立、平台中立和可扩展的序列化结构化数据的方式,并提供 Java、C++ 和 Python 这三种语言的实现,每一种实现都包含了相应语言的编译器以及库文件,而且它是一种二进制的格式,所以其速度是使用 XML 进行数据交换的10倍左右。它主要用于两个方面:其一是RPC通信,它可用于分布式应用之间或者异构环境下的通信。其二是数据存储方面,因为它自描述,而且压缩很方便,所以可用于对数据进行持久化,比如存储日志信息,并可被Map Reduce程序处理。与Protocol Buffer比较类似的产品还有Facebook的 Thrift ,而且 Facebook 号称Thrift在速度上还有一定的优势。

分布式大规模数据处理

MapReduce

首先,在Google数据中心会有大规模数据需要处理,比如被网络爬虫(Web Crawler)抓取的大量网页等。由于这些数据很多都是PB级别,导致处理工作不得不尽可能的并行化,而Google为了解决这个问题,引入了MapReduce这个编程模型,MapReduce是源自函数式语言,主要通过"Map(映射)"和"Reduce(化简)"这两个步骤来并行处理大规模的数据集。Map会先对由很多独立元素组成的逻辑列表中的每一个元素进行指定的操作,且原始列表不会被更改,会创建多个新的列表来保存Map的处理结果。也就意味着,Map操作是高度并行的。当Map工作完成之后,系统会先对新生成的多个列表进行清理(Shuffle)和排序,之后会这些新创建的列表进行Reduce操作,也就是对一个列表中的元素根据Key值进行适当的合并。

下图为MapReduce的运行机制:

Map Reduce.PNG

图2. MapReduce的运行机制(参[19])

接下来,将根据上图来举一个MapReduce的例子:比如,通过搜索Spider将海量的Web页面抓取到本地的GFS集群中,然后Index系统将会对这个GFS集群中多个数据Chunk进行平行的Map处理,生成多个Key为URL,value为html页面的键值对(Key-Value Map),接着系统会对这些刚生成的键值对进行Shuffle(清理),之后系统会通过Reduce操作来根据相同的key值(也就是URL)合并这些键值对。

最后,通过MapReduce这么简单的编程模型,不仅能用于处理大规模数据,而且能将很多繁琐的细节隐藏起来,比如自动并行化,负载均衡和机器宕机处理等,这样将极大地简化程序员的开发工作。MapReduce可用于包括"分布grep,分布排序,web访问日志分析,反向索引构建,文档聚类,机器学习,基于统计的机器翻译,生成Google的整个搜索的索引"等大规模数据处理工作。Yahoo也推出MapReduce的开源版本Hadoop,而且Hadoop在业界也已经被大规模使用。

Sawzall

Sawzall可以被认为是构建在MapReduce之上的采用类似Java语法的DSL(Domain-Specific Language),也可以认为它是分布式的AWK。它主要用于对大规模分布式数据进行筛选和聚合等高级数据处理操作,在实现方面,是通过解释器将其转化为相对应的MapReduce任务。除了Google的Sawzall之外,yahoo推出了相似的Pig语言,但其语法类似于SQL。

分布式数据库技术

BigTable

由于在Google的数据中心存储PB级以上的非关系型数据时候,比如网页和地理数据等,为了更好地存储和利用这些数据,Google开发了一套数据库系统,名为"BigTable"。BigTable不是一个关系型的数据库,它也不支持关联(Join)等高级SQL操作,取而代之的是多级映射的数据结构,并是一种面向大规模处理、容错性强的自我管理系统,拥有TB级的内存和PB级的存储能力,使用结构化的文件来存储数据,并每秒可以处理数百万的读写操作。

什么是多级映射的数据结构呢?就是一个稀疏的,多维的,排序的Map,每个Cell由行关键字,列关键字和时间戳三维定位.Cell的内容是一个不解释的字符串,比如下表存储每个网站的内容与被其他网站的反向连接的文本。 反向的URL com.cnn.www是这行的关键字;contents列存储网页内容,每个内容有一个时间戳,因为有两个反向连接,所以archor的Column Family有两列:anchor: cnnsi.com和anchhor:my.look.ca。Column Family这个概念,使得表可以轻松地横向扩展。下面是它具体的数据模型图:

Big Table Model.PNG

图3. BigTable数据模型图(参[4])

在结构上,首先,BigTable基于GFS分布式文件系统和Chubby分布式锁服务。其次BigTable也分为两部分:其一是Master节点,用来处理元数据相关的操作并支持负载均衡。其二是tablet节点,主要用于存储数据库的分片tablet,并提供相应的数据访问,同时Tablet是基于名为SSTable的格式,对压缩有很好的支持。

BigTable.PNG

图4. BigTable架构图(参[15])

BigTable正在为Google六十多种产品和项目提供存储和获取结构化数据的支撑平台,其中包括有Google Print、 Orkut、Google Maps、Google Earth和Blogger等,而且Google至少运行着500个BigTable集群。

随着Google内部服务对需求的不断提高和技术的不断地发展,导致原先的BigTable已经无法满足用户的需求,而Google也正在开发下一代BigTable,名为"Spanner(扳手)",它主要有下面这些BigTable所无法支持的特性:

  • 支持多种数据结构,比如table,familie,group和coprocessor等。
  • 基于分层目录和行的细粒度的复制和权限管理。
  • 支持跨数据中心的强一致性和弱一致性控制。
  • 基于Paxos算法的强一致性副本同步,并支持分布式事务。
  • 提供许多自动化操作。
  • 强大的扩展能力,能支持百万台服务器级别的集群。
  • 用户可以自定义诸如延迟和复制次数等重要参数以适应不同的需求。

数据库Sharding

Sharding就是分片的意思,虽然非关系型数据库比如BigTable在Google的世界中占有非常重要的地位,但是面对传统OLTP应用,比如广告系统,Google还是采用传统的关系型数据库技术,也就是MySQL,同时由于Google所需要面对流量非常巨大,所以Google在数据库层采用了分片(Sharding)的水平扩展(Scale Out)解决方案,分片是在传统垂直扩展(Scale Up)的分区模式上的一种提升,主要通过时间,范围和面向服务等方式来将一个大型的数据库分成多片,并且这些数据片可以跨越多个数据库和服务器来实现水平扩展。

Google整套数据库分片技术主要有下面这些优点:

  • 扩展性强:在Google生产环境中,已经有支持上千台服务器的MySQL分片集群。
  • 吞吐量惊人:通过巨大的MySQL分片集群能满足巨量的查询请求。
  • 全球备份:不仅在一个数据中心还是在全球的范围,Google都会对MySQL的分片数据进行备份,这样不仅能保护数据,而且方便扩展。

在实现方面,主要可分为两块:其一是在MySQL InnoDB基础上添加了数据库分片的技术。其二是在ORM层的Hibernate的基础上也添加了相关的分片技术,并支持虚拟分片(Virtual Shard)来便于开发和管理。同时Google也已经将这两方面的代码提交给相关组织。

数据中心优化技术

数据中心高温化

大中型数据中心的PUE(Power Usage Effectiveness)普遍在2左右,也就是在服务器等计算设备上耗1度电,在空调等辅助设备上也要消耗一度电。对一些非常出色的数据中心,最多也就能达到1.7,但是Google通过一些有效的设计使部分数据中心到达了业界领先的1.2,在这些设计当中,其中最有特色的莫过于数据中心高温化,也就是让数据中心内的计算设备运行在偏高的温度下,Google的能源方面的总监Erik Teetzel在谈到这点的时候说:"普通的数据中心在70华氏度(21摄氏度)下面工作,而我们则推荐80华氏度(27摄氏度)"。但是在提高数据中心的温度方面会有两个常见的限制条件:其一是服务器设备的崩溃点,其二是精确的温度控制。如果做好这两点,数据中心就能够在高温下工作,因为假设数据中心的管理员能对数据中心的温度进行正负1/2度的调节,这将使服务器设备能在崩溃点5度之内工作,而不是常见的20度之内,这样既经济,又安全。还有,业界传言Intel为Google提供抗高温设计的定制芯片,但云计算界的顶级专家James Hamilton认为不太可能,因为虽然处理器也非常惧怕热量,但是与内存和硬盘相比还是强很多,所以处理器在抗高温设计中并不是一个核心因素。同时他也非常支持使数据中心高温化这个想法,而且期望将来数据中心甚至能运行在40摄氏度下,这样不仅能节省空调方面的成本,而且对环境也很有利。

12V电池

由于传统的UPS在资源方面比较浪费,所以Google在这方面另辟蹊径,采用了给每台服务器配一个专用的12V电池的做法来替换了常用的UPS,如果主电源系统出现故障,将由该电池负责对服务器供电。虽然大型UPS可以达到92%到95%的效率,但是比起内置电池的99.99%而言是非常捉襟见肘的,而且由于能量守恒的原因,导致那么未被UPS充分利用的电力会被转化成热能,这将导致用于空调的能耗相应地攀升,从而走入一个恶性循环。同时在电源方面也有类似的"神来之笔",普通的服务器电源会同时提供5V和12V的直流电。但是Google设计的服务器电源只输出12V直流电,必要的转换在主板上进行,虽然这种设计会使主板的成本增加1美元到2美元,但是它不仅能使电源能在接近其峰值容量的情况下运行,而且在铜线上传输电流时效率更高。

服务器整合

谈到虚拟化的杀手锏时,第一个让人想到肯定是服务器整合,而且普遍能实现1:8的整合率来降低各方面的成本。有趣的是,Google在硬件方面也引入类似服务器整合的想法,它的做法是在一个机箱大小的空间内放置两台服务器,这些做的好处有很多,首先,减小了占地面积。其次,通过让两台服务器共享诸如电源等设备,来降低设备和能源等方面的投入。

本篇结束,下篇将猜想一下Google整体架构。

--EOF--

从 Reddit 学到的经验

最近有一些比较有价值的文章似乎没引起太多人注意,比如 Steve Huffman 分享创建 Reddit 过程中的经验这篇文章,在 Twitter 上的中文技术圈子似乎没有被提及。150px-Reddit_logo.svg.png

作为社会化新闻站点,国内似乎关注 Reddit 的人并不多,我只知道少数 Geek 是其死忠粉丝。Reddit 在 2005 年 6 月由 Steve Huffman 与 Alexis Ohanian 创建,之后在 2007 年被 Condé Nast 收购。到现在看 Alexa 排名在 300 名之内。

根据维基百科的介绍(refer):Reddit 最早是用 Common Lisp 开发,随之用 Python 进行了重写(2005年底完成)。著名的Python 框架 Web.py 就是 Reddit 当时的员工 Aaron Swartz 开发的,现在 Reddit 的 Web 框架则使用了 Pylons 。在 2009 年 11 月,Reddit 迁移到 Amazon 的云计算平台。前端框架现在用的是 jQuery。或许你早就知道,Reddit 网站程序现在已经开源,如果你感兴趣的话,不妨下载研究。

严格来说,Steve 的这个演讲其实并没有涉及多深入的技术信息,只是这几条经验的确可以作为通用规则与大家分享。

  • 宕机是家常便饭(Crash Often)
    可能很多人会认为一些 Startup 的创建人都是天才,其实也未必。两个22岁的初出茅庐的大学毕业生写的程序会好到哪里?网站起步的时候,频繁的宕机让他们吃尽了苦头。其实 Twitter 以及最近热火的 FourSquare 在初期的稳定性也不怎么样,但是仍然能对用户产生足够的吸引力。这是很多创业者需要细思量之处。
  • 服务分离( Separation of Services)
    现在已经超过 20 台数据库,每个数据库只处理一种特定类型的数据,原因无他,更为简化。另外,Reddit 得到的一个经验是不要使用 Python 的线程,而是用多进程的方式。
  • 开放 Schema(Open Schema)
    个人觉得,应该叫 Key-Value 更恰当。
  • 无状态处理请求(Keep it Stateless)
    "无状态"意味着横向扩展更为容易。单节点服务器向多台扩展,或许这是第一个要考虑的问题。否则,背的包袱就会越来越重。
  • Memcached
    除了尽可能的利用 Memcached 加速用户对数据的访问速度,在 Memcached 中存储了大量预生成的页面内容,另外,也在适当的场景使用了 MemcacheDB 以满足数据持久化的需要。
  • 存储冗余数据(Store Redundant Data)
    让站点变得更慢的一个"好办法"就是遵循范式设计数据库。除了在 RDBMS 中存储数据外,在上一条提到的 MemcacheDB 中也存储了大量数据,和收益相比,冗余的成本并不高。前提是数据一致性要能得到有效保证。
  • 脱机工作(Work Offline)
    尽可能的异步处理用户操作,对计算量比较大的功能利用离线计算的模式。消息队列用用 RabbitMQ(Rabbit Technologies Ltd.已经被 SpringSource 收购) ,采用了 AMQP 协议。

或许还有意犹未尽之处,各位自己顺着文章来源分析吧。Reddit 就像一个技术标本,仔细琢磨下去还会有很多有趣的地方,相信也会对你有帮助。

--EOF--

按:此为客座博文系列。投稿人吴朱华,曾在IBM中国研究院从事与云计算相关的研究,现在则致力于研发下一代云计算系统,撰写一些与云计算相关的文章,他的个人站点: PeopleYun.com。(文章版权属于原作者,转载请勿混淆。本篇原文地址)

本篇是本系列最终章,将会首先总结了Force.com的设计理念,之后会对整个系列进行总结。

设计理念

根据 Craig Weissman 的演讲和几份官方的白皮书,在Force.com的设计方面Salesforce团队主要有下面这五大考量:

  • 数据驱动:由于 Salesforce 主要面向企业用户,导致其上面运行的应用,无论是 CRM ,还是报表工具,都是以数据的CRUD(增删改查)为核心,所以 Force.com 需要由数据来驱动,而且也需要为此做一定程度的优化。
  • 规模经济:由于需要在低价格和灵活付费的基础上提供可定制化应用,所以需要让尽可能多用户共享同一套系统,来大幅减低基础设施和管理等资源的投入,并实现规模经济的效益。
  • 安全为先:由于在一套物理设备上将承载数以万计客户的企业级应用,那么如果出现严重的程序错误或者数据方面遗失或者错乱,将会发生非常严重的后果,所以安全问题是一个 Salesforce绝不能轻视的问题。
  • 定制方便:虽然各个企业都会存在一部分比较通用的流程,但是每个企业都可能存在一部分私有或者独特的流程,所以Force.com需要提供方便的定制功能来帮助用户将更快捷地将企业的业务迁移到其上。
  • 功能丰富:虽然用户能在 Force.com 上进行开发和定制,但是如果 Force.com 能提供更多的功能模块或者能让用户购买和整合第三方的应用将非常有效地帮助用户开发应用。

虽然这些设计理念说起来很容易,但是实现起来是非常艰难的。可贵地是,Salesforce 团队在开发 Force.com 的过程中基本实现了这些设计理念。

总结

关于本系列的总结,也主要包括五个方面:

  • Trade-Off 是难免的:为了满足设计目标,有时不得不做Trade-Off 。由于 Salesforce 所需要承载的多租户应用的规模之大,定制化需求之高都是前所未见的,所以Salesforce并没有采用在第二篇所提到几种常见模型,而是从长计议,采用了更灵活但技术要求更高的 Metadata 方式。 还有为了避免在数据库中执行成本非常高并会 Locking 整个数据库的 DDL(数据库定义语句)操作,所以在 Force.com 运行的时候是无法创建和修改数据库表,而这样将会提升实现的难度。
  • 优化很重要,虽然 Force.com 的多租户架构就像 Java 一样,采用了很多动态生成的机制。很显然,如果像早期的Java那样缺乏优化的话,那么 Force.com 整体的性能将会非常糟糕,从而无法实现其设计要求。但幸运的是,Salesforce 团队不仅做了优化,而且凭借着其很多核心成员来自于 Oracle 的背景,在数据库端做了很多高水平的优化,比如添加了很多貌似累赘的 Pivot 表来加快部分常用数据的读取。
  • 人才很重要:经过本系列的介绍,可以看出 Force.com 的整个架构并不全是在现有的框架和库的基础上构建的,而是为了设计目标开发了很多比较底层和比较复杂的模块,而且这些模块是只有那些顶级的程序员才能编写出来的,所以说如果没有硅谷那个庞大的优秀程序员池,Salesforce 就很难走到今天。
  • 软件是一个进化的工程:刚开始的时候 Salesforce 架构是普普通通的 B/S 架构,但是随着用户不断地提出定制化的要求,Salesforce 也不得不在架构中引入多租户的概念,之后,由于用户需要更灵活的,可伸缩的和功能更强大的平台,导致 Salesforce 不断地对其架构进行重构,到最后,终于整出了 Force.com 这一优秀的 PaaS 平台。
  • 有用的创新才珍贵:Salesforce 不仅在 Force.com 引入很多创新,而且都非常有效。在这些创新当中,最有用的除了 Metadata 驱动这种多租户架构实现机制之外,还有一个名为"回收站(Recycle Bin)"的概念,这个回收站主要存储30天来那些从数据表里面删除的数据,如果用户在30天内发现数据是误删,可以对数据进行恢复,这样既减低数据误删的可能性,而且能回收部分物理资源,比如硬盘空间等。

最后,我想说虽然到现在为止,Salesforce 还不能算是一场巨大的商业胜利,但是它在产品和思路方面有很多值得我们借鉴的地方,这也是我写本文的初衷,并谢谢大家花时间在这个系列上面,希望能对得起大家的时间。还有,如果大家对本系列有什么疑问或者见解,那么就不要吝惜你的时间,请留下你的评论。

本系列参考资料


本系列文章列表

--EOF--

按:此为客座博文系列。投稿人吴朱华,曾在IBM中国研究院从事与云计算相关的研究,现在则致力于研发下一代云计算系统,撰写一些与云计算相关的文章,他的个人站点: PeopleYun.com。(文章版权属于原作者,转载请勿混淆。本篇原文地址)

本篇是上篇的延续,主要是通过对上篇提到的几个模块进行深入地分析。

大规模数据处理引擎

由于Force.com需要处理的数据量不论是来自网页端,还是来自Web Service端都是非常巨大的,所以Salesforce在Force.com中引入了特制的大规模数据处理引擎来处理大量的数据读写和在线事务。它主要有两大特点:其一是对大规模数据处理进行了优化,特别是当一个API调用发来很多待处理的数据时,这个引擎能非常快速地处理。其二是这个引擎内置错误恢复机制,当处理大规模数据时候,假如其中一个步骤发生错误时,这个引擎会捕捉和修复这个错误,并且保持这个步骤之前正确的结果以避免整个重做。

多租户感知的查询优化引擎

大多数现在数据库都自带基于成本的查询优化器,这种优化器主要是基于数据库表和索引数据等相关数值来进行计算和比较。但是由于传统的基于成本的优化器都是主要为单租户的环境设计的,所以他们并不能很好地适应多租户的环境,因为在数据库中是没有多租户这个概念。为了让优化器能够在多租户环境下良好工作,Salesforce在Oracle自带优化器的基础上搭建了一个多租户感知的查询优化引擎,它也主要有两个特点:其一是这个引擎为每个多租户对象维护了一整套便于优化的数据(租户层的,组层的和用户层的)。其二是这个引擎也维护租户和租户下面用户的安全信息,这样不仅能提升了效率,因为能避免将那些不属于这个租户的数据加入到计算,而且能提升数据的安全性。

全文检索引擎

全文检索功能对Web应用而言,基本可以算是一种基本功能,而对基于Force.com的应用而言,同样如此,Force.com为此内置一个全文检索引擎,其是基于大名鼎鼎的Lucene技术。当一个运行在Force.com平台上的应用对数据库中数据进行更新的时候,会有一组称为检索服务器的后台进程来异步更新数据相关的索引。通过这种异步机制不仅能够保证检索工作不影响处理事务的效率,而且同时也能让用户使用到最新的搜索结果。为了优化这个检索流程,系统会同步将修改过的数据复制到一个内部"等待检索"的表,之后检索服务器会访问这个表来进行检索,这样好处是减少了检索服务器的I/O处理量。而且为了更好地适应多租户环境,检索引擎自动为每个租户维护一个独立的索引。

数据库表的设计

下图为Force.com的数据库表结构:

Force DB.PNG

图1. 数据库表的结构(图源自参[4])

Metadata表

Metadata表的作用是存储用户定制的对象和对象所包含的字段的结构信息,不保存具体的数据,主要有两大类:

  • Object Metadata表:这个表主要存储对象的信息,其中主要字段包括对象的ID(ObjID),拥有这个对象的租户的ID(OrgID)和这个对象的名字(ObjName)。
  • Field Metadata表:这个表主要存储对象附带字段的信息,其中主要字段包括字段的ID(FieldID),拥有这个字段的租户的ID(OrgID),这个字段的名字(FieldName),这个字段的数据类型(datatype)和一个布尔字段(IsIndexed)来定义这个字段是否需要被检索。

Data表

Data表的作用和Metadata表正好相反,它主要存储那些用户定制的对象和对象所包含的字段的数据,主要也包括两大类:

  • Data表:这个表放置着上面那些对象和字段所对应的数据,核心字段有全局唯一的ID(GUID),租户ID(OrgID),对象的ID(ObjID)和存放对象名字的"Nature Name(自然名称)",比如这行和一个会计对象有关,这行的""Nature Name"字段可能是"Account Name",除了这些核心字段之外,这个表还有名字从Value0到Value500的501个数据列来存储数据,而且这些列都是varchar的形式来承载不同类型的数据,这种数据列也被称为"flex列"。
  • Clob表:这个表主要存放那些CLOB(Character Large Object,字符大对象)数据,对象最大支持到32000个字符。

Pivot表

Pivot表,也称为"数据透视表",在Force.com中是以denormalized (去规范化)格式存储那些用于特殊目的的数据,比如用于检索(indexing),唯一性和关系等,主要作用是加速这些特殊数据的读取以提升系统整体的性能。主要有五种Pivot表:

  • Index Pivot表:由于Data表里面数据都是以"flex列"的形式存储,所以很难在Data表的基础上对表中的数据进行检索,所以Force.com引入Index Pivot表来解决这个问题,系统在运行的时候会将需要索引的数据从Data表同步到Index Pivot表中相对应的字段来方便检索,比如这个数据的类型是日期型的,那么它将会被同步到Index Pivot表中的日期字段。
  • UniqueFields Pivot表:这个表是用来帮助系统在Data表中字段实现唯一性。
  • Relationships Pivot表:Force.com提供了"Relationship"这个数据类型来定义多个对象之间的关系,而Relationships Pivot表则起到方便和加速"Relationship"数据读取的作用。
  • NameDenorm表:是一个简单的数据表用于存储对象的ID(ObjID)和这个对象的实例的名字,主要让一些仅需获取名字的查询调用,从而让一些简单的查询无需查询规模庞大的Data表。
  • FallbackIndex表:这个表将记录所有对象的名字,来免去成本高昂的"UNION"操作,从而加速查询。

APEX

APEX的语言是为Force.com度身定做的一门语法上类似Java的强类型面向对象语言,主要可以通过APEX在Force.com上创建Web Service,编辑复杂的商业逻辑和整合多个Force.com的模块等。APEX主要以两种方式执行:其一是以单独脚本的形式,按照用户的需要执行。其二是以触发器的形式,当一个特定的数据处理事件发生的之前或者之后,与这个事件绑定的APEX代码将会被执行。而且所有APEX代码将会以Metadata的形式存储在Metadata表内。当一段APEX代码被调用的时候,APEX的翻译器(runtime interpreter)将会从Metadata Cache读取编译之后的APEX代码,而且能够同时被多个租户共享以提升效率。

那么为什么要在Force.com引入APEX这门新的语言,而不是像Google App Engine那样支持已经有一定市场占有率的语言,比如Java和Pyhon。Salesforce的首席架构师在谈到这点时,他提出了一个非常重要的原因,那就是安全,首先,Salesforce会APEX语言度身设计一组管理工具,通过这个工具能够非常方便地监控APEX脚本的执行,并且能知道这个脚本在执行过程所耗费的CPU时间,内存容量和SQL语句的数量等数据来判断是否需要中断这个APEX脚本,以避免影响到属于其他租户的应用,如果中断的话,系统会抛出一个runtime exception给上层的调用者。其次,基于APEX语言的代码能够对其内嵌的SOQL(Sforce Object Query Language)和SOSL(Sforce Object Search Language)进行验证来避免实际运行时出现错误。还有,在安全方面除了APEX自带的功能之外,Salesforce还要求每个上传到Force.com的APEX脚本,都需要自带能覆盖其75%代码的测试用例,这种做法不仅显著地提升APEX代码的质量从而确保平台整体运行的稳定,而且在Force.com自己更新的时候,能使用这些用例来确保新的更新不会影响现有的基于Force.com的应用。

关于Force.com多租户架构的详细介绍已经告一段落,下篇会对本系列所提到的内容进行总结!


本系列文章列表

--EOF--

按:此为客座博文系列。投稿人吴朱华,曾在IBM中国研究院从事与云计算相关的研究,现在则致力于研发下一代云计算系统,撰写一些与云计算相关的文章,他的个人站点: PeopleYun.com。(文章版权属于原作者,转载请勿混淆。本篇原文地址)

由于Force.com所负载的应用不论是在定制方面的灵活性上,还是所承受的负载上,对基于多租户的架构而言,都是史无前例的,导致之前提到的一些模型或者改动已经无法满足要求了,所以Salesforce在Force.com引入了通过Metadata(元数据)驱动的多租户架构来动态生成快速的,可伸缩的和可定制的应用。接下来,将一步步为大家揭开Force.com多租户架构的神秘面纱,首先是它的总体架构。

总体架构

在介绍Force.com的整个架构之前,请看下图,此图是根据Salesforce首席架构师Craig Weissman在2009年旧金山QCon大会上的演讲总结而成。

Force com Architecture new.PNG

图1. Force.com的架构图

首先,在最前面是Gateway(网关),网关将接受所有访问Force.com的请求,无论它是访问Sales Cloud,还是关于第三方定制程序的。接下来,网关会根据这个请求所属的租户把请求转发给对应的POD,什么是POD?简单的来说,POD就是一组集群服务器,每个POD都运行同一套Force.com系统,而且每个POD支持成千上万个租户,Salesforce总共有10多个POD来支撑它所有服务的运营,并把所有租户平衡地分配给每个POD,而且主要通过建立新的POD来支撑新的租户。当POD收到请求之后,POD会先通过其内置的Load Balancer(负载均衡器)来将请求转发给负载略轻的App Server(应用服务器),由于为了简化架构和方便伸缩(Scale),所以应用服务器是Stateless(无状态),而且在一个POD内会有多个应用服务器以应对大规模的请求。最后,当应用服务器在处理请求的时候,如果发现请求所需的数据没有被Cache住的话,应用服务器会调用这个租户所属的Shared DB(共享数据库)来取得相关数据,虽然共享数据库是使用成熟的Oracle数据库产品,但是在数据库表的设计上面为多租户做了很多地优化。

接下来,将介绍Force.com是如何通过Metadata来动态生成和定制应用的。

Metadata驱动

首先,Force.com的Metadata是基于大家非常熟悉的面向对象的概念,所以也可以把Metadata认为是对象,也就是说Force.com是由一个个对象组装而成,而且Force.com中的对象可以是表格,也可以是UI,甚至可以是用户权益等。一个Force.com的对象和这个对象下面的字段可以对应一个数据库的表和这个表的列,而且Force.com对象之间的关系(relationship)在功能上类似于数据库的引用完整性約束(referential integrity constraint),但与数据库中每个数据库表对应于独立的存储地址不同的是,Force.com使用几个共享的大数据库表来作为堆存储(heap storage)来放置所有对象,另外这些存储Metadata的表也被称为"UDD(Universal Data Dictionary)"。

接着,是关于应用的,一个在Force.com上运行的应用实例是通过组合许许多多个对象来生成的,也可以说一个应用实例是使用Metadata来描述的,比如,在应用初始的时候,每个客户都是使用同一个版本和同样规模的对象,而且用户通过添加和更新对象来定制应用,比如增加新的UI和字段等,同时系统会对共享的和定制的对象进行严格地分离,使得既能非常方便地更新共享代码,也能保证某个用户定制过的部分不影响到其他用户。在实现上,Force.com并没有实际地为一个新对象生成一个数据库表,而且以元数据的形式存储在几张大表中,并在运行时候,Force.com会有一套引擎来通过分析数据库中的Metadata来动态生成一个虚拟应用实例和这个应用所需的模块(Virtual Application Componets),比如公共UI(Common Application Screen),定制UI(Tenant-Specific Screen)和其他对象等。

virtual app.png

图2. 虚拟应用模块图(源自参[1])

还有,虽然Metadata驱动这种和Java很类似的动态生成机制在速度上有天生缺陷,但是Force.com也内置与Sun的Hotspot技术有异曲同工之妙的Metadata Cache来加速常用Metadata的读取。

下面,将分别介绍Force.com的两大组成部分:应用服务器和共享数据库。

应用服务器

Force App arch.png

应用服务器主要包括五大核心模块:

  • Metadata Cache:用于存放那些最近用到的和比较常用的Metadata来加速应用的生成。
  • 大规模数据处理引擎:主要用来加速处理大量的数据读写和在线事务。
  • 多租户感知的查询优化引擎:这个引擎将通过维护多租户的信息来帮助Oracle自带的基于成本的查询优化器更好地适应多租户环境。
  • 运行时应用生成器:这个生成器主要根据用户的请求来动态生成应用,并且利用上面提到的查询优化引擎来提升效率。
  • 全文检索引擎:在数据库对数据进行更新的同时,这个引擎会异步更新这个数据的相关索引。

共享数据库

Force DB arch.PNG

图1. Force.com的架构(图源自参[1])

整个共享数据库主要有三种类型的数据库表:

  • Metadata表:主要存放用户定制的对象和对象所包含的字段的结构信息,也被称为"UDD"。
  • 数据表:主要存储那些用户定制的对象和对象所包含的字段的数据。
  • Pivot表:用来维护那些用于检索(indexing),唯一性和关系等denormalized (去规范化)数据以优化系统的效率。

还有,在物理层面,数据库里面所有表格,包括底下的索引,都根据每个租户不同的租户ID(OrgID)来使用Oracle的Hash分区技术进行分区。通过Hash分区这种久经考验的技术能够将大规模的数据平均地分割成多个更小的和更容易管理的分块,从而帮助大数据库系统能够在多租户的环境下提升速度,伸缩性和可用性等。

本篇结束,下篇将主要对应用服务器内部的一些模块(比如查询优化引擎,外部全文检索引擎等)和数据库表的设计进行详细的描述。


本系列文章列表

--EOF--

1 2 3 4 5 6 7 8 9 10 11 12

关于归档

本页包含 Arch 类别下的所有文章.

Database 为下一类别.

回到 首页 查看最近发表的文章或者查看所有 归档文章.