大型网站系统架构

上一期《互联网架构设计：高性能的前端》讲述了设计互联网高性能前端架构的基本方法，本篇文章将阐述一下如何设计高性能的后端服务。

先简略回顾一下。对于互联网产品的高性能架构设计通常包括以下几个大方面：

1）Web浏览器高性能设计

2）App客户端高性能设计

3）高性能的网络和硬件

4）后台服务高性能设计

后端服务一般指用户直接看到的远程服务，涉及到网络硬件、逻辑计算、通信协议和数据存储等部分。下面我们将着重介绍高性能后台服务的设计方法和策略。

1、高性能的网络和硬件

网络硬件是提供实现高性能服务的先决条件，如果网络硬件失败，再优秀的团队也是“巧妇难为无米之炊”。互联网产品在网络硬件方面经常需要使用的高性能方案有如下几种：

1）CDN加速技术。CDN加速将网站的内容缓存在网络边缘（离用户接入网络最近的地方），然后在用户访问网站内容的时候，通过调度系统将用户的请求路由或者引导到离用户接入网络最近或者访问效果最佳的缓存服务器上，由该缓存服务器为用户提供内容服务；相对于直接访问源站，这种方式缩短了用户和内容之间的网络距离，从而达到加速的效果。

2）足够的带宽。带宽应该满足在网站峰值的情况还能足够快速的使用，所以网络带宽应该大于峰值流量 = 峰值QPS * 平均请求大小。只有在保证带宽的情况才能实现高性能服务。

3）服务器性能。服务器性能主要从CPU、内存和磁盘三个方面来考虑，CPU核心数量能尽量多点，内存大小最好大一点，利用到磁盘存储的话SSD会优于机械磁盘。

4）硬件负载均衡设备。对于有条件的团队可以采购硬件负载均衡设备，加强后台服务负载均衡的能力，比如F5。

2、后台服务高性能设计

后台服务的高性能设计是互联网产品高性能架构设计中最重要的一环，对服务整体性能起到决定性的作用。我们来看看设计高性能后台服务的方法：

1）分布式缓存。缓存的本质是通过key-value形式的Hash表提升读写速度，一般情况是O(1)的读写速度。读写量比较高，变化量不大的数据比较适合使用缓存。业内比较成熟的分布式缓存系统有redis/memcache。

一般的缓存设计架构如下：用户第一次请求应用程序时，通过存储服务直接读取数据，然后将数据存储到缓存系统去，用户第二次请求的时候就直接从缓存系统读取，从而提升读取速度。

对于分布式缓存系统可以Set化部署，比如商品数据缓存到Set1，用户数据缓存到Set2，或者一类用户的数据缓存到Set1，另一类的用户缓存到Set2，如下图：

此外，也可以按集群化部署，每一个缓存服务存储的数据都是对等的，可以对外提供同等的服务，所以外部请求需要负载均衡到不同有缓存服务器，如下图：

Set化部署的目的主要在于将不同类型的数据路由到不同的地方，好处就是可以减少不同业务数据的耦合，可以针对不同业务进行不同的优化，从而提升整体性能。集群式部署的目的在于，提高缓存系统的对外服务能力，上层业务的路由策略简单灵活，扩缩容比较容易。

2）服务分层

在经典的三层（接入层、逻辑层和存储层）后台服务架构中，三层的划分的原则就是同层次的系统专注处理自己的事情。接入层专注于处理前端和后台服务的接入连通、安全认证和数据转发。逻辑层专注于处理不同业务的无状态逻辑服务。存储层专注于处理业务数据的存储。这样分层的好处在于各个层次能够依据业务特点专注于自己的事情，提高系统复用性，降低业务间的耦合性。在中小型网站中三层架构的典型实现是Nginx（接入层）、Apache Web（逻辑层）、Mysql/Redis（存储层）。

3）操作异步化

目前大型系统中普遍消息队列来将调用异步化，不仅可以提升系统性能还可以提升系统的扩展性。对于大量的数据库写请求，对于数据库的压力很大，同时也会造成数据库响应不及时。可以考虑使用消息队列，数据库的写请求可以直接写入到消息队列，然后通过多线程或多进程从消息队列中读取数据慢慢写入到数据库。消息队列服务器的处理速度会远远快于数据库，所以用户在写入操作时会感觉到很快的写入速度。

此外，消息队列对于请求不均衡的系统，还具有削峰填谷的作用，将短时间内的高峰请求，逐步平摊到更长的时间里去，从而避免短时间内大量请求压跨系统。

4）服务拆分

服务拆分有多种说法，比如大系统小做，分布式拆分，分层结构以及目前很流行的微服务化。不过服务拆分一般来说有以下原则：

