【Docker】技术架构演进

 

目录

一. 单机架构

二.应用数据分离架构

三.应用服务集群架构——应用扛不住

四. 读写分离/主从分离架构——数据库扛不住

五. 引入缓存 -- 冷热分离架构

六.垂直分库

七.微服务

八.容器化引入——容器编排架构

尾声

---

为什么在Docker的文章里面加入技术架构这么一章呢？

我们学习东西，都是为了解决问题的。

而我们Docker到底能解决什么问题，这就需要在技术架构里面得知。

接下来，我将一一讲解八大架构演进

1. 单机架构
2. 应用数据分离架构
3. 应用服务集群架构
4. 读写分离/主从分离架构
5. 冷热分离架构
6. 垂直分库架构
7. 微服务架构
8. 容器编排架构

一. 单机架构

背景

初期，我们需要利用我们精干的技术团队，快速将业务系统投入市场进行检验，并且可以迅速响应变化要求。但好在前期用户访问量很少，没有对我们的性能、安全等提出很高的要求，而且系统架构简单，无需专业的运维团队，所以选择单机架构是合适的。

---

1.简介

单机架构就是应用服务和服务器共用一台服务器。

单机架构就是“所有东西都塞在一台服务器里”——你的网站程序、数据库、文件（比如图片）全放在同一台机器上运行，像个小杂货铺，所有活儿都自己干。

我们举一个例子

我们将应用服务和服务器都放到同一台机器里。 

---

2.出现原因

1. 早期技术简单：互联网初期用户少、功能简单，一台机器就够用。
2. 省钱省事：初创公司或小项目没钱买多台服务器，直接“一锅端”最便宜。
3. 门槛低：开发、测试、部署不用考虑网络和分布式问题，上手容易。

---

3.架构工作原理

1. 用户访问：用户通过浏览器或APP发请求（比如看网页）。

2. 单机处理：这台服务器同时干两件事：

   • 运行程序：处理用户请求（比如生成网页内容）。

   • 读写数据：根据用户的请求去直接操作自己硬盘上的数据库或文件。

3. 返回结果：服务器把结果（比如网页或图片）直接返回给用户。

类比：就像一个人开个小店，自己收银、搬货、打扫，啥都自己干。

---

4.技术案例

1. 早期个人博客：用WordPress搭的博客，程序+MySQL数据库全装在一台服务器。

2. 学生项目：毕业设计或课程作业的网站（比如用Spring Boot+MySQL）。

3. 本地测试环境：程序员在自己电脑上跑的小Demo（比如XAMPP一键安装包）。

---

5.架构优缺点

优点：

• 便宜：只买一台服务器，电费网费都省。

• 简单：不用折腾网络、集群，开发调试快。

• 好维护：出问题就检查这一台机器，不用到处找。

缺点：

• 性能差：人一多就卡死（比如双11你一个人收银，排队排到崩溃）。

• 容易挂：机器坏了、停电了，整个服务直接瘫痪。

• 竞争资源：数据库和应用相互竞争资源

• 数据危险：硬盘坏了，所有数据可能全丢（没备份的话）。

总结：适合“小而美”，但扛不住大流量和高要求。

---

相关软件

• Web 服务器软件：Tomcat、Netty、Nginx、Apache 等
• 数据库软件：MySQL、Oracle、PostgreSQL、SQL Server 等

二.应用数据分离架构

背景

随着系统的上线，我们不出意外地获得了成功。

市场上出现了一批忠实于我们的用户，使得系统的访问量逐步上升，逐渐逼近了硬件资源的极限，同时团队也在此期间积累了对业务流程的一批经验。

面对当前的性能压力，我们需要未雨绸缪去进行系统重构、架构挑战，以提升系统的承载能力。

但由于预算仍然很紧张，我们选择了将应用和数据分离的做法，可以最小代价的提升系统的承载能力。

---

简介

应用数据分离架构就是把“干活的程序”和“存数据的仓库”分开放到两台不同的服务器上——比如网站程序跑在一台机器，数据库单独跑在另一台机器，相当于雇了两个人，一个负责算账，一个负责搬货，分工合作。

我们的应用服务器来通过网络对存储服务器进行访问 

---

出现原因

