SAE[编辑]

简介：

SAE一般有两种解释：一，Sina App Engine是新浪研发中心研发的，是新浪云计算战略的核心组成部分。二，系统架构演进（System Architecture Evolution），是一个基于全IP网络的平坦架构，主要组成是核心分组网演进。

Sina App Engine的特点及优势：
SAE服务可以让开发者在开发网络应用程序的过程中摆脱繁琐的环境，并且SAE提供许多服务供开发者使用，开发者无需重复开发，降低用户的开发成本，SAE还自动为用户提供SQL语句性能分析、前端防攻击、代码检查等功能，而且SAE上的所有应用均为多机房容灾部署，这比传统的部署模式更加安全可靠，因此开发者只需要把精力专注于业务逻辑。对于一般不会编程的用户，他们更可以利用SAE快速的拥有自己的团购、博客、微博、Wiki等。

系统架构演进的特点和优势：
SAE是3GPP对于LTE无线通信标准的核心网络架构的升级计划，也是3GPP系统在持续演进和优化，为更好地提高性能和降低成本下提出的，长期演进目的是为了减少时延、提供更高的用户数据速率、更高的系统容量和更好的覆盖、减少运营商的成本。

核心优势

SAE的基本目标用户有两种，一种是Web开发者，另一种是普通互联网上网人群。

对于Web开发者，SAE带来的好处有：

·硬件成本更低，无需预先购买设备，承担更大的投入风险

·开发成本更低，SAE提供许多服务供开发者使用，开发者无需重复开发，包括队列、数据库、缓存、定时、验证码、计数器，几乎覆盖了Web开发的所有领域。另外对于特定开放平台的开发者，比如WAP开发者，SAE已经集成了完整的OpenAPI的封装，将开发者的开发成本降到最低。值得一提的是，SAE的开发者已经形成了良好的交流氛围，在意见反馈中心、SAE官方群，SAE官方微群可以看到很多热情的开发者在一起共同提高

·运维成本更低，在SAE上的应用无需关心硬件维护、服务监控、数据容灾等操作，SAE会通过其高可靠的架构和方便的监控页面为用户将运维成本降到最低扩展性更强，在SAE上的服务无需关心服务压力猛增时带来的扩容等操作，SAE自动支持服务扩展

·更加安全可靠，SAE自动提供SQL语句性能分析、前端防攻击、代码检查等功能，在SAE上的所有应用均为多机房容灾部署，比传统的部署模式更加安全可靠，并且SAE提供服务的SLA来实现对用户服务质量的承诺

对于普通上网人群，使用SAE可以：

使用推荐应用一键安装Web应用，普通用户无需会编码，也可以在瞬间拥有自己的团购、博客、微博、Wiki等。

整体架构

SAE从架构上采用分层设计，从上往下分别为反向代理层、路由逻辑层、Web计算服务池。而从Web计算服务层延伸出SAE附属的分布式计算型服务和分布式存储型服务，具体又分成同步计算型服务、异步计算型服务、持久化存储服务、非持久化存储服务。各种服务统一向日志和统计中心汇报，参考下图：

Level7ReverseProxy（7层反向代理层）：HTTP反向代理，在最外层，负责响应用户的HTTP请求，分析请求，并转发到后端的Web服务池上，并提供负载均衡、健康检查等功能。

ServiceRouter（服务路由层）：逻辑层，负责根据请求的唯一标识，快速的映射（O(1)时间复杂度）到相应的Web服务池，并映射到相应的硬件路径。如果发现映射关系不存在或者错误，则给出相应的错误提示。该层对用户隐藏了很多具体地址信息，使开发者无需关心服务的内部实际分配情况。

WebServicePools（Web服务池）：由一些不同特性的Web服务池组成。每个Web服务池实际是由一组Apache(PHP)组成的，这些池按照不同的SLA提供不同级别的服务。每个Web服务进程实际处理用户的HTTP请求，进程运行在HTTP服务沙盒内，同时还内嵌同样运行在SAE沙盒内的PHP解析引擎。用户的代码最终通过接口调用各种服务。