a）高内聚、低耦合： 将耦合性低的业务逻辑划分为不同系统，将聚合性高的业务逻辑划分为同一个系统。

b）单一职责原则：对于一个层次或者一个模块应该保持相对单一的职责，专注于自己的服务。

c）故障隔离：不同系统必须相对独立设计和运行，能够独立处理自己的故障，而不至于影响全局。

d）独立运维和持续交互：对于不同的系统可以随时迭代更新，而不至于影响其他服务。

对于服务拆分主要有纵向拆分和水平拆分两种方法。三层架构就是典型的纵向拆分模式，第2）点有所阐述。对于不同的业务模块，针对业务逻辑和存储服务可以按水平拆分的方法将拆分为不同的系统。比如商品系统逻辑层、订单系统逻辑层、商品系统存储层、订单系统存储层。

5）分布式集群化

分布式集群化是指将不同的业务用集群化的方式部署到不同的机器上去，对于每一个业务都具备大规模集群化的能力，从而提升系统的扩展性和高性能。

对于无状态化的被调服务A，在基于负载均衡的技术下，可以通过集群化部署成倍的提升服务性能，比如A1服务的性能是1万请求每秒，那么部署3台A服务机器，那么A服务的性能就是3万请求每秒了。

6）代码优化

对于IO操作的请求可以采用基于状态机的异步化编程。如下图的请求需要业务系统调用三个接口才能返回响应数据，当业务系统收到请求时，将给该请求分配一个seqid，该seqid在接口响应中也应该原封返回，然后并发三个IO接口的请求包，将该seqid对应的请求上下文保存到timer中，然后去并发处理其他请求，从而极大的提升系统性能。

此外，高性能的编程模型还有多线程模型、多进程模型、多协程模型和事件驱动模型。

对于数据结构的设计可以采用高效的数据结构，比如典型的key-value缓存系统就是基于hash的基本原理来实现的，hash表的查询效率是O(1)，效率极快。

转自原文：https://zhuanlan.zhihu/p/28817489

在大型网站开发和设计过程中，非常需要考虑的问题是网站的并发访问的问题，为此我也通过思考，通过借鉴前辈们设计思想，总结出一些解决方案：

1、尽量将请求的页面静态化

静态化的页面为.html(.htm等)不需要web服务器重新加载项解析，只需要生成一次，以后每次都直接下载到客户端，效率高很多。javaWeb静态化的技术有freemark和Velocity等。

2、将网站系统的web服务器、数据库服务器、图片和文件服务器分开

通过将服务器专业化分工，以提高网站访问速度。因为图片和文件在下载的时候无论是IIS、Apache等服务器都会有很大压力。

3、设置专门的数据缓存服务器

将大量数据放到缓存数据区，在访问量少得时候存入数据，减少连接直接操作数据库的开销。

4、数据库集群、库表散列

大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。

我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。

sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

5、镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

6、负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的高端解决办法。

负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。

（1）、硬件四层交换第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。

第四层交换功能就像是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。“Yahoo中国”当初接近2000台服务器，只使用了三、四台Alteon就搞定了。

(2)、软件四层交换

大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是LinuxVirtualServer，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的强壮性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

对于大型网站来说，前面提到的每个方法可能都会被同时使用到，这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会。有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大。

7、最新：CDN加速技术

什么是CDN？

CDN的全称是内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。

CDN有别于镜像，因为它比镜像更智能，或者可以做这样一个比喻：CDN=更智能的镜像+缓存+流量导流。因而，CDN可以明显提高Internet网络中信息流动的效率。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等问题，提高用户访问网站的响应速度。

CDN的类型特点CDN的实现分为三类：镜像、高速缓存、专线。

镜像站点（MirrorSite），是最常见的，它让内容直接发布，适用于静态和准动态的数据同步。但是购买和维护新服务器的费用较高，还必须在各个地区设置镜像服务器，配备专业技术人员进行管理与维护。对于大型网站来说，更新所用的带宽成本也大大提高了。

高速缓存，成本较低，适用于静态内容。Internet的统计表明，超过80%的用户经常访问的是20%的网站的内容，在这个规律下，缓存服务器可以处理大部分客户的静态请求，而原始的服务器只需处理约20%左右的非缓存请求和动态请求，于是大大加快了客户请求的响应时间，并降低了原始服务器的负载。

CDN服务一般会在全国范围内的关键节点上放置缓存服务器。专线，让用户直接访问数据源，可以实现数据的动态同步。

CDN的实例

举个例子来说，当某用户访问网站时，网站会利用全球负载均衡技术，将用户的访问指向到距离用户最近的正常工作的缓存服务器上，直接响应用户的请求。

