本帖最后由 shengnan007 于 2012-10-15 10:24 编辑 5 c2 _: w( u: q' j
7 l \8 Q6 `& A& j F
开篇首先说明一下，这篇文章并非纯原创，而是摘抄自SAE的官方文档和丛磊（新浪）的演讲发言，略加修饰而成。目的在于，方便开发者对于SAE的整体架构有一个初步的认识，同时，也是在做技术架构的调研时，要做的一个基本工作。
- o: S% x: [+ c, @ T a/ _" @4 h' k( Z3 Q+ U. f. I- M
SAE简介
" o2 k7 W% W. M9 \& q& B& ~% N SAE就是简单高效的分布式Web服务开发、运行平台。 支持的语言：PHP，Java，Python。 5 f A$ W2 E% V) }7 L9 s* |/ M
SAE的功能 开发： ·代码检查，帮助检查不良函数并帮助移植 ·代码部署 ·分布式数据库 ·分布式文件存储 ·分布式缓存 ·各种附属分布式服务，包括图像、定时、任务队列、邮件、计数器等 ·对接多个开放平台，如新浪微博开发平台 ·团队协作，可以邀请好友以不同的权限加入项目 ·代码版本管理（计划支持） 运营： ·应用打包，通过我们的应用向导进行推广 ·日志，包括访问日志、错误日志等 ·资源报表，消耗SAE各项资源的统计 ·服务监控，监控各项服务状态 ·数据迁移，包括数据库导入、数据库导出等 1 J1 m2 U, t" I0 w6 v. s/ `
3 T% n- n" j L n& n SAE提供的服务 | 服务名称 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 提供临时文件存储，文件生命周期在一个会话内，Http请求结束文件自动消失 | | - M) C1 c! d$ W7 A# X! {
| 提供应用配置功能，取代Apache htaccess | | | | | | | | | | | | | | | 在线代码编辑器，编辑的代码保存后入自动入SVN并部署到Web服务器 |
* m3 H t* t y4 G# f/ R( `3 y0 s整体架构 SAE从架构上采用分层设计，从上往下分别为反向代理层、路由逻辑层、Web计算服务池。而从Web计算服务层延伸出SAE附属的分布式计算型服务和分布式存储型服务，具体又分成同步计算型服务、异步计算型服务、持久化存储服务、非持久化存储服务，后边会详细讲述。各种服务统一向日志和统计中心汇报，参考下图：) `& W1 Z9 N& M( _
* I: G9 P/ Y/ G, `7 V9 l
. v$ W& s" r+ F# G* N' jSAE整体架构图
2 O5 G% L* y, H. ?( H7 ^) C" d: K1 T/ g2 k( d# Y! Y/ i
7层反向代理层（Reverse Proxy）：HTTP反向代理，在最外层，负责响应用户的HTTP请求，分析请求，并转发到后端的Web服务池上，并提供负载均衡、健康检查等功能。 服务路由层（Service Router）：逻辑层，负责根据请求的唯一标识，快速的映射（O(1)时间复杂度）到相应的Web服务池，并映射到相应的硬件路径。如果发现映射关系不存在或者错误，则给出相应的错误提示。该层对用户隐藏了很多具体地址信息，使开发者无需关心服务的内部实际分配情况。 Web服务池（WebService Pools）：由一些不同特性的Web服务池组成。每个Web服务池实际是由一组Apache Server组成的，这些池按照不同的服务策略提供不同级别的服务。这些Web服务池的服务进程处理用户的HTTP请求，进程运行在HTTP服务沙盒内，同时还内嵌同样运行在SAE沙盒内的解析引擎。用户的代码最终通过接口调用各种服务。 日志和统计中心：统计中心负责对用户所使用的所有服务的配额进行统计和资源计费，这里的配额有两种，一种是分钟配额，用来保证整个平台的稳定；一种是天配额，用户可以给自己设定每天资源消耗的最高上限。日志中心负责将用户所有服务的日志汇总并备份，并提供检索查询服务。 各种分布式服务：SAE提供覆盖Web应用开发主要方面的多种服务，用户可以通过StdLib（可以理解为SAE PHP版的STL）很方便的调用它们。同时因为Web服务的多样性，SAE的标准服务不可能满足所有场景的需求，所以SAE可以对接第三方服务（如分词、全文检索等），SAE的使用者们可以直接使用对接到SAE中的第三方服务。 下图是程辉在讲解SAE的时候所用到的架构图，图中把Reverse Proxy层和Service Router层合并为App Router层，不过这和SAE的官方架构图并不冲突。同时，图中提到了DynamicDNS，SAE的Dynamic DNS，提供了多线路支持和智能解析，使用户访问速度更快。
# N, \4 R& [& V( X" ]3 \4 W6 |( J
1 g; f0 w/ n. v; T4 H; H) i" b0 _+ J: m% k5 c. L
+ Z2 X6 Y5 S' M2 e" e- |8 R" X- O
SAE架构图-程辉版 8 x8 e, v! Y) L% \
& J& t4 T# v& i; \0 p) c' O
SAE在解释自己的架构的扩展性的时候，在文档中的说法如下。 静态扩展，用户和资源有强绑定关系。最典型的例子为亚马逊的EC2和Ruby云计算平台Heroku，用户申请的资源和用户有严格的一对一关系，换句话说，A用户申请的虚拟机在A退还资源前，B用户不能使用，哪怕A用户的虚拟机处于闲置状态。 动态扩展，用户和资源没有强绑定关系。最典型的例子为Google App Engine，用户申请的资源和用户没有严格的一对一关系，换句话说，处理A用户请求的进程在处理完之后，可以马上处理B用户的请求。 在SAE平台上，采用了以动态扩展为主，静态扩展为辅的兼而有之的设计。在Web计算池层，是典型的动态扩展，没有一个用户独占Web服务进程，而是所有用户以共享的方式使用Web服务进程，通过Cache，热的用户自然在缓存层占据更多的位置。而在SAE的某些服务中，扩展性又是以静态扩展的方式展现，如RDC（Relational DB Cluster）分布式数据库集群，当用户申请了MySQL服务，SAE就会在RDC后端创建DB给用户，在用户显式的删除该DB前，该DB都不会被别人使用。当然，通过RDC，任何一个用户也无需知道后端DB的实际地址，只需访问RDC统一的host和port即可。 SAE的安全性 + I7 t- ~/ ^0 @0 X2 h: |- _: Q
( |# ~; q& s5 g/ N- q8 P% B
防火墙和Runtime SandBox
4 u6 |! [% O2 M1 }: z) j/ d& r! a X! F4 [4 z
1 r$ K* P) n% l7 g
. p1 {4 s9 R( m/ v) D0 N
SAE沙盒结构图 & [7 h' k8 k" t+ u( z$ x
' E* g. h' e' Y
SAE设计多层沙盒来保证用户应用之间的隔离性。 6 L4 e [5 _$ B# @0 ~. A4 _
最内层的就是用户代码，大部分PHP代码不需要做任何修改就可以跑在SAE平台上。小部分代码需要做一些修改以适应SAE的平台特性。比如，SAE因为安全性禁用了本地IO，所以fwrite等函数需要修改为使用TmpFD读写本地临时文件或者直接通过Storage服务读写分布式文件存储。 PHP Zend为标准的PHP官方解释器，目前采用的版本为5.3。 SAE Zend Sandbox为用户的代码运行提供良好的隔离性。这里有两个层面，1，是通过标准的php.ini，SAE设定了一些特殊配置和禁用函数；2，为了达到一些php.ini无法实现的沙盒功能，对Zend解释器核做了一些改进，以便通过用户标识将资源进行隔离。另外还把一些SAE的特定服务也在Zend层做了融合。 Apache为标准的Apache Web Server，目前版本为2.2。不过SAE禁用了htaccess，并提供了自己实现的替换方案AppConfig。 HTTP Server沙盒为Apache的安全可靠运行提供了多种保护功能，比如防止某个用户恶意占用连接数从而导致整个Web服务不正常。 最外层的是标准POSIX环境。 参考资料： 8 d1 ]8 C% d7 n0 A* @
* p* Q$ L5 d( F" b6 Z7 m
| 
雷达卡
发表于 2012-10-15 10:12:07
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
楼主
发表于 2012-10-16 09:35:27