有时间的朋友可以自己观看丛磊的演讲,时间大约1个小时,地址:http://www.infoq.com/cn/presentations/cl-sae-cloud-architecture
下面对演讲内容重点记录如下:
讲座主题本次讲座在SAE整个架构的基础上详细介绍其内部的主要分布式服务:包括分布式数据库集群、分布式缓存系统、轻量级任务队列、重量级任务队列等相关技术。
讲座内容Cloud Service 基本服务介绍
PHP语言平台
Stor分布式文件存储
MemcacheX分布式缓存
DB数据库
RDC分布式数据库集群
TaskQueue简单轻量级异步任务队列服务
Cron分布式定时服务
DeferredJobs重量级离线任务处理队列
FetchurlHTTP抓取
Tmpfs临时文件IO
Appconfig因SAE不支持Apache .htaccess,Appconfig语法更灵活,性能更优秀
SMail邮件发送
Image图片操作
XHProf大名鼎鼎的 Facebook 开源的PHP性能分析与调优工具
以上的开发的团队前端+后端 10人!
SAE Cloud Service 架构
最外端 Level 7 反向代理
服务路由到某个逻辑站点
Web Service PoolsApache 进程池,真正处理用户代码
Async Computing Cloud 同步计算云
Sync Computing Cloud 异步计算云
Permanent Storage 持久化存储
Impermanent Storage 非持久化存储
Statistics Center Log Center 统计日志记录,负责计费、资源使用等记录
SAE 沙盒
App 沙盒(从内到外)
用户PHP代码
PHP Zend5.3.3
SAE Zend Sandbox PHP级用户等隔离
Apache with SAE Appconfig 加载Appconfig
HTTP Server Sandbox 基于用户连接数,连接时间保护
POSIX Linux 基本环境
RDC (Relational DB Cluster)
RDC的目标
监控百万数量级的DB,包括心跳检查、主从同步检查、节点负载
管理百万数量级的DB,包括启动、停止、迁移、重启、切换
被动复制模式的HA
支持MySQL5通讯协议,代理层完全透明,代理损耗低
无状态依赖,自身支持水平扩展
提供用户的DB的隔离性,保证整体集群的安全性
RDC与MySQL在实现上的一些不同
多进程 (SAE) vs 多线程 (MySQL) (稳定性和安全性考虑)
SQL解析,词法分析 vs 语法分析 (性能考虑,词法快于语法)
Query Cache (所有语句均经过词法分析)
特别说明:
RDC不负责用户数据库的水平扩展,所以水平扩展需要用户自己做分表
RDC自身提供一主多从的DB结构,上层支持读写分离
为了整个数据库平台的安全和可靠,RDC会根据自身的预判算法预先屏蔽某些SQL语句
RDC强烈建议用户使用正确的MySQL调用习惯,对每个MySQL函数判断返回值
SAE RDC 架构
读写分离,后端主从同步,
SAE 控制界面开启 RDC
主库 – w.rdc.sae.sina.com.cn : 3307
从库 – r.rdc.sae.sina.com.cn : 3307
RDC Benchmark,RDC vs 标准 MySQL
with QueryCache -5%
without QueryCache -10%
MemcacheX
MemcacheX的目的
Low overhead 解决用户没使用但进程得始终维持的浪费问题
HA 解决重启后数据空的问题
Statics
Connection Protector 并发大的时候,主动关闭Socket功能
Data dump 数据预热
SAE MemcachedX 架构
异步TaskQueue
TaskQueue vs DeferredJobs
URL回调 vs 系统级(C代码)执行
短时间 vs 长时间
TaskQueue 有顺行队列(按部就班)和并发队列(尽快执行)。
SAE TaskQueue 架构
TaskQueue 特性
硬哈希 用户队列名映射到物理存储队列(worker中的进程吧?)
多进程
非阻塞timeout 延迟不影响服务器性能
master-slave 被动复制 内存级主从复制
worker延迟等待时间 防止用户任务队列被分配到多个worker,保证一一对应
worker死亡唤醒检查 把死亡队列更换worker
SAE未来计划
新的代码部署文件系统 保证代码在SAE中只有一个拷贝,目前是多个
无缝迁移 PHP用户迁入SAE
Key-Value 数据库
后记看过' 视频后yunster感觉丛磊是个踏实人,演讲中很多技术细节都阐述的很清楚,而且的确做了很多非常卓越的工作,相信这样的团队做出的东西也是非常靠谱的。
此前,yunster一直对新浪做云计算的决心持怀疑态度。从 SAE 的团队配置来看,新浪并没有投入很多的资源。但 SAE 团队的工程师都比较牛,从无到有果真搭起了SAE的基本框架,实属不易,可喜可贺。不得不承认,像Heroku这样的PaaS能够迅速发展是与IaaS的铺垫有关的。SAE平地起高楼其中的难度也可想而知。应该说 SAE 选择用 PHP 作为语言基础是非常符合国情的,战略上的决策比 Google 要好得多,团队执行力大家也有目共睹,未来的发展应该得到新浪高层更多的重视才对。希望 SAE 能够赶紧铺开抢占市场,很多用户的实际需求还有待实践去检查和完善。云计算说到底重点不是拼技术框架的好坏,而是所提供服务的好坏。希望我们这些云计算的Geek也能够赶快用上国内的好产品吧。
P.S :附加希望,yunster需要一个SAE的邀请码!
本篇文章属个人技术总结以及与大家研讨之用,如有侵权请及时通知yunster处理。