StatisticsCenter&LogCenter（日志和统计中心）：负责对用户所使用的所有服务进行统计和资源计费，并设定的分钟配额，来判定是否有非正常的使用。分钟配额描述了资源消耗的速度，当资源消耗的速度到达一个预警阈值时，SAE通知系统会提前向用户发出一个警告，提醒用户应用在某个服务上的使用可能存在问题，需要介入关注或处理，配额系统是SAE用来保证整个平台稳定的措施之一；日志中心负责将用户所有服务的日志汇总并备份，并提供检索查询服务。

各种分布式服务：SAE提供覆盖Web应用开发主要方面的多种服务，用户可以通过StdLib（可以理解为SAEPHP版的STL）很方便的调用它们。同时因为Web服务的多样性，SAE的标准服务不可能满足所有场景的需求，所以SAE通过服务总线来对接第三方服务（如分词、全文检索等），SAE也欢迎第三方服务商选择SAE来为开发者提供服务。

真正的用户代码是跑在SAE提供的Web运行环境下的，为了提供公有云计算特有的安全性，SAE设计多层沙盒来保证用户应用之间的隔离性。参考下图：

最内层的就是用户代码，大部分PHP代码不需要做任何修改就可以跑在SAE平台上。小部分代码需要做一些修改以适应SAE的平台特性。这主要有，SAE因为安全性禁用了本地IO，所以fwrite等函数需要修改为使用TmpFD读写本地临时文件或者直接通过Storage服务读写我们的分布式文件存储。

PHPZend为标准的PHP官方解释器。

SAEZendSandbox为一个逻辑概念，为用户的代码运行提供良好的隔离性。这里有两个层面：

1、是通过标准的php.ini，我们设定了一些特殊配置和禁用函数；

2、为了达到一些php.ini无法实现的沙盒功能，我们对Zend解释器核做了一些改进，以便通过用户标识将资源进行隔离。另外我们还把一些SAE的特定服务也在Zend层做了融合。

Apache为标准的ApacheWebServer。不过我们禁用了htaccess，并提供了自己实现的替换方案AppConfig。用户可以通过类自然语言的方式编写AppConfig，如-compress:if(out_header["Content-Length"]>=500)compress表示按条件启动页面压缩。AppConfig提供的功能有：目录默认页面、自定义错误页面、压缩、页面重定向、页面过期、设置响应头的content-type、设置页面访问权限。我们选择自行实现AppConfig还有一个考虑，就是因为传统Apache的htaccess因为要按目录递归方式合并配置文件，效率不能满足SAE的需求。

HTTPServer沙盒为Apache的安全可靠运行提供了多种保护功能，比如防止某个用户恶意占用连接数从而导致整个Web服务不正常。

最外层的是标准POSIX环境，我们的服务跑在Linux上。

接着将详细讨论我们架构设计的特点。

·扩展性

扩展性是分布式系统的两个主要目的之一，SAE作为公有云计算，同样把服务的扩展性作为架构设计的重要指标，要求在用户增长、压力提升的情况下，可以实现自动的服务扩展，同样的当压力降低时，可以将服务收缩，以节约资源，整个过程无需人工参与。SAE人工只需做好容量规划和管理。国外的公有云计算架构的扩展性主要有两个思路：

静态扩展，用户和资源有强绑定关系。最典型的例子为亚马逊的EC2和Ruby云计算平台Heroku，用户申请的资源和用户有严格的一对一关系，换句话说，A用户申请的虚拟机在A退还资源前，B用户不能使用，哪怕A用户的虚拟机处于闲置状态。

动态扩展，用户和资源没有强绑定关系。最典型的例子为GoogleAppEngine，用户申请的资源和用户没有严格的一对一关系，换句话说，处理A用户请求的进程在处理完之后，可以马上处理B用户的请求。

