July 2008 Archives

在上周六的 QClub 上,BASE 成为了一个热点话题,其实除了这个 BASE 之外,还有个 CAP 理论也是值得关注一下的。这个概念也来自 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer ,应该说他 10 年前的那篇 Lessons from Internet Services: ACID vs. BASE 是互联网技术最为重要的一篇文章了。

C: Consistency 一致性 
A: Availability 可用性
P: Tolerance of network Partition 分区容忍性(有翻译为耐受性的,个人觉得不妥)

CAP.png

熊掌与鱼不可兼得,三个目标不能同时满足。如果对"一致性"要求高,且必需要做到"分区",那么就要牺牲可用性;而对大型网站,可用性与分区容忍性优先级要高于数据一致性,一般会尽量朝着 A、P 的方向设计,然后通过其它手段保证对于一致性的商务需求。

CAP 不是什么高深的东西,应该说 CAP 只是一个经验理论,切不可钻牛角尖,号称自己做的东西能打破 CAP 理论,那只是无意义的事情罢了。

如果知道 ACID(酸) 、BASE(碱) 在词典中的含义,那么这个 CAP 的辞典含义也很有趣。

--EOF--

最后推荐阅读一下这篇:可伸缩性原则

我开始还有点担心到底多少人会来参加这次 QClub,毕竟这几天杭州太热了,不过大家的热情比天气还热 :) 甚至还有从上海、宁波等地赶来的朋友,如果今天的技术活动能让各位感到不虚此行则是我们莫大的荣幸,非常感谢各位朋友的光临!

组织这样的会议,我也不是很有经验,希望没有怠慢了大家。有点小纰漏:最后要不是同事提醒,为大家准备的 T 恤居然差点忘了发送,有几位朋友走的快,可能没有拿到 T 恤,希望下次活动的时候给大家补上。

会议内容,回头 InfoQ 泰稳那边会有视频和文字的技术内容,我这里先发点会议的照片(拍的好的可能是同事拍的,拍的手法很差的基本是我按的快门,如有不合适的地方请通知我,完整的照片集等下周整理一下放上来)。

QClub合影大图

上图:会议结束时合影

程立的无奈一笑

上图:泰稳拿了一只录音笔,让程立别在身上;同事拿来一只录音笔,程立也别在衣服上;接着又要拿无线麦克风,发现身上挂的东西太多了 :)

分享进行中

演讲内容很精彩

上图:聚精会神。可见程立的技术分享之精彩。

支付宝胡喜 vs. 淘宝毕玄(林昊)

上图:左边:支付宝架构师胡喜,右:淘宝架构师林昊(BlueDavy),有点遗憾的是没让他给大家分享点东西:)

QClub 花絮

上图:谈到妙处,开怀一笑。

InfoQ宣传画

支付宝的学习发展规划

上图:这两个朋友对支付宝的学习发展计划居然很感兴趣 :) 今天活动的会议室平时支付宝用来做新员工培训的,所以墙壁上有很多招贴画、手写的海报什么的。

更多照片看我的 Flickr 或者 Yupoo 相册

--EOF--

Alipay + QClub , 期待杭州侠客光临

本月 26 日,也就是明天,QClub:当SOA遭遇现实 将如期在支付宝举行。

除了报名参加的杭州本地的众多技术精英,阿里集团各家子公司也都有人参加,淘宝、阿里软件、阿里妈妈都会有资深架构师到现场来。相信这回是一场精彩的思维碰撞,期待。

特邀嘉宾:支付宝首席架构师 程立(花名:鲁肃)

程立,支付宝(中国)网络技术有限公司。2004年开始参与淘宝网与支付宝系统的建设,2005年起进入支付宝,一直从事于互联网电子支付系统的研发工作。现任支付宝首席架构师,专注于电子支付系统的分布式服务架构与开放架构。

一说起 SOA 可能很多人会觉得比较"空",这也是我们举办会议的目的之一,"来点实在的技术信息" 是这次活动的一个宗旨。

会议地点

文三路、万塘路交汇处,华星时代广场 5 楼。大厅届时会有人指路

友情提示

为便于交流,请尽量携带名片 :) 

--EOF--

广而告之: 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

今天看到 Brad Fitzpatrick (就是大名鼎鼎的 Memcached 的作者,现在效力 Google) 在网志中说道,正在利用 Google 著名的 20% 的业余时间为 Google App Engine 增加对 Perl 的支持。

GAE_arch.png[来源]

还记得时不时的会从中文 Perl 邮件列表里看到有人散布 Perl 过时的言论,其实一个语言过时与否都不重要,关键的是是否有人依赖该语言打造出比较激动人心的应用。如果 GAE 能够支持 Perl ,或许就是 Perl 焕发第二春的时候。从这个角度来说, Erlang 不也是如此么?

