雨中的高速公路 - bluetent的个人主页

　　本周有幸用两天多的时间，与业界顶级的SEO咨询师进行了面对面的交流，收获颇丰。除掉80%不能说的内容，还是有一些common的经验能够分享给大家。这篇文章本身也顺便看看能否带来足够多的搜索引擎流量吧，呵呵。
　　1、对于百度，平级的文件形式的url要比目录形式的便于收录。
　　2、在页面里主动做相关网站的链接，并不一定是坏事。假设你的网站是A，相关网站是B，那么，用户从A链到B，比用户从搜索引擎直接点到B要好，此时搜索引擎会认为A更有价值，因为被更多的人点击了。
　　3、百度关注网站外链的数量，而Google更关注其质量。
　　4、简单来说，要先保证网站内链的良好结构，再做好外链，否则你可能会浪费很多精力。
　　5、有一些SEO公司可能在向你灌输错误的理论，因为他们需要你持续的为他们的服务付费，并产生依赖，尤其是一些让你购买他们外链的公司。

[Read more →]

　　我本科是学自动化的，所以工作六年来，一直致力于如何让一台服务器尽可能在无值守的情况下保持工作。但当前两天公司一台服务器的文件系统因硬件原因莫名其妙只读了之后，我突然打算反思自己这种追求完美的观点。
　　一个服务，放在那里，没人管他，想死是件很容易的事，而且往往都很出人意料，我来从记忆中随便抽些片段：
　　关于硬盘满：
　　某天夜里备份一个大目录，先tar后gzip，硬盘满，其上的MySQL服务无法写入，挂掉。
　　某天tmp分区满，某HTTP Server无法创建socket fd，挂掉。
　　某个脚本突然多了很多输出，向/var/mail下发了n多消息，导致var分区满，挂掉。
　　关于内存满：
　　某个不靠谱的服务需要固定占用2G内存，它为了防止内存泄漏，每天凌晨粗暴的自我重启。某天重启的时候，发现操作系统的内存忽然不够它挥霍了。
　　在apache的prefork模式下，在并发超大的时候，把系统内存吃光。
　　关于单点故障：
　　数据库通常配成一主多从，但主的服务器总有一天会出问题。
　　若干T的图片服务器，硬盘总是有寿命的，不多说了。
　　NFS有时候也会给服务添麻烦，比如某个不靠谱的程序员在NFS Server上跑统计脚本，把其它服务器都拖死。
　　LVS、L7负载均衡器、DNS Server、时间服务器、交换机、路由器、网卡、电源……冗余的代价太高了，有时候我们只能假设它们不会坏，并配上一系列聊以自慰的监控程序。
　　还有些不重要的服务器，直接放在公司，公司的机房没有UPS，也不一定有备件。如果硬件坏了，虽不影响线上服务，但恢复需要很长时间。如果它是一台开发服务器，那也足以挫伤组员的斗志，估算一下间接损失也可能上万。
　　关于不健壮的业务逻辑：
　　到memcache的连接，打开后忘记关闭，一群请求过来，memcache挂掉。
　　某个SQL语句锁住了整张表，或者创建了超大的临时表，可能几秒内就会把1000个连接占满。
　　内部的HTTP通讯没有设置合理的超时时间，导致上游压力过大时，内部因连接堆积而瘫痪。
　　异地备份程序没有确认数据已经传输完毕，就删除了本地数据。
　　其它：
　　某天你的网站突然被搜索引擎眷顾了，引发了超大流量，被IDC限速，于是你的服务器就不停的丢包，但你此时还沉浸在幸福当中，却忘了去看网络流量图。
　　你的隔壁机柜服务器中毒了，可防火墙在你们的上级节点。
　　以上情况如果平均每个月出现一次，就已经让人足够崩溃了。可是真有那么多Mr. knowall，或者先知，能提前规避这一切吗？从这里可以看出技术管理的重要性，好的团队，好的沟通机制，可以抵抗一些基本风险。说说我建议做和不建议做的：
　　建议：
　　核心的服务逻辑尽早做的足够强壮，并封装好，放到整个体系中复用、测试，不断完善并稳定下来。用你最放心的人做这件事情，不要让其他“不重要”的人去修改这个核，要把上述风险控制在你手里。
　　如果现有的架构已经老旧不堪，考虑新做一个可复用的核，然后一个服务一个服务迁移过去。
　　内部服务过于HTTP化也不好，内部的通讯是要消耗额外资源的，除非你一定要用nginx来做高可用部署。有些服务可以不Listen端口，而改为Listen socket fd。
　　有些服务，如果开源的软件已经做了很多年了，就不要自己再做一次，哪怕有创作的欲望，也要克制。把开源软件配置好，不比自己写的技术要求低。
　　不建议：
　　亡羊补牢是短视的做法，出现了问题，不要就事论事，关键还要深层次的去想，团队管理和沟通出现了什么异常，而不要划分责任或甚至逃避。我感觉，一个技术相对差的团队不太容易把一个业务搞死，但一个缺乏管理的团队一定会把一个业务搞死，而且是以最浪费资源的方式。
　　突然想到有两台服务器的服役期快三年了，得想办法赶紧把上面的重要服务挪走。梦想着把我们的系统逐渐改为一个去中心化的架构，这样服务稳定性对硬件寿命的依赖程度就低了。
　　

