第2章 PaaS平台架构设计

第2章：PaaS平台架构设计

聊到PaaS平台的架构设计，我习惯先画一张大图。说白了，就是搞清楚「这东西到底长什么样」。很多团队一上来就堆组件，结果控制面和数据面搅在一起，多租户隔离全靠硬编码——嗯，我见过太多这样的坑了。

今天咱们就掰开揉碎，把PaaS平台的骨架讲清楚。

2.1 整体架构分层

我个人习惯把PaaS平台分成四层。你想想看，每一层各司其职，就像一家公司——有前台、有中台、有后台，还有管后勤的。

层级	职责	典型组件
接入层	统一入口、认证鉴权、流量治理	API Gateway、负载均衡
控制面	资源调度、服务编排、策略管理	调度器、控制器、Webhook
数据面	中间件实例运行、数据持久化	容器、存储卷、网络插件
基础设施层	计算、存储、网络资源	Kubernetes、Ceph、Calico

这里有个关键点：控制面和数据面必须解耦。我在项目中遇到过，有人把调度逻辑直接写在中间件容器里，结果一升级就得重启所有实例——那场面，简直灾难。

2.2 核心组件介绍

咱们挑几个核心组件聊聊。不贪多，讲透就行。

2.2.1 资源管理器

资源管理器是PaaS平台的「大脑」。它负责两件事：资源抽象和资源调度。

资源抽象：把物理资源（CPU、内存、磁盘）包装成虚拟资源池。比如一个Redis实例，你不需要关心它跑在哪台机器上。
资源调度：根据策略（如亲和性、资源水位）决定实例部署位置。

重要：资源调度策略一定要支持热更新。我曾经因为策略写死在配置里，线上扩容时调度器死活不认新节点——最后只能重启整个控制面。

2.2.2 服务目录

服务目录就是PaaS平台的「菜单」。用户点菜（申请中间件），你得上菜（创建实例）。

我建议服务目录采用声明式API设计。举个例子：

apiVersion: paas.example.com/v1
kind: MiddlewareInstance
metadata:
  name: redis-prod-01
spec:
  type: Redis
  version: "7.0"
  resources:
    cpu: "2"
    memory: "4Gi"
  persistence:
    size: "100Gi"
    storageClass: "ssd"

用户只需要告诉平台「我要什么」，平台负责「怎么给」。这才是PaaS该有的样子。

2.2.3 监控与告警

没有监控的PaaS平台，就像闭着眼睛开车。我见过最离谱的情况：一个MySQL实例内存爆了，监控系统居然没报警——因为采集器跟实例跑在同一个容器里，容器OOM了，采集器也跟着挂了。

避坑指南：监控采集器一定要独立部署，最好用DaemonSet方式。我曾经吃过这个亏，后来所有监控组件都改成sidecar模式，采集和业务进程彻底隔离。

2.3 控制面与数据面分离

这个设计理念，说白了就是「管的人不管事，做事的人不管人」。控制面负责决策，数据面负责执行。

为什么要分离？我总结三个核心原因：

故障隔离：控制面挂了，数据面还能继续运行。用户业务不受影响。
独立扩缩：控制面需要高可用，数据面需要高性能。两者资源需求不同，混在一起谁也管不好。
版本解耦：控制面升级不影响数据面。你想想看，如果每次升级都要重启所有中间件实例，用户不骂娘才怪。

注意：控制面和数据面之间通信必须可靠。我建议用消息队列做异步通信，而不是直接RPC调用。直接调用一旦网络抖动，整个调度链路都会阻塞。

举个例子，控制面下发一个「创建Redis实例」的指令：

控制面把指令写入消息队列（比如Kafka）
数据面的Agent从队列拉取指令
Agent在本地执行容器创建、网络配置、存储挂载
执行结果通过另一个队列回传给控制面

这样设计，控制面不会因为数据面响应慢而卡死。数据面也不会因为控制面重启而丢失指令。

2.4 多租户设计思路

多租户是PaaS平台的灵魂。没有多租户，你做的就是个单机版玩具。

我习惯从三个维度来设计多租户：隔离性、可观测性、计费性。

2.4.1 隔离性

隔离性分三个级别：

级别	实现方式	适用场景
软隔离	Namespace + RBAC	开发测试环境
硬隔离	独立Node/集群	生产环境、金融客户
混合隔离	控制面共享，数据面独立	大多数商业PaaS平台

我个人推荐混合隔离。控制面共享可以降低运维成本，数据面独立保证租户之间不互相影响。我在项目中遇到过，有个租户跑了个死循环，把整个集群的CPU打满了——幸好数据面是独立的，其他租户的Redis实例毫发无伤。

2.4.2 可观测性

每个租户只能看到自己的资源。这个听起来简单，做起来坑不少。

比如监控数据：你不能让租户A看到租户B的QPS。日志也一样，租户A的慢查询日志不能混到租户B的里面。

我的做法：所有监控指标和日志都打上租户标签（tenant_id）。查询时强制带上租户过滤条件。API层做拦截，防止越权查询。

2.4.3 计费性

计费是多租户的商业闭环。没有计费，PaaS平台就是个成本中心。

计费模型通常包含：

资源计费：按CPU、内存、存储使用量计费
流量计费：按网络出入流量计费
服务计费：按中间件类型和版本计费（比如Redis集群版比单机版贵）

我建议计费数据从数据面直接采集，不要经过控制面。控制面一旦故障，计费数据就丢了——那月底对账的时候，财务部门会疯掉的。

2.5 小结

这一章咱们聊了PaaS平台的架构分层、核心组件、控制面与数据面分离、多租户设计。说白了，架构设计就是不断做权衡：

控制面和数据面分离，换来的是稳定性和可维护性
多租户隔离，换来的是安全性和商业价值
声明式API，换来的是用户体验和自动化能力

下一章，咱们深入聊聊中间件服务化的核心——如何把MySQL、Redis、Kafka这些「有状态」的服务，跑在「无状态」的容器平台上。嗯，这才是真正的硬骨头。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录