提个意见,Google App Engine 啥时候能支持给中国移动发短信? 现在支持 China Unicom,周围没有朋友用联不通的,大家都用移不动的。

--EOF--

广而告之: 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

再说存储引擎

继续上一篇的讨论,记录针对 MySQL 在大企业级商用上我的一些零星想法。网络上到处都有关于各个引擎之间的对比。这里要提醒一点是,注意各个引擎的锁的粒度。InnoDB 是行锁,锁的实现是依赖于索引的,MyISAM 只是表锁。锁粒度是衡量存储引擎的一个重要指标,其能力很大程度上决定并发能力。

至于 TRANSACTION ISOLATION LEVEL,则是另外一个需要衡量的指标。

老生常谈的,某某引擎适合什么类型的应用,归根结底还是由于其实现的机制决定了引擎的特性。

存储层的解决方案

相信没有人愿意在 MySQL 上用 RAW 设备,很多人几乎就是直接把数据文件放在文件系统上(个人认为,对于数据库这样的应用来说,文件系统可靠性还有所欠缺)。我还没发现 MySQL 上类似 Oracle ASM 的解决方案。如果用文件系统,单节点的数据存储能力肯定要受到制约--没有人喜欢把几个 T 的数据扔到一个 MySQL DB 上吧? 一旦某个文件系统故障,麻烦就来了。从这个角度考虑,或许 LVM2 是一个可选的方式。

当然,如果把数据文件扔到 SAN 上也还不错。一方面问题是,现在存储厂商对于 MySQL 的重视长度还远不如 Oracle、DB2 等老牌商业数据库。另一方面,很多 MySQL 用户没有 SAN 环境的,数据都是在本地磁盘上。

固态硬盘与 MySQL

前两天有朋友在上一篇分析留言,提及应注重闪存的应用。其实还不如布署固态硬盘 (SSD) 对 MySQL 可能的影响问题。 相信现在有很多企业需要在 DB 的 IOPS 上寻求突破,SSD 是个可能的突破口,但从目前我收集到的数据来看,还没有足够的数据说明启用了 SSD 的 MySQL 能有预期的数量级上的 IOPS 提升。

商业支持

现在 MySQL 的背后有 Sun ,但是,如果不购买服务的话,到哪里去找比较正规的商业支持(我是说软件集成商)? 即使购买了服务,如果问题出在存储引擎上,MySQL 能给即时、有效的技术响应么? 这也是 MySQL 没有自有存储引擎的一个弱点,因为衔接的环节多,一旦有商务上的问题,很容易陷入扯皮阶段。

--思路中断,这是这个系列不成熟的第二篇。如果有第三篇,我倒是想写几点关于 MySQL 的设想。

--EOF--

连续看到几个和 Oracle 优化器隐含参数 _sort_elimination_cost_ratio 相关的优化案例(Refer Refer )。

如果用 _SORT_ELIMINATION_COST_RATIO 作为关键字在 Metalink 上查询,会发现很多和该参数有关的 Bug ,执行计划的出错特征是也走了索引,但是走了索引全扫描(INDEX FULL SCAN),如果做 10053 Trace ,会发现有个烦人的 Recost for ORDER BY 步骤,然后就会引到错误的执行计划上。

在 9i 升级到 10g 最容易遇到这个问题(原来好好的,到了 10g 发现执行计划有问题了). 出问题的 SQL 一般是走 INDEX RANGE SCAN 然后有个 ORDER BY 会触发,更多的时候优化器模式是 FIRST ROWS -- 这样 Oracle 会尽量消除排序,默认认为排序是开销昂贵的操作。通过控制 _SORT_ELIMINATION_COST_RATIO 隐含参数的值 (默认是0) 能够解决这个问题:

ALTER SESSION SET "_SORT_ELIMINATION_COST_RATIO"=5 

其它可能的解决办法:对索引里面的排序保持和 SQL 里的 ORDER by 一致。

其实说白了,很多 Oracle 隐含参数就是为了解决 Oracle 特定情况下的 Bug 的,因为不具备普遍性,所以在某些版本中作为隐含参数出现。在生产数据库上,个别的时候启用隐含参数倒也不是不行的,只要明白了相应的隐含参数到底是干啥的就成了。

题外话:_SORT_ELIMINATION_COST_RATIO 相关的 Bug 频繁出现,倒是感觉和 Oracle 内部代码管理有关,本来应该消除掉的,怎么后面的版本又跑了出来?

目前关于 CBO 最好的书籍应该是Jonathan Lewis 的 Cost-Based Oracle Fundamentals ,有中文译本:《基于成本的Oracle优化法则》。是 DBA 不可错过的一本书。

--EOF--

