程序员应该了解大型网站架构的发展历史吗？ 如何有效增加服务器？

上面已经介绍了大型网站的业务需求和一般工作原理，但不能简单地理解为简单地添加服务器就可以将网站变成可以处理大量用户的网站。本节简单介绍了大型网站架构的发展，并描述了大型网站架构如何有效增加服务器数量。您只需了解本节介绍的技术点即可，后续章节将给出更详细的解释。大型网站系统内部比较复杂，一般是各种网站架构的混合体。另外，除了下面提到的动态网页外，其余都是基于B/S架构的网站。随着B/S架构的应用，浏览器运行的网页与处理请求的服务器的接口也分别称为前端和后端。非关系型数据库和关系型数据库的共存无疑是大型网站架构设计的必要组成部分。

大型网站架构开发

上面已经介绍了大型网站的业务需求和一般工作原理，但不能简单地理解为简单地添加服务器就可以将网站变成可以处理大量用户的网站。

通过增加服务器来支持更多的用户是大型网站架构的目的。

本节简单介绍了大型网站架构的发展，并描述了大型网站架构如何有效增加服务器数量。

您只需了解本节介绍的技术点即可，后续章节将给出更详细的解释。

大型网站系统内部比较复杂，一般是各种网站架构的混合体（包括静态网站、动态网站、B/S架构网站等）。

本节介绍的内容将忽略一些细节。 另外，除了下面提到的动态网页外，其余都是基于B/S架构的网站。

说明：软件架构是对软件整体结构和组件的抽象描述，是一个软件的基本思想。 简单来说，架构就是从宏观的角度思考软件如何解决问题。

动态网络时代

动态网站的工作原理在之前动态网站的出现中已经提到过。 服务器收到浏览器的请求后，应用程序对网页资源文件进行处理，然后返回文件。 这里再解释一下，处理后只返回HTML格式的文件，比如JSP、PHP文件。

对于不需要处理的资源文件，如JavaScript脚本文件、CSS样式文件、图片文件、视频文件等，服务器收到请求后会直接返回。 当然，动态网站除了操作数据库之外，还可以调度云计算服务。 动态网站的技术架构如图1.5所示。

图1.5 动态网站技术架构

B/S结构网站的兴起

动态网页在每次请求网页时都不可避免地需要处理所有HTML格式文件（例如JSP和PHP文件）。 这无疑会浪费大量的资源。 如果需要更新网页中的内容，则必须重新加载整个网页，这使得用户体验不太友好，尤其是在网速不好的情况下。

因此，网站更好的方式应该是类似于C/S架构模型（客户端-服务器模型，如桌面软件等），服务器只需要处理客户端关心的数据，并且有不需要做多余的处理。 出于这样的考虑，B/S架构模式（浏览器-服务器模式）应运而生。 服务器接受网页请求时，仍然直接返回HTML文件，而不像静态网站那样进行处理。 当浏览器需要更新部分网页数据时，只需要通过JavaScript脚本向服务器请求自己关心的数据，然后更新网页的某一部分。 B/S架构的网站也常被称为伪静态网站。 大型网站虽然内部结构复杂，可能包括动态网站和静态网站，但一般以B/S架构网站为主。

随着B/S架构的应用，浏览器运行的网页与处理请求的服务器的接口也分别称为前端和后端。 随着Ajax技术的出现，前端和后端的请求方式进一步简化，B/S架构逐渐兴起。 B/S网站技术架构如图1.6所示。

图1.6 B/S网站技术架构

CDN加速网站响应

虽然传统意义上的网页无需安装软件就可以使用，但实际上，每次打开网页时，都需要从服务器下载网页文件（浏览器会有一些文件缓存，但大多数情况下是重新下载的） -下载）。 这些网页文件（如HTML超文本文件、JavaScript脚本文件、CSS样式文件、图片文件和视频文件等）大部分不需要服务器处理。 如果每次都从服务器返回网页文件，显然当大量用户访问时，服务器的压力非常大。 再加上复杂的网络环境，不同地区的用户访问网站的速度差异很大。

因此，对于不需要这些服务器处理的文件，在面对大量的用户访问时，“如何让用户快速打开网站”是一个非常重要的问题。

