一个可以支持10亿人民同时在线的 HTTP Server


关于 GigaHttpd 的一次讨论



讨论地点:CSDN VIP俱乐部

讨论人:
普罗通信西安有限公司 架构师 肖舸
GigaHttpd 项目维护人 鲁义明

内容整理:
深圳元征软件 架构师 钟益斌

————————————————————————————————————————————————

深圳元征软件 架构师 钟益斌 2009-03-30 15:01
以下是从《架构师都介绍介绍自己所从事的行业领域吧》帖子中摘过来的,肖兄和鲁兄关于web server的讨论很精彩,放在我那个帖中实在太不合适了,故转贴过来,期望有更多的朋友加入进来探讨,呵呵,我也可以从中学习了:

鲁义明:
在写一个新的开源 Web Server,类似于 Apache, IIS, nginx,目标是可以支持10亿用户同时在线。

肖舸:
你们预设的并发访问量是多少?

鲁义明:
目前的目标,一千台PC,一万个CPU+一万块网卡的情况下,1秒钟内能够回复1亿个HTTP请求。几年内的目标,是1秒钟内回复10亿个。

不过目前还在非常初级的开发阶段 :)

肖舸:
嗯,简单说吧,C10K问题你们咋解决的?
或者,你们根本不用X86架构?

肖舸:
我刚刚完成解决C10k的基本模型,还没有来得及测试,顺便想请教一下你们的思路。能否告知一二?

鲁义明:
呵呵,当然可以,是个开源软件,并且会公布所有的设计文档(都是中文写的)。
http://gigahttpd.sf.net
里面的设计思想的 0.1 版和 0.2 版是主要的设计思路。

鲁义明:
呵呵,我是从网络设备公司出来的,还没经历过 C10K 的问题。
还是 X86 体系,不过会放弃目前的操作系统模式。目前主流的进程/线程都不会再有了。