广而告之: 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

上周五去了一趟淘宝,在淘宝二楼实时展示交易信息的大屏幕前看了一会儿。发现关于商品显示的排序列表是两排,左右排列的。

1 商品名一 2 商品名二
3 商品名三 4 商品名四
5 商品名五 6 商品名六
......
N-1 商品名N-1  N 商品名 N
......

尽管符合从左到右的阅读习惯,看起来感觉怪怪的。前一段时间有不少关于电梯楼层按钮排列问题的帖子(),针对电梯的按钮应该说已经讨论的很好了,但我感觉如果针对 Web 页面上大量列表项的排列显示来说,很有值得商榷的地方。

我再抛一个另外的反面例子,关于百度 Mp3 歌曲 Top 500 的列表展示:

baidu_mp3_top500.png(点击图片看大图或者到 Baidu 站点上体验)

假设 M 行 x N 列的展示,如果 M 很大,而 N 很小,在前面几行过去之后(一般是 N行*N列后),会发现非常难以定位你要找的歌曲。尤其是越到后面效果越差。如果 M 和 N 都很小,那么相差是不大的(不知道这是什么心智模型? 尤其是对该项的描述也符合 M:N 值很小,比如 Flickr 的图片展示)。

这个其实和电梯楼层按钮排列的问题不太一样:电梯上面只有一个按钮(楼层号),而 MP3 列表排列项后面还有该项的名字或描述(MP3 名字, 艺术家名字)。需要展示的内容性质和信息量已经变化了。

Flickr_items_arrange.png

这只是 UE 门外汉的个人看法。供参考。

--EOF--

BTW, 注意到火车站和机场的公示牌显示倒是挺符合阅读习惯的。

关于 Nginx 的几个误解

| 7 Comments

在 IBM developerworks 网站看到一篇不错的介绍 Nginx 的文档:使用 Nginx 提升网站访问速度。针对其中的几个描述,我个人感觉不是很清晰:

# 目前官方 Nginx 并不支持 Windows,您只能在包括 Linux、UNIX、BSD 系统下安装和使用;

虽然 Nginx 官方并不提供 Windows 平台的下载,但还是有热心的开发者维护 Windows 平台上编译好的版本,而且,从邮件列表中观察了一段时间,和官方发布的版本基本上是同步的。

当然,我相信不太会有人在 Windows 上跑 Nginx 吧?

还有一句话我觉得也不太妥当:

# Nginx 本身只是一个 HTTP 和反向代理服务器,它无法像 Apache 一样通过安装各种模块来支持不同的页面脚本,例如 PHP、CGI 等;

其实针对 Nginx 的内建的 Perl 模块现在就是支持的(当然,更准确的说是在实验阶段)。

--EOF--

一直以来,支付宝的技术人员都比较低调,这次总算利用网络侠客行大会的机会,促成了对支付宝首席架构师程立的采访。如果你对支付宝的架构和开发实践感兴趣,请不要错过 InfoQ 中文站 的这次专访:《程立谈架构、敏捷和SOA实践》

InfoQ 编辑在 介绍页面中引用程立的这段话我很欣赏:

老子说"道生一、一生二、二生三、三生万物"。在业务愿景的技术实现过程中,
假设"道"为愿景、一为方向、二为战略的话,三就应该是架构了,架构既出,万物化生可矣。

因为支付宝一直以为用户提供良好支付体验为目标,以致于有技术人员误认为简单的支付环节背后的支付宝后台技术也是非常简单的。其实想想看为将近 1 亿用户提供服务,每日交易额几个亿人民币,技术上没有独到之处怎么能做到?

和程立一起共事也有三年多了。我工作这么多年,很少遇到这么功力深厚、勤奋、敬业的技术人,感觉他就像一台自我修正的计算机,能一直朝着既定的目标前进,这一点值得很多技术人员学习。

如果觉得这次采访不过瘾,请关注接下来的 7月26日QClub杭州站-- 支付宝首席架构师程立与您分享"当SOA遭遇现实"的心得

--EOF--

前两天在上海参加技术研讨,讨论了关于 MySQL 的一些面向企业级应用的思路,今天和几位同事开会,也谈及了能否用 MySQL 替代当前 Oracle 的问题。干脆整理一下思路,算是做个备忘。

首先说明一点的是,我不是说 MySQL 没有大企业级的应用,事实上,可以看到越来越多的成功布署 MySQL 的应用,但是,还不够多,还有许多大企业的关键应用还不敢用 MySQL。或许这篇小文能和大家一起探讨一些比较"虚"的东西。

存储引擎

