December 2008 Archives

今年世界上大事儿够多，雪灾地震奥运神七金融危机毒奶粉战火......相比之下，个人的一点点事情就是绝对的鸡毛蒜皮了。

去年年末的计划列表，相比之下，完成率提高了一点：结婚，参加的是公司组织的集体婚礼，相对比较省心一些；折腾房子大半年，前几天也搬进了新居，一年内大事算完成两件。

工作上，这一年并不痛快，变动还是不小，暂且不提这档子事儿吧。年初计划的交流、培训倒也进行的凑合；在技术分享上应该也及格了；主机托管这事儿不靠谱，现在优化后的访问速度也还凑合；写书? 只好放到 2009 年了。其他折腾的事儿也不少，比较有趣的是参加中文网志年会。真正让自己感到放松的几天。

对我个人而言，2008 是值得纪念的一年；也是混沌之年。

2009 年的 TO-DO List:

• 翻译一本书. 和同事合作翻译 Troubleshooting Oracle Performance，这也是我认为 2008 年非常重要的一本 Oracle 图书，期待能按时交卷；
• 写一本书. 博文周老师的诚意让我感动不已，时候不早了，需要开动我的键盘啦；
• 提高团队声望. 提高我们技术团队的影响力，尽量去做；
• 提升技能. 技术是安身立命的东西，不能丢掉；此外需要提升时间掌控能力，多学点有趣的东西；
• 技术交流. 多参加一些活动，提升一点演讲技巧。

还有一些不方便列在这里的。

我的 2008 ：

• 年度致敬：许志永 面色平静而内心力量强大。
• 年度媒体：爱枣报。 推荐他们的年终特刊。另推荐网易的"无跟帖，不新闻"。
• 年度图书：《百城记》。那些被火炬照耀的地方...
• 年度活动：中文网志年会。
• 年度废物：管理者。管理是一门技术还是艺术?
• 年度技术：山寨。2009 ，我要继续我的山寨风格网站架构技术普及行动。
• 年度专辑：声音碎片的 《把光芒洒向更开阔的地方》。

我想你和我都需要一些变化，就像我们这个正在剧烈变化的世界那样。

--EOF--

年底了，收到的垃圾骚扰信息也多，到处都在搞年底业绩大跃进，什么中奖活动、折扣信息...... 眼看着元旦还有几天，最后的疯狂不能错过。

和朋友讨论类似的现象，都认为是 KPI (Key Performance Indicators) 惹的祸，完全以 KPI 为导向的团队，要想成员不作恶是不可能的。为完成小团体的业绩，管他什么企业价值观什么使命感，都是狗屁！赶紧把相关指标搞定，年底好分奖金才是真格的。

国内某些企业的败局，有些案例的导火索就是某些追求业绩的中层捅出的篓子。所谓"风起于青萍之末"，未尝没有道理。

或许用企业价值观强行对 KPI 进行干预是一种办法 ? 可操作性还是个问题。

Don't be evil ! 与君共勉!

--EOF--

在互联网这个行业，"以用户为中心的设计"已经达成共识，但很少听到有人说"以用户为中心进行性能优化"之类的话，很多时候，网站性能优化是面向服务器来进行，或许，应该扭转一点思维，改到考虑如何面向用户进行网站性能优化的时候了。

优化的目的

为什么要做优化? 不外乎如下几种原因：

• 节省资源，服务器、网络资源；
• 消除或者减少系统瓶颈；
• 提升用户体验

多数公司做优化都是从前两者出发，而"提升用户体验"虽然是从用户(网站访问者)角度出发，但却很少提升到非常重要的高度。

此外，或许也有炫技的因素在内，为了优化而优化，当然这是不可取的做法。

建立有效的度量

有效的优化方式前提是要能有有效的度量。一个用户访问网站，从 提交请求到得到响应，完整看到页面，中间的每个环节都应该确保优化得当。否则如果后端已经"完美"优化，单用户请求的页面有 N 多大图片，也是个糟糕的事情。在没有建立端到端的度量数据收集之前，很可能存在较大偏差。

(图Refer)

一些常见的问题是，您知道访问自己站点的用户在使用什么样的线路? 什么样的 ADSL 线路，有多少还在用拨号上网? 在网吧上网的用户有多少? 多少是移动设备用户? ... 如果此类数据收集有所欠缺，也很难做出有效的性能度量。

一些优化的错误认识

服务器压力降低 = 用户访问速度快 这是最常见的一种优化态度。技术人员对自己的网站用尽了各种优化手段，服务器压力终于降低了，单用户会真的满意么? 未必。但如果从没观察过终端用户的访问习惯和网络连接方式能客观因素，也是徒劳。

前端优化不如后端优化重要 前端优化仍然没有受到应有的重视，仍有多数设计者对性能问题熟视无睹，随手弄个 1M 大小的活动页面对他们来说，图片设计是否华丽可能才最重要。对于越来越需要多媒体、富媒体表现的页面来说，前端优化其实是重中之重。两手抓，两手都要硬。用户访问费劲的页面，再华丽也是垃圾。

节省 PV = 减少 PV 以 KPI 为导向的 Web 公司中，PageView 可能是很多人的饭碗，轻易不要太岁头上动土。不过对于 KPI 制定者来说，起码要具备如何识别虚假繁荣的 PV (除非也是作弊团伙成员)。不必要的 PV 能节省就节省，节余的带宽资源留给更有价值的应用。

把优化作为项目来做 有些网站会有"起个项目对某某块做个优化"之类的事儿。优化应该是个长期、持续的事情，如果单纯的作为项目来做，可能一波热乎劲儿过去就没人管了。

--未完待续--

这次搬家的时候，从各个角落里挖出来不少已经没什么用的小物件: 老式笔记本内存条、迷你路由器、便携网线、USB 小风扇、小台灯、奇形怪状的鼠标什么的等等一大堆... 当初弄到这些东西的时候都当回事儿的，可要是一段时间没想起用，基本上也就再也不用了。

估计 "绿色 IT" 将成为下一个行业内流行语，个人生活是否也有必要做一些精简? 少弄一些必须要的电子器件(今天就差点多买一个无线路由器)。"如无必要，勿增实体"，奥卡姆剃刀定律还是金科玉律。

