百度技术沙龙第9期内容回顾：App Engine技术应用（含资料下载）

在2010年12月18日第9期的百度技术沙龙活动中，我们请到了百度基础平台部高级软件工程肖伟和新浪SAE经理丛磊，分别分享了百度和新浪的App Engine技术及其应用话题。现在对他们的的分享简单总结如下，并提供相关音视频等资料的下载。

百度应用开发引擎（点击下载相关音视频及文字资料）

在肖伟的演讲中，主要介绍了百度App Engine的项目内容应用以及和其他公司App Engine的不同之处：

经过半年多的推广，百度App Engine已经初见成效，虽然项目名字是Baidu App Engine（BAE），但是和google的GAE内容是完全不一样的，在很多功能上都做了优化，它的定位也是面向企业的云平台服务。它的定义有以下几个方面

面向开发者的单机环境

面向程序执行的分布式环境

面向运维的自动化工具链

面向分布式的多语言编程框架

统一管理百度所有分布式资源

因此对于BAE，大家的理解应该是面向网络的操作系统，而不是一个开发平台。肖伟为了说明这个问题拿了Windows程序来与百度互联网服务比较，从功能、代表产品、开发工具、开发技巧以及运行环境等方面来进行的阐述，为什么把Baidu App Engine称作是一个网络操作系统。通过比较，大家也大概了解了，BAE只是在名字上类似，其实完全是不一样的，百度的产品是解决公司企业问题的云服务。接下来肖伟又开始给大家介绍BAE的使用模式和特点：

统一集群、多产品使用 ；每个产品账号拥有独立的资源 ：CPU、带宽、内存容量、存储容量 等，因此资源可以根据服务热度，动态调整 ；支持传统服务的移植 ：直接移植 ；少量修改移植；

在这之后内，肖伟把BAE和业界其他云服务平台进行了对比，让大家对其优缺点一目了然：

指标\产品	AWS	BAE	GAE
支持的数据量	海量（S3，simpledb）	海量（百度云存储和分布式数据库）	海量（Blob存储，GQL）
分布式支持	无，需要开发者考虑	多进程模型，进程通讯优化	对等服务部署，简单分布式支持
运维灵活性	强	强	弱
复杂运用开发支持	强	强	弱
学习成本	低	低	中
安全性	好	一般	好
成熟度	成熟	不成熟	成熟
基础设施（比如IDC）	亚马逊部署，灵活性不佳	配合产品需求统筹考虑	没这个概念
评价	开发相对复杂运用	开发企业级复杂运用	简单个人运用开发

在进行了对比之后，肖伟宏观的陈述了BAE的架构：

所有云服务资源化，支持多账号限额访问

提供管理这些资源的平台

提供用户使用这些资源的程序运行环境

其它辅助工具

以上就是BAE的一个简单的架构，用户请求传至7层负载之后，就会扔给计算结点，计算结点接到请求就会按部就班的进行处理。如果机器发生变化，比如发生死机或者你进行扩容，我们会有一个定位服务器，服务发生变更就会通知到这里，定位服务器再反馈到7层负载，然后传给计算结点，你就能找到合适的资源进行处理。

对于定位服务器的定义和功能，肖伟是这样解释的：

管理程序启动的进程组，这些进程有可能在本机，有可能在其他机器上；

管理进程组下每个进程的状态和配置；

动态监控进程组下进程的变化；

能将进程变化信息实时推送给监听者；

计划提供DNS服务。

对计算结点，肖伟也进行了说明：

计算结点是用户进程执行的环境 ；

提供多语言支持 ：对于c语言就是虚拟机 ，对于php就是php解释器 ；

提供分布式化支持 ：对虚拟机进程和镜像的调度 ，对php解释器进程（fastcgi）和php代码的调度 。

最后肖伟举例进行说明，首先演示了PhP的架构，解释如何伸缩资源和更新代码的细节问题，以及对进程调度粒度还有如何进行不同服务的进程隔离都做了详细的描述。同时也介绍了分布式数据库、分布式KV存储以及消息队列等等其他功能性服务。目前百度的中小型PhP网站都是用这个PhP框架来做的，并且以前的网站也都挪过来了。但仅是PhP框架还是远远不够的，作为一个搜索引擎公司，怎么把数据分析、大规模计算以及很多很多的C语言、Java等服务统一运维来，天生的分布式化呢，我们目前展开了以下工作，第一就是支持linux老服务迁移 ，第二开发C语言分布式开发框架 。

在讲完PhP之后，肖伟开始向大家介绍他们是如何对C语言进行支持的：

不仅是C语言框架，就是对纯C语言也是支持的。C服务于PhP框架有什么区别呢？就是虚拟机进程取代fastcgi进程，即载体取代载体，fastcgi进程上有PhP编译器来运行PhP，那么虚拟机取代以后也可以运行任何语言。