由于 MySQL 自己一直没有一个成熟可靠的存储引擎,估计这让他们深感痛处(尤其是目前最成熟的事务型引擎 InnoDB 又在 Oracle 手里)。MySQL 寄予厚望的 Falcon 在开发了两年多之后,建树不大,而该项目带头人 Jim Starkey 前不久又离开了 MySQL,陋屋偏逢连夜雨。

Sun 会给 MySQL 一个稳健的引擎么? 我看短时间内未必能达到。除非,Sun 从 Oracle 手里把 InnoDB 买回来。

如果进行大企业级应用,考虑到引擎本身的稳定性,似乎可选的也只有 InnoDB 了,但 InnoDB 的备份工具又是收费的。至于 MyISAM ,尽管有人的确喜欢用,但对于并发能力要求稍微严格一点,MyISAM 根本不行。

在线 DDL 锁表问题

MySQL 中,在线对表对象做 DDL 操作是要锁表的,对于可用性要求比较高,而应用变化又比较频繁的环境,这是个非常很糟糕瓶颈。没想到有什么好的办法,除非,像大家开玩笑说的,把所有的表都预留出足够的空闲列,减少类似增加列的变更麻烦。

这个 MySQL 天生的缺陷在 PostgreSQL 中是不存在的,比如创建索引,可以用CREATE INDEX CONCURRENTLY 的方式来减小影响。(MySQL 后续的版本中在逐渐改善这个问题:添加了 ONLINE 关键字)

这个看似是个小问题,但实际上却是对很多人最为困扰的。

在线备份问题

谢天谢地,MySQL 6.0 后终于具备在线备份的能力了。但现在,恐怕比较激进的用户也只能用版本 5 而已。

很多 MySQL 资深用户能够根据自己应用的特点布署适合自己的备份方式(尽管可能也会有缺陷,比如基于时间点的恢复)。

至于另一个常用来衡量 DB 可扩展性的特性:分区,现在 MySQL 已经能够支持了,尽管实现的的确有点晚。而使用 MySQL 的用户,一般都采取 Sharding 的策略对数据进行切分,所以,分区的问题倒似乎并不是最为关键的。

因为是整理思路,这算是这个系列的第一篇。

Discuz! 优化的误区

| 13 Comments

很多 Discuz! 的用户在论坛规模达到一定程度上,就要经常性的考虑优化的问题。现在网络上的很多热心的技术人都分享了 Discuz! 的优化经验,应该说,很多经验还是不错的,但也有的帖子可能会让用户走入误区。

误区一:SQL 慢,加索引

多数情况下,数据库可能是瓶颈。通过 Slow Query Log 发现执行时间比较长的 SQL 并不难,于是有的人一看 SQL 走了全表扫描,干脆添加个索引好了。

其实这个地方值得商榷的。第一,必须确定一下该 SQL 执行次数到底是怎样的? 执行真的很频繁? 那么对应的页面是否通过 Cache 可以减少对 DB 的冲击? 如果可以,尽量不要添加索引,索引本身对表的负面影响也是很大的,比如降低更新速度,影响并发能力等。

误区二:瓶颈一定在数据库上

前面说,数据库"可能"是瓶颈,但不总是瓶颈,优化的第一步,必需要有针对瓶颈优化。很多时候,图片访问带来的压力甚至比数据库压力还大 --- 有的用户数据库、用户上传的图片文件、Web 服务器都扔到一台服务器上,这时候,第一手去调整 MySQL 或许会有作用,但价值不大。

应该说,瓶颈的有效定位的确是个技术活儿,对于一个新的论坛环境,也有人用逐一尝试法来做,这倒也没什么。

误区四:盲目的静态编译 MySQL

静态编译 MySQL 有好处,但如果系统已经在线上运行了,在原有环境中进行静态编译未必能带来多大好处。我问过一些朋友,静态编译到底带来多大好处? 没有几个人能说清楚。

对于 PHP 也是这样,如果一次优化从其它方式上能带来更清晰、直接的开销,就不要重新编译

误区五:反复尝试,但不建立基准数据

这其实是第四点的延伸。而建立基准数据,实在应该是优化的最基本的步骤。这样才能有效的评估优化的效果。否则的话,象误区一描述的,添加了一个索引,短期内可能感觉快了,长期看,性能可能又会慢下来。

误区六:一次进行多个优化步骤

这可能是比较普遍的"习惯"了,有的朋友喜欢一次调整多个参数或是多个环境的设置,然后观察效果。如果每个步骤都是"对"的话,那么效果看起来是好的。如果有的步骤调节"错"的话,可能会抵消那些有效果的优化步骤。

优化策略是个见仁见智的问题。以上只是个人浅见,欢迎留言探讨。

--EOF--

谨慎对待自我生成内容(egc)

| 7 Comments