就我个人来说，至少还应该努力尝试如下几点：

• 无线网络，网线再见 在有线的环境中，那根网线既麻烦还浪费，用坏的线还污染环境。
• 少买图书，不买杂志 图书杂志浪费纸张，不环保，在家里还占地方。当然这样说出版社的朋友们准不乐意了 :) 还好我只是说"少"买图书。
• 不换电话，少打电话 一部 iPhone 能多用一段时间就多用一段时间，尽量少发短信，很多时候没有打电话的必要，能不打就不打。
• 不写笔记，多写网志 不用纸质的笔记本，少用纸张，多写网志，不亦快哉。
• 抛弃鼠标，键盘作业 鼠标对人体造成的伤害还是不小的，或者只用指点杆也不错的嘛。再说鼠标非常容易坏，坏了往哪里扔? 尽量熟悉键盘快捷键，减少鼠标操作对阅读造成的中断，效率还能提升不少。
• 不用光盘，网上下载 有些厂商的软件还在通过光盘来分发，都什么年代了，还做这种吃力不讨好的事儿。能下载就让用户自己下载好了。

各位朋友对此还有何建议?

现在都在说刺激消费，我这里算是反其道而行之。嗯，有点拧巴。

--EOF--

补充一：

买东西尽量买同类商品中品质好一点的那个。一个劣质耳机和造成的污染其实和一个高质量的耳机是一样的。从投资的角度上看，也是划算的。

补充二：

不去领一些惠而不费的礼品。基本上都没什么实际用途的东西，尤其是一些展会上厂商分发的玩意儿。

补充三：

少弄一些劣质 T 恤。穿过一次就扔掉了，太浪费。牛仔裤也尽量少买，发扬"一条裤子穿三年"的革命朴素主义精神，嘿。

没吃过猪肉，也看过猪跑。简单的评几个我认为不错的 Web 应用设计。标准：针对 Web 应用的设计，2008 年出现的。

FriendFeed Real-time

FriendFeed 现在是 Web 应用设计的翘楚，各种特性都可圈可点的。我比较有感觉的是 Real-time 的设计，在减少大量及时信息附属信息造成的干扰，FriendFeed 几乎做到极致了。不信的话看看国内那些 SNS 模仿者就知道了。

在 2008 年对 FriendFeed 用的挺少，倒是有不少朋友在上面添加我。

淘宝商城 iPhone 版

淘宝 UED 的这帮家伙创造力很棒。我个人曾在数次无聊的会议中测试该应用。这个应用设计完全符合 iPhone 用户的习惯，对象元素的分布合理，对商品的主要可展示元素考虑的也足够充分。

其实本来 6.cn 针对 iPhone 而设立的频道开始也很好，但后来的设计就变得比较诡异。

建议：为了满足人民群众看图需要，淘宝把画报也做个 iPhone 版吧。闲极无聊的时候看图是个好的休闲活动，至于购物? 恐怕还不现实。

访问: iPhone 访问如下地址: http://i.mall.taobao.com/。

有啊表情

业界即时通信软件的表情图标其实雷同的太多了，而且很难表达出准确的含义。尽管说，一图胜千言，但很明显，有些人没把表情图标当成图。抛开其他问题不谈，这套图标值得表扬一下。

请欣赏:

如果非要挑毛病，那么第 20 号图标的爆炸后最后一帧不应该显示出黑色背景框.

好的设计让人心情愉悦。糟糕的设计让人火冒三丈。

--EOF--

不知道是不是受到金融危机的影响。今年国内新冒出来的 Web 2.0 Startup 挺少的。标准：国内的，基本要 2008 年出来的或者经历过比较大的改版，在 Startup 阶段，产品思路不是一味的完全复制硅谷已有的 Startup 。完全个人化的评价。

虾米网

虾米网给自己的定位是"高品质音乐社区"。这也是阿里系同学打造的 Startup 站点。我曾经专门介绍过，这段时间用的也比较多的。有一个观点我渐渐动摇，"高音质" 究竟有多少受众? 不管怎么说，虾米，还是给了我不少惊喜。

银杏泰克(GinkgoTek)

霍炬和郝培强 等技术牛人组建的银杏泰克是"专业搜索引擎技术提供商"。他们是少数看到了客户的商业需求而创业的 Startup 团队。不声不响已经培养了不少客户。

UCDChina

UCDChina 是中文领域"用户体验和产品设计行业"影响力最大的社区。白鸦和隽辰捣鼓的，玩票的成分居多，目前没什么商业化的趋向，但不排除向"UCD"之外扩散影响力。

这一年来，除了到处复制的 SNS 站点，其实亮点比较少。 Web 2.0 这一波到了低谷，建议初创团队还是从真正用户需求出发，玩概念只有死路一条。

--EOF--

圣诞节要到了，祝大家快乐！

年底了，推荐几个 BLOG。我的推荐标准：持续更新，在相关技术领域文章高质量，可能相对比较小众。希望能给这几位作者再带来一点订阅量，也让他们写就的东西有更多人受益。

知道分子

地址: http://hutuworm.blogspot.com/
作者: Hutuworm
Hutuworm 的 Blog。"沉浸于 Linux 系统管理十余年"，文章有技术含量，而且绝对有趣味。技术人多数不愿意写东西，写东西不一定技术好(比如我)，技术好的不一定文笔好，文笔好的不一定有幽默感。Hutuworm 好像这几点都具备。

Gracecode

地址: http://www.gracecode.com/
作者: 手气不错
来自淘宝 UED 的 "前端技术" 开发者，勤奋的 Blogger ，工作卖力，写文章也很卖力，在到处都是转载的所谓前端技巧的网络环境中坚持原创，是一件不容易的事儿。他的 "Javascript 每日测试" 系列文章很有价值( 2009年应该继续下去 )。

4G Spaces

地址: http://blog.youxu.info/
作者: 徐宥
我和作者不认识。他的《编程珠玑番外篇》是今年见到的最好的技术八卦(并非贬义)；"完全用键盘"工作的系列文章很好的体现了 Geek 精神。

云风

