基于xml的网站模型应用

  今天朋友对我说我被推荐到csdn专家了，很开心，特发布新博以示庆祝。

前言：xml网站不是什么新东西了，csdn最早的论坛也是基于xml的，后来为什么改掉了，我想除了搜索殷勤支持不够外更多地是技术支持不完善，但这正是我研究了3年多的项目核心，从最早的asp.net实现到后来的自制java模型实现，再到后来的基于linux的c/c++模型实现，现在回归到用.net配合IIS的几个模型实现，产品脉络基本成型，固然还有一些基础问题没有得到解决，但是对于总体的运行、SEO、用户体验、多样式、多语言等等方面已经有了初步的论证。

 

  下面这个截图是网站的一个运行预览

 

 

1、综述。

  做了8年的web，从asp到asp.net,还兼学了jsp(甚至自制过一个简化的jsp实现和一个jsp服务器)，看透了web开发其实就是一张皮，对于传统的程序员发展成为web的会非常不习惯web的viewer方式，对于美工发展过来的web工程师会觉得那跟那都很模糊，人们会很大程度地去争论哪种技术的优劣，也难怪，对于入门者你很难要求他从架构上去考虑一些东西，本身就云里来雾里去的，js在客户端运行的、html在渲染层起作用的、asp.net绑定是服务端运行的，这些基本的概念糅杂在一起了本身很多人都没有搞清楚，谈架构就更不容易了。

    的确，微软在商品化上了做了很多的贡献，asp.net在商品性的层面上的确是领先的，但是现有的asp.net jsp php等等都是满足基础的程序需要的，讲求大而全，我可以不用，你不可以没有，像raise这种新奇的东西才迅速被人认可，敏捷才提上日程，但是现在所谓的敏捷开发是指对于开发速度来讲，对于运行速度等架构方面的东西只有一些大公司才做的起，比如google和百度，google的很多应用就是一个服务插在一个自制的web服务器上完成的，这种离散的的架构恰恰是web的核心所在，而往往被人所忽视。

   其实xml模型是一种再好不过的模型，因为他有个天然的xsl作为viewer，而程序员可以专心考虑数据结构，程序算法，数据安全等等，这样其实后台用什么语言都是何以耦合的，更符合web的需求，但是种种原因限制了他的发展，很重要的一个方面就是seo（ie6以下也起了很大的阻碍），现在的程序员靠考虑的东西越来越多了，什么浏览器兼容，ajax，css等等等，这么好的一个模型在这里却白白浪费。

    3年来我的工作就是致力于从根本上解决一些主流的问题，我的总结就是我们错误的认为我们所看到的就一定是搜索引擎需要看到的，其实不然，搜索殷勤是不需要美术的，既然浏览器能合成作为viewer渲染出完整的html为什么不能针对搜索引擎提供服务器端渲染呢？搜索殷勤对于一个网站的流量连1%都占不到，这样我们就可以静态化大部分数据（有权限的可视数据），如果能在客户端访问IIS 、apache等最前端的时候截获请求，分析如果是搜索引擎就转向到指定的后台合成服务模块的话，就可以解决大部分的问题了。

 

    这里重点要解决的一个问题是如何让重要的url写在xml或者xsl里面，而不是通过js等程序生成，下面我就重点讨论一些常见的技术细节：

2，技术架构探讨。

   a、分页。

      看似简单的一个问题在整个架构中却最难解决，因为必须要所有的链接都能有xsl解析器解析，而不是js解析，这里可以把数据再次分离，本身对与一个数据列表是分两个部分的，第一个部分是指具体页面的数据列表，第二个部分是指满足要求的总的数量，这是所有分页的基础，对于倒排序的尤为困难，我采用的方法是将数据数量等配置信息作为一个外include xsl包含在分页的xsl中，这样 分页.xsl和 列表.xsl是可以静态化的，数量.xsl也可以静态化，只是需要每次增加后促发一次更新，这样这3个部分都是静态化了，对于浏览器用户可以直接静态化使用，对服务器压力几乎全在静态文件上。

 

     对于产品无极分类等页面，解决的办法只有将数量信息输出到列表也中，得不到即使更新，但是可以通过设计把列表占用字节做的很小，优化到多用int联合查询，这样这种列表也可以实现。

 

   还有一种解决倒排的方法是最后一页满足双倍于一个最大页码时才自动分离成2个页面，具体问题可以联系我探讨,需要特殊技术支持。

 b、多语言、多皮肤。

   这项功能构思了很久，直到现在的项目应用才不断完善，解决的办法就是将所有的xsl放在固定目录下，比如skin/default/default.xsl,在引用的时候全部引用相同路径，对于服务器的404xsl进行处理，转换到对应路径，这样只有一个xsl的请求时需要服务器redrict的，对服务器的性能影响很小。这样服务器就可以根据用户选择语言或者皮肤对应到不同的目录。

  曾经在用c做自己的服务器的时候考虑的是xml不包含xsl，因为处理性能比apache还快，所以在用户输出的时候进行动态包含，现在基础.net没有相应的技术支持就没有办法了，只能通过redrict的方式解决，对于用户来讲是感觉不出来的，一个网络来回一般也就32毫秒。

  加上客户端会缓存css、图片、xsl等等，所以第一个页面打开后用户的用户体验会明显提高，比任何服务端合成的皮肤样式都会快。

 至于为什么不用css来完成皮肤功能想必用过的都知道，顶多也就完成类似baidu博客的那种换肤，只是简单的表面的更换，而xsl可以达到任何级别的更换。

  c、SEO

    最终对于seo还是要采取特别的办法，对于asp.net jsp等都有现成的xsl转换器，php的不熟悉，现在发现的问题是对于给定的一个xml和xsl他们获取引用的资源的时候都是采用本地相对路径的方法，如果是引用一个动态生成的网络资源就会不显示，因为本地文件不存在，所以对于那些大型架构不在同一个服务器上的文件会有些麻烦。

 

  好像可以重载转换器的输入源，但是没有试过对于内部的xsl引用xsl管不管用，理论上来讲，浏览器能做到的，服务器端就能做到，所以这不会成为最终的障碍。

  d、性能

   如果考虑得到完全可以将95%的代码静态化，虽然放在客户端执行优惠会觉得速度慢，但是相对于几百个人都把请求交给server端渲染来讲要快得多，瓶颈分散了，如果你的客户群至少有奔腾三的cpu，你完全不用考虑他能不能承担起这额外的开销，因为我工作的测试机器就是奔三的。

3、扩展和升迁

  如果你能把上面说的问题都注意到，那么如果你的业务架构变得非常大了，对于升迁来讲是很方便的，绝大部分的ui代码都不用更改的，只要针对程序逻辑进行更改，而我的理想就是在我的c web服务器上运行起分布式的架构网站，这可能才是其真正的商业价值所在吧。所真的，如果是一个小网站你真的不用考虑这些了，适合的就是最好的。

 

 好了，时间太晚了，今天就到这里。