当用户访问已经使用了CDN服务的网站时，其解析过程与传统解析方式的最大区别就在于网站的授权域名服务器不是以传统的轮询方式来响应本地DNS的解析请求，而是充分考虑用户发起请求的地点和当时网络的情况，来决定把用户的请求定向到离用户最近同时负载相对较轻的节点缓存服务器上。

通过用户定位算法和服务器健康检测算法综合后的数据，可以将用户的请求就近定向到分布在网络“边缘”的缓存服务器上，保证用户的访问能得到更及时可靠的响应。由于大量的用户访问都由分布在网络边缘的CDN节点缓存服务器直接响应了，这就不仅提高了用户的访问质量，同时有效地降低了源服务器的负载压力。

附：某CDN服务商的服务说明

采用GCDN加速方式

采用了GCDN加速方式以后，系统会在浏览用户和您的服务器之间增加一台GCDN服务器。浏览用户访问您的服务器时，一般静态数据，如图片、多媒体资料等数据将直接从GCDN服务器读取，使得从主服务器上读取静态数据的交换量大大减少。

为VIP型虚拟主机而特加的VPN高速压缩通道，使用高速压缩的电信网通、电信国际（HK）、网通国际（HK）等跨网专线通道，智能多线，自动获取最快路径，极速的动态实时并发响应速度，实现了网站的动态脚本实时同步，对动态网站有一个更加明显的加速效果。

每个网络运营商（电信、网通、铁通、教育网）均有您服务器的GCDN服务器，无论浏览用户是来自何处，GCDN都能让您的服务器展现最快的速度！另外，我们将对您的数据进行实时备份，让您的数据更安全。

java

架构模式

模式： 每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地用该方案而不必做重复工作 。

先来说说常见的网站架构模式。这里没有涉及具体实现过程，只是简单介绍其思想和原理，方便日后有用到再深入了解。

分层

分层是企业应用系统中最常见的一种架构模式，将系统在横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后 通过上层对下层的依赖和调用 组成一个完整的系统。

功能

应用层

负责具体业务和视图展示，如网站首页以及搜索输入和结果展示

服务层

为应用层提供服务支持，如用户管理服务，购物车服务

数据层

提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等

分层架构还可以细分下去 ，比如说应用层可以细分为视图层和业务逻辑层。服务层可以细分为数据接口层和逻辑处理层。

分层结构对网站支持高并发向分布式发展至关重要，所以在网站规模很小的时候就应该采用分层的架构，这样将来网站做大时才能有更好地应对 。

所以说我们在设计一个新项目的架构时，就需要考虑到分层。不能等到日后项目做大了，再重构就耗时耗力了。

分割

上面的分层是将软件在横向方面进行切分，而分割是在纵向方面 对软件进行切分。将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。

比如在应用层，将购物、论坛、搜索、广告分割成不同的应用，由独立的团队负责，部署在不同的服务器上。

在同一个应用内部，如果规模庞大业务负责，会继续进行分割，比如说购物业务，可以分割为机票酒店业务、3C业务、小商品业务等更细小的粒度。

分布式

对于大型网站， 分层和分割的主要目的是为了切分后的模块便于分布式部署 。

利用分布式解决网站高并发的问题的同时，会带来其他问题：

分布式意味着服务调用必须通过网络，这可能对性能造成比较严重的影响；

1) 服务器越多，服务器宕机的概率就越大；

2) 数据的一致性问题，分布式事务难以保证；

3) 开发管理维护困难。

所以说要量力而行，不要为了分布式而分布式。

常用的分布式方案有以下几种：

1) 分布式应用和服务：将分层和分割后的应用和服务模块分布式部署，使不同应用复用共同的服务，便于业务功能扩展。

2) 分布式静态资源：网站的静态资源如js、css、图片等独立分布式部署，并采用独立的域名。减轻应用服务器的负载压力，并通过独立域名加快浏览器并发加载速度。

3) 分布式数据和存储：数据量过大，一台机器无法存储。

4) 分布式计算：后台业务需要处理，包括搜索引擎的索引构建、数据仓库的数据分析统计。通过Hadoop及MapReduce分布式计算框架进行批处理计算

集群

使用分布式已经将切分后的模块独立部署，但是对于用户访问集中的模块，还需要将独立部署的服务器集群化，多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。

即使是访问量很小的分布式应用和服务，也会部署两台服务器构成一个小的集群，目的就是提高系统的可用性 。

缓存

缓存是改善软件性能的第一手段。有以下几种方式：

1) CDN：内容分发网络，部署在距离终端用户最近的网络服务商，在这里缓存网站的一些静态资源，就可以以最快的速度返回给用户。