地址：http://blog.codingnow.com/
作者：云风
每一篇文章我都读过至少两遍，尤其比较感兴趣他念叨如何解决某个问题之类的事儿。《那些日子》，不管是不是游戏迷，应该读一下。云风的 BLOG 不算小众。

排序没有特别顺序，如果说有，那就是订阅量从小到大 :)

再推荐一个群体 BLOG :

apple4us

地址：http://apple4.us/
作者：张亮、飞猪、胡维等一票苹果迷
除去写乔布斯帮主的那些八卦(我不喜欢 Jobs 这个人)，其他的文章我都非常爱看。有趣、有味、有料。

--EOF--

豆瓣

如果没有豆瓣，我想这几年不可能保持如此高的阅读量。前一段时间我又在豆瓣上新开了一个小阵地，利用豆瓣日记写一些"以猜测、不着调、狂想为主的内容", 同时"设想一些不可能的事情，尝试一些思维碰撞"。

豆瓣坚持去中心化、不盲从的态度是国内互联网绝无仅有的。

Twitter -- 小道消息才能救互联网

相比去年的回顾，已经成了 Twitter 重度用户了。Followers 超过 1000 ，总消息也超过了 5000 条，可见我废话之多。Twitter 是获取消息最有趣的通道之一，尽管今年在参加一些技术会议的时候也用到过国内模仿 Twitter 的应用，但用起来总感觉味道不对。Twitter 在上半年因为性能问题导致可用性非常差，下半年已经取得了很大改善。

如果你也用 Twitter ，请 @Fenng 。我还是在上面分享了不少有点价值的技术信息的。

SlideShare -- 阅读 PPT 成为一种学习习惯

从 SlideShare 上获取了不少有料的 PPT。要学习、摸索一些新东西，请搜索 SlideShare 吧。其实 Scribd 也不错，但域名实在不好拼写嘛。

WikiPedia 维基百科

维基百科本身就是最好的技术知识资料库。Google 对 WikiPedia 的青睐让你不得不跑上去多看几页。让自己的惭愧的是，从来没给 WikiPedia 贡献一点内容。

尽管时不时的被阻尼，但是作为技术人员，总应该知道如何翻墙吧?

其他

其他还有我的 Flickr ，图片 Blog ，今年贡献了很多内容；del.icio.us ，也有朋友在关注我的收藏信息；Google Reader 共享，有的时候可能过度分享了。这几个一直是必然要用的网络服务，以后可能也不会变化。

保持学习，保持联系，保持更新，保持分享!

--EOF--

杭州电信分公司真是一家垃圾企业，流氓企业，无赖企业！ 强行涨价，也就忍了；强行限速，也就忍了；劫持 DNS ，也就忍了；乱弹广告，也就忍了...

可是，我办理一个 ADSL 服务，20 天之前交的费用，承诺 24 小时联系，可实际上没有主动打过来一个电话。这么多天前后打了几十个客服电话，每次都是经过漫长的 "线路忙，请等待" 之后，有个活人的声音(其实要弄个机器人估计也成)，要你报上身份证，然后听到一句 "很抱歉，我们将尽快为您办理" 之类的不痛不痒敷衍的话。

什么时候能安装? 他们永远说不上来；你继续打电话，还是这样，什么时候能安装? "我们也不知道"'；进行到什么状态? "我们也看不到"；我要投诉，找客服主管? "客服主管有，我找不来"。

你大爷的杭州电信! 这样的垃圾企业，如果不是仗着垄断，早该倒闭了！

--EOF--

到今天，DBA notes 五年了! 从当年记录的日志看，2003 年 12 月17 日，这个站点"对外正式提供访问"。

前几天浏览 Flickr 上的历史照片，过去的很多场景似乎一下子又跑了出来，今天翻看站点的历史信息，也有这种感觉，那些记忆并没完全消失在时间里，它们还在...

看看还存在旧首页，还有从最开始的那些尽量"符合 Web 标准"的 HTML 页面，站点成立之初完全是用刀耕火种似的手工方式进行更新，直到后来换到了 Movable Type 内容平台。这个过程也是摸索、学习、实践互联网相关技术与文化的过程。从今年开始，Twitter(有 1000 多个 Follower 了) 似乎成了发布微格式内容的一个更直接渠道，不过只需通过简单的集成即可把消息显示在 DBA notes 首页，独立站点仍然是主体，将来可能也不会变化。

一直觉得自己是个不善于坚持的人，从没想过会持续 5 年的时间做一件事情，并且还在不断尝试做一些改进。5 年，1800 多天，在这个站点上发布了 1200 多篇所谓的文章，从开始的 Oracle 数据库的一些小品文，到一些鸡毛蒜皮的个人事情，再到网络评论以及网站架构介绍.....有的时候自己会考虑迎合一下读者的口味，有的时候则完全由着性子写。自己其实不太清楚为什么会一路坚持写下去，可能仅仅像吃饭喝水那样，没有更深层的原因。

上次在广州参加网志年会的时候，居然遇到了一位 4 年前就是我的读者的朋友，多少有点惊讶。5 年，通过在站点上表达的这些东西，认识了很多新朋友，也收到过很多来自他们的反馈以及建议与意见 ... 5 年，已经无法计算究竟为此花费了多少业余时间，不过有一点：我相信付出的那些时间都是有价值的。我付出，也得到了应有的回报。分享知识的过程是最让人快乐的，即使分享的那些东西或许微不足道。

回想当初申请域名时，最头疼的就是关于域名购买的网上支付问题，这也使我在考虑加入支付宝的时候无形中投了一票。从北京到杭州，如今也已经将近 4 年，互联网的支付问题已不再是问题，这其中有自己的一份力。或许，人在做某些决定的时候也只是其他某个地方的蝴蝶扇动了一下翅膀。阿里巴巴五年以上的老员工叫做 "5 年陈"，会有一枚戒指作为纪念。Blog 五年有什么纪念?

感谢互联网，没有这个神奇的事物可能我不会学到如此多的知识，更不会成为一个技术人! 感谢车东，我在看他的网站的过程中萌生了自己建个站点的想法；感谢 SixApart 提供的 MT ! 当然也要感谢 Larry Wall，因为 MT 是用 Perl 实现的；感谢 Dreamhost 提供的物美价廉的空间! 感谢 鲜果，让我今年 Blog 订阅量暴增。 感谢通过 DBA notes 我所认识的朋友们!