标题里的 egc 代表:ego-Generated Content,是我模仿 UGC(User-generated content)造出来的一个词。用以表示个人生成内容,尤其是在一些 UGC 网站产生的内容。

记得 CSDN 的曾登高问过我:

如果 CSDN 开发一个 Google Group的功能,你会创建自己的小组,建立一个兴趣小圈子吗? 

我的直接回答是"不用",尤其是国内的很多明显是克隆国外服务的站点,比如饭否这样的。最近一段时间里,一觉醒来,似乎遍地都是 SNS ,对于一些明显是浑水摸鱼的服务,我一般会敬而远之,即使注册了,也基本不会真的花费心思去参与。原因只有一个:自己生成的内容是有价值的,有价值的东西不要随便扔到不靠谱的地方,当然,这么说肯定会引起一部分人的误解(我现在也在用个别的 SNS 服务,主要的目的还是为了研究用户体验和产品设计。作为一个技术人员,至少到到现在为止,还没从 SNS 服务里面发现比较有价值的技术内容)。

自我生成内容成本其实很高。考虑到每个人的一生也就那么长的时间,如果你的时间有价值,那么产生的哪怕每个字符都有必要保存,一旦内容丢失,对个人来说,就是最大的浪费。我个人不认为 SNS 之类的服务能产生更有价值的信息,倒是有可能产生更有价值的"关系",而且,SNS 的服务很少让人静下新来作一些"沉淀",每天被新信息充斥着。

至于 LifeSteam:之所以会产生 Lifestream 功能的服务,其终极目的还是要把一个人产生的内容融合起来,但这里面最大的一个问题是,不能做信息的归档保存(类似数据库-> 数据仓库的机制),只是即时更新的信息流而已。从这一上来说,也不利于 egc 的整理。

所以,有必要谨慎对待自我产生的内容,尽管你还没发现这些内容的价值。也不要趋之若鹜的去到处尝试一些新服务,做小白鼠其实没什么大价值。

个人建议:

  • 同类服务只用一个,最多用两个,如果用了三个,那么你是一个义务测试员。

--EOF--

周日上午在上海,宾馆里的电视放着在成都举办的电影《赤壁》首映礼,听着到场明星如潮的谄评,我开玩笑说,"没准是个大烂片",没错,说中了。

有《三国志》也没用

和《三国演义》不相符的地方,吴宇森可以说是研究《三国志》得来的,和《三国志》不一样的,可以说是遵循《三国演义》。可几个人面对着一匹难产的马折腾了半天,这是跟什么地方学来的? 《英雄本色》么? 这样多余的段落实在太多了,听牧童吹笛、孙权射老虎(这段是给外国人看的,建议海外版把这一段加进去,很弗洛伊德)、古代足球--蹴鞠等完全是可有可无的桥段,没有这些,冲着当年吴宇森拍过的片子,大部分观众可能也愿意掏钱的。

人物形象

冷兵器变成了现代武打,下次让关羽骑马吧,每次跑着出来(当然是穿着刘备给打的草鞋),拖着大片刀也的确不太好;张飞也最好带着兵器,别总赤手空拳,好像把丈八蛇矛弄丢了似的,这样不好! 至于小乔,那双手也太大了些,特写太多了些;周瑜的头盔实在有些不好看,建议和《投名状》学一下嘛,反正都是古装,穿越一下就成了。至于瑜亮的大段飈琴,简直是现代摇滚青年的翻版嘛。

吹毛求疵

刘备自称的"豫州"也实在让人倒胃口,哪有这么说的? 而八卦阵那一段,估计连外国人也糊弄不了吧? 孙子兵法都说了,"十则围之",对付区区两千敌军还折腾半天。

那些笑声

搞笑的亮点有很多:刘备要诸葛亮多吃米饭,刘备重拾本行打草鞋,诸葛亮在孙权殿前走起的模特步,关羽给孩子们上课居然说出"现在读书,以后就会有饭吃",而张飞聚精会神练习书法(尽管张飞历史上的确是书法家,可剧中人物那握笔的姿势实在有些问题嘛),听着一次又一次的笑声,完全有理由相信这是吴导演的转型喜剧之作。

估计很多人会疑问,这就是那个拍出《英雄本色》的吴宇森么? 现在开始怀念那"一亿颗子弹"吧,然后,面对着下集可能出现更多的恶评,吴导演最需要的是"冷静"。

--EOF--

比较出彩的地方,应该算曹操的 "架六龙,乘风而行;九合诸侯,一匡天下" 那个镜头。这句话是从曹操的两首诗里面拼出来的。

上周六去了上海,参加 博客大巴 CTO 车东 组织的 Startup 技术沙龙。

