2022年面向搜索引擎的内容管理系统（CMS）设计搜索研究教程.docx

《2022年面向搜索引擎的内容管理系统（CMS）设计搜索研究教程.docx》由会员分享，可在线阅读，更多相关《2022年面向搜索引擎的内容管理系统（CMS）设计搜索研究教程.docx（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、2022年面向搜索引擎的内容管理系统（CMS）设计搜索研究教程搜寻引擎友好(Search engine Friendly)：基于PATH_INFO的参数解析使得动态网页在链接（URI）形式上更像静态的书目结构，大大便利网站内容被搜寻引擎收录；可缓存性（Cache Friendly）：CMS本身不要过多考虑“效率”问题，只要页面输出设计的比较Cacheable，效率问题可以通过更前端专业的缓存服务器解决。后面附有一个简洁的利用PATH_INFO机制 + SquidWEB加速模式实现PHP动态网页的静态发布的例子，比起那些能导出静态页面的大型发布系统这种轻量级的动态缓存解决方案只需对原有的动态发布

2、系统做少量的修改，从而大大提高了原有内容发布系统的重用度。网站内容静态发布的重要性：Cacheable / Search Engine Friendly由于一个动态页面的速度往往会比静态页面慢210倍，因此对于一个访问量逐步向百万级发展的网站来说，访问速度很快成为一个瓶颈。除了优化内容发布系统的应用本身外，假如能把更新频率比较低的动态页面转存成静态网页来发布，速度上的提升效果将是显著的，而静态网页假如能被缓存在内存里，访问速度更会比原有动态网页有23个数量级的提高。在国外内容管理系统(CMS)已经是一个特别成熟的行业，能够真正支撑大访问的系统中静态页面输出和缓存系统几乎是必需的。此外随着互联网

3、上的内容以惊人速度的增长也越来越突出了搜寻引擎的重要性，假如网站想更好地被搜寻引擎收录，网站设计除了面对用户友好（User Friendly）外，面对搜寻引擎友好的设计也是特别重要的。链接地址相对固定的静态网页比较适合搜寻引擎索引，动态网页后面跟的参数敏捷度很大，因此许多搜寻引擎都往往会忽视动态页面，比如：对于news.php?day=22month=03year=2022，许多搜寻引擎可能只索引news.php这个页面一次，更多其他参数的页面可能都会当成相像内容滤掉；我个人始终怀疑在搜寻引擎中：即使是同样内容，静态页面往往也比动态网页的PageRank高。因此，将动态页面转换成静态页面，无论

4、从效率上还是面对搜寻引擎友好上，都是一个门户级内容发布系统必需面对的问题。静态缓存和动态缓存的比较静态页面的缓存可能有2种形式：静态缓存：是在新内容发布的同时就立即生成相应内容的静态页面，比如：2022年3月22日，管理员通过后台内容管理界面录入一篇新闻后，就立即生成 动态缓存：是在新内容发布以后，并不预先生成相应的静态页面，直到对相应内容发出恳求时，假如前台缓存服务器找不到相应缓存，就向后台内容管理服务器发出恳求，后台系统会生成相应内容的静态页面，用户第一次访问页面时可能会慢一点，但是以后就是干脆访问缓存了。假如去ZDNet等国外网站会发觉他们运用的基于Vignette内容管理系统都有这样的

5、页面名称：0,22342566,300458.html。其实这里的0,22342566,300458就是用逗号分割开的多个参数：第一次访问找不到页面后，相当于会在服务器端产生一个doc_type=0doc_id=22342566doc_template=300458的查询，而查询结果会生成的缓存的静态页面：0,22342566,300458.html静态缓存的缺点：困难的触发更新机制：这两种机制在内容管理系统比较简洁的时候都是特别适用的。但对于一个关系比较困难的网站来说，页面之间的逻辑引用关系就成为一个特别特别困难的问题。最典型的例子就是一条新闻要同时出现在新闻首页和相关的3个新闻专题中，在静

6、态缓存模式中，每发一篇新文章，除了这篇新闻内容本身的页面外，还须要系统通过触发器生成多个新的相关静态页面，这些相关逻辑的触发也往往就会成为内容管理系统中最困难的部分之一。旧内容的批量更新： 通过静态缓存发布的内容，对于以前生成的静态页面的内容很难修改，这样用户访问旧页面时，新的模板根本无法生效。在动态缓存模式中，内容管理系统只须要关切各个页面自身，而相关的其他页面链接能自动更新，从而大大削减了设计触发器设计的须要。VIGNETTE的动态缓存虽然很好，但是一个系统假如设计得太全面其实也是有很大危急的：假如一个频道下文章许多：比如达到十万时，假如生成的静态页面都在一个书目下，对系统文件系统是一个极