肖舸:
呃,老鲁,网站看了,说实话有点没看懂。
嗯,你提出来做一个奇大无比的web server系统,这个好像有点值得商榷。
首先我想到了市场,我觉得没有哪个公司开设新网站的时候,会上来就购买或部署一个性能及其强悍的web server,原因很简单,他的客户还没有那么多,没有那么大的收入来支撑他庞大的设备采购费和运营维护费,如果纯粹烧股东的钱,再多的钱都不够烧的。
嗯还有一个问题,就是这么高的设备要求,目前好不好采购是一回事,就算能采购,采购的成本会不会很高,简单算下,4核8G的hp服务器,差不多几万块钱,算5万好了,10核的就算做出来,怎么也得20万,1000台就是差不多两个亿。恐怕没有哪个新公司会先投2亿买设备。
老公司改造可能性也不大,他们目前以apache等现成的软件已经开始run了,人员的培训,公司的技术积累,基本上都是围绕现有平台来的,如果突然改用新平台,不说股东敢不敢做,就算敢做,除了设备采购开销,恐怕员工培训的费用,应用软件改造的费用,恐怕也是天文数字。
那这个东东做出来,市场在哪里,确实不好把握。
嗯还有技术问题,google刚开始,实际上是在旧货市场买二手主板、硬盘,用了差不多50万套,拼了一台超级计算机出来,我的理解,google在超级计算机领域,绝对不是创造者,更多的是一个实践者和粘合剂的作用。因此,我评估google的特长,搜索算法是宗师,但并行计算和超级计算领域,最多是个实践家,他没有去研究某一个单点的突出的计算能力,而是很务实地把研发实力投放到节点之间的无缝备援,快速的查询请求蔓延,容错,平行扩容方面,这样,他以有限的,简陋的计算能力,顺利地搭建出超级计算机,实现自己的搜索平台。我觉得他们的方向比较对,应该学习。
嗯还有一个技术问题,我们知道,http访问决不仅仅是一个访问行为,一个web网站,我的理解内容为王,再彪悍的受访能力,没有内容,没有人来访问,也就没有意义。
我到不是很担心TCP应答受访能力,这个用平行扩容的方法很容易解决,但是,每次访问,肯定会引发后台一系列数据库查询,检索,计算等动作,这个后面的计算能力需求,恐怕远远超过您这1000台设备的计算能力,那就是说,你这个系统要投入实用,应该还有一个后端计算集群在保证。
还有一个内容的疑问,我很怀疑什么应用能保证10亿人都需要用到,如果有这么庞大的市场,恐怕不用我们开源来设计,商业公司早就切入进去了。你的10亿人访问,我的理解还是并发访问,因为顺序访问没有设计这个系统的意义。我确实想不出这个世界上有什么信息服务可以引发10人次的并发访问量。
当然,你也可以说这是多个应用的集合体,那既然是多个应用,为啥还要集中到一个平台上做?各做各的好了,这样还容易得多。
而且,应用多了,可以进一步细分服务,如用户验证,确实可以把多个应用的这个功能使用同一个服务来表现,以实现用户数据库的统一,但这本来就是一个低loading的活动,每个用户每次上线,最多验证一次就好了,这也不需要很高的应答能力。
而其他需要很高响应能力的服务,往往又都是针对性很强的,如线上游戏,IM,照片库等,这些应用各有各的特点,优化方法不尽相同,分开做可能会更容易一点点。而且应用一旦细分,市场必然细分,访问的人群,专注度在提高,但数量会减少,这也进一步限制了对大并发量的需求。
嗯,感觉还有一些疑问,就不一一细说了。
我个人觉得你的这个想法还是很好的,在纯IO计算领域,研究一款高响应能力的接入服务器,还是很有必要的。不过,我建议如果要实现这个目的,可以考虑从如下方面思考:
第一,努力对网络web服务的访问类型取模,采样,精选出有代表意义的大容量数据访问行为,实现算法和数据结构,以及网络拓扑等方面的优化,努力使每次访问的loading降到最低,单点优化的结果会导致受访能力的大幅度提升。
第二,研究系统简洁化平行扩容的方法,就是努力细分服务,使服务功能尽量单一,简单,消除系统瓶颈,把系统的耦合行为编程各个服务器模组之间的搭配关系,实现系统的平行扩容,进而,提供系统近乎无线的扩容能力。在此基础上,降低系统基本配置需求,降低门槛,使大众可采购,可使用,可扩充。
所以,我觉得,您目前提出来的需求,换一个方向,研究一下轻量级http服务,快速业务模型,以及平行扩容方法,也能达到这个目标,而且,其费用和用户门槛都好低很多,建议你思考一下。
以上是我一家之言哈,本人水平有限,仅仅根据经验提一点建议,绝对不是批评,希望能抛砖引玉,帮助你完善设计思路。

鲁义明:
谢谢谢谢!这么深入的关注!

Q.首先我想到了市场,我觉得没有哪个公司开设新网站的时候,会上来就购买或部署一个性能及其强悍的web server,原因很简单,他的客户还没有那么多,没有那么大的收入来支撑他庞大的设备采购费和运营维护费,如果纯粹烧股东的钱,再多的钱都不够烧的。
A.市场方面,最近几年,在大家看到携程和淘宝之类的成功案例后,有不少各行业的朋友想要做网站,要把传统行业的业务转成互联网模式。但是现在运营网站的技术难度不小,成本很好。所以开发GigaHttpd的目标之一,从市场的角度,就是大幅度降低互联网商业的成本。目前的预期是从网站系统的角度,把维护每个注册用户的成本将到每年一分钱。将来社会上就可以有很多很多淘宝之类的网站。