杭州这几天很热,我的 ForecastFox 插件上显示的是根小火柴温度计(?):Hangzhou_hot.png。下午 4 点多的时候和同事 Ningoo 一起出发,到了杭州火车站发现人真叫一个多啊。让我稍感到安慰的是和谐号车内空气质量似乎比以前好多了。一路顺利到了上海,居然都没晕车。

要出行,找携程

出于节约成本的考虑,星级酒店不能住啦。出发之前,给汉庭打了订房电话,为保险起见,给另外一家快捷酒店的"旗舰店"也打了电话。出火车站后电话询问汉庭的位置,如论如何也听不清楚电话里那个家伙说的话,只好先去另一家"旗舰店",手续敲定,进了房间,一股霉味扑鼻而来,二话不说,下楼退房跑路,再给汉庭打电话,这次终于弄明白具体的位置了,赶过去,前台告诉我,房间取消了。"因为你是散客订的房,所以,时间到了就取消了",接待人员牛气的不得了,爱理不理的样子。

只好重新订房。Ningoo 说自己是携程金卡会员,给携程打了个电话,等,不一会儿电话回来,房间定好了,上航假日酒店,价格也不贵,到了一看,性价比很高。我不由得赞不绝口。这里严重表扬一下携程,想方设法给用户省钱的公司就该赚钱,携程的价值或许低估了许多。

当天晚上,昔日的魔岩三杰也在上海开演唱会。

参会感受

BlogBus 位于 2577 创意大院,很休闲,都有些不太像 IT 公司,还养了一只狗,后来我临走的时候差点咬我 :)

参加讨论的朋友们陆陆续续到场,没有什么偏商务的宣传,话题都是大家平时遇到的一些技术点,现场气氛很好。参会的朋友来自 Blogbus51安居客CDN Union豆瓣虾米5173 等众多网站的朋友,我和另外一位周日上午赶到的同事(搜索引擎专家)代表支付宝,Ningoo 则来自淘宝

信息不对称还是比较严重的,尽管有些技术问题可能是类似,但解决的办法和思路还是能互相带来很好的参考和借鉴。记得马云说过,"技术只有分享才有进步",的确如此。会上主要议题包括:LifeStream 产品设计思路、数据库备份策略、日志处理、防 DDos 攻击等。因为还有些东西也涉及到业务数据,不多说了。

我在会上的一个技术论点:关于 Cache 服务器数量的问题,当时的说法:尽量保持为 2 的 N 次方。回来仔细想了一下,多少有些武断了。这个问题我回头仔细思考一下。这个思路用在 Sharding 上似乎没问题,但是是否能扩展开来? 未必站得住脚。

又看到老朋友,结识了新朋友。这也是大老远跑来才能收获到的吧。

归程

回来的路上挺有意思,三个人一路赶到上海南站才发现车票......居然是上海站的,三个人一口差点一起晕倒。匆忙坐地铁过去,地铁上发现一件有趣的事儿,所有的液晶屏终端都是 Linux 操作系统,而且在不停的重启动...

上海地铁里的 Linux 应用

128M 内存,Linux 2.4 Kernel 的 :)

--EOF--

《Python源码剖析》推荐序

看了博文视点编辑的这篇《让我们做的更好》》,我也把之前给这本《Python源码剖析》写的序翻了出来,贴一下。也希望对关注 Python 的朋友能多多支持支持原创,有的时候多几分欣赏,少一点点苛求,软件书籍的出版环境就会更好一些。



Python.gif

非常高兴看到又一本原创 Python 图书的出版。

说起来,我和 Python 还算有一点缘分。在 2000 年的时候,非常偶然的一次机会接触 到Python,当时网上资料非常之少,不知天高地厚的我竟冒失地接手了国内第一本引进 Python 图书的合作翻译工作,往事不堪回首。记得当时经常有人问我 Python 能用来做什么...而能举出来的例子的确寥寥可数。

历经数年的发展,Python 已今非昔比,各领域都不乏 Python 成功案例。就拿 Web 方面来说,正如 PHP 给 Yahoo! 带来的巨大动力,Python 在新一代互联网霸主 Google 内部早就充当着重要角色,是排名第三的"官方语言"。而就在几天前,Google 革命性的 App Engine 产品一经推出即引起莫大关注,其首选开发语言就是 Python。

纵观国内技术环境,Python 语言仍处于慢热的状态,应用仍然不算广泛。不过我们也已经有称得上比较成功的实现案例,比如著名的 Web 2.0 的代表站点豆瓣网即是用 Python 开发,创始人杨勃对 Python 的效率、优雅赞誉有加。(Refer)

Python 也是权威机构 TIOBE 评出的 2007 年度编程语言,这些"利好"消息也将进而带动新一轮的技术走向,预示着 Python 更大规模流行时代即将到来。