为了解决这个问题，我们可以添加足够的服务器，并根据用户的地理分布合理分配服务器。 这确实是解决问题的一个办法，但是如果这些服务器完全由网站服务商提供的话，成本会非常高。 然而，许多第三方提供商（例如阿里云、腾讯云等）已经提供了这些服务器。 我们只需在第三方平台配置网站域名和缓存策略即可解决问题。 配置完成后，第三方服务器会自动缓存网页文件，用户可以从最近的服务器获取网页文件，而不用每次请求都积压在网站服务器上。 这样的服务称为CDN（Content Delivery Network，内容交付网络）加速，本网站的技术架构如图1.7所示。

图1.7 CDN加速后的网站技术架构

应用程序和数据分离

网站服务器中有应用程序、资源文件、数据库和云计算服务。 它们对计算机的物理性能都有不同的要求。 例如，资源文件需要更好的硬盘性能，数据库除了硬盘性能之外还需要更好的CPU性能。 如果应用程序、资源文件、数据库、云计算服务都放在一台服务器上，网站就无法有针对性地扩展。

因此，我们需要将应用程序和数据分离，将应用程序、资源文件、数据库和云计算服务部署在专用服务器上。 当用户数量增加时，可以有针对性地添加性能瓶颈的服务器。 应用与数据分离的网站技术架构如图1.8所示。

图1.8 应用与数据分离的网站技术架构

非关系型数据库与关系型数据库共存

从某种程度上来说，网站是围绕数据工作的，网站的业务实际上就是对数据的管理，而数据库一般是整个网站系统的核心。 因此，大型网站架构中数据库的使用非常重要。 数据库一般是指像MySQL、Oracle这样的表状关系数据库。 当然，仅使用关系型数据库就可以满足所有的业务需求，但是存在两个问题：第一，对于查询来说，很多查询请求是相同的，并且在一段时间内查询结果是相同的，而数据库基本上每次都需要重新查找； 其次，由于形式的限制，表形式的关系数据库在处理一些业务场景时能力较弱。 非关系型数据库的出现是为了应对大规模数据采集和多种数据类型等挑战。

对于问题1，关系型数据库虽然也有自己的缓存机制来达到减少检索的目的，但无法根据具体业务定制缓存策略。 Redis等引用键值存储的非关系型数据库可以缓存预计访问量大、更新概率低的数据，可以大大减轻关系型数据库的压力。

对于问题2，在处理海量数据时，使用HBase等列式存储的非关系型数据库的劳动强度较小； 在处理大量、结构不受限制的数据时，使用MongoDB等文档型非关系型数据库的劳动强度较小； 在处理社会关系等复杂数据时，使用Neo4J等图形化非关系数据库相对省力。 需要注意的是，这里的图不是图片，而是图结构。

根据实际情况选择对应的非关系型数据库。 非关系型数据库和关系型数据库的共存无疑是大型网站架构设计的必要组成部分。 图1.9展示了非关系型数据库和关系型数据库共存的网站技术架构。

图1.9 非关系型数据库和关系型数据库共存的网站技术架构

聚类

集群实际上就是我们前面提到的服务器数量的增加。 但单纯增加服务器最多也就是从一个网站变成多个网站，而不是把一个网站变成一个可以容纳更多用户的网站。 为了更好的增加服务器，需要添加一些软件来协调这些具有相同功能的服务器。

下面根据应用与数据分离中提到的大型网站的四个部分（应用、资源文件、数据库、云计算服务）来介绍集群相关技术。

·应用集群：在B/S架构中，应用一般指后端接口。 应用程序的集群需要添加负载均衡服务，以便前端网页请求后端接口时，均匀调度这些应用程序服务器。

·资源文件服务器集群：资源文件服务器集群主要是为了处理前端的下载请求。 虽然CDN加速解决了大部分资源文件服务器的压力，但CDN在一段时间后也会回归资源文件服务器。 当用户的地理分布足够广时，这种压力就不容忽视。 资源文件服务器的集群还需要添加负载均衡服务。

数据库服务器的集群：一般数据库都会提供集群部署方案，可以按照该方案进行部署。

云计算服务的集群：如果您使用的是第三方云计算服务，则集群由第三方平台提供； 如果是自己的云计算服务器，则需要使用RabbitMQ等消息队列作为任务调度中心。

集群网站技术架构如图1.10所示。

图1.10 集群网站技术架构

分布趋势

