运营一个大型网站需要多少台服务器?首先要明白,这个问题不容易量化,影响一个大型网站所需服务器数量的因素很多。
对于最基础的网站源代码,如果一个技术高超的程序员能实现最好的算法,那么几台服务器就能完成一个拥有数千万并发量的网站。相反,对于低水平的程序员来说,即使几十万台服务器也只能完成几万个并发网站。对于随意需要成百上千台服务器的网站,程序员素质很低,架构师水平极低。
其次,业务量越大,网站的整体结构就会越复杂。
我们看到的网站只是冰山一角,有成千上万的系统支持。服务器的评估需要根据不同业务系统的特点进行分析。
(1) 新闻等服务不复杂的普通网站,交互容易,以展示为主,所以即使PV很大,也不会需要很多机器。单台NGINX服务器可以处理静态页面,可以达到几千甚至几万QPS(当然这只是一个理论值,考虑到页面大小和宽带等因素是达不到的)。
(2) 业务复杂的系统,如携程, 京东, 淘宝等。复杂的用户交互、存储、支付、第三方沟通等。再加上保证系统稳定性和支持容灾,将会成倍增加机器的需求。分析系统,对比业务复杂度,然后对比机器数量更有可比性。
此外,机器配置也有好有坏,新服务器的性能可能是旧机器的几倍甚至十倍。
再者,什么样的网站才算大?
假设2M带宽,它可以在线承载10,000个IP。网页大概60K,一般人的等待耐心是3到5秒。按3秒计算,每个网页占用的带宽约为20K/S2M=2048K2048/20=103。如果是5秒计算,200个人可以同时触发。如果页面文件很小,以此类推。用2M带宽支持300人在线基本没问题。如果每秒300人可以同时触发,那么每分钟就有1.8万人,低至每秒10人。它每分钟还能载600人。按照一般20分钟SESSION故障计算,它也有12000人的承载能力。这种网站可以同时承受1000W人在线,基本可以算是中型网站。如新浪, 雅虎,头条、腾讯等。可以算是大型网站。像官网这样的中小企业都是小企业。
任何一个大型网站都是经历用户积累,然后成长的。
只有一台服务器对多台服务器才能支持网站的现有数据、用户和页面请求。大型网站(如淘宝, 京东,等)的系统架构。)不具备高性能、高可用性、安全性等完整特征。
它总是随着用户的增加和业务功能的扩展而不断进化和完善。在这个过程中,开发模式、技术架构、设计思路也发生了很大的变化,甚至技术人员也从几个人发展到一个部门甚至一条产品线。
所以成熟的系统架构是随着业务的拓展而完善的,不是一蹴而就的;不同业务特性的系统会有自己的侧重点。
例如,在淘宝,需要解决搜索、下单和支付海量商品信息的问题。例如,在腾讯,需要解决数亿用户的实时消息传输问题,而在百度,则需要处理大量的搜索请求。他们都有自己的业务特点和不同的系统架构。
1.如果一个网站访问量小,比如一个小公司的小论坛,可能只有几个人同时在线,稳定性和安全性要求相对较低,那么配置差的服务器就足够了,数据库和应用服务器都在上面;
2.再大一点,考虑到数据库服务器和应用服务器的分离,每个服务器都设置好了,可以再增加一个服务器,把静态请求和动态请求分开;
3.当一个应用服务在高峰期举步维艰,严重影响访问质量时,可以考虑增加一个应用服务器进行负载均衡,分散压力的同时提高稳定性。如果一个应用服务器宕机,还有一个应用服务器响应请求(前提是可以完成负载均衡,所有请求都会交给另一个);
4.如果安全要求高,就不能有数据丢失,尤其是涉及到钱的问题,数据库需要备份,那么数据库主从都可以做,主机停机时会自动切换到从机;
5.如果访问量持续增加,大量数据被频繁读取,相对较少被写入,这部分数据可以分离出来缓存到专门的服务器,比如Memcache和Redis缓存服务器,可以大大减轻数据库读写的压力。这是一种非常有效的解压方法;
6.如果部署N个缓存服务器后数据库仍然有压力,可以考虑读取数据库的写分李,一个主服务器写,N个从服务器读。当然,你必须做好数据同步;
7.如果网站有大量图片或文件需要管理,则需要添加图片服务器或文件系统服务器。这些服务器通常是分布式应用,比如Hadoop,可以使用N个服务器进行部署;
8.如果瞬时流量极大,请求数量达到一定数量级,后台服务还是很难的,我们对实时响应有一般要求,可以增加N个消息队列服务器进行缓冲;
9.然后是上述服务器的大规模集群。它可以大到n。有些巨头有几十万甚至几百万台服务器。几年前,谷歌有250万台服务器。
首先,什么是大型网站架构呢?
其实大型网站架构的概念对于每一个开发者来说很笼统、很模糊,正如盲人摸象,看到的、了解到的只是很小的一部分,大部分情况下我们只是负责架构中的一小块内容,所以很难清晰地给出具体定义。这就是所谓“不识庐山真面目 只缘身在此山中”的尴尬吧。所以我们要跳出来,站在宏观的角度,从整体到细节实现来认识大型网站架构。
那么从宏观的角度怎么去认识大型网站架构呢?
问题识别:当前什么问题、谁的问题、问题边界;
概念认知:通过分析问题,会产生哪些概念,统一概念认知,达成沟通交流规范;
架构切分:根据概念来解决问题,如何架构切分,产生哪些架构,提出具体解决方案;
在进行分析大型网站架构的演进之路前,首先我们要明确的两个价值观:
核心价值:随网站所需灵活应对;大型网站不是从无到有一步就搭建好一个大型网站,而是能够伴随小型网站业务的渐进发展,慢慢地演化成一个大型网站;
驱动力量:网站的业务发展—业务成就了技术,事业成就了人,而不是相反;
还有,大型网站架构演进必须避免的几个误区:
一味追随大公司的解决方案;
为了技术而技术-->常见问题;
企图用技术解决所有问题:技术是用来解决业务问题的,而业务的问题,也可以通过业务的手段去解决;
草根时期,快速开发网站并上线。当然,通常只是先试水,用户规模也没有形成,经济能力和投入也非常有限。应用程序、数据库、文件等所有资源都集中在一台 Server上,典型案例:基于 LAMP 架构的 PHP 网站;
优点:简单、快速迭代达成业务目标;
缺点:存在单点、谈不上高可用;
技术点:应用设计要保证可扩展;
有一定的业务量和用户规模了,想提升网站速度,于是,缓存出场了。
优点:简单有效、方便维护;
缺点:存在单点、谈不上高可用;
技术点:客户端(浏览器)缓存、前端页面缓存、页面片段缓存、本地数据缓存/数据库缓存、远程缓存;
如上图,缓存可以分为:
页面缓存:客户端缓存,减少对网站的访问;
本地缓存:访问速度快,但数据量有限,减少对DB查询;
远程缓存:远程访问,可以集群,因此容量不受限制;
市场反响还不错,用户量每天在增长,数据库疯狂读写,逐渐发现一台服务器快撑不住了。于是,决定把数据服务和APP做分离。
优点:简单有效、方便维护、提高不同Server对硬件资源的利用率;
缺点:存在单点、谈不上高可用;
技术点:文件服务器部署、数据库服务器,扩展数据访问模块;
分离后三台 Server 对硬件资源的需求各不相同:
应用服务器:需要更快更强大的 CPU;
数据库服务器:需要更快的硬盘和更大的内存;
文件服务器:需要更大的硬盘;
单台数据库也感觉快撑不住了,一般都会尝试做“读写分离”。由于大部分互联网“读多写少”的特性所决定的。Salve的台数,取决于按业务评估的读写比例。
优点:简单有效、降低数据库单台压力;
缺点:读写分离,增加程序难度,架构变复杂,维护难度增加;
技术点:数据库主从同步部署,扩展数据访问模块,实现读写分离;
数据库层面是缓解了,但是应用程序层面也出现了瓶颈,由于访问量增大,加上早期程序员水平有限写的代码也很烂,人员流动性也大,很难去维护和优化。所以,很常用的办法还是“堆机器”。
优点:增加服务器和HA机制,系统性能及可用性得到保证;
缺点:应用之间缓存、Session一致性问题;
技术点:负载均衡;
通过集群解决高并发、海量数据问题的常用手段,实现系统的可伸缩性。通过负载均衡调度器,可将用户访问分发到集群中的某台 Server 上,应用服务器的负载压力不再成为整个网站的瓶颈。
加机器谁都会加,关键是加完之后得有效果,加完之后可能会引发一些问题。例如非常常见的:集群应用之间页面输出缓存和本地缓存一致性的问题,Session保存的问题......。
优点:应用之间缓存、Session一致,存储无限制,可以扩展;
缺点:不如本地缓存访问快,缓存服务器、Session服务器等仍存在单点问题;
技术点:缓存服务器部署、Session集中存储方案;
动静分离也是提高网站响应速度的一种常用方式。将动态请求与静态请求分离开,尽量减少对应用服务器的压力。同时,可以再进一步对静态请求,进行缓存,以加快响应速度。可以需要开发人员配合(把静态资源放独立站点下),也可以不需要开发人员配合(利用7层反向代理来处理,根据后缀名等信息来判断资源类型)。
优点:减轻应用负载压力,针对静态文件缓存;
缺点:静态文件缓存更新失效问题;
技术点:动静分离、静态文件缓存方案;
使用反向代理和CDN加速网站响应:CDN 和反向代理的基本原理都是缓存,区别在于:
CDN部署在网络提供商的机房;
反向代理则部署在网站的中心机房;
使用 CDN 和反向代理的目的都是尽早返回数据给用户,一方面加快用户访问速度,另一方面也减轻后端服务器的负载压力。
优点:减轻应用负载压力,异地缓存有效解决不同地方用户访问过慢的问题;
缺点:成本大幅增加,架构进一步复杂化,也维护难度进一步增大,静态文件缓存更新失效问题;
技术点:CDN、反向代理方案;
到这里,已经基本做到了DB层面和应用层面的横向扩展了,可以开始关注一些其它方面,例如:站内搜索的精准度,对DB的依赖,开始引入全文索引、NoSQL。
NoSQL和搜索引擎都是源自互联网的技术手段,对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。
优点:降低DB依赖;
缺点:单点问题,谈不上高可用;
技术点:NoSQL、搜索引擎、分布式;
到目前为止,一个能够承载日均百万级访问量的中型网站架构基本介绍完了。
在做扩展满足了基本的性能需求后,我们会逐渐关注“可用性”(也就是我们通常听别人吹牛时说的SLA、几个9)。如何保证真正“高可用”,也是个难题。
对关键应用/服务,做集群冗余负载,这也是保证高可用比较常用的手段:
文件系统、数据库系统集群;
静态内容服务器集群;
CDN服务器集群;
反向代理服务器集群;
负载均衡调度器集群;
分布式NoSQL服务器集群;
搜索引擎服务器集群;
分布式缓存服务器集群;
分布式Session服务器集群;
优点:集群负载,保证高可用;
缺点:数据一致性、数据有状态问题;
技术点:负载调度器、集群方案;
截止目前为止,都没有怎么去改动应用程序的架构,或者说通俗点,都不怎么需要大面积的修改代码。
如果上面那些手段都用光了,还是支撑不住怎么办?不停的加机器也不是办法啊?
随着业务越来越复杂,网站的功能越来越多,虽然部署层面是采用的集群,但是应用程序架构层面还是“集中式”的,这样会导致很多耦合,不便于开发、维护,而且容易“一荣俱损”。所以,通常会把网站拆分出不同的子站点来单独宿主。
通过分而治之的手段将整个网站业务分成不同的产品线,如首页、商铺、订单、卖家、买家等拆分成不同的产品线,分归不同的业务团队负责。各个应用之间可以通过建立一个超链接建立关系,也可以通过消息队列进行数据分发。
优点:降低耦合、分压;
缺点:应用架构复杂;
技术点:业务抽取拆分;
应用都拆了,由于单个数据库的连接,QPS,TPS,I/O处理能力都非常有限,DB层面也可以去做垂直分库操作。
优点:降低DB耦合、分压DB;
缺点:数据访问模块复杂;
技术点:业务抽取拆分;
拆分应用和DB之后,其实还是会有很多问题。不同的站点,里面可能会有相同逻辑和功能的代码。当然,对于一些基础的功能我们可以封装DLL或者Jar包去到处提供引用,但是这种强依赖也很容易造成一些问题(版本问题、依赖关系等处理起来非常麻烦)。
既然每一个应用系统都需要执行许多相通的业务操作,比如用户管理、商品管理等,那么可以将这些共用的业务提取出来,独立部署。这样,传说中的SOA的价值就得到体现了。
优点:服务统一管理,提供重用度;
缺点:应用架构更复杂;
技术点:业务抽取拆分、服务化技术方案;
应用、服务之间还是会出现一些依赖问题,这时候,高吞吐量的解耦利器出现了。
优点:提高吞吐量、应用、服务之间解耦;
缺点:存在消息消费延迟问题;
技术点:消息队列技术方案;
最后,再介绍一个大型互联网公司都用的绝技--分库分表。个人经验,不是业务发展和各方面非常迫切,不要轻易走这一步。
因为分库分表谁都会干,关键是拆完之后怎么办。目前,市面上还没有完全开源免费的方案,能让你一劳永逸地解决数据库拆分问题。
分库分表:
横向拆分;
纵向拆分;
分布式数据库访问层;
数据库中间件(代理);
上面讲述了在网站业务发展的不同阶段,会面临不同的问题,针对不同的问题,会选择不同的架构。大型网站架构就是在不同阶段时解决不同问题的过程中慢慢演进来的。
最后几句话,送给有缘的你:
一切以解决业务目标为首要任务;
没有以业务为目标的任何架构、技术,都是毫无意义的耍流氓;
再牛逼的架构、再牛逼的技术,不能够解决业务的问题,你也只能算是会架构、会技术的工匠,而不能算是真正意义上的架构师;
业务成就了技术,平台成就了人,事业成就了人,而不是相反;
在选择服务器的时候,很多站长认为虚拟空间就够了,但实际上并非如此。当一个网站的流量不断完善的时候,对web服务器的配置要求也会随之增加。当一个网站的流量数以万计时,虚拟服务器基本不适合使用。建设大型网站应该使用什么样的配置?
对于电商网站来说,每天都有大量的用户访问和购买,所以服务器需要处理大量的数据请求,所以对于电商网站的CPU和内存的标准会更高。
对于视频网站来说,除了用户的访问请求和下载数据之外,还需要配置大硬盘和大带宽,才能有效保证用户在观看时不会卡壳。
对于大型网站,无论是视频网站、门户企业网站还是电商小票,在租用服务器时,都需要考虑基本的配置标准,比如CPU、硬盘、内存、带宽、硬防御。CPU要8核以上,内存视频网站不低于16G。硬盘至少1T,独占带宽100M会更好。
当然,这里推荐的只是正规大型网站所需的配置条件。如果您是易受攻击的行业类型,还应该考虑服务器防御。