随后肖伟又列出了二者之间比较的框架并像开始那样对虚拟机框架也进行了演示。并着重解释了虚拟机内的进程通讯及其优化。

在最后，肖伟现场回答了大家在新浪微博上以及现场的提问：

BAE的PhP可以写本地目录吗？

我们的所有文件都可以写本地目录，而且它可以做分布式化，这涉及到运维的策略，有两个方案，第一个是我提供分布式文件系统，通过VFS虚拟文件接口把远程磁盘挂载进来，所有人共享这个磁盘的话，PhP写一个磁盘是可以的，而且也不会因为服务流量的增加而出现瓶颈问题，因为我们的云存储可以多做副本，然后在前面加分布式缓存就能解决；第二就是一些非常大的数据我们通过脚本运维的方式解决，不过要是快的话，我们建议修改以前操作本地数据的API改成我的API，数据我们帮你导过去。因为写本地的数据非常小，能达到一个T就不错了。所以我们允许写本地目录，并有办法把它同步到其他服务器上去。

Fastcgi如何解决PhP依赖文件调度

是require once吗？这个得说清楚，如果是的话，根本不存在依赖的问题，因为我们的代码是存在云端的，如果发现本地缓存没有这段代码的话，会去发请示网络请求所要代码，并加载到本地。如果有的话就可以直接读，跟实际中的用法没有区别。

BAE用的是什么虚拟机？

大家如果仔细看的话，虚拟机只是个幌子，它可以是物理机，之所以我说虚拟机，这是有历史原因的，因为之前提到，并不是所有的服务都可以不用修改的迁移过来，只能利用虚拟机把它的资源利用率提高，其实这个方案不仅是虚拟机能做的，物理机也可以。

Java应用是如何分布式化的？

如果是进程的话，可以用我刚才的这套方案，但是要配合Java的编程框架；另外一个是这样的，比如说JSP，虽然现在还没有做，但是要是做出来的话，还是和fastcgi一样。我们现在还是只做PhP和C的。PhP已经完成，C语言项目正在开展中。

BAE对开发者开放有没有计划表？

之前的介绍中大家已经看到，BAE跟其他产品比较有两点很差，一个是安全性，一个是存储度，现在还是不能推荐给大家用，因为我不相信互联网用户不会搞破坏，只要有人找一个漏洞，我的精力就不能放到继续完善中来，二是不停的解决安全性问题，这对产品的发展没有太大的好处。我们还准备研发一种技术，能够对机器的进程进行监控，并把监控的进程汇报给定位服务器，如果我们做了这个技术以后，Java进程还是可以做的，但是现在还没有考虑。

深入SAE云计算架构(点击下载相关音视频及文字资料)

新浪的SAE技术经理丛磊给我们分享了的是SAE云计算架构的话题。

在之前的一些活动和文章中，已经做过关于新浪SAE相关内容的陈述，这次话题在以前一些表面架构介绍的基础上，又有所深入，进入云服务里面，进行一些更细节具体的介绍。SAE是新浪在2009年11月开始研发的国内公有云计算平台，目的是打造一个Web服务的运行和运营的平台，一直到现在，SAE的发展趋势已经达到预期的目标。

今天SAE话题的主要内容有4个部分：SAE上的云服务（Cloud Sevice）、RDC（ Relational Database Cluster：分布式数据库集群）、MemcacheX（新版分布式缓存）、TaskQueue（异步离线任务队列服务）。

SAE上的云服务（Cloud Sevice）：

SAE和虚拟主机最大的区别就是它提供了特别多的分布式服务供开发者使用，而虚拟主机是没有的。目前新浪要的服务以下内容：PhP、Stor、MemcacheX、Datebase、RDC、TaskQueue、Cron（分布式定时服务，新浪目前采用了一种比paxos级别还要高的算法，目前正在为这种算法申请专利）、DeferredJobs、fetchurl、tmpfs、appconfig、smail、 image、xhprofc等十几项内容。

接下来丛磊同样给我们绘出了SAE的架构图并介绍了用户代码运行的环境：

首先是一个反向代理（Level7 Reverse Proxy）接应外部请求，通过逻辑上的Service Router转发到相应的Web Service Pools（阿帕奇的进程池）上，然后往外延伸至四个主要服务分类：同步计算云、异步计算云、可持久化存储、非可持久化存储。这四个服务分类最后会统一向统计中心和日志汇报。
用户代码运行环境App Sandbox组成由内到外分别为：User App、PhP Zend、SAE Zend Sandbox、Apache with SAE Appconfig、Http Sever Sandbox、POSIX Environment。

然后接下来在话题分享中，丛磊把RDC（ Relational Database Cluster：分布式数据库集群）、MemcacheX（新版分布式缓存）、TaskQueue（异步离线任务队列服务）这三个重点给大家做了详细的介绍。

RDC（ Relational Database Cluster）：

