Udacity分享他们在Google App Engine上的架构

Udacity是一个以提供个性化计算机教育免费在线课程为主的网站，虽然该网站上目前只有18种课程，但是它的流量却相当可观，目前在Alexa的排名是11926。

Chris Chew是该网站的资深软件工程师。日前，他在Google App Engine的官方博客上分享了如何使用App Engine来构建Udacity。

Chris指出：使用App Engine的决策，是由Udacity的CTO和联合创始人Mike Sokolsky做出的。连续多周，Mike必须不断加入新的服务器、管理MySQL复制数据库，以满足他们复杂的扩展模式。经过这段时间后，Mike认为App Engine的运维简单方便，很有说服力。

到现在，Udacity使用App Engine已经将近一年了，他们目前的架构如下：

其中：

• 使用NDB完成海量数据集的复制。NDB提供在无Schema的对象数据库中的持久化存储，支持自动化缓存、复杂查询和原子事务。
• Memcache
• Python Task Queues API完成延迟执行、MapReduce、批处理工作。
• App Engine Search API，索引课程内容和学生的简历。
• Blobstore API，存储课程视频、简历，导出数据。
• Image API，生成缩略图。
• MapReduce API，数据每日使用分析、数据迁移、数据维护。
• Trails和Trove，是由Piotr Kaminski主要开发的两个程序库。Trails提供清晰的语法，可在webapp2.RequestHandler上创建RESTful ，同时提供自动化分发。Trove包装了NDB，加入常用的属性类型，包括另一层的缓存，存储实体和之间的关系（包括处理中的和memcache），还有事件“监控”框架，当数据变化时，可完成可靠的带外处理触发。

Chris指出：图中没有标示出他们为NDB打的补丁，这些补丁能创建更好的hook，类似于现有的pre/post/put/delete等hook。这些自定义的hook为“监控”提供了抽象，让代码能对数据层中的变更反应。每个监控的执行都被延迟，并在请求之外完成，以避免增加响应时间。

Chirs提到：在使用App Engine完成扩展的头一年中，他们发现，性能是一件很复杂的事情。响应时间是多种因素的函数，既在他们控制之内，又在他们控制之外。App Engine确实有“水平扩展”的能力，但是他们发现对于某个给定请求的响应时间常常出现变化，即使是在系统负载很低的时候。因此，他们做了如下事情，以降低延迟变化的影响：

• 使用新的NDB API，而不是老的。
• 尽可能使用NDB.tasklet协同程序（coroutines），在RPC操作阻塞时允许并行处理。
• 不索引默认字段，仅在需要查询的时候才加入索引
• 小心地避免索引热点，只在需要的时候才索引可以预测值的字段（比如当前日期和时间的DateTime类型字段，或是枚举类型的字符串字段）。
• 大量使用实体化视图（Materialized view），这样可以限制每个请求尽可能少地查询数据集。

他们在最后一点上做的非常极端，把他们的数据集以去正规化的方式，专门生成为读操作优化的记录。比如，为读操作优化的用户档案记录包括：标准的档案信息、隐私配置、课程注册信息、课程进度和权限。这些数据都放在实体化视图中，只需要一个查询就可以完成。

对于App Engine，Chris给出的结论是：

App Engine是非常完善、可靠的平台，符合为数众多的用户案例和场景。很明显，对于知道如何扩展web应用的人来说，它的服务和API是专门为他们设计的。……想要完成任何概念验证，都是轻而易举的事情，而且后续的应用扩展工作要比你自己搞一套基础设施要轻松得多。

跟其他平台一样，你也要做出一些让步。使用App Engine要做出的让步是：你要不留余地地降低延迟，这才能享用令人赞叹的、支持扩展的服务。这对于我们来说很容易，因为在多次令人兴奋的海量访问时，App Engine已经有很好的表现。为了完成自己的使命，相对于自己搭建基础设施，我们现在的进度要快得多了。