[Read more →]

　　最近几天利用春节放假的时间，搞定了nginx+php的编译与配置，将源代码和安装脚本都用一个git库维护起来，支持以下特性：

在服务器的任何一个目录解压均可，一个脚本完成所有编译工作。
将loadbalancer和webserver用不同的配置选项编译。
php的配置选项与debian发行版保持完全一致，包括suhosin patch。

　　拖了一年多才完成此事，也算是后知后觉了。计划在三月份，将我负责的所有web服务器及负载均衡器切换到这个体系下。

[Read more →]

方法很简单，以Nokia第三版为例，只需要三步操作即可：
1、到这里下载GO Contact Sync，它可以将Outlook的联系人双向同步到Gmail的联系人里。
2、依照Google mobile的步骤，配置自己的Nokia第三版手机。
3、点击手机的“同步”按钮。
非常的方便，而且信息很全面，甚至Google Talk联系人的小头像都同步到手机上了，呵呵。

[Read more →]

　　最近听同事介绍，试用了clicktale，它是一款用户行为跟踪工具。最大的特点是可以回放每个访客的操作流程，包括输入和鼠标轨迹，以及页面跳转。这可为很多网站节约用户体验测试的成本，对改进网站可用性是非常有帮助的。它的Free用户有每月400个PV的限制，且只能回放两个页面。最低的付费价格是59美元每月。打算应用到公司的产品上试用一段时间。
　　另外还有一个叫crazyegg的类似站点，它有一个优点是可以自动收集用户的鼠标行为，形成热图（Heatmap）。没有免费的版本，最低价格是每月9美元，限制1万PV的流量。作为抽样研究来说足够了。

[Read more →]

　　其实是上周二（4月14日）就已经办了，1740元包年，13个月，每个月可以使用300小时的本地流量。最近一周，我分别在东五环、上地、时速80公里的车上、首都机场旁边和燕郊进行了实地使用，信号都是一样的好，速度都是一样的快，下行超过1Mb没有任何问题。
　　今天联通出了它未来的3G套餐，貌似150元包月，想钱想疯了？我一直认为接下来联通和移动应该会出一档类似50元100小时之类的套餐，以填补电信资费套餐的空白。没想到它们还生活在太古时代。

[Read more →]