7、大的危害，因为一个书目下文件个数超过3000效率就会特别差，甚至连rm *时都会出现too many arguments错误。简洁的说，一个好的内容管理系统应当包括：输入：便利的内容录入，所见即所得的编辑界面，权限限制等输出：便利的模板管理，缓存发布等设计或找寻这样一个系统假如考虑功能全面和高集成度，你会发觉只有那些几十万$以上的专业内容发布系统才能你满意全部的需求。以前做应用的时候也用过一些方式：应用首次访问以后将生成的内容存成一个缓存文件，下次恳求时从缓存书目中读取缓存文件，内容更新时，应用把内容从缓存书目中删掉，从而削减对数据库的访问。虽然这样做也能承载比较大的负载，但这样的内容

8、管理和缓存一体的系统是很难分别的。假如换一个思路：通过肯定的分工现内容管理和缓存机制2者的分别，你会发觉无论哪一方面可选的余地都是特别大的。甚至有可能利用目前的已经是“功能”比较全面的内容管理系统，而让全部“效率”问题都由前台更专业，而且是很简单分布的缓存服务器解决：可以是通过开放源代码的SQUID做反相代理的WEB加速，可以是特地的缓存硬件设备，甚至是专业的缓存服务商。动态缓存必需有一个基于静态链接本身的参数解析过程，许多专业内容管理系统系统都是将参数解析机制做成了WEB服务器的模块实现的。我们可以把以前的HTTP/GET方式的?key=value改为干脆用/value1/value2的方式

9、来传递，从而实现了动态页面的静态URL形式。而缓存只须要在前端加上一层CACHE服务器，比如：Squid。网站动态内容的动态缓存发布就可以实现了。根据这个机制实现的发布系统很好地体现了应用系统的分工：把困难地内容管理系统分解成：内容输入和缓存这2个相对简洁的系统实现。而中间的内容发布通过URL REWRITE或PATH_INFO解决动态页面的参数传递：后台：内容管理系统，用心的将内容发布做好，比如：困难的工作流管理，困难的模板规则等前台：页面的缓存管理则可以运用缓存软件（比如前台80端口运用SQUID对后台8080的内容发布管理系统进行缓存），缓存硬件，甚至交给缓存服务商。_ _|Squid

10、Software cache| |F5 Hardware cache|- - / _ / |ASP |JSP |PHP | PATH_INFO Based Content Manage System -把URI地址用作参数传递：URL REWRITE和PATH_INFO最近看到许多关于面对搜寻引擎URL设计优化(URI Pretty)的文章，提到了许多利用肯定机制将动态网页参数变成像静态网页的形式：比如可以将：变成：最简洁的是基于各种WEB服务器中的URL重写转向（Rewrite）模块的URL转换：这样几乎可以不修改程序的实现将news.asp?id=234的映射成news/234.htmlA

11、pache上有一个模块（非缺省）：mod_rewrite：当然URL REWRITE的强大功能还远远不止于此。当我须要将将news.asp?id=234的映射成news/234.html时：只需设置：RewriteRule /news/(d+).html /news.asp?id=$1 N,I这样就把 /news/234.html 映射成了 /news.asp?id=234当有对/news/234.html的恳求时：web服务器会把实际恳求转发给/news.asp?id=234而在IIS也有相应的REWRITE模块：比如ISAPI REWRITE和IIS REWRITE，语法都是基于正

12、则表达式，因此语法是几乎相同的：比对于某一个简洁应用可以是：RewriteRule /news/(d+)? /news.asp?id=$1 N,I这样就把 /news/234 映射到了 /news.asp?id=234如我须要把 表现成 RewriteRule (.*?.php)(?/*)?/(/*)/(/*)(.+?)? $1(?2$2:?)$3=$4?5$5: N,I通过URL REWRITE还有一个好处就是隐藏后台实现：比如我们须要将应用从news.asp?id=234迁移成news.php?query=234时，前台的表现可以始终保持为 news/234.html。从实现应用和前台表现的分别：保持了URL的稳定性，在实现后台应用平台的迁移时特别有用。运用mod_rewrite甚至可以把恳求转发到其他后台服务器上：另外一个方式就是基于PATH_INFO：PATH_INFO是一个CGI 1.1的标准，全部干脆跟在CGI或动态页面app.cgi后面的/value_1/value_2就是PATH_INFO参数：比如 = /man/lsPATH_INFO是CGI标准，因此PHP Servlet等都有比较好