域名主机域名解析的作用_【架构师入门必知】大型网站技术架构入门知识点大全

我花了两天时间读完了《大型网站技术架构》这本书，并在章节中记录了一些有用的信息。本书可以作为架构师入门的第一本书，因为它很少涉及具体的编程或系统设计，而是从宏观的角度讨论大型网站的架构方案。它可以让您从全局的角度了解架构师的工作和职责。请注意这一点。

一个好的网站架构需要具备以下特点：高可用性、高性能、易扩展、可扩展性和安全性。同时，网站的访问特征符合80/20规则，即：80%的业务访问集中在20%的数据上。网站技术架构的发展要以自身业务发展为驱动。小型网站不应该过多关注高性能网站架构，而应该从业务出发。当业务规模发展到一定程度，就会考虑技术架构的发展。大公司的技术架构只能作为参考，不能盲目跟风。毕竟每个公司的业务流程都是不同的。有时候需要多关注业务层面是否合适，确认业务流程合理后再进行技术架构的扩展。

上图是一个大型网站架构最终的演化结构图。一个网站架构的发展从最初的单机处理到最后的分布式集群、业务拆分和细化，整个过程经历了多次迭代和重构：

初始版本：单机应用（数据库+应用系统+文件系统）

服务分离：多机系统（数据库、应用系统、文件系统各自独立到单独的机器上）

增加缓存：解决DB压力（本地缓存+远程缓存集群，存储80%常用数据）

应用集群：应用服务器使用集群（使用Load来调度集群压力）

读写分离：数据库读写分离、主从热备（读写操作分离、主从双备）

CDN/反向代理：提高静态文件传输效率（缓存在反向代理服务器或CDN加速中）

文件/数据集群：文件系统和数据库使用集群（全部基于服务，对外透明）

独立服务：如微服务架构（每个服务都是独立的，服务有独立的内部结构，服务通过URL进行通信）

常用的大型网站架构模式包括：分层、分段、分布式、集群、缓存、异步（共享队列）、冗余、自动化、安全。其中，分层和分割是后续架构模型的前提。就像互联网的七层模型一样，高耦合、低内聚的独立模块是灵活部署、弹性伸缩的前提。

分层：水平分层、逻辑分层、物理分层。例如，网站结构分为视图层、控制层和数据层（MVC）。各层级之间应保持相对独立的接口，职责单一、明确。

细分：纵向的，如业务的划分。一个大的业务部门又分为几个小的业务部门。每个部门负责自己的业务和技术架构。

分布式：分布式可以将网站架构的所有资源模块化。每个模块都有自己独立的资源池为自己提供计算。同时，分布式还可以增加网站的可用性，增强和提高资源的处理效率。但问题是数据一致性很难保证。

集群：分布式架构后的各个模块将在“单机”模式下被“多机集群”模式取代。这样做的好处是可以提供即时的容灾服务，大大提高计算效率。每个集群通过“Load”透明地对外提供服务。 （*使用集群时，请注意用户等信息的状态保存不要与应用服务器放在一起）

缓存：主要包括CDN、反向代理、分布式缓存和本地缓存。使用缓存有两个先决条件。首先是数据访问热点不均衡，热点数据放入缓存。二是数据在一定时间内有效，不会很快过期。

异步（共享队列）：这里我将异步改为“共享队列”。模块化的业务组件不存在任何功能耦合，即组件之间没有直接的功能顺序。所有资源都放入共享队列中并由每个组件处理。已处理的资源仍将在队列中。每个组件只需要负责队列中它可以处理的资源。同时，“共享队列”还可以作为“压力容器”，承载高并发访问时来不及处理的资源，防止资源阻塞导致服务器宕机，影响用户体验。

冗余：即服务器一定程度的冗余运行和数据冗余备份。除了档案的定期备份和冷备份外，还需要将数据实时同步到从库，实现热备份。

自动化：安全级别的自动化部署、自动化代码管理、自动化安全检测、自动化监控和报警、自动化故障转移（将故障机器从集群中隔离）、自动化故障恢复、自动化降级（通过关闭一些不重要的服务来保证系统负载） ），自动化资源分配。

安全：加密、验证码、防攻击、风控。

高性能网站架构：下面我们主要关注如何从多个方面进行“高性能网站架构”。性能优化小到重构一行代码，大到重新架构一个服务器集群。如何通过各种数据指标监控网站的实时表现？只有找出网站的性能“弱点”，并以此为目标进行迭代优化，网站架构才能逐渐达到高性能水平。

1. 网站性能测试

