web_架构

一个星期前，我写了《我的创业梦想》，文中，我主要写了做什么样的网站、取什么样的域名、怎么宣传等等的想法。

很多网友多对我提出了很好的建议，以及鼓励。

这一篇，主要是从技术的角度来阐述网站的架构和功能。

在开始技术性的讨论之前，还要说一下前文没有解决的问题。

第一是网站名字的问题，给网站取名字，确实很费了我的一番头脑，因为要做数码照片类的网站，又因为要有一定的意境，又要字母数不太长，还要容易记忆，所以取起来相当的困难。

我几乎查遍了“美好的、美丽的、难忘的、生动的”这样的形容词和“生命、生活、时光、记忆、回忆”这样的名词的组合，当然也少不了“照片、图片”这样的词，很可惜，所有能被注册的域名都被注册了。

后来，几经波折，终于选定smstars，但是不少人都说SM会让很多人产生邪恶的想法，于是只好推倒重来，我又走上了寻找域名之路。

在翻阅众多唐诗宋词、武侠小说和喜欢小说后，又在认真查找中文字典和英语词典后，我终于为我的网站确定了新的名字——“曳影”，曳，是摇曳生姿的意思。

我觉得这个名字还可以，不过如果各位网友有板砖的，还是尽管来吧，呵呵。

至于英文域名，我申请了两个：
这里的yum，是美好、美妙的意思，是我在翻阅英文词典的时候无意间发现的，beauty 和beautiful也是美好的意思，但是凡是带beauty或beautiful的域名基本上都被注册了，而yum使用得却非常的少。

由此可见，天道酬勤啊，终于被我找到一个意思比较好而使用比较少的单词了。

我在我周围的人群中进行了调查，发现有人喜欢yumdays，因为他们觉得days代表了“岁月、年华”，比较有时空感，也有人喜欢yumphoto，因为他们觉得photo更加直接、好记。

于是我干脆两个域名都注册了。

为什么后面那个是.net 呢？因为已经被别人注册了。

第二个问题是有人给我泼冷水，有人说我的想法早就有人实现了，也有人说我要实现的功能只是目前诸多大网站的一些很少的子功能，如果不放开思路的话，路走不远。

这里我要说一下，我并不是直到2008年才有创业的想法，这种想法早已有之，在我有这种想法的时候，还没有Web2.0的概念，也没有博客和土豆。

但是我的路比别人走得慢，现在已经是遍地桃花开，而我却还没有迈出第一步。

原因我认为主要有两个，第一个是我在资本方面的积累需要时间，在我刚参加工作时每个月不到1000元的薪水，那是不可能去创业的，作为一个程序员，智商我还有点自信，情商就不敢妄谈了，所以也没有走写企划书捞风险投资这条路（估计想走也走不通）；第二个是在技术方面的积累也需要时间，在我刚开始有创业想法的时候，我还没有能力做出一个可以高并发高负载的网站，也没有办法快速开发，我有创业想法的时候Spring、ROR都还没有在国内流行起来，AJAX也没有被发掘出来，开源社区也没有这么火爆（单指国内），而且我学习开发技术也需要时间，因此直到现在创业也还没有起步。

再说网站的功能，我认为初期并不能跟别人比多，功能越花哨，倒闭的风险相反越大。

我觉得我们都应该从程序员的角度来考虑这些问题，我不是富翁，我的开发只有亲力亲为，每一行代码都自己写，因此刚开始不能奢望实现太多的功能，应该先实现最基本的功能，让网站尽快上线，成本方面要能省则省。

先立而后图强，只要网站做起来了，总能够吸引一些用户，因为现在的需求大，并不是大网站都能把用户一口吞完的。

网站要做得专业，这一点博客园的dudu给我做了很好的榜样，大家都可以看出，博客园的功能并不花哨，新功能也是逐步添加的，为什么能成功呢？内容最重要，专业最重要。

我之所以选择博客园，就是因为我觉得它粘贴代码的功能太棒了，一下子就给了我很专业的感觉。

好了，说了这么多废话，下面进入正题。

要想做一个高并发高负载的网站，架构极其重要。

在《程序员》的增刊《实战Web2.0》中，阐述了不少大网站的架构，但是我没有看，因为我这里买不到这本增刊。

一下的观点，纯属我自己的意见，欢迎大家斧正。

先来看一下最简单的方法，那就是使用服务器的集群功能，而使用DNS来实现负载平衡，示例图如下：
使用DNS实现负载平衡是扩展网络应用的最简单的方法，可以为同一个域名指定多个不同的IP地址，每个IP地址代表一个Web服务器，在这些Web服务器之间实现负载均衡，然后再在Web服务器之间和SQL服务器之间分别实现集群。

