提要
一年之计在于春。
本文对我最近两年所参与设计的系统进行概述，总结期间的经验，希望有助于日后的工作，也期望对本文的读者有所帮助。
轰轰烈烈的纸条箱
2007年的春天，我参与设计开发纸条箱系统，产品定位是新浪站内的便捷通讯系统。当时产品设计对系统容量有很大的期望，技术设计人员也对系统有很高的要求，要求能够做到分布式异地部署，导致初期花费大量时间对系统底层进行设计。期间，在负载均衡方面，通过改装LIGHTTPD，设计出七层交换系统，并冠名以F7来抗衡当时xx的并且获得过新浪年度创新奖的F6系统（现在已经出现{zx1}一代的F8系统）；在存储方面，总结以前邮箱的经验，借鉴了TINYMIC的重要思想，设计出单纯使用文件系统进行消息存储和索引的存储策略；在系统间通信方面，计划对DNS系统进行改装，来作为存储和前端的通信系统；对设备的要求也从初期的预计八台演变到最终上线时的二十五台。上线期间紧张而又兴奋，但通过不断的观察系统负载情况，渐渐的很失望，服务器利用率很低。此时产品人员热情依旧高涨，当时有想法要做移动版的纸条箱，捆绑嵌入到手机等移动终端设备，誓言要超过中国移动短信的发送数量。随着日子{yt}天过去，大家对纸条箱的热情逐渐降温，纸条箱的访问量也随之下降，反倒是当初纸条箱的一个附加产品：黑白名单系统日渐活跃，后逐渐演变为目前的好友系统。
SPACE上线初期，对纸条箱系统进行了改造，存储方式由纯粹的文件系统转向数据库方式，对数据进行了迁移，最终两台数据库即承担了整个纸条箱业务的服务。
总结：
产品设计人员对产品的容量有不切实际的夸大，技术设计人员对高新技术有与生俱来的喜好，二者相辅相成，使得产品开发阶段过分看重技术实现，忽视业务逻辑，最终产品上线后，因为不能达到预期目标而造成资源的浪费。
顽强生存的好友系统
好友系统的前身只是纸条箱系统的一个附加功能：让用户可以设置黑白名单，来控制垃圾纸条的接收，随着互动社区的发展，好友系统的轮廓日渐清晰，重要性也与日俱增，曾经出去对效率与负载的考虑，试图增加Cache机制，但后来发现，即使不用任何外部的Cache机制，好友系统依然效率很好，如果增加Cache机制，反倒经常因为缓存不同步造成用户投诉甚至故障。后经过总结，主要是由于好友系统由简单的数据库存储，简单的数据结构、简单的应用逻辑构成，使得系统即使承担每秒钟3000次以上的查询，依然能够保持快速的响应。
总结：
无心插柳柳成荫。
不要重新发明轮子。

未见天日的Twitter
纸条箱后期、SPACE前期我参与设计新浪Twitter系统，当初产品设计人员对系统容量没有明确的目标，反倒是技术人员有更多的想法，认为这个系统的访问量会非常高（当时用“恐怖”来形容），消息发送量可能会超过UC的IM系统，所以技术人员站在了很高的高度，投入很多的时间和精力设计了“下一代分布式统一存储系统”，设计目标要不仅能够分布式部署，还能够灵活选用多种存储介质，性能当然也不能落后，要能够很好的解决互联网应用对于分布式存储的需求。当时这个系统还有一个辅助的高性能的队列系统，已经动工并有阶段性成果，但由于整体系统设计及其复杂，以当时的人力物力，尚不能实现。后来产品方逐渐热情不再，导致这个系统都像泡沫一样在大家心中破灭。
总结：对技术的狂热，蒙蔽了我们的眼睛，使我们看不清真正的敌人。
年度大戏
SPACE这场年度大戏终于上演了，我作为系统开发人员，对系统做了部分设设计，存储部分计划采用MYSQL多主库分布式部署方案，这样的方案，技术比较成熟，开发成本很低，实施难度并不是很大，系统运维部同事也大力配合，分别在北京、广州、天津三地机房部署了大量机器，多主库部署的结构也基本搭建完成。当时为了应对想像中SPACE巨大的用户量和数据量，不惜成本采购了大量的磁盘阵列系统，并部署到各个机房，由于部署盘阵的经验不足，当时费了很大周折。之后SPACE{dy}版的程序陆续开发完成，但在{dy}次系统测试的过程中，北京到天津机房之间的专线网络出现了严重的故障，导致测试很难进行，北京到广州的网络也有很大的延迟，公司网络访问广州机房很慢，使测试人员以及领导对系统的印象很不好。后来经过深刻反思，决定弃繁从简，放弃异地分布部署，全部收缩到北京进行部署（这一决定值得SPACE至今仍然只部署在北京一地）。此后一直到系统上线，基本顺利。上线后，系统负载基本平稳。预料中可能出现问题的地方是SPACE的核心部分：FEED系统。FEED部分由于数据量巨大，一个月内积累的数据达到数亿条，频繁出现数据读取延迟的现象。为此系统运维同事作出很大的努力，当时硬件资源比较匮乏，找一台大内存的机器都很困难，如果当初有两台16G内存的机器，FEED系统读取数据延迟的现象会大为缓解。后也曾设计很多解决FEED数据量的技术方案，但大多由于实施复杂、或者运维人员见解不一直而未能施行。
总结：
Make It Simple。
复杂的问题总是有简单的解决方案，《UNIX编程艺术》这部著作中写道：
优化一个系统的{zh0}的方式就是什么都不做——等待着新一代更快的机器出现。
有时候我们辛苦几个月实施一套复杂的优化方案，效果反而不如增加几条内存明显。
平淡的留言
接下来设计开发了平台留言系统，此时我对那些先进的系统架构没有了太多兴趣，当时领导对平台留言系统的期望亦不是很高，加之开发时间紧迫，所以平台留言系统平移了SPACE留言系统的存储方式、存储操作程序接口，只是简单的包装了一层应用逻辑。现在看来，留言系统在在系统架构上是大有文章可做的，平台留言采取页面读取数据接口的方式，很适合对数据接口进行异地分布式部署。我错过了一个千载难逢的实践分布式部署的机会。目前数据库多主库异地部署，在SINA貌似还没有先例，这应该是一个比较有意义的实践。
总结：
技术人员需要激情。
又一个订阅系统
最近的正在做邮箱信息订阅系统，因为产品人员不能拿出一个有说服力的系统容量数据而搁置。我觉得产品人员拿不出这个数据是很正常的，如果我们来做产品设计，也不一定能够拿出有理有据的数据，在很大程度上会是“拍脑门”定出来的。我认为应该以系统开发人员的经验来评估这个容量数据，迅速开发简单的系统，上线后在针对运行情况做进一步评估，来决定系统容量是否需要扩充。很有可能这个系统表现平淡，在运行一段时间后，就没有人xx了，然后黯然下线。所以我们没有必要在这个容量因素上纠缠太久，实践是检验真理的{wy}标准。
总结：
产品人员畏缩了，技术人员保守了，就算是理性么？
没有结尾
系统设计还在一个接一个的进行中，其中的纠结怎能用一篇短文道出！