浅谈常规网站是如何从小变大的

DNS策略分析和处理服务是对请求IP进行分析和判断的系统，判断请求来自哪个地域、哪个运营商，然后根据内部的一些库的判断，决定应该返回哪个WebServer的IP。这样，就能尽量保证用户以最快的速度访问到对应的服务。

但是，如果我们有大量的WebServer，那每个Server都要有一个IP，另外，我们要增加一个新机器，又要申请一个IP地址，好像很麻烦，且不可接受。怎么办呢？

第二点，我们需要考虑对于服务器的WebServer的多机化方式。

我们为什么要WebServer多机化？原因就是因为单机的处理性能不行了，我们要提升处理能力。

那WebServer要做哪些事情？Hold住大量用户请求连接；根据URL将请求分流到不同逻辑处理的服务器上；有可能还有一些防攻击策略等。其实这些都是消耗CPU的。

如果我们在WebServer前端增加一层，什么逻辑都不处理，就是利用一定的负载均衡策略将数据包转发给WebServer（比如：工作在IP层，而非TCP层）。那这一层的处理能力跟WebServer比是否是要强悍很多？！这样的话，这一层后面就可以挂载很多的WebServer，而无需增加外网IP。我们暂且叫这一层叫VS（Virtual Server）。这一层服务要求稳定性较高，且处理逻辑要极为简单，同时最好工作在网络模型中较低的层次上。

这样的话，我们就只需要几个这样的VS服务器组，就可以组建大量的WebServer集群。当一个群组出现问题，直接可以通过改变IP绑定，就可以切换到其他服务器组上。

现在这样的VS实现有多种。有靠硬件方式实现的，也有靠软件方式实现的。硬件方式实现的话，成本较高，但稳定性和效率较好。软件方式实现的，则成本较低，但稳定性和效率较硬件方式要低一些。

现在用的比较多的有开源的LVS（Linux Virtual Server），是由我国的一个博士写的，NB！以及根据LVS改写后的一些变种。

另外还有F5 Networks公司出的收费的F5-BIG-IP-GTM等。（注：这个确实没用过，以前在网上看过，写到此处记不清，在百度上搜的。如有错误，敬请雅正）。

好了，通过上述的方式，我们基本实现了WebServer的多机化。

【第九阶段：逻辑关联和层次划分】

在第七阶段的时候，我们提到了几个问题，其中有一个就是业务关联问题。当我们将业务拆分以后，多个业务之间没有了耦合（或者是极弱的耦合），能够独立的运转。这个看起来是多么美妙的事情。但是实际情况真是如此嘛？

这样的业务还真是存在的。比如我们有两个业务blog和image。blog可以上传和展示图片。那image.XXX.com就提供两个HTTP服务，一个是上传的，一个是显示的。这样，blog业务就可以通过简单的URL耦合来实现了图片的这些功能。

但真是所有的情况都是如此的嘛？

我们再看一个例子。比如blog和用户相关的业务。用户可以在blog登录、注销等，blog需要实时判断某一个用户是否登录等。登录和注销两个操作似乎可以通过类似account.XXX.com提供的login和logout这样的URL接口实现。但是每次页面浏览要判断用户是否已经登录了，出于安全性等多方面的考虑，就不好通过URL来提供这样的服务。

那看起来，我们在第七阶段提出的按业务切分的理想情况，在实施的时候，并不是那样的完美。在实际的运行中，耦合是不可避免的。

有了耦合，我的第一反应基本上就是看看是否能够借助设计模式来解决这些的问题。其实呢，设计模式早已经给我们比较好的解决方案（但绝对不是完美的解决方案。俗话说的：没有最好，只有更好！）。在这篇文章的最初已经提到过了，为了增强网站代码的可重用性，我们引入了一些框架，比如：struts、spring、hibernate等等。其实这些框架，基本上是围绕着MVC的原则来设计的。struts、webwork等框架，将视图和逻辑控制分离；spring负责组织业务逻辑的数据；hibernate很好的做了数据访问层的工作，实现了ORM。

那现在我们采用多机分布式的时候，是否可以借鉴这些思想呢？其实也是可以的。