2) 反向代理：反向代理属于网站前端架构的一部分，部署在网站的前端，当用户请求到达网站的数据中心时，最先访问反向代理服务器，这里缓存网站的静态资源。

3) 本地缓存：在应用服务器本地缓存着热点数据，应用程序可以在本机内存中直接访问数据，而无需访问数据库。

4) 分布式缓存：数据量很大时，除了本地缓存，还需要分布式缓存，将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据

5) 缓存有两个前提条件，一是数据访问热点不均衡，某些数据会被更频繁的访问，这些数据应该放在缓存中；二是数据在某个数据段内有效，不会很快过期，否则缓存的数据就会因为已经失效而产生脏读，影响结果的正确性。

异步

系统解除耦合的重要手段是异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。

在单一服务器内部可以通过多线程共享内存队列的方式实现异步，处在业务操作前面的线程将输出写入到队列，后面的线程从队列中读取数据进行处理；

在分布式系统中，多个服务器集群通过分布式消息队列实现异步 ，分布式消息队列可以看作内存队列的分布式部署。

冗余

要保证在服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份。

数据库除了定期备份，存档保存，实现冷备份外，还需要进行主从分离，实时同步实现热备份 。

自动化

发布对网站是头等大事，发布过程自动化可以有效减少故障。自动化测试，自动化安全监测，自动化部署。自动化监控，自动化报警，自动化失效转移，自动化失效恢复。

如果对你有帮助，请告诉小编，小编会推送更多相关内容呢~

在大型网站技术架构中，涉及到许多的技术，这些技术是具备大型网站架构设计能力的前提和基础，文末有该Java架构师资料原图下载~

计算机基础

操作系统(推荐现代操作系统)编译原理计算机网络互联网协议TCP/IP(推荐《TCP/IP协议族》)HTTP1.1/2.0HTTPSOAauth 2.0REST集合框架（源码）

ListArrayListLinkedListSet：HashSet、TreeSetMap：TreeMap、ConcurrentHashMapQueue：ConcurrentLinkedQueueStackCollection的synchronized等方法工具类

Google guava（推荐）Apache common lang/BeanUtils/Collctions/IOJSONfastjsongsonjackson框架

Spring：IOC、AOP、常用注解SpringMVCMybatisShiroNetty远程调用（RPC）

rmiThriftDubbo（Dubbox）服务器治理，也可以作为微服务gRPC构建

Maven：推荐《Maven实战》Gradle安全

单项散列算法：MD5、SHA对称加密：DES非对称加密：RSA、HTTPSJVM

Java虚拟机（Hotspot实现）类加载机制内存模型GC：回收算法、垃圾收集器调优工具：jstack、jmap、jconsole并发编程

Executor框架Fork/joinhappen-before数据结构：ConcurrentHashMap线程池：参数设置、原理、拒绝策略线程状态Lock/synchronized原子操作类并发工具类：CountDownLatch、Semaphore、CyclicBarrier、ExchangerIO、BIO、AIO、NIO数据

NoSQL：MongoDB

分布式缓存：Memcached、Redis（推荐）

关系数据库

MySQL引擎InnoDB（支持事务）分库分表CobarMycatSQL优化

索引主键索引组合索引explain存储过程SQL注入：使用#而不使用$

事务隔离级别（ACID）

原子性一致性隔离性持久性锁

表锁行锁悲观锁数据库设计

范式

第一范式第二范式第三范式E-R图搜索引擎

Luecene

Solr

ElasticSearch

大数据

HadoopHbaseSparkStorm/JStorm算法与数据结构

数组链表栈队列树二叉树B Tree/B+ Tree红黑树哈希排序

内部排序插入排序直接插入排序希尔排序选择排序简单选择排序堆排序交换排序冒泡排序快速排序归并排序基数排序桶排序外部排序分布式系统

从集中到分布式分布式Session：Session复制、Session绑定、Session服务器（靠谱）分布式缓存：Redis、一致性Hash算法数据库：读写分离、主从热备、分库分表、一致性分布式事务、CAP、BASE、2PC/3PC分布式锁Redisson负载均衡、硬件、F5、软件、LVS、Nginx消息队列：RabbitMQ、ZeroMQ、ActiveMQ、Kafka（推荐）服务化：服务注册与发现、Zookeeper架构微服务Spring BootDubboRPCSOA虚拟化Docker

以上架构师技能(高清原图)：资料获取方式

关注+转发后，私信关键词 【架构师】即可获取！

重要的事情说三遍，转发、转发、转发后再发私信，才可以拿到！

1 架构演化

