海边沫沫

相濡以沫,不如相忘于江湖
posts - 42, comments - 462, trackbacks - 0, articles - 0
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理
一个星期前,我写了《我的创业梦想》,文中,我主要写了做什么样的网站、取什么样的域名、怎么宣传等等的想法。很多网友多对我提出了很好的建议,以及鼓励。这一篇,主要是从技术的角度来阐述网站的架构和功能。

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

第一是网站名字的问题,给网站取名字,确实很费了我的一番头脑,因为要做数码照片类的网站,又因为要有一定的意境,又要字母数不太长,还要容易记忆,所以取起来相当的困难。我几乎查遍了“美好的、美丽的、难忘的、生动的”这样的形容词和“生命、生活、时光、记忆、回忆”这样的名词的组合,当然也少不了“照片、图片”这样的词,很可惜,所有能被注册的域名都被注册了。后来,几经波折,终于选定smstars,但是不少人都说SM会让很多人产生邪恶的想法,于是只好推倒重来,我又走上了寻找域名之路。在翻阅众多唐诗宋词、武侠小说和喜欢小说后,又在认真查找中文字典和英语词典后,我终于为我的网站确定了新的名字——“曳影”,曳,是摇曳生姿的意思。我觉得这个名字还可以,不过如果各位网友有板砖的,还是尽管来吧,呵呵。至于英文域名,我申请了两个:
yumdays.com
yumphoto.net
这里的yum,是美好、美妙的意思,是我在翻阅英文词典的时候无意间发现的,beauty和beautiful也是美好的意思,但是凡是带beauty或beautiful的域名基本上都被注册了,而yum使用得却非常的少。由此可见,天道酬勤啊,终于被我找到一个意思比较好而使用比较少的单词了。我在我周围的人群中进行了调查,发现有人喜欢yumdays,因为他们觉得days代表了“岁月、年华”,比较有时空感,也有人喜欢yumphoto,因为他们觉得photo更加直接、好记。于是我干脆两个域名都注册了。为什么后面那个是.net呢?因为yumphoto.com已经被别人注册了。

第二个问题是有人给我泼冷水,有人说我的想法早就有人实现了,也有人说我要实现的功能只是目前诸多大网站的一些很少的子功能,如果不放开思路的话,路走不远。这里我要说一下,我并不是直到2008年才有创业的想法,这种想法早已有之,在我有这种想法的时候,还没有Web2.0的概念,也没有博客和土豆。但是我的路比别人走得慢,现在已经是遍地桃花开,而我却还没有迈出第一步。原因我认为主要有两个,第一个是我在资本方面的积累需要时间,在我刚参加工作时每个月不到1000元的薪水,那是不可能去创业的,作为一个程序员,智商我还有点自信,情商就不敢妄谈了,所以也没有走写企划书捞风险投资这条路(估计想走也走不通);第二个是在技术方面的积累也需要时间,在我刚开始有创业想法的时候,我还没有能力做出一个可以高并发高负载的网站,也没有办法快速开发,我有创业想法的时候Spring、ROR都还没有在国内流行起来,AJAX也没有被发掘出来,开源社区也没有这么火爆(单指国内),而且我学习开发技术也需要时间,因此直到现在创业也还没有起步。
再说网站的功能,我认为初期并不能跟别人比多,功能越花哨,倒闭的风险相反越大。我觉得我们都应该从程序员的角度来考虑这些问题,我不是富翁,我的开发只有亲力亲为,每一行代码都自己写,因此刚开始不能奢望实现太多的功能,应该先实现最基本的功能,让网站尽快上线,成本方面要能省则省。先立而后图强,只要网站做起来了,总能够吸引一些用户,因为现在的需求大,并不是大网站都能把用户一口吞完的。网站要做得专业,这一点博客园的dudu给我做了很好的榜样,大家都可以看出,博客园的功能并不花哨,新功能也是逐步添加的,为什么能成功呢?内容最重要,专业最重要。我之所以选择博客园,就是因为我觉得它粘贴代码的功能太棒了,一下子就给了我很专业的感觉。

好了,说了这么多废话,下面进入正题。要想做一个高并发高负载的网站,架构极其重要。在《程序员》的增刊《实战Web2.0》中,阐述了不少大网站的架构,但是我没有看,因为我这里买不到这本增刊。一下的观点,纯属我自己的意见,欢迎大家斧正。

先来看一下最简单的方法,那就是使用服务器的集群功能,而使用DNS来实现负载平衡,示例图如下:
01.png
使用DNS实现负载平衡是扩展网络应用的最简单的方法,可以为同一个域名指定多个不同的IP地址,每个IP地址代表一个Web服务器,在这些Web服务器之间实现负载均衡,然后再在Web服务器之间和SQL服务器之间分别实现集群。几乎所有的Java EE应用服务器都有配置集群的功能,而最新版本的MySQL,也可以在Unix/Linux系列的服务器上实现集群。

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