是一种面向公有云计算服务的数据集群，它的主要目标或者功能如下：

1．监控百万数量级的DB，包括心跳检查、主从同步检查、节点负载；

2．管理百万数量级的DB，包括启动、停止、迁移、重启、切换；

3．被动复制模式的HA；

4．支持MySQL5通讯协议，代理层完全透明，代理损耗低；

5．无状态依赖，自身支持水平扩展；

6．提供用户的DB的隔离性，保证整体集群的安全性。

之后，丛磊又向大家介绍了RDC与SQL在实现上的不同，并特别指出：

1．RDC不负责用户数据库的水平扩展，所以水平扩展需要用户自己做分表；

2．RDC自身提供一主多从的DB结构，上层支持读写分离；

3．为了整个数据库平台的安全和可靠，RDC会根据自身的预判算法预先屏蔽某些SQL语句，目前这个预判算法新浪也正在准备申请专利；

4．RDC强烈建议用户使用正确的MySQL调用习惯，对每个MySQL函数判断返回值。

介绍这些之后，丛磊又跟大家分享了RDC的结构、用法以及其运行环境要求等。然后进入第二个重点话题介绍—MemcacheX（新版分布式缓存）：

MemcacheX就是新版的分布式缓存。在以往的分布式缓存中，如果用户需要Memcache服务，我们就给开启一个Memcache实例，如果发现宕掉之后，就会马上做一个迁移，这个迁移是没有数据迁移的，直接再重新起来一个，把原来的映射关系转过去。我们仍然需要把用户的继承放在这里，这就造成了一种资源的浪费。MemcacheX就考虑到了这一点并做了优化，即low overhead；

第二个就是HA的问题：之前包括新浪内部也有过几次大的运维事故，因此觉得HA对于开发者来说更加的重要。在以前的Memcache中存在这样的问题：宕掉之后再重新起一个是有问题的，因为重新起的Memcache是空的，用户需要时间预热。MemcacheX中就不存在这样的问题，即时有一两台机器宕掉，但Memcache对用户的服务是正常的。

还有一点就是Connection Protector：这也是根据我们内部的需求来的，我们发现并发非常大的时候，因对于PB人员的水平不同的原因，极有可能会有服务器Socket不能及时被关闭。MemcacheX就增加了主动关闭服务器Socket的功能；

最后就是MemcacheX增加了Date dump的功能，加快用户数据预热时间。

接下来，对MemcacheX的结构和用法做了详细说明后，丛磊开始了最后一个分享的重点：就是TaskQueue（异步离线任务队列服务）。

TaskQueue就是一个简单的任务离线处理队列，比如说，一个Web开发者要给100个人或者1000个人发微博，你肯定不能写一个循环去赋100次或者1000次发微博。所以把任务放到离线处理的队列里去，让队列离线去处理，能保证页面时正常。它与Deferredjob不同，后者是一个重量级离线任务处理队列。TaskQueue只是回一个URL，真正执行的还是用户的PhP代码；Deferredjob是系统在执行，是一种C语言级的代码。

最后，在介绍完TaskQueue的结构和用法之后，丛磊向大家透露了下一步SAE的计划：

第一个是新的代码部署文件系统：为了更好的提供服务，需要设计具有更高可靠性和一致性的代码部署文件系统。第二就是无缝迁移：这是一个重点项目，争取把所有用户的PhP代码不做任何修改转化直接转换迁移到SAE上来。第三个我就不多说了，就是Key-Value数据库，也是下一步工作计划之一。

分享结束后丛磊现场回答了参会者通过微博或者直接提出的几个问题：

如何进行代码重构和数据结构的变换？

首先是代码重构，我们SAE已经有版本切换，做代码重构的时候可以切换到一个测试版本，自己去做去，做完之后在合到默认版本里，现在SAE都支持。然后说数据结构的更改，我觉得可能说的是表的修改，如果是这样，你执行大量数据，比如说Auto Table，绝对会被拦截掉，但是可以用我们的DeferredJobs来实现。

GD库中的函数比较耗cpu，但SAE也有cpu方面的计费机制，请问 SAE能支持PhP中的GD库吗？

现在SAE本身在前端并没有把GD模块编译进去，而是提供了Image服务，这是跟我们的理念一样的，就是说我们希望吧cpu逆行的服务单独放到一个计算池里去。如果支持GD的话可能就会打破这个设计，但是请提问的人放心，我们马上就能支持无缝迁移GD代码。如果可以的话，这个服务代码明年一月份就能完成。

在两位精彩的分享之后，就是我们百度技术沙龙的OpenSpace环节，在这个环节里大家自由分组积极的参与了相关话题的讨论，并由话题提出人对各自话题小组的讨论进行了分享。

会后，来自 凤凰网的资深架构师孙立在他的 个人博客里发表了个人对 本期百度技术沙龙的总结并分享了自己所在OpenSpace话题小组的内容和看法。