病中的 eBay

电子商务巨头 eBay 有恙，病在腠理，不治将恐深。已经好久不写针对竞争对手公司的评论了，但《福布斯》这篇文章真的让人感触良多。

硅谷的 IBM

谁的会议多，谁的效率低下:

公司内部流传着一个笑话，说eBay已经成了”硅谷的IBM”。20年前，IBM的官僚作风最终导致了公司风光不在，而这一比喻正是对eBay当前状况的真实写照。一些现任和前任eBay员工纷纷在采访中抱怨说，eBay总是有开不完的会，公司太看中幻灯片的演示而忽视了真正的创新。他们说，eBay成了 “商业咨询师”的聚集地，但是这些人大都是”纸上谈兵”，根本没有与客户进行深入的接触，而且缺乏技术眼光，行为方式过于保守，而真正工程师却只能在一旁听候指挥。

不吃自己的狗粮

eBay 管理人员不用自己的产品，自然也就无从知道用户的感受:

“eBay的管理人员都很聪明，但是这些聪明人却从来都不用eBay，也没有花费足够的时间来研究他人是如何使用eBay的。”

电子商务公司需要技术高层

除了刚刚加盟前网景公司联合创始人马克-安德森(Marc Andreessen)之外，eBay公司的最高管理层中找不到任何的拥有技术背景的人。

尽管有些问题，但是 eBay 仍然是需要我们仰视。

–EOF–

Cocolog 从 PostgreSQL 迁移到 MySQL 的经验

 Tips: 10 月 9 日我将去南京，参加支付宝 2008 校园招聘 南京大学站。

Cocolog 是日本领先的 Blog 社区，基于 SixApart 的 TypePad 技术框架。运营公司是 NIFTY（最新的调查报告显示，NIFTY 在日本流量排名第 10 ）。前一段时间看到这篇 Migrating from PostgreSQL to MySQL at Cocolog, Japan’s Largest Blog Community ，比较详细的描述了从 PostgreSQL 迁移到 MySQL 的经验，很有参考价值(日本互联网技术特点?)，在这里做一篇学习笔记。

核心系统的支撑软件

Linux 2.4/2.6
Apache 1.3/2.0/2.2 & mod_perl
Perl 5.8+CPAN
PostgreSQL 8.1
MySQL 5.0
Memcached/TheSchwartz/cfengine

都是一些司空见惯的东西, cfengine 是用作软件维护、部署、分发的玩意儿。

初期技术架构示意图

这是我第一次知道 TypePad 除了 SixApart 自己的服务之外还支撑了第三方的站点(孤陋寡闻!)。

初期 PostgreSQL 基本上是用来存储本地注册用户信息。这个阶段数据库分区之前，服务器数量在 10 个以下。

第二阶段

这阶段数据库分区之前，服务器数量在 50 个以下，可以看到 DB 还额外存储了富内容模板等元数据信息。系统各个模块紧耦合，数据库 Schema 变更有些费劲了。

第三阶段

Web API 的引入在一定程度上消除了紧耦合的问题，Memcached 的引入很大程度减轻了 DB 的负担。服务器数量在 200 个以下，未分区之前。

第四阶段

数据库分区之前，服务器数量在 300 个以下，增加对移动互联网的支持能力。这个时候 PostgreSQL 貌似还是单实例的样子。数据超过 100GB，40% 是索引。要忍受比较严重的数据碎片问题，备份是个麻烦事儿。

在此之前，PostgreSQL 服务器在硬件上一直是 Scale Up 的思路，内存从最初的 1GB 扩展到 07 年底迁移前的 16GB，磁盘换到了阵列上，阵列是富士通的 E8000 。国内倒是很少遇到有把 PostgreSQl 扔到企业存储上的案例。

现阶段

这是迁移后的架构示意图。引入了多个 MySQL 实例。从原来的 Scale Up 切换到 Scale Out 的路线上。数据库分区，服务器数量 150 个。

集群软件采用了 NEC 的 ClusterPro 。数据库是共享存储的，不过 I/O 瓶颈应该消除了，因为读的压力分散在每个 MySQL 服务器上，内存承担了大部分工作。写操作的压力在一台存储上，问题不会很大。

实施步骤

1. 服务器准备；
2. 全局写问题（Global Write）　应对策略：写用户信息到全局 DB 中；
3. 全局读问题应对策略：读、写用户信息在全局 DB 中折腾；
4. 迁移序列　应对策略：全局 DB 承担；
5. 用户数据迁移（User Data Move）　应对策略：移动用户数据到用户分区中；
6. 新用户分区（New User Partition）　应对策略：所有新用户直接保存到新用户分区1中；
7. 新用户数据处理策略　　根据需求设定一个策略；
8. 非用户数据迁移。

