最近在设计一套网络存储系统，因为不知道该产品上线后的用户使用数目，因此只能靠预估计来定制方案：
目前客户端的注册用户是4亿，每天活跃用户在4,000万左右，其中有1,000多万人是登录过网站的，每天有50万用户活跃在网站。网络存储过能是每用户100MB空间，会员是1G空间。
那么我们要为网络存储系统来预估计第一期设计。互联网产品的架构，忌讳初期设计的复杂，原因就是要为以后的快速改变留下余地，一般一个产品的架构前两个版本都是alpha的，第三个版本开始产品设计部门才清晰自己究竟要怎么做。但是架构，一定要比产品思考的更远，可扩展性、高可用性是首要考虑的问题，同时还有一个需要关注的，就是后续的资金投入。
在对比了Hadoop等产品后，我们决定自己做基于windows server平台的分布式存储系统的构建，原因只是我们对.net/windows平台有更多的熟悉和对微软产品的信任。那么预估计一下，按照80/20法则，我们可以估计初期我们承载的用户应该在50w*20% = 10w，每用户100MB的话就是100,000*0.1G/1000=10T，其次，金融学里还有个著名的7/2法则，我们可以用这个法则来预估增长的时间段。第一步，我们先不考虑那么远，10T的上限空间，其实我们提供8T的存储，就可以满足初期的要求。
8T的空间，是自己攒服务器呢还是选用NAS？还是SAN呢？
如果自己攒服务器，挂10块1T的SATA盘，1块做热备，9块做RAID5，那么存储空间可以达到8T了，符合了要求。放10块盘，用3U的机器就OK了，对于内存和CPU的投入采用中等偏上的配置就可以了，是不是很经济？如果选用NAS的话，打开投入会增加60几倍，用SAN的话则更贵。
OK，我们倒过来看问题：我们的网络存储系统，除了存储外，更重要的一个功能是上传和下载，这里消耗的是什么？是I/O了。按照传统经验，SATA盘每个的I/O上限也就在100左右了，9块盘最多支持800的并发，I/O已经接近满载了。那么问题到这，我们看到，我们能承受10w用户存储容量的系统，只能容纳800用户的并发操作，能做到只有什么？当然需要做Load Balance了，100,000/800，这个值不小吧？
我们再换个角度看问题：高可用性。用户的数据需要备份，这么大的数据量，备份较为经济的做法，选择带库是比较合算的。现有的网络结构中，有部署在SAN中的Tape Library做备份用，这个网络结构的设计是很合理的。但是问题来了，我们的存储服务器的硬盘是自己搭建的，不是走SAN中的磁盘阵列，如果我想选用SAN中的带库做备份，那只能从SAN中打通一条网络连接到存储服务器上，这个就只能走LAN了。及时我们选用1G的网卡，每秒的数据传输能到50MB已经是非常非常不错了，那要备份5T的数据，都需要超过1天的时间了。按照备份的常理，我一周做一次全量备份就不现实了。如果不选用带库，那其他方式的备份方案就更不经济了。
走到这一步，我们应该怎样去思考结构了？
(To Be Continued …)