话说回来,"开放平台"在未来几年一定是个不可避免的技术趋势,而跟着大厂商的平台亦步亦趋,照猫画虎,想必也能开发出来繁多的周边应用,但开放未必对所有人都是个好事情,久而久之开发者难免有盲人摸象之感,很难掌握全局、关键架构技术,故深入研究 Python 基础技术仍不可少。这本 《Python源码剖析》的出版恰是好时机,弥补了国内图书在这方面的空白,此外,作者在 Python 领域的精耕细作研究精神亦值得学习。

研读、分析源代码乃是提高编程技能的一条捷径,庖丁解牛方能游刃有余,夯实基础,方可构建坚实大厦。

读这本书《Python源码剖析》就像一次探险之旅,祝愿朋友们能够获得一次愉悦的阅读体验。

--EOF--

跨站脚本攻击(XSS, Cross Site Scripting) 可能是目前所有网站都比较头疼的问题,Google 也不例外。这次 Google 又做了一次雷锋,把内部用来审计 XSS 的工具开源了:ratproxy

Google_ratProxy.png

Ratproxy 工作流程:

  • 1) 运行脚本后,会在本地启动一个代理服务器,默认端口是 8080 ;
  • 2) 浏览器设置这个地址 (http://localhost:8080)为 代理地址 ;
  • 3) 浏览要测试的 Web 页面,进行实际登录,填写表单等操作(这些动作会被代理服务器捕捉并做点"手脚"发给待检测的页面),ratproxy 会在后台记录相关的 Log ;
  • 4) 用 ratproxy 提供的工具解析 Log 并输出 HTML 进行分析;
  • 5) 修正比较严重的问题后,跳回到第一步,直到评估通过为止。

在我的 Ubuntu 下测试了一下,需要说一下的是,本地系统需要安装 libssl-dev 与 openssl 。

$ sudo apt-get install libssl-dev openssl 
$ cd ratproxy ; make

然后就可以提交类似:

$ ./ratproxy -v . -w foo.log -d foo.com -lfscm 

然后,人肉点击相关的页面进行测试了。这个工具的设计思路还是很值得借鉴的,推荐对安全感兴趣的同学读一下源代码。

ratproxy 的作者是 MIchal Zalewski,一个波兰的白帽子黑客。他的个人主页上能找到更多有趣的工具。

--EOF--

另参见另一份试用报告

Updated:Google的另一个工具:Skipfish 尤其值得关注。

前面几天介绍的 Web 前端优化最佳实践 系列离不开一个关键词:YSlow。简单的说,YSlow 是以最佳实践得到的规则为基础,进行 Web 页面的性能评估,并给出指导建议。

Velocity 2008 上发布的 Jiffy ,我断言是一个比 YSlow 更有前途的工具,只是当前还没引起足够的关注度。之所以说 Jiffy 更有前途,是因为 Jiffy 设计初衷是面向端到端的,不只是个工具(Jiffy 有基于 FireBug 的插件 Jiffy Firebug Extension for Firefox ),而变成了框架,对于 Web 上的每个组件,都能进行性能度量。如果说 YSlow 是类似"望闻问切"的诊断方式,那么 Jiffy 就是 CT 检查了。

下图揭示了 Jiffy 的工作机制:

Jiffy.png

通过页面中植入 Jiffy.js ,针对 Apache 做特定的设置,当用户调用页面的时候,拦截并记录 Jiffy 的相关请求,接着把所有的性能信息注入数据库中,然后从数据库中抽取数据进行展现。这正是当前绝大多数 Web 公司都缺少的性能衡量策略(尤其是 JavaScript 的精细度量)。唯一美中不足的是使用 Oracle XE 做性能信息存储的数据库,相信不久就会完美支持 MySQL 。

关心 UE 的朋友可以在自己的环境里面搭一套 Jiffy 啦,有好处没坏处。

--EOF--

更新:有得朋友说,安装了,点击了,没反应。这是因为页面中没有嵌入 jiffy.js 脚本。可以到我的 egosurf 页面测试一下。

在讨论 eBay 的Scalability最佳实践 的时候,结尾提到了 BASE 机制。现在越来越多的架构师更为关注 BASE 策略 (当然,我不是说 ACID 就不重要了)

BASE 策略是 Inktomi 公司(被雅虎收购后已是明日黄花)的 Eric A. Brewer 在 1988 年提出的。这几个缩写词如下定义:

  • Basically Available --基本可用
  • Soft-state --软状态/柔性事务
  • Eventual Consistency --最终一致性

"Soft state" (SS) 是与 "Hard state"(HS) 对应的。我几乎没找到很清晰的定义。不过用 RFC-1633 中的描述, "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的,这样就清晰多了。

最终一致性, 也是是 ACID 的最终目的。对于 eBay 这样的大架构,是通过强大的消息总线能力来保证的。