我会继续的...

--EOF--

尤其要感谢从前我的女友--当然，现在已经是我的老婆--感谢她容忍我不陪她逛街或是摄影。

在前不久结束的 QCon 2008 上，MySpace 的首席架构师 Dan Farino 做了题为 Behind the Scenes at MySpace.com (PDF 下载)的技术演讲。

架构概况

超过 4,500 台 Web 服务器，配置为 Windows 2003/IIS 6.0/ASP.NET ；超过 1200 台 Cache 服务器，64 位的 Windows 2003，超过 500 台的数据库服务器，配置为 64 位的 Windows 2003，数据库为 SQL Server 2005 。

之前曾有一篇 揭秘 MySpace 架构的文章，也有中文版本《亿万用户网站MySpace的成功秘密》，请 Google 之！

运维数据收集

其实这个演讲我感觉主要讲的是这个数据收集模块 :) MySpace 的方案倒是让我们看到了在超大规模的 Windows 环境下如何进行数据收集的。

每个客户端通过一个 TCP 连接到收集上服务器。收集的信息包括：Windows 性能计数器 Performance Counters、 WMI 对象(定制后的 WMI 对象)、事件日志、 硬件数据等等。收集器服务(Agent) 用 C#实现的，完全的异步 I/O，用了微软的 Concurrency and Coordination Runtime 库。每台主机上一个 Agent。其实国内也有超大规模的 Windows 环境 -- 比如盛大，数据采集和监控的机制倒是类似的。

数据协议用的 Google 的 Protocol buffers。这倒是看到 Google 的这玩意儿公开后第一家大站点在用。也是因为用 Protocol buffers 从而不用 XMPP+ejabberd 的消息处理方案。

QCon 是我非常心仪的技术会议。可惜今年因为客观原因没能组织同事去参加。期待 2009 年在伦敦的会议。

--EOF--

延伸阅读：InfoQ 对 DanFarino 的专访。

周末的时候看到这篇 Scaling memcached at Facebook，感觉挺有料。但似乎又没什么可写的。最多就是准翻译一下。

相比之前介绍过的数据( 5TB数据/400台服务器).，现在 Facebook 在 Memcached 上的内容已经超过 28TB，总服务器数量超过 800 台。可见硬件降价真是够快的，内存的确便宜得很。

Facebook 作出改进的第一个问题是 Apache (连接带来的)进程连接开销问题。实现了一个针对 TCP/UDP 的共享的进程连接缓冲池。共享的方式比针对单连接独占内存的方式节省不少内存资源。考虑到一共有 800 台乃至更多的服务器，总体节省的内存资源是惊人的。

第二个改进是 UDP 模式的效率问题。第三个改进是网络中断给 CPU 带来的影响，这个我觉得就是变相的实现了 Intel I/OAT 的某些功能。补充一句，网络中断的问题其实是给很多企图制造山寨存储的技术人员一个拦路虎。

最后一个问题是在 8 核芯片上发现的新瓶颈。这个问题我想对于在多核机器上跑 MySQL 也会有很大借鉴作用。CPU 不是越多越好。有些开源软件与硬件的配合上面应该的确稍微滞后(不是落后)一点。

四个大的改进的结果是从 50, 000 /s 的 UDP 请求到 300,000 /s 的 UDP 请求支撑能力，延迟只有 173 微秒。

Facebook 的技术还是挺开放的。这一点上比 Google 强多了。

--EOF--

这次去北京参加 CSDN SD 2.0 ，没发现高春辉的身影，原来是忙着做手机之家的架构升级呢。

从老高的近期工作总结中看到：

目前的技术状况是基于自行设计的 PHP 框架，跑在 PHP 5.2 + MySQL 5.1 下，PHP 使用 Fastcgi 模式，WebServer 选择了 Nginx。搜索功能基于 Lucene 开发。缓存代理使用 Varnish。

对老高进行了一次非正式采访，聊了不少内容，整理了一下和大家分享。(谁是高春辉? 这个不要介绍了吧，请 Google! )

1) 历史情况

Fenng: 原来大约是用什么? 框架用的什么？
高春辉: 你说老系统？Apache 1.3 , DB 是 MySQL 4.0。新框架是团队自己写的，定制了一些东西吧，主要强调的是性能和方便、简单。另外把针对 YSlow 的优化也做进去了。
Fenng: 单说现在用的框架，大约投入了多少个人/天 ?
高春辉: 从全年开始考虑写，一直不断的写 -- 具体时间不好说。反正是不少了 :)
Fenng: 看了你 Blog 中的描述，有个小疑惑：没使用面向 DB 的 Cache 层?
高春辉: 我文中说的 Data accessor 就算是了。目前是拿 PHP 做的，Client+Server 集成在一起。后面第二期准备拿 Java 来写 Server 端。

2) 遭遇 PHP Bug

Fenng: 你提到的 502 错误不会是 PHP Fastcgi 内存爆了的原因吧？
高春辉: 不是，是 PHP 和 APC Bug 的问题。换新版就好了，你可以看 PHP 5.2.7 的 Buglist。里面列了一个在 Fastcgi 下父进程不能执行 shutdown module 方法的问题。主要是这个原因。APC 也有问题，它的Lock在大并发下非常容易挂掉。换上还没发布的测试版就好了。现在挺稳定的。一台机器跑了700万次请求了。
Fenng: 你遇到的是这个问题吧? Bug 45423
高春辉: Yes Here is the APC bug link : http://pecl.php.net/bugs/bug.php?id=5280 还附带这个问题。当时发现原因之后，非常郁闷，呵呵。
Fenng: 现在用 5.2.8 了?
高春辉: 嗯。5.2.7/5.2.8 反正没啥区别，就修正了一个bug。

3) DB 压力