大型网站的关注指标

高可用

高性能

易扩展

可伸缩

安全

大型网站的特点

高并发，大流量

高可用

海量数据

用户分布广泛，网络情况复杂

安全环境恶劣

需求快速变更，发布频繁

渐进式发展

大型网站架构演化发展过程

初始阶段，多使用LAMP来搭建，All In One即所有资源存放在一台服务器上

应用服务和数据服务分离，有独立的数据库服务器

使用缓存改善网站性能（依据是二八定律：80%的业务访问集中在20%的数据上）

这里需要考虑哪些数据适合缓存

缓存可以是本地缓存，也可以是远程分布式缓存

需要考虑使用合理的缓存策略，防止透传

使用应用服务器集群改善网站的并发处理能力

如果能通过增加一台服务器的方式来改善负载压力，就可以以同样的方式持续增加服务器来不断改善系统性能，从而实现系统的可伸缩性

这里需要考虑使用哪些负载均衡的策略

数据库读写分离

可以利用主流数据库提供的主从热备功能，通过配置两台数据库的主从关系，同时业内也有很多优秀的开源中间件如Atlas

缓存中的数据，如果更新过快，那么会持续刷新缓存，从而降低性能

使用反向代理和CDN加速网络响应

CDN和反向代理的基本原理都是缓存

CDN部署在网络提供商的机房，用户在请求网络服务时，可以从距离自己最近的网络提供商机房获取数据

反向代理部署在网站的中心机房，当用户的请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，那么就将其直接返回给用户

CDN的重点：——《大型网站系统与Java中间件实践》

全局调度

缓存技术

内容分发

带宽优化

使用分布式文件系统和分布式数据库系统

网站常用的数据库拆分手段是业务分库，即将不同业务的数据库部署到不同的物理服务器上

使用NoSQL和搜索引擎

ES

MongoDB

业务拆分，使用分而治之的手段将整个网站业务分成不同的产品线

SOA、服务化

中心化的 gataway方式

消息队列

不同服务访问同一个DB等

这部分十分重要，道理很简单，但是执行起来的效果千差万别。

当下火热的微服务，也是基于这种思想。

技术实现方式也有很多

分布式服务

大型网站架构演化的价值观

网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的。因此对于小型网站来说，最需要做的是位用户提供好的服务来创造价值，得到用户的认可，从而活下去，野蛮生长。

大型网站架构技术的核心价值是随网站所需灵活应对， 它是一个演化的过程

驱动大型网站技术发展的主要力量是网站的业务发展，是业务成就了技术，而不是相反。因此要摒弃为了技术而技术的套路

网站架构设计误区

一味追求大公司的解决方案

为了技术而技术

企图用技术解决所有问题

2 架构模式

分层，这是在横向方向对系统进行切分

分层的挑战在于必须合理规划层次边界和接口

分层包括物理分层和逻辑分层两种

分割，这是在纵向方向对系统进行切分

将不同的功能和服务分割开来，包装秤高内聚低耦合的模块单元

分布式

1） 分布式应用和服务；

2） 分布式静态资源；

3） 分布式数据和存储；

4） 分布式计算；

5） 分布式配置、分布式锁、分布式文件系统。。。

1） 分布式意味着服务调用必须通过网络，需要考虑带宽的影响；

2） 服务器越多，宕机的概率越大

分层和分割的目的在于小模块便于分布式部署

带来的问题：

常用的分布式方案：

集群，即多台服务器部署相同的应用，从而构成一个集群，通过负载均衡设备共同对外提供服务

即使访问量很小的分布式应用和服务，也至少要部署到两台服务器来构成一个小集群，这样可以提高系统的可用性

缓存，即将数据放在距离计算最近的位置以加快处理速度

CDN

反向代理

本地缓存

分布式缓存

异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步进行协作

1） 提高系统可用性；

2） 加快网站响应速度；

3） 消除并发访问高峰

通常需要使用消息队列

带来的好处：

冗余

集群带来的必然结果

安全需求的必然结果

自动化，DevOps思维，尽量减少人工干预

自动化发布

自动化代码管理

自动化测试

自动化安全监测

自动化部署

自动化监控

自动化报警

自动化失效转移、恢复

自动化分配资源

......

安全

3 大型网站核心架构要素

性能

一个性能问题可能会导致网站用户严重流失

衡量性能的指标：响应时间、TPS、系统性能计数器等

可用性

没有网站可以完美的7*24运行

网站高可用结构的前提是必然会出现服务器宕机，儿高可用设计的目标是当服务器宕机时，服务或者应用依然可用

必要的手段是集群，即冗余

