百度技术沙龙第 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 话题小组的内容和看法。