Fenng: "原有的两台数据库平均总和超过 2000QPS 的查询次数，目前仅有 150+150+250= 550QPS 左右了" 这个 150+150+250 怎么来得？ 三台？
高春辉: 现在变成三台机器了 :)
Fenng: 哈
高春辉: 是原来的 1/4 吧 。
Fenng: 你 Blog 中提到 "由于新系统未经大规模流量实际验证，即使再有信心", 前面有没有做过压力测试?
高春辉: 做过，但是那个问题不是马上就暴露的。而是要运行一段时间才会出。所以我强调的是实际验证。

4) 过程挑战

Fenng: 问个比较俗 的事儿,最近一段时间给你压力最大的事儿是啥？ 招聘？项目发布？
高春辉: 人!
Fenng: 人员协调？还是人力招聘？
高春辉: 人永远是问题，好的人不够用， 差一点的人不想用，呵呵。
Fenng: 国内 PHP 好手还是太少吧？
高春辉: 嗯。太多人缺乏对大规模的研究和实践了。而且这次有些思路的转变是对 Java 的引入。之前是考虑 99% PHP 实现。现在考虑 PHP 只做前端。JAVA 做服务器后端。 这样混合编程才算是比较发挥各自的优势。
Fenng: 你们有很多事务的东西？
高春辉: 不是事务多，而是 PHP 本身就不适合做服务器端的内容。包括性能也很慢。比如开始发给你的链接(Fenng 注：之前发给我一个 Session 信息统计的地址)，那个 Session Server 就是拿 Java 做的。之前 PHP 的版本，一次请求要两位数(ms)以上，现在一次只要1.5ms，差距很大。

5) 再说网站架构

Fenng:提供给我一份网站架构拓扑图吧 ?
高春辉:这是实际的，包括 IP 了,供参考吧:

Fenng: 你们网站规模都这么大了!
高春辉: (笑)

Fenng: 考虑到安全问题，我只把缩略图放到网站上吧。估计没人能看清楚 :)
高春辉: 好。我们目前还是做了一些感觉比较不错的小东西的。比如 Data accessor、Session server、YUI compress server 等等吧。
Fenng: YUI compress server 应该是借鉴了 Yahoo YUI, 然后针对静态文件进行压缩的吧？
高春辉: 就是用 YUI Compressor 做的，只是做成了一个 Daemon 服务，而不是命令行的方式来处理。
Fenng: Data accessor 或者其他组件是否准备开源?
高春辉: 关键是只有到规模才需要它。恐怕大部分网站还是觉得麻烦得多吧。
Fenng: 统计分析和监控也是自己写程序？
高春辉: 那倒还没来得及下大功夫，只是做了一些简单的脚本。

6) 图片处理问题

Fenng: 提一个小建议：我发现主题频道这里的图片仍然有拉伸，我个人觉得拉伸是网站必须要慎重对待的问题，用户体验非常不好。
高春辉: 应该是 Imagemagick 使用的问题。 我还在继续修正，不过相信不是大问题。
Fenng: 这么说图片处理用了 Imagemagick ?
高春辉: 嗯。有图形处理后端 Server。

高春辉: 你可以看看手机之家论坛(http://bbs.imobile.com.cn/)的页面源代码...
Fenng: 现在(网站)的速度可真不是一般的快...YSlow 上的表现惊人, 差不多是国内网站我看到的最高分了。
高春辉: 其实全都都是动态请求，包括你看到的任何一个图片/JavaScript/CSS ...
Fenng: 你们的图片都是如何处理的？我看到似乎是动态拿过来？在DB里？然后Cache到缓存里么？
高春辉: 全部放到数据库里。作为备份。你在前台看到的都是动态处理的，通过 ID 进行关联。前面有两级缓存。数据库的内容相当于备份。这么做的我认为的好处是不用备份上百万个小文件了。而只是备份几百个大文件就行了。速度会提高非常多；而且那种静态损坏的几率就没有了，因为数据库本身会做数据的校验，我们也都保留的验证数据。

Fenng: 这是个反潮流的做法啊,我的猜测是每天数据量变化不大？
高春辉: 目前一天顶多也就是几百兆的增加，应该是可以承受的。而且即使量大也没关系，我可以具体到一个表拆到一个机器上跑。
Fenng: 可这样的话 EXIF 信息就不用了？
高春辉: 所有的信息都可以有一个 Metainfo 表进行保存。而且可以从新生成，假设你的文件信息解析程序有更新的话。
Fenng: 这是我这几年来看到的第一例。不过合适就好。
高春辉: Metainfo表,当然也可以由各应用自己解析自己保存。目前 FileStorage 已经保存了 1.1TB 的文件数据了。当前拆成了 256 个小表，每个表4G左右大小。
Fenng: 文件层用什么文件系统？XFS?
高春辉: 数据库都是 CentOS 5.2 64 bit 的系统。文件系统用 Ext3。其实没你想像的那么大的 I/O 压力，只要两级缓存有了。根本到不了数据库这里。而且前端的两级缓存都是可以多台机器一起跑冗余的。
只要配置就行了。以后备份和故障恢复也很简单。
Fenng: 这一点很有趣。 突破传统思维 :)
高春辉: 也是基于之前的教训而琢磨的方法，呵。

7) 对待 NFS 的态度

Fenng: 这次架构升级还有什么补充一下?
高春辉: 刚才还忘了说，我们这次以后坚决拒绝 NFS ...
Fenng: 为何?
高春辉: 主要是太容易单点了。 IO对一个机器压力大。这本来就不是个分布式的解决方法。

最后帮老高做个广告，他那边还在招人，需要 PHP/Java 方面的好手，如果有兴趣请访问他的 Blog 并发邮件给他：[email protected] 。

--EOF--

还是继续这个网站运维的话题吧。前面谈了知识管理与积累，这次谈一下运维过程中的自动化管理。

在进行这篇的扯淡之前，让我想起了《太平广记》里的一个《 板桥三娘子》的故事，姓赵的客商窥探到客栈老板娘三娘子在小箱子中取出小孩玩具大小的木头牛，木头人，喷口水，木头人、牛开始犁地耕作，撒一粒荞麦种子，木头小人种下，不一会儿，荞麦长成开花结实，木头人收割，乃至磨成面粉。然后三娘子把木头牛、人收入箱中，用得来的面粉做了数张面饼。多么好的一个自动化场景呀。