伸缩性，即通过不断向集群中加入服务器的手段来环节不断上升的用户并发访问压力和不断增长的数据存储需求

衡量标准：是否可以构建集群；是否可以方便的向集群中添加新的服务器

扩展性，直接关注网站的功能，保证可以快速响应需求变更

衡量标准： 网站增加新的业务产品时，是否对现有业务透明无影响

安全性

衡量标准： 针对现存和潜在的各种攻击和窃密手段，是否可以有效的应对

4 瞬时响应 - 网站的高性能架构

不同视角下的网站性能

用户视角

主要是端到端的感觉

主要通过前段优化的手段来提升用户体验

开发人员视角

主要关注应用程序本身以及相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等

主要优化手段： 使用缓存加速数据读取、使用集群提高吞吐能力、使用异步消息加快请求响应、使用代码优化提升程序性能

运维人员视角

主要关注基础设施性能和资源利用率

主要优化手段： 建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用率

性能测试指标

响应时间，即应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间

并发数，即系统能够同时处理的请求的数目，也反映了系统的负载特性

吞吐量，即单位时间内系统处理的请求数量，体现系统的整理处理能力

性能计数器， 描述服务器或者操作系统性能的一些数据指标

性能测试方法

性能测试，以系统设计初期规划的性能指标为预期目标，对系统不断增压，验证系统在资源可接受范围内，是否能达到性能预期

负载测试，对系统不断的增加并发请求，知道系统的某项或者多项性能指标达到安全临界值

压力测试，超过安全负载的情况下，继续对系统增压，直到系统崩溃或者不能再处理任何请求

稳定性测试，在特定硬件、软件、网络情况下，给系统加载一定压力，是系统运行较长一段时间，来观察系统是否稳定

Web前端优化

浏览器访问优化

减少http请求

使用浏览器缓存

启用压缩

CSS放在页面最上面，JavaScript放在页面最下面

减少Cookie传输

CDN加速

反向代理

应用服务器性能优化

分布式缓存

一般会使用消息队列，带来的额外好处是会削平峰值

1）不同的缓存服务器之间进行通信，例如JBoss Cache；

2）不同缓存服务器之间不进行通信，例如Memcached

缓存从本质上来说，就是一个内存hash表

缓存需要缓存那些读写比很高、很少变化的数据，一般来说读写比在2:1以上时，缓存才有意义

应用程序读取数据时，首先到缓存中读取，如果缓存不存在或者已失效，再访问数据库，同时将新的数据放入缓存

缓存也需要注意缓存热点数据

缓存预热，在新启动的缓存系统中，在启动时就加载热点数据，这样启动后就可以直接使用

缓存穿透， 应用持续大量访问不存在的数据，因为这类数据不存在于缓存中，因此会大量访问数据库，从而降低性能

对于分布式缓存来说，目前有两类：

异步操作

使用集群

代码优化

多线程

1） 将对象设计成无状态对象；

2） 使用局部对象；

3） 并发访问资源时使用锁

需要注意线程安全问题，方法：

资源复用

主要是单例和资源池（对象池）

数据结构，选择合适的算法

垃圾回收

合理设置垃圾回收策略

存储性能优化

机械硬盘 vs 固态硬盘

B+树 vs LSM树

RAID vs HDFS

5 万无一失 - 网站的高可用架构

网站可用性度量

网站不可用时间 = 故障修复时间点 - 故障发现时间点

网站年度可用性指标 = （1 - 网站不可用时间/年度总时间）* 100%

一般以几个9来表示，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟

网站高可用架构的设计目标是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问

网站高可用架构的主要手段：数据和服务的冗余备份以及失效转移，一旦服务器宕机，就将服务切换至其他可用的服务器上。

高可用的应用

无状态应用： 应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等，请求提交到任何一个服务器上，处理的结构都是相同的。

通过负载均衡进行无状态服务的失效转移

负载均衡： 主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上， 以提升整体的负载处理能力

应用服务器集群的Session管理

Session复制

Session绑定

利用Cookie记录Session

Session服务器

高可用的服务

分级管理

核心服务与非核心服务隔离

核心服务优先使用高性能服务器

超时设置

异步调用

必须满足可以使用异步调用方式

服务降级

幂等性设计

服务高可用（高可靠）一直是美团外卖的第一要求，为了提高可用性，做了很多策略，包括并不限于上文提出的各种架构设计方案。

其实造成线上问题的很大一部分原因是由于发版造成的，也体现出了SOP的重要性。

关于降级与依赖隔离，可以考虑采用Hystrix实现自动降级与依赖隔离 。

高可用的数据

数据一旦出现问题，对于网站往往是毁灭性的打击，因此保护网站的数据就是保护企业的命脉。