Q.嗯还有一个问题,就是这么高的设备要求,目前好不好采购是一回事,就算能采购,采购的成本会不会很高,简单算下,4核8G的hp服务器,差不多几万块钱,算5万好了,10核的就算做出来,怎么也得20万,1000台就是差不多两个亿。恐怕没有哪个新公司会先投2亿买设备。
A.目前的设计是不采用专用服务器,采用普通的PC,市场上的主流多核CPU,还有多插几块网卡而已,每台PC不超过1万元。最近也有做刀片服务器的朋友在关注这个项目,有可能会出针对GigaHttpd的版本,成本也不会太高。另外,在目前的设计中,用户的应用系统,从最开始,用户很少的时候,是从一个 PC开始增长的,目前的粗略测算,每台PC会支持50万在线用户,所以根据用户数的增长,只要不断增加 PC 就行了,系统和软件方面,不需要做任何改动,形象的说,“插上去一个PC就可以了”,GigaHttpd自动摊开负载均衡。如果GigaHttpd开始投入商业应用,以目前的数据中心的带宽,几十个PC满载运行,就把机房的全部出口带宽都占满了。

Q.老公司改造可能性也不大,他们目前以apache等现成的软件已经开始run了,人员的培训,公司的技术积累,基本上都是围绕现有平台来的,如果突然改用新平台,不说股东敢不敢做,就算敢做,除了设备采购开销,恐怕员工培训的费用,应用软件改造的费用,恐怕也是天文数字。
A.这个是个大问题,照目前的设计来看,以前传统的应用程序都不能在GigaHttpd上面跑。不过另一方面,打算在GigaHttpd上支持PHP之类的应用程序开发界面,让程序员们转换起来方便一些。另外,有朋友在设计GigaHttpd的最初的商业应用,可能会用来做Cache,目前的Cache性能可能不太好。

Q.嗯还有技术问题,google刚开始,实际上是在旧货市场买二手主板、硬盘,用了差不多50万套,拼了一台超级计算机出来,我的理解,google在超级计算机领域,绝对不是创造者,更多的是一个实践者和粘合剂的作用。因此,我评估google的特长,搜索算法是宗师,但并行计算和超级计算领域,最多是个实践家,他没有去研究某一个单点的突出的计算能力,而是很务实地把研发实力投放到节点之间的无缝备援,快速的查询请求蔓延,容错,平行扩容方面,这样,他以有限的,简陋的计算能力,顺利地搭建出超级计算机,实现自己的搜索平台。我觉得他们的方向比较对,应该学习。
A.对,GigaHttpd的设计融合了很多好的思想。没准儿,将来可以把GigaHttpd推荐给Google做他们的WebServer,呵呵。

Q.还有一个技术问题,我们知道,http访问决不仅仅是一个访问行为,一个web网站,我的理解内容为王,再彪悍的受访能力,没有内容,没有人来访问,也就没有意义。
A.这个就不是GigaHttpd要考虑的问题了,现在大家都认为互联网才刚刚开始,估计有很有多疯狂的商业创意与公益创意在策划进行中。

Q.我到不是很担心TCP应答受访能力,这个用平行扩容的方法很容易解决,但是,每次访问,肯定会引发后台一系列数据库查询,检索,计算等动作,这个后面的计算能力需求,恐怕远远超过您这1000台设备的计算能力,那就是说,你这个系统要投入实用,应该还有一个后端计算集群在保证。
A.目前的设计中,传统的文件系统和数据库系统都被放弃了,GigaHttpd设计了新的数据存放及访问方式,以及排序、统计方式。对于大家都很喜欢的 SQL语句,如果应用数据量小到只要一个CPU就可以负担,可能将来会把Sqlite这样的系统移植到GigaHttpd中。另一方面,对于10亿条记录的数据库应用,保存在上万个CPU的几个TB的内存中,则等待数据库高手设计分布式SQL语句及实现。