　　最近将公司的一个产品从apache 2迁移到了lighttpd。迁移过程中出现了几次措手不及的问题，但好在没影响线上服务，并且及时找到了原因，也算基本成功了吧，至少今后公司同事做类似事情的时候，不会重蹈覆辙了。
　　为什么要放弃apache？
　　这个原因直接从网上搜吧，一堆堆的。从实际工作角度来看，我是这样考虑的：之前用的是apache的prefork模式，它主要的问题是内存占用大（几个G），并且CPU占用会随着瞬时请求增加而飚升。对于一个访问量不断增加的网站来说，这些弊端是不可以接受的。
　　为什么要迁移到lighttpd？
　　响应能力高，根据我的测试和网上一些评测报告，粗略的看，能提高一倍左右。负载稳定，这个跟它用epoll还是有很大关系的。内存消耗少，这方面的优势是惊人的，稍后介绍。
　　为什么不迁移到nginx？
　　其实我对nginx更偏爱一些，一方面是没看到网上有从nginx迁移到lighttpd的，另一方面对它的并发处理能力很欣赏，但还是因为工作中的复杂情况，没有从apache一次迁移到nginx，确实是忍痛割爱了。
　　迁移中的重点难点在哪里？
　　是调优！max-keep-alive-requests和max-keep-alive-idle这两个值困扰了我好久，因为在和apache对比测试的时候，发现lighttpd的并发连接比apache要高几倍，虽说吞吐量大了，但是负载也上去了，后来才发现这两个值设的有点高。这说明，片面追求性能高，也不是好事，比如你可以把keepalive的idle时间设的充分长，但可能瞬时上千个爬虫IP来访问，服务器就挂了。（这块我理解的可能还有些偏差）
　　在url rewrite方面，apache和lighttpd的规则大部分是相同的，而nginx跟他们就不太一致，很多需要重写。
　　迁移后的效果如何？
　　高峰时段的负载也变得很平滑，之前负载的突变彻底消失了，每天的最高负载稳定在2到2.5，很完美的范围哦。
　　内存占用控制在1G左右。有时候我们不是嫌内存占的多，而是不知道它会占多少。lighttpd在这方面做的非常好，不但内存数量可控，且占用较低；举个例子，同样的fastcgi程序，用lighttpd启动，内存就比apache要小20%甚至更多；在高峰的时候，apache可能会拼命启动很多个fastcgi，而假设一个进程占几十M的话……就等着服务器报警吧，这个时候谁都会束手无策，虽然重启服务很简单，但fork几百上千个进程是需要开销的，更重要的是，每秒还有成百上千的用户在等着访问你的80端口。
　　

[Read more →]

　　一个是图书城，一个是Book Gadget。从主体文字的配色上看，高度一致，甚至右侧的推荐按钮也是相同的，当然后来douban修改成了自己的风格。
　　现已无法考证这几个网站是谁抄袭谁的了。

[Read more →]

　　今天下午，为了讨论某合作项目，与一个朋友开了次远程会议。
　　会议的目的是将先前整理的方案进行交流和汇总，并制定某个站点的用户需求和功能列表。如果有一间大屋子，有白板、笔和投影仪，那么讨论起来一定很方便，但恰好条件不具备，于是就决定开个网络会议，并找来一些工具加以辅助。
　　首先，采用google talk进行文字聊天，因为可以在gmail里方便的搜索聊天记录。
　　其次，采用QQ语音进行音频聊天，因为相比之下，QQ比google talk的传输质量要好一些，skype可能更好，但我们都没装，于是忽略。
　　接下来，我们还缺块“白板”，我找来一个叫stixy的网站，这个网站提供类似onenote一样的视图，方便的将文字以贴条的方式记录在白板上，并支持与其它用户的共享和协同编辑。
　　准备就绪后，会议开始，双方将自己在纸上和ppt上的计划讲解一下，我同时在stixy上记录，整个过程花了一个多小时，达成了许多共识。我起初以为，远程会议是无法达到面对面交流那么直接的效果的，比如聊天的时候可以说闲话，网络质量会影响讨论进展，等等。但实施了一次，发现好处还是非常多的：
　　远程会议能够让参与者更尊重对方的发言，因为抢话会带来更多的中断，是欲速不达的事情。
　　远程会议能够让参与者先组织好足够多的语言，然后表达出来，因为你没有那么多形象的手势和白板上的图形可以利用了，如果你不像让对方总质问你每个代词的含义，就把语言组织的更有逻辑些吧。
　　远程会议能够让参与者更聚精会神的聆听，尤其是做记录的那方。
　　远程会议能够帮助快速形成结论，因为争吵的成本太高了，大家都付不起，而且，今天是周末，不出去玩还可以睡觉呢，上网多浪费时间啊。

[Read more →]

　　用uch搭了一个SNS，想用来分享和交流与音乐有关的信息。大家可以点这个链接注册。里面装了两个比较好玩的应用，一个是全国各大广播电台的在线收听，另一个是酷狗的音乐盒。最近会完善一些群组的内容。

[Read more →]