这几个过程都不难理解，数据迁移的一节倒是值得描述一下：

对上图做个解释(其实也是翻译 PPT 上的注释):

1 Job 服务器提交一个新的Schwartz Job 迁移已有的用户数据，用户数据异步迁移；
2 迁移中的用户发布的留言保存到 Schwartz ，稍后发布；
3 迁移完毕后，所有用户数据存放在用户角色 DB 分区；
4 一旦所有用户数据迁移完毕，只有非用户相关数据存在 PostgreSQL 中。

这个迁移的技术细节其实可能不那么重要，但重要的是必须有个迁移流程的制定过程，任何所谓的迁移，如果没有制定详细的计划，无疑会吃苦头。

迁移后的备份示意图：

最后看一下架构概览图(点击可放大)：

Tip：这个架构图中关于 NAS 部分，可能不那么可靠的。

上面引用的图版权归原 PPT 作者所有。转载我这篇流水帐的网站请不要随便给图片打水印。

–EOF–

P.S. 如果你有耐心看完前面的部分，你或许应该提出如下疑问：

1）为什么要迁移到 MySQL ? PostgreSQL 也是支持分区的啊 …
2) 这其实就是个数据 Sharding (分片)的问题, 作者为啥不直接说?
3) 第五阶段, 服务器数量为什么变少了?
4) 迁移全是在线进行的么? 有没有影响用户访问?

如果一个问题都没有, 其实和没看差不多。

又及：PPT 里面提到的监控指标也需要注意一下，你的网站监控了这些内容么?

response time of each post
number of spam comments/trackbacks
number of comments/trackbacks
source IP address of spam
number of entries
number of comments via mobile devices
page views via mobile devices
time of batch completion
amount of API usage
bandwidth usage

对付经济危机，我有解放鞋 — 工字胶底鞋评测

经济危机席卷全球，寒意袭人，创业者喜欢说”从头再来”，可咱这样的小市民只能”从脚做起”。昨天在家闭门苦思对策，忽想起了前不久谈论的中国解放鞋成欧美新时尚，灵机一动，附近的菜市场这鞋的原型就有的卖啊，今天斥巨资采购了两双回来，平均 RMB 15.00 一双，这个价格在杭州银泰恐怕一双袜子都买不到。

有图为证

我拍照水平有限，不能弄出 Ospop 那样酷炫的效果。不过模仿网上所谓的运动鞋评测，咱也来个”评测”。

评分

-----------------------------------------------------------
外观 9      (现在不都说复古么?)
舒适合脚度 9  (没说的，从小就穿)。
保护 8     (穿着去户外，蚊子肯定叮不到你)
缓震 2     (毕竟咱这不是运动鞋)
场感 10   (穿在脚上绝对拉风)
-----------------------------------------------------------
总评 8

优点

这双鞋的外观是笔者非常喜欢的地方，足够保守，所以给了高分。可能有些人看法不同，这纯属个人意见。虽然这双鞋子没有内靴，但是鞋舌、高高的鞋帮以及在鞋内连接鞋舌和鞋底的缝合部分让这双鞋子的包裹感同样出色。

鞋底足够耐磨(经过两万五千里压力磨损测试)。劳动人民都爱穿的鞋，品质有保证。

缺点

此鞋不带天足技术，所以缓震效果一般，脚感偏硬，透气性一般。另外，和裤子不太好搭配。另外一点，鞋帮上印的不是 “工”，而是 “K”，百思不得其解。(网友给我留言说可能是”克隆”的意思? 不过即使是克隆，那和欧美的”一丁点骄傲”也是表亲啊)

据小道不靠谱消息，著名网友某某、某某等已经赶去菜市场抢购。已有个别商家准备囤货，伺机抬高价格牟利。

–EOF–

更新：在豆瓣建立了一个”解放鞋“小组. 欢迎加入，只为好玩。

黄金周

这个黄金周，美国救市方案获参议院通过，中国银行借记卡全部告别免费。北京两个音乐节同时举行。要说国庆谁比较累，一般人儿比不过崔健大爷。不过国庆之后最累的可能就是学生了，每天长跑 1000～2000 米可不是那么轻松的，还不如弄个 2008 米，叫做欢庆奥运成功好了，只是不知道现在学生是否喝牛奶。

在 SNS 上做了一个小实验，似乎没成功。我自己在这个假期基本上是处于 “IDLE” 状态，这半年多来得紧迫感好像没了…总算感觉歇过来了。

–EOF–