1. 单机扛不住了：

   • 用户量大了，程序（比如网站后台）和数据库（比如订单数据）抢同一台机器的CPU、内存，结果谁都跑不快。

2. 数据安全需求：

   • 数据库单独放一台机器，方便做备份、加密，避免被黑客一锅端。

3. 性能优化：

   • 程序服务器可以专注处理业务逻辑（比如生成网页），数据库服务器专注读写数据，各干各的更快。

一句话：单机忙不过来了，拆开才能活下去。

---

架构工作原理

1. 用户发请求：比如点击“购买商品”。

2. 应用服务器干活：

   • 运行程序逻辑（检查库存、计算价格）。

3. 数据库服务器响应：

   • 应用服务器通过网络问数据库：“库存够吗？” → 数据库查完回复：“还剩10件”。

4. 返回结果：应用服务器把结果包装成网页或数据，返回给用户。

类比：

• 应用服务器像服务员，负责接待顾客、处理订单。

• 数据库服务器像仓库管理员，只管存取货物。

• 两人用对讲机（网络）沟通，分工明确。

---

技术案例

1. 中小型电商网站：

   • 应用服务器：用Java（Spring Boot）或Python（Django）处理用户下单、支付。

   • 数据库服务器：MySQL单独部署，存商品信息、订单记录。

   • 场景：每天几千订单，单机数据库扛得住，但程序和数据库必须分开避免互相拖累。

2. 企业内容管理系统（CMS）：

   • 应用服务器：PHP或Node.js生成网页内容。

   • 数据库服务器：单独用PostgreSQL存文章、用户权限数据。

   • 场景：公司内部使用，保证数据安全性和编辑效率。

3. 在线教育平台（初期）：

   • 应用服务器：Go或Ruby处理视频上传、用户登录。

   • 数据库服务器：MongoDB存用户信息、课程数据。

   • 场景：学生同时在线看课，程序和数据分开后响应更快。

---

架构优缺点

优点：

1. 性能提升：程序和数据库不抢资源，速度更快。

2. 安全性加强：数据库单独保护，被黑了程序还能跑。

3. 独立扩展：数据库慢了就升级数据库服务器，不用动程序服务器。

缺点：

1. 加钱：得多买一台服务器，网费电费都翻倍。

2. 网络延迟：程序和数据库隔着网络“打电话”，偶尔会卡一下（比如查数据慢0.5秒）。

3. 运维变麻烦：要管两台机器，备份、监控都得做两套。

总结：

• 适合：访问量中等（比如日活1万~10万）、数据量开始增长的场景。

• 不适合：超大规模高并发（比如双11秒杀），得继续升级成集群或分库分表。

三.应用服务集群架构——应用扛不住

背景

我们的系统受到了用户的欢迎，并且出现了爆款，单台应用服务器已经无法满足需求了。我们的单机应用服务器首先遇到了瓶颈，摆在我们技术团队面前的有两种方案，大家针对方案的优劣展示了热烈的讨论：

1. 垂直扩展/纵向扩展Scale Up。通过购买性能更优、价格更高的应用服务器来应对更多的流量。这种方案的优势在于完全不需要对系统软件做任何的调整；但劣势也很明显：硬件性能和价格的增长关系是非线性的，意味着选择性能2倍的硬件可能需要花费超过4倍的价格，其次硬件性能提升是有明显上限的。
2. 水平扩展/横向扩展Scale Out。通过调整软件架构，增加应用层硬件，将用户流量分担到不同的应用层服务器上，来提升系统的承载能力。这种方案的优势在于成本相对较低，并且提升的上限空间也很大。但劣势是带给系统更多的复杂性，需要技术团队有更丰富的经验。

经过团队的学习、调研和讨论，最终选择了水平扩展的方案，来解决该问题，但这需要引入一个新的组件——负载均衡：为了解决用户流量向哪台应用服务器分发的问题，需要一个专门的系统组件做流量分发。实际中负载均衡不仅仅指的是工作在应用层的，甚至可能是其他的网络层之中。同时流量调度算法也有很多种，这里简单介绍几种较为常见的：

1. Round-Robin轮询算法。即非常公平地将请求依次分给不同的应用服务器。
2. Weight-Round-Robin轮询算法。为不同的服务器（比如性能不同）赋予不同的权重(weight),能者多劳。
3. 一致哈希散列算法。通过计算用户的特征值（比如IP地址）得到哈希值，根据哈希结果做分发，优点是确保来自相同用户的请求总是被分给指定的服务器。也就是我们平时遇到的专项客户经理服务。

