本帖最后由 shengnan007 于 2012-10-15 10:24 编辑 & b: E7 u' x1 e( n/ M8 v4 w
9 s0 b; O/ P* b4 Y# h8 S 开篇首先说明一下,这篇文章并非纯原创,而是摘抄自SAE的官方文档和丛磊(新浪)的演讲发言,略加修饰而成。目的在于,方便开发者对于SAE的整体架构有一个初步的认识,同时,也是在做技术架构的调研时,要做的一个基本工作。
, x4 @3 j$ e `/ B7 V, N
. |" A4 d, a; i, g/ @* U# I! CSAE简介 2 i( K2 e4 f$ ]' b
SAE就是简单高效的分布式Web服务开发、运行平台。 支持的语言:PHP,Java,Python。
* q% N r& K7 M, K- H8 J" S6 p5 } SAE的功能 开发: ·代码检查,帮助检查不良函数并帮助移植 ·代码部署 ·分布式数据库 ·分布式文件存储 ·分布式缓存 ·各种附属分布式服务,包括图像、定时、任务队列、邮件、计数器等 ·对接多个开放平台,如新浪微博开发平台 ·团队协作,可以邀请好友以不同的权限加入项目 ·代码版本管理(计划支持) 运营: ·应用打包,通过我们的应用向导进行推广 ·日志,包括访问日志、错误日志等 ·资源报表,消耗SAE各项资源的统计 ·服务监控,监控各项服务状态 ·数据迁移,包括数据库导入、数据库导出等 4 Q6 t, l0 H c4 z! ~% ~- \' r
" m! z- @1 M+ v5 G
SAE提供的服务 服务名称 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 提供临时文件存储,文件生命周期在一个会话内,Http请求结束文件自动消失 | |
! Z2 @" k+ r, q: u% M3 f, N9 t
| 提供应用配置功能,取代Apache htaccess | | | | | | | | | | | | | | | 在线代码编辑器,编辑的代码保存后入自动入SVN并部署到Web服务器 |
/ U& N- ?, J4 H整体架构 SAE从架构上采用分层设计,从上往下分别为反向代理层、路由逻辑层、Web计算服务池。而从Web计算服务层延伸出SAE附属的分布式计算型服务和分布式存储型服务,具体又分成同步计算型服务、异步计算型服务、持久化存储服务、非持久化存储服务,后边会详细讲述。各种服务统一向日志和统计中心汇报,参考下图:: z/ w# f) T0 S9 W8 N( B- _- G2 x9 U
. _, P) t6 q+ l" Y8 w+ I7 [+ x* n+ N
+ R' w% G7 _4 G5 ]' K9 O
SAE整体架构图
6 h- _* n: @0 n) M$ b0 K8 j2 u' b0 a p3 O* B% B. T
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,提供了多线路支持和智能解析,使用户访问速度更快。/ D9 c5 G$ h$ L
/ ?! o7 X( Q+ M) F4 R: D
$ h. @' K- U% E
0 f3 F& T9 X1 i& O! n
SAE架构图-程辉版
% \$ W: u/ V/ a4 r2 c5 ^: z9 L! a& u3 R5 v0 i
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的安全性
; M0 O* Q1 K2 w. S9 q
+ M) g1 L! o/ `9 q; ?: m防火墙和Runtime SandBox
& f ?5 D& P7 T% u3 f, e0 C5 c3 B' M6 D1 v/ x7 n8 t
- R ?) _4 u1 q) r! ~4 _
( U. @' K% c1 S; D9 W5 e: VSAE沙盒结构图 : h9 N* A/ o6 y( M' _3 p2 K
; U2 U) x* m0 z. E' {7 @! x0 N SAE设计多层沙盒来保证用户应用之间的隔离性。 + i/ ?$ C2 c L* H
最内层的就是用户代码,大部分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环境。 参考资料:
+ ~2 Z% ?: N0 M$ X+ S/ ]
0 o/ J+ w( `! P2 O L. N |