Appearance
信息系统架构：企业架构 · TOGAF · 微服务与云原生（零基础版）
本页导读：盖房子之前，施工队不能直接开干，得先有一摞图纸：功能布局图、水电图、结构图。给企业建信息系统也一样——这套"图纸"就叫架构。零基础的你不需要会画图，只需要看懂图纸分几层、每层画的是什么。本页主线：先看"企业四层图纸"（业务/应用/数据/技术架构），再学国际通用的画图流程 TOGAF ADM，然后是几组经典对比（集中式 vs 分布式、SOA vs 微服务、虚拟机 vs 容器），最后认识云原生新技术族。考法以概念判断和"某做法属于哪类架构"的场景匹配为主。
你将学会
- 用"盖房子的图纸"理解架构，背下企业架构四层口诀"业应数技"
- TOGAF 的 ADM 流程顺序，以及"需求管理居中"这个高频考点
- 集中式 vs 分布式、C/S vs B/S、SOA vs 微服务、虚拟机 vs 容器四组经典辨析
- 云原生"四大件"和数据仓库/湖/集市一组词的分辨
一、架构是什么：盖房子的图纸
比喻：你要盖一栋楼，包工头问"图纸呢？"——没有人会说"边盖边想吧"。架构就是信息系统这栋楼的整套图纸 + 关键决策：盖几层、每层干什么、水电怎么走、用什么建材。
企业级系统的图纸还不止一张，是一摞：先有功能布局图（客厅卧室怎么分），再有设备清单（空调洗衣机用哪些），然后是管线图（水电气怎么通），最后是结构施工图（地基用什么、承重怎么算）。这就是企业架构的四层。
项目经理不需要亲手画架构图，但要能：
- 读懂架构方案，参与评审（案例题干常给架构描述让你判断优劣）
- 在论文里把项目技术背景写得专业可信
二、企业架构（EA）：四层骨架（高频）
四层从上往下，业务架构是源头（先定住哪、再谈管线），技术架构是底座（地基建材）：
| 层 | 图纸比喻 | 回答的问题 | 典型内容 |
|---|---|---|---|
| 业务架构 | 功能布局图 | 业务怎么运转 | 业务流程、组织结构、业务能力地图 |
| 应用架构 | 设备清单与插座布置 | 用哪些系统支撑业务 | 应用系统划分、系统间接口与集成关系 |
| 数据架构 | 水路管线图 | 数据怎么组织流动 | 数据模型、主数据、数据流、数据治理 |
| 技术架构 | 地基结构与建材清单 | 跑在什么技术设施上 | 网络、服务器、云平台、中间件、安全设施 |
记忆口诀：业应数技（业务→应用→数据→技术）。考题爱把某项内容塞错层，比如把"主数据管理"放到技术架构——它属于数据架构；"中间件选型"才是技术架构的事。
三、TOGAF 与 ADM：标准的"装修施工流程"
TOGAF 是 The Open Group 发布的企业架构框架，核心是 ADM（Architecture Development Method，架构开发方法）——相当于一套"从毛坯到入住"的标准化装修流程，而且做完一轮还能循环再来（房子住着住着要翻新）。
ADM 阶段顺序（按序记忆）
| 阶段 | 名称 | 装修比喻 | 干什么 |
|---|---|---|---|
| 预备阶段 | Preliminary | 找装修队、定规矩 | 明确架构能力、原则、准备资源 |
| A | 架构愿景 | 定风格预算：装成什么调性 | 确定范围、干系人、愿景与批准 |
| B | 业务架构 | 定功能布局：哪住人哪做饭 | 定义业务基线与目标架构 |
| C | 信息系统架构 | 水电图 + 设备图一起画 | 数据架构 + 应用架构两小步 |
| D | 技术架构 | 定建材施工方案 | 定义技术基线与目标架构 |
| E | 机会与解决方案 | 出方案对比与报价单 | 差距分析，形成候选方案与路线图 |
| F | 迁移规划 | 排施工进度表 | 制定实施与迁移计划 |
| G | 实施治理 | 盯工地别跑偏 | 对实施项目进行架构治理 |
| H | 架构变更管理 | 住进去后的改装修申请管理 | 管理架构变更需求 |
| 中心 | 需求管理 | 工地板房里的"业主需求登记簿" | 贯穿全程，持续接收并管理需求 |
高频考法：①"需求管理位于 ADM 的什么位置"——中心，贯穿各阶段（任何工种随时来翻需求登记簿）；②阶段排序题；③"C 阶段包含哪两个架构"——数据 + 应用。
四、集中式 vs 分布式：一个大食堂 vs 多个档口
比喻：集中式像一个大食堂：全校师生都到这一个食堂打饭，菜好管、账好算，但人一多就排长队，食堂一关全员没饭吃。分布式像美食街多个档口：任务分散、互相 backup，一个档口歇业别的照开，但协调起来复杂。
| 维度 | 集中式 | 分布式 |
|---|---|---|
| 结构 | 一台/一组核心主机统一处理 | 多节点协作，任务拆分到多机 |
| 比喻 | 一个大食堂 | 多个档口协作 |
| 优点 | 结构简单、数据一致性好管理 | 高并发、可扩展、容错好 |
| 缺点 | 单点瓶颈、扩展性差 | 复杂、一致性保障难 |
| 典型 | 传统核心银行主机 | 互联网大规模服务 |
经典 C/S 与 B/S（用户怎么进门）：
| 结构 | 比喻 | 客户端形态 | 特点 |
|---|---|---|---|
| C/S | 专门下载的 APP | 需安装专用客户端 | 交互强、性能好；部署维护成本高 |
| B/S | 打开浏览器就能用 | 浏览器即可 | 零安装、易升级；受浏览器能力限制 |
五、SOA 与微服务：大超市 vs 专卖店（经典辨析，必背）
两个都是"把功能拆成服务"的思想，差在拆法和治理：
比喻：SOA 像大超市——生鲜、日化、熟食都在一个屋檐下，统一收银、总服务台协调一切（ESB）。微服务像专卖店一条街——每家店小而专，各自进货各自收银（独立数据库），谁家装修不影响别家（独立部署）。
| 维度 | SOA 面向服务架构 | 微服务 |
|---|---|---|
| 比喻 | 大超市统一管理 | 专卖店各自独立 |
| 粒度 | 粗粒度服务 | 细粒度、小而专 |
| 通信 | 重协议（SOAP/WSDL），常经 ESB 企业服务总线 | 轻量协议（REST/HTTP、消息队列） |
| 治理 | 中心化（ESB 是枢纽，像超市总服务台） | 去中心化 |
| 数据 | 多服务共享数据库 | 每服务独立数据库（每档口自带冷柜） |
| 部署 | 整体打包部署为主 | 独立部署、独立伸缩 |
| 典型场景 | 企业遗留系统整合 | 互联网持续迭代的业务系统 |
一句话抓分：ESB 是 SOA 的招牌，独立数据库是微服务的招牌。
六、常见架构风格速览
| 风格 | 比喻 | 特点 | 考点 |
|---|---|---|---|
| 分层架构 | 楼房一层层往上盖 | 表现层/业务层/数据层等水平切分 | 最常见的"默认答案" |
| 事件驱动 | 小区广播站：一喊全员响应 | 组件通过事件消息解耦联动 | 与消息队列配合 |
| 管道-过滤器 | 工厂流水线 | 数据流经一串处理单元 | 编译器类系统 |
| 微内核 | 手机 + 装 APP | 小核心 + 插件扩展 | IDE、浏览器插件体系 |
| C/S 与 B/S | 见上节 | 客户端/浏览器两种进门方式 | 与"瘦客户端"结合考 |
七、云原生：生在云上、长在云上
比喻：传统应用像"从老家搬来的家具"，硬塞进云上的新房子总有点不合尺寸；云原生应用是按新房尺寸定制的家具，天生适配云的弹性。四大件常被并提：容器、微服务、DevOps、持续交付。
| 技术 | 比喻 | 一句话 | 考点 |
|---|---|---|---|
| 容器 Docker | 打包好的集装箱 | 轻量级、可移植的标准化运行单元 | 与虚拟机辨析：共享内核、秒级启动 |
| Kubernetes（K8s） | 集装箱港口调度员 | 容器编排平台：调度、扩缩容、自愈 | 云原生底座的事实标准 |
| 服务网格 | 档口间统一跑腿服务 | 处理服务间通信的基础设施层 | 微服务流量治理下沉 |
| Serverless | 自助咖啡机：按次付费不用买机器 | 无服务器：按事件触发、按需付费，不感知底层机器 | 理念是"免运维、弹性到函数级" |
| DevOps | 设计师和施工队合成一队 | 开发运维一体，自动化流水线 | 与敏捷的关系：敏捷管开发节奏，DevOps 打通开发到运维 |
| 中台 | 中央厨房做半成品 | 沉淀可复用的能力层（业务中台/数据中台） | 国内互联网大厂概念，案例背景常见 |
虚拟机 vs 容器（高频辨析）
| 维度 | 虚拟机 | 容器 |
|---|---|---|
| 比喻 | 整租整套公寓（自带厨卫水电全套） | 集装箱宿舍（共享大楼水电，拎包入住） |
| 隔离级别 | 完整操作系统级 | 进程级（共享宿主内核） |
| 启动速度 | 分钟级 | 秒级 |
| 资源开销 | 大（每台带完整 OS） | 小 |
八、数据架构补充：仓库、湖与集市
做论文背景或案例阅读时常见这组词，用"存东西的地方"区分：
| 概念 | 比喻 | 定位 |
|---|---|---|
| OLTP | 收银台记账 | 面向交易的处理，日常业务系统数据库的工作模式 |
| OLAP | 老板看报表 | 面向分析的多维查询，支撑报表与决策 |
| 数据仓库 DW | 图书馆的分类书架 | 面向主题的、集成的、相对稳定的数据集合，支撑决策分析 |
| 数据湖 | 原始材料大仓库，先囤后整理 | 原始形态集中存放多源数据，先存后治理 |
| 数据集市 | 部门资料角 | 面向部门/主题的小型数据集市 |
| BI | 阅览室的报表与图表工具 | 在数仓之上做分析与可视化的工具体系 |
辨析一句话：数仓先建模后入库，数据湖先入库后建模。
九、常考辨析汇总
| 易混点 | 一句话区分 |
|---|---|
| 业务/应用/数据/技术架构 | 业应数技四层，业务是源头 |
| ADM 的 C 阶段 | 数据架构 + 应用架构 |
| 需求管理 | 在 ADM 中心，贯穿全程 |
| SOA vs 微服务 | ESB 中心化 vs 去中心化独立部署独立库 |
| C/S vs B/S | 装客户端 APP vs 浏览器直接用 |
| 虚拟机 vs 容器 | 带完整 OS 的分钟级 vs 共享内核的秒级 |
| 数仓 vs 数据湖 | 先建模 vs 先存后治 |
| OLTP vs OLAP | 收银记账 vs 老板看账 |
| 集中式 vs 分布式 | 一个大食堂 vs 多档口协作 |
十、论文里怎么用
- 项目技术背景一句话模板："本项目采用 B/S 架构、微服务技术栈，部署于企业私有云，通过 K8s 实现容器化编排……"
- 迁移/重构类项目可写"由集中式单体架构向分布式微服务架构演进"，正好带出风险与干系人管理的故事线
- 架构选型理由要落在业务需求上（高并发、快速迭代、遗留整合），不要为技术而技术——这本身就是架构评审的思维方式
术语卡
| 术语 | 大白话 | 考试怎么考 |
|---|---|---|
| 架构 | 系统的整套图纸与关键决策 | 概念判断 |
| 企业架构（EA） | 企业级的一摞图纸 | 四层归属题 |
| 业务架构 | 功能布局图（业务怎么运转） | 内容塞错层辨析 |
| 数据架构 | 水路管线图（数据怎么流） | 主数据归这层 |
| 技术架构 | 地基建材清单 | 中间件、云平台归这层 |
| TOGAF/ADM | 标准化装修流程 | 阶段排序 |
| 需求管理 | 板房中心的业主需求登记簿 | "居中、贯穿全程"必考 |
| 集中式/分布式 | 一个大食堂 vs 多档口 | 特点对比 |
| C/S、B/S | 装 APP vs 开浏览器 | 特点匹配 |
| SOA | 大超市 + 总服务台（ESB） | 与微服务辨析 |
| 微服务 | 专卖店街：小而专、自带冷柜 | 独立数据库招牌 |
| 容器/K8s | 集装箱 / 港口调度员 | 与虚拟机辨析 |
| 数据仓库/湖 | 分类书架 vs 原料大仓库 | 先建模 vs 先囤后治 |
| OLTP/OLAP | 收银记账 vs 看报表 | 场景匹配 |
易错点
- 四层内容塞错层：主数据、数据治理 = 数据架构（不是技术架构）；中间件、网络、云平台 = 技术架构；业务流程 = 业务架构。
- ADM 需求管理位置记错：它在中心，不是第一阶段也不是收尾阶段——"贯穿全程"是关键词。
- C 阶段只答一个：C 阶段是信息系统架构 = 数据 + 应用两个子架构，漏一个就丢分。
- SOA 与微服务混搭：ESB、重协议、共享库是 SOA；轻协议、独立库、独立部署是微服务，别交叉记忆。
- 虚拟机和容器说反：容器共享宿主机内核、秒级启动；虚拟机带完整操作系统、分钟级启动。
- 数仓和数据湖方向搞反：数仓"先建模后入库"（进书架前先分类），数据湖"先入库后建模"（先囤起来再说）。
- B/S 说成"不需要服务器"：B/S 只是客户端用浏览器，服务器照样有，别被字面骗了。
- DevOps 与敏捷等同：敏捷管"开发节奏"，DevOps 打通"开发到运维"，范围不同。
自测 5 题
1. "主数据管理、数据流设计"应归入企业架构的哪一层？ A. 业务架构 B. 应用架构 C. 数据架构 D. 技术架构
2. 在 TOGAF 的 ADM 中，需求管理处于什么位置？ A. 预备阶段之前 B. 中心，贯穿各阶段 C. H 阶段之后 D. 只在 A 阶段
3. 以下哪项是微服务的"招牌"特征？ A. 依赖 ESB 总线集成 B. 服务共享一个数据库 C. 每个服务独立数据库、独立部署 D. 整体打包一次部署
4. 关于虚拟机与容器，说法正确的是？ A. 容器启动需要分钟级 B. 虚拟机共享宿主机内核 C. 容器共享宿主内核、秒级启动 D. 两者没有区别
5. "先把多源原始数据集中囤起来，之后再整理建模"，这描述的是？ A. 数据仓库 B. 数据湖 C. 数据集市 D. OLTP
点开看答案与解析
1. C —— 数据模型、主数据、数据流、数据治理都是数据架构（水路管线图）的内容；中间件、云平台才属于技术架构。 2. B —— 需求管理像"工地板房中心的需求登记簿"，位于 ADM 中心、贯穿各阶段，是高频考点。 3. C —— 微服务 = 专卖店模式：小而专、独立数据库、独立部署；ESB 和共享库是 SOA 的特征。 4. C —— 容器共享宿主内核、秒级启动、开销小；虚拟机带完整操作系统、分钟级启动、开销大。 5. B —— 数据湖 = 先囤后治（先入库后建模）；数据仓库 = 先分类再上架（先建模后入库）。
小结
- 企业架构四层"业应数技"，业务是源头；TOGAF ADM 顺序 + 需求管理居中是硬考点
- 四组必秒辨析：集中式 vs 分布式、C/S vs B/S、SOA vs 微服务、虚拟机 vs 容器
- 云原生四件套：容器、微服务、DevOps、持续交付；数仓与湖是"先建模 vs 先囤后治"
下一页：信息安全 →