企云云
企业微信服务商
企业微信服务商
2012年1月11日，第六届中国IDC产业年度大典在北京开幕，本届大会以“构建云暨创新论坛”为主题，邀电信运营商、IDC、设备厂商、等业界同仁共同探讨时代下的IDC产业机遇与责任，研发中 技术经理程辉发表演讲：新浪SAE云计算平台架构。
新浪研发中心技术经理程辉：大家好!非常高兴和荣幸共聚一堂，讨论新浪的SAE架构设计。昨天我们已经听了很多关于的各种概念，会后我跟一些朋友讨论了，尤其是之前没有做过这个领域的朋友，他们仍然感觉云计算这个概念还是很虚，一说到云计算三个字，就感觉是非得建一个五星级的云计算数据中心，或者是在数据中心建设上投入大量的资金，才能感受和体验到云计算。在我们看来不是这样的。在我们看来，要体验云计算很简单，只需要一个ID，只要一个帐号，只需要低于1块钱，就能体验到云计算相关的技术，能为企业、个人带来实惠，这才是真正的云计算。下面我们开始谈一下新浪在云计算PaaS平台SAE的设计和架构。今天主要有以下三方面的内容。第一方面，我们介绍一下SAE的需求和背景。我们首先会试用一下SAE，从外表看到底是什么东西。第二，我们从几个方面来阐述SAE能给我们带来什么，能承担什么应用。第三，我们在这里发布一些SAE的数据。第二，也是今天的重点，我们会从上面的背景和需求出发，阐述SAE的设计。包括在安全上的考虑。第三，SAE的企业服务，我们介绍一下。先来试用，大家在和做过SAE，第一个就能进到新浪Appengine首页，简单高效的应用开发和运行平台，这是一句广告语，我们会用这句话来做阐述。从这里来看，不需要任何的邀请，不需要投入多大的资金，只需要有一个微博ID就可以体验。我们登录进来之后，看到自己的应用列表，我们可以看到，目前SAE支持三大平台，PHP Pashion和JAVA，PHP目前是全开放的，后两种是处于测试阶段，很快就会开发出来。我来之前创建了一个应用，这个只是测试一下。我们这里可以选择我们平台的开发语言，PHP Pashion和JAVA，创建一个应用，点击进入一个应用首页，映入眼帘的是资源统计，SAE的资源统计非常丰富，能够看到像PVUP的统计，HTTP，我们能看到每分钟的实时的，或者安全的启用时间等，带宽、CPU消耗等，再就是我们其他的服务，定时任务，队列，数据抓取、图片处理，MC等很多的服务，还有其他的服务没有列出来，后面我们会了解到。这是我们代码管理，创建一个应用之后，我们第一件事情，就是想到去有一个代码，运行一个Hadwork，目前在我们公司网站直接上传。我们有两个渠道，第一个渠道，创建一个应用，默认就了一个SAE仓库，只需要Check out上来，将代码复制到本地的SO的工作仓库，Checkin就完成部署了。另外，我们如果不习惯，站长习惯用传统的Http方式，我们到现在都没有提供这个方式。另外一个模式，就是提供在线编译器，写完代码之后，这个代码就部署到了我们所有的机器上，就完成代码部署和分发工作。互联网业务，一些高性能的业务会用到MC，我们的很简单，传统的要搭建一个环境，用户需要安装一个MySQL，然后装上各种配置，我们这里就是一键完成，点一下应用，就在这里了，我们可以直接管理我们的应用，或者给其他用户授权，这里也能看到数据库列表。第二，我们这里有一个MC的列表，能看到MC的利用率和内存占用率，这里也可以做测试，也可以及时的调整MC的容量。这就是资源报表，这一页我们看到了很多重要的信息，第一，就是价格。比如说带宽，我们后台计费精确到每一KB，100个芸豆等于1块钱，就是2.4元一个GB.大概填完之后，我们接下来看一下新浪的SAE是什么，定位是什么？首先，我这里把SAE的全程写出来，就是Sina Appengine，engine是一个应用引擎。我们的应用是什么呢？大家可以看，应用可以是一个平台级的应用，比如说微游，目前的微游戏频道是最赚钱的频道，除了主要业务之外流量最大的频道。之前，在下面这个大空白地方，我列了一些微游戏的数据，后来领导说，我们不是官方，不便公布，但是可以给大家一个数量级，微游戏目前的PV是在三亿左右，每天都是这样，应该是SAE最大的应用。它在我们平台上，自己不需要投入任何的运维相关的人力，这么大的平台，不需要一个运维，一个运维都没有，一个系统工程师都没有。微游戏是新浪跟五分钟团队合作的一个项目，他们主要做应用逻辑的开发。这是我们的App可以是一个平台级的应用。然后我们的应用也可以是一个工具类的应用，这是微博上非常火热的微盘应用，也是运行在我们的平台上，业务两大概在一亿平维(音译)左右。目前存多少数据？应该是在几十T数量级左右。除了平台即应用，工具类的应用，SAE还运行很多游戏的应用。微三国，是目前微游戏平台，360开放平台运行的游戏。是目前微游戏排名第三第四的样子，PV也是在几千万的级别，日活跃用户大概在百万级别以上，这么大型的应用，我们后面会介绍到负责人使用我们SAE的感受是什么。他们也没有一个运维做后端的部署工作，或者做后端的维护监控工作。全是一个小团队做开发的。我们这里还有一个门户类的应用，北外的主站已经移到SAE了，这是不花一分钱的，对于一个主站来说，每天几万或者几十万的PV，费用可能太低了，可能在几十块钱左右。对于我们来说，完全可以忽略掉，我们直接对高校免费使用SAE平台。所以，从这一点来看，现在的Appengine，应用能放什么？取决于用户开发者，或者用户的需求，你们做什么，SAE就能放什么。下面说到SAE首页重要的广告词，简单高效的应用开发和托管平台。托管平台，前面的案例介绍到了。我们说一下简单高效？SAE还有一个频道叫应用商店，应用商店里面可以安装各种别人开发好的，或者别人移植好的应用，比如说安装一个Wordprass，找到之后直接在后端部署装置完成了。跟微游戏、微三国等使用的是同一个环境。只要说Wordprass量很大没有关系，从一个Pv到几十个Pv，后端不需要做任何的事情，我们跟用户有需求，针对需求进行配合，前提是肯定要做一些优化。对于互联网业务依赖的MySQL，点击优化就可以完成了，所有的操作尽量做到一键化。这在传统的互联网公司是非常难做到的。SAE之前，新浪某一个业务部门有一个产品线上线，原先的数据库平台，得联系运维部门，数据库平台帮助他们分配数据库，数据库平台可能还帮助负载MC，这样下来一周时间过去了。而在这个平台上，几分钟或者一个小时左右，就能完成，自动完成后端的部署。SAE也是一个应用开发的平台，通过SAE，不管是、Windows、，都有SAE的客户端，直接使用就可以。我们不需要登录服务器查看日志，直接在日志中心能看到Http、MySQL、邮件等所有服务的日志。通过我们这个平台，能够看到微游戏的首页，Http服务，每个请求花了多少CPU的时间，这里都有显示。正常的情况下，每一个Http请求只需要41毫秒的时间。应该是SAE里面非常优化的平台，如果应用有波动的话，比如说部署代码，代码业务逻辑处理不好，导致CPU的使用形势急剧上升，或者新浪的页面服务遭到一些故障。SAE，对于普通用户来说，是一个LAMP平台，已经在后端做了分布式，用户使用起来跟标准LAMP没有什么差别。尤其是我们在PHP运行时间开发之初，尽量做到跟标准平台完全兼容。目前除了本地IO没有开放外，所有的平台都做到了兼容。SAE是一个PaaS平台，我不太愿意讲云计算的概念。SAE2009年6月份就开始开发，我们对出开发的目的并不是为了云计算，目的是解决内部的需求，或者是解决普通用户对于应用托管和应用开发的需求。后来，我们快上线了，我们感觉最近这个概念越来越火了，正好确实是PaaS平台的理念和概念，我们就认为它是PaaS平台了。发布一些SAE的数据，目前PV量/日是5亿，截止到1月10号凌晨，有17万个应用。14万个开发者，开发者应该有六成以上都是我们认证过的开发者。70%的微博应用托管在SAE平台，SAE有一个应用频道，我们点击就能够看到无数个应用，其中70%是在SAE平台上运行。目前SAE正在跟合作，他们的开发者可以直接使用SAE平台开发应用。现在就可以，因为SAE是完全开放的，支持所有的平台，不止限于新浪微博。比如说微三国的已经上架360的平台，100%的微博企业合作伙伴正在使用SAE.微博合作伙伴的概念是指，微博上平台上目前开发的美食平台，目前还没有开放，这是内部透露的。还有企业平台、漫画平台、婚恋平台，很多跟微博平台合作的都在，内部已经形成默契，第三方合作伙伴不服务器了，直接使用SAE.下面进入今天的重点。前面就是试用的情况，外表上SAE是什么样，现在从SAE的需求入手，讨论SAE背后的设计。这是SAE的总体架构，这张图，不管是在首页，还是在其他的分享会议上，这张图都是没有的，这是这几天精心打造的一张图，比较形象。我们对外公布了一些架构图，在其他的分享活动上，我们其他的开发者，包括我们的同事也做了图。我总感觉还是有点虚，不够实，这里具体一点。这里有两个角色，一个角色是User，不是指用户，是我们普通的应用访问者，我们叫Vistor，第二个角色是开发者。我们的Vistor找到的负载均衡，有路由的作用，到每一台服务器，下面专门介绍到。负载这一层到客户真正执行业务逻辑层面，就是PHP和Java.到了中间这一层，跟我们后端各个服务打交道，比如跟MySQL，MySQL没有办法用标准的MySQL，我们自己做了一个代理，会用到我们自己开发的KVDB服务，还有改造过的MC服务，还有数据抓取，我们不可能直接从后端那么多机器上访问Web网。数据出去都需要通过数据代理，还有Cron的服务。下面重点介绍一下Servicegate，通过这个门，可以对接第三方其他的服务。这是一个用户进来以后，通过负载均衡到达Runtime，如果业务逻辑没有使用的话，其他服务都会从Runtime请求调用，开发者会走这条路，通过SVN，把代码Check out下来，直接Check in，首先通过Code到代码部署的中型机，会将目前的更新分发到Runtime，后端是扩展的，目前可以透露一下，后端大概有几百台。这个中心也是多点的，是PHP的，一份更新、代码直接部到几百台服务器上。下面重点介绍一下架构里面的各个子部分。动态DNS，从这里可以看到，一个普通的用户，比如说ABC.app.com，问ABC的应用，通过直接解析到新浪的SAE的更新。还有一个是国外的用户和小运营商，比如说等小运营商，会有一个PHP的机房，五大机房到新浪的SAE提供业务逻辑的机房，中间有高速通道，机房全在北京，然后通过光纤通道直接到我们的SAE核心机房。这样有什么好处？因为我们现在很难找到一个机房，能支持所有的主流运营上还能覆盖小运营商，在目前来说是不可能的。所以说，只能通过不同的机房之间的高速光纤通道来解决目前国内的高速访问的问题。这一套动态DNS，对SAE应用有一个纪要，能看到全国所有的城市都是绿色的，也就是说请求都是理想的。对于传统的IDC或者传统虚拟主机来讲，很难做到这一点，因为总是在一个机房来做的。其实，这套东西并不是SAE专属的，是新浪本来就有的，SAE正好用上这套资源。对于我们普通的开发者来说，部署一个简单的应用，直接就使用了新浪这么久以来打造的非常完好的各大运营商、各大线路的支持。我们从这里可以看到，多线路的支持，针对解析IT容灾，有两个IDC做互备的。下面说到另外一个核心，就是负载均衡层，或者路由层。路由层基于nginx进行二次开发，nginx本来没有状态，一个应用请求大了以后，需要将请求分发下去，必须得存很多的状态信息。比如说APP，因为用户给负载均衡发送的请求就是标准的请求，会有一个UIA，凭这两个东西要帮助找到是哪台服务器做的开发，是JAVA平台还是其他的平台，应用有配置信息在里面，都是通过高速的缓存。第一版是直接拿一个MC，MC的平台的应用平台，Nginx直接从MC平台里面找，还有一个内MC，一方面兼容MC，另外一方面，可以进行共享，不需要去读它。另外一点，它实现高可用，负载均衡同时有两个IP对外提供服务，任何一个机器宕了，会到另外一台机器上，电信会看到这两个IP.任何时刻，这两个IP都是OK的。做法功能、应用配置和应用路由的信息都有介绍。第三个功能，就是可以做域名服务。目前SAE是支持域名绑定的，只是没有对外提供渠道，新浪现在没有SAE的资质，仍然支持绑定域名，只要这个域名备案了。下面说到SAE的核心，因为周边的服务除了MySQL、MC比较费劲之外，其他的服务都好说。然后就是Runtime，最初的设计，也是目前的设计，分几层。首先是层，标准的操作系统。第二层，是HTTPSandbox，为什么做沙箱呢？因为这台机器上所有的应用，Runtime有很多的机器，每台机器都能为所有的应用提供服务，所有应用跑在这台机器上，必须做隔离，不管是数据隔离，访问隔离，还有权限控制，资源的控制。目前我们这个上线时间，就有这几个功能。虽然说所有的用户的代码都在我们一台机器上，但是是没有办法访问到其他用户的代码。应当说这个也好做。我们做了很多的工作。做了代码还不行，如果说一个应用被恶意攻击了，因为一个请求，我们看到微三国游戏，一个请求需要花41毫秒，有上万的请求过来，某一个时刻，我们后端的Http服务器的数量会急剧增长，很容易将后端的Runtime撑爆，虽然流量很大，仍然会撑爆。所以我们在HTTP服务器做了并发流量数和内存的限制。可以不通过大量请求的方式，可以直接发每个请求，每个请求Slip一天，肯定是不行的，每一个请求有一个最大的生命周期，就是300秒，超过300苗，HTTP服务器会自动掐掉。最后，就是分轴份额，上面的两个应用都没有超，因为我们对每一个服务都有一个配额，配额的标准不影响其他的应用。如果没有超过上限，因为业务量，资源的慢用，影响到其他的用户，这个时候仍然会被禁用。这是HTTP沙箱和我们后面的Php等沙箱做的最主要的事情。第二个，就是应用配置，高效简单，以及为了HTTP上限的安全。第三项，本地IO，我们之前进行很大的努力，解决数据的抓取，直接兼容了PHP的CRL，后来将时间也改掉了，之前怎么用数据抓取，现在还是怎么用。所以，网络IO被解决了，但是本地IO目前来说，对于云计算，或者分布式系统来说，仍然是一个问题。因为我们的客户大部分都是之前的单机开发者。比如说一个站长的数据直接存在本地，在PHP的环境里面，IO操作函数并没有禁用，但是使用起来有一些限制。提供一个TMPFS，一个生命周期里面，函数是存在的，只要请求结束了，这个文件就消失了。所以说，这保证什么？既保证了临时的IO需求，又不会造成在这台Runtime写的数据，又请求到另外一台机器上，另外一台机器又看不到，再一个请求生命周期，这个文件就消失了，也不想到下一个时段读它，因为本来就不支持。如果想持久化保留数据，可以用我们的Storage的服务，使用我们的接口不太放心，或者懒得自己改，我们直接提供，持久化服务，可以保留数据，保留到后端存储上。MC Wrapper就更简单了，对于PHP的框架，会将动态的设置为静态的，之前他们的做法就是直接保存在本地文件系统里，直接给用户输出。但是仍然不支持本地存储，但是保存在Storage里面也不存储，生成之后效率不太高，但是可以保留在MC里，MC的存储通过Fopen和Fright存储的。最后就是我们开发的，MySQL，并不是用的标准的MySQL.虽然对外的协议，就是用MySQLi，支持，但是我们做了安全性和稳定性的修改。模块，介绍分布式MC的实现，Session也是用那个方式。下面是Memcache，都是我们自己开发的，客户端和服务端都是自己定制的。后面的模块GD，目前用GD库，但是用的并不是单机的GD，GD操作，就是图像操作，里面有大量的配置参数，比如说这个图片要做旋转，或者做拉伸，前面大量的函数做好之后，最后一个函数执行这次变更，并不是再一个Runtime上做的，是将请求发到后端的GD池，处理好再发回给Runtime，CURL也是定制过的，最后XHPROF，是开源的PHP的代码，可以看到执行站的每一个函数，每语句的效益，这是为用户做调试用的。这是Runtime的设计和开发考虑。用户这一段，通过SVN部署他们的代码。用户创建一个应用，自动初始化一个SVN的仓库，SVN提供很多的内容，我们所有工作都是在Pre conmit(音译做的。用客户端修改完代码Checkin，或者最开始提供的桌面STK，直接Ctrl s，或者直接应用，这么多渠道都对接了SVN的内容，我们并不是标准的SVN的协议，而是用的HHTPS WEBDAP(音译)的协议。没有什么特别，但是代码上来之后，在脚本里面，就可以看到这次的更新是什么内容，有哪些变更，这时候我们通过代码分发，我们有一个支持P2P的代码系统，也是完全自主开发的，没有使用任何第三方开源框架。部署到近百台的Work服务器，有这么大的服务器，用户感觉不到，一个工作一秒之内就可以完成，之后就可以看到修改完代码之后的变更。下面重点介绍，最难的就是的沙箱，沙箱做好了，用户由于企业重度依赖的MySQL，也需要做隔离。Runtime用户的请求过来，会走到我们一个系统，系统叫做RDC，RDC是一个透明代理。然后用户的所有请求通过这个透明代理，会扔到后端的MySQL池。我们先说透明代理干什么的？大家可以想像，一个PaaS平台，有很多的用户，用的都是数据库，其中只要有任何一个用户写了一个SQL扔到MySQL服务器上，没有办法在很短时间内运行成功的，这样的SQL如果扔到MySQL池子里，可能对我们的MySQL服务，是一个毁灭性的影响。所以说，RDC的中间层，做的第一个事情，是透明代理，第二个就是做SQL预判，我们根据新浪数据库平台这么多年来，对于SQL的分析，我们制定了一套过滤规则。比如说匹配规则，我们百分之百的确认，扔到后端，必造成后端可能在几分钟或者一两个小时之内，只要超过几分钟执行不完，就会把这条语句过滤。我们做了预判和过滤，很多用户担心，我的SQL是否会直接被过滤掉。从我们目前统计来看，99.9%的SQL是OK的，大概有0.01%的SQL通过这个方面直接过滤掉，0.01%对数据库来说是致命的。目前来看，用户在这块的抱怨，基本上就是消除了。因为他想到了最开始，我们就要把SQL写好，写不是随便写一个，再后来出现问题的时候再优化，并不是这样的。我们鼓励最开始做优化。RDC还做一个健康检查，我们后端这么多池子，如何一台有从了，一台从，没有保持同步了，可能差了十秒，这个时候会选择另外一个从，如果还不行的话，如果在维护的时候，这个机器要重启，数据导出，我们直接停了，没有关系，因为RDC将所有的请求并向到主层上，主层断了的话，SAE目前还没有办法，目前为止，SAE还没有发生这样的事情。大家都知道，关于数据库，我们能做的就是在主层这块做工作。如果我们再做一个主的互备，主坏了，迁移到另一台主层，可以实现，微博数据库，我们做了很多的测试，结果显示还不如人工响应更安全和快速。我们上去跑一个脚本，或者我们直接在平台，就可以完成，不需要自动来做。这是健康检查和故障切换，Slave到Slave，之后到Master.我们的MySQLPool重要的特点就是单实例，实例就是进程，目前大概一个数据库，就是一个MySQL集成多的话有五千多个数据库，大家觉得太荒唐或者很不合理，能跑五千个数据库，太不可思议了，但是目前来看，MySQL负载很低，很健康，并不是说使用少。而是说，通过透明代理过来的SQL都是健康的，到了MySQL很快就结束了。所以说，不会对我们的数据库造成多大的压力。还有多用户。MySQL也要做沙箱，这个比较简单，我们依赖于MySQL自己提供的用户授权，就完成用户的隔离。MySQL的权限还是值得信赖的。DB动态分配，一个用户创建，在前台点一个数据库，在后端的MySQL池子里选空闲的机器分配DB.当时有一些特点，一主两从，让所有用户享受到高数据的保障。这基本上是最高的级别，SAE开发标准就是微博设计标准，或者微博主张的标准，任何用户享受高标准的数据库服务。通过一主两从，就是冷热备，可以在14天之内任意做数据的恢复。经常有一些用户，进行，一不小心点错程序了，需要我们帮助他们做数据，我们很快将自动恢复直接推到前台，用户指定一个时间点，自动完成，自动恢复。99.99%的可靠性。高性能，单实例，支持多DB，没有问题。这是MySQL服务。花了不少的，仅次于Runtime的设计。还有Memcache，高性能，大访问量的Memcache不能不用。Memcache也是这样的，单实例多用户，大家从谷歌搜高端的Memcache，我们后端做了多实例的改造。要实现单个进程、多个用户，第一点就是用户想到了，因为大家用过Memcache都知道，或者我一上去之后，就能Gate别人的数据，就是我们要做这个，会遇到这个问题。怎么做呢？我们在Memcache标准的基础上做了二次开发，就是解决Memcache服务器端做了一个概念，就是说一个用户进来之后，我们在MC的协议上，因为我们的客户端是自己开发的，我们不依赖于标准的客户端，首先给用户发一个协议，是在哪个命名空间的，跟MC的客户端有协议，接下来所有的协议请求，都是在这个命名空间，都不会Gate到别人的数据。还有一个重要的就是在线扩容，用过Memcache都知道，一个Memcache其中有一个参数，我是指定Memcache最大能分配多少内存，对于用户来说，不可能给几个G的内存，下次想调容量的时候，重启一下Memcache，是不可能的。我们在命名空间里面，可以通过我们的控制面板，直接调整容量，我们Memcache做一个标记，就可以支持MC容量，只要不超过单台Memcache大概48G内存，都可以满足。统计和计费，这不用说了，我们对Memcache的容量，或者对于他的请求做计费统计。还做了一个重要的事情，就是连接数的LRU，首先单台MC进程支持的并发，就是在十万级别的。如果是在非常特殊的情况下，大量用户用MC，我们这时会做选取快进快出，这是在MC上的实现。下面说到另外一个服务，就是ServiceGate，Runtime对接很多自己开发的服务，Runtime也能对接第三方服务。比如说一个短信业务，用户通过接口直接从我们平台上调用移动的短信接口发短信，我们这里完成计费和统计。其他的服务，有互联网行业最关心的几大服务，还有已经开发上线的产品，有些是通过内部上线。邮件服务通过我们平台直接发送，安全扫描还没有上线，新浪有一个安全部门，负责新浪所有产品线的安全检测，漏洞扫描等服务。在安全领域内，包装一个服务，然后做成了接口，用户只要在控制面板，这个控制面板就是发起请求，对应用进行扫描，这个时候会对你的日志、SQL语句、前端做判断，就是是否有漏洞，日志有什么异常，都可以给予提示。地理位置服务，这是新浪移动事业部提供的一个接口，不是我们自己开发的。包括，也是新浪安全部门做的。地理位置服务，是新浪移动部门做的，我们通过前面ServiceGate对接这个服务。图片处理GD，还支持Images，还有计数器服务，游戏需求比较大，还有全文检索，短信服务目前就是内部开发。应用已经上线了，可以对自动判断，每一分钟超过一千个请求，从某一台机器过来，设置一个条件，打造这个条件之后，就会自动的被过掉，在公有云的环境下，别人请求你的资源，会消耗你的钱，对于传统的虚拟厂商来说，因为已经一次性付了，比如说一千块钱一个月，别人再怎么攻击和撑，也不会再增大，大不了应用不能访问。但是对于公有云来说，所有的流量、带宽都有计费的，如果请求你的资源，我们就是支付多的钱，我们付出了带宽的资源，然后还可以设一个条件。CDN，还有的配置，新浪自己开发的一套咨询服务。这是已经开放的，或者内部测试的几大重要服务。下面说一下SAE的安全，跟架构联系非常紧密，设计之初就考虑安全的问题了。第一层，从最外面的用户访问我们的时候，有一个防火墙，能避免对平台大规模的攻击。这是第一层，这一层除了做防火墙控制，再就是端口限制，这层防火墙比较简单了。到了我们的反向之后，因为给Runtime发过去的信息，可能会是伪造的，目前来说，是没有办法伪造，从负载均衡发信息的话，中间是代码跑的地方，就是编程的地方，编程的地方是没有办法，比如从某一台Web服务器，到另外一台Web服务器，压根没有走这里，因为这是不可能的。Web 服务器，直接发请求是不可能的。大家可以看到，这里的几条线及这是新浪的内网，还有公共网。除了自己的服务能通之外，新浪的内网都不能通的，就是把隔离了，也就是说想发请求是不可能的。这里保证了负载均衡过来的数据是安全的。Runtime向我们所有的后端服务，MySQL、MC、图像服务等都有非常严格的监测。不能从Runtime发起对其他应用的MySQL请求，这是不行的。如果说应用需要防攻，比如抓什么API，默认只能通过一层Fetchurl出去，通过正向代理出去。Fetchurl是完全金融的URL，跟单机使用没有任何的区别。开发者部署这一层，最近因为密码泄露的问题比较多，新浪的SAE已经上线了动态密码。很简单，你下载一个App，然后一个移动应用安装到上，每分钟会生产一个随机码，在部署的时候，输入随机码，这样即使密码泄露也没有问题的。这是SAE在安全上的考虑。下面介绍一下SAE的企业服务，第一，就叫SAE的企业服务，我们为企业提供个性化解决方案和咨询服务。比如说应用发生什么问题，可以随时跟我们工程师，或者是我们的技术经理一对一的沟通。第三方服务接入，目前对接了前面说的案例，在扩展服务里面，爱立信的API已经对接了，新浪自己的短信安全，还有地理位置都已经对接了，这是新浪内部，都是通过ServiceGate.你是，或者是淘宝的，跟新浪其他部门没有任何区别，都可以对接SAE.第三，是推荐应用，开发者可以在我们的应用商店里面应用，目前都是免费和开源的。SAE企业服务，按需提升分钟配额，前面我们说到分钟配额是为了避免某个应用大量消耗资源，以至于影响其他的应用。像微游戏的应用，本来消耗大量的资源，这时候会按需提升分钟配额，更高的存储和并发上限，禁用保护等。我们对于大企业提供咨询保护，有一个分钟配，是发一个通知，而不是禁止，如果没有芸豆了，也可以联系。还有高级的服务，域名绑定，本身没有资质，我们只是尽最大的努力帮助客户做域名绑定。DBA服务，客户对MySQL做审查，有任何的问题，都可以直接胡椒DBA.CDN服务，新浪敏感内容主动监测的服务，也做成了API，帮助SAE.如果是一个平台提供商，有很多大量的内容，可以通过所有的接口做一下预判，电话技术支持，应用迁移指导，应用架构指导，企业培训。微游戏、微三国都是属于SAE企业服务，我们会做一些培训，他们有任何的问题都可以咨询我们。微游戏和微三国，是我直接给他们做支持的。第三方服务接入，新浪其他部门，也可以是其他公司的产品。除了从SAERuntime发起请求之后，手机端和PC端可以通过这一点对接第三方，统计配额等功能。应用商店，我们提供了很多的应用，上线之后，所有的用户都可以。目前还没有收费，全是免费的应用，非常鼓励应用开发者或者其他公司上架应用。这是企业客户的评价。这里加了引号，这里都是他们自己写的，一个字都没有改过。五分钟张伟志给予评价，还有自游网CEO吴军的评价，还有微三国的游戏负责人赵立元的评价。他们上线微三国之后，终于能安稳的睡觉了，不需要半夜收短信了。SAE的企业服务，如果大家感兴趣的话，可以联系我们的商务经理，可以随时在微博上@我，也可以给我邮件!提问：请教一下，我们在数据安全、代码安全这块，有没有法律的保证？我们公司是金融企业，上传数据的时候，有没有保障？我看到你讲的时候，有很多是自己开发的内容，我们在移植的时候会不会有问题？比如说我们在SAE上开发的代码，移植到其他的平台上，会不会有一些问题？新浪研发中心技术经理程辉：安全问题，我们在安全上，SAE只是在技术上保证用户代码不可被窃取。还有乌平台，就是跑在SAE上，乌云平台，是中国最著名的安全团队，他们目前跑在SAE上，有一个故事，虽然是中国最著名的安全团队，他们主站在上个月有一次被了，首页被篡改了，目的就是为了把乌云的平台，。org给攻击了，以为是团队的主站，攻击之后，改了首页，找半天也没有找到，因为在SAE平台上，是不可以写的，任何用户不可以篡改的，并不是技术上的漏洞，而是通过社会攻击的，找到其中一个管理员，在其他网站上注册了帐号，直接登录到他们的Wordprass，把首页篡改了，运行在SAE平台上的。org非常安全，对我们的评价也非常高。他们也对SAE进行很完整的分析，从自己的角度审查SAE的安全。SAE只是在技术上做尽量的保障，金融企业有特殊要求，我们可以签订单独的协议保证安全。代码移植的问题，我说了，SAE开发之初，一直努力的事情，尽量跟标准的LAMP一致，本地IO不能往本地写，本地持久的写以外，必须写在我们的持久存储之内，除了这一点没有任何其他的差别。一方面，是保持兼容，一方面有任何问题，工程师会有一对一的支持，不管是迁出还是迁进。提问：咱们SAE能不能提供。net的环境支持？就是的平台。新浪研发中心技术经理程辉：目前SAE没有这个计划，目前有Pyhthon和JAVA，因为。net不是开源的，没有办法根据需求做改进。SAE是一个PaaS平台，我们有大客户就是。net的客户，目前SAE开发了私有云，没有对外开发，只是对我们的大客户，如果有需求，可以申请这个平台，跟在亚马逊的完全一样，对虚拟机有完全的自主权限，初期不打算开发。提问：你刚刚讲到的还是安全的问题，你说的所谓的防火墙是什么？跟传统的网络安全没有任何的区别。作为一个用户，把代码和数据放到新浪上，结果是什么？你的系统管理员能Check到这些数据，我问你们自己的系统管理员。新浪研发中心技术经理程辉：第二个问题是确定的，我们的系统管理员是可以Check您的数据，勿庸置疑。因为我们后端并没有做加密文件系统，或者代码没有做加密处理，这是确定的。但是在机制上，只有目前我和另外两个SAE创始人，能直接接触到用户的代码，所以普通的员工，包括SAE的普通员工，是没有这个权限的。对于公有云来讲，确实有这个问题。第一个问题，跟传统的防火墙没有任何的差别，我们在技术上将可能出现安全漏洞的地方，尽量补上，我们凭自己的实力，没有办法规避所有的安全问题。一方面在周边的网络环境下，另一方面在沙箱这块做技术改造。我们后期出一份关于沙箱安全的报告，在理由上、技术上，如何保障用户代码不可被窃取。另外一方面，积极邀请国内安全团队对我们的SAE进行各种审查。目前来看，应该说是非常安全的。因为对上面的老大，任何的数据都有权限的，这是所有互联网企业运营最大的问题。
新浪研发中心技术经理程辉：大家好!非常高兴和荣幸共聚一堂，讨论新浪的SAE架构设计。昨天我们已经听了很多关于云计算、数据中心的各种概念，会后我跟一些朋友讨论了，尤其是之前没有做过这个领域的朋友，他们仍然感觉云计算这个概念还是很虚，一说到云计算三个字，就感觉是非得建一个五星级的云计算数据中心，或者是在数据中心建设上投入大量的资金，才能感受和体验到云计算。在我们看来不是这样的。在我们看来，要体验云计算很简单，只需要一个ID，只要一个微博帐号，只需要低于1块钱，就能体验到云计算相关的技术，能为企业、个人带来实惠，这才是真正的云计算。
下面我们开始谈一下新浪在云计算PaaS平台SAE的设计和架构。今天主要有以下三方面的内容。
第一方面，我们介绍一下SAE的需求和背景。我们首先会试用一下SAE，从外表看到底是什么东西。第二，我们从几个方面来阐述SAE能给我们带来什么，能承担什么应用。第三，我们在这里发布一些SAE的数据。
第二，也是今天的重点，我们会从上面的背景和需求出发，阐述SAE的设计。包括在安全上的考虑。
第三，SAE的企业服务，我们介绍一下。
先来试用，大家在谷歌和百度做过SAE，第一个就能进到新浪Appengine首页，简单高效的应用开发和运行平台，这是一句广告语，我们会用这句话来做阐述。从这里来看，不需要任何的邀请，不需要投入多大的资金，只需要有一个微博ID就可以体验。我们登录进来之后，看到自己的应用列表，我们可以看到，目前SAE支持三大平台，PHP Pashion和JAVA，PHP目前是全开放的，后两种是处于测试阶段，很快就会开发出来。我来之前创建了一个应用，这个只是测试一下。我们这里可以选择我们平台的开发语言，PHP Pashion和JAVA，创建一个应用，点击进入一个应用首页，映入眼帘的是资源统计，SAE的资源统计非常丰富，能够看到像PVUP的统计，HTTP，我们能看到每分钟的实时的，或者安全的启用时间等，带宽、CPU消耗等，再就是我们其他的服务，定时任务，队列，数据抓取、图片处理，MC等很多的服务，还有其他的服务没有列出来，后面我们会了解到。
这是我们代码管理，创建一个应用之后，我们第一件事情，就是想到去有一个代码，运行一个Hadwork，目前在我们公司网站直接上传。我们有两个渠道，第一个渠道，创建一个应用，默认就了一个SAE仓库，只需要Check out上来，将代码复制到本地的SO的工作仓库，Checkin就完成部署了。另外，我们如果不习惯，站长习惯用传统的Http方式，我们到现在都没有提供这个方式。另外一个模式，就是提供在线编译器，写完代码之后，这个代码就部署到了我们所有的机器上，就完成代码部署和分发工作。
互联网业务，一些高性能的业务会用到MC，我们的MySQL很简单，传统的要搭建一个环境，用户需要安装一个MySQL服务器，然后装上各种配置，我们这里就是一键完成，点一下应用，数据库就在这里了，我们可以直接管理我们的应用，或者给其他用户授权，这里也能看到数据库列表。第二，我们这里有一个MC的列表，能看到MC的利用率和内存占用率，这里也可以做测试，也可以及时的调整MC的容量。这就是资源报表，这一页我们看到了很多重要的信息，第一，就是价格。比如说带宽，我们后台计费精确到每一KB，100个芸豆等于1块钱，就是2.4元一个GB.大概填完之后，我们接下来看一下新浪的SAE是什么，定位是什么？
首先，我这里把SAE的全程写出来，就是Sina Appengine，engine是一个应用引擎。我们的应用是什么呢？大家可以看，应用可以是一个平台级的应用，比如说微游戏，目前新浪微博的微游戏频道是最赚钱的频道，除了主要业务之外流量最大的频道。之前，在下面这个大空白地方，我列了一些微游戏的数据，后来领导说，我们不是官方，不便公布，但是可以给大家一个数量级，微游戏目前的PV是在三亿左右，每天都是这样，应该是SAE最大的应用。
它在我们平台上，自己不需要投入任何的运维相关的人力，这么大的平台，不需要一个运维，一个运维都没有，一个系统工程师都没有。微游戏是新浪跟五分钟团队合作的一个项目，他们主要做应用逻辑的开发。这是我们的App可以是一个平台级的应用。然后我们的应用也可以是一个工具类的应用，这是微博上非常火热的微盘应用，也是运行在我们的平台上，业务两大概在一亿平维(音译)左右。目前存多少数据？应该是在几十T数量级左右。除了平台即应用，工具类的应用，SAE还运行很多游戏的应用。微三国，是目前微游戏平台，360开放平台运行的游戏。是目前微游戏排名第三第四的样子，PV也是在几千万的级别，日活跃用户大概在百万级别以上，这么大型的应用，我们后面会介绍到负责人使用我们SAE的感受是什么。他们也没有一个运维做后端的部署工作，或者做后端的维护监控工作。全是一个小团队做开发的。
我们这里还有一个门户类的应用，北外的主站已经移到SAE了，这是不花一分钱的，对于一个主站来说，每天几万或者几十万的PV，费用可能太低了，可能在几十块钱左右。对于我们来说，完全可以忽略掉，我们直接对高校免费使用SAE平台。
所以，从这一点来看，现在的Appengine，应用能放什么？取决于用户开发者，或者用户的需求，你们做什么，SAE就能放什么。下面说到SAE首页重要的广告词，简单高效的应用开发和托管平台。托管平台，前面的案例介绍到了。我们说一下简单高效？SAE还有一个频道叫应用商店，应用商店里面可以安装各种别人开发好的，或者别人移植好的应用，比如说安装一个Wordprass，找到之后直接在后端部署装置完成了。跟微游戏、微三国等使用的是同一个环境。只要说Wordprass量很大没有关系，从一个Pv到几十个Pv，后端不需要做任何的事情，我们跟用户有需求，针对需求进行配合，前提是肯定要做一些优化。
对于互联网业务依赖的MySQL，点击优化就可以完成了，所有的操作尽量做到一键化。这在传统的互联网公司是非常难做到的。SAE之前，新浪某一个业务部门有一个产品线上线，原先的数据库平台，得联系运维部门，数据库平台帮助他们分配数据库，数据库平台可能还帮助负载MC，这样下来一周时间过去了。而在这个平台上，几分钟或者一个小时左右，就能完成，自动完成后端的部署。SAE也是一个应用开发的平台，通过SAE，不管是Mac、Windows、Linux，都有SAE的客户端，直接使用就可以。我们不需要登录服务器查看日志，直接在日志中心能看到Http、MySQL、邮件等所有服务的日志。通过我们这个平台，能够看到微游戏的首页，Http服务，每个请求花了多少CPU的时间，这里都有显示。正常的情况下，每一个Http请求只需要41毫秒的时间。应该是SAE里面非常优化的平台，如果应用有波动的话，比如说部署代码，代码业务逻辑处理不好，导致CPU的使用形势急剧上升，或者新浪的页面服务遭到一些故障。
SAE，对于普通用户来说，是一个LAMP平台，已经在后端做了分布式，用户使用起来跟标准LAMP没有什么差别。尤其是我们在PHP运行时间开发之初，尽量做到跟标准平台完全兼容。目前除了本地IO没有开放外，所有的平台都做到了兼容。SAE是一个PaaS平台，我不太愿意讲云计算的概念。SAE2009年6月份就开始开发，我们对出开发的目的并不是为了云计算，目的是解决内部的需求，或者是解决普通用户对于应用托管和应用开发的需求。后来，我们快上线了，我们感觉最近这个概念越来越火了，正好确实是PaaS平台的理念和概念，我们就认为它是PaaS平台了。
发布一些SAE的数据，目前PV量/日是5亿，截止到1月10号凌晨，有17万个应用。14万个开发者，开发者应该有六成以上都是我们认证过的开发者。70%的微博应用托管在SAE平台，SAE有一个应用频道，我们点击就能够看到无数个应用，其中70%是在SAE平台上运行。目前SAE正在跟淘宝合作，他们的开发者可以直接使用SAE平台开发应用。现在就可以，因为SAE是完全开放的，支持所有的平台，不止限于新浪微博。比如说微三国的已经上架360的平台，100%的微博企业合作伙伴正在使用SAE.微博合作伙伴的概念是指，微博上平台上目前开发的美食平台，目前还没有开放，这是内部透露的。还有企业平台、漫画平台、婚恋平台，很多跟微博平台合作的都在，内部已经形成默契，第三方合作伙伴不再分配服务器了，直接使用SAE.下面进入今天的重点。前面就是试用的情况，外表上SAE是什么样，现在从SAE的需求入手，讨论SAE背后的设计。这是SAE的总体架构，这张图，不管是在首页，还是在其他的分享会议上，这张图都是没有的，这是这几天精心打造的一张图，比较形象。我们对外公布了一些架构图，在其他的分享活动上，我们其他的开发者，包括我们的同事也做了图。我总感觉还是有点虚，不够实，这里具体一点。
这里有两个角色，一个角色是User，不是指用户，是我们普通的应用访问者，我们叫Vistor，第二个角色是开发者。我们的Vistor找到的负载均衡，有路由的作用，到每一台服务器，下面专门介绍到。负载这一层到客户真正执行业务逻辑层面，就是PHP和Java.到了中间这一层，跟我们后端各个服务打交道，比如跟MySQL，MySQL没有办法用标准的MySQL，我们自己做了一个代理，会用到我们自己开发的KVDB服务，还有改造过的MC服务，还有数据抓取，我们不可能直接从后端那么多机器上访问Web网。数据出去都需要通过数据代理，还有Cron的服务。下面重点介绍一下Servicegate，通过这个门，可以对接第三方其他的服务。这是一个用户进来以后，通过负载均衡到达Runtime，如果业务逻辑没有使用的话，其他服务都会从Runtime请求调用，开发者会走这条路，通过SVN，把代码Check out下来，直接Check in，首先通过Code到代码部署的中型机，会将目前的更新分发到Runtime，后端是无线扩展的，目前可以透露一下，后端大概有几百台。这个中心也是多点的，是PHP的，一份更新、代码直接部到几百台服务器上。
下面重点介绍一下架构里面的各个子部分。动态DNS，从这里可以看到，一个普通的用户，比如说ABC.app.com，问ABC的应用，通过域名直接解析到新浪的SAE的更新。还有一个机房是国外的用户和小运营商，比如说歌华有线等小运营商，会有一个PHP的机房，五大机房到新浪的SAE提供业务逻辑的机房，中间有高速通道，机房全在北京，然后通过光纤通道直接到我们的SAE核心机房。这样有什么好处？因为我们现在很难找到一个机房，能支持所有的主流运营上还能覆盖小运营商，在目前来说是不可能的。
所以说，只能通过不同的机房之间的高速光纤通道来解决目前国内的高速访问的问题。这一套动态DNS，对SAE应用有一个纪要，能看到全国所有的城市都是绿色的，也就是说请求都是理想的。对于传统的IDC或者传统虚拟主机来讲，很难做到这一点，因为总是在一个机房来做的。其实，这套东西并不是SAE专属的，是新浪本来就有的，SAE正好用上这套资源。对于我们普通的开发者来说，部署一个简单的应用，直接就使用了新浪这么久以来打造的非常完好的各大运营商、各大线路的支持。
我们从这里可以看到，多线路的支持，针对解析IT容灾，有两个IDC做互备的。下面说到另外一个核心，就是负载均衡层，或者路由层。路由层基于nginx进行二次开发，nginx本来没有状态，一个应用请求大了以后，需要将请求分发下去，必须得存很多的状态信息。比如说APP，因为用户给负载均衡发送的请求就是标准的请求，会有一个UIA，凭这两个东西要帮助找到是哪台服务器做的开发，是JAVA平台还是其他的平台，应用有配置信息在里面，都是通过高速的缓存。第一版是直接拿一个MC，MC存储的平台的应用平台，Nginx直接从MC平台里面找，还有一个内MC，一方面兼容MC，另外一方面，可以进行共享，不需要去读它。
另外一点，它实现高可用，负载均衡同时有两个IP对外提供服务，任何一个机器宕了，会到另外一台机器上，电信会看到这两个IP.任何时刻，这两个IP都是OK的。做法功能、应用配置和应用路由的信息都有介绍。第三个功能，就是可以做域名服务。目前SAE是支持域名绑定的，只是没有对外提供渠道，新浪现在没有SAE的资质，仍然支持绑定域名，只要这个域名备案了。
下面说到SAE的核心，因为周边的服务除了MySQL、MC比较费劲之外，其他的服务都好说。然后就是Runtime，最初的设计，也是目前的设计，分几层。首先是操作系统层，标准的操作系统。第二层，是HTTPSandbox，为什么做沙箱呢？因为这台机器上所有的应用，Runtime有很多的机器，每台机器都能为所有的应用提供服务，所有应用跑在这台机器上，必须做隔离，不管是数据隔离，访问隔离，还有权限控制，资源的控制。目前我们这个上线时间，就有这几个功能。虽然说所有的用户的代码都在我们一台机器上，但是是没有办法访问到其他用户的代码。应当说这个也好做。我们做了很多的工作。做了代码还不行，如果说一个应用被恶意攻击了，因为一个请求，我们看到微三国游戏，一个请求需要花41毫秒，有上万的请求过来，某一个时刻，我们后端的Http服务器的数量会急剧增长，很容易将后端的Runtime撑爆，虽然流量很大，仍然会撑爆。所以我们在HTTP服务器做了并发流量数和内存的限制。可以不通过大量请求的方式，可以直接发每个请求，每个请求Slip一天，肯定是不行的，每一个请求有一个最大的生命周期，就是300秒，超过300苗，HTTP服务器会自动掐掉。
最后，就是分轴份额，上面的两个应用都没有超，因为我们对每一个服务都有一个配额，配额的标准不影响其他的应用。如果没有超过上限，因为业务量，资源的慢用，影响到其他的用户，这个时候仍然会被禁用。这是HTTP沙箱和我们后面的Php等沙箱做的最主要的事情。
第二个，就是应用配置，高效简单，以及为了HTTP上限的安全。
第三项，本地IO，我们之前进行很大的努力，解决数据的抓取，直接兼容了PHP的CRL，后来将时间也改掉了，之前怎么用数据抓取，现在还是怎么用。所以，网络IO被解决了，但是本地IO目前来说，对于云计算，或者分布式系统来说，仍然是一个问题。因为我们的客户大部分都是之前的单机开发者。比如说一个站长的数据直接存在本地，在PHP的环境里面，IO操作函数并没有禁用，但是使用起来有一些限制。提供一个TMPFS，一个生命周期里面，函数是存在的，只要请求结束了，这个文件就消失了。所以说，这保证什么？既保证了临时的IO需求，又不会造成在这台Runtime写的数据，又请求到另外一台机器上，另外一台机器又看不到，再一个请求生命周期，这个文件就消失了，也不想到下一个时段读它，因为本来就不支持。如果想持久化保留数据，可以用我们的Storage的服务，使用我们的接口不太放心，或者懒得自己改，我们直接提供封装，持久化服务，可以保留数据，保留到后端存储上。
MC Wrapper就更简单了，对于PHP的框架，会将动态的设置为静态的，之前他们的做法就是直接保存在本地文件系统里，直接给用户输出。但是仍然不支持本地存储，但是保存在Storage里面也不存储，生成之后效率不太高，但是可以保留在MC里，MC的存储通过Fopen和Fright存储的。最后就是我们开发的模块，MySQL，并不是用的标准的MySQL.虽然对外的协议，就是用MySQLi，支持，但是我们做了安全性和稳定性的修改。Session模块，介绍分布式MC的实现，Session也是用那个方式。下面是Memcache，都是我们自己开发的，客户端和服务端都是自己定制的。后面的模块GD，目前用GD库，但是用的并不是单机的GD，GD操作，就是图像操作，里面有大量的配置参数，比如说这个图片要做旋转，或者做拉伸，前面大量的函数做好之后，最后一个函数执行这次变更，并不是再一个Runtime上做的，是将请求发到后端的GD池，处理好再发回给Runtime，CURL也是定制过的，最后XHPROF，是Facebook开源的PHP的代码，可以看到执行站的每一个函数，每一条语句的效益，这是为用户做调试用的。这是Runtime的设计和开发考虑。
用户这一段，通过SVN部署他们的代码。用户创建一个应用，自动初始化一个SVN的仓库，SVN提供很多的内容，我们所有工作都是在Pre conmit(音译做的。用客户端修改完代码Checkin，或者最开始提供的桌面STK，直接Ctrl s，或者直接应用，这么多渠道都对接了SVN的内容，我们并不是标准的SVN的协议，而是用的HHTPS WEBDAP(音译)的协议。没有什么特别，但是代码上来之后，在脚本里面，就可以看到这次的更新是什么内容，有哪些变更，这时候我们通过代码分发，我们有一个支持P2P的代码系统，也是完全自主开发的，没有使用任何第三方开源框架。部署到近百台的Work服务器，有这么大的服务器，用户感觉不到，一个工作一秒之内就可以完成，之后就可以看到修改完代码之后的变更。
下面重点介绍，最难的就是Web服务器的沙箱，沙箱做好了，用户由于企业重度依赖的MySQL，也需要做隔离。Runtime用户的请求过来，会走到我们一个系统，系统叫做RDC，RDC是一个透明代理。然后用户的所有请求通过这个透明代理，会扔到后端的MySQL池。我们先说透明代理干什么的？大家可以想像，一个PaaS平台，有很多的用户，用的都是数据库，其中只要有任何一个用户写了一个SQL扔到MySQL服务器上，没有办法在很短时间内运行成功的，这样的SQL如果扔到MySQL池子里，可能对我们的MySQL服务，是一个毁灭性的影响。所以说，RDC的中间层，做的第一个事情，是透明代理，第二个就是做SQL预判，我们根据新浪数据库平台这么多年来，对于SQL的分析，我们制定了一套过滤规则。比如说匹配规则，我们百分之百的确认，扔到后端，必造成后端可能在几分钟或者一两个小时之内，只要超过几分钟执行不完，就会把这条语句过滤。我们做了预判和过滤，很多用户担心，我的SQL是否会直接被过滤掉。从我们目前统计来看，99.9%的SQL是OK的，大概有0.01%的SQL通过这个方面直接过滤掉，0.01%对数据库来说是致命的。目前来看，用户在这块的抱怨，基本上就是消除了。因为他想到了最开始，我们就要把SQL写好，写不是随便写一个，再后来出现问题的时候再优化，并不是这样的。我们鼓励最开始做优化。
RDC还做一个健康检查，我们后端这么多池子，如何一台有从了，一台从，没有保持同步了，可能差了十秒，这个时候会选择另外一个从，如果还不行的话，如果在维护的时候，这个机器要重启，数据导出，我们直接停了，没有关系，因为RDC将所有的请求并向到主层上，主层断了的话，SAE目前还没有办法，目前为止，SAE还没有发生这样的事情。大家都知道，关于数据库，我们能做的就是在主层这块做工作。如果我们再做一个主的互备，主坏了，迁移到另一台主层，可以实现，微博数据库，我们做了很多的测试，结果显示还不如人工响应更安全和快速。我们上去跑一个脚本，或者我们直接在运维管理平台，就可以完成，不需要自动来做。这是健康检查和故障切换，Slave到Slave，之后到Master.我们的MySQLPool重要的特点就是单实例，实例就是进程，目前大概一个数据库，就是一个MySQL集成多的话有五千多个数据库，大家觉得太荒唐或者很不合理，能跑五千个数据库，太不可思议了，但是目前来看，MySQL负载很低，很健康，并不是说使用少。而是说，通过透明代理过来的SQL都是健康的，到了MySQL很快就结束了。所以说，不会对我们的数据库造成多大的压力。还有多用户。
MySQL也要做沙箱，这个比较简单，我们依赖于MySQL自己提供的用户授权，就完成用户的隔离。MySQL的权限还是值得信赖的。DB动态分配，一个用户创建，在前台点一个数据库，在后端的MySQL池子里选空闲的机器分配DB.当时有一些特点，一主两从，让所有用户享受到高数据的保障。这基本上是最高的级别，SAE开发标准就是微博设计标准，或者微博主张的标准，任何用户都可以享受高标准的数据库服务。通过一主两从，就是冷热备，可以在14天之内任意做数据的恢复。经常有一些用户，进行数据库的管理，一不小心点错程序了，需要我们帮助他们做数据，我们很快将自动恢复直接推到前台，用户指定一个时间点，自动完成，自动恢复。99.99%的可靠性。高性能，单实例，支持多DB，没有问题。这是MySQL服务。花了不少的精力，仅次于Runtime的设计。还有Memcache，高性能，大访问量的Memcache不能不用。
Memcache也是这样的，单实例多用户，大家从谷歌搜高端的Memcache，我们后端做了多实例的改造。要实现单个进程、多个用户，第一点就是用户想到了，因为大家用过Memcache都知道，或者我一上去之后，就能Gate别人的数据，就是我们要做这个方案，会遇到这个问题。怎么做呢？我们在Memcache标准的基础上做了二次开发，就是解决Memcache服务器端做了一个概念，就是说一个用户进来之后，我们在MC的协议上，因为我们的客户端是自己开发的，我们不依赖于标准的客户端，首先给用户发一个协议，是在哪个命名空间的，跟MC的客户端有协议，接下来所有的协议请求，都是在这个命名空间，都不会Gate到别人的数据。
还有一个重要的就是在线扩容，用过Memcache都知道，一个Memcache其中有一个参数，我是指定Memcache最大能分配多少内存，对于用户来说，不可能给几个G的内存，下次想调容量的时候，重启一下Memcache，是不可能的。我们在命名空间里面，可以通过我们的控制面板，直接调整容量，我们Memcache做一个标记，就可以支持MC容量，只要不超过单台Memcache大概48G内存，都可以满足。
统计和计费，这不用说了，我们对Memcache的容量，或者对于他的请求做计费统计。还做了一个重要的事情，就是连接数的LRU，首先单台MC进程支持的并发，就是在十万级别的。如果是在非常特殊的情况下，大量用户用MC，我们这时会做选取快进快出，这是在MC上的实现。下面说到另外一个服务，就是ServiceGate，Runtime对接很多自己开发的服务，Runtime也能对接第三方服务。比如说中国移动一个短信业务，用户通过接口直接从我们平台上调用移动的短信接口发短信，我们这里完成计费和统计。其他的服务，有互联网行业最关心的几大服务，还有已经开发上线的产品，有些是通过内部上线。邮件服务通过我们平台直接发送，安全扫描还没有上线，新浪有一个安全部门，负责新浪所有产品线的安全检测，漏洞扫描等服务。在安全领域内，包装一个服务，然后做成了接口，用户只要在控制面板，这个控制面板就是发起请求，对应用进行扫描，这个时候会对你的日志、SQL语句、前端做判断，就是是否有漏洞，日志有什么异常，都可以给予提示。地理位置服务，这是新浪移动事业部提供的一个接口，不是我们自己开发的。包括安全服务，也是新浪安全部门做的。地理位置服务，是新浪移动部门做的，我们通过前面ServiceGate对接这个服务。图片处理GD，还支持Images，还有计数器服务，游戏需求比较大，还有全文检索，短信服务目前就是内部开发。应用防火墙已经上线了，可以对自动判断，每一分钟超过一千个请求，从某一台机器过来，设置一个条件，打造这个条件之后，就会自动的被过掉，在公有云的环境下，别人请求你的资源，会消耗你的钱，对于传统的虚拟厂商来说，因为已经一次性付了，比如说一千块钱一个月，别人再怎么攻击和撑，也不会再增大，大不了应用不能访问。但是对于公有云来说，所有的流量、带宽都有计费的，如果请求你的资源，我们就是支付多的钱，我们付出了带宽的资源，然后还可以设一个条件。
CDN内容分发，还有直接在线的配置，新浪自己开发的一套咨询服务。这是已经开放的，或者内部测试的几大重要服务。
下面说一下SAE的安全，跟架构联系非常紧密，设计之初就考虑安全的问题了。第一层，从最外面的用户访问我们的时候，有一个防火墙，能避免对平台大规模的攻击。这是第一层，这一层除了做防火墙控制，再就是端口限制，这层防火墙比较简单了。到了我们的反向之后，因为给Runtime发过去的信息，可能会是伪造的，目前来说，是没有办法伪造，从负载均衡发信息的话，中间是代码跑的地方，就是编程的地方，编程的地方是没有办法，比如从某一台Web服务器，到另外一台Web服务器，压根没有走这里，因为这是不可能的。Web 服务器，直接发请求是不可能的。大家可以看到，这里的几条线及这是新浪的内网，还有公共网。除了自己的服务能通之外，新浪的内网都不能通的，就是把新浪内网隔离了，也就是说想发请求是不可能的。这里保证了负载均衡过来的数据是安全的。
Runtime向我们所有的后端服务，MySQL、MC、图像服务等都有非常严格的监测。不能从Runtime发起对其他应用的MySQL请求，这是不行的。如果说应用需要防攻，比如抓什么API，默认只能通过一层Fetchurl出去，通过正向代理出去。Fetchurl是完全金融的URL，跟单机使用没有任何的区别。
开发者部署这一层，最近因为密码泄露的问题比较多，新浪的SAE已经上线了动态密码。很简单，你下载一个App，然后一个移动应用安装到手机上，每分钟会生产一个随机码，在部署的时候，输入随机码，这样即使密码泄露也没有问题的。这是SAE在安全上的考虑。
下面介绍一下SAE的企业服务，第一，就叫SAE的企业服务，我们为企业提供个性化解决方案和咨询服务。比如说应用发生什么问题，可以随时跟我们工程师，或者是我们的技术经理一对一的沟通。第三方服务接入，目前对接了前面说的案例，爱立信在扩展服务里面，爱立信的API已经对接了，新浪自己的短信安全，还有地理位置都已经对接了，这是新浪内部，都是通过ServiceGate.你是人人网，或者是淘宝的，跟新浪其他部门没有任何区别，都可以对接SAE.第三，是推荐应用，开发者可以在我们的应用商店里面应用，目前都是免费和开源的。SAE企业服务，按需提升分钟配额，前面我们说到分钟配额是为了避免某个应用大量消耗资源，以至于影响其他的应用。像微游戏的应用，本来消耗大量的资源，这时候会按需提升分钟配额，更高的存储和并发上限，禁用保护等。我们对于大企业提供咨询保护，有一个分钟配，是发一个通知，而不是禁止，如果没有芸豆了，也可以联系。还有高级的服务，域名绑定，本身没有资质，我们只是尽最大的努力帮助客户做域名绑定。DBA服务，客户对MySQL做审查，有任何的问题，都可以直接胡椒DBA.CDN服务，新浪敏感内容主动监测的服务，也做成了API，帮助SAE.如果是一个平台提供商，有很多大量的内容，可以通过所有的接口做一下预判，电话技术支持，应用迁移指导，应用架构指导，企业培训。微游戏、微三国都是属于SAE企业服务，我们会做一些培训，他们有任何的问题都可以咨询我们。微游戏和微三国，是我直接给他们做支持的。第三方服务接入，新浪其他部门，也可以是其他公司的产品。除了从SAERuntime发起请求之后，手机端和PC端可以通过这一点对接第三方，统计配额等功能。应用商店，我们提供了很多的应用，上线之后，所有的用户都可以一键安装。目前还没有收费，全是免费的应用，非常鼓励应用开发者或者其他公司上架应用。这是企业客户的评价。这里加了引号，这里都是他们自己写的，一个字都没有改过。五分钟CTO张伟志给予评价，还有自游网CEO吴军的评价，还有微三国的游戏负责人赵立元的评价。他们上线微三国之后，终于能安稳的睡觉了，不需要半夜收短信了。
SAE的企业服务，如果大家感兴趣的话，可以联系我们的商务经理，可以随时在微博上@我，也可以给我邮件!
提问：请教一下，我们在数据安全、代码安全这块，有没有法律的保证？我们公司是金融企业，上传数据的时候，有没有保障？我看到你讲的时候，有很多是自己开发的内容，我们在移植的时候会不会有问题？比如说我们在SAE上开发的代码，移植到其他的平台上，会不会有一些问题？
新浪研发中心技术经理程辉：安全问题，我们在安全上，SAE只是在技术上保证用户代码不可被窃取。还有乌云安全平台，就是跑在SAE上，乌云平台，是中国最著名的安全团队，他们目前跑在SAE上，有一个故事，虽然是中国最著名的安全团队，他们主站在上个月有一次被入侵了，首页被篡改了，目的就是为了把乌云的平台，。org给攻击了，以为是团队的主站，攻击之后，改了首页，找半天也没有找到，因为在SAE平台上，是不可以写的，任何用户不可以篡改的，并不是技术上的漏洞，而是通过社会攻击的，找到其中一个管理员，在其他网站上注册了帐号，直接登录到他们的Wordprass，把首页篡改了，运行在SAE平台上的。org非常安全，对我们的评价也非常高。他们也对SAE进行很完整的分析，从自己的角度审查SAE的安全。SAE只是在技术上做尽量的保障，金融企业有特殊要求，我们可以签订单独的协议保证安全。
代码移植的问题，我说了，SAE开发之初，一直努力的事情，尽量跟标准的LAMP一致，本地IO不能往本地写，本地持久的写以外，必须写在我们的持久存储之内，除了这一点没有任何其他的差别。一方面，是保持兼容，一方面有任何问题，工程师会有一对一的支持，不管是迁出还是迁进。
提问：咱们SAE能不能提供。net的环境支持？就是微软的平台。
新浪研发中心技术经理程辉：目前SAE没有这个计划，目前有Pyhthon和JAVA，因为。net不是开源的，没有办法根据需求做改进。SAE是一个PaaS平台，我们有大客户就是。net的客户，目前SAE开发了私有云，没有对外开发，只是对我们的大客户，如果有需求，可以申请这个平台，跟在亚马逊的完全一样，对虚拟机有完全的自主权限，初期不打算开发。
提问：你刚刚讲到的还是安全的问题，你说的所谓的防火墙是什么？跟传统的网络安全没有任何的区别。作为一个用户，把代码和数据放到新浪上，结果是什么？你的系统管理员能Check到这些数据，我问你们自己的系统管理员。
新浪研发中心技术经理程辉：第二个问题是确定的，我们的系统管理员是可以Check您的数据，勿庸置疑。因为我们后端并没有做加密文件系统，或者代码没有做加密处理，这是确定的。但是在内部管理机制上，只有目前我和另外两个SAE创始人，能直接接触到用户的代码，所以普通的员工，包括SAE的普通员工，是没有这个权限的。对于公有云来讲，确实有这个问题。
第一个问题，跟传统的防火墙没有任何的差别，我们在技术上将可能出现安全漏洞的地方，尽量补上，我们凭自己的实力，没有办法规避所有的安全问题。一方面在周边的网络环境下，另一方面在沙箱这块做技术改造。我们后期出一份关于沙箱安全的报告，在理由上、技术上，如何保障用户代码不可被窃取。
另外一方面，积极邀请国内安全团队对我们的SAE进行各种审查。目前来看，应该说是非常安全的。因为对上面的老大，任何的数据都有权限的，这是所有互联网企业运营最大的问题。
读过这篇文章的人还读过：
4006199527
您的位置：