Weibo lamp improvements
42 likes17,446 views
本文讨论了微博系统的发展和优化历程，包括原始架构面临的性能问题及其解决方案，网罗了如yaf框架、pagelet服务化、以及yar RPC框架等关键技术的采用与优化。同时，文中提到了未来的技术发展方向，包括使用NGINX和PHP 5.4的优势，以及灰度发布系统的实施和代码规范的建立。
Weibo lamp improvements
- 2. 微博示意图 2 ?
- 3. 最初的微博 l?? Apache Prefork l?? PHP-5.2 + APC l?? Swift(Simpli?ed Kohana) l?? Smarty l?? BigPipe 3 ?
- 4. 最初的微博 l?? 日访问量巨大, 在业务高速增长期, 架构一直没变 l?? 响应时间越来越慢 l?? 用户效率, 服务成本. l?? 代码量庞大, 只做加法不敢做减法 l?? 开发成本大, 开发周期长 l?? 开发效率 l?? 工作方向 l?? 性能优化 l?? 结构优化 4 ?
- 5. 内容 l?? 性能优化 l?? 框架优化 - Yaf l?? 配置优化 - Weibo l?? 模板优化 - 弃用Smarty l?? 并行化 - CBigpipe l?? 结构优化 l?? PL服务化 – Yar l?? 进行中的工作 l?? 接下来 5 ?
- 6. Yaf – Yet Another framework l?? Yaf l?? PHP社区第一个C语言扩展框架, 最快的PHP框架 l?? 兼容PSR0的自动加载 l?? 基于命名空间的文件目录组织 l?? 自带高性能的PHP模板引擎 l?? 已开源 6 ?
- 7. Weibo Extension l?? Weibo Ext l?? Weibo_Conf 1.? 在Apache启动的时候Parse 2.? Fork的时候利用COW, 避免共享内存 3.? Lookup只需要一个zval的复制(时间复杂度,空间复杂度 O(1)) l?? Weibo_Util 1.? 运算密集型/PHP脚本无法实现的功能 2.? 业务无关性 3.? ID encode, At, Link, Topic … 7 ?
- 8. PHP Templates l?? 模板的优化 l?? Smarty太过庞大 l?? 不兼容的自动加载规则 l?? 编译后的模板代码臃肿,低效 l?? PHP本身就是一个很好的模板语言 l?? 模板自动转换工具 8 ?
- 9. Apache Optimize l?? Apache配置调优 l?? 避免多余的配置 l?? 目录结构优化 l?? 梳理Rewrite规则, 去除无用分支 l?? 统一的国际化 l?? gettext全面应用 9 ?
- 10. 性能优化 10 ? l?? 响应时间下降 44% l?? 吞吐提升 78% l?? CPU利用率下降 l?? 内存占用率下降
- 11. 业务解耦 l?? 代码过于繁多, 只做加法不做减法 l?? 主干开发, 团队配合风险大, 开发周期长 l?? 大包上线, 上线周期长, 风险大 l?? 新业务, 新需求不断增加, 恶化趋势明显 l?? 怎么办? 11 ?
- 12. 业务解耦 l?? 我们已经有了解耦的基础 l?? Pagelet l?? Bigpipe l?? Pagelet服务化 l?? SOA(Service-Oriented Architecture)的实践 12 ?
- 13. Pagelet服务化 l?? Pagelet独立开发/上线/运维 l?? Pagelet通过接口对外提供数据 l?? Pagelet之间通过L0 Cache来共享数据 13 ?
- 14. Yar – Yet Another RPC Framework l?? Yar l?? 开源社区第一个PHP并行RPC框架 l?? 高效, 轻量级, 易用的RPC框架 l?? Curl + PHP Stream l?? PHP, Json, Messagepack l?? 已开源 14 ?
- 15. 性能优化 - CBigpipe l?? Yar - 并行化的RPC l?? Curl Multi + Select(epoll) l?? Bigpipe + Yar = Concurrent Bigpipe l?? Pagelets并发渲染 l?? Fastest Pagelet Renderred ?rst 15 ?
- 16. CBigpipe – Concurrent Bigpipe l?? CBigpipe l?? Pagelets并行生成, 谁快谁先到客户端渲染 l?? 各自独立容灾, 前面的PL失败不会影响后面的PL l?? 生成时间缩短为”最耗时的PL”生成时间 l?? 但是, 吞吐下降 l?? 1 变 M (M << N) 16 ?
- 17. Yar Plus l?? 前端PHP后端C的服务架构 l?? Yar + C = Yar C framework l?? Master/Slaver l?? 异步模型 l?? Msgpack l?? 运维友好 17 ?
- 18. Yar C Framework l?? 业务面向统一的Yar Client l?? PHP Service和C Service无缝切换 l?? 前端PHP后端C的服务架构成型 l?? 关键词检测服务 l?? 白名单服务 l?? 策略服务 l?? 策略服务为例 l?? 单机每秒处理请求20K+ 18 ? 0 5000 10000 15000 20000 25000 Yar C Nginx Lua
- 19. Nginx and PHP 5.4 l?? Nginx l?? 异步 – 单机承载更多连接, 弥补并行化的吞吐下降, 有利于长连接 l?? 配置编程 – 更高的配置灵活性 l?? 二次开发 – 唯一请求ID,替代部分7层功能 l?? PHP5.4 + Zend Opcache l?? 迁移代价小, 和5.2的兼容性好 l?? 大量Bug修复, 大量新特性(Closure, Slow log etc) l?? 性能提升 (30%) 19 ?
- 20. Zend Opcache l?? 不仅仅是Opcode Cache l?? 常量表达式预先计算 l?? 常数散播 l?? Numeric offset转换 l?? Nop移除 l?? CFG dead block移除 l?? Literals合并 l?? 7 ~ 10% 快于APC 20 ?
- 21. Nginx and PHP 5.4(with O +) l?? 替换的过程很漫长 l?? 小坑踩了不少 l?? Libmemcached l?? Bigpipe和gzip l?? Rewrite规则改写 l?? Request_time和lingering_close 21 ? 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 25并发 ? 50并发 ? Apache Nginx 响应时间对比 ?
- 22. 首屏时间 l?? 数据填满用户浏览器的时间(800 * 600) l?? 建立连接时间 + 第一个包处理时间 + 接收时间 + 渲染时间 l?? 数据来自第三方统计机构 22 ? 3.82 3.17 2.57 2.37 2.24 2.11 1.772 0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 2011Q4 2012Q1 2012Q2 2012Q3 2012Q4 2013Q1 201306
- 23. 唯一请求ID l?? 服务间调用关系复杂 l?? 模块依赖繁多 l?? 出现问题定位耗时, 困难 l?? 到底是哪个环节出错了? 23 ?
- 24. Yac – Yet Another Cache l?? Zend Opcache没有User Data Cache l?? L0 Memcached的代价和维护成本 l?? 我们User Data Cache的特点 l?? 内容Cache和用户ID相关 l?? 内容Cache一般大小固定 l?? 内容Cache出错的代价 24 ?
- 25. Yac – Lockless cache l?? Yac l?? 无锁的共享内存Cache l?? Last win l?? 随机LRU l?? 冲突的解决 l?? 已开源 25 ?
- 26. 灰度发布系统 l?? 快速的产物功能验证 l?? 快速的AB测试 l?? 快速的新功能迭代 26 ? 分流系统 ? 灰度1 ? 实时日志反馈/分析系统 ? 灰度2 ? 灰度3 ? …… ? 分量上线系统 ? 策 略 投 放 管 理 系 统 ? 基于流量 ? 基于用户特征 ?基于地域 ?
- 27. 灰度发布系统 27 ?
- 28. 代码规范 l?? 微博应用代码规范.txt, 微博模板开发规范.txt l?? 代码规范检测平台, 代码提交的时刻实时检查. l?? 微博应用代码规范.exe, 微博模板开发规范.exe l??技术保障规范的规范, 才是真的规范 28 ?
- 29. 未来? 29 ? l?? Nginx l?? PHP5.4 l?? Yar and Persistent link l?? Yaf and Security l?? 核心包和包管理/发布Cycle (40%) l?? 灰度发布系统 and 分级上线系统 l?? 基本服务 and Yar C l?? …
- 30. 以微博之?力, 让世界更美 ! weibo.com 加入我们: http://hr.weibo.com/jobs/