架构师的登山之路-第四站-用架构师的视角重新理解网络和安全

架构师的登山之路｜第四站：用架构师的视角重新理解网络和安全

在前三站里，我们聊了 Docker、Kubernetes 和 DevOps，这些技术让应用"跑得起来、跑得快、改得动"。

但只盯着这些还不够------在真实生产环境中，还有两块"看不见但很关键"的地基：网络和安全。

很多刚转型做架构的同学，脑子里有这样的画面：

"网络不就是能 ping 通就行？"
"安全不是有运维/安全团队负责吗？"

结果系统上线后，不是访问慢、端口乱，就是被各种安全基线检查打回重做。

这一站，我们站在架构师视角，把网络和安全重新过一遍，目标是：

你不必变成网络工程师 / 安全专家；
但要能 看懂拓扑、做出合理的高层设计、知道风险在哪里。

一、网络基础：看不见的管道

网络更像是一座城市的交通系统：

IP 是门牌号
子网是小区
路由是路网
DNS 是导航
负载均衡是交通指挥
CDN 是前置仓

架构师不需要记住每一条"街道"的细节，但要知道 城市是怎么规划的。

1.1 架构师需要懂到什么程度？

用一句话划线：

你至少要能画出"客户端 → 边缘 → 网关层 → 应用层 → 数据层"的端到端链路，并解释每一层在干什么。

例如：

用户在浏览器输入域名：DNS 怎么解析？
请求打到公网入口：是直接进 Nginx，还是先经过 API 网关 / WAF？
内网之间：哪些服务可以互相访问，哪些必须隔离？

理解这些之后，网络就不再是"黑盒"。

1.2 IP、子网与路由：从"能连上"到"设计合理"

IP 地址：门牌号

每台设备都有自己的 IP 地址，分为 公网 IP 和 私网 IP。
架构师需要关心的不是每个数字，而是：
- 哪些服务必须暴露在公网？
- 哪些服务只能在内网？
- 未来要不要跟别的 VPC / 数据中心打通？

子网与网段规划：小区怎么划

子网就像一个小区，同一子网内的机器可以"直接打招呼"，不同子网之间需要通过路由。
在云上（阿里云 VPC、AWS VPC 等）常见做法：
- 公网子网：放负载均衡、跳板机等；
- 私网子网：放应用、数据库、中间件。
作为架构师，你要能回答：
- 一个 VPC 下要划多少个子网？
- 每个子网承载哪一类服务？
- 日后扩容时有没有 IP 段可以继续分？

路由：决定"走哪条路"

默认路由（0.0.0.0/0）决定访问外网时走哪条出口；
多 VPC / 混合云场景中，路由表特别关键：
- 某个服务访问另一个 VPC 的 Redis/ES，通过哪个网关 / 专线 / VPN？
- 出现"内网 IP ping 不通"时，很多问题其实是路由没配对或被安全策略挡住。

1.3 DNS：流量入口的"导航系统"

DNS 不是简单的"IP 电话簿"，而是整个系统的 第一个入口控制点。

架构师要关注：

解析路径
- 用户 → 本地 DNS → 运营商 DNS → 权威 DNS；
- 企业环境中，通常还会多一层公司内部的 DNS 代理。
记录类型
- A 记录：域名 → IP；
- CNAME：域名 → 另一个域名（CDN、负载均衡常用）；
- TXT、MX 等用于校验、邮件等场景。
常见坑
- TTL 设置太长：发布切换后用户访问的还是旧 IP；
- 多地多运营商 DNS 不一致：某些地区访问异常；
- 内外网"同名不同指向"：测试环境和生产环境域名容易搞混。

对架构师来说，DNS 是 多环境切换、灰度发布、多活部署 的一个重要战术工具。

1.4 TCP / HTTP / HTTPS：从传输到应用

TCP/UDP：城市的交通规则

TCP：可靠传输，保证有序、不丢，适合大多数业务 API；
UDP：不保证可靠，胜在简单高效，适合实时语音、直播、游戏等。

你不用背三次握手四次挥手的细节，但要知道：

高并发长连接服务（网关、IM、WebSocket）会受到 TCP 连接数、TIME_WAIT 等限制；
LB 和应用层之间的超时配置要匹配，否则容易出现"前端提示超时，但后端还在跑"。

