这里所说的web,特指large scale web,大规模,高负载,高并发是它最显著的特点.
asp.net作为一个基于.net framework和windows的web框架,总体来说还是不错的.为什么说它要基于windows的,在linux下不也是可以用asp.net了吗？但那个asp.net是做不了large scale的web application的（这个我们可以一起探讨为什么）
asp.net在走过1.0,1.1到2.0的时代上,已经显露出了大量的弊端,随着各种快速并且在一定程度下仍能保证不错性能的几个流行的快速开发框架下,asp.net也做出了响应的改进,下一个版本的asp.net有非常大的可能直接是4.0版本,其核心的两大框架是asp.net mvc和dynamic data.比如说我们参照一下RoR框架,scaffolding是不是很酷,创建好数据库的table,一个scaffold,实体层和数据访问层就well done了,大多数情况下速度也不错.而django可以直接写一个实体的entity,然后就直接可以用了,更是方便,我们都忘记数据库是什么了.
技术的进步带来的一个不可避免的结果就是让更多的程序员缺乏对真相的认识和底层技术的匮乏.
园子里的朋友绝大多数的都是从事基于.net开发职业的.那么当你面对一个即将要展现在internet上的large scale的website的时候,我们如何考虑性能？NLB,Cluster,缓存,减少数据库带来的性能损耗,分布式...
这样的考虑出发点并没有错,看一下微软提供个我们的：方便的outputcache,愈发强大的sql server 2008,wcf框架, 更有前几天刚推出来的分布式缓存...
反过来我们看几点：
- 这些缓存真的需要这么麻烦创建或者说一定要你亲自动手去做吗？
- 把成千上万的小数据的内容放在硬盘上一定比放在sql server里快吗？
- 分布式一定要做的那么标准那么符合微软的要求吗？
我一直觉得早期使用过较多asp技术的朋友比起从asp.net作为起点开始web开发的朋友要幸福许多,能看到更多web的真相,也就是能更多的需要去了解http这个东西. 5年前有一个项目让我比较幸运的使用vb6封装了asp来开发一个产品,也是从那时候,逐渐开始知道了rfc的重要性.
我不知道有多少看了这篇blog的朋友能回味起学生时代听老师把html和web讲述成各种各样的版本.现在的学习方式应该改变了,是需要质疑和刨根问底的,相信学校里的老师或培训机构的课程,不如自己看看rfc并且动手实验一下.
要做大规模的web application我们需要了解一些什么呢？
a) HTTP
这个太重要了,很多地方都讲过它.这里不讲述什么,我们看一个例子：
一会就能看到response了.如果您对这三行命令一头雾水或还不太明白,那应该看看http相关的rfc了,如果您没有注意到这个request并没有“connection已经丢失”的提示,那应该看看rfc2616.
b) Web Server
不知道从上图大家是否看到了园子很酷的地方：使用了IIS7.0
IIS7.0如此的酷,是iis历史上一个最大的变革.从这个版本开始,才更像是一个web server了,同时也弥补了一些asp.net框架上的不足.
从两个不同的角度来举例子：
- 有没有朋友在iis6上使用asp.net mvc时发现你的url不能很酷,如果不借助third party你不能不接受url里是的情况.aspnet_isapi.dll不是那么优先的,至少它前面还有一个http.sys,但是对于使用asp.net的幸福的一代,这两个东西在大多数情况下都没必要直道他存在.iis一直是跟着文件走的,称作mapping,在到达asp.net之前,server已经根据url做了该做的工作,这也就是你无法把这个url重写的原因,要想rewrite这个url,唯一的做法就是去写一个isapi,托管代码在此时就没有任何作用了,换言之,要了解一些win32和iis6的工作模型才能完成这个工作了（幸运的是这个task不是很难）.而web使用的最多的是什么类型的？肯定是static file,那么好,iis7.0就把static file拉出来重新审视他的地位,所以在iis7上你可以把这个.mvc的尾巴去掉了.相比iis7,google app engine的server更多的是关注non-static的内容了,所有static的东西一定要说明了才可以使用.
- Gmail能不能用iis来做server,答案是当然不可以.http说我们可以有head,get,post,delete等命令,iis,apache等主流server都不支持delete,换一个角度,也就是说我们开发的环境导致了我们对web认识的片面性: client给server一个request,server是不是必须要立刻返回？ 一个request发送出去后还没有response,我们可不可以继续发送request呢？能发送多少个？
为internet提供服务的web server有各种个样,在一棵树上吊死或许不是明智之举,这里不是说微软的平台不好,而是说这个平台的价格和她的能力应该去让她去做更重要的事,这就好比你当老板的时候招一个3,4K的程序员来做架构,ta不一定有这能力;招一个12k的程序员来做一些繁琐和基础的工作,ta不一定能做好一样.Linux下有很多很酷的东西,比如nginx,lighttpd这样的lightweight web server,在处理静态文件的时候效率是非常不错的,由此节省的成本也骤然降低了N个档次.有时候我们会认为把静态内容放到内存里比做成静态文件更快,如果能不把IIS当作你唯一知道的webserver的话,那应该了解到webserver其实是一个处理静态文件的好手.像CDN这样的应用的例子是一个极限情况,应用它所需要付出的成本也是很可观的.有一些聪明的网站使用nginx来做过滤器,自己处理静态内容,动态内容转交到其他服务器来处理.而web server的实现也不是那么复杂,建立一个最基本功能的webserver只需要十几k的c的代码,有兴趣的朋友可以看看qshttpd-0.3.0这个版本的源代码.
c) Browser
最近几年来让人特别关注客户端开发的是xhtml, ajax, advance css, Yahoo的21 rules和IE8.尤其是yahoo的YUI小组两次公布的rules上,越来越多的人注意到了客户端程序结构的重要性,IE8的到来更让许多人知道了浏览器的connection的小秘密.其实不然,http标准里对这些内容的阐述就像是1年级的数学一样,只是用了一个SHOULD略加修饰.
在举一个case：如果您遇到需要删除一个Repeater里的所有checkbox为checked的items,除了在服务器端遍历这堆checkbox外,为何不用javascript去遍历然后将特征值以某种形式post到服务器,服务器删除完后给一个ok的回应,脚本再将客户端的页面的相关的内容从dom中去除或隐藏掉？仔细比较一下,性能和复用上都是一个提高.
上周五在家修养了一天,想了很多关于这篇blog该怎么写.文笔太粗,内容显得比较凌乱.技术应该是没有界线的,就像微软也从不排斥其他技术一样.写这篇blog希望更多的可以让园友们看到基于.net的web开发上的一些死角和一些固定思路.更希望有更多的朋友可以一起来丰富这个主题！
P.S.
与上文的图相比,看红框内的内容.
如果对lighttpd感兴趣可以参看一下： 如果对google app engine感兴趣可以看一下： 如果对博客园团队感兴趣可以comment上您的博客园ID加入该team.此外,对于Team我开通,希望有些您不是太急一时google不到结果的问题可以post到小组里.小组相比QQ群是异步的,在不耽误大家工作的同时相信会有更好的答案.