大型网站的架构演进与知识体系

另外，最近很多同学觉得很难理解为什么一个网站需要这么复杂的技术，于是有了写这篇文章的想法。在这篇文章中，他们将阐述一个典型的架构演进过程和普通网站发展成大型网站过程中的知识体系，希望能给想从事互联网行业的同学一些初步的概念，)。请针对文中的错误给出更多的建议，让本文真正达到吸引有价值建议的效果。-[如果！supportLineBreakNewLine] -！--[endif]-架构演进的第一步：webserver和数据库的物理分离从一开始就开始了，所以由于一些想法，在互联网上建立了一个网站。此时，甚至主机也可能被租用。但是，由于我们在本文中只关注架构的演变，因此我们假设此时已经托管了一台主机，并且拥有一定的带宽。这时，因为网站有一定的特点，吸引了一些人来访问，你逐渐发现系统的压力越来越高，而响应速度越来越慢。这时，很明显数据库和应用程序相互作用，数据库也容易出现问题。当数据库出现问题时，应用程序也容易出现问题，所以你进入了第一个进化阶段：应用程序和数据库在物理上是分离的，变成了两台机器。目前没有新的技术要求。但是你发现它确实起作用了，系统恢复到以前的响应速度，支持更高的流量，数据库和应用之间没有相互影响。完成这一步后看系统图：-[如果！-

！--[endif]-这一步涉及到这些知识体系：架构演进的这一步对技术知识体系基本没有要求。-[如果！supportLineBreakNewLine] -！-[endif]-架构演进的第二步：增加页面缓存不会持续太久。随着越来越多的人来访，你会发现响应速度又开始变慢了。找原因，你发现访问数据库的操作太多，导致数据连接竞争激烈，所以响应慢，但是数据库连接不能打开太多，否则对数据库机的压力会很大。因此，考虑到使用缓存机制来减少数据库连接资源的竞争和数据库读取的压力，此时我们可能会首先选择使用squid等类似机制来缓存系统中相对静态的页面(例如，一两天内不会更新的页面)(当然，我们也可以采用让页面静态的方案)，这样就可以在不修改程序的情况下减少对web服务器的压力和数据库连接资源的竞争。好了，于是我们开始用squid制作相对静态的页面。完成这一步后看系统图：-[如果！-

！-[endif]-这一步涉及到这些知识系统：前端页面缓存技术，比如squid。要想用好它，必须彻底掌握squid的实现和缓存失效算法。架构演进的第三步：加入squid作为缓存后，整个系统的速度确实有所提升，webserver的压力也开始下降。但是随着访问量的增加，发现系统又开始变得有点慢了。在品尝了squid这样的动态缓存带来的好处后，我开始怀疑动态页面中相对静态的部分是否可以被缓存。所以我考虑采用ESI这样的页面片段缓存策略，OK，于是开始采用ESI。完成这一步后看系统图：-[如果！-

！-[endif]-这一步涉及这些知识体系：页面片段缓存技术，如ESI等。要想用好，还需要掌握ESI的实现等。架构演进的第四步：数据缓存。再次使用ESI等技术提升系统缓存效果后，系统的压力确实进一步降低，但同样的，随着访问量的增加，系统还是开始变慢。搜索后，可能会发现系统中有一些地方反复获取数据信息，比如获取用户信息。这时，我们开始考虑是否可以缓存这些数据信息，于是我们将这些数据缓存在本地内存中，更改后完全达到了预期。完成这一步后看系统图：-[如果！-

！-[endif]-这一步涉及到这些知识体系：缓存技术，包括Map这样的数据结构、缓存算法、所选框架本身的实现机制等。架构演进的第五步：添加web服务器不会持续很久。研究发现，随着系统访问量的增加，峰值时对webserver机器的压力会上升到更高的水平。这时我们开始考虑增加一个webserver，这也是为了同时解决可用性问题，避免出现单个webserver宕机机器无法使用的情况。做了这些考虑之后，当你决定添加一个web服务器和添加一个web服务器的时候，你会遇到一些问题，比如：1。如何分配对这两台机器的访问？这时候你通常会考虑Apache自己的负载均衡方案或者LVS软件的负载均衡方案；2.如何保持用户会话等状态信息的同步？此时，要考虑的方案包括写入数据库、写入存储器、cookie或同步会话信息等机制。3.如何保持数据缓存信息的同步，比如之前缓存的用户数据等。此时通常考虑的机制是缓存同步或分布式缓存；4.如何让上传文件等类似功能继续正常工作，此时通常考虑的机制是使用共享文件系统或存储等。在解决了这些问题之后，webserver的数量终于增加到了两个，系统也终于恢复到了之前的速度。完成这一步后看系统图：-[如果！-

！-[endif]-这一步涉及这些知识体系：负载均衡技术(包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选技术的实现细节等。)，主备技术(包括但不限于ARP欺骗、linux心跳等。)，状态信息或缓存同步技术(包括但不限于Cookie技术、UDP协议、Status信息广播、所选缓存同步技术的实现细节等。)，文件共享技术(包括但不限于NFS等。)，以及存储技术(包括但不限于存储设备等。).架构演进第六步：子库享受了一段时间系统访问量高速增长的快乐后，发现系统又开始变慢了。这次是什么情况？搜索后发现，部分数据库连接在数据库写入和更新操作中的资源竞争非常激烈，导致系统运行速度变慢。现在应该怎么做？此时可选的方案有数据库聚类和子库策略，有些数据库对聚类的支持不是很好。因此，库拆分将成为一种常见的策略，这意味着修改原始程序。通过一次修改实现库拆分后，达到了目的，系统恢复甚至比以前更快。完成这一步后看系统图：-[如果！-

！--[endif]-这一步涉及到这些知识体系：这一步更需要从业务上进行合理的划分来实现子数据库，在具体的技术细节上没有其他要求；同时，随着数据量的增加和子数据库的进展，数据库的设计、调优和维护都需要做得更好，因此对这些技术提出了很高的要求。架构演进的第七步：表分类、DAL和分布式缓存。随着系统的不断运行，数据量开始大幅增加。这时发现数据库分类后查询还是会有点慢，于是按照数据库分类的思路开始了表分类工作。当然，这将不可避免地需要对程序进行一些修改。也许此时会发现，应用数据库分类和表分类的规则还是有些复杂的。因此，可以增加一个通用框架来实现子数据库和子表的数据访问，这与ebay架构中的DAL相对应。这个进化过程需要相对较长的时间。当然，也有可能在子表完成后才开始这个通用框架。同时，在这个阶段，可以发现以前的缓存同步方案存在问题，因为数据量太大，现在无法将缓存存储在本地。然后在同步的方式上，需要采用分布式缓存方案，所以又是一次考察和煎熬，最终大量的数据缓存被转移到分布式缓存中。完成这一步后看系统图：-[如果！-

！--[endif]-这一步涉及这些知识体系：子表也是业务划分，技术涉及动态哈希算法、一致哈希算法等；DAL涉及到很多复杂的技术，比如数据库连接的管理(超时、异常)、数据库操作的控制(超时、异常)、子数据库和子表的规则封装等。架构进化的第八步：增加更多的网络服务器。完成了数据库和表的划分工作后，数据库的压力降到了比较低的水平，我开始过着每天看着访问量突然增加的幸福生活。突然有一天，我发现进入系统的速度开始变慢。这时我先查了一下数据库，压力正常。在检查了web服务器之后，我发现apache阻止了许多请求。应用服务器对每个请求都很快。似乎是请求数量太高，导致需要排队等待，响应速度慢。这很容易处理。一般来说，这个时候会有一些钱，所以增加了一些网络服务器。在这个添加网络服务器的过程中，可能会有几个挑战：1。Apache的软负载或LVS的软负载无法承担巨大web流量(请求的连接数、网络流量等)的调度。).此时，如果资金允许，解决方案将是购买硬件负载，如F5、Netsclar、Athelon等。如果资金不允许，解决方案将是对应用程序进行逻辑分类，然后将它们分发到不同的软负载集群。2.一些原有的方案如状态信息同步、文件共享等可能存在瓶颈，需要改进。也许在这个时候，会根据情况编制一个符合网站业务需求的分布式文件系统。完成这些任务后，我们开始进入一个看似完美的无限可扩展性时代。当网站流量增加时，解决办法就是不断增加webserver。完成这一步后看系统图：-[如果！-

！--[endif]-这一步涉及到这些知识系统：在这一步，随着机器数量的不断增加，数据量的不断增加，以及对系统可用性的更高要求，需要对所采用的技术有更深入的了解，并根据网站的需求做出更多定制化的产品。架构演进的第九步：数据读写分离和廉价存储方案突然有一天，发现这个完美的时代即将结束，数据库的噩梦再次出现在我们面前。由于添加了太多的webserver，数据库连接的资源仍然不够。此时，它已经分为数据库和表。当我们开始分析数据库的压力情况时，可能会发现数据库的读写比例非常高。这时通常会想到数据读写分离的方案。当然，实现这个方案并不容易。此外，可能会发现存储在数据库中的一些数据是浪费的或者占用了太多的数据库资源。因此，这个阶段可能形成的架构演进是实现数据读写分离，写一些更便宜的存储方案，比如BigTable。完成这一步后看系统图：-[如果！-

！--[endif]-这一步涉及到这些知识体系：数据读写分离需要深入掌握和理解数据库复制、待机等策略，以及自实现技术；廉价存储方案需要深入了解OS文件存储，也需要深入了解文件实现中使用的语言。架构演进的第十步：进入大规模分布式应用时代和廉价服务器场的梦想时代。经过以上漫长而痛苦的过程，完美的时代终于再次迎来。不断增加webserver的数量可以支持越来越高的访问量。对于大型网站来说，知名度无疑是重要的。随着日益普及，各种功能需求开始爆发。这时突然发现，原来部署在web服务器上的web应用已经很大了。当很多团队开始对其进行修改时，确实很不方便，可重用性也相当差。基本上每个团队都做了或多或少重复的事情，部署和维护也相当麻烦，因为在n台机器上复制和启动庞大的应用程序包需要花费大量的时间，出了问题也不容易检查。另一种更糟糕的情况是，应用程序中的一个bug很可能会导致整个站都不可用，还有其他因素，比如调优操作不佳(因为部署在机器上的应用程序必须做所有的事情，根本不可能进行有针对性的调优)。根据这种分析，决定按职责拆分系统，于是一个大型分布式应用诞生了。通常，这一步需要很长时间。因为它会遇到很多挑战：1。拆分成分布式后需要提供高性能稳定的通信框架，需要支持多种不同的通信和远程调用方式；2.拆分一个庞大的应用需要很长时间，需要业务安排和系统依赖控制。3.如何操作和维护这个庞大的分布式应用(依赖管理、健康管理、错误跟踪、调优、监控和报警等)。).经过这一步，系统的架构几乎进入了相对稳定的阶段，同时可以使用大量廉价的机器来支持庞大的访问量和数据量。结合这种架构和从如此多的演进中获得的经验，可以使用各种其他方法来支持不断增加的访问数量。完成这一步后看系统图：-[如果！-

！--[endif]-这一步涉及这些知识系统：这一步涉及的知识系统很多，需要对通信、远程调用、消息机制等有深刻的理解和掌握。并清楚地了解理论、硬件级别、操作系统级别和所采用语言的实现。操作和维护涉及到很多知识系统。大多数情况下，需要掌握分布式并行计算、报表、监控技术、规则和策略等。不需要太多努力就能说出来。整个网站架构的经典演进过程和上面对比的差不多。当然，方案的每一步和演进的步骤可能是不同的。另外，因为网站的业务不同，会有不同的专业技术要求。这个博客更多的是从建筑学的角度来解释进化的过程。当然，这里还有很多技术没有提到，比如数据库聚类、数据挖掘、搜索等等。但在真正的演进过程中，会借助升级硬件配置、网络环境、改造操作系统、CDN镜像等来支持更大的流量。所以在真正的发展过程中会有很多的不同。另一个大型网站需要做的不仅仅是上面这些，还要像安全、运维、运营、服务、存储等。做好一个大型网站真的不容易。写这篇文章更多的是希望引领更大规模网站架构的演进。Ps:最后附上几篇关于LiveJournal架构演进的文章：从LiveJournal的后台开发看大规模网站性能优化方法。此外，从这里：http://www.danga.com/words/,你可以找到更多关于当前LiveJournal网站架构的介绍。