HTTP / HTTPS：应用层世界

HTTP 是明文；
HTTPS = HTTP + TLS 加密 → 防窃听、防篡改、防伪造。

从架构角度要搞清楚：

HTTPS 终止点在哪里？
- CDN？负载均衡？API 网关？还是直接到应用？
内网服务之间是否需要 TLS？
- 金融、政务等高安全行业，有时会要求"内网也加密"；
证书如何管理？
- 手动上传 + 定期更换？
- 还是用自动续签（ACME / Let's Encrypt）和云厂商的证书托管服务？

1.5 负载均衡与 CDN：让流量跑得更稳、更快

负载均衡（Load Balancer）

可以把负载均衡理解为流量入口的"分流器"：

四层 LB（L4）
- 基于 IP + 端口转发 TCP/UDP；
- 性能高，对应用层协议不感知。
七层 LB（L7）
- 能根据 URL、Header、Cookie 做路由；
- 适合做蓝绿发布、灰度发布、按路径/域名拆分。

架构师要设计清楚：

对外流量是走单层 LB，还是"公网 LB → API 网关 → 服务网格"多层结构？
是否需要对不同业务拆 LB（缓解配置混乱 & 安全风险）？

CDN（内容分发网络）

CDN 是"边缘缓存层"：

静态资源（图片、视频、前端静态文件等）放在 CDN，可以显著减少源站压力；
配合对象存储，可以形成：
浏览器 → CDN → 对象存储 的访问路径，而不是直击后端应用。

从架构角度要考虑：

哪些路径应该缓存？缓存多久？
动静分离做得是否彻底？
灰度/版本切换时，如何控制 CDN 缓存刷新？

二、安全基础：从"能访问"到"只能该访问的人访问"

如果说网络是"路修好没"，那安全就是"谁能在这条路上走"。

对架构师来说，一个重要心态是：

不要默认"谁都能访问"，而要默认"谁都不能访问"，再逐步开放。

2.1 认证、授权与审计：三个层次不要混

身份认证（Authentication）：你是谁？

典型方式：
- 用户名 + 密码；
- 短信 / 邮箱验证码；
- 双因素认证（2FA/MFA）；
- OAuth2 / SSO（企业微信、钉钉登录等）。

架构设计时要考虑：

是否需要统一身份认证中心（SSO）？
B 端、C 端、内部系统是否共用一套认证体系？
外部第三方接入时，如何统一发 token、统一校验？

授权（Authorization）：你能干什么？

RBAC（基于角色的访问控制）：
- 用户 → 角色 → 权限；
ABAC（基于属性的访问控制）：
- 按部门、地域、时间、终端类型等多维度判断。

设计授权时，优先考虑：

最小权限原则：只给业务当前必需的权限；
权限模型能不能支撑未来几年业务扩展，而不需要大重构。

审计（Audit）：谁在什么时候做了什么？

很多系统只做了"登录+权限"，忽略了"记录行为"。

架构师要推动的是：

管理后台、高风险接口、导数/删除操作必须有审计日志；
审计日志相对独立存储，防止管理员"自删痕迹"。

2.2 加密与密钥管理：安全不只是在传输过程中

加密至少有三个维度：

传输加密（in transit）
- 全站 HTTPS；
- 内部服务 mTLS（双向 TLS）；
- 对接第三方支付/接口时的加签与验签。
存储加密（at rest）
- 数据库透明加密（TDE）；
- 对象存储加密、磁盘加密；
- 重要备份文件的加密。
使用中保护（in use）
- 高安全场景涉及机密计算；
- 普通业务至少要做到：敏感数据在日志中打码、脱敏。

更关键的是 密钥管理：

密钥不应该：
- 硬编码在代码里；
- 放在公开仓库；
- 明文写在配置文件里到处拷贝。
更合理的方式：
- 使用云厂商 KMS（Key Management Service）；
- 使用 Vault 等密钥管理组件；
- 配合配置中心，把"密钥"和"版本配置"分开管理。

2.3 防火墙、安全组、WAF：一圈一圈的"围栏"

可以把这些理解为多层防线：

