【Docker#1】技术架构演进之路

一、概述

1. 基本概念

① 应用(Application) / 系统(System)：为了完成一整套服务的一个程序或者一组相互配合的程序群。

② 模块(Module) / 组件(Component)：当应用较复杂时，为了分离职责，将其中具有清晰职责的、内聚性强的部分，抽象出概念，便于理解。

③ 分布式(Distributed)：系统中的多个模块被部署于不同服务器之上，即可以将该系统称为 分布式系统。如： Web 服务器与数据库分别工作在不同的服务器上，或者多台 Web 服务器被分别部署在不同服务器上。

④ 集群(Cluster)：被部署于多台服务器上的、为了实现特定目标的一个/组特定的组件，整个整体被称为 集群。比如：多个 MySQL 工作在不同服务器上，共同提供数据库服务目标，可以被称为一组数据库集群。

⑤ 主(Master) / 从(Slave)：集群中，通常有一个程序需要承担更多的职责，被称为主;其他承担附属职责的被称为从。

⑥ 中间件(Middleware)：一类提供不同应用程序用于相互通信的软件，即处于不同技术、工具和数据库之间的桥梁。

⑦ 容器(Docker)：Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux 或 Windows 操作系统的机器上,也可以实现虚拟化。

⑧ 容器编排(K8S)：kubernetes，简称 K8s，是用8代替名字中间的8个字符 “ubermete” 而成的缩写。是一个 开源的、用于管理云平台中多个主机上的容器化的应用，Kubermetes 的目标是让部署容器化的应用简单并且高效。

2. 评价指标(Metric)

3. 常见对比和误区

✅ 分布式 vs 集群（通常不用太严格区分两者的细微概念）

⚠️ 实际开发中两者经常共存，如一个分布式系统可能包含多个集群。

✅ 高可用（HA） vs 高并发（HC）

小结：术语速记口诀（帮助记忆）

• 应用是整体，模块是分工；
• 分布式是分布，集群是集中；
• 主从有主次，中间件是桥；
• Docker是容器，K8s管容器；
• 可用看时间，响应看速度；
• 吞吐看总量，并发看瞬间。

二、架构演进

1. 单机架构

简介：应用服务和数据库服务共用一台服务器

出现原因：出现在互联网早期，访问量比较小，单机足以满足需求。

下面以电子商城为例，可以看到通过应用（划分了多个模块）和数据库在单个服务器上协作完成业务运行。

用户在浏览器中输入 www.baidu.com，首先经过 DNS 服务将域名解析成 IP 地址10.102.41.1，随后浏览器访问该 |P 对应的应用服务。

备注：

• DNS（Domain Name System，域名系统）是互联网的一项服务，它作为将域名和IP地址相互映射的一个分布式数据库。
  • 能够使人更方便地访问互联网，而不需要记住能够被机器直接读取的IP数串。
  • 通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）
• Tomcat 是一个非常适合初学者和小型项目的Java Web应用服务器

优点：部署简单、成本低

缺点：存在严重的性能瓶颈、数据库和应用互相竞争资源

2. 应用数据分离架构

简介：应用服务和数据库服务使用不同服务器。

出现原因：单机存在严重的资源竞争，导致站点变慢。

以电子商城为例，可以看到 应用和数据库在各自的服务器上通过网络协作完成业务运行。

优点：性能相比单机有提升、数据库单独隔离，不会因为应用把数据库搞坏，有一定的容灾能力

缺点：硬件成本变高，显而易见的多了一台服务器，性能有瓶颈，无法应对海量并发

3. 应用集群架构

简介：引入了负载均衡，应用以集群方式运作。

出现原因：单个应用不足以支持海量的并发请求，高并发的时候站点响应变慢。

以电子商城为例，可以看到应用不再是一个，而是变成了多个，通过负载均衡来支持海量的并发。

下面说明：

1. LVS/F5 主要负责负载均衡，在多个服务器之间分配流量，确保系统的高可用性和性能。
2. Nginx 既可以作为一个独立的 Web 服务器来提供静态内容，也可以作为反向代理来分发请求到后端服务器。
3. Tomcat 则专注于 Java 应用的部署和运行，是 Java 开发者常用的服务器之一。

优点

1. 应用服务可用性：应用满足高可用，不会一个服务出问题整个站点挂掉
2. 应用服务具备一定高性能：如果不访问数据库，应用相关处理通过扩展可以支持海量请求快速响应
3. 应用支持横向扩展

缺点

1. 数据库成为性能瓶颈，无法应对数据库的海量查询
2. 数据库是单点，没有高可用
3. 运维工作增多，扩展后部署运维工作增多，需要开发对应的工具应对快速部署
4. 硬件成本较高

4. 读写分离/主从分离架构