自动化的目的

自动化管理是网站规模化之后必须要面对的问题。为什么要自动化?肯定不是为了炫技，针对一个发展中的网站来说，自动化的主要目的还是为了节省维护成本，提升运维成熟度能力。另外一个经常被忽略的收益是能让运维工作更有趣味性一些，不那么无聊，不无聊的有益副作用是减少人为出错的可能。

自动化针对的范围大致可以分为安装自动化、部署自动化、软件发布自动化、升级自动化、监控自动化等几个方面。优化自动化? 别，这个稍微"高级"并且不靠谱了一点。

自动化要解决的问题是 N 次循环的过程，如果 N 不具备延续性，那么自动化未必有必要。比如某个过程可能只是短时间内需要临时进行几次，是否有必要将其自动化就有待于商榷。如果计划和开发自动化过程的成本高于非自动化成本就没必要了。

开发自动化过程

如果看过古龙的小说，他曾经描述过几个有趣的懒人，懒人造了一些木头人和机关来帮自己干一些不愿意做的事情。自动化多少就是"懒人"要做的事情，因为懒嘛，所以才会想办法节省时间和其他成本。一般来说，这个过程的开发者也是使用者，所以没必要一定要按照所谓的项目过程去走，但是开发者必须能够产出一份文档给同团队的伙伴(如果有的话)。

考虑到多数的网站运维可能都是在 Unix like 环境中的，而 Unix 的哲学思想之一就是"Write programs that do one thing and do it well"，每个过程只做一件事情就很关键，"功能单一的自动化模块"是有必要的，把不同的模块拼装起来再去完成更复杂的需求。

Unix 相比 Windows 来说，天生具备可自动化能力。如 Shell/BASH(自动化日常操作)、CronTab(自动化任务调度) 、Expect (自动化交互场景) 、rsync(数据远程同步)等 啊都是一些需要注意的技术内容。

优化自动化过程

自动化过程一般要有个生命周期，定期升级、优化也是有必要的。面对不同的应用场景应该逐渐改进自动化的可用性。

示例：自动部署 Linux

对于批量的 Linux 安装，RedHat 提供有 Kickstart Installations 自动安装解决方案，不过该方案相对比较繁琐，前不久推出的 Cobbler 是让人眼前一亮的好工具(参见 hutuworm 的介绍文章)。我一直怀疑 Cobbler 是中国人命名的项目，因为 PXE 发音为"pixie"(皮鞋)，而 Cobbler 的中文意思是"补鞋匠"。

OS 安装完毕之后的软件安装、更新是个麻烦事。在一个 Linux 的环境中，SA 一定不要为软件相互依赖性浪费太多的时间。什么 YUM、APT、YAST 啊，能用就用上。别太迷信自己编译软件所能带来的优化收益，实际上犯错的几率更大。达到某个规模后，本地建立、维护一个软件资料库(repositories)也是有必要的。

Linux 软件安装进化之路：

手工预编译-->RPM-->APT 等工具

已经进化到更好的阶段了，没必要还走着老路在原地折腾。

其他参考：Flickr 运维曾经采用 System Image 来自动化 Linux 相关的的运维工作。或许也可以尝试一下。

在系统配置管理(别混淆到另一个配置管理上去)方面，其实 cfengine 就挺好用的。更多类似工具参考这个比较列表。

标准化，减少后续维护成本是节省人力资源的一大法门。

自动化的一些风险

必须要承认的是，自动化有的时候是容易带来一些风险的，比如"冲掉"原有配置文件信息，不恰当的自动化脚本给系统带来额外负载等，在运维过程中需要不断总结经验。(又落入俗套)

这方面值得推荐的一本书是《UNIX和Linux自动化管理》，借鉴一下其中的思路和方法。

对了，补充一下前面的《板桥三娘子》的故事发展，三娘子的面饼如果被客人吃下，则会变成驴...... 同样，自动化有的时候会把人陷进去的，运维人不要变成自动化的奴隶。

这个话题还需要继续下去么? 我再想想 ...

这是支付宝首席架构师程立在 CSDN 软件开发 2.0 技术会议(SD2C 2008)上的技术演讲《大规模SOA系统中的分布事务处理》的 PPT 最后定稿。好几位朋友可能都等着着急了吧。

感谢程立的激情演讲与无私分享。原稿件大约有 8M ，我稍微转换了一下，放到了 SlideShare 上，便于更好的传播。如果要下载，点击上面的链接到 SlideShare 上即可。

关于程立

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

针对这次技术大会，程立说：

去讲这个主题的目的很简单，希望分享一下对大家可能有用的经验，说一些曾经困扰我们的问题，并给出我们的解决办法，不一定是最好的，不一定是正确的，但源自于亲身实践，并经过生产环境的严格验证。

延伸阅读：程立谈架构、敏捷和SOA实践

大家针对该 PPT 有任何问题，请留言或者发邮件给我，我将第一时间转给程立。

--EOF--

BTW: 支付宝架构组目前还在招聘架构师，有意者发邮件给: [email protected]

补充 :

• 云风的 PPT
• 黄冬的 PPT
• 李亮(Holly Lee)的 PPT
• 周爱民 (2007 年的) PPT

周六，北京的气温似乎回升了一点。

上午的课程兴趣不大，和网易的一些朋友聊了一会儿。下午倒是好几个话题都让我非常感兴趣。钱宏武的课程内容大致在意料中。来自 Amazon Jeffrey Barr 介绍的内容也没有让人惊喜的地方。

接下来就是支付宝同事程立的课程开始了。之前我还非常担心因为是最后一天的下午有人会急着回程，担心现场的人数。结果证明我的担心是多余的，现场非常火爆。

程立的演讲也很激情，我临来北京前看过一次他的 PPT ，没想到他后来又增加了很多几个有趣的元素进来(比如引用的山寨鸟巢的那个图)，平时感觉他挺严肃的，没想到幽默感也十足啊。

另外，要感谢程立帮我的 Blog 做的广告。我下周一上班把他的 PPT 放上来。大家先别着急。

最后是黄冬的课程，黄冬给我的感觉和车东倒是很像，随和，诚恳。这个课程内容其实寄托了他的一个创业梦想(PPT)。今天还是黄冬的生日，会议结束后，CSDN 还在现场播放了生日快乐歌。