---

简介

应用服务集群架构就是雇一群服务员——把同一个程序部署到多台服务器上，通过“调度员”（负载均衡器）把用户请求分给不同的服务器处理，避免一个人累死，其他人闲着。

这个也就是多台应用服务器，一台数据库服务器！！！

---

出现原因

1. 单台服务器撑不住了：

   • 用户量暴涨（比如促销活动），一台机器CPU跑满，直接卡死。

2. 怕宕机：

   • 单台服务器挂了，整个服务瘫痪，老板要砍人。

3. 想提升响应速度：

   • 多台机器并行处理请求，用户不用排队等。

---

架构工作原理

1. 用户发请求：比如访问网站首页。

2. 负载均衡器分配任务：

   • 像“调度员”一样，按轮询、随机或权重算法，把请求分给集群中的某一台应用服务器。

3. 应用服务器干活：

   • 每台服务器运行相同的程序，独立处理分到的请求（比如生成网页、调用数据库）。

4. 返回结果：处理完的结果直接返回给用户。

---

技术案例

   以电子商城为例，如下图所示：用户在访问服务器时，先通过负载均衡技术将请求发送给对应的服务器节点，负载均衡再根据分配策略将请求发送给合适的应用服务器，然后应用服务器再去查询商品，数据库服务器和应用服务器之间还是以网络的方式进行通信，之后服务层把拿到的数据返回给用户（这里负载均衡有两种模式，一种是返回的流量经过负载均衡，一种是流量不经过负载均衡）

---

架构优缺点

优点：

1. 能扛高并发：人多就加机器，理论上无限扩展。

2. 高可用：一台挂了，其他机器顶上，用户无感知。

3. 灵活扩容：流量高峰临时加机器，低谷减机器，省钱。

缺点：

1. 烧钱：服务器数量翻倍，成本也翻倍。

2. 复杂度飙升：

   • 要解决Session共享、配置同步、负载均衡策略等问题。

   • 监控和日志收集变难（得用ELK或Prometheus）。

3. 依赖基础设施：

   • 负载均衡器自己不能挂，否则全瘫（通常得做双机热备）。

---

相关软件

• 负载均衡软件：Nginx、HAProxy、LVS、F5 等

四. 读写分离/主从分离架构——数据库扛不住

上一节提到，我们把用户的请求通过负载均衡分发到不同的应用服务器之后，可以并行处理了，并且可以随着业务的增长，可以动态扩张服务器的数量来缓解压力。

但是现在的架构里，无论扩展多少台服务器，这些请求最终都会从数据库读写数据，到一定程度之后，数据的压力称为系统承载能力的瓶颈点。

我们可以像扩展应用服务器一样扩展数据库服务器么？

答案是否定的，因为数据库服务有其特殊性：如果将数据分散到各台服务器之后，数据的一致性将无法得到保障。

所谓数据的一致性，此处是指：针对同一个系统，无论何时何地，我们都应该看到一个始终维持统一的数据。

想象一下，银行管理的账户金额，如果收到一笔转账之后，一份数据库的数据修改了，但另外的数据库没有修改，则用户得到的存款金额将是错误的。

我们采用的解决办法是这样的，保留一个主要的数据库作为写入数据库，其他的数据库作为从属数据库。

从库的所有数据全部来自主库的数据，经过同步后，从库可以维护着与主库一致的数据。然后为了分担数据库的压力，我们可以将写数据请求全部交给主库处理，但读请求分散到各个从库中。

由于大部分的系统中，读写请求都是不成比例的，例如100次读1次写，所以只要将读请求由各个从库分担之后，数据库的压力就没有那么大了。

当然这个过程不是无代价的，主库到从库的数据同步其实是有时间成本的，但这个问题我们暂时不做进一步探讨。

---

简介

读写分离就是把数据库分成两个角色：一个专门负责写数据（主库），其他几个负责读数据（从库）。就像饭店里主厨只管炒菜（写数据），服务员只管端菜（读数据），分工明确。

---

出现原因

直接原因：扛不住高并发！

