06 十二 11 velocity china 2011第一日见闻

今天去参加了velocity china 2011会议，收获颇多。该会议和前不久的hadoop china 2011相比干货还是多不少。其中收获最多的有几个：1、Facebook的David Wei的当面交流。2、淘叔度的Nginx分享。

Facebook的David Wei主题演讲非常给力，技术也相当的强悍，从前端的JS/CSS到后端的Linux内核都有深入的了解，和他的沟通学习到不少，也了解到更多关于Facebook的技术细节，具体有：

1、静态文件管理系统。基于内容的md5做唯一签名，采用独立的系统解决静态文件版本更新的问题。细粒度，唯一性都满足。

2、hihop。hihop在facebook中完全使用了，所有的PHP代码采用分布式编译系统编译成一个大的可执行文件（基于分布式编译系统也要便宜20分钟，囧）。hihop不会带来明显的性能提升，正如我在《大话PHP之性能》中描述的一样，PHP语言本身不是性能瓶颈。但hihop会节省大量的CPU计算，这个我会《深入探讨PHP性能问题》中深入研究，看看具体提升的比例。

3、灰度发布。目前这个概念非常火。facebook默认是周二进行一次大规模的灰度发布，日常也会进行小BUG修复性质的上线。在国内关于“灰度发布”上线的讨论中，很多都会把它和小流量A/B测试结合在一起，但和David的沟通中了解到，在facebook中两者是分离的，事实上facebook的灰度上线只会持续半天完成。所以大多数情况下，线上的环境是一致的。其实这样挺好，把灰度上线和A/B测试分成两个问题来解决，会轻松容易很多。

4、hihop后，facebook是否前面还有web server。。这个问题貌似David不是特别清楚。还有一些其他的关于负载均衡，memcache雪崩等问题没有很深入的问了。应该都差不多。

接下来比较给力的就是淘叔度的nginx相关分享，记录我一些比较感兴趣的说：

1、源码级别的修改。这个问题我比较纠结，呵呵，修改源码后就相当于淘宝独立分支了，如何merge其实成本挺大的。公司内关于这些开源的起分支基本上都非常悲催。不过淘叔度说他们有一组人在维护这个，那看起来应该问题不大。

2、强制gzip压缩。不是完全的强制，有一定的check。据说目前有15%左右浏览器是因为代理而不能使用gzip，所以才产生的。如果是这样，这个模块还是相当给力。

3、防攻击功能的增强，limit_conn和limit_req的增强。实话说，nginx这两个模块的确太弱了。呵呵，不过可以做的更加强大点，比如说黑白名单、组合条件、规则链等等。

4、系统过载保护。恩，不错。不到一定的压力，一般铁定没有人搞这个。

5、问题追查协助的东西。类似yahoo在页面的HTML中添加注释标明对应的web server，目前基本上和yahoo做法一致，只在HTML最后添加了。和我们在做的问题追查比较类似，但应该可以做的更加强大并且平台化。有机会也可以一起探讨。

6、分布式实时防攻击系统（TMD系统）。呵呵，其实我比较纠结是否应该叫做分布式。从淘叔度的描述来看，更加类似于分组防攻击管理。并且功能应该也不会太强（实时的）。我比较期待真正完全的分布式，并且是实时+准实时结合。这样当然也需要结合数据挖掘来做。

7、灰度发布和监控等等。这些方面做得工作都非常赞。

8、淘宝量子统计的架构变迁中，去掉了php，而是在nignx中引入lua来写逻辑。其实这个不是很赞同。有几点理由：系统大了，分层才是王道。每层专注每层应该解决的问题。web server和业务逻辑层不应该放到一起。一方面有资源竞争，另外一方面不好扩展。当然量子统计可能是因为业务逻辑太简单的缘故。第二、如果是简单逻辑，PHP不可能会成为性能瓶颈（参见《大话PHP之性能》）。第三、lua和nginx中一系列关联导致的问题，还有lua调试等等。这些量子统计也在想办法解决。呵呵，整体上我比较倾向的还是webserver->php(业务逻辑)->存储的三层架构。如果说有一些非常简单的数据接口，的确可以跳过PHP，但整体架构不应该跳过（纯属个人意见）。

另外，大会上还有一些关于redis/mysql相关的分享，也都是实践中的干货。但相对谈的比较多了，就不写了。

最后，关于nodejs，很赞一句话“nodejs没性能优势，还引入了异步编程这种悲剧的东西”，其实挺难的。

