运营一个大型网站需要多少台服务器？首先要明白，这个问题不容易量化，影响一个大型网站所需服务器数量的因素很多。
对于最基础的网站源代码，如果一个技术高超的程序员能实现最好的算法，那么几台服务器就能完成一个拥有数千万并发量的网站。相反，对于低水平的程序员来说，即使几十万台服务器也只能完成几万个并发网站。对于随意需要成百上千台服务器的网站，程序员素质很低，架构师水平极低。
其次，业务量越大，网站的整体结构就会越复杂。
我们看到的网站只是冰山一角，有成千上万的系统支持。服务器的评估需要根据不同业务系统的特点进行分析。
(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万台服务器。
一、如何搭建一个大型网站架构？
首先，什么是大型网站架构呢？
其实大型网站架构的概念对于每一个开发者来说很笼统、很模糊，正如盲人摸象，看到的、了解到的只是很小的一部分，大部分情况下我们只是负责架构中的一小块内容，所以很难清晰地给出具体定义。这就是所谓“不识庐山真面目 只缘身在此山中”的尴尬吧。所以我们要跳出来，站在宏观的角度，从整体到细节实现来认识大型网站架构。
那么从宏观的角度怎么去认识大型网站架构呢？
问题识别：当前什么问题、谁的问题、问题边界；
概念认知：通过分析问题，会产生哪些概念，统一概念认知，达成沟通交流规范；
架构切分：根据概念来解决问题，如何架构切分，产生哪些架构，提出具体解决方案；
在进行分析大型网站架构的演进之路前，首先我们要明确的两个价值观：
核心价值：随网站所需灵活应对；大型网站不是从无到有一步就搭建好一个大型网站，而是能够伴随小型网站业务的渐进发展，慢慢地演化成一个大型网站；
驱动力量：网站的业务发展—业务成就了技术，事业成就了人，而不是相反；
还有，大型网站架构演进必须避免的几个误区：
一味追随大公司的解决方案；
为了技术而技术-->常见问题；
企图用技术解决所有问题：技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决；
二、网站架构体系演进
1、单机时代
草根时期，快速开发网站并上线。当然，通常只是先试水，用户规模也没有形成，经济能力和投入也非常有限。应用程序、数据库、文件等所有资源都集中在一台 Server上，典型案例：基于 LAMP 架构的 PHP 网站；
优点：简单、快速迭代达成业务目标；
缺点：存在单点、谈不上高可用；
技术点：应用设计要保证可扩展；
2、缓存出场
有一定的业务量和用户规模了，想提升网站速度，于是，缓存出场了。
优点：简单有效、方便维护；
缺点：存在单点、谈不上高可用；
技术点：客户端（浏览器）缓存、前端页面缓存、页面片段缓存、本地数据缓存/数据库缓存、远程缓存；
如上图，缓存可以分为：
页面缓存：客户端缓存，减少对网站的访问；
本地缓存：访问速度快，但数据量有限，减少对DB查询；
远程缓存：远程访问，可以集群，因此容量不受限制；
3、数据服务与应用分离
市场反响还不错，用户量每天在增长，数据库疯狂读写，逐渐发现一台服务器快撑不住了。于是，决定把数据服务和APP做分离。
优点：简单有效、方便维护、提高不同Server对硬件资源的利用率；
缺点：存在单点、谈不上高可用；
技术点：文件服务器部署、数据库服务器，扩展数据访问模块；
分离后三台 Server 对硬件资源的需求各不相同：
应用服务器：需要更快更强大的 CPU；
数据库服务器：需要更快的硬盘和更大的内存；
文件服务器：需要更大的硬盘；
4、数据库读写分离
单台数据库也感觉快撑不住了，一般都会尝试做“读写分离”。由于大部分互联网“读多写少”的特性所决定的。Salve的台数，取决于按业务评估的读写比例。
优点：简单有效、降低数据库单台压力；
缺点：读写分离，增加程序难度，架构变复杂，维护难度增加；
技术点：数据库主从同步部署，扩展数据访问模块，实现读写分离；
5、应用服务集群
数据库层面是缓解了，但是应用程序层面也出现了瓶颈，由于访问量增大，加上早期程序员水平有限写的代码也很烂，人员流动性也大，很难去维护和优化。所以，很常用的办法还是“堆机器”。
优点：增加服务器和HA机制，系统性能及可用性得到保证；
缺点：应用之间缓存、Session一致性问题；
技术点：负载均衡；
通过集群解决高并发、海量数据问题的常用手段，实现系统的可伸缩性。通过负载均衡调度器，可将用户访问分发到集群中的某台 Server 上，应用服务器的负载压力不再成为整个网站的瓶颈。
6、集中式缓存、Session集中存储
加机器谁都会加，关键是加完之后得有效果，加完之后可能会引发一些问题。例如非常常见的：集群应用之间页面输出缓存和本地缓存一致性的问题，Session保存的问题......。
优点：应用之间缓存、Session一致，存储无限制，可以扩展；
缺点：不如本地缓存访问快，缓存服务器、Session服务器等仍存在单点问题；
技术点：缓存服务器部署、Session集中存储方案；
7、动静分离
动静分离也是提高网站响应速度的一种常用方式。将动态请求与静态请求分离开，尽量减少对应用服务器的压力。同时，可以再进一步对静态请求，进行缓存，以加快响应速度。可以需要开发人员配合（把静态资源放独立站点下），也可以不需要开发人员配合（利用7层反向代理来处理，根据后缀名等信息来判断资源类型）。
优点：减轻应用负载压力，针对静态文件缓存；
缺点：静态文件缓存更新失效问题；
技术点：动静分离、静态文件缓存方案；
8、反向代理和CDN加速网站响应
使用反向代理和CDN加速网站响应：CDN 和反向代理的基本原理都是缓存，区别在于：
CDN部署在网络提供商的机房；
反向代理则部署在网站的中心机房；
使用 CDN 和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。
优点：减轻应用负载压力，异地缓存有效解决不同地方用户访问过慢的问题；
缺点：成本大幅增加，架构进一步复杂化，也维护难度进一步增大，静态文件缓存更新失效问题；
技术点：CDN、反向代理方案；
9、使用NoSQL和搜索引擎
到这里，已经基本做到了DB层面和应用层面的横向扩展了，可以开始关注一些其它方面，例如：站内搜索的精准度，对DB的依赖，开始引入全文索引、NoSQL。
NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。
优点：降低DB依赖；
缺点：单点问题，谈不上高可用；
技术点：NoSQL、搜索引擎、分布式；
到目前为止，一个能够承载日均百万级访问量的中型网站架构基本介绍完了。
10、如何保证高可用
在做扩展满足了基本的性能需求后，我们会逐渐关注“可用性”（也就是我们通常听别人吹牛时说的SLA、几个9）。如何保证真正“高可用”，也是个难题。
对关键应用/服务，做集群冗余负载，这也是保证高可用比较常用的手段：
文件系统、数据库系统集群；
静态内容服务器集群；
CDN服务器集群；
反向代理服务器集群；
负载均衡调度器集群；
分布式NoSQL服务器集群；
搜索引擎服务器集群；
分布式缓存服务器集群；
分布式Session服务器集群；
优点：集群负载，保证高可用；
缺点：数据一致性、数据有状态问题；
技术点：负载调度器、集群方案；