• 比如一个电商网站，每天1万人疯狂刷商品（读数据），但只有100人下单（写数据）。如果所有读写请求都怼到同一个数据库，读操作会把数据库累趴下。

• 主从分离后，读请求分摊到多个从库，主库专心处理写操作，整体性能提升。

---

架构工作原理

• 写操作：用户下单、修改数据等操作，全部交给主库（主厨）。

• 数据同步：主库炒完菜（写完数据），把菜谱（数据变更记录）发给所有从库（服务员）。

• 读操作：用户查订单、看商品等操作，全由从库处理（服务员端菜）。

✅ 关键点：主库和从库之间通过日志（如MySQL的binlog）同步数据，通常有短暂延迟（比如1秒内）。

---

技术案例

• MySQL主从复制：最常见方案，主库写，从库通过binlog同步数据。

• Redis哨兵模式：主Redis处理写，从Redis处理读，哨兵监控主库故障自动切换。

• MongoDB副本集：一个主节点写，多个从节点读，自动选举新主节点。

• 中间件工具：如MyCat、ProxySQL，自动把读请求路由到从库，写请求发给主库。

---

架构优缺点

优点

• 性能提升：读操作分摊到多个从库，轻松应对高并发读。

• 高可用：主库挂了，从库可以临时顶替（但通常需要手动切换）。

• 数据备份：从库天然是主库的备份，防止数据丢失。

缺点

• 数据延迟：主库刚写入，从库可能查不到（比如下单后立刻查订单）。

• 主库单点风险：写操作集中在主库，主库挂了整个系统无法写入。

• 架构变复杂：要维护主从同步、处理故障切换，运维成本高。

---

相关软件

• MyCat、TDDL、Amoeba、Cobar 等类似数据库中间件等

五. 引入缓存 -- 冷热分离架构

随着访问量继续增加，发现业务中一些数据的读取频率远大于其他数据的读取频率。

我们把这部分数据称为热点数据，与之相对应的是冷数据。

针对热数据，为了提升其读取的响应时间，可以增加本地缓存，并在外部增加分布式缓存，缓存热门商品信息或热门商品的 html 页面等。

通过缓存能把绝大多数请求在读写数据库前拦截掉大大降低数据库压力。

其中涉及的技术包括:使用memcached作为本地缓存，使用Redis 作为分布式缓存，还会涉及缓存一致性、缓存穿透/击穿、缓存雪崩、热点数据集中失效等问题。

---

 简介

冷热分离就是把数据分库成「热数据」（经常用）和「冷数据」（很少用），热数据放高速存储（比如内存缓存数据库），冷数据扔到慢速存储（比如存储数据库）。

就像家里冰箱放常吃的菜（热数据），地下室存过季衣服（冷数据），各找各的地儿。

---

出现原因 

直接原因：资源浪费！

• 比如一个社交App，用户最近3天的动态被疯狂查看（热数据），但3个月前的动态几乎没人看（冷数据）。如果所有数据都放昂贵的缓存里，成本爆炸。

• 冷热分离后，高频访问的数据快速响应，低频数据低成本存储，省资源又保性能。

---

工作原理 

• 数据分类：根据访问频率或时间区分冷热（比如最近3天是热数据，超过30天是冷数据）。

• 热数据处理：热数据塞进缓存（如Redis）或高速数据库（如内存数据库），保证快速访问。

• 冷数据归档：冷数据迁移到便宜存储（如硬盘、对象存储、归档数据库），甚至压缩保存。

• 动态升降级：冷数据被访问时，可能临时拉回热存储（比如突然有人翻旧帖子）。

✅ 关键点：冷热分离不是一刀切，而是动态调整（比如定时任务扫描数据访问频率）。

---

 优缺点

优点（为什么要用？）

• 省钱：内存和SSD贵，冷数据用廉价存储，成本直降。

• 性能高：热数据在高速存储中，响应速度飞起。

• 扩展性好：冷数据可无限堆积到低成本存储（比如云对象存储）

缺点（坑在哪里？）

• 数据迁移麻烦：冷热数据要来回倒腾，可能影响业务（比如迁移时查询卡顿）。

• 冷数据访问慢：查历史数据得像翻箱倒柜，用户体验打折。

• 分类策略难：如何定义「冷」和「热」？规则定不好，可能热数据被误杀。

---

相关软件

