SAE整体架构
SAE从架构上采用分层设计,从上往下分别为反向代理层、路由逻辑层、Web计算服务池。而从Web计算服务层延伸出SAE附属的分布式计算型服务和分布式存储型服务,具体又分成同步计算型服务、异步计算型服务、持久化存储服务、非持久化存储服务。各种服务统一向日志和统计中心汇报,参考下图:
![](http://sae.sina.com.cn/static/image/constructor_content/sae_constructor.png)
SAE整体架构图
7层反向代理层:HTTP反向代理,在最外层,负责响应用户的HTTP请求,分析请求,并转发到后端的Web服务池上,并提供负载均衡、健康检查等功能。
服务路由层:逻辑层,负责根据请求的唯一标识,快速的映射(O(1)时间复杂度)到相应的Web服务池,并映射到相应的硬件路径。如果发现映射关系不存在或者错误,则给出相应的错误提示。该层对用户隐藏了很多具体地址信息,使开发者无需关心服务的内部实际分配情况。
Web服务池:由一些不同特性的Web服务池组成。每个Web服务池实际是由一组Apache Server组成的,这些池按照不同的SLA提供不同级别的服务。每个Web服务进程实际处理用户的HTTP请求,进程运行在HTTP服务沙盒内,同时还内嵌同样运行在SAE沙盒内的解析引擎。用户的代码最终通过接口调用各种服务。
日志和统计中心:负责对用户所使用的所有服务的配额进行统计和资源计费,这里的配额有两种,一种是分钟配额,用来保证整个平台的稳定;一种是天配额,用户可以给自己的设定每天资源消耗的最高上限。日志中心负责将用户所有服务的日志汇总并备份,并提供检索查询服务。
各种分布式服务:SAE提供覆盖Web应用开发主要方面的多种服务,用户可以通过StdLib(可以理解为SAE PHP版的STL)很方便的调用它们。同时因为Web服务的多样性,SAE的标准服务不可能满足所有场景的需求,所以SAE通过服务总线来对接第三方服务(如分词、全文检索等),SAE也欢迎第三方服务商选择SAE来为开发者提供服务。
扩展性
扩展性是分布式系统的两个主要目的之一,SAE作为公有云计算,同样把服务的扩展性作为架构设计的重要指标,要求在用户增长、压力提升的情况下,可以实现自动的服务扩展,同样的当压力降低时,可以将服务收缩,以节约资源,整个过程无需人工参与。SAE人工只需做好容量规划和管理。目前国外的公有云计算架构的扩展性主要有两个思路:
静态扩展,用户和资源有强绑定关系。最典型的例子为亚马逊的EC2和Ruby云计算平台Heroku,用户申请的资源和用户有严格的一对一关系,换句话说,A用户申请的虚拟机在A退还资源前,B用户不能使用,哪怕A用户的虚拟机处于闲置状态。
动态扩展,用户和资源没有强绑定关系。最典型的例子为Google App Engine,用户申请的资源和用户没有严格的一对一关系,换句话说,处理A用户请求的进程在处理完之后,可以马上处理B用户的请求。
两种扩展性各有利弊,静态扩展的长处是为平台提供了良好的隔离性,资源可以固定的映射在某个用户下,但缺点是资源利用率不高;动态扩展的长处是资源利用率高,这样整个云计算平台的成本会很低,但缺点是对隔离性有更高的要求,因为资源可以在很短的时间被多个用户使用。相比较,在安全性上,动态扩展要比静态扩展的技术门槛更高。
在SAE平台上,我们采用以动态扩展为主,静态扩展为辅的兼而有之的设计。在Web计算池层,是典型的动态扩展,没有一个用户独占Web服务进程,而是所有用户以共享的方式使用Web服务进程,通过Cache,热的用户自然在缓存层占据更多的位置。而在SAE的某些服务中,扩展性又是以静态扩展的方式展现,如RDC(Relational DB Cluster)分布式数据库集群,当用户申请了MySQL服务,我们就会在RDC后端根据SLA的级别创建一主多从的DB给用户,在用户显式的删除该DB前,该DB都不会被别人使用。当然,通过RDC,任何一个用户也无需知道后端DB的实际地址,只需访问RDC统一的host和port即可。
高可靠性
HA是分布式系统的另一个主要目的,SAE同样以提供服务的高可靠性为架构设计的重要指标。HA的实现途径主要有两个,一个是硬件保证,一个是架构的冗余设计。
在SAE平台上,所有服务器都是新浪标准采购的硬件设备,运行在国内最好机房内,并进行多机房容灾,网络资源方面则享用门户网站所使用的带宽环境。另外,所有的硬件设备都有专门的运维部门负责,故障的响应速度和新浪内部服务一样。
在架构设计上,SAE通过对所有服务都进行冗余设计来提供服务的高可靠性。这里的服务可以分成计算型和数据型两种类别讨论:
针对计算型程序,冗余设计就是程序在多节点运行。但这样会带来一致性问题,最主要的困扰就是选举问题,如何在多个节点中选出一个主节点来执行。比如SAE上的分布式定时服务Cron,采用多点部署方式,多个计算节点相互隔离,通过时钟同步服务同时触发用户设定的定时任务,但要求只能有一个节点负责执行。为了解决这个问题,SAE设计出了一套分布式锁算法来提供选举服务。该算法可以在牺牲某些特定条件下的一致性来提供比Paxos算法更高的可靠性(3台机器在最高任意2台机器发生故障的情况下整个选举过程仍然正常,而Paxos算法最多容忍1台)。目前,该算法正在申请专利,并广泛应用在SAE内部。
针对数据型服务,SAE主要是通过复制来保证服务的高可靠性。SAE上的数据存储服务普遍采用被动复制和主动复制两种方式。如SAE上MySQL之间的主从Binlog同步就是典型的被动复制,TaskQueue、DeferredJob等服务也采用被动复制的方式,用户的任务描述会写到到主内存级队列中,主队列利用后台线程将写操作同步到从队列上,一旦主队列发生故障,从队列会快速的切换为主队列。另外SAE上也有部分服务采用主动复制(双写复制)的方式来保证HA,比如Cron,当用户通过App的工程配置文件appconfig.yaml设定定时任务时,任务信息会以双写的方式写到多个持久化DB中,以供后续的到时触发。
另外,SAE在整体架构设计时,充分考虑服务之间的“优雅降级”,尽量降低服务之间的耦合度,我们要求任何一个服务都不要假设其他服务是可靠的。目前在SAE平台上的所有服务均不存在单点设计,服务的平均HA在99.95%,即年平均服务不可用时间在4到5个小时之间。