# 互联网软件架构发展历程（了解-鸟瞰其架构）

最新推荐文章于 2023-04-17 21:36:47 发布

小小编码

最新推荐文章于 2023-04-17 21:36:47 发布

阅读量236

点赞数 1

文章标签：架构 java 网络

本文链接：https://blog.csdn.net/weixin_48206782/article/details/126801245

版权

互联网软件架构发展历程（了解-鸟瞰其架构）

1 软件架构初识

1.1概述

为了更好理解互联网软件架构，我们现在介绍一下，一百万到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整

体的认知。

1.2基本概念

在介绍架构之前，为了避免初学者对架构设计中的一些概念不了解，下面对几个最基础

的概念进行介绍。

▪ 分布式

将系统部署在不同服务器上，即可称为分布式系统，如 Tomcat和数据库分别部署在不

同的服务器上，或两个相同功能的 Tomcat分别部署在不同服务器上。

▪ 高可用

系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用

性。保证系统的高可用性，可从如下几个 9说起，如图所示：

在这里插入图片描述

为了提高可用性，我们要么提高系统的无故障时间，要么减少系统的故障恢复时间，这

就需要我们知道故障的原因。这个原因通常分为两大部分：

1) 无计划的系统故障

✓ 系统级故障：包括主机、操作系统、中间件、数据库、网络、电源以及外围设备。

✓ 自然灾害、人为破坏，以及供电问题等。

2) 有计划的日常任务：

✓ 运维相关：数据库维护、应用维护、中间件维护、操作系统维护、网络维护。

✓ 升级相关：数据库、应用、中间件、操作系统、网络，包括硬件升级。

我们再对这些故障做个归类：

1) 网络问题：网络链接出现问题，网络带宽出现拥塞等

2) 性能问题：慢 SQL、Java Full GC、硬盘 IO 过大、CPU 飙高、内存不足等

3) 安全问题：被网络攻击，如 DDoS 等。

4) 运维问题：系统总是在被更新和修改，架构也在不断地被调整，监控问题等

5) 管理问题：没有梳理关键服务及服务的依赖关系，运行信息没有和控制系统同步等

6) 硬件问题：硬盘损坏、网卡出问题、交换机出问题、机房掉电、挖掘机问题等

总之，我们要正确认识故障，故障不可避免。尤其是在大型分布式系统中，出现故障是

一种常态。有时出现故障根本就不知道出现在了什么地方。所以我们要对故障原因先有一个

认识，与此同时我们要基于故障有应对的策略，也就是我们所说的“弹力设计”，就类似三

国中的赵云猛将，在搏杀中能进能退。

▪ 集群

一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为

集群。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节

点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性。

▪ 负载均衡

请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能

够均匀的处理请求负载，则可认为系统是负载均衡的。

▪ 正向代理和反向代理

系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看

来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；当外部请求进入系统时，

代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理

服务器，此时代理服务器实现的是反向代理。简单来说，正向代理是代理服务器代替系统内

部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务

器的过程。如图所示：在这里插入图片描述

2 软件架构演进过程

2.1单体架构初步设计

在互联网应用初期，互联网用户数相对都较少，可以把 web 服务器(例如 Tomcat)和数据库

部署在同一台服务器上。浏览器往 www.taobao.com 发起请求时，首先经过 DNS 服务器（域

名系统）把域名转换为实际IP地址202.100.10.128，浏览器转而访问该IP对应的Tomcat。

如图所示：在这里插入图片描述

在单体架构下，随着用户数的增长，Tomcat 和数据库之间竞争资源，单机性能不足以

支撑业务。

小节面试分析：

1) 从浏览器输入一个 url 到数据加载完成整个过程发生了什么？

2) 浏览器与 tomcat 进行通讯使用的什么协议，这个协议有什么特点？

3) Tomcat 如何并发处理多个客户端的请求？

4) Tomcat 中的应用是如何访问数据数据库的？

2.2Web 服务与数据库分开

Web 服务器(Tomcat)和数据库分别独占服务器资源，显著提高两者各自性能。在这里插入图片描述

Web服务如何连接数据库服务器？