•  Memcached、Redis 等缓存软件

六.垂直分库

随着业务的数据量增大，大量的数据存储在同一个库中已经显得有些力不从心了， 所以可以按照业务，将数据分别存储。

比如针对评论数据，可按照商品 ID 进行 hash， 路由到对应的表中存储；

针对支付记录，可按照小时创建表，每个小时表继续拆分为 小表，使用用户ID或记录编号来路由数据。

只要实时操作的表数据量足够小，请求能 够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高 性能。

其中前面提到的Mycat也支持在大表拆分为小表情况下的访问控制。

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

数据库设计到这种结构时，已 经可以称为分布式数据库，但是这只是一个逻辑的数据库整体，数据库里不同的组成 部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由Mycat实现， SQL的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果 的汇总可能由数据库接口层来实现等等，这种架构其实是MPP（大规模并行处理）架 构的一类实现。

---

简介

垂直分库就是按业务功能把一个大数据库拆成多个小数据库，比如订单、用户、商品各自独立成库，就像把大超市拆成服装店、食品店、家电店，各管一摊互不干扰。

垂直分库就像分宿舍——男生住A栋，女生住B栋，互不打扰。好处是男生打游戏不会吵到女生（业务隔离），缺点是谈恋爱得跨楼跑腿（跨库查询麻烦）。

---

出现原因 

直接原因：业务打架！

• 场景举例：

  • 一个电商系统，订单表和用户表在一个库里。

  • 双11时，每秒1万次订单写入（疯狂写订单表），同时用户登录查信息（频繁读用户表）。

  • 结果：订单写入把数据库CPU打满，用户登录卡成狗。

• 本质问题：

  • 不同业务混在一个库，互相抢资源。

  • 单库表太多，维护像在垃圾堆里找东西。

---

工作原理

• 拆分原则：

  • 按业务边界切分（比如用户相关表归用户库，订单相关表归订单库）。

  • 每个库独立部署在不同服务器（物理隔离）。

• 运行过程：

  1. 用户注册 → 写入用户库的用户表。

  2. 用户下单 → 先查用户库（验证用户状态），再写订单库的订单表。

  3. 查订单详情 → 从订单库读订单数据，从商品库读商品信息。

• 关键点：

  • 应用层需要知道数据在哪个库（比如代码里配置多个数据库连接）。

  • 跨库操作无法直接联表查询（比如查“用户买过哪些商品”需要分别查用户库和订单库，再代码里拼数据）。

---

实际案例 

• 电商系统拆分：

  • 用户库：用户表、地址表、登录日志表。

  • 订单库：订单表、支付流水表、退款表。

  • 商品库：商品表、库存表、分类表。

  • 营销库：优惠券表、活动配置表。

• 论坛系统拆分：

  • 用户库：用户信息、粉丝关系。

  • 帖子库：帖子内容、点赞记录。

  • 评论库：评论内容、回复记录。

• 工具支持：

  • ShardingSphere：用配置指定哪些表路由到哪个库。

  • 业务代码硬编码：不同业务模块用不同的数据库连接（简单粗暴但有效）。

---

优缺点 

优点（为什么要用？）

• 性能提升：

  • 订单高频写入不再影响用户查询（物理隔离）。

  • 单个库变小，索引效率更高（比如用户库只需维护用户表的索引）。

• 业务解耦：

  • 各团队专注自己的库（用户团队改用户表不用怕影响订单服务）。

• 独立扩展：

  • 给订单库上SSD硬盘，用户库用普通硬盘（按业务需求花钱）。

  • 订单库可以单独加服务器应对大促。

缺点（坑在哪里？）

• 跨库查询要命：

  • 查“用户最近买的商品”需要先查订单库拿商品ID，再查商品库拿详情（代码里手动拼接，性能差）。

  • 无法用SQL直接JOIN用户表和订单表（因为不在同一个库）。

• 分布式事务头痛：

  • 用户扣余额（用户库）和生成订单（订单库）要保证同时成功，只能用复杂方案（如Seata）或最终一致性。

• 维护成本高：

  • 每个库要单独备份、监控、优化。

  • 代码里一堆数据库连接配置，容易搞错。

---

相关软件

• Greenplum、TiDB、Postgresql XC、HAWQ等，商用的如南大通用的GBase、 睿帆科技的雪球DB、华为的LibrA 等