网站的性能指标可以是开发者客观的性能分析数据，也可以是测试指标。它也可以是主观的最终用户体验。一般来说，我们用以下几个指标来衡量一个网站的性能水平：响应时间、并发数、吞吐量、性能计数器。响应时间是指从发送请求到收到响应并解析成相应的可视化结果所花费的时间；并发数是指系统可以同时处理的请求数量。吞吐量是指系统单位时间内能够处理的请求数量。常用的单位有TPS（每秒事务数）、HPS（每秒HTTP请求数）、QPS（每秒数据库查询数）；性能计数器是直观的数据指标，比如当前系统负载、对象和线程数量、CPU/内存使用情况、磁盘和网络IO等。理想的系统负载应该与系统中的CPU数量相对应，因为系统负载指当前排队等待CPU处理的进程数。

常见的测试方法分为：性能测试、负载测试、压力测试和稳定性测试。性能测试用于验证系统在可接受的资源范围内，在一定的压力下是否能够达到预期的性能指标。负载测试用于测试系统资源满载时系统所能达到的最大吞吐量。压力测试就是在超过系统安全负载的情况下继续施加压力，测试直到系统崩溃所需的时间长度。稳定性测试是让系统在一定的压力下运行一段时间，检测系统在不同时间点是否出现资源使用异常的情况，从而推断系统的稳定性。

在性能测试和负载测试中，系统的TPS值会随着压力的增加而不断增加。在压力测试下，由于系统资源已经耗尽，再施加压力只会拖累CPU的性能。因此，此时的系统TPS会随着压力的不断增加而逐渐下降。在所有测试中，系统的响应时间随着压力的增加而逐渐增加。然而，在压力测试中，每对系统施加单位压力，系统的响应时间就会呈指数增长。

对于系统性能优化，需要从一次请求开始，记录请求到达各个关键节点（如代理服务器、负载均衡服务器、应用服务器）的时间，分析哪段时间不合理，进而检测通过分析监控数据位置来解决问题。

2.WEB前端优化

合并资源，将静态资源独立成独立域名（防止污染），浏览器本地缓存，服务器GZip压缩，CDN加速（ISP端），使用反向代理（相当于主机，可以缓存资源，还可以保护内部）网络）等等等。

3.应用服务器优化

应用服务器主要用于处理系统业务。它是整个网站架构的核心，也是最复杂、变化最多的部分。常用的优化方法有：使用分布式缓存（网站优化第一定律：优先使用缓存。缓存不适合频繁修改的数据，不适合无热点访问的数据，容易出现脏读。系统正常运行时不应该依赖缓存系统，初始化时可以先对缓存系统进行“缓存预热”，比如Redis在初始化时会从硬盘读取数据放入内存。日志中发现无法命中缓存的请求数，就会出现“缓存穿透”的情况，高并发的情况下，继续访问系统中不存在的资源。 ，造成渗透问题的一个简单的对策是缓存不存在的数据，比如JBoss和JBoss，当数据发生变化时，JBoss的所有集群机器都会更新。不过这种方式，主机之间没有通信，所以它的线性伸缩不会影响缓存系统的性能），使用共享队列，使用集群，代码优化（使用多线程，线程数为一般与CPU数量成正比，使用无状态对象或者锁来防止一致性问题，复用数据连接、通信连接等资源）

4、存储系统优化

使用SSD硬盘，使用NoSql数据库（因为LSM树的数据更新速度比B+树快），根据需要使用RAID磁盘阵列和HDFS（RAID可以改善磁盘的访问延迟，并在一定程度上增强可用性）但对于大量数据的存储需求，基于并发任务处理的HDFS可能更适合）

高可用网站架构：下面主要从多个方面来阐述如何进行“高可用网站架构”。为了让网站页面完整地呈现在最终用户面前，需要经过很多环节。除了任何一个环节出现问题之外，都可能存在问题。网站页面变得无法访问。网络请求的情况千变万化，“突然”的实时热点访问可能会导致您的网站瘫痪。

1. 可用性测量

我们通常用九的个数来衡量网站的可用性。例如，四个九代表服务的可用率达到 99.99%，这意味着它需要确保只有 0.01% 的时间发生故障而服务不可用。两个9和三个9的意思是一样的。但对于网站整体来说，想要达到4个9甚至5个9的可用性，除了过硬的技术和大量的设备投入外，还需要有好的运气。

一般情况下，为了将网站的可用性指标转化为相应的责任衡量指标并分配给个人或组织，我们一般采用“故障点”对网站单位​​时间故障进行加权计算，然后将责任分配给个人并加上其年度绩效。正在评估中。例如，可以将不同的权重划分为不同级别的故障类型，然后根据相应类型故障的发生时间即可得到该故障的故障评分。

2、高可用整体架构

我们一般将网站架构分为三层：应用层、服务层、数据层。应用层负责业务逻辑处理，服务层提供可复用的服务，数据层负责数据封装和存储。每一层都是相对独立的。 。由于网站的架构资源的原因，硬件故障是最常见的问题。高可用性架构的主要目的是确保服务器在硬件故障时仍然可用。主要手段是数据和服务的冗余备份和故障转移。