本文首发xlq的博客（转载请保留）http://blog.xiuwz.com/2011/12/06/velocity-china-2011-1/

Tags: hihop, lua, nginx, nodejs, php, redis, 防攻击
Filed in Nginx原理, PHP开发使用, Web服务器, WEB架构, 技术大会 with 10 Comments

Reader's Comments

laruence # 06 十二 2011 9:58 下午
nodejs怎么又没性能优势了? 不是说性能很强劲么? 呵呵.
anyway, 我没去成..可惜了.
登录以回复
- 管理员 # 07 十二 2011 7:49 下午
  nodejs的性能相对nginx+lua的性能。呵呵，所以会比较尴尬。
  登录以回复
何戬 # 06 十二 2011 10:25 下午
“php不会成为性能瓶颈”，我一直不赞同强哥你的这个说法。这个议题的关键是把php用在什么地方？把php用在前端开发有瓶颈和把php用在后端服务上的瓶颈，其意义是不一样的，瓶颈这个词面对不同的时间量级时，其意义和影响也不一样。假设一个请求用c写的服务里可以在<0.05ms的时间内完成，而用php确用了1ms左右的时间完成，里面涉及各类复杂的数据结构（不光是你说的科学计算），那此时性能的差距立马就出来了。另一个假设，用C处理的时间在100ms，用php处理的时间在102ms时，此时php的性能确实可忽略不计。所所以php应该用在合适的地方，而不是说能用php做的东西就都用php做。毕竟术业有专攻，各有所长。
登录以回复
- 管理员 # 07 十二 2011 7:51 下午
  对，“PHP不会成为性能瓶颈”这个是有前提的，就是写应用逻辑。并不赞成所有的模式下采用PHP。在合适的地方采用合适的解决方案。
  登录以回复
lipingtababa # 08 十二 2011 11:35 上午
Steve Sounders说有15%的浏览器请求没有带accept-encoding头部,但是他没有给出数据来源.

我做过测试,实际数字少很多,不足1%.
登录以回复
- 管理员 # 08 十二 2011 2:35 下午
  这个应该他们做了数据调研的，具体需要结合自己产品调研数据来看。但如果有15%，还是很值得做的。
  登录以回复
agentzh # 09 十二 2011 6:40 下午
当年我把量子统计的 php-fpm 实现的数据接口用 ngx_lua + 标准 Lua 改写之后，真实的直通车报表的业务接口，在 mysql 自身的查询缓存命中时平均响应时间的变化：http://agentzh.org/misc/nginx/perf_with_mysqlcache.html 后来从标准 Lua 切换到 LuaJIT 2.0 后真实业务接口的延时变化：http://agentzh.org/misc/nginx/2011-03-10-core_lua51_vs_luajit20.html 当然，前端的并发能力更有极大提升，毕竟 php-fpm 是不能处理 C10K 问题的替换为 ngx_lua 之后，再没有因为后端大集群中的某一台机器超时而导致前端请求积压到雪崩而影响到所有的用户。
登录以回复
- 管理员 # 10 十二 2011 7:01 下午
  增加fpm一层的确会导致响应时间的下降，但也正如你的图所描述的那样，不会存在量的差异。增加fpm一层，需要进行更加精细化的控制，比如说超时、负载均衡等等。对于fpm不能处理C10问题，这里面主要说还是PHP代码中本身不支持异步IO吧？呵呵，但其实这也是一种权衡，在编程复杂性和性能之前的一种折中吧。如果说PHP代码本身非常简单（没有其他的IO等待），其实fpm也是可以处理C10K的，呵呵。PS：随着量子统计业务逻辑复杂度的增加，lua的维护和开发有可能会成为新的瓶颈的。所以，总体上来说，我倾向于整体架构有PHP层，简单的数据接口可以绕过php，直接nginx到后端数据层，比如说mysql、memcache或者其它的server。
  登录以回复
Simon Lee # 20 三 2012 9:42 上午
nginx + lua 解决的不是php语言本身的性能问题，而是后端数据库查询导致的php阻塞问题。这个问题囿于php自身的限制，是无法解决的。
登录以回复
- 管理员 # 21 三 2012 9:41 下午
  是异步和并行化吧？其实PHP扩展来搞不是不可以。:)，主要是需求。而且引入异步后，PHP开发的难度就大大提高了。
  登录以回复

06 十二 11 velocity china 2011第一日见闻

Reader's Comments

Leave a Comment 取消回复

分类目录

我的微博

近期评论

标签

Blogroll

功能