七.微服务

随着人员增加，业务发展，我们将业务分给不同的开发团队去维护，每个团队独 立实现自己的微服务，然后互相之间对数据的直接访问进行隔离，可以利用 Gateway、 消息总线等技术，实现相互之间的调用关联。甚至可以把一些类似用户管理等业务提 成公共服务。

 

---

简介

微服务就是把一个臃肿的「单体系统」拆成一堆独立的小服务，每个服务只管一件事（比如用户服务只负责登录、订单服务只管下单），就像把大公司拆成小部门，各司其职，互不干扰。

微服务就像开连锁店——总店（网关）接单，分店各自炒菜（独立服务）。好处是分店独立运营（开发快），坏处是协调麻烦（得打电话确认库存）。

---

出现原因 

直接原因：单体系统变“屎山”！

• 场景举例：

  • 一个电商系统初期所有功能（用户、订单、商品）都写在一个代码包里。

  • 3年后代码量百万行，每次改需求就像在迷宫找出口，测试要3天才能上线。

  • 双11想扩容订单功能，结果不得不把整个系统扩容，浪费资源。

• 本质问题：

  • 开发效率低：几十人改同一个代码库，天天冲突。

  • 维护困难：一个BUG可能引发全站崩溃。

  • 无法针对性扩展：促销时订单模块压力大，但必须连带扩容用户模块。

---

工作原理

• 拆分服务：

  • 用户服务：只管注册、登录、改密码。

  • 订单服务：只管下单、支付、退款。

  • 商品服务：只管查商品、扣库存。

• 独立运行：

  • 每个服务自己单独部署，用不同的技术栈（比如用户服务用Java，商品服务用Go）。

  • 服务之间通过API通信（比如HTTP或RPC），就像部门之间发邮件协作。

• 核心机制：

  • 注册中心（如Nacos）：所有服务上线后到“电话簿”登记自己的地址，其他服务需要时去查。

  • 网关（如Gateway）：统一入口，负责鉴权、限流、路由（比如用户请求先过网关，再转发到订单服务）。

  • 配置中心：统一管理所有服务的配置（比如数据库密码、开关参数）。

---

 技术案例（实际应用）

• Spring Cloud全家桶：

  • Eureka/Nacos：服务注册与发现。

  • Feign：服务间HTTP调用。

  • Ribbon：负载均衡（轮流调用多个订单服务实例）。

  • Hystrix：熔断降级（订单服务挂了，直接返回默认提示，避免雪崩）。

• Dubbo：阿里开源的RPC框架，高性能服务调用。

• 实际拆分案例：

  • 用户服务：独立数据库，提供/user/login、/user/info接口。

  • 订单服务：独立数据库，提供/order/create、/order/pay接口。

  • 商品服务：Redis缓存热门商品，提供/product/detail接口。

---

优缺点

优点（为什么要用？）

• 独立开发部署：

  • 用户团队改登录逻辑，无需通知订单团队，自己测试完就能上线。

• 故障隔离：

  • 商品服务挂了，用户依然能登录，订单依然能下单（只是看不到商品详情）。

• 技术自由：

  • 订单服务用Java，用户服务用Python，哪个合适用哪个。

• 弹性扩展：

  • 双11订单服务扩容到100台机器，用户服务只用10台。

缺点（坑在哪里？）

• 复杂度爆炸：

  • 原本1个系统变成30个服务，监控、日志、调试难度翻倍。

  • 服务调用链路过长（A→B→C→D），查一个BUG要翻遍所有日志。

• 网络问题：

  • 服务间通信依赖网络，一次下单可能调用5个服务，网络抖动导致超时。

• 分布式事务：

  • 用户扣款（用户服务）和生成订单（订单服务）要保证同时成功，只能用复杂方案（如Seata）或妥协最终一致性。

• 运维地狱：

  • 每个服务要独立监控、告警、升级，运维成本几何级增长。

---

相关软件

• Spring Cloud、Dubbo 

八.容器化引入——容器编排架构

 随着业务增长，然后发现系统的资源利用率不高，很多资源用来应对短时高并发，平 时又闲置，需要动态扩缩容，还没有办法直接下线服务器，而且开发、测试、生产每 套环境都要隔离的环境，运维的工作量变的非常大。

