Web Secret之：
导言
再提Web 2.0，都有些索然无味，再去界定哪些应用是Web 2.0的应用，也已经失去价值，虽然到现在，对于Web 2.0还是没有一个绝对的共识，但是大家不约而同地界定出了非Web 2.0的应用，那就是以门户和传统的Web企业应用为代表，“过去的、已有的、确定的”第一代互联网服务模式，我们叫着Web 1.0，而今天的、未来的所有应用，都可以称为Web x.0，与此对应的是技术领域，发展至今也百花齐放，有太多的技术是为Web 2.0而生的，如Ajax、RSS、Mashup、Cloud Computing、RIA等等，我并不想去探讨技术之间的优劣，也不想去探讨所谓的技术趋势，因为大多技术是因为商业而出现，同样是因为商业而退出舞台。
当我们把更多的注意力放在了用户体验，放在了“以用户为中心”，也将思维转向了逢人必谈商业模式和用户体验。而对于技术人员，更加乐意的事情是学习、介绍不断更迭的技术框架，比如AIR、Siliverlight、JQuery、DOJO等等，当然也会提到Google App Engine,Live Mesh,Amazon S3等等更加面向未来的服务模式。
跟随技术趋势而动是无可厚非的，但是对于新人而言，这些不计其数的框架带来了应用开发层面的诸多选择，同时也打开了潘多拉之盒，因为业务复杂性的提高，原本一些编程人员需要考虑太多的问题也就付出水面，那就是Web体系结构的设计相对以往，已经变得难以想象的复杂，也正因为如此，越来越多的公司明确化了架构师的职责，那就是在整体技术架构设计上需要满足不断变动的业务和日益增长的需求。
有很多词是用来界定体系结构设计的优劣，如可靠性、可扩展性、可伸缩性、安全性、可管理性、可编程性……我们创造了越来越多(xxx)libility相关的词语，自然而言，这些词也成了对于架构师工作的考量指标，有很多的文章和教程来让我们去学习一项新的技术或框架，网络上也有太多的框架和类库来帮助我们实现特定的功能，却没有太多的文章来讲述具体应用的架构设计，因为大多公司都会将这一部分作为他们的核心技术来看待，而技术本身是需要交流才能够进步的。
对于我的意图似乎有些敖述，那就打个比方来说，我们都知道几乎所有的应用都需要管理用户上传的图片，最简单的做法可能不需要超过10行的代码：
l 接受用户上传的文件流，存储到硬盘的指定位置，在应用代码里记录浏览的图片地址
l 提供一个图片服务器，用户可以查看上传的照片
可一旦业务有些特定的需求，事情就不是如此简单了：
l 需要能够一次性上传多个文件
l 允许上传大照片
l 流量比较大，不能够和应用服务器放置在一起
l .....
如此简单一个问题就会变得尤为复杂，通过搜索引擎，我们的确是可以找到不同面的解决方案，比如上传、比如图片压缩、比如分开存储.....只要你够勤快，几乎所有的技术点都可以在互联网上找到代码片断，你需要的只是把这些代码粘连在一起似乎就足够了。
可是如何完整地设计一个这样的解决方案，然后成为一个公司业务应用的一个基础支撑，互联网上这样的讨论似乎不是很多，我的视角这是基于这个原因，想从结构设计的角度去探讨一个互联网基础应用的方方面面，同时会在过去自己经验的基础上提出对于问题的考虑，当然，更多时候是去推荐成熟的应用解决方案。
我会用这样的思路去探讨Web应用的基础架构：
l 那些功能是基本的应用
l 在压力增大的时候，如何保证性能不会成为瓶颈
l 在“持续性”业务需求提出的时候，我们的架构应该如何调整而满足
l 如何控制管理和维护的成本
l 关键环节技术的实现探讨
至于探讨的主题，只能够根据我的经验和知识而确定，比如图片服务、论坛、聊天、投票、分享、邮件服务、站内消息、统一登录等等，另外出于交流和讨论的目的，我不会对技术平台做特定的偏向，只是从自己理解随意地选择合适的平台和语言来表达，也正因为如此，对于一些技术的了解不够深入，甚至出现偏差的问题，也希望真正的高手指点。
目前已经完成的：
图片服务：
l Web Secret：图片服务（一）——构建一个基本的图片服务
l Web Secret：图片服务（二）——扩展您的图片服务
l Web Secret：图片服务（三）——为您的服务加上缓存
l Web Secret：图片服务（四）——重新设计您的存储架构
l Web Secret:图片服务（六）——优化您的用户体验
137
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
