Docker 【 技术架构(1)】

一、基础概念

在正式开始前,我们先认识几个"熟脸",后面会反复出现。

概念 一句话解释 例子
应用/系统 提供一整套服务的程序群 淘宝App(下单、支付、物流全包)
模块/组件 应用里干某一件事的小分队 购物车模块、订单模块
分布式 不同模块放在不同的机器上,通过网络配合干活 Web服务器一台,数据库另一台
集群 多台机器干同一件事,看起来像一台超级机器 10台Tomcat组成应用集群
主/从 集群里有一个"老大"负责写,其他人负责读 MySQL主库写,从库读
中间件 两个程序之间的"传话筒" Nginx、Redis、MyCat
容器 把应用和它的环境打包成一个"箱子" Docker镜像
容器编排 管理成千上万个箱子的"码头调度员" Kubernetes (K8s)

衡量架构好不好的几个指标

  • 可用性 (Availability):一年里系统能正常工作的占比。99.99%叫"四个9",一年宕机不超过52分钟。

  • 响应时长 (RT):从你点"下单"到页面告诉你"成功"用了多久。越快越好。

  • 吞吐量 vs 并发

    • 并发:同一时刻有多少请求打进来(比如收费站同时开了2个口子)。

    • 吞吐:一段时间处理了多少请求(比如一分钟过了20辆车)。

    平时吹牛说的"高并发"其实是高吞吐的近义词,别太较真。


二、阶段一:单机架构

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

用户 → DNS解析 → 单机服务器(应用+数据库)

架构特点

  • 应用服务(用户/商品/交易)和数据库部署在同一台服务器

  • 架构简单,无需专业运维


三、阶段二:应用数据分离架构

遇到的问题 :用户量上升,单机硬件资源逼近极限

解决方案 :将应用服务器数据库服务器分离部署。

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

优缺点 :

✅ 优点

  1. 成本可控:相比后续集群架构投入更低;
  2. 性能提升:应用、数据库资源隔离,不再争抢硬件资源,整体性能优于单机;
  3. 故障隔离:应用宕机、程序异常不会破坏数据库数据,具备基础容灾能力。

❌ 缺点

  1. 硬件成本上升:需要采购两台及以上独立服务器;
  2. 性能存在上限:单应用 + 单库架构承载能力有限,无法支撑海量高并发业务

技术案例

中小型初创电商、中小企业后台管理系统、中小型门户网站,普遍采用该架构。


四、阶段三:应用服务集群架构

遇到的问题:出现爆款,单台应用服务器扛不住了!

两种扩展方案对比

方案 名称 优势 劣势
Scale Up 纵向扩展(升级硬件) 无需改代码 价格非线性增长,有上限
Scale Out 横向扩展(加服务器) 成本低,上限高 系统更复杂

最终选择 :Scale Out + 负载均衡(Load Balance)

负载均衡算法

  • Round-Robin:轮询,依次分配(公平)

  • Weight-Round-Robin:加权轮询,能者多劳

  • 一致哈希:相同用户固定分配到某台服务器(类似专属客服)

相关软件 :Nginx、HAProxy、LVS、F5

🌰 例子:饭店生意火爆,从1个厨师增加到5个厨师,前台(负载均衡)负责给客人分配座位。

优点:

应用服务高可用:应用满足高可用,不会一个服务出问题整个站点挂掉

应用服务具备**一定高性能:如果不访问数据库,**应用相关处理通过扩展可以支持海量请求快速响应

应用服务有一定扩展能力:支持横向扩展

缺点:

数据库成为性能瓶颈,无法应对数据库的海量查询

数据库是单点,没有高可用

运维工作增多**,扩展后部署运维工作增多**,需要开发对应的工具应对快速部署

硬件成本较高


五、阶段四:读写分离 / 主从分离

遇到的问题

无论加多少应用服务器,所有请求最终都打到数据库,数据库成为瓶颈。

为什么不能直接扩展数据库?

因为数据一致性无法保障!想象一下银行账户:转账后一个库改了,另一个没改,用户看到的余额就错了。

解决方案一主多从

关键点

  • 主库负责写入(增删改),从库负责读取

  • 从库数据通过同步机制从主库复制

  • 大部分系统读多写少(100次读 vs 1次写),读写分离效果显著

  • 应用中需要对读写请求做分离处理,所以可以利用一些数据库中间件,将请求分离的职责托管出去

相关软件 :MyCat、TDDL、Amoeba、Cobar

🌰 例子 :银行只有一个总账本(主库),但每个网点都可以查余额(从库),查完的数据定期和总账本同步。

相关推荐
她的男孩10 小时前
数据权限为什么不能只靠注解?Forge 的 Mapper 层 SQL 改写源码拆解
java·后端·架构
小爷毛毛_卓寿杰10 小时前
我把 397B 的「Agentic 大脑」塞进了 Xinference,一键部署 Nex-N2
人工智能·架构·github
柒和远方12 小时前
从一次工程审查看 AI 学习产品的边界兜底:RAG 资料链路一致性实战
前端·后端·架构
raindesound12 小时前
Android+QC modem手机通信模块技术分析 (2)
架构
raindesound12 小时前
Android+QC modem手机通信模块技术分析 (4)
架构
raindesound12 小时前
Android+QC modem手机通信模块技术分析 (1)
架构
程序员cxuan15 小时前
读懂 Claude Code 架构分析系列,第一篇,开始!
人工智能·后端·架构
Yeats_Liao16 小时前
14:Servlet中的页面跳转-Java Web
java·后端·架构
raindesound16 小时前
计算机基础:ADT(Abstract Data Type)抽象数据类型 (2)
架构
武子康16 小时前
调查研究-201 Rust 里的 dev build 和 release build:为什么同一份代码性能差这么多?
后端·架构·rust