网络边界防火墙
- 控制整个数据中心 / VPC 的入口与出口；
- 决定哪些 IP/端口可以进入/出去。
安全组 / NACL
- 对某个实例 / 子网的精细访问控制：
  - 只允许某些端口对特定网段开放；
  - 默认拒绝所有外来访问；
- 比如：
  - 数据库只允许来自应用子网的 3306；
  - Redis 只允许内部若干服务访问。
WAF（Web 应用防火墙）
- 专门防御 Web 层攻击：
  - SQL 注入；
  - XSS；
  - 常见扫描、漏洞利用等。

架构师的职责是 设计出"哪一层防什么"的整体策略，而不是去写每一条规则。

2.4 日志与监控：城市的摄像头和报警器

没有日志的系统，就像一个没有摄像头的机房，出事了只能靠猜。

建议的基本实践：

应用层：
- 访问日志、错误日志；
- 关键操作日志（登录、下单、支付、权限变更等）；
- 与用户相关的异常行为记录（多次登录失败、频繁接口访问等）。
基础设施：
- 系统日志（syslog）；
- LB / WAF / API 网关日志；
- 云厂商的审计日志（如 ActionTrail / CloudTrail）。

配合：

指标监控（Metrics）
- QPS、响应时间、错误率；
- 各类资源使用率（CPU、内存、磁盘、连接数）；
日志搜索（Log Search / SIEM）
- 可以按时间、用户、IP、接口快速筛查；
告警
- 流量暴涨、错误率飙升、登录失败异常增多、关键服务不可用等。

三、在项目中实践"网络 + 安全"

用一个最常见的三层 Web 应用为例，画一个简化链路：

用户 → DNS → CDN（可选） → WAF / LB → API 网关 → 应用服务 → 数据库 / 缓存

作为架构师，你应该能给出类似的设计要点：

入口与域名
- 域名统一由 DNS 管理；
- 尽量只暴露 80/443，对外只开放 443；
- 配置好 HSTS、证书自动续签。
边缘层
- 静态资源走 CDN，减少源站压力；
- WAF 放在 CDN / LB 前面，拦截常见攻击。
应用层
- 内网调用走服务发现（例如 Kubernetes Service / Service Mesh）；
- 为关键业务提供限流、熔断、重试等保护；
- 管理后台与外部接口做物理/逻辑隔离。
数据层
- 数据库、缓存不暴露公网 IP；
- 访问通过私网 IP + 安全组控制；
- 按应用拆分数据库账号，禁用"全能账号"做业务访问。
运维与访问控制
- 运维通过堡垒机 / VPN 访问；
- 不同角色使用不同账号，禁止多人共用一个"超级管理员"；
- 操作有审计、命令有记录。
监控与应急
- 有统一监控告警平台；
- 编写基本的故障预案和演练（例如：某个机房挂了、WAF 误杀、证书过期）。

四、给架构师的一份"网络与安全 Checklist"

可以在每个项目启动或架构评审时，用这份清单快速过一遍。

网络 Checklist

是否画清楚了 端到端调用链路（用户 → 边缘 → 应用 → 数据）？
是否合理划分了 公网子网 / 私网子网？
对外暴露的端口是否最小化（理想情况只暴露 80/443）？
是否预留了后期扩容的 IP 段和子网规划？
是否规划好 CDN、LB、API 网关的职责边界？

安全 Checklist

是否有统一的 身份认证 方案（SSO / OAuth2 等）？
是否落地了 最小权限原则（账号、角色、系统权限拆分）？
是否开启了 HTTPS/TLS，并设计好证书管理方案？
敏感数据是否做了加密或脱敏？密钥如何集中管理？
是否配置了防火墙、安全组和 WAF，覆盖关键系统？
是否搭建统一的日志与监控平台，可以快速排查问题？
是否对管理后台、关键操作做了审计？是否有基本安全告警？

五、下一站预告：从"存在哪"到"怎么存"------数据库选型

搞定了网络和安全，我们的架构"地基"就更稳固了。

接下来，可以把注意力放在另一个老大难问题上：

"数据到底怎么存？"

下一站，我们会从架构师视角聊聊：

关系型数据库 vs NoSQL 的本质差异；
读多写多、高并发、强一致、最终一致分别适合什么数据库；
如何结合业务特征做出"够用又不会太贵"的数据库选型。