这里还有一个问题:图片文件如何保存?这个问题我很早就和朋友探讨过,有的人主张保存到数据库中,有的人主张保存到文件系统中,至今也无法确定哪种方法更好。但是我还是觉得把图片文件保存到文件系统比较好,一是容易备份,二是减轻SQL服务器的负担。

我觉得,要想真正实现服务器的无限向外扩展,集群是肯定无法满足要求的,只能借助于划分。划分有几种方式,一种是将不同的功能放到不同的服务器上,另一种是将不同的用户放到不同的服务器上。我更趋向于使用第二种方法。假设我有三台服务器,它们分别为
www.yumdays.com
www1.yumdays.com
www2.yumdays.com
我可以让user01到user10000分配到www1.yumdays.com上,而user10001到user20000分配到www2.yumdays.com上,每一个用户的添加、删除、修改操作都在自己的所分配服务器上完成,服务器和服务器之间完全不存在Session复制,这也就是《J2EE Development without EJB》中所提到的农场模式。更进一步,我可以让每一个Web服务器只访问它自己的SQL服务器,这样,就进一步实现了数据的划分。那么,怎样将这些用户分配到他自己的服务器上去你?我们需要维护一个索引数据库,而www.yumdays.com则专门负责查询这个索引数据库,然后重定向用户的请求,它的表现就像是一个反向代理服务器。Apache httpd也有反向代理的模块,但是是通过文本来配置的,不是通过查询数据库来实现的,无法满足我们的功能。好在自己写个这样的反向代理服务器也并不困难。

示意图如下:
02.png
这里还有一个好处,就是图片文件可以保存在Web服务器的硬盘上,各Web服务器之间不需要任何的数据复制。如果有人要阅读user01的图文,就会被重定向到www1.yumdays.com上,如果要阅读user10001的,则会被重定向到www2.yumdays.com上,简洁明了。还有,更具服务器的负载状况,并不需要把每一个逻辑服务器都放到单独的物理服务器上。比如说,www1.yumdays.com和www2.yumdays.com的负荷较重,而它们对应的数据库服务器负荷比较轻,则可以将两个数据库服务器放到一个物理服务器上,反之亦然。在我开发和测试的时候,这里的6个逻辑服务器都存在于我的一台电脑上。

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

这三个问题我现在基本上都想到了解决办法。第一个问题的解决办法就是使用加密的Cookie来保存用户的验证信息,当然,这样存在一定的安全隐患,实在不行,就只保存用户的ID吧,让用户在每次回复之前重新输入密码。第二个和第三个问题的解决,都离不开Web Service,比如,每当用户完成一定操作的时候,就把这些操作的相关信息通过Web Service向相关的服务器提交,比如,当位于www1.yumdays.com上的user01回复了位于www2.yumdays.com上的user100001的文章,就调用www1.yumdays.com的Web Service将这个动作保存到user01的数据中,同时调用索引服务器的Web Service,将该文章的回复数、该文章作者的得分等信息提交到索引服务器中,这样,再根据索引服务器中的数据,就可以很方便的统计排名了。

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

另外,就是系统高可用性的问题,以上的示例图中存在很多单点,很容易出现单点故障。解决的办法,就是在每一个单点上面进行小范围的集群。由于用户的图片数据直接保存在Web服务器上,所以在搞Web服务器的集群时有点问题,总不可能在服务器之间复制这样的大数据吧?要解决这个问题,只有引入NFS(网络文件系统)了,一个mount命令就可以让Web服务器认为这些文件就在自己的机器上。至于SAN(存储区域网络),这种东西太高端了,目前我还真的是不懂它。

综合起来,最后的网站架构应该是这样:
03.png

写了这么多,也不知道我的意思表达清楚了没有。欢迎大家批评指教。

Feedback

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-16 19:42 by roydu
请问大哥,smstars是性虐明星的意思吗?你太有创意了!

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-16 19:55 by wangdei
就这个,晕,你还是先看看这个网站再说吧.http://www.yaonba.com

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-16 20:21 by 海边沫沫
@roydu
我的原意,smstars代表so many stars。至于后来那个邪恶的意思是经过别人的提醒我才发现的。你可以看我的上一篇。
由此可见,集思广益实在是太重要了。

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-16 21:10 by sitinspring
yum这个词既在英语的边缘更在汉语拼音的边缘外,楼主不觉得吗?

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-16 21:23 by 海边沫沫
@sitinspring
再边缘也没有办法,要找一个短一点又有意义一点的域名实在太难。

