"系统要做集群""这个平台是微服务""数据库已经主从了"------这些说法经常出现在同一场会议里，却在回答不同的问题。
理解它们，先抓住三个问题：**功能怎么组织，程序在哪里运行，出故障后怎么办。**应用拆成几个部分，服务器用了几台，坏一台能否继续工作，需要分别判断。
下面用一个虚构的企业研发平台举例。它有用户管理、试验管理、文件转换、知识库几个功能。例子只用于解释原理。
一、应用如何组织
单体架构与模块化单体
如果几个功能都放在一个后端应用里，通常一起构建、一起发布，就可以叫单体应用。内部照样能分成用户模块、试验模块和文件模块，代码清楚、职责明确的做法常被称为模块化单体。
单体可以配一个 Vue 前端，也可以使用数据库、缓存和后台任务。前后端分离描述界面与服务端的分工，不能仅凭"Vue＋Django"判断是否微服务。一个 Django 项目里有多个 app，也不等于多个可独立部署的服务。
单体常见的好处是部署链路较短、事务容易处理；随着业务增多，也可能出现改一个功能要发布整套应用、某个模块拖慢整体的问题。是否需要拆分，要看这些问题是否已经影响交付。
服务化与面向服务架构（SOA）
将用户管理、文件转换等能力拆成独立程序，通过接口协作，就有了服务化特征。面向服务架构（SOA）也是按服务组织能力的一类思路，常用于不同系统之间的集成；实际边界和粒度因项目而异。
微服务架构
微服务更强调围绕业务能力划分边界，服务能独立部署和演进。判断时可以看下面这些问题，而不是数容器有几个。微软的微服务架构说明
| 判断问题 | 它说明什么 |
|---|---|
| 文件服务升级时，其他服务能否保持运行？ | 发布是否独立 |
| 文件任务增多时，能否只增加文件服务的副本？ | 扩容是否独立 |
| 其他系统通过接口获取用户信息，还是直接改用户表？ | 数据和接口边界是否清楚 |
| 一个服务失败后，其他服务会不会一直等待并拖垮？ | 故障是否有隔离措施 |
"微"没有统一的代码行数标准。多个完整业务系统通过网关连接，可能是多应用集成或较大粒度的服务化架构；若各系统内部又分别作为一个整体发布，也可以形成多个单体应用互联的形态。共享数据库会增加耦合，但还要看是否共享表、谁能修改数据、表结构变更是否迫使各方同时发布。
二、程序如何部署
分布式部署
数据库、业务程序、文件存储分别运行在不同节点并通过网络协作，就是典型的分布式场景。微服务经常采用分布式部署，但分布式系统也可能是一个单体应用配远程数据库。分布式带来扩展空间，也带来网络超时、部分失败、数据一致性等问题。
集群部署
集群可以先理解成一组共同承担任务的节点或实例。它们可能一起分担请求，也可能一个工作、其他接班，还可能把数据拆开保存。不同产品的"集群"工作方式差别很大。
| 听到的说法 | 具体可能是什么 |
|---|---|
| 应用集群 | 同一应用运行多个实例，共同处理请求 |
| 数据库集群 | 数据库节点复制或分片，按规则读写、切换 |
| Kubernetes 集群 | 一组机器由统一控制面管理容器任务 |
| 计算集群 | 多个节点协同执行计算任务 |
"三台服务器"本身不能说明集群能力。如果三台机器各自运行互不相关的软件，更适合直接称为多服务器部署。讨论集群时，还要问成员关系、任务分配、健康检查和故障处理。
实例、节点与副本
实例通常指一份正在运行的程序；节点通常指系统中的一个运行成员，例如一台物理机或虚拟机；副本指同一服务或数据的另一份。具体含义要结合产品，比如数据库副本与应用副本承担的职责不同。
同一台服务器运行三个应用副本，可以分担部分请求，也能应对某个进程退出；整台服务器断电时，它们仍会一起停止。要防服务器故障，副本需要分布在不同机器上；要防机房故障，还要进一步考虑跨机房部署和数据、网络等依赖。
路由与负载均衡
网关看到"用户接口"，转给用户服务；看到"文件接口"，转给文件服务，这是路由。如果文件服务有三个健康实例，入口再把请求分配给它们，这是负载均衡。APISIX、Nginx 都能承担其中一些工作，实际能力取决于配置。
因此，使用 APISIX 不能单独证明是微服务架构。网关可以连接多个完整应用，也可以连接细分服务。给一个上游配置了轮询算法，但它只有一个实例，也没有获得多副本容错能力。APISIX 官方上游说明
三、故障后如何继续运行
高可用与单点故障
高可用（HA，High Availability）关注故障发生后服务是否能继续提供，以及恢复需要多久。它通常依赖冗余、故障检测、切换和恢复机制。
即使业务程序有三份，如果网关只有一个、数据库只有一个，或者文件仅保存在某台机器的本地目录，这些依赖仍可能让整套服务中断。这样独一份、坏了便影响整体的关键环节，就叫单点故障。
讨论高可用时，具体问题比标签更有用：停掉一台机器后谁接管？需要人工操作吗？用户要重新登录吗？正在上传的文件和进行中的任务怎么办？是否做过切换演练？
主从复制、读写分离、分片与备份
| 名词 | 主要作用 | 需要注意 |
|---|---|---|
| 主从复制 | 把主库变更复制到副本 | 可能有延迟，切换能力需另行配置 |
| 读写分离 | 写请求去主库，部分读请求去副本 | 刚写入的数据可能暂时读不到 |
| 分片 | 将不同数据分配给不同节点 | 查询与事务可能跨节点 |
| 备份 | 保存可恢复的数据版本 | 必须确认恢复方法和恢复所需时间 |
复制不能直接替代备份：如果误删操作也被复制，副本同样可能丢失数据。MySQL 支持不同复制方式，异步复制也是常见方式，不能听见"主从"就默认副本始终与主库完全同步。MySQL 官方复制说明
四、常用部署与性能工具
Docker 与 Kubernetes
Docker 容器提供相对隔离的运行环境，镜像打包应用及所需文件。Docker 官方容器介绍 Kubernetes，常缩写为 K8s，负责在节点上调度和管理容器化应用；它的集群由控制面与工作节点组成。Kubernetes 官方架构说明
它们都能运行单体或微服务。安装 Kubernetes 后，还需要配置副本、健康检查、持久化存储、访问入口等。基础平台能够帮助恢复程序，业务本身是否能正确恢复仍要设计。
扩容、异步任务与缓存
| 名词 | 直观理解 | 适用问题 |
|---|---|---|
| 纵向扩容 | 给原机器增加资源 | 单机能力不足 |
| 横向扩容 | 增加实例或机器 | 请求或任务可分摊 |
| 异步任务 | 先接收任务，后台处理 | 文件转换等耗时工作 |
| 消息队列 | 任务先排队，消费者陆续处理 | 流量波动、任务解耦 |
| 缓存 | 暂存可复用结果 | 减少重复计算或查询 |
横向扩容尤其需要考虑状态。登录会话、上传文件、任务进度如果只存在某个实例里，换一个实例处理请求就可能找不到。缓存还要考虑失效，异步任务还要考虑失败重试和重复执行；这些机制需要配合业务规则。
五、怎样判断一个系统的架构
看架构图或听方案介绍时，可以按下面三个维度判断。一个系统可以同时具有多种特征。
| 维度 | 需要确认的问题 |
|---|---|
| 应用组织 | 哪些功能一起发布？哪些服务能独立发布和扩容？数据由谁管理？ |
| 运行部署 | 有多少实例？分布在哪些机器上？请求和任务如何分配？ |
| 故障恢复 | 坏一个节点后谁接管？是否需要人工切换？数据能恢复到哪个时间点？ |
例如，"模块化单体＋多实例部署＋数据库主从"是一种可以成立的组合。是否具备高可用，还要继续检查访问入口、数据存储和故障切换机制。