小网站架构优化-提升抗并发能力：子应用程序分离方案
前言：
标题为啥要加个“小”，只因为上一篇文章“
小网站架构优化：从100并发抗到4000并发”，带了个“小”字，所以这篇也顺流加个“小”了。
大意“小”是特指秋色园（流量小，服务器配置低）的意思，毕竟文章都是从实战后才写出来的。
关于现实网站的抗并发实情：
由于每个网站的性能点，最后都离不开抗并发这一话题。
也许，网站本身并没有那么多并发访问，但为何还要抗并发？
因为现实不是每个人都是善良的，商业竞争也很激烈，竞争对手间时不时的互相攻击网站也很普遍。
昨天才一网友向我说起，他朋友的网站，逢周一就会被竞争对手攻击，导致业务无法开展，换服务器也无济于事。
所以，提升网站的抗并发能力，除了抵抗用户的高峰期访问，也是是自我网站保护的一种手段。
什么样的站点能抗的起高并发？
若除却外部带宽等因素造成的外部影响，则内部答案只有一个：静态网站。
静态网站何以能抗高并发？
因为静态页面据说在操作系统内核级就能缓存数据并做出响应，所以抗并发能力理论上是最强的。
所以，你看看电商网站，除却技术背后的实现，你能看到的页面，多数是静态页面。
所以技术的背后是Java还是.net还是php，看似就不是那么的特别了。
当然了，也不是所有站点都适合静态化，所以技术架构优化显的特别的重要。
根据某网友提供的数据，仅供参考：
CSDN首页的文章：2000并发以下挂了，这块是java提供服务。
而CSDN的博客：能顶好万级的并发，这块是ASP.NET提供服务。
而CSDN的论坛：能顶好几十级以上的并发，这就是静态化的结果。
所以那篇很火的“去.NET化的文章”，可能是作者个人意淫，
当然了，这些数据可能也是意淫的结果，不一定所属事实。
所以，要提高抗并发数，高配的服务器不是全部，还需要合理的代码架构优化：
本次实践分离方案的背景：
在秋色园系统的优化文章中，都似多似少的提到了搜索这块引发的CPU命案。
某天，我想起了“
IIs 网站应用程序与虚拟目录的区别及高级应用说明”这篇文章的内容。
有了想把搜索独立出去的想法，这样即使搜索挂了，也不影响网站访问，更不用担心搜索引发的CPU命案。
构思中：
于是三七二十七，就开始想了：
目前秋色园的URL搜索这一块为：www.cyqdata.com/search/类型/搜索内容。
而文章的关键字（一般博客为设置为tag，引到文章，而我是引到搜索区）。
想了两种方案：
A：是弄个二级域名，建个网站来运行，这个需要动点代码：
这种方案，要修改URL变为so.cyqdata.com/类型/搜索内容，看似改动不少，需要调整URL机制和301处理，预计整体在30-60分钟内应该可以解决完。
这种方案的好处是，后续扩展可以部署到其它服务器。
这种方案的好处是，后续扩展可以部署到其它服务器。
B：直接使用子应用程序，可以不改动代码，直接把搜索这块分离独立子应用程序运行：
这种方案，代码不用改，因为根据search建立子应用程序即可。
这种方案，一般就局域服务器只能在局域网内了。
这种方案，一般就局域服务器只能在局域网内了。
方案选择：
综合秋色园目前的情况，也就一台VPS。
两个方案的区别就在于动代码和不动代码了。
后来我选择了不动代码，因为实际的效果几乎是一样的，所以就不动代码了。
方案二实施过程：
1：在IIS 6 里新建一虚拟目录search，创建右键属性，应用程序名那里对应的按钮点击“创建应用程序”然后虚拟目录就转化为应用程序了。
2：项目路径还是原来的项目路径，然后设置新的应用程序池，最终如下图：
总结：
一般一个项目大了后，或者逻辑变的复杂后，往往的解决方案就是分解成子项目。
而分解的方案：一般是根据域名，或首页节点目录。
后来思绪了一下，比如目前博客的URL是：xxx.com/cyq1162/admin/...
如果一开始考虑把它设计成：xxx.com/admin/cyq1162/...
这样是不是也就可以轻松的把博客的前后台分离开来。
当然了，分成多个进程，是需要思考，是否有涉及直接的通讯。
文本就介绍到这里了，仅提供一种参考方案。
版权声明：本文原创发表于博客园，作者为路过秋天，原文链接：
http://www.cnblogs.com/cyq1162/archive/2013/05/27/3101834.html
