第3章：PaaS平台架构总览
好，咱们进入正题。这一章我打算聊聊PaaS平台的骨架——架构总览。说白了，就是告诉你一个企业级PaaS平台长什么样，各个零件怎么拼，为什么这么拼。
我个人习惯，做架构设计前先画一张大图。这张图能帮你一眼看穿全局。嗯，咱们就从这张图开始。
3.1 分层架构设计
一个成熟的PaaS平台，我建议分成四层。为什么是四层？我在项目中踩过坑，少了不够用，多了太臃肿。四层刚刚好。
| 层级 | 名称 | 核心职责 | 典型组件 |
|---|---|---|---|
| L4 | 应用服务层 | 提供运行时环境、中间件、数据库 | Spring Cloud、Kafka、MySQL、Redis |
| L3 | 编排调度层 | 资源调度、服务编排、弹性伸缩 | Kubernetes、Mesos、Docker Swarm |
| L2 | 基础设施层 | 计算、存储、网络资源抽象 | OpenStack、VMware、Ceph、Calico |
| L1 | 硬件资源层 | 物理服务器、GPU、SSD、网络设备 | Intel/AMD、NVIDIA、Mellanox |
你想想看，这四层其实对应了不同的团队职责。L1和L2通常是基础设施团队管，L3是平台团队的核心，L4则直接面向业务开发。
为什么这么分？ 我记得有一次，一个团队把数据库和容器调度混在一起管理，结果出问题时互相甩锅。分层之后，责任边界清晰了，问题定位也快了。
3.1.1 应用服务层（L4）
这一层是开发者最常打交道的。说白了，就是提供「开箱即用」的服务。
- 中间件服务：消息队列、缓存、配置中心
- 数据库服务：MySQL、PostgreSQL、MongoDB
- 运行时环境：Java、Python、Node.js 容器镜像
- API网关：统一入口、限流、鉴权
我在项目中遇到过，开发者想用Redis，结果自己搭了个单机版，连密码都没设。嗯，后来我们统一提供了Redis集群服务，自动配置好主从和密码，再也没出过安全问题。
3.1.2 编排调度层（L3）
这一层是PaaS平台的「大脑」。Kubernetes是绝对的主角，但我建议别裸用K8s，太痛苦了。
我个人习惯，在K8s上层再加一层抽象。比如用KubeSphere或者Rancher，把Pod、Service这些概念封装成「应用」和「环境」。开发者只需要说「我要部署一个Java应用，3个实例，2核4G」，剩下的交给平台。
核心能力清单：
- 资源调度：CPU、内存、GPU的分配与回收
- 弹性伸缩：基于CPU/内存/自定义指标的自动扩缩容
- 服务发现：内部DNS + 注册中心
- 灰度发布：蓝绿部署、金丝雀发布
3.1.3 基础设施层（L2）
这一层负责把物理资源「虚拟化」。说白了，就是把一台物理机切成N台虚拟机，或者把N台物理机的硬盘拼成一个大的存储池。
我曾经踩过一个坑：直接用K8s管理裸金属服务器，结果网络配置搞了整整两周。后来老老实实上了OpenStack，网络、存储、计算都统一管理，省心多了。
3.1.4 硬件资源层（L1）
这一层没什么好说的，就是真金白银买的服务器。但有一点要注意：异构资源管理。比如你有Intel的机器，也有AMD的，还有带GPU的。平台得能识别并合理调度。
3.2 技术选型原则
技术选型这事儿，我见过太多人「为了用而用」。比如团队明明只有5个人，非要上Service Mesh，结果光Istio就学了一个月。
我总结了三条原则，你可以参考：
- 成熟度优先：选社区活跃、文档齐全的。Kubernetes、Docker、Prometheus，这些经过大规模验证的，优先考虑。
- 团队能力匹配：你团队里没人懂Java，就别硬上Spring Cloud。Go写的组件，运维起来成本更低。
- 可替换性：别跟某个组件绑死。比如容器运行时，我建议同时支持Docker和containerd，万一哪天Docker出幺蛾子，还能切。
我的避坑指南： 我曾经选了一个冷门的服务网格组件，结果遇到bug连个问的人都没有。后来老老实实换了Istio。记住，选技术不是选美，是选队友。
3.3 高可用设计
高可用，说白了就是「别挂」。但企业级PaaS平台，挂了就是事故，得赔钱的。
我建议从三个维度来设计：
3.3.1 控制面高可用
Kubernetes的Master节点，必须三节点起步。etcd更是重中之重，我见过etcd单节点挂了，整个集群都瘫痪的惨案。
# 推荐的控制面部署方案
- API Server: 3个实例，负载均衡
- etcd: 3节点集群，奇数节点
- Scheduler: 2个实例，主备模式
- Controller Manager: 2个实例，主备模式3.3.2 数据面高可用
数据面就是跑业务的地方。节点挂了怎么办？Pod漂移了怎么办？
- Pod反亲和：同一个应用的Pod，尽量分散到不同节点
- PDB（PodDisruptionBudget）：保证最少可用实例数
- 多可用区：如果机房支持，把节点分布到不同可用区
我记得有一次，一个机柜的电源模块烧了，整个机柜的机器全挂了。但因为Pod分散在不同机柜，业务只损失了20%的容量，没完全挂掉。
3.3.3 数据持久化高可用
有状态服务是最头疼的。数据库、消息队列，这些挂了就真挂了。
我的建议：
- 数据库：主从复制 + 自动故障切换（比如MySQL的MGR或Galera）
- 存储：分布式存储（Ceph、Longhorn），三副本起步
- 备份：每天全量备份 + 每小时增量备份
警告： 别以为上了K8s就万事大吉。StatefulSet + PVC，如果底层存储挂了，一样完蛋。一定要做存储层面的高可用。
3.4 安全架构
安全这事儿，很多人觉得「等出事了再说」。但企业级平台，出事就是大事。
我建议从四个层面来构建安全体系：
3.4.1 网络安全
- 网络隔离：不同租户的网络必须隔离，用VPC或NetworkPolicy
- 东西向流量加密：Pod之间的通信，建议用mTLS加密
- 南北向流量管控：API网关统一入口，WAF防护
3.4.2 身份与访问控制
说白了，就是「谁是谁，能干什么」。
- RBAC：Kubernetes原生的角色权限控制
- OIDC集成：对接企业的LDAP或AD
- 服务账号：每个应用有自己的身份，不能共享Token
我曾经遇到一个客户，所有应用共用一个K8s ServiceAccount。结果一个应用被入侵，攻击者直接拿到了整个集群的控制权。嗯，从那以后，我坚持每个应用独立服务账号。
3.4.3 镜像安全
镜像里藏病毒？这事儿真发生过。
- 镜像签名：只运行经过签名的镜像
- 漏洞扫描：每次推送镜像，自动扫描CVE
- 基础镜像最小化：用Alpine或Distroless，减少攻击面
3.4.4 运行时安全
应用跑起来了，不代表就安全了。
- Pod安全策略：禁止特权容器、禁止挂载宿主机目录
- Seccomp/AppArmor：限制系统调用
- 审计日志：所有操作都有记录，出了问题能追溯
安全架构的核心思想： 纵深防御。别指望单点防御能挡住所有攻击。网络、身份、镜像、运行时，每一层都设防，攻击者得突破四道关卡才能得手。
好了，这一章的内容就到这里。PaaS平台的架构总览，说白了就是「分层、选型、高可用、安全」这八个字。下一章咱们聊聊具体的组件选型，比如Kubernetes怎么搭、存储怎么选，到时候再细说。