目录
吞吐（Throughput）vs 并发（Concurrent）
在 docker 中我们有提到 [Docker#1] 专栏前言 | 亿级高并发架构演进之路，
在讲解 redis 之前，我们再对架构 进行进一步的了解，对于 redis 的讲解，难免离不开分布式~
电子商务应用架构演进
概述
本文以“电子商务”应用为例，介绍从一百个到千万级并发情况下服务端的架构演进过程。目的：帮助读者建立对架构演进的整体认知，便于深入学习后续知识。
常见概念
- 应用（Application）/ 系统（System）：完成一系列服务的程序或程序群。
- 模块（Module）/ 组件（Component）：负责特定功能的内聚单元。
- 分布式（Distributed）：系统组件部署在不同服务器上，通过网络通信协作。（物理上
- 集群（Cluster）：多个组件部署在多台服务器上，共同实现特定目标。（逻辑上
- 主（Master）/ 从（Slave）：集群中承担主要或辅助职责的组件。例如: 一个写，多个同步读的模式
- 中间件（Middleware）：不同应用程序间通信的桥梁。与业务无关的更通用的服务（eg. sql,cache,消息队列...
评价指标
- 可用性（Availability）：系统正常提供服务/一年总时长 的时间比例。
例如：平时我们常说的4个9即系统可以提供99.99%的可用性，5个9是99.999%的可用性，以此类推。我们平时只是用高可用（High Availability, HA）这个非量化目标简要表达我们系统的追求。
- 响应时长（Response Time RT）：用户输入到系统响应的时间。
- 吞吐（Throughput）vs 并发（Concurrent）：单位时间内处理的请求数量 vs 同时支持的最大请求数量。
响应时长 和 吞吐 并发 都是衡量服务器性能的标准
架构演进
1 单机架构
- 适用场景：早期用户访问量少，系统简单，无需专业运维团队。
- 架构描述：用户请求通过DNS解析到单机服务器，服务器同时提供应用服务和数据库服务。
- 相关软件：Web服务器（Tomcat、Netty、Nginx、Apache等）、数据库（MySQL、Oracle、PostgreSQL、SQL Server等）。
2 应用数据分离架构
- 适用场景：系统访问量增加，硬件资源接近极限。
- 架构描述：应用服务和数据库服务分离部署，应用服务通过网络访问数据库。
- 优势：最小代价提升系统承载能力。
3 应用服务集群架构
- 适用场景：单台应用服务器无法满足需求。--引入负载均衡
- 方案选择：
-
- 垂直扩展（Scale Up）：购买更高性能的服务器，成本高且提升有限。
- 水平扩展（Scale Out）：增加应用服务器数量，成本相对较低，提升空间大。
- 引入组件：负载均衡（Nginx、HAProxy、LVS、F5等）。
- 流量调度算法：
-
- Round-Robin：公平地将请求分发给不同服务器。
- Weight-Round-Robin：按权重分配请求。
- 一致哈希散列算法：确保同一用户的请求分发到同一服务器。
4 读写分离 / 主从分离架构
- 适用场景：数据库成为系统瓶颈。
- 运用：我们采用的解决办法是这样的，保留一个主要的数据库作为写入数据库，其他的数据库作为从属数据库。从库的所有数据全部来自主库的数据，经过同步后，从库可以维护着与主库一致的数据。
- 优点：然后为了分担数据库的压力，我们可以将写数据请求全部交给主库处理，但读请求分散到各个从库中。由于大部分的系统中，读写请求都是不成比例的，例如100次读1次写，所以只要将读请求由各个从库分担之后，数据库的压力就没有那么大了。
- 问题：当然这个过程不是无代价的，主库到从库的数据同步其实是有时间成本的，但这个问题我们暂时不做进一步探讨。
- 解决方案：保留一个主数据库用于写入，其他从数据库用于读取，通过数据同步保持一致性。
- 相关软件：数据库中间件（MyCat、TDDL、Amoeba、Cobar等）。
5 引入缓存 - 冷热分离架构
- 随着访问量继续增加，发现业务中⼀些数据的读取频率远⼤于其他数据的读取频率。我们把这部 分数据称为热点数据，与之相对应的是冷数据。
- 适用场景：读取频率高的热点数据增加。读取频率高的热点数据增加。
- 解决方案：使用本地缓存和分布式缓存（Memcached、Redis）减少数据库压力。
- 面临问题：缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等。
6 垂直分库
随着业务的数据量增大，大量数据存储在同一个库中已经显得有些力不从心了，所以可以按照业务，将数据分别存储。
- 例如针对评论数据，可按照商品ID进行hash，路由到对应的表中存储；
- 针对支付记录，可按照小时创建表，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据。
只要实时操作的表数据量足够小，请求能够均匀地分发到多台服务器上的小表，数据库就能通过水平扩展的方式来提高性能。
- 其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制。
- 这种做法显著增加了数据库运维的难度，对DBA的要求较高。
- 数据库设计到这种结构时，已经可以称为分布式数据库。
但是这只是⼀个逻辑的数据库整体，数据库⾥不同的组成部分是由不同的组件单独来实现的
- 如分库分表的管理和请求分发，由Mycat实现
- SQL的解析由单机的数据库实现
- 读写分离可 能由⽹关和消息队列来实现
- 查询结果的汇总可能由数据库接口层来实现等等
这种架构其实是MPP （⼤规模并行处理）架构的⼀类实现。
适用场景：数据量增大，单库难以支撑。
- 解决方案：按业务将数据分库存储，使用Mycat等工具管理分库分表。
- 相关软件：分布式数据库（Greenplum、TiDB、Postgresql XC、HAWQ等）。
7 业务拆分 - 微服务
- 随着⼈员增加，业务发展，我们将业务分给不同的开发团队去维护，每个团队独⽴实现⾃⼰的微服务，然后互相之间对数据的直接访问进⾏隔离
适用场景：业务复杂度增加，团队扩大。
- 解决方案：将业务拆分为独立的微服务，通过Gateway、消息总线等技术实现服务间的调用。
- 公共服务：安全中心、监控预警中心等。
总结
- 架构演进顺序：实际场景中可能同时存在多个问题，需根据具体情况灵活解决。
- 扩展接口：预留扩展接口以应对未来需求。
- 大数据架构：涉及数据采集、存储、分析、服务等多个环节，提供分布式存储、计算等能力。
突然回忆到了，博主之间对结构的一篇文章：【Linux详解】冯诺依曼架构 | 操作系统设计 | 斯坦福经典项目Pintos，重点摘要如下 ：
• 底层硬件：遵顼冯诺依曼体系系结构，通过内存为枢纽的数据数据交换，实现了降本增效，使得计算机走入百姓家中
• 驱动程序：操作系统管理系统管理硬键的重要手段，操作系统通过驱动程序获取硬件的信息，进而而实行管理
• 操作系统：计算机体系中的管理者，管理各种各样的软硬件资源，遵循先描述，再组织的重要思想，使得操作系统可以批量管理众多软硬件
• 系统调用接口：为了保证操作系统提供的服 务是安全可靠的，通过系统调用接口来帮助 用户访问问计算机，同时保护了操作系统内部的数据
• 用户操作接口：直接通过系统调用接口访 问计算机会比较麻烦，于是通过用户操作接口以更加便捷的方式提供服务，并且提供了跨平台的特性，使得计算机的访问方便快捷
总结
应用（Application）/ 系统（System）
- 一个应用, 就是一个/组服务器程序
模块（Module）/ 组件（Component）
- 一个应用, 里面有很多个功能。每个独立的功能, 就可以称为是一个模块/组件
分布式（Distributed）
- 引入多个主机/服务器, 协同配合完成一系列的工作。（物理上
集群（Cluster）
- 引入多个主机/服务器, 协同配合完成一系列的工作。（逻辑上
主（Master）/ 从（Slave）
- 分布式系统中一种比较典型的结构~ ~
- 多个服务器节点, 其中一个是主, 另外的是从。从节点的数据要从主节点这里同步过来~ ~
中间件（Middleware）
和业务无关的服务(功能更通用的服务)
- 数据库
- 缓存
- 消息队列
- ...
可用性（Availability）
- 系统整体可用的时间 / 总的时间
- 360 / 365 => 可用性~ ~
- 4 个9即系统可以提供99.99% 的可用性，5 个9 是99.999%
响应时长（Response Time RT）
- 衡量服务器的性能
- 越小越好~ ~
吞吐（Throughput）vs 并发（Concurrent）
- 衡量系统的处理请求的能力。衡量性能的一种方式
分布式系统小结
1.单机架构 (应用程序 + 数据库服务器)
2.数据库和应用分离
- 应用程序和数据库服务器分别放到不同主机上部署了.
3.引入负载均衡, 应用服务器 => 集群
- 通过负载均衡器, 把请求比较均匀的分发给集群中的每个应用服务器.
- 当集群中的某个主机挂了, 其他的主机仍然可以承担服务.
- 提高了整个系统的可用性~ ~
4.引入读写分离, 数据库主从结构
- 一个数据库节点作为主节点, 其他N个数据库节点作为从节点.
- 主节点负责写数据, 从节点负责读数据.
- 主节点需要把修改过的数据同步给从节点~
上述四点，都是为了 高效的处理更多的数据
5.引入缓存, 冷热数据分离
- Redis 在一个分布式系统中, 通常就扮演着缓存这样的角色~ ~
- 引入的问题: 数据库和缓存的数据一致性问题~ ~
6.引入分库分表, 数据库能够进一步扩展存储空间
7.引入微服务, 从业务上进一步拆分应用服务器
- 从业务功能的角度, 把应用服务器, 拆分成更多的功能更单一, 更简单, 更小的服务器.
上述这样的几个演化的步骤, 只是一个粗略的过程.
实际上一个商业项目, 真实的演化过程, 都是和他的业务发展密切相关的.
业务是更重要的, 技术是给业务提供支持的.
所谓的分布式系统, 就是想办法引入更多的硬件资源!!