dockor --技术架构

1.基本概念

1.1应用（Application）/ 系统（System）

为了完成一整套服务的一个程序或者一组相互配合的程序群。生活例子类比：为了完成一项任务，而搭建的由一个人或者一群相互配的人组成的团队。

1.2模块（Module）/ 组件（Component）

当应用较复杂时，为了分离职责，将其中具有清晰职责的、内聚性强的部分，抽象出概念，便于理解。生活例子类比：军队中为了进行某据点的攻克，将人员分为突击小组、爆破小组、掩护小组、通信小组等。

1.3分布式（Distributed）

系统中的多个模块被部署于不同服务器之上，即可以将该系统称为分布式系统。如 Web 服务器与数据库分别工作在不同的服务器上，或者多台 Web 服务器被分别部署在不同服务器上。生活例子类比：为了更好的满足现实需要，一个在同一个办公场地的工作小组被分散到多个城市的不同工作场地中进行远程配合工作完成目标。跨主机之间的模块之间的通信基本要借助网络支撑完成。

1.4集群（Cluster）

被部署于多台服务器上的、为了实现特定目标的一个/组特定的组件，整个整体被称为集群。比如多个 MySQL 工作在不同服务器上，共同提供数据库服务目标，可以被称为一组数据库集群。生活例子类比：为了解决军队攻克防守坚固的大城市的作战目标，指挥部将大批炮兵部队集中起来形成一个炮兵打击集群。

分布式 vs 集群。通常不用太严格区分两者的细微概念，细究的话，分布式强调的是物理形态，即工作在不同服务器上并且通过网络通信配合完成任务；而集群更在意逻辑形态，即是否为了完成特定服务目标。

1.5主（Master）/ 从（Slave）

集群中，通常有一个程序需要承担更多的职责，被称为主；其他承担附属职责的被称为从。比如 MySQL 集群中，只有其中一台服务器上数据库允许进行数据的写入（增/删/改），其他数据库的数据修改全部要从这台数据库同步而来，则把那台数据库称为主库，其他数据库称为从库。

1.6中间件（Middleware）

一类提供不同应用程序用于相互通信的软件，即处于不同技术、工具和数据库之间的桥梁。生活例子类比：一家饭店开始时，会每天去市场挑选买菜，但随着饭店业务量变大，成立一个采购部，由采购部专职于采买业务，称为厨房和菜市场之间的桥梁。

1.7容器（Docker）

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux 或 Windows 操作系统的机器上，也可以实现虚拟化。可以理解为一个集装箱，集装箱里面是每个用户的货物，整体打包。

1.8容器编排（K8S）

kubernetes，简称 K8s，是用 8 代替名字中间的 8 个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效。可以理解为一个货船，安装集装箱的大小，货物情况合理的来组织集装箱完成整体货物的搬运。

评价指标（Metric）

1.9可用性（Availability）

考察单位时间段内，系统可以正常提供服务的概率/期望。例如： 年化系统可用性= 系统正常提供服务时长 / 一年总时长。这里暗含着一个指标，即如何评价系统提供无法是否正常，我们就不深入了。平时我们常说的 4 个 9 即系统可以提供 99.99% 的可用性，5 个 9 是 99.999% 的可用性，以此类推。我们平时只是用高可用（High Availability HA）这个非量化目标简要表达我们系统的追求。

1.10响应时长（Response Time RT）

指用户完成输入到系统给出用户反应的时长。例如点外卖业务的响应时长 = 拿到外卖的时刻 - 完成点单的时刻。通常我们需要衡量的是最长响应时长、平均响应时长和中位数响应时长。这个指标原则上是越小越好，但很多情况下由于实现的限制，需要根据实际情况具体判断。

1.11吞吐（Throughput）vs 并发（Concurrent）

吞吐考察单位时间段内，系统可以成功处理的请求的数量。并发指系统同一时刻支持的请求最高量。例如一条 2 车道高速公路，一分钟可以通过 20 辆车，则并发是 2，一分钟的吞吐量是 20。实践中，并发量往往无法直接获取，很多时候都是用极短的时间段（比如 1 秒）的吞吐量做代替。我们平时用高并发（Hight Concurrnet）这个非量化目标简要表达系统的追求。

2.架构演进

2.1单机架构

出现原因：
市场上绝大多数得产品部署，都是这种单机架构。

所谓的单机架构，就是应用服务和数据库公用一台服务器。

互联网早期或者业务本身低的访问量的时候，所采用的架构。下面以电子商务的架构图举例：

工作原理：应用和数据库在单个服务器上协作完成业务运行。

特点：

整个系统（包括应用服务和数据库）运行在单台计算机上。
适用于小型应用或开发环境，因为部署简单、易于管理。
面临性能瓶颈，特别是在处理大规模数据或高并发请求时。

2.2应用数据分离架构

出现原因：

因为单机存在严重的资源竞争，站点变慢。所以我们决定扩展为两个服务器。

工作原理：应用服务和数据库在各自的服务器上完成运行，之间通过网络交互。