集群之后，大型网站系统可以通过增加服务器来有效应对大量用户访问的压力。 然而，大型网站系统除了应对大量的用户访问之外，还需要不断扩展业务。 而当业务功能不断扩展时，应用部分就会变得非常复杂和混乱。 为了缓解这部分应用的复杂、混乱的情况，出现了分布式大型网站架构的趋势。

分布式大型网站架构，简单来说，就是将一个庞大的大型网站系统划分为多个独立的子系统和子模块，这些系统和模块通过相互协助完成任务。 从物理意义上来说，分布式大型网站系统将这些子系统部署在不同的服务器上，并让这些应用程序协同完成任务。

例如，上传视频可以获得积分，分布式网站系统会通过视频管理子系统接收上传的视频，然后积分管理子系统会给用户增加积分。 视频管理子系统和信用管理子系统部署在不同的服务器集群中。

分布式网站系统将变得越来越流行。 虽然它们的开发成本较高，但独立的子系统可以独立发布，发现问题时可以单独测试，为后续运维提供了保障。 另外，一个独立的子系统如果具有足够的通用性，还可以被复用，即该子系统可以为其他网站服务，降低新网站系统的开发成本。 分布式网站技术架构如图1.11所示。

图1.11 分布式网站技术架构

微服务

微服务也是近年来的热门话题。 2014年，Martin Fowler和James Lewis共同提出了微服务的概念，定义微服务是由单个应用程序组成的具有轻量级处理流程的小型服务。 多个微服务共同提供网站系统所需的功能。

微服务是分布式网站系统的进一步优化。 简单来说，微服务希望一个大型网站可以由很多完全独立的小服务组成。 这样可以使网站系统运维更清晰，开发更快捷，问题定位更准确。

然而，微服务也存在争议。 在笔者使用微服务经历的两个项目中，最终的效果都不是很好。 除了微服务框架的中间件增加了网站结构的复杂性之外，更重要的是微服务的粒度需要由项目本身来定义，而这种粒度的权衡很难把握。 因此，大多数使用微服务的项目效果并不理想，应用部分变得非常臃肿，微服务之间的调用也非常混乱。

笔者认为，微服务的概念会给大型网站架构带来新的思考，但在目前的状态下，盲目使用微服务框架大多数情况下只会弄巧成拙。 微服务网站的技术架构如图1.12所示。

图1.12 微服务网站技术架构

大型网站架构的未来

目前，大型网站架构的各种技术已经比较成熟，第三方云服务平台（如腾讯云、阿里云）也提供各种基础服务和云计算服务。 然而，从头开始构建一个大型网站仍然很困难。

这样的建设难度恰恰证明了大型网站的架构还没有完全成熟。

微服务概念的引入，虽然其实际应用效果并不理想，但确实给原本被认为成熟的大型网站架构带来了新的思考。 一个比较成熟的大型网站架构应该是由很多独立的模块组成，就像一个巨大的机械设备是由很多现成的零件组装而成的。

大型网站架构仍在发展中，更加标准化的架构将会出现。 那时，大型网站架构将成为标准化的生态环境，开发大型网站时无需考虑那么多技术点。 网站架构主要考虑将现有的哪些子系统模块进行组合。

概括

在了解大型网站的业务演进时，需要了解各种网站类型的应用场景； 在了解大型网站架构的开发时，需要了解大型网站架构可能遇到的问题。 通过了解这些发展历史，相信读者能够对大型网站的架构有一个大概的了解。

当然，仅仅从宏观上了解是不够的，毕竟我们忽略了很多复杂的细节。

然而，我们可以站在巨人的肩膀上。 我们的前辈发现并解决了很多问题，产生了很多技术。 我们可以借鉴别人的经验和以前的技术来解决我们遇到的问题。 有些技术等到需要使用的时候再仔细学习也不晚。

随着发展，大型网站的架构变得越来越复杂。 在进行技术选型和架构决策时，确实需要一些经验才能抓住要点。 我们在虚心学习前人经验的同时，也不能盲目跟风，而是需要根据项目的实际情况做出清醒的选择和冷静的判断。

本文讲解的内容是大型网站架构的开发。 下一篇文章将讲解大型网站架构面临的挑战：大型网站架构的基本问题。 觉得文章不错的朋友可以转发这篇文章关注小编； 感谢您的支持支持！