主要手段：数据备份和失效转移

缓存服务高可用

观点一：缓存服务已经承担了业务中绝大多数的数据读取访问，因此需要同样保证高可用

观点二：缓存服务并不是数据存储服务，出现服务不可用导致数据丢失应从别的手段解决，而不是提高缓存服务本身高可用

缓存服务器集群中单机故障，集群规模较大时，数据丢失比例和数据负载压力影响很小。

CAP原理： 一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Parition Tolerance）这三个条件

数据高可用含义：

副本间数据一致

多个副本可读

同时写入数据副本

1）数据持久性

2）数据可访问性

3）数据一致性

数据一致性分类：

1） 数据强一致；

2） 数据用户一致；

3） 数据最终一致

数据备份

1） 异步热备；

2） 同步热备

冷备的优点是简单和廉价，成本和技术难度较低，缺点是不能保证数据最终一致

热备分为两种：

失效转移

1） 心跳检测（Keepalived、Heartbeat）；

2） 应用程序访问失败报告

失效确认：

访问转移

数据恢复

高可用网站的软件质量保证

网站发布，它的过程和服务器宕机效果箱单，其对系统可用性的影响也 类似

一般采取批量更新的方式进行，不会一次关掉集群中的全部服务器

自动化测试

一般使用Selenium来进行测试

预发布验证

预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的区别是没有配置在负载均衡服务器上，外部用户无法访问

代码控制

主干开发，分支发布

分支开发，主干发布，这是目前使用的主流方式

自动化发布

火车模型：将每个应用的发布过程看做一次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目下车，通过的项目继续坐着火车旅行，直到火车到达终点。

实际中，可能所有项目在途中都下车了，这样火车不得不回到原点，等待�...

架构模式

模式： 每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地用该方案而不必做重复工作 。

先来说说常见的网站架构模式。这里没有涉及具体实现过程，只是简单介绍其思想和原理，方便日后有用到再深入了解。

分层

分层是企业应用系统中最常见的一种架构模式，将系统在横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后 通过上层对下层的依赖和调用 组成一个完整的系统。

功能

应用层

负责具体业务和视图展示，如网站首页以及搜索输入和结果展示

服务层

为应用层提供服务支持，如用户管理服务，购物车服务

数据层

提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等

分层架构还可以细分下去 ，比如说应用层可以细分为视图层和业务逻辑层。服务层可以细分为数据接口层和逻辑处理层。

分层结构对网站支持高并发向分布式发展至关重要，所以在网站规模很小的时候就应该采用分层的架构，这样将来网站做大时才能有更好地应对 。

所以说我们在设计一个新项目的架构时，就需要考虑到分层。不能等到日后项目做大了，再重构就耗时耗力了。

分割

上面的分层是将软件在横向方面进行切分，而分割是在纵向方面 对软件进行切分。将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。

比如在应用层，将购物、论坛、搜索、广告分割成不同的应用，由独立的团队负责，部署在不同的服务器上。

在同一个应用内部，如果规模庞大业务负责，会继续进行分割，比如说购物业务，可以分割为机票酒店业务、3C业务、小商品业务等更细小的粒度。

分布式

对于大型网站， 分层和分割的主要目的是为了切分后的模块便于分布式部署 。

利用分布式解决网站高并发的问题的同时，会带来其他问题：

分布式意味着服务调用必须通过网络，这可能对性能造成比较严重的影响；

1) 服务器越多，服务器宕机的概率就越大；

2) 数据的一致性问题，分布式事务难以保证；

3) 开发管理维护困难。

所以说要量力而行，不要为了分布式而分布式。

常用的分布式方案有以下几种：

1) 分布式应用和服务：将分层和分割后的应用和服务模块分布式部署，使不同应用复用共同的服务，便于业务功能扩展。

2) 分布式静态资源：网站的静态资源如js、css、图片等独立分布式部署，并采用独立的域名。减轻应用服务器的负载压力，并通过独立域名加快浏览器并发加载速度。

3) 分布式数据和存储：数据量过大，一台机器无法存储。

4) 分布式计算：后台业务需要处理，包括搜索引擎的索引构建、数据仓库的数据分析统计。通过Hadoop及MapReduce分布式计算框架进行批处理计算

集群

使用分布式已经将切分后的模块独立部署，但是对于用户访问集中的模块，还需要将独立部署的服务器集群化，多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。

即使是访问量很小的分布式应用和服务，也会部署两台服务器构成一个小的集群，目的就是提高系统的可用性 。

缓存

缓存是改善软件性能的第一手段。有以下几种方式：

