前言:
标题为啥要加个“小”,只因为上一篇文章“
小网站架构优化:从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:项目路径还是原来的项目路径,然后设置新的应用程序池,最终如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/701e11d2f4c45484e4b8a31550c9032e.jpeg)
总结:
一般一个项目大了后,或者逻辑变的复杂后,往往的解决方案就是分解成子项目。
而分解的方案:一般是根据域名,或首页节点目录。
后来思绪了一下,比如目前博客的URL是:xxx.com/cyq1162/admin/...
如果一开始考虑把它设计成:xxx.com/admin/cyq1162/...
这样是不是也就可以轻松的把博客的前后台分离开来。
当然了,分成多个进程,是需要思考,是否有涉及直接的通讯。
文本就介绍到这里了,仅提供一种参考方案。