技术架构
例：打开浏览器/app访问了一个地址，域名并不能告诉我们是哪个服务器由我们的dns做一个转换，就知道了服务器ip(找到服务器门牌号)，就去访问服务器。默认先去访问80端口，应用服务绑定了80端口。我们就访问到了应用服务，我们去查找一个商品----应用服务去访问数据库服务，数据库查到商品信息后，返回给应用服务。从第一次dns后就不需要再进行，直接用户直接跟服务器进行通信。应用服务直接把信息返回给用户
目录
吞吐（Throughput）vs 并发（Concurrent）
常见概念
在正式引入架构演进之前，优先对其中一些比较重要的概念做前置介绍：
基本概念
应用（Application）/ 系统（System）
为了完成一整套服务的一个程序或者一组相互配合的程序群。
生活例子类比：为 了完成一项任务，而搭建的由一个人或者一群相互配的人组成的团队。
模块（Module）/ 组件（Component）
当应用较复杂时，为了分离职责，将其中具有清晰职责的、内聚性强的部分，抽象出概念，便于理解。
生活例子类比：军队中为了进行某据点的攻克，将人员分为突 击小组、爆破小组、掩护小组、通信小组等。
分布式（Distributed）
系统中的多个模块被部署于不同服务器之上，即可以将该系统称为分布式系统。
如 Web 服务器与数据库分别工作在不同的服务器上，或者多台 Web 服务器被分别部署在不同服务器上。
生活例子类比：为了更好的满足现实需要，一个在同一个办公场 地的工作小组被分散到多个城市的不同工作场地中进行远程配合工作完成目标。跨主机之间的模块之间的通信基本要借助网络支撑完成。
集群（Cluster）
被部署于多台服务器上的、为了实现特定目标的一个/组特定的组件，整个整体被称为集群。
比如多个 MySQL 工作在不同服务器上，共同提供数据库服务目标，可以被称为一组数据库集群。
生活例子类比：为了解决军队攻克防守坚固的大城市的作战 目标，指挥部将大批炮兵部队集中起来形成一个炮兵打击集群。
分布式 vs 集群。
通常不用太严格区分两者的细微概念，细究的话，分布式强调的 是物理形态，即工作在不同服务器上并且通过网络通信配合完成任务；而集群更在意逻辑形态，即是否为了完成特定服务目标。
主（Master）/ 从（Slave）
集群中，通常有一个程序需要承担更多的职责，被称为主；其他承担附属职责的被称为从。
比如 MySQL 集群中，只有其中一台服务器上数据库允许进行数据的写入 （增/删/改），其他数据库的数据修改全部要从这台数据库同步而来，则把那台数据库称为主库，其他数据库称为从库。
中间件（Middleware）
一类提供不同应用程序用于相互通信的软件，即处于不同技术、工具和数据库之间的桥梁。
生活例子类比：一家饭店开始时，会每天去市场挑选买菜，但随着饭店业务量变大，成立一个采购部，由采购部专职于采买业务，称为厨房和菜市场之间的桥梁。
容器（Docker）
Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux 或 Windows 操作系统的机器上， 也可以实现虚拟化。可以理解为一个集装箱，集装箱里面是每个用户的货物，整体打包。
容器编排（K8S）
kubernetes，简称 K8s，是用 8 代替名字中间的 8 个字符“ubernete”而成的缩写。 是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是 让部署容器化的应用简单并且高效。可以理解为一个货船，安装集装箱的大小，货物情况合理的来组织集装箱完成整体货物的搬运。
评价指标（Metric）
可用性（Availability）
考察单位时间段内，系统可以正常提供服务的概率/期望。
例如： 年化系统可用性 = 系统正常提供服务时长 / 一年总时长。这里暗含着一个指标，即如何评价系统提供无法是否正常，我们就不深入了。平时我们常说的 4 个 9 即系统可以提供 99.99% 的可用性，5 个 9 是 99.999% 的可用性，以此类推。我们平时只是用高可用（High Availability HA）这个非量化目标简要表达我们系统的追求。
响应时长（Response Time RT）
指用户完成输入到系统给出用户反应的时长。例如点外卖业务的响应时长 = 拿到 外卖的时刻 - 完成点单的时刻。通常我们需要衡量的是最长响应时长、平均响应时长 和中位数响应时长。这个指标原则上是越小越好，但很多情况下由于实现的限制，需要根据实际情况具体判断。
吞吐（Throughput）vs 并发（Concurrent）
吞吐考察单位时间段内，系统可以成功处理的请求的数量。并发指系统同一时刻 支持的请求最高量。例如一条 2 车道高速公路，一分钟可以通过 20 辆车，则并发是 2， 一分钟的吞吐量是 20。实践中，并发量往往无法直接获取，很多时候都是用极短的时 间段（比如 1 秒）的吞吐量做代替。我们平时用高并发（Hight Concurrnet）这个非量 化目标简要表达系统的追求。
架构演进
技术架构演进之路
目标---了解每种技术架构以及如何演进的,熟悉Docker在架构中的核心作用
八大架构演进
单机架构
应用数据分离架构
应用服务集群架构
读写分离/主从分离架构
冷热分离架构
垂直分库架构
微服务架构
容器编排架构
1.单机架构
所有的服务全部部署到一台单机服务器上。
简介---应用服务和数据库服务共用一台服务器
出现原因---出现在互联网早期，访问量比较小，单机足以满足需求
架构工作原理---以电子商城为例，可以看到通过应用（划分了多个模块）和数据库在单个服务器上协作完成业务运行
例：打开浏览器/app访问了一个地址，域名并不能告诉我们是哪个服务器
由我们的dns做一个转换，就知道了服务器ip(找到服务器门牌号)，就去访问服务器。
默认先去访问80端口，应用服务绑定了80端口。我们就访问到了应用服务，我们去查找一个商品----应用服务去访问数据库服务，数据库查到商品信息后，返回给应用服务。从第一次dns后就不需要再进行，直接用户直接跟服务器进行通信。应用服务直接把信息返回给用户app，应用就看到了有哪些商品。
用户在浏览器中输入 www.bit.com，首先经过 DNS 服务将域名解析成 IP 地址 10.102.41.1，随后浏览器访问该 IP 对应的应用服务。
那些蓝色的就是Java代码，Java代码以应用服务的形式对外提供，应用服务就是一个Tomcat。
最后这些Java代码以Tomcat组件的形式对外提供服务。
相关软件 Web 服务器软件：Tomcat、Netty、Nginx、Apache 等
数据库软件：MySQL、Oracle、PostgreSQL、SQL Server 等
架构优缺点---优缺点
优点 部署简单 成本低
缺点 存在严重的性能瓶颈
数据库和应用互相竞争资源
最开始背锅侠---服务器
2.应用数据分离架构
将应用和数据分离的做法，可以最小代价的提升系统的承载能力。
和之前架构的主要区别在于将数据库服务独立部署在同一个数据中心的其他服务器上， 应用服务通过网络访问数据。
简介---应用服务和数据库服务使用不同服务器
出现原因 单机存在严重的资源竞争，导致站点变慢
架构工作原理 以电子商城为例，可以看到应用（划分了多个模块）和数据库在各自的服务器上通过网络协作完成业务运行
用户查看商品：
用户使用app访问了域名www.xxx.com，找到DNS。DNS就把我们IP返回回来，返回应用服务的IP。拿到应用服务器的IP发现绑定了一个80端口，80端口由我们的tomcat提供服务。我们浏览器就去访问tomcat服务去了，tomcat之后就去访问数据库通过网络来完成一个访问。
回去：
数据库查询到后把查询到的商品信息给Tmocat返回，Tomcat返回给浏览器/APP，再接着返回给用户，用户能在自己的应用上看到商品信息。
架构优缺点---优缺点
优点
成本相对可控
性能相比单机有提升
数据库单独隔离，不会因为应用把数据库搞坏，有一定的容灾能力
缺点
硬件成本变高
性能有瓶颈，无法应对海量并发
背锅侠---服务器 ----》购买服务器
3.应用服务集群架构
单机应用服务器首先遇到了瓶颈，摆在我们技术团队面前的有两种方案，大家针对方案的优劣展示了热烈的讨论：
• 垂直扩展 / 纵向扩展 Scale Up。通过购买性能更优、价格更高的应用服务器来应对更多的流量。这种方案的优势在于完全不需要对系统软件做任何的调整；但劣势也很明显：硬件性能和价格的增长关系是非线性的，意味着选择性能 2 倍的硬件可能需 要花费超过 4 倍的价格，其次硬件性能提升是有明显上限的。
• 水平扩展 / 横向扩展 Scale Out。通过调整软件架构，增加应用层硬件，将用户流 量分担到不同的应用层服务器上，来提升系统的承载能力。这种方案的优势在于成本 相对较低，并且提升的上限空间也很大。但劣势是带给系统更多的复杂性，需要技术 团队有更丰富的经验。
经过团队的学习、调研和讨论，最终选择了水平扩展的方案，来解决该问题，但这需 要引入一个新的组件 —— 负载均衡：为了解决用户流量向哪台应用服务器分发的问题， 需要一个专门的系统组件做流量分发。实际中负载均衡不仅仅指的是工作在应用层的， 甚至可能是其他的网络层之中。同时流量调度算法也有很多种，这里简单介绍几种较为常见的：
• Round-Robin 轮询算法。即非常公平地将请求依次分给不同的应用服务器。
• Weight-Round-Robin 轮询算法。为不同的服务器（比如性能不同）赋予不同的权 重（weight），能者多劳。
• 一致哈希散列算法。通过计算用户的特征值（比如 IP 地址）得到哈希值，根据哈 希结果做分发，优点是确保来自相同用户的请求总是被分给指定的服务器。也就是我 们平时遇到的专项客户经理服务
简介 引入了负载均衡，应用以集群方式运作
出现原因 单个应用不足以支持海量的并发请求，高并发的时候站点响应变慢
架构工作原理 以电子商城为例，可以看到应用不再是一个，而是变成了多个,通过负载均衡来支持海量的并发
技术案例
背锅侠---应用 --》 横向扩展
负载均衡
相关软件
负载均衡软件：Nginx、HAProxy、LVS、F5 等
第一阶段是DNS，通过多个IP的返回解决
第二阶段是LVS/F5
第三阶段是Nginx
这样能抗住千万级甚至亿级的流量
架构优缺点---优缺点
优点
应用服务高可用：应用满足高可用，不会一个服务出问题整个站点挂掉
应用服务具备一定高性能：如果不访问数据库，应用相关处理通过扩展可以支持海
量请求快速响应应用服务有一定扩展能力：支持横向扩展
缺点
数据库成为性能瓶颈，无法应对数据库的海量查询
数据库是单点，没有高可用
运维工作增多，扩展后部署运维工作增多，需要开发对应的工具应对快速部署
硬件成本较高
4.读写分离 / 主从分离架构
一致性问题
服务器1 Seq=1 UpdateTime=10
update table set status = 1;
服务器2 Seq=2 UpdateTime=9
update table set status = 2;
提到，我们把用户的请求通过负载均衡分发到不同的应用服务器之后，可以并行处理了，并且可以随着业务的增长，可以动态扩张服务器的数量来缓解压力。 但是现在的架构里，无论扩展多少台服务器，这些请求最终都会从数据库读写数据， 到一定程度之后，数据的压力称为系统承载能力的瓶颈点。我们可以像扩展应用服务 器一样扩展数据库服务器么？答案是否定的，因为数据库服务有其特殊性：如果将数 据分散到各台服务器之后，数据的一致性将无法得到保障。所谓数据的一致性，此处 是指：针对同一个系统，无论何时何地，我们都应该看到一个始终维持统一的数据。 想象一下，银行管理的账户金额，如果收到一笔转账之后，一份数据库的数据修改了， 但另外的数据库没有修改，则用户得到的存款金额将是错误的
我们采用的解决办法是这样的，保留一个主要的数据库作为写入数据库，其他的 数据库作为从属数据库。从库的所有数据全部来自主库的数据，经过同步后，从库可 以维护着与主库一致的数据。然后为了分担数据库的压力，我们可以将写数据请求全 部交给主库处理，但读请求分散到各个从库中。由于大部分的系统中，读写请求都是 不成比例的，例如 100 次读 1 次写，所以只要将读请求由各个从库分担之后，数据库 的压力就没有那么大了。当然这个过程不是无代价的，主库到从库的数据同步其实是有时间成本的
简介 将数据库读写操作分散到不同的节点上，数据库服务器搭建主从集群，一主一从、一主多从都可以，数据库主机负责写操作，从机只负责读操作
出现原因 数据库成为瓶颈，而互联网应用一般读多写少，数据库承载压力大，主要是由这些读的请求造成的，那么我们可以把读操作和写操作分开
架构工作原理 以电子商城为例，可以看到数据库服务器不再是一个，而是变成了多个,数据库主机负责写操作，从机负责读操作，数据库主机通过复制将数据同步到从机
背锅侠---》数据库 读写分离
集群化
应用中需要对读写请求做分离处理，所以可以利用一些数据库中间件，将请求分离的 职责托管出去
相关软件 MyCat、TDDL、Amoeba、Cobar 等类似数据库中间件等
技术案例
架构优缺点---优缺点
优点 数据库的读取性能提升
读取被其他服务器分担，写的性能间接提升
数据库有从库，数据库的可用性提高了
缺点
热点数据的频繁读取导致数据库负载很高
当同步挂掉，或者同步延迟比较大时，写库和读库的数据不一致
服务器成本需要进一步增加
5.引入缓存 —— 冷热分离架构
随着访问量继续增加，发现业务中一些数据的读取频率远大于其他数据的读取频 率。我们把这部分数据称为热点数据，与之相对应的是冷数据。针对热数据，为了提 升其读取的响应时间，可以增加本地缓存，并在外部增加分布式缓存，缓存热门商品 信息或热门商品的 html 页面等。通过缓存能把绝大多数请求在读写数据库前拦截掉， 大大降低数据库压力。其中涉及的技术包括：使用 memcached 作为本地缓存，使用 Redis 作为分布式缓存，还会涉及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据 集中失效等问题
简介 引入缓存，实行冷热分离，将热点数据放到缓存中快速响应
出现原因 海量的请求导致数据库负载过高，站点响应再度变慢
架构工作原理 以电子商城为例，可以看到多了缓存服务器，对于热点数据全部放到缓存中，不常用数据再去查询我们的数据库
背锅侠----》数据库 引入缓存
写入数据
读取数据
技术案例
写入
读取
相关软件： Memcached、Redis 等缓存软件
架构优缺点---优缺点
优点
大幅降低对数据库的访问请求，性能提升非常明显
缺点
带来了缓存一致性，缓存击穿，缓存失效，缓存雪崩等问题
服务器成本需要进一步增加
业务体量支持变大后，数据不断增加，数据库单库太大，单个表体量也太大，数据查询会很慢，导致数据库再度成为系统瓶颈
6.垂直分库架构
随着业务的数据量增大，大量的数据存储在同一个库中已经显得有些力不从心了， 所以可以按照业务，将数据分别存储。比如针对评论数据，可按照商品 ID 进行 hash， 路由到对应的表中存储；针对支付记录，可按照小时创建表，每个小时表继续拆分为 小表，使用用户 ID 或记录编号来路由数据。只要实时操作的表数据量足够小，请求能 够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能。其中前面提到的 Mycat 也支持在大表拆分为小表情况下的访问控制。这种做法 显著的增加了数据库运维的难度，对 DBA 的要求较高。数据库设计到这种结构时，已 经可以称为分布式数据库，但是这只是一个逻辑的数据库整体，数据库里不同的组成 部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由 Mycat 实现， SQL 的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果 的汇总可能由数据库接口层来实现等等，这种架构其实是 MPP（大规模并行处理）架构的一类实现。
分库分表
分布式数据库
简介 数据库的数据被拆分，数据库数据分布式存储，分布式处理，分布式查询，也可以理解为分布式数据库架构
出现原因 单机的写库会逐渐会达到性能瓶颈，需要拆分数据库，数据表的数据量太大，处理压力太大，需要进行分表，为降低运维难度，业界逐渐研发了分布式数据库，库表天然支持分布式
架构工作原理 以电子商城为例，数据库是由多个主从库或者存储集群构成，支持分布式大规模并行处理
背锅侠
写入
读取
技术案例
相关软件 Greenplum、TiDB、Postgresql XC、HAWQ 等，商用的如南大通用的 GBase、 睿帆科技的雪球 DB、华为的 LibrA 等
分库分表
分布式数据库
写
读
架构优缺点---优缺点
优点
数据库吞吐量大幅提升，不再是瓶颈
缺点
跨库join、分布式事务等问题，这些需要对应的去进行解决，目前的mpp都有对应的解决方案
数据库和缓存结合目前能够抗住海量的请求，但是应用的代码整体耦合在一起，修改一行代码需要整体重新发布
7.微服务架构
随着人员增加，业务发展，我们将业务分给不同的开发团队去维护，每个团队独 立实现自己的微服务，然后互相之间对数据的直接访问进行隔离，可以利用 Gateway、 消息总线等技术，实现相互之间的调用关联。甚至可以把一些类似用户管理等业务提 成公共服务。
简介 微服务是一种架构风格，按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级迭代。
出现原因
扩展性差:应用程序无法轻松扩展，因为每次需要更新应用程序时，都必须重新构建整个系统
持续开发困难:一个很小的代码改动，也需要重新部署整个应用,无法频繁并轻松的发布版本
不可靠:即使系统的一个功能不起作用，可能导致整个系统无法工作
不灵活:无法使用不同的技术构建单体应用程序
代码维护难:所有功能耦合在一起，新人不知道何从下手
背锅侠
架构工作原理 以电子商城为例，一个商城应用拆分成了多个微服务，如用户服务、交易服务和商品服务，相互之间协作支持整个商城的应用
相关软件 Docker、K8S
技术案例
架构优缺点---优缺点
优点
灵活性高：服务独立测试、部署、升级、发布
独立扩展：每个服务可以各自进行扩展
提高容错性：一个服务问题并不会让整个系统瘫痪；
新技术的应用容易:支持多种编程语言
缺点
运维复杂度高：业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难
资源使用变多：所有这些独立运行的微服务都需要需要占用内存和 CPU
处理故障困难：一个请求跨多个服务调用，需要查看不同服务的日志完成问题定位
8.容器编排架构
随着业务增长，然后发现系统的资源利用率不高，很多资源用来应对短时高并发，平 时又闲置，需要动态扩缩容，还没有办法直接下线服务器，而且开发、测试、生产每 套环境都要隔离的环境，运维的工作量变的非常大。容器化技术的出现给这些问题的 解决带来了新的思路。 目前最流行的容器化技术是 Docker，最流行的容器管理服务是 Kubernetes(K8S)，应 用/服务可以打包为 Docker 镜像，通过 K8S 来动态分发和部署镜像。Docker 镜像可理 解为一个能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运 行环境根据实际的需要设置好。把整个“操作系统”打包为一个镜像后，就可以分发到需 要部署相关服务的机器上，直接启动 Docker 镜像就可以把服务起起来，使服务的部署 和运维变得简单。服务 通常会有生产和研发 k8s 集群，一般不会公用，而研发集群通过命名空间来完成应用隔离，有的公司按照研发目的划分为研发和测试集群，有的公司通过组织架构完成部 门间的资源复用
简介 借助容器化技术(如docker)将应用/服务可以打包为镜像，通过容器编排工具(如k8s)来动态分发和部署镜像，服务以容器化方式运行
出现原因
微服务拆分细，服务多部署工作量大，而且配置复杂，容易出错
微服务数量多扩缩容麻烦，而且容易出错，每次缩容后再扩容又需要重新配置服务对应的环境参数信息
微服务之间运行环境可能冲突，需要更多的资源来进行部署或者通过修改配置来解决冲突
架构工作原理
以电子商城为例，一个商城应用拆分成了多个微服务，如用户服务、交易服务和商品服务，每一个微服务打包到容器之中，相互协作来完成系统功能，通过容器编排工具完成部署运维技术案例
背锅侠
运维 快速部署
技术案例
架构优缺点---优缺点
优点
部署、运维简单快速：一条命令就可以完成几百个服务的部署或者扩缩容
隔离性好：容器与容器之间文件系统、网络等互相隔离，不会产生环境冲突
轻松支持滚动更新：版本间切换都可以通过一个命令完成升级或者回滚
缺点
技术栈变多，对研发团队要求高
机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低，可以通过购买云厂商服务器解决。
最后背锅是服务器，解决方案就是用云厂商的
最终支持了一个海量的并发
例子
一个互联网应用架构
最后还是要根据实际场景、实际业务角度去进行考虑。
感谢你的观看，期待我们下次再见！
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
20
0- 0
已为社区贡献8条内容
所有评论(0)