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