几乎所有的Java EE 应用服务器都有配置集群的功能，而最新版本的MySQL，也可以在Unix/Linux系列的服务器上实现集群。

然而，集群的致命缺点是显而易见的，那就是服务器和服务器之间必须得保持数据的同步，Web服务器之间要复制Session状态，数据库服务器之间要复制数据，因此是不可能无限扩展的，当用户数量增加时，性能会急剧下降。

这里还有一个问题：图片文件如何保存？这个问题我很早就和朋友探讨过，有的人主张保存到数据库中，有的人主张保存到文件系统中，至今也无法确定哪种方法更好。

但是我还是觉得把图片文件保存到文件系统比较好，一是容易备份，二是减轻SQL服务器的负担。

我觉得，要想真正实现服务器的无限向外扩展，集群是肯定无法满足要求的，只能借助于划分。

划分有几种方式，一种是将不同的功能放到不同的服务器上，另一种是将不同的用户放到不同的服务器上。

我更趋向于使用第二种方法。

假设我有三台
服务器，它们分别为
我可以让user01到user10000分配到上，而
user10001到user20000分配到上，每一个用户的添加、删除、修改操作都在自己的所分配服务器上完成，服务器和服务器之间完全不存在Session复制，这也就是《J2EE Development without EJB》中所提到的农场模式。

更进一步，我可以让每一个Web服务器只访问它自己的SQL服务器，这样，就进一步实现了数据的划分。

那么，怎样将这些用户分配到他自己的服务器上去你？我们需要维护一个索引数据库，而则专门负责查询这个索引数据库，然后重定向用户的请求，它的表现就像是一个反向代理服务器。

Apache httpd也有反向代理的模块，但是是通过文本来配置的，不是通过查询数据库来实现的，无法满足我们的功能。

好在自己写个这样的反向代理服务器也并不困难。

示意图如下：
这里还有一个好处，就是图片文件可以保存在Web服务器的硬盘上，各Web服务器之间不需要任何的数据复制。

如果有人要阅读user01的图文，就会被重定向到
上，如果要阅读user10001的，则会被重定向到
上，简洁明了。

还有，更具服务器的负载状况，并不需要把每一个逻辑服务器都放到单独的物理服务器上。

比如说，和
的负荷较重，而它们对应的数据库服务器负荷比较轻，则可以将两个数据库服务器放到一个物理服务器上，反之亦然。

在我开发和测试的时候，这里的6
个逻辑服务器都存在于我的一台电脑上。

做完了这样的划分，下面要解决的问题来了？
1、如何在不同的服务器之间传递用户的验证信息？为什么会有这个问题呢，我们考虑一下这样的场景，user01在上登录了，然后他阅读了位于
上的user100001的文章，这个时候，他要回复该文章，那么如何标记他的身份呢？
2、如果位于上的user01回复了位于 上的user100001的文章，这个时候，回复的数据肯定要保存在 所对应的SQL服务器中，那么有一天，当user01想要知道他回复了哪些文章时，如何获得他想要的统计信息？
3、如何给用户提供一些统计信息，如用户排名、最新被回复的文章、24小时内最热门的文章等等。

因为各服务器之间完全独立，所以要想获得这样的统计信息，算法是相当复杂的。

这三个问题我现在基本上都想到了解决办法。

第一个问题的解决办法就是使用加密的Cookie来保存用户的验证信息，当然，这样存在一定的安全隐患，实在不行，就只保存用户的ID吧，让用户在每次回复之前重新输入密码。

第二个和第三个问题的解决，都离不开Web Service，比如，每当用户完成一定操作的时候，就把这些操作的相关信息通过Web Service向相关的服务器提交，比如，当位于上的user01回复了位于上的user100001的文章，就调用
的Web Service将这个动作保存到user01的数据中，同时调用索引服务器的Web Service，将该文章的回复数、该文章作者的得分等信息提交到索引服务器中，这样，再根据索引服务器中的数据，就可以很方便的统计排名了。

这么做了以后，很快就会担心索引服务器是否能够胜任这么多的重任，不过考虑到索引服务器不保存任何数据，可以多搞一些做负载均衡吗。

这个很简单。

另外，就是系统高可用性的问题，以上的示例图中存在很多单点，很容易出现单点故障。

解决的办法，就是在每一个单点上面进行小范围的集群。

由于用户的图片数据直接保存在Web服务器上，所以在搞Web服务器的集群时有点问题，总不可能在服务器之间复制这样的大数据吧？要解决这个问题，只有引入NFS（网络文件系统）了，一个mount命令就可以让Web服务器认为这些文件就在自己的机器上。

至于SAN（存储区域网络），这种东西太高端了，目前我还真的是不懂它。

综合起来，最后的网站架构应该是这样：。