目录
大型网站系统架构演化
一、第一阶段：单体架构 到 第二阶段：垂直架构
二、第三阶段：使用缓存改善网站性能
1、缓存与数据库的数据一致性问题
2、缓存技术对比【MemCache与Redis】
3、Redis分布式存储方案
4、Redis集群切片的常见方式
5、Redis数据分片方案
6、Redis数据类型
7、Redis数据淘汰算法
8、Redis的持久化
9、Redis常见问题
9.1 缓存雪崩
9.2 缓存穿透
9.3 缓存预热
9.5 缓存降级
三、第四阶段：使用服务集群改善网站并发处理能力
1、集群带来的问题
2、负载均衡的引入
3、负载均衡技术
3.1 静态算法（不考虑动态负载）
3.2 动态算法（考虑动态负载）
3.3 硬件负载均衡
3.4 软件负载均衡
4、有状态无状态
4.1 无状态服务
4.2 有状态服务
5、有状态与无状态（Session共享机制）
5.1 携带session的cookie
5.2 服务器间同步session
5.3 将session存入redis
四、第五阶段：数据库读写分离
1、用缓存缓解读库的压力
五、第六阶段：使用反向代理和CDN加速网站响应
1、CDN（内容分发网络）
六、第七阶段：使用分布式文件系统和分布式数据库系统
七、第八阶段：使用NoSQL和搜索引擎
八、第九阶段：业务拆分
九、第十阶段：分布式服务
十、Web应用服务器
十一、响应式Web设计
十二、关于中台
十三、常见架构分析
大型网站系统架构演化
一、第一阶段：单体架构 到 第二阶段：垂直架构
二、第三阶段：使用缓存改善网站性能
分布式缓存：
分布式数据库缓存指的是在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。
常见缓存技术：
MemCache：MemCache是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。MemCache在内存里维护一个统一的巨大的hash表，数据存在该hash表中。
Redis：Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库（支持多种数据结构，如Key-Value、String、Set、List等），并提供多种语言的API。
Squid：Squid是一个高性能的代理缓存服务器，Squid支持FTP、gopher、HTTPS和HTTP协议。
1、缓存与数据库的数据一致性问题
问题：数据库与缓存数据是否有可能不一致？如何解决？
（1）数据读取
操作步骤：
（1）根据Key从缓存读取
（2）若缓存中没有，则根据key在数据库中查找
（3）读取到 “值” 之后，更新缓存
代码示例：
data = queryDataRedis(key);
if (data == null) {
data = queryDataMySQL(key); // 缓存查询不到，从MySQL做查询
if (data != null) {
updateRedis(key,data); // 查询完数据后更新到Redis
}
}
（2）数据写入
没有完全统一的做法，常见操作步骤：
（1）根据key值写数据库
（2）根据key更新缓存【或删除缓存】
代码示例：
updateMySQL()； // 更新MySQL数据库
updateRedis(key，data); // 更新缓存
2、缓存技术对比【MemCache与Redis】
Redis与MemCache能力比较
3、Redis分布式存储方案
4、Redis集群切片的常见方式
5、Redis数据分片方案
（1）范围分片
（2）哈希分片
（3）一致性哈希分片
一致性哈希分片是将数据按照特征值映射到一个首尾相接的hash环上，同时也将节点（按照IP地址或者机器名hash）映射到这个环上。对于数据，从数据在环身上的位置开始，顺时针找到第一个节点即为数据的存储节点。
6、Redis数据类型
7、Redis数据淘汰算法
8、Redis的持久化
Redis的持久化主要有两种方式： RDB和AOF。
RDB：传统数据库中快照的思想。指定时间间隔将数据进行快照存储。
AOF：传统数据库中日志的思想，把每条数据集的命令追加到AOF文件末尾，这样出了问题，可以重新执行AOF文件中的命令来重建数据集。
9、Redis常见问题
9.1 缓存雪崩
解决方案：
（1）使用锁或队列：保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统。
（2）为key设置不同的缓存失效时间：在固定的一个缓存时间的基础上 + 随机一个时间作为缓存失效时间。
（3）二级缓存：设置一个有时间限制的缓存 + 一个无时间限制的缓存。避免大规模访问数据库。
9.2 缓存穿透
查询无数据返回 -> 直接查数据库
解决方案：
（1） 如果查询结果为空，直接设置一个默认值存放到缓存，这样第二次到缓存中获取就有值了。设置一个不超过5分钟的过期时间，以便能正常更新缓存。
（2）设置布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
【布隆过滤器】
布隆过滤器用于快速识别1个元素不在一个集合中。通过一个长二进制向量和一系列随机映射函数来记录与识别某个数据是否在一个集合中。 
【优点】
（1）占用内存小
（2）查询效率高
（3）不需要存储元素本身，在某些对保密要求比较严格的场合有很大优势。
【缺点】
（1）有一定误判率，即存在假阳性，不能准确判断元素是否在集合中。
（2）一般情况下不能从布隆过滤器中删除元素
（3）不能获取元素本身
9.3 缓存预热
系统上线后，将相关需要缓存数据直接加到缓存系统中。
解决方案：
（1）直接写个缓存刷新页面，上线时手工操作。
（2）数据量不大时，可以在项目启动的时候自动进行加载。
（3）定时刷新缓存。
9.4 缓存更新
除Redis系统自带的缓存失效策略，常见采用以下两种：
（1）定时清理过期的缓存。
（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到数据并更新缓存。
9.5 缓存降级
降级的目的是保证核心服务可用，即使是有损的，而且有些服务是无法降级的（如电商的购物流程等）；在进行降级之前要对系统进行梳理，从而梳理出哪些必须保护，哪些可降级。
三、第四阶段：使用服务集群改善网站并发处理能力
1、集群带来的问题
系统演变到这里，将会出现下面几个问题：
（1）用户的请求由谁来转发到具体的应用服务器。（负载均衡）
（2）用户如果每次访问到的服务器不一样，那么如何维护session的一致性。（有状态无状态问题）
2、负载均衡的引入
负载均衡可以放在应用层或传输层工作，在应用层的方法一般有基于特定软件的负载均衡（HTTP重定向）和反向代理负载均衡。在传输层的方法一般有基于DNS的负载均衡和基于NAT的负载均衡。放在传输层效率更高。
应用层负载均衡：
（1）HTTP重定向：HTTP重定向就是应用层的请求转发。用户的请求其实已经到了HTTP重定向负载均衡服务器，服务器根据算法要求用户重定向，用户收到重定向请求后，再次请求真正的集群。
特点：实现简单，但性能较差。
（2）反向代理服务器。在用户的请求到达反向代理服务器时（已经到达网站机房），由反向代理服务器根据算法转发到具体的服务器。常用的apache、nginx都可以充当反向代理服务器。
特点：部署简单，但代理服务器可能成为性能的瓶颈。
传输层负载均衡：
（1）DNS域名解析负载均衡：DNS域名解析负载均衡就是在用户请求DNS服务器时，获取域名对应的IP地址时，DNS服务器直接给出负载均衡后的服务器IP。
特点：效率比HTTP重定向高，减少维护负载均衡服务器成本。但一个应用服务器故障，不能及时通知DNS，而且DNS负载均衡的控制权在域名服务商那里，网站无法做更多的改善和更强大的管理。
（2）基于NAT的负载均衡：基于NAT的负载均衡将一个外部IP地址映射为多个IP地址，对每次连接请求动态地转换为一个内部节点地址。
特点：技术较为成熟，一般在网关位置，可以通过硬件实现。像四层交换机一般就采用了这种技术。
3、负载均衡技术
3.1 静态算法（不考虑动态负载）
（1）轮转算法：轮流将服务请求（任务）调度给不同的节点（即：服务器）。
（2）加权轮转算法：考虑不同节点处理能力的差异。
（3）源地址哈希散列算法：根据请求的源IP地址，作为散列键从静态分配的散列表找出对应的节点。
（4）目标地址哈希散列算法：根据请求目标IP做散列找出对应节点。
（5）随机算法：随机分配，简单，但不可控。
3.2 动态算法（考虑动态负载）
（1）最小连结数算法：新请求分配给当前活动请求数量最少的节点，每个节点处理能力相同的情况下。
（2）加权最小连接数算法：考虑节点处理能力不同，按最小连接数分配。
（3）加权百分比算法：考虑了节点的利用率、硬盘速率、进程个数等，使用利用率来表现剩余处理能力。
3.3 硬件负载均衡
F5
3.4 软件负载均衡
LVS、Nginx、HAproxy
4、有状态无状态
4.1 无状态服务
无状态服务（stateless service）对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息。
4.2 有状态服务
有状态服务（stateful service）则相反，它会在自身保存一些数据，先后的请求是有关联的。
判断以下构件是有状态服务还是无状态服务：
（1）Identification Bean（身份认证构件）：有状态
（2）ResPublish Bean（资源发布构件）：无状态
（3）ResRetrieval Bean（资源检索构件）：无状态
（4）OnlineEdit bean（在线编辑构件）：有状态
（5）Statistics Bean（统计分析构件）：无状态
5、有状态与无状态（Session共享机制）
5.1 携带session的cookie
session是在服务器端创建和维护，cookie是存在用户本地客户端，每个网站都会有对应自己的cookie信息，每次访问请求的时候cookie信息会跟着一并发送给服务器，把session存入cookie中，这样每次请求都会携带session。存在一定安全风险和效率低的问题。
5.2 服务器间同步session
只适合极少数量的服务器，服务器之间双向同步session，当服务器过多时，因为是多对多连接，服务器容易崩溃，可扩展性极差。
5.3 将session存入redis
用redis来存储session，谁使用谁就从redis中获取。
四、第五阶段：数据库读写分离
主从数据库结构特点：
（1）一般一主多从，也可以多主多从。
（2）主库做写操作，从库做读操作。
主从复制步骤：
（1）主库（Master）更新数据完成前，将操作写binlog日志文件。
（2）从库（Salve）打开I/O线程与主库连接，做binlog dump process，并将事件写入中继日志。
（3）从库执行中继日志事件，保持与主库一致。
1、用缓存缓解读库的压力
数据库主从结构单独使用并不能起到很好的作用，所以要跟分布式缓存结合起来一起使用，这里的分布式缓存就是指Redis、MemCache这些东西。
五、第六阶段：使用反向代理和CDN加速网站响应
使用反向代理和CDN加速网站响应：
CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，反向代理部署在网站的中心机房。使用CDN和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。
优点：减轻应用负载压力，异地缓存有效解决不同地方用户访问过慢的问题。
缺点：成本大幅增加，架构进一步复杂，维护难度也进一步增大，静态文件缓存更新失效问题。
1、CDN（内容分发网络）
CDN全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。
六、第七阶段：使用分布式文件系统和分布式数据库系统
分布式文件系统：
分布式文件系统可以被认为是分布式数据存储，即在一组机器中存储和访问大量数据，所有这些数据都显示为一个整体。它们通常与分布式计算并驾齐驱。例如，雅虎因为在超过42000个节点上运行HDFS（Hadoop分布式文件系统）并存储600PB数据而出名。
分布式数据系统：
分布式数据库系统通常使用较小的计算机系统，每台计算机可单独存放在一个地方。每台计算机中都保留DBMS（数据库管理系统）的一份完整副本，或者部分副本，并具有局部的数据库。许多位于不同地点的计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。
七、第八阶段：使用NoSQL和搜索引擎
对于海量数据的查询和分析，我们使用NoSQL数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NoSQL（非关系型数据库）有Membase、MongoDB、HBase、Redis，搜索引擎有Lucene、Solr、Elasticsearch
八、第九阶段：业务拆分
随着业务进一步扩展，应用程序变得非常臃肿，这时我们需要将应用程序进行业务拆分，如百度分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者共享数据库来实现。
九、第十阶段：分布式服务
这时我们发现各个业务应用都会使用到一些基本的业务服务，例如用户服务、订单服务、支付服务、安全服务，这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分布式服务框架搭建分布式服务。阿里的Dubbo是一个不错选择。
十、Web应用服务器
WEB应用服务器可以理解为两层意思：
（1）WEB服务器：其职能较为单一，就是把浏览器发过来的Request请求，返回Html页面。
（2）应用服务器：进行业务逻辑处理。如：EJB、Corba、COM+。
例：
（1）Apache：Web服务器，市场占有率60% 左右。它可以运行在几乎所有Unix、Windows、Linux系统平台上。
（2）IIS：早起Web服务器，目前小规模站点仍有应用。
（3）Tomcat：开源、运行servlet和JSP Web应用软件的基于Java的Web应用软件容器。
（4）JBOSS：JBOSS是基于J2EE的开放源代码的应用服务器。一般与Tomcat或Jetty绑定使用。
（5）WebSphere：一种功能完善、开放的Web应用程序服务器，它是基于JAVA的应用环静，用于建立、部署和管理Internet和Intranet（内联网） Web应用程序。
（6）WebLogic：BEA WebLogic Server是一种多功能、基于标准的web应用服务器，为企业构建自己的应用基础提供了坚实的基础。
（7）Jetty：Jetty是一个开源的servlet容器，它为基于Java的web容器。
十一、响应式Web设计
响应式WEB设计是一种网络页面设计布局，其理念是：集中创建页面的图片排版大小，可以智能地根据用户行为以及使用的设备环境进行相对应的布局。
方法与策略：
（1）采用流式布局和弹性化设计：使用相对单位，设定百分比而非具体指的方式设置页面元素大小。
（2）响应式图片：不仅要同比的缩放图片，还要在小设备上降低自身图片的分辨率。
十二、关于中台
中台是一套结合互联网技术和行业特性，将企业核心能力以共享服务形式沉淀，形成 “大中台、小前台” 的组织和业务机制，供企业快速低成本的对企业架构进行业务创新。中台又可以进一步细分，比如业务中台、数据中台、技术中台等。本质上，都是对企业通用进行业务创新的企业架构能力在不同层面的沉淀，并对外能力开放。
中台的践行者：
Supercell：芬兰游戏巨头，2015年世界游戏前10占5席，员工仅200多人，因使用中台，具有小团队快速开发能力，后被腾讯86亿美金收购。
阿里：2015年参观Supercell，而后推行中台。
【业务中台】：提供重用服务 ，例如学员中心、课程中心之类的开箱即用可重用能力。
【数据中台】：提供数据整合分析能力，帮助企业从数据中学习改进，调整方向。
数据中台必备的4个核心能力：
（1）数据汇聚整合的能力。（2）数据提纯加工的能力
（3）数据服务可视化（4）价值变现方面
【技术中台】：提供技术重用组件能力，帮助解决基础技术平台的复用。如：中间件、分布式存储、AI、负载均衡的基础设施。
【业务中台】和【数据中台】的区分
例：
（1）多个电商渠道使用一个下单服务，一个订单接口同时为多个前台系统提供服务。（业务中台）
（2）多个前台系统，根据一个用户的手机号，获取对应的画像、用户的标签。（数据中台）
（3）将多个支付通道，抽象建立成一个支付API，暴露给前台业务系统。（业务中台）
（4）通过一个订单编号，来获取可能的商品推荐清单，从而做到交叉销售。（数据中台）文章来源：https://www.toymoban.com/news/detail-633538.html
十三、常见架构分析
文章来源地址https://www.toymoban.com/news/detail-633538.html
到了这里，关于系统架构设计师-软件架构设计（7）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