这里可以给大家讲个小插曲,我老婆觉得土豆网很火爆,于是推荐我将域名注册为“萝卜”,可惜啊,我上网一查,“萝卜”早就被注册了。估计换成“地瓜”也没戏。

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-16 22:06 by bromon
1、cluster的主要作用不是用来解决并发问题,而是高可用的问题。集群能够对并发有一定的辅助作用,但是不明显,而且也不是你那样做的。

2、你的集群结构图有很大的问题,看得出来是读过相关的书之后照着画出来的理论模型,不具备实际可操性

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-16 22:07 by bromon
高并发有很多的办法,比cluster高效得多,你的方向完全错了

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-16 22:14 by 海边沫沫
@bromon
多谢指教,如果能更详细一点就好了。

我这里的东西不是照着书画的,是我拍着脑袋想出来的。不具备实际可操作性倒是事实。欢迎批评。

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-17 08:44 by 久城
关注!~.........

# re: 再谈创业之路(高并发高负载的网站架构)[未登录]  回复  更多评论   

2008-01-17 09:12 by dennis
真想干的话应该行动,这样纸上谈兵的东西在实际中肯定有较大出入

# re: 再谈创业之路(高并发高负载的网站架构)[未登录]  回复  更多评论   

2008-01-17 16:01 by Jun
继续关注。。。

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-17 17:58 by no nane
第一:按你的规划,服务器上的投资不小: 8台服务器 X 3万/台 =24万

第二:多台机器之间的身份验证,可考虑换成用cookie来解决。

第三:负载均衡的问题可加一个硬件来解决,F5听说过吗?按功能来做分布,如:blog程序放一台机器上,bbs放另一台,cms放一台....每台做raid1或raid45,挂掉直接热切。

第四:别的方面不清楚,就技术而言,你离创业还远。

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-17 20:34 by 海边沫沫
@no nane

第一,在开发初期,所有的逻辑服务器可以放到一台物理服务器中,投资并不算大,到后期,8台那是远远不够的。

第二,英雄所见是一样的。

第三,F5我要去学习下。不过按功能做划分我不认同,如果单一功能的服务器也超过负载了呢?我的架构是按照用户来划分,我认为这样比较能够容易向外扩展(也就是可以通过添加服务器来获得更高负载)。而RAID和热切换解决的都是高可用性的问题(能不间断的提供服务),解决的不是高并发高负载的问题。

第四,技术不够可以学嘛,我把思路写出来就是为了抛砖引玉。

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-18 14:16 by y45871296
可以做个创业的团队,有经营,有技术。模拟一个公司来运作,虚拟经营嘛。能拉到风险投资,在和到一起来开公司,呵呵!!

# re: 再谈创业之路(高并发高负载的网站架构)[未登录]  回复  更多评论   

2008-01-24 23:20 by 差沙
关于名字,不多于三个字的中文名 -> 直接对应的汉语拼音。(你看有几个国内网站不是?)
这个是必须的,你要是用yum,就连老外记起来都难。唉~~~

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-25 12:43 by mlhorizon
yum==晕?????

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-01-25 14:19 by mlhorizon
像我等英文底薄的就这么按拼音读了

# re: 再谈创业之路(高并发高负载的网站架构)[未登录]  回复  更多评论   

2008-02-02 10:55 by olive
yum多用于口语,好吃的意思。。。

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-02-27 10:43 by 我这样赚钱
去年我也一直在为找一个好项目发愁,后来我无意看到了旺财网这个网站,里面有好多连锁加盟项目,通过考察分析,我发现旺财网里面的项目都比较真实可信,我就在里面选择了一个适合我的餐饮项目,现在做的还不错,你不妨也到这个网站里找找看,或许有适合你的好项目,他们的网址是www.wangcai800.com,你也去看看吧,祝你好运,朋友。

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-03-04 16:47 by changker
1 我与你一样是一个有创业梦想的程序员
2 服务器负载均衡,初期大概也就是这么做的。没必要考虑SMP和Cluster之类的。我支持你的想法 。至少,已经将 数据库和文件存放 做了扩展考虑。只要这两样保证,再怎么折腾服务器,都可以承受。
3 跨站传递用户信息,我也是使用 cookie
4yumphoton 会不会是 郁闷的照片?????????
5你的BLOG写得很细致。不是乱转帖的那种,一定花了不少精力打理吧。佩服

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-03-04 18:03 by 海边沫沫
@changker
呵呵,谢谢支持!

# re: 再谈创业之路(高并发高负载的网站架构)  回复  更多评论   

2008-03-05 13:58 by 秀图
好文章,学到不少有用的东西。。。。。。。。。。。。。

标题  
姓名  
主页
验证码 *  
内容(请不要发表任何与政治相关的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
该文被作者在 2008-01-16 22:55 编辑过