看到 Smugmug 的 CEO
Don MacAskill
写的一篇关于使用 Sun 软件栈的经验。Web 2.0 公司用 Sun 这套东西的真的不多见。
| Smugmug 解决方案前后对比 | |
| 旧方案 | 新方案 |
| Linux | OpenSolaris |
| MySQL 5.0 | MySQL 5.1 |
| LVM2 + EXT3 | ZFS |
| 硬 RAID | 软 RAID |
| 非压缩 | GZip9 卷压缩 |
其实从一个技术体系迁移到另一个技术体系，最合理的理由就是能得到哪些收益。整个项目看下来，ZFS 是其中最大的亮点。管理简单，功能丰富，足够稳定。此外，ZFS 的备份、压缩功能也是非常值得称赞之处。
至于 OpenSolaris 的启用，倒是有一些潜在的隐患，比如 GNU 工具的集成使用上，缺少经验可能会给用户带来不少麻烦。其实 Sun 也是的，干脆把 ZFS 和 Dtrace 移植到 Linux 上算了。何必抱残守缺呢? 说起 Dtrace ，这可是好东西，性能 Tuning ，那可是屠龙刀。值得一提的是，以 OpenSolaris 衍生的Nexenta 项目似乎很有趣。
–EOF–
老文。去年受泰稳之托做的采访。这是我整理的稿件。另请参见 InfoQ 中文站上关于 此文的更多信息。
可能 MySQL Proxy 很多数据库技术人员都比较熟悉了，在前不久，国内也有开发者发布了一个Amoeba(变形虫)项目（http://sourceforge.net/projects/amoeba），这个项目专注分布式数据库 Proxy 开发，引起了广泛的关注。 DBA notes( https://www.dbanotes.net ) 站长Fenng 有幸采访了阿米巴项目的开发者陈思儒，以下是采访全文。
Fenng：你好，思儒，很高兴能接受采访，简要介绍一下自己吧?
陈思儒: 我目前是盛大计算机(上海)有限公司的一位高级研究员。 在就业生涯中从事分布式消息系统、分布式应用、多层框架设计、规则引擎开发框架研究，以及 Java 2D MMORPG框架研究。
Fenng: 说一下当初开发 Amoeba 项目的缘由如何，估计其中也会有不少小故事吧? 我可是非常好奇。
陈思儒: 其实 Amoeba 的前身是网络数据包分析代理，之所以 Amoeba 能够快速稳定发展也是因为个人在前期使用这些技术分析过一些游戏的数据包(这儿不方便透露一些细节，这些都只是个人爱好而已，并没有破坏那些被我研究过的游戏 :D )。
为什么会有 Amoeba 这个产品，这个话题的确非常有意思，我关注 MySQL Proxy 也有一段时间了。MySQL Proxy 的这种想法做的非常棒，它能够根据自己的想法去构造目标的 MySQL Proxy 应用，比如监控 SQL 执行、数据流量、读写分离。但由于我们使用 MySQL Proxy 并不能非常轻易的解决一些问题（读写分离、数据切分、水平切分、负载均衡），而是需要写大量的Lua Script，这些 Lua 并不是现成的而是自己需要去写。这个工作对于并不熟悉 MySQL Proxy 内置变量、MySQL Protocol 来说是非常困难的。
因此带着这个想法我就设想做一个非常容易使用、可移植性非常强的软件。Amoeba就因此诞生了。为什么叫Amoeba? 其实这个想法我是突然想到的，Amoeba中文意思是”变形虫”，Amoeba被设想为数据库代理的开发框架，它可以为符合Amoeba框架的任何数据库开发代理层。因此也比较象”变形虫”一样能够变成目标数据库的代理层软件。
Fenng: 我观察到 Amoeba 与 Oracle 交互的时候似乎还是模拟 MySQL 的驱动器, 实际情况是否如此?
陈思儒：目前Amoeba有2个产品：Amoeba for MySQL，Amoeba for Aladdin 。这2个产品有不同的适用范围：
其实在我上一家公司的时候也正在研发 Amoeba for Oracle，这个产品目前还正在研发状态。这个产品性能也跟 Amoeba for MySQL 一样出色。
就 Amoeba for Aladdin 产品来说，后端的任何数据与 Aladdin 交互采用 JDBC Driver. 对于 Aladdin来说，数据库的协议是透明的，而应用跟 Aladdin 的交互则采用 MySQL 协议，这个做法很多人有不明白，其实做这个决定主要是想借助 MySQL 使用的广泛程度以及对各种 开发语言的支持。因此对前端的应用来说 Aladdin 就是一个虚拟的 MySQL 数据库。你这个问题应该是问使用 Aladdin 的时候。
Fenng: 是的，是在看了你的 Aladdin 架构图后产生的疑惑。你比我严谨多了(笑)。能否冒昧问一下 Amoeba 项目当前的局限?
陈思儒：虽然 Amoeba 能够很好的解决水平切分、垂直切分等，但还是会存在一些局限性，这些局限性是因为我们在设计目标的数据库架构的时候就必须考虑到我们未来的数据库框架（可以线性扩容的数据库架构）。因此也有些查询将不支持，比如跨数据库服务器进行Join，我们要尽量避免类似的业务出现，也可以通过多次查询来解决这类问题。
Fenng: 你在前面也说到了 MySQL Proxy，能否简单的说说 Amoeba 与 MySQL Proxy的区别?
陈思儒：其实说与MySQL Proxy的区别应该是Amoeba for MySQL与 MySQL Proxy 的区别，在上面表述的第二点应该都涉及到了:
Fenng: 据说你也分析过 Oracle 的 TNS 协议，你认为可靠性如何?
陈思儒：的确，我在上一家公司为做 Amoeba for Oracle 分析过 TNS协议，可靠性以及安全方面都是没什么问题，Oracle 还提供了一些网络层的性能参数，用来改变Oracle的网络吞吐量。但是 Oracle 的数据部封包做法让我和老同事在分析 Oracle 数据包的时候伤透脑筋， 我觉得 Oracle 如果想在协议上面升级版本将不是一件容易的事情。而MySQL 的协议封包的做法我比较赞同。
Fenng: 对于分析 TNS 的可行性，我的看法倒是和你类似。顺便问一下，现在 Amoeba 是否已经有了成功案例, 方便的话能否举几个?
陈思儒：Amoeba for MySQL 的成功案例，目前就网友直接跟我说的有几个，但我还没具体了解他们具体的公司名称，以后知道了我再透露。
Fenng: 到时候千万要通知我一下。对了，能否说一下 Amoeba 项目的愿景以及下一步的目标?
陈思儒：目前距离Amoeba发展目标还有一点距离，Amoeba 未来将是一个更加容易使用、可管理、可动态装载配置、Amoeba集群等。
如果未来可行的话，我将补充 MySQL 协议，做一个用于负载均衡的”重定向路由器”（类似F5功能，但它只是做连接跳转）。
Fenng: 现在开发者主要是你一个人? 是否还有其他维护者 ?
陈思儒：Amoeba 框架、Amoeba for MySQL、Amoeba for Aladdin 目前的开发就我一个人。
Fenng: 很高兴你接受我的采访。期待 Amoeba 项目取得更大的成就，也祝你工作愉快！
陈思儒：客气！也希望有更多的开源爱好者或是数据库技术爱好者加入到这个项目的开发中来。关于 Amoeba 项目的进展我会在 “Amoeba 开发者博客“上更新，欢迎订阅。
–EOF–
旧文重发，期待新的一年这个项目能有更大的发展，能有更多公司从该项目中受益。
这是去年发在《程序员》杂志的一篇文章。当时写得比较急，现在看起来，有些观点有些武断。仅供参考。
引言, “The one that is without any tradeoff is to have the logical storage master up in the cloud” by Bill Gates.
2008 年的 IT 界，云计算是个热词。很多企业都在宣称自己提供云计算服务，很多人也都在讨论云计算(一些明显是凑热闹的，比如所谓的”云安全”)，从业界公认的几种云计算的服务能力看，都绕不开存储这个基础支撑组件，dSaaS(data-Storage-as-a-Service) 更是把存储提到了首要的位置。而从我们目前能得到的信息来看，在存储层已经解决很好的，恐怕也只有 Google 和 Amazon 两家，至于其他公司可能都还在路上，即使是微软，尽管也有自己的 Dryad ，但是实际上，仍然处于理论阶段，产品化的路还有点距离。
上面表格中的举例仅仅是为了举例，如果某家已经 “云计算了” 的公司大名不在上面，并非该公司”云”的不够彻底，应该只是笔者眼光差的原因而已。
根据 EMC 公司赞助 IDC 进行的研究计划 “Digital Universe” 的分析报告，在整个 2007 年，我们这个世界生成、占用的数字信息及复制总量大约是 281 Exabytes (1 Exabytes=1024 Petabytes ，1 Petabytes = 1024 TB 这里换算都按照二进制的换算)，这个数据平摊到地球上的所有人，大约是每个人 45 GB的数据；截至到笔者写稿的时候，2008年到现在整个世界已经生成了大约 374 EB 的数据（可以到 “Digital Universe” 页面查看最新的数据，也可以下载一个评估工具，看看自己产生的数据是大约如何）；到 2011 年，每年产生的数字信息大约是 1800 EB，10倍于2006 年产生的信息量。做为对比，Google 每天处理的数据大约是 20 PB 的样子，Google 的目标是要组织所有的信息，看来并非易事。
其他可参考数据：据美国国家档案馆工作人员估计，布什政府电子档案存储量大约为1亿GB，这一数字约为前总统克林顿两届政府档案总量的50倍，是国会图书馆2000万册编目图书内容总量的5倍。
每年激增如此庞大的信息量，加上已有的历史数据信息，对整个业界的数据存储、处理带来了很大的机遇与挑战。通过该研究能看出，在可用存储之间与信息生成总量之间不是严格匹配的，一方面多媒体领域信息增长过快，一方面因为不合理的存储分配、占用情形比比皆是。例如研究表明一封大约 1M 的邮件发出后，经过不同服务器的存储、备份、归档等最后总体占用空间竟然达到惊人的 50M 之多。正如云计算的初衷是为了充分发挥计算机闲置资源，提高总体使用率以便达到经济效益，云计算中的存储方面也应该能有效提高存储利用率而进一步创造价值，盲目的复制、堆积数据是没有出路的。工业界提倡节能减排，其实 IT 界应该提倡一下节约存储了。
其实，什么是云计算都很难有一个权威的定义，笔者在这里更愿意把”云计算中涉及的存储”简称为云存储(Cloud Storage)。云存储本身离不开云计算，更多的时候云存储是做为云计算的一个支撑组件。
云存储不是简单的在线存储或是网络硬盘，在线存储服务只是云存储能够提供的众多服务中的一种而已。
云存储至少应该能够具备如下特点：
谈到存储，可靠性还是要排到第一位的。没有人喜欢买三天两头坏掉的硬盘，代表高科技形象的云存储可靠性也要加强。
如果云存储服务不是针对在线用户的，那么没有什么实际意义，如果针对在线用户，不具备足够高的可用性也是没有意义的。Amazon 的 S3 服务给足够多的 Web 2.0 企业解放了在硬件存储上的压力，但是偶然的一次宕机会影响所有的 Web 2.0 用户；
云存储本质上还是规模化经济。如果成本不能有效的控制，那么云存储对厂家、对用户来说是没有意义的；
云存储组件应该具有足够高的扩展性，应该能够通过在线扩充存储单元进行有效的平滑线性扩展；
因为低成本的，存储组件的损耗率应该很高，云存储厂商应该能在软件层做到自动容错而不是依赖硬件本身的容错；
构建云存储系统，可管理性应该在设计之初就要考虑到，如果管理太复杂，很难做到低成本，稳定性、可靠性也会受到挑战。
对元数据的管理不应该通过少数或者单一的管理节点来操作或者存储。
要建设成功的云存储系统，高扩展性、高可靠性的分布式文件系统是一个关键因素。而硬件问题反而是次要的。
云存储的服务形式见上表。
未完待续…
在互联网这个行业，”以用户为中心的设计“已经达成共识，但很少听到有人说”以用户为中心进行性能优化”之类的话，很多时候，网站性能优化是面向服务器来进行，或许，应该扭转一点思维，改到考虑如何面向用户进行网站性能优化的时候了。
为什么要做优化? 不外乎如下几种原因：
多数公司做优化都是从前两者出发，而”提升用户体验”虽然是从用户(网站访问者)角度出发，但却很少提升到非常重要的高度。
此外，或许也有炫技的因素在内，为了优化而优化，当然这是不可取的做法。
有效的优化方式前提是要能有有效的度量。一个用户访问网站，从 提交请求到得到响应，完整看到页面，中间的每个环节都应该确保优化得当。否则如果后端已经”完美”优化，单用户请求的页面有 N 多大图片，也是个糟糕的事情。在没有建立端到端的度量数据收集之前，很可能存在较大偏差。
(图Refer)
一些常见的问题是，您知道访问自己站点的用户在使用什么样的线路? 什么样的 ADSL 线路，有多少还在用拨号上网? 在网吧上网的用户有多少? 多少是移动设备用户? … 如果此类数据收集有所欠缺，也很难做出有效的性能度量。
服务器压力降低 = 用户访问速度快 这是最常见的一种优化态度。技术人员对自己的网站用尽了各种优化手段，服务器压力终于降低了，单用户会真的满意么? 未必。但如果从没观察过终端用户的访问习惯和网络连接方式能客观因素，也是徒劳。
前端优化不如后端优化重要 前端优化仍然没有受到应有的重视，仍有多数设计者对性能问题熟视无睹，随手弄个 1M 大小的活动页面对他们来说，图片设计是否华丽可能才最重要。对于越来越需要多媒体、富媒体表现的页面来说，前端优化其实是重中之重。两手抓，两手都要硬。用户访问费劲的页面，再华丽也是垃圾。
节省 PV = 减少 PV 以 KPI 为导向的 Web 公司中，PageView 可能是很多人的饭碗，轻易不要太岁头上动土。不过对于 KPI 制定者来说，起码要具备如何识别虚假繁荣的 PV (除非也是作弊团伙成员)。不必要的 PV 能节省就节省，节余的带宽资源留给更有价值的应用。
把优化作为项目来做 有些网站会有”起个项目对某某块做个优化”之类的事儿。优化应该是个长期、持续的事情，如果单纯的作为项目来做，可能一波热乎劲儿过去就没人管了。
–未完待续–