简介：将数据库读写操作分散到不同的节点上，数据库服务器搭建主从集群，一主一从、一主多从都可以。数据库主机负责写操作，从机只负责读操作。

出现原因：数据库成为瓶颈，而互联网应用一般读多写少，数据库承载压力大，主要是由这些读的请求造成的，那么我们可以把读操作和写操作分开。

以电子商城为例，可以看到存储服务器不再是一个，而是变成了多个，而且把读写操作分开减少数据库压力。

优点：数据库的读取性能提升；读取被其他服务器分担，写的性能间接提升；数据库有从库，数据库的可用性提高了。

缺点：当同步挂掉，或者同步延迟比较大时，写库和读库的数据不一致；服务器成本需要进一步增加

5. 冷热分离架构 – 引入缓存

简介：引入缓存，实行冷热分离，将热点数据放到缓存中快速响应。

出现原因：海量的请求导致数据库负载过高，站点响应速度变慢。

例如双十一秒杀的时候，秒杀的数据就可以放到 缓存服务器中

优点：大幅降低对数据库的访问请求，性能提升非常明显

缺点

• 带来了缓存一致性，缓存击穿，缓存失效，缓存雪崩等问题
• 服务器成本需要进一步增加
• 业务体量支持变大后，数据不断增加，数据库单表太大，单个表体量也太大，数据查询会很慢，导致数据库再度成为系统瓶颈

6. 垂直分库架构

简介：数据库的数据被拆分，数据库数据分布式存储，分布式处理，分布式查询，也可以理解为 分布式数据库架构

出现原因

1. 单机的写库会逐渐达到性能瓶颈，需要拆分数据库，数据表的数据量太大，处理压力太大，需要进行分表，为降低运维难度，业界逐渐研发了分布式数据库，库表天然支持分布式。
2. 可以以 集群 为单位，进行部署

优点

• 数据库吞吐量大幅提升，不再是瓶颈
• 跨库 join、分布式事务等问题，这些需要对应的去进行解决，目前的 mpp（大规模并行处理） 都有对应的解决方案

缺点：数据库和缓存结合目前能够抗住海量的请求，但是应用的代码整体耦合在一起，修改一行代码需要整体重新发布

7. 微服务架构

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

出现原因

1. 扩展性差：应用程序无法轻松扩展，因为每次需要更新应用程序时，都必须重新构建整个系统
2. 持续集成困难：一个很小的代码改动，也需要重新部署整个应用，无法频繁并轻松地发布版本
3. 不可靠：即使系统的一个功能不起作用，可能导致整个系统无法工作
4. 不灵活：无法使用不同的技术栈构建单体应用程序
5. 代码维护难：所有功能耦合在一起，新人不知道何从下手

应用如下：

优点

1. 灵活性高：服务独立测试、部署、升级、发布
2. 独立扩展：每个服务可以各自进行扩展
3. 提高容错性：一个服务问题并不会让整个系统瘫痪
4. 新技术的应用容易：支持多种编程语言

缺点

1. 运维复杂度高：业务不断发展，应用和服务都会不断增多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题。
   • 此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难（后面引入了 K8S~)
2. 资源使用变多：所有这些独立运行的微服务都需要占用内存和CPU
3. 处理故障困难：一个请求跨多个服务调用，需要查看不同服务的日志完成问题定位

8. 容器编排架构

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

出现原因

1. 微服务拆分细，服务多部署工作量大，而且配置复杂，容易出错
2. 微服务数量多扩缩容麻烦，而且容易出错，每次缩容后再扩容又需要重新配置服务对应的环境参数信息
3. 微服务之间运行环境可能冲突，需要更多的资源来进行部署或者通过修改配置来解决冲突

抽象理解如下：

• 应用–快递
• 容器–docker–箱子
• 镜像–包裹
• k8s–快递公司，使几千台 docker 可以快速部署，减少了运维 环境配置 的工作量
• 服务端–收货地

优点

1. 部署、运维简单快速：一条命令就可以完成几百个服务的部署或者扩缩容
2. 隔离性好：容器与容器之间文件系统、网络等互不影响，不会产生环境冲突
3. 轻松支持滚动更新：版本间切换都可以通过一个命令完成升级或者回滚

缺点

1. 技术栈变多，对研发团队要求高
2. 机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都很高，资源利用率低，可以通过购买云厂商服务器解决。

三、补充说明

1. 上层传输

WAF（Web Application Firewall，Web 应用防火墙）

• 作用：保护 Web 应用程序免受常见的攻击，如 SQL 注入和 XSS（跨站脚本）。
• 功能：通过监控和过滤 Web 流量，阻止恶意请求，提高网站安全性。

CLB（Cloud Load Balancer，云负载均衡）