Q.还有一个内容的疑问,我很怀疑什么应用能保证10亿人都需要用到,如果有这么庞大的市场,恐怕不用我们开源来设计,商业公司早就切入进去了。你的10 亿人访问,我的理解还是并发访问,因为顺序访问没有设计这个系统的意义。我确实想不出这个世界上有什么信息服务可以引发10人次的并发访问量。
A.GigaHttpd将来主要的客户端是手机之类的设备。简单设想一个应用。假设人寿保险公司,给每个人的手机里放一个应用程序,可以侦测每个人的一些健康指标数据,比如气温、湿度、体温、血压、心律、等等,然后实时传回后台服务器端,寿险公司根据这些数据给用户发出健康指导,要求用户遵守,对于不爱护自己身体健康的人,寿险公司可以对其提高保费标准,而对于长期保养身体健康的人,则可以降低其保费标准。按照大家的估计,类似这样的应用将来可能会很多,其实手机上的应用还没开始呢。

Q.当然,你也可以说这是多个应用的集合体,那既然是多个应用,为啥还要集中到一个平台上做?各做各的好了,这样还容易得多。
而且,应用多了,可以进一步细分服务,如用户验证,确实可以把多个应用的这个功能使用同一个服务来表现,以实现用户数据库的统一,但这本来就是一个低loading的活动,每个用户每次上线,最多验证一次就好了,这也不需要很高的应答能力。
A.对,GigaHttpd的设计中有明确的原则,只做一个应用,分解不开的,必须在一个系统中合并计算的,比如几千万人用手机同时玩一个网络RPG游戏,或者观看最新的新闻热点视频。在早期,不建议中小规模的应用采用GigaHttpd,比如100万用户以下的应用,可以采用现有的模式,成本低风险小,很稳定了。

Q.而其他需要很高响应能力的服务,往往又都是针对性很强的,如线上游戏,IM,照片库等,这些应用各有各的特点,优化方法不尽相同,分开做可能会更容易一点点。而且应用一旦细分,市场必然细分,访问的人群,专注度在提高,但数量会减少,这也进一步限制了对大并发量的需求。
A. 嗯,GigaHttpd是长期的开发计划,可能会超过10、20年,主要是针对将来手机上的应用,所以将来用户量应该不是太大问题。

Q.我个人觉得你的这个想法还是很好的,在纯IO计算领域,研究一款高响应能力的接入服务器,还是很有必要的。不过,我建议如果要实现这个目的,可以考虑从如下方面思考:
第一,努力对网络web服务的访问类型取模,采样,精选出有代表意义的大容量数据访问行为,实现算法和数据结构,以及网络拓扑等方面的优化,努力使每次访问的loading降到最低,单点优化的结果会导致受访能力的大幅度提升。
第二,研究系统简洁化平行扩容的方法,就是努力细分服务,使服务功能尽量单一,简单,消除系统瓶颈,把系统的耦合行为编程各个服务器模组之间的搭配关系,实现系统的平行扩容,进而,提供系统近乎无线的扩容能力。在此基础上,降低系统基本配置需求,降低门槛,使大众可采购,可使用,可扩充。
所以,我觉得,您目前提出来的需求,换一个方向,研究一下轻量级http服务,快速业务模型,以及平行扩容方法,也能达到这个目标,而且,其费用和用户门槛都好低很多,建议你思考一下。
A.谢谢!我对并行系统还没有深入的研究,只是想做一个性能很好的Web Server,目前常见的http服务器还都是在内核之上的进程,而我对内核/进程这种体系没太多兴趣了,所以想找一条新路,试试看。

再多说两句,设计GigaHttpd的原因就是因为我们人多手机多,将来会有大规模的应用,所以希望跟大家一起设计一个平台,以后大家需要高性能支持的时候方便一些 :)



肖舸:
嗯,老鲁,你的回答也很有道理,其实东西无所谓好坏,看站在什么角度不同。手机等移动终端,确实有可能会导致访问量大增,这个访问瓶颈,在未来一些时候,很快就会需要解决。
我也需要就这些问题做一点思考。
预祝你的项目成功!








Contact: 鲁义明 (Yiming Lu) - lu.yiming.lu@gmail.com