位于应用层的服务器通常通过负载均衡（Load）形成集群，对外透明地提供服务，以应对高并发请求。负载均衡通过心跳检测来监控服务器状态。当发现不可用的机器时，会将其从集群中移除，并将该机器的路由设置为不可用。同时，所有请求都会转发到集群中的其他机器。服务层的机器与应用层类似。位于数据层的服务器比较特殊。为了保证数据不丢失，我们需要在数据写入时将数据同步复制到集群中的其他服务器上，以保证数据的一致性和可用性。

3. 高可用的应用程序

由于应用层主要负责业务处理，为了利用集群来提高应用服务的高可用性，我们将应用层设计为无状态服务，即不保存用户的状态信息（如信息）本地在应用程序服务器上。这样做的目的是为了让集群中的所有服务器平等，在负载均衡调度请求时一视同仁。我们将以专门的方式管理用户的状态信息。

由于业务总是有状态的，所以在单机情况下，我们将会话信息交给服务器上的Web容器来管理，但对于集群环境，我们通常采用以下方式处理： 复制（所有应用服务器都是在本地共享同一套会话信息，每个新的会话都会在整个应用集群内部进行复制，仅用于小型集群）、绑定（负载均衡服务器将来自同一IP源的请求绑定到固定的应用服务器上，也称为为“会话粘性”，但不满足高可用的特点）、利用率（将用户的会话信息存储在客户端浏览器中，安全性较低，影响传输性能，且受浏览器限制）、服务器（专用）通过负载平衡调度的集群可以使用分布式缓存/数据库进行包装）。

4.高可用服务

高可用服务必须是独立且可重用的。服务的设计也需要遵循几个原则：分层管理（核心应用和服务优先使用更好的硬件，核心服务和数据需要部署在不同区域的数据中心，低优先级的服务甚至可以隔离，只使用多线程）、超时设置（设置服务的远程调用超时时间，如果一台机器超过指定的响应时间，集群或者负载均衡会重新分配资源）、异步调用（拆分一个完整的业务流程，比如发送一个邮件发送成功等，可以推迟的任务和步骤都在消息队列中异步执行，即采用传统的消费者模型），服务降级（高并发情况下，可以适当关闭不必要的低优先级服务） down）保存系统性能，或者通过随机拒绝服务分散压力），幂等设计（我们无法确定失败的服务请求是否真的失败，为了避免二次调用服务造成“意外”结构，我们需要使服务调用幂等，即一次调用和多次调用效果相同）。

5. 数据高可用

保证数据高可用性的主要手段是数据备份和故障转移。一般来说，为了保证数据的高可用性，我们可能会牺牲另一个指标，即：“数据一致性”。数据高可用一般包括三个指标：“数据持久性”、“数据可用性”和“数据一致性”。根据CAP原则，数据服务存储系统不能同时满足数据一致性（）、数据可用性（）和分区容错性（）。数据一致性意味着所有应用程序都可以访问相同的数据，可用性意味着任何应用程序都可以随时读写数据，分区容错性意味着系统可以跨网络分区线性扩展。由于A、P这两个指标比C更重要，既然我们已经放弃了数据的强一致性，那么我们可以选择在不影响用户体验的情况下保证数据用户的一致性。

常用的数据备份方法分为热备份和冷备份。冷备份是一种古老而有效的数据保护方法。它主要通过定期将数据复制到存储介质并物理归档来保护数据。缺点是无法保证数据的最终一致性（最弱的一致性，系统经过一段时间的自我恢复和修正后最终达到一致性），并且数据备份时需要停机。热备份是一种实时备份数据保护方式，分为异步热备份和同步热备份。同时，对于关系数据库来说，热备机制的Slave同步机制也可以通过读写分离来提高数据库性能。

故障转移一般通过心跳检测或者应用程序的访问失败报告来通知。当控制中心收到故障报告后，会通过心跳检测再次确认。如果确认失败，该机器将被路由到其他可用的机器。

6、高可用的软件质量保证

例如，当我们发布新版本的软件时，我们必须注意不要影响原来在线运行的服务。因此，我们一般通过发布脚本的方式，一次关闭一部分集群机器，进行软件更新，然后启用。然后关闭机器的另一部分并重复上述过程。软件发布前需要进行“预发布”，即先发布到在线集群中一台只能内网访问、但使用在线数据的机器上，通过后再发布到线上内部测试。优越的。

同时，对于大型网站的软件发布，我们可以采用“灰度发布”的方式，即在一段时间内只发布在线集群中的一部分机器。观察一段时间没有问题后，我们就可以逐步释放集群中的其他机器。我们在进行“灰度发布”的同时，甚至可以进行“AB测试”，以新发布的机器作为对照组，检查新旧软件的用户反馈。

另一方面，网站也需要全天候实时监控。例如，监控服务器日志、客户端日志、运行数据报告（缓存命中率、平均响应延迟等）。该设置应该自动检测系统警报并向机器提供反馈，以便立即实现系统故障转移和优雅降级（在并发和压力较高时自动关闭某些低优先级服务）等操作。