• 作用：将流量分发到多台服务器，保证服务的高可用性和可靠性。
• 功能：在多台服务器间分摊流量压力，提高系统的稳定性。

SLB（Server Load Balancer，服务器负载均衡）

• 作用：类似于 CLB，将流量分配到多台服务器，但通常用于私有网络或内网环境。
• 功能：实现高可用的负载分担，提高资源利用率。

API（Application Programming Interface，应用程序接口）

• 作用：提供应用之间的通讯标准，使它们能够互相调用功能。
• 功能：定义了不同软件系统之间如何交互的规则和协议。

网关（Gateway）

• 作用：作为系统的入口，控制流量、转发请求、保护后端服务。
• 功能：实现流量控制、身份验证和日志记录等功能。

K8S（Kubernetes，容器编排平台）

• 作用：管理和自动化容器化应用的部署、扩展和运维。
• 功能：支持容器集群的调度和管理，常用于微服务架构。

TKE：腾讯云的 Kubernetes 服务。 ACK：阿里云的 Kubernetes 服务。

2. 框架

Spring Cloud

• 作用：用于构建分布式系统的框架，提供配置管理、服务发现、断路器等工具。
• 功能：让微服务的管理和调用更加便捷，适合云原生应用的开发。

Dubbo

• 作用：一种 RPC（远程过程调用）框架，用于服务之间的调用。
• 功能：支持高效的服务发现和负载均衡，适合大规模微服务架构。

TSF（Tencent Service Framework，腾讯服务框架）

• 作用：腾讯云提供的微服务架构平台，支持微服务治理和监控。
• 功能：帮助企业快速搭建微服务体系，实现分布式系统管理。

Istio

• 作用：服务网格（Service Mesh）框架，管理微服务之间的通信。
• 功能：实现流量管理、故障恢复和安全策略，适合大型微服务集群。

3. 数据处理

缓存数据

Redis

• 作用：高性能的键值对存储数据库，常用作缓存。
• 功能：支持数据的快速存储和读取，适用于高并发场景。

Tair

• 作用：阿里巴巴开发的分布式缓存系统。
• 功能：提供高性能数据缓存，支持大规模访问。

Keewideb

• 作用：类似 Redis 的缓存系统，专注于高效的缓存服务。
• 功能：提供快速的数据读取和写入。

基础数据

MySQL

• 作用：关系型数据库管理系统，广泛应用于 Web 开发。
• 功能：支持结构化数据的存储、查询和管理，数据一致性强。

PolarDB

• 作用：阿里云推出的云数据库，兼具 MySQL 兼容性和高性能。
• 功能：支持弹性扩展和高并发访问，适合企业级应用。

TDSQL

• 作用：腾讯云推出的分布式数据库，适合金融级业务。
• 功能：提供高可用和强一致性，支持海量数据的分布式存储。

TiDB

• 作用：分布式 NewSQL 数据库，兼容 MySQL，适合大数据处理。
• 功能：支持水平扩展和强一致性，适合 OLTP 和 OLAP 场景。

GBase

• 作用：国产数据库，支持事务和分析，适合大数据处理。
• 功能：适合于高并发访问的大规模数据处理任务。

其他

OSS/COS/MinIO

• 作用：对象存储服务，用于存储大量非结构化数据，如图片、视频。
• OSS：阿里云对象存储服务。
• COS：腾讯云对象存储服务。
• MinIO：开源对象存储解决方案。

ES 集群（Elasticsearch）

• 作用：分布式搜索和分析引擎，支持全文检索。
• 功能：适合日志分析和大规模文本数据的搜索，广泛应用于日志管理和数据分析。

MongoDB 集群

• 作用：分布式文档数据库，适合处理半结构化数据。
• 功能：支持高并发和大数据量存储，灵活性高。

MaxCompute/EMR/GFS

1. MaxCompute：阿里云的分布式计算服务，支持大数据分析。
2. EMR（Elastic MapReduce）：阿里云和 AWS 提供的分布式数据处理服务，基于 Hadoop。
3. GFS（Google File System）：谷歌的分布式文件系统，用于存储海量数据。

这些技术广泛应用于分布式系统和云计算，适用于构建可扩展、高效的现代化应用。

4. 主要思想

1. 一个人扛不住，喊兄弟过来
2. 软件上，没有什么是加一层 解决不了的，出问题了加一层就好了

“背锅”演进之路：通过对架构的优化，解决系统的问题，如图下所示：

一些思考:

1. 如何决策 要不要演进？=> 结合 满足 实际业务需求 即可
2. 架构必须这么演进吗？=>结合 实际情况
3. 架构必须是这么几个么？=> 可以自行 增减，结合业务
4. docker 的核心作用？=> 容器化 实现细化