容器化技术的出现给这些问题的 解决带来了新的思路。

目前最流行的容器化技术是Docker，最流行的容器管理服务是Kubernetes(K8S)，应 用/服务可以打包为Docker镜像，通过K8S来动态分发和部署镜像。

Docker镜像可理 解为一个能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运 行环境根据实际的需要设置好。把整个“操作系统”打包为一个镜像后，就可以分发到需 要部署相关服务的机器上，直接启动Docker镜像就可以把服务起起来，使服务的部署 和运维变得简单。

服务 通常会有生产和研发k8s集群，一般不会公用，而研发集群通过命名空间来完成应用 隔离，有的公司按照研发目的划分为研发和测试集群，有的公司通过组织架构完成部 门间的资源复用。

---

简介

• 什么是容器？ 想象一下“集装箱”。它把货物（你的应用代码、运行环境、配置等）打包成一个标准化的、隔离的单元。这个单元在任何支持集装箱（容器运行时，如 Docker）的码头（服务器）上都能运行，保证环境一致。

• 问题来了： 当你的应用变得复杂，需要很多个集装箱（容器）一起协作（比如前端、后端、数据库、缓存），并且需要运行在多台货轮（服务器）上时，手动管理就崩溃了：

  • 哪个容器放哪台服务器？

  • 容器挂了谁重启？

  • 流量大了怎么自动加容器？

  • 流量小了怎么自动减容器？

  • 容器之间怎么互相发现和通信？

  • 怎么安全地更新容器版本？

  • 怎么管理配置和密码？

---

出现原因

容器编排架构就是为了解决上面那一堆“手动管理崩溃”的问题而诞生的！ 它的核心使命是：自动化地管理大规模容器集群的生命周期。

• 需求驱动：

  • 微服务普及： 应用拆分成很多小服务（微服务），每个服务都需要独立部署、伸缩，容器是天然载体，数量爆炸式增长，手动管不了。

  • 弹性伸缩： 应对流量高峰低谷，需要自动增减容器数量。

  • 高可用性： 容器挂了要自动恢复，服务不能中断。

  • 复杂部署： 滚动更新、蓝绿部署、金丝雀发布等高级部署策略需要自动化。

  • 资源优化： 高效利用服务器资源，避免浪费。

  • 简化运维： 用一套工具管所有容器，降低运维复杂度。

---

架构工作原理

可以把容器编排系统想象成一个智能的“集群大脑”和“自动化工厂”：

1. API 服务器/控制平面： 这是“指挥中心”。你（或你的自动化工具）告诉它你想要什么状态（比如：运行5个Web容器，3个数据库容器）。它接收指令，是整个系统的入口和管理界面。

2. 调度器： 这是“智能调度员”。指挥中心收到指令后，调度员负责看哪台服务器（节点）有空闲资源（CPU、内存），并且满足要求（比如需要有GPU），然后决定把新容器放到哪台服务器上运行最合适。

3. 控制器： 这是“监工和修复员”。它时刻盯着集群的实际状态，对比指挥中心期望的状态。发现不一致（比如某个容器挂了，或者数量不够了），它就立刻采取行动（重启容器、启动新容器），让实际状态向期望状态靠拢。这是实现“自愈”和“弹性”的关键！

4. 配置存储： 这是“集群的记事本”。存储着集群的所有重要信息：期望状态、当前状态、配置、密码等。指挥中心、调度员、监工都要读写这个记事本来协同工作。通常是一个高可用的数据库（如 etcd）。

5. 节点/工作节点： 这是“干活的码头工人”。每台实际运行容器的服务器就是一个节点。上面安装了：

   • 容器运行时： 真正负责启动、停止、运行容器的软件（如 Docker, containerd）。

   • 代理： 一个“小监工”。它听从指挥中心大监工的命令，负责在本节点上管理容器的生命周期（启动、停止、监控），并向指挥中心报告本节点和容器的状态。

6. 网络插件： 负责解决容器之间、容器与外部世界通信的复杂网络问题，就像一个“通信工程师”，确保网络畅通、隔离和安全。

7. 存储插件： 负责解决容器需要持久化保存数据（如数据库文件）的问题，将外部存储（云盘、NFS等）挂载给容器，像一个“仓库管理员”。

工作流程简化版：