两种扩展性各有利弊，静态扩展的长处是为平台提供了良好的隔离性，资源可以固定的映射在某个用户下，但缺点是资源利用率不高；动态扩展的长处是资源利用率高，这样整个云计算平台的成本会很低，但缺点是对隔离性有更高的要求，因为资源可以在很短的时间被多个用户使用。相比较，在安全性上，动态扩展要比静态扩展的技术门槛更高。

在SAE平台上，我们采用以动态扩展为主，静态扩展为辅的兼而有之的设计。在Web计算池层，是典型的动态扩展，没有一个用户独占Web服务进程，而是所有用户以共享的方式使用Web服务进程，通过Cache，热的用户自然在缓存层占据更多的位置。而在SAE的某些服务中，扩展性又是以静态扩展的方式展现，如RDC（RelationalDBCluster）分布式数据库集群，当用户申请了MySQL服务，我们就会在RDC后端根据SLA的级别创建一主多从的DB给用户，在用户显式的删除该DB前，该DB都不会被别人使用。当然，通过RDC，任何一个用户也无需知道后端DB的实际地址，只需访问RDC统一的host和port即可。

·高可靠性

HA是分布式系统的另一个主要目的，SAE同样以提供服务的高可靠性为架构设计的重要指标。HA的实现途径主要有两个，一个是硬件保证，一个是架构的冗余设计。

在SAE平台上，所有服务器都是新浪标准采购的硬件设备，运行在国内最好机房内，并进行多机房容灾，网络资源方面则享用门户网站所使用的带宽环境。另外，所有的硬件设备都有专门的运维部门负责，故障的响应速度和新浪内部服务一样。

在架构设计上，SAE通过对所有服务都进行冗余设计来提供服务的高可靠性。这里的服务可以分成计算型和数据型两种类别讨论：

针对计算型程序，冗余设计就是程序在多节点运行。但这样会带来一致性问题，最主要的困扰就是选举问题，如何在多个节点中选出一个主节点来执行。比如SAE上的分布式定时服务Cron，采用多点部署方式，多个计算节点相互隔离，通过时钟同步服务同时触发用户设定的定时任务，但要求只能有一个节点负责执行。为了解决这个问题，SAE设计出了一套分布式锁算法来提供选举服务。该算法可以在牺牲某些特定条件下的一致性来提供比Paxos算法更高的可靠性（3台机器在最高任意2台机器发生故障的情况下整个选举过程仍然正常，而Paxos算法最多容忍1台）。截止至2012年12月该算法正在申请专利，并广泛应用在SAE内部。

针对数据型服务，SAE主要是通过复制来保证服务的高可靠性。SAE上的数据存储服务普遍采用被动复制和主动复制两种方式。如SAE上MySQL之间的主从Binlog同步就是典型的被动复制，TaskQueue、DeferredJob等服务也采用被动复制的方式，用户的任务描述会写到到主内存级队列中，主队列利用后台线程将写操作同步到从队列上，一旦主队列发生故障，从队列会快速的切换为主队列。另外SAE上也有部分服务采用主动复制（双写复制）的方式来保证HA，比如Cron，当用户通过App的工程配置文件appconfig.yaml设定定时任务时，任务信息会以双写的方式写到多个持久化DB中，以供后续的到时触发。

另外，SAE在整体架构设计时，充分考虑服务之间的“优雅降级”，尽量降低服务之间的耦合度，我们要求任何一个服务都不要假设其他服务是可靠的。SAE平台上的所有服务均不存在单点设计，服务的平均HA在99.95%，即年平均服务不可用时间在4到5个小时之间。

线路特性

·平台出口IP：

220.181.129.126

220.181.129.121

220.181.136.229

220.181.136.230

http接口方需要IP授权可以进行相应的设置。

参考资料： soso百科

扩展阅读：