特点：
将应用程序的用户界面、业务逻辑与数据存储分离开来。
用户界面层负责与用户交互，业务逻辑层处理应用程序的核心功能，数据存储层管理和存储数据。
提高系统的灵活性、可维护性和可扩展性。
允许各个部分独立修改、扩展和维护，降低系统复杂性。

和之前架构的主要区别在于将数据库服务独立部署在同一个数据中心的其他服务器上，应用服务通过网络访问数据。

优点：成本相对可控、性能对比单机有提升、数据库单独隔离，较为安全。
缺点：硬件成本变高、性能任然存在瓶颈，无法应对海量开发。

2.3应用服务集群架构

出现原因：

因为原本的单个应用不足以支持海量的并发请求，高并发时候站点相应变慢，所以引进应用服务集群，从而解决上层的高并发问题。

架构原理：应用变成多个（横向扩展），通过负载均衡支持海量的并发。

特点：

应用程序被部署在多台服务器上，通过负载均衡等技术实现高可用性和扩展性。
多台服务器共同提供同一种服务，负载均衡器将请求分发到不同服务器上。
提高系统的处理能力，即使某台服务器出现故障，其他服务器仍能继续提供服务。

2.4读写分离/主从分离架构

出现原因：

数据库成为瓶颈，而互联网一般读多写少，数据库承载压力大，主要是由这些读请求造成的，那么我们可以将读写操作进行分离。提高数据库的吞吐量。

架构工作原理：数据库服务器变成了多个，数据库主机负责写操作，从机负责读，数据库主机通过复制将数据同步到从机。

特点：
在应用服务集群架构的基础上，将数据库分为主数据库（负责写操作）和从数据库（负责读操作）。
主从数据库之间进行数据同步，保持数据一致性。
提高数据库的读取性能，因为读操作可以分散到多个从数据库上。
增加数据库的可用性，因为即使主数据库出现故障，从数据库仍然可以提供读服务。

2.5冷热分离架构（引入缓存的架构）

出现原因：
海量请求导致数据库负载过高，站点响应再度变慢，引入缓存能帮助数据库更好的解决这个问题。

架构工作原理：多了缓存服务器，将热点数据全部放到缓存中去，不常用的数据再去查询我们的数据库。

特点：

引入缓存服务器（如Redis），将热点数据存储在缓存中，减少对数据库的访问请求。
根据二八原则（20%的热点数据支持80%的访问量），大幅提高系统性能。
需要注意缓存一致性、缓存击穿、缓存失效和缓存雪崩等问题。

2.6垂直分库架构

出现原因：
单机的写库会逐渐达到性能瓶颈，需求拆分数据库，数据表的数据量太大，处理压力太大，需要进行分表，为降低运维难度，业界逐渐研发了分布式数据库，库表天然支持分布式。

架构工作原理：数据库是由多个主从库或者存储集群构成，支持分布式大规模并行处理。

优点：数据库吞吐量大幅提升，不再是瓶颈。

缺点：

1.跨库join、分布式事务等问题，这些需要对应的解决方案，目前mpp都有对应的解决方案。

2.数据库和缓存结合目前能够抗住海量的请求，但是应用的代码整体耦合在一起，修改一行代码就需要整体重新发布。## 2.7微服务架构

2.7微服务架构

微服务是一种架构风格，按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级迭代。

架构工作原理：应用拆分成了多个微服务，微服务相互之间协作完成整个应用服务。

优点：

1.灵活性高，服务独立测试，部署升级，发布。

2.独立扩展：每个服务可以各自进行扩展

3.提高容错性：一个服务问题并不会让整个系统瘫痪

4.新技术的应用扩展容易：支持多种编程语言。

5.解决了人的问题

6.可以给不同的服务进行不同的部署。

缺点：

1.运维复杂变高，部署复杂,应用服务环境变得复杂。

2.资源使用变多

3.处理故障困难

2.8容器编排架构

借助容器化技术（如docker）将应用/服务可以打包为镜像，通过容器编排工具（如k8s）来动态分发和部署镜像，服务以容器化的方式运行。

出现原因：
1.微服务拆分细，服务多部署工作量大，配置复杂，容易出错。

2.微服务数量多扩缩容麻烦，容易出错，每次缩容再扩容重新配置服务对于的环境参数信息

3.微服务之间运行环境可能冲突，需要更多的资源来进行部署或者通过修改配置来解决冲突。

架构工作原理：应用拆分为了多个微服务，如用户服务… 每个微服务打包到一个容器中，相互协作完成系统功能，通过容器编排工具完成部署运维。

优点：

1.部署运维简单。

2.隔离性好

3.支持滚动更新。（版本更新那种，回退版本、更新版本 ：使用镜像替换即可）

缺点：

1.技术栈变多。（k8s/docker/SpringClound/Dubbo）

2.机器还是需要公司本身管理，非大促的时候需要闲置大量的机器资源，机器自身成本和运维成本都极高，资源利用率低，可以通过购买云厂商服务器解决。