1. 你（或CI/CD工具）通过命令行或YAML文件告诉“指挥中心”：我要运行3个Nginx容器。

2. “指挥中心”把“运行3个Nginx”这个期望状态记录到“记事本”。

3. “监工”发现实际状态是0个Nginx，与记事本不符。

4. “监工”通知“调度员”：需要启动3个Nginx容器。

5. “调度员”查看各“码头工人”（节点）的资源情况，挑出3个合适的节点。

6. “调度员”告诉这3个节点上的“小监工”：启动一个Nginx容器。

7. 每个“小监工”命令本地的“容器运行时”启动一个Nginx容器。

8. “小监工”持续监控容器状态，报告给“指挥中心”。

9. 如果某个容器挂了，“监工”会发现状态不符，又触发调度和启动流程，保证始终有3个在运行。

10. 你想升级Nginx版本？告诉“指挥中心”新版本。“监工”会按照策略（如滚动更新）逐个替换旧容器为新容器。

---

技术案例

• Kubernetes： 毫无疑问的行业标准和领导者。功能最全面、生态最庞大、社区最活跃。它提供了上述所有核心组件。常说 K8s。

• Docker Swarm： Docker官方出的编排工具。概念简单，与Docker引擎集成紧密，上手容易。适合较小规模或对复杂性要求不高的场景。K8s兴起后，热度有所下降。

• Apache Mesos + Marathon： 更通用的集群资源管理器（Mesos），可以跑容器（通过Marathon）、大数据任务等。曾经很流行，但K8s在容器编排领域基本取代了它。

• HashiCorp Nomad： 一个更轻量级、更灵活的工作负载编排器，不仅能编排容器，还能编排虚拟机、Java应用等。简单易用，资源占用小。

---

优缺点

优点：

1. 自动化运维： 自动部署、修复、扩缩容，解放双手，减少人为错误。

2. 高可用 & 自愈： 容器挂了自动重启，节点挂了容器自动迁移，服务更稳定。

3. 高效资源利用： 智能调度把容器塞进服务器缝隙里，榨干硬件资源。

4. 服务发现与负载均衡： 自动管理容器地址变化，并把流量均匀分发到健康的容器上。

5. 声明式配置： 你只需说“我要什么”（YAML文件），不用管“怎么做”，系统自动搞定。配置即代码，易于管理。

6. 标准化部署： 无论底层是物理机、虚拟机还是云，编排方式都一样。

7. 支持复杂部署策略： 滚动更新、蓝绿部署等高级玩法变得可行且相对简单。

8. 大规模管理能力： 轻松管理成百上千个容器。

缺点：

1. 学习曲线陡峭： 概念多（Pod, Service, Deployment, StatefulSet, Ingress...）、组件复杂（尤其K8s），入门和精通都需要时间。这是最大的门槛！

2. 复杂性高： 搭建、配置、维护一套生产级高可用的编排集群本身就很复杂。需要专业知识。

3. 资源开销： 控制平面组件（指挥中心、监工、调度员、记事本）本身需要消耗一定的CPU和内存资源。

4. 网络和存储配置复杂： 容器网络和持久化存储是两大难点，配置不当容易出问题。

5. 调试困难： 当问题发生时，由于涉及组件多、层次多，定位根因可能比较困难。

6. “杀鸡用牛刀”风险： 对于非常小规模、简单的应用，引入复杂的编排系统可能得不偿失，增加了不必要的管理负担。

7. 安全挑战： 大规模集群的安全配置（认证、授权、网络策略、密钥管理）需要格外注意。

---

相关软件

• Docker、K8S

尾声

至此，一个还算合理的高可用、高并发系统的基本雏形已显。

注意，以上所说的 架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有 几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问 题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不 是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。

对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要 求就足够了，但要留有扩展架构的接口以便不备之需。

对于不断发展的系统，如电商 平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不 断的迭代升级架构，以支持更高的并发和更丰富的业务。

所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等 场景解决方案的一个统称，在每一个场景都包含了多种可选的技术，如数据采集有 Flume、Sqoop、Kettle等，数据存储有分布式文件系统HDFS、FastDFS，NoSQL 数据库HBase、MongoDB等，数据分析有Spark技术栈、机器学习算法等。

总的来 说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提 供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。

而服务端 架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。