对于 eBay 这样的大架构,另请参考 eBay 的 Dan Pritchett 在 最近的技术的散文:BASE: An ACID Alternative,注意其中提到的的事件驱动(Event-Driven)的架构的说法。

相信在今后几年,BASE 将成为一个技术热词。ACID 当然没过时,只是各自需要合适的应用场景而已。随着互联网技术的开放性,更多的时候,一个架构师需要反复的衡量合适的应用场景。

BTW: "ACID" 英文里面有"酸"的意思,而 "BASE" 有"碱"的意思. 酸碱在一起才能中和啊,哈

--EOF--

Web 前端优化最佳实践最后一部分是针对移动应用的,其实只是针对 iPhone 的,目前只有两条规则。

1. 单个数据对象小于 25K (Keep Components under 25K)

这个似乎只是针对 iPhone 研究的。建议保持单个 Web 数据对象在 25 K 以下。为什么是 25K? Apple 官方信息指出可缓存到内存中的 Web 对象最大支持到 10M,但经过测试,发现也就是 25K 左右。

iPhone 在市场上的优异表现,让 Web 人员不得不考虑如何针对其进行优化。相信这部分内容也在不断变化中。

2. Pack Components into a Multipart Document

把Web 页面组件打包成一个多部分组成的文档。其目的是减少 HTTP 请求。对这部分语焉不详,等待后续更新吧。

--EOF--

Updated: 根据这篇 iPhone caching 的文章,可供 Cache 的最大单个数据对象是 15K,而不是前面说的 25K。iPhone 总的 Cache Size 为 1.5M。浏览器地址栏的刷新按钮将导致无条件刷新所有组件。这些也是挺有趣的。

Web 前端优化最佳实践第六部分面向 图片(Image),这部分目前有 4 条规则。在最近的 Velocity 2008 技术大会上,Yahoo! 的 Stoyan Stefanov 做的 Image Optimization: How Many of These 7 Mistakes Are You Making 也非常有参考价值。结合一起说一下。

1. 优化图片 (Optimize Images)

使用 GIF 、JPG 还是 PNG 格式的图片? 尽可能的使用 PNG 格式的图片,更多的功能,更小的尺寸(与 GIF 相比)。

对于 PNG 图片,考虑用 Pngcrush 或类似的工具进行优化。常见的工具如下表:

  • pngcrush http://pmt.sourceforge.net/pngcrush/
  • pngrewrite http://www.pobox.com/~jason1/pngrewrite/
  • OptiPNG http://www.cs.toronto.edu/~cosmin/pngtech/optipng/ (refer: 教程)
  • PNGOut http://advsys.net/ken/utils.htm

另请参见: Five Tips For the Effective Use of PNG Images

对 JPEG 图片的优化工具:

必需要强调的是,图片设计的同学啊,请考虑设计面向 Web 的图片,不要动不动就设计超过可接受尺寸之外大家伙,这应该是一种习惯,而不是什么高超的技能,只需要记住就成了。

2. 使用 CSS Sprites 技巧对图片优化 (Optimize CSS Sprites)

之前提到过,简单的说就是"利用 CSS background 相关元素进行背景图绝对定位",把多次 HTTP 调用变为一次调用,更多参考:CSS Sprites: Image Slicing's Kiss of Death

补充一下:对于这个技巧我曾经见到有人滥用的。把多个背景图片揉成一个,减少 HTTP 调用,这是一个很好的思路。但一定要记住这个大图片不能太"重",我看到过 100 多K 的背景图。一个图片就把整个网站拖得很慢。比较好的例子可以参考雅虎关系的这个图.

更新:使用 CSS Sprites 的一个潜在的副作用是客户端将消耗更多内存(参考)。

3. 不要在 HTML 中使用缩放图片 (Don't Scale Images in HTML)

更多的时候,可能是因为偷懒而没有制作合适大小的图片,如果是批量处理图片的话,可能一条 ImageMagic 命令(convert )就能搞定 。必须提及的是,看到太多的对图片拉伸很难看的页面,救救这些页面!

4. 用更小的并且可缓存的 favicon.ico (Make favicon.ico Small and Cacheable)

更小,可缓存,这两条可能都不是问题。问题是,太多站点根本没有 favicon.ico 。有的时候,判断独立域名的 Blog 是否专业,基本看一下是否有 favicon.ico 就差不多了。

--EOF--

补充:视觉设计者应该尽量考虑控制图片大小,推荐在 200K 以下。这不是胡说的,参考页面。

关于这篇归档

This page is an archive of entries from July 2008 listed from newest to oldest.

June 2008 is the previous archive.

August 2008 is the next archive.

Find recent content on the main index or look in the archives to find all content.