合影，告别，挥手再见！结束了，为期三天的活动就这样结束了。

--EOF--

周五上午听了一下云风的课程: 高性能健壮系统中的内存管理。这个课程是我之前计划要听的。一个有趣的花絮，云风提问，有个朋友答对了，然后云风很老实的说"我没有礼品送啊"。

我发现云风一个有趣的小习惯，如果你和他对面站着，他会不停的晃动身体，我都快头晕了。可如果他在台上，他根本不晃 :)

碰上阿朱和张银奎老师在签售。阿朱的前面聚了一大堆人，而《软件调试》的大部头似乎感兴趣的人不多，我实在看不过去，把博文视点海猫同学的话筒抢过来，帮着吆喝了几句，然后简单的说了一下昨天听课的真实感受。还别说，我如果做书托还真有点效果。然后又帮阿朱喊了几嗓子。

保持低调的张老师：

下午听了一会儿周爱民的讲座，其他的几个话题我不感兴趣，到城里和互动百科的朋友做了一番交流，话题集中在网站架构、开发方面，大约说了三个小时。然后在海底捞(还真不是一般的火爆)吃了一顿饭，再回到九华山庄都差不多半夜了。

晚安，北京，晚安，所有未眠的人们！

--EOF--

毛主席教导我们：要坚持以山寨风格报道技术会议！

好多朋友不喜欢我写流水帐，今天再破例一下。周三下午我们出了机场打车直奔小汤山九华山庄。没想到出租车司机不认识路，走了好一阵子才说自己没来过这地方，我们沿着京承高速一直狂奔，中间我还打电话问了一下朋友，最后看见路标写着"前方一公里牛栏山出口"，大家全晕了。接着往回绕，找到小汤山后又多走了一段冤枉路后总算到了九华山庄。

办理入住的时候发现旁边一高个子长发帅哥， 心说莫不是云风? 一问果然是他，真的巧。三句话不离本行，我办理手续时候听见他们已经开始讨论技术了。云风说他背来一个游戏，热情邀请晚上一起玩。

九华山庄办理入住手续非常雷人，几乎是全国最落后笨蛋低级的业务流程了。在无奈的等了 40 多分钟后，手续终于办完(没想到后面还留下好多麻烦)。

过了一会儿去找云风，凑齐了四个人玩他带来的桌上游戏，Race For The Galaxy（银河竞逐）很复杂，还好云风有足够耐心，听明白了之后开玩，挺有意思，一边玩一边问，就是有点困。好不容易一盘下来，已经过了零点了。休息不表。

4 号下午 1 点会议正式开始。美女开场舞蹈，然后是CSDN 老板蒋涛致辞，主持人依然是韩磊，我在叽歪大屏幕上调侃"站姿标准"，这次叽歪大屏幕只在一侧有，现场也没有大范围提供 Wi-Fi 热点，所以互动性不那么强，相比之下不如上次在上海的好玩。从登高那里得到了现场唯一的无线热点密码，算是抢占了有利地形，除了跑到外面聊天的间隔，一下午基本上算是占领了屏幕，差点惹起民愤。尤其是我调侃" 谷歌的展位太雷人了，没人看着，用户自助服务。莫非Google 有智能监控么?"

开场舞蹈(有些雷):

蒋涛发言中(我非常喜欢这张照片，动静相宜):

谷歌中国展台空无一人(不知道设置这个展台干啥):

Jacobson 题为 Be Smart 演讲:

其实大多数 Keynote 都是类似的，大家各取所需吧。有的主题演讲我没听到，倒是听了一下戴志康的演讲，个人评价还是挺诚恳的。

会场外面雷军在休息，不经意变成了小型座谈，吸引了大量人气，雷老板就是有号召力。

最右边的周筠老师。

晚上去听了张银奎老师的《软件调试》的Session，很过瘾。张老师浸淫软件调试多年，三载成书，长达千页，而这次的技术演讲又是经过精心准备，幽默生动，富有激情。是我这次会议上的意外收获。结束后拿到张老师赠书一本，激动。

调试设备与生俱来:

--EOF--

晚上的飞机去北京。明天参加 CSDN 组织的 SD 2.0 技术会议。会议的话题林林总总，我仔细挑选了几个。相对一些业界名人味同嚼蜡的"宏观技术"演讲，我更喜欢参加在技术一线的技术人的分享，"技术含量" 是衡量技术会议质量的唯一标准。

选几个自己将参加的主题：

云风 -- 高性能健壮系统中的内存管理

虽然和云风都在杭州，但是一直没机会见面。他的 Blog 我可是每篇必然精读，很有嚼头，这次在会上希望能得到更多的技术启迪。

程立 -- 大规模SOA系统中的分布事务处理

程立是我支付宝的同事，可以负责任的说，他准备的东西很棒，在公司内部也多次交流过分布式事务的经验。"有技术含量"，这不是我一个人的评价，其他人都这么说。

周爱民 -- JavaScript + Delphi + ErLang = ?

周爱民的大作 《JAVASCRIPT》在我们公司很受欢迎。不知道他最近在修炼什么。到时候就知道了。

钱宏武 -- 如何诊断并且平滑升级大规模互动产品

他和黄冬，我听朋友介绍过多次了。这个话题我也比较感兴趣，希望有所收获。

除了这几位，还有张银奎老师的"感受和思考调试器的威力"，应该绝对有技术含量，但和我的技术领域有点偏差(担心听不懂)，有时间还是要去助阵。阿朱的新书应该也能在会议上看到了吧。

因为自己关注领域有限，可不是说其他的演讲都没技术含量。有的技术话题，自己也懂点，而有些时间有冲突的或是同事或朋友，因为交流过，就不重复参加了。

对了，据说 CSDN 在九华山庄斥巨资拉了一条专线，没准儿我在会上来个 现场直播也说不定，请关注我的 Twitter 吧。

--EOF--

接上一篇《流程规范》，继续谈谈知识管理与知识积累的相关内容。