(jdbc:mysql://ip:port/dbname?serverTimezone=Asia/Shanghai&….)

为什么 Web 服务连接不上我们的数据库服务器?(网络不通，IP 地址不正确，端口

（不正确，服务宕机了，防火墙，连接已用尽-数据库支持的连接数量是有限的)

为什么随着用户的增长，访问数据库的请求越来越多,此时会出现什么问题？

(读写瓶颈)

何为读写瓶颈？

（访问数据库的请求就会越多，线程多了，CPU 处理不过来了）

如何解决读写瓶颈问题呢？

(尽量在上层将请求拦截掉，减少访问数据库的请求)

2.3本地缓存和分布式缓存

在 JVM 中增加本地缓存，并在外部增加分布式缓存，缓存热门数据等。通过缓存能把绝大

多数请求在读写数据库前拦截掉，大大降低数据库压力。如图所示：在这里插入图片描述

FAQ？

本地缓存的选型？(Caffeine/Guava/自己写/。。。。。）
分布式缓存？(Redis/Memcached/….)
使用缓存可以解决什么问题？(提高查询的效率/减少对关系型数据库的访问-mysql)
使用缓存能会带来哪些负面问题？(数据一致性问题，缓存穿透/缓存雪崩/缓存击穿)
为什么应用了缓存会有数据一致性问题？(数据库数据更新了，缓存中数据还没更新)
什么是缓存穿透、缓存雪崩、缓存击穿？

https://mp.weixin.qq.com/s?__biz=Mzg4MzIxMDE2Mg==&mid=2247484586&idx=1&sn

=dd1a22b1b7d0794df3aef6a2d31719a0&chksm=cf4ba677f83c2f612e5bd021dd96279e8

8c111794d7c8db106cd201ade88ad132b257ac3b665&token=1501001257&lang=zh_CN#

假如让你去设计一个缓存要考虑哪些问题？（数据的存储结构/数据的淘汰算法/日志记

录/定时刷新/线程安全/序列化）

什么是深拷贝、浅拷贝？(深拷贝就是拷贝内容-可以理解为序列化和反序列化，浅拷贝

一般拷贝地址。)

2.4反向代理与负载均衡设计

在多台服务器上分别部署 Tomcat，使用反向代理软件（Nginx）把请求均匀分发到每个

Tomcat 中。此处假设 Tomcat 最多支持 100 个并发，Nginx 最多支持 50000 个并发，那么

理论上 Nginx 把请求分发到 500 个 Tomcat 上，就能抗住 50000 个并发。其中涉及的技术

包括：Nginx、HAProxy，如图所示：在这里插入图片描述
FAQ?

Nginx 代理的是谁？(服务端的服务器)
Nginx 代理的作用什么？(请求转发,负载均衡)
这种架构下 Web 服务器多了，可以承载的并发也大了，并发多了请求的类型也就多了，

此时可能就会有大量的请求击穿缓存去访问数据库，数据库的压力就会巨增，那如何解

决这个问题呢？

2.5数据库读写分离设计

把数据库划分为读库和写库，读库可以有多个(并发读通常会多于并发写)，通过同步机制把

写库的数据同步到读库，对于需要查询最新写入数据场景，可通过在缓存中多写一份，通过

缓存获得最新数据。如图所示：在这里插入图片描述
其中涉及的技术包括：Mycat，它是数据库中间件，可通过它来组织数据库的分离读写

和分库分表，客户端通过它来访问下层数据库，还会涉及数据同步，数据一致性的问题。

业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响

性能。

2.6数据库按业务进行分库

把不同业务的数据保存到不同的数据库中，使业务之间的资源竞争降低，对于访问量大的业

务，可以部署更多的服务器来支撑。在这里插入图片描述
这样同时导致跨业务的表无法直接做关联分析，需要通过其他途径来解决，但这不是本

文讨论的重点，有兴趣的可以自行搜索解决方案。对于这种方案，随着用户数的增长，单机

的写库会逐渐会达到性能瓶颈。

2.7大表拆分为小表

比如针对评论数据，可按照商品 ID 进行 hash，路由到对应的表中存储；针对支付记录，可按照小时创建表，每个小时表继续拆分为小表，使用用户 ID 或记录编号来路由数据。只要实时操作的表数据量足够小，请求能够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能。其中前面提到的 Mycat 也支持在大表拆分为小表情况下的访问控制。在这里插入图片描述

这种做法显著的增加了数据库运维的难度，对 DBA 的要求较高。数据库设计到这种结

构时，已经可以称为分布式数据库，但是这只是一个逻辑的数据库整体，数据库里不同的组

成部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由 Mycat 实现，SQL

的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果的汇总可能

由数据库接口层来实现等等，这种架构其实是 MPP（大规模并行处理）架构的一类实现。

数据库和 Tomcat 都能够水平扩展，可支撑的并发大幅提高，随着用户数的增长，最终

单机的 Nginx 会成为瓶颈。

2.8LVS 或 F5 让多个 Nginx 负载均衡

由于瓶颈在 Nginx，因此无法通过两层的 Nginx 来实现多个 Nginx 的负载均衡。此时

采用 LVS 和 F5 作为网络负载均衡解决方案，如图所示：在这里插入图片描述
其中 LVS 是软件，运行在操作系统内核态，可对 TCP 请求或更高层级的网络协议进行

转发，因此支持的协议更丰富，并且性能也远高于 Nginx，可假设单机的 LVS 可支持几十万

个并发的请求转发；F5 是一种负载均衡硬件，与 LVS 提供的能力类似，性能比 LVS 更高，

但价格昂贵。由于 LVS 是单机版的软件，若 LVS 所在服务器宕机则会导致整个后端系统都

无法访问，因此需要有备用节点。可使用 keepalived 软件模拟出虚拟 IP，然后把虚拟 IP 绑

定到多台 LVS 服务器上，浏览器访问虚拟 IP 时，会被路由器重定向到真实的 LVS 服务器，

当主 LVS 服务器宕机时，keepalived 软件会自动更新路由器中的路由表，把虚拟 IP 重定向

到另外一台正常的 LVS 服务器，从而达到 LVS 服务器高可用的效果。

此种方案中，由于 LVS 也是单机的，随着并发数增长到几十万时，LVS 服务器最终会达

到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房距离不

同，导致了访问的延迟会明显不同。

2.9DNS 轮询实现机房的负载均衡

在 DNS 服务器中可配置一个域名对应多个 IP 地址，每个 IP 地址对应到不同的机房里

的虚拟 IP。当用户访问 www.taobao.com 时，DNS 服务器会使用轮询策略或其他策略，来

选择某个 IP 供用户访问。此方式能实现机房间的负载均衡，至此，系统可做到机房级别的

水平扩展，千万级到亿级的并发量都可通过增加机房来解决，系统入口处的请求并发量不再

是问题。
在这里插入图片描述

随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无

法解决如此丰富的需求

2.10 大应用拆分成小应用

按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级

迭代。这时候应用之间可能会涉及到一些公共配置，可以通过分布式配置中心 Zookeeper

来解决。
在这里插入图片描述

不同应用之间存在共用的模块，由应用单独管理会导致相同代码存在多份，导致公共功

能升级时全部应用代码都要跟着升级。

2.11 抽离微服务实现工程复用

如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代

码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之

间通过 HTTP、TCP 或 RPC 请求等多种方式来访问公共服务，每个单独的服务都可以由单独

的团队来管理。此外，可以通过 Dubbo、SpringCloud 等框架实现服务治理、限流、熔断、

降级等功能，提高服务的稳定性和可用性。如图所示：在这里插入图片描述

2.12 容器化技术设计及应用

目前最流行的容器化技术是 Docker，最流行的容器管理服务是 Kubernetes(K8S)，应用/服

务可以打包为 Docker 镜像，通过 K8S 来动态分发和部署镜像。Docker 镜像可理解为一个

能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运行环境根据实

际的需要设置好。把整个“操作系统”打包为一个镜像后，就可以分发到需要部署相关服务的

机器上，直接启动 Docker 镜像就可以把服务起起来，使服务的部署和运维变得简单。

在这里插入图片描述

在大促的之前，可以在现有的机器集群上划分出服务器来启动 Docker 镜像，增强服务的性

能，大促过后就可以关闭镜像，对机器上的其他服务不造成影响（在 3.14 节之前，服务运

行在新增机器上需要修改系统配置来适配服务，这会导致机器上其他服务需要的运行环境被

破坏）。

2.13 云平台服务部署

系统可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题，在大

促的时间段里，在云平台中临时申请更多的资源，结合 Docker 和 K8S 来快速部署服务，在

大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维成本。在这里插入图片描述

所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在

之上可按需动态申请硬件资源（如 CPU、内存、网络等），并且之上提供通用的操作系统，

提供常用的技术组件（如 Hadoop 技术栈，MPP 数据库等）供用户使用，甚至提供开发好的

应用，用户不需要关系应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮

件服务、个人博客等）。

3 总结(Summary)

3.1重难点分析

▪ 发展历程中的关键设计及技能点。

▪ 架构发展过程中暴露出的问题以及解决方案。

3.2FAQ 分析

▪ 单体架构你觉得存在什么缺陷？（容量、计算、故障）

▪ 为什么要使用分布式架构？(增加容量、高并发、高性能、高可用)

▪ 分布式架构有什么劣势？(设计的难度、维护成本)

▪ 为什么要使用缓存？(减少数据库访问压力、提高性能)

▪ 使用缓存时要注意什么问题？(一致性、淘汰算法、击穿、雪崩)

▪ 如何理解反向代理？(服务端代理，是服务端服务器的一种代理机制，请求转发)

▪ 反向代理如何实现负载均衡？(轮询，轮询+权重，哈希 IP)

▪ 什么是读写分离、读写分离的目的是什么？(单机数据库有瓶颈、读写频次，并发能力)

▪ 读写分离后可能会带来什么问题？（数据同步）

▪ 当我们向写库写数据时还要做什么？(写缓存、数据同步到读库)

▪ 为什么要进行分库、分表，有哪些分表策略？(业务数据可靠性、查询性能)

▪ 何为服务，有什么是微服务？(服务-软件要解决的问题，可以提供的功能。微服务-服务中的共性再抽象，以实现更好的重用)

▪ 哪种互联网架构设计最好？(没有最好，只有更好，脱离业务谈就够就是耍流氓)

▪ 如何理解分布式架构中的水平分？(MVC，服务冗余，表中记录也可以按 id 或时间进行水平分)