1) CDN：内容分发网络，部署在距离终端用户最近的网络服务商，在这里缓存网站的一些静态资源，就可以以最快的速度返回给用户。

2) 反向代理：反向代理属于网站前端架构的一部分，部署在网站的前端，当用户请求到达网站的数据中心时，最先访问反向代理服务器，这里缓存网站的静态资源。

3) 本地缓存：在应用服务器本地缓存着热点数据，应用程序可以在本机内存中直接访问数据，而无需访问数据库。

4) 分布式缓存：数据量很大时，除了本地缓存，还需要分布式缓存，将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据

5) 缓存有两个前提条件，一是数据访问热点不均衡，某些数据会被更频繁的访问，这些数据应该放在缓存中；二是数据在某个数据段内有效，不会很快过期，否则缓存的数据就会因为已经失效而产生脏读，影响结果的正确性。

异步

系统解除耦合的重要手段是异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。

在单一服务器内部可以通过多线程共享内存队列的方式实现异步，处在业务操作前面的线程将输出写入到队列，后面的线程从队列中读取数据进行处理；

在分布式系统中，多个服务器集群通过分布式消息队列实现异步 ，分布式消息队列可以看作内存队列的分布式部署。

冗余

要保证在服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份。

数据库除了定期备份，存档保存，实现冷备份外，还需要进行主从分离，实时同步实现热备份 。

自动化

发布对网站是头等大事，发布过程自动化可以有效减少故障。自动化测试，自动化安全监测，自动化部署。自动化监控，自动化报警，自动化失效转移，自动化失效恢复。

如果对你有帮助，请告诉小编，小编会推送更多相关内容呢~

在大型网站技术架构中，涉及到许多的技术，这些技术是具备大型网站架构设计能力的前提和基础，文末有该Java架构师资料原图下载~

计算机基础

操作系统(推荐现代操作系统)编译原理计算机网络互联网协议TCP/IP(推荐《TCP/IP协议族》)HTTP1.1/2.0HTTPSOAauth 2.0REST集合框架（源码）

ListArrayListLinkedListSet：HashSet、TreeSetMap：TreeMap、ConcurrentHashMapQueue：ConcurrentLinkedQueueStackCollection的synchronized等方法工具类

Google guava（推荐）Apache common lang/BeanUtils/Collctions/IOJSONfastjsongsonjackson框架

Spring：IOC、AOP、常用注解SpringMVCMybatisShiroNetty远程调用（RPC）

rmiThriftDubbo（Dubbox）服务器治理，也可以作为微服务gRPC构建

Maven：推荐《Maven实战》Gradle安全

单项散列算法：MD5、SHA对称加密：DES非对称加密：RSA、HTTPSJVM

Java虚拟机（Hotspot实现）类加载机制内存模型GC：回收算法、垃圾收集器调优工具：jstack、jmap、jconsole并发编程

Executor框架Fork/joinhappen-before数据结构：ConcurrentHashMap线程池：参数设置、原理、拒绝策略线程状态Lock/synchronized原子操作类并发工具类：CountDownLatch、Semaphore、CyclicBarrier、ExchangerIO、BIO、AIO、NIO数据

NoSQL：MongoDB

分布式缓存：Memcached、Redis（推荐）

关系数据库

MySQL引擎InnoDB（支持事务）分库分表CobarMycatSQL优化

索引主键索引组合索引explain存储过程SQL注入：使用#而不使用$

事务隔离级别（ACID）

原子性一致性隔离性持久性锁

表锁行锁悲观锁数据库设计

范式

第一范式第二范式第三范式E-R图搜索引擎

Luecene

Solr

ElasticSearch

大数据

HadoopHbaseSparkStorm/JStorm算法与数据结构

数组链表栈队列树二叉树B Tree/B+ Tree红黑树哈希排序

内部排序插入排序直接插入排序希尔排序选择排序简单选择排序堆排序交换排序冒泡排序快速排序归并排序基数排序桶排序外部排序分布式系统

从集中到分布式分布式Session：Session复制、Session绑定、Session服务器（靠谱）分布式缓存：Redis、一致性Hash算法数据库：读写分离、主从热备、分库分表、一致性分布式事务、CAP、BASE、2PC/3PC分布式锁Redisson负载均衡、硬件、F5、软件、LVS、Nginx消息队列：RabbitMQ、ZeroMQ、ActiveMQ、Kafka（推荐）服务化：服务注册与发现、Zookeeper架构微服务Spring BootDubboRPCSOA虚拟化Docker

以上架构师技能(高清原图)：资料获取方式

关注+转发后，私信关键词 【架构师】即可获取！

重要的事情说三遍，转发、转发、转发后再发私信，才可以拿到！