所谓"知识管理与知识积累"，其实有点绕，我们不如就说说"运维技术文档"的事儿吧，这样可能还直白一点。因为每次说起类似的话题，总有兄弟用不屑的语气说，不就是写写文档的事儿么?

运维友好的文档

不同的团队对文档要求可能都有不同的"风格"--更多的时候是运维主管要看着舒服。就运维来说，必须能够创建"运维人员友好"的文档。

一般来说，运维文档应该具备如下特点：

• 易读性 便于阅读，便于技术人员阅读。尤其是内容不应引起歧义、转码等。
• 可搜索性 针对具体内容便于查找，便于发现。
• 版本化控制 这里不是普通的 V1.0，V2.0 之类的简单标识版本，而是要能够获取所有的内容改变过程，便于回溯。
• 通行格式 能够适应不同的操作系统平台。
• 信息完备性 具备足够丰富的交叉引用，反复保存的时候不会丢失信息等。

可能还有其他特性没在这里一一列出。有的网友看了上面的描述，这不就是 Wiki 嘛! Bingo! 基于 HTML 的 Wiki 页面，绝对是对运维友好的，尤其是网站运维团队。 我见过很多团队用 Word 写文档，这是非常糟糕的事情。在版本化控制、可搜索性方面具备天生缺陷。或许书写运维报告用 Word 是好的选择，但是运维技术文档的积累绝对不能用 Word。

运维友好的 Wiki

你们的运维团队在用 Wiki 么?

一般来说，具备一顶的语言背景可能更喜欢用该语言开发的工具(嗯，我说的是"一般")，有一定 Java 背景的程序员可能会喜欢用 Confluence 之类的 Wiki 工具。而对运维人员来说呢，什么是他们的语言背景? Shell ? No ! Perl/Python/PHP ，一般运维人员可能都熟悉三者之中的东西。

我个人多少喜欢一点 TWiki ，尽管我对 Perl 不那么熟悉。而很多中小 Web 网站，可能是 PHP 为开发语言，搂柴火打兔子，捎带脚让程序员帮着定制一些功能就成了。这是不是有点扯远了? 什么是运维友好的 Wiki 呢? 我的意见是要能促进运维人员技能的 Wiki 软件，比如选用了 TWiki，那么在维护的时候，Perl 背景技能就能派上用场并能进一步促进，多少有点以战养战的意味在里面。

此外，应该强制运维人员提交 Wiki 标记化的文档，而不是简单上传一些 Word 文档、PPT 甚至 HTML 附件。Wiki 编辑器里别直接粘贴从 Word 文档 Copy 来得内容。

如果团队足够大，应该有人专门定期检查文档质量，乃至对新人做一些简单的示例或者培训什么的。写一份好的文档甚至比写一大段好的代码更重要。

知识管理与积累

Wiki 上都记录什么? 最佳实践、技术心得、配置文档、软硬件信息 ... 乃至团队人员联系方式，随时记录是需要的，但保持更新更重要。

知识管理(KM, Knowledge Management)是干啥的? 这四个字说来话长，维基百科解释道：

... comprises a range of practices used in an organisation to identify, create, 
 represent, distribute  and enable adoption of insights and experiences.

用我的土话说，要把信息沉淀下来并传递给更多的人用。一个人写的文档，团队其他的人要能看明白，要理解，要能拿着这文档做事情。没有知识管理意识的团队，成员之间的信息交流或许也有些不顺畅，可能会在人员的使用上存在很多瓶颈，遇到一点技术上的小事情，原来负责的人不在场，其他人可能搞不定，这是风险！

有些团队对待知识管理的态度上是"拿来主义"但缺乏分享精神，比如复制大量网络上的信息到内部，但是不愿意对外分享团队的心得，这样不好!

积累，意味着这是一件长期的事情。不是一窝蜂搞一下就结束不管的。一份运维文档应该贯穿网站建设的始终，逐渐丰富完善。

后记：如果还有兴趣，写写关于《自动化维护》的话题? 要不算了吧。今天这个话题写的有点匆忙，因为不是对媒体供稿，所以行文语气很散，有待于收到反馈后更新吧...

--EOF--

插播一条广告：帮朋友公司招聘 .NET 架构师一名。尽管是互联网寒冬，还是有的公司准备足了木头、煤来取暖的。

职责：

• 1. 主要负责公司产品组件设计工作
• 2. 负责产品开发技术研究及其实现方面的技术分析和架构
• 3. 负责基于服务的接口定义和方案及其实现规划
• 4. 带领和带动整个开发团队的技术学习并对编码人员进行指导
• 5. 全局掌控和执行既定解决方案的实施
• 6. 关注团队代码质量和规范化

要求：

• 1. 熟悉面向对象的编程思想
• 2. 7-10年以上软件行业工作经验(非必须)
• 3. 计算机相关专业本科及以上学历
• 4. 具有良好的沟通能力及团队协作能力，工作细致，能承受工作压力,富有责任心
• 5. 拥有SOA系统的架构和设计能力，并且有实际的工作经验
• 6. 具有3年以上大型ERP项目开发经验并产于架构工作（非必须)
• 7. 了解微软主要企业应用技术和服务器：Biztalk,Message Queen(消息队列)，Windows UDDI Server等相关技术
• 8. 对WEB Service 有非常精通，特别要熟悉WCF,WWF等相关技术
• 9. 注重在后台开发架构，而非页面操作方面的能力
• 10. 对实现软件设计解偶的设计模式有相当经验
• 11. 熟练掌握常见的多种设计模式
• 12. 对系统性能的优化和评估有实际工作经验
• 13. 有MVC设计方法有实际经验
• 14. 对多层应用系统开发有3年以上实际经验
• 15. 了解IOC 和AOP等等技术
• 16. 有SSO单点认证或者通行证开发经验
• 17. 拥有多系统集成项目实施经验。

描述的内容还不少。其实就是一个 .NET 架构师该做的事儿，倒也不必强求所有条件都符合(那两个"非必须"的标注是我加的)，也别挑刺其中描述是否有过分的地方吧。

工作地点在杭州。

薪酬，年薪 + 期权。感兴趣的话请发简历到 [email protected] .，具体情况和招聘公司详谈，我知道的不比这个页面上描述的内容更多。

--EOF--