Flyme公有云平台建设

# 1. 背景

公司在多个可用区拥有自建机房，为满足内部资源统一纳管及对外提供云服务的能力，主导将自建机房改造为公有云平台，面向第三方企业提供标准云产品与底层云底座能力。

目标：聚焦车企数字化转型、车联网、智能座舱等核心场景需求，打造适配车企业务特性（高可靠、低延迟、高安全、可扩展）的公有云平台，实现内部资源统一纳管与对外标准化云服务输出。

远景：从车企、手机互联客户迈向全行业需要上云的客户，向阿里云看齐。

# 2. 整体规划

# 阶段1：基础准备与底座搭建

核心目标：完成机房资源梳理、基础环境部署、核心底座框架搭建、网络隔离策略验证，实现资源可视化与初步纳管，为后续云产品落地奠定基础。

# 阶段2：核心云产品与子系统开发

核心目标：落地基础云产品（ECS、RDS等）与核心子系统（租户、计费、网络等），实现“基础服务可购买、资源可调度、使用可监控”。

# 阶段3：高可用架构完善与场景适配

核心目标：完成多可用区容灾、车企场景定制化适配、发布平台、可观测体系优化，实现平台高可用、高适配，支撑车企核心业务（如车联网数据传输、智能座舱后台）。

# 阶段4：平台优化与商业化落地

核心目标：优化性能、完善安全体系、推出车企定制化云产品，完成商业化部署，实现对外规模化服务。

# 3. 服务能力

总体架构:

云产品体系建设：涵盖
- ECI 弹性伸缩服务
- ECS 弹性云服务器
- ALB 微服务网关
- RDS（Redis/MySQL/Elasticsearch/ClickHouse）
- RMQ（RocketMQ/Kafka/RabbitMQ）
- 可观测（类似 ARMS）
- 微服务引擎（Nacos、Zookeeper、Apollo）
- 块存储/对象存储 (类似OSS、S3)
- 监控大盘与告警
云底座能力构建
- 计算子系统
  - OpenStack 裸金属服务器（IMS）与高性能虚拟机（ECS）的编排、网络隔离、资源池管理、规格划分。
  - K8s 多集群管理池，不仅仅是 ACK，更要解决底层资源池的统一调度，保障平台多租户隔离、高可用与可扩展性。
- 网络子系统
  - VPC 虚拟专有网络：基于 VxLAN 实现租户间的网络隔离。
  - 混合云专线：车企通常有本地机房，必须提供物理专线或 VPN 网关接入。
- 计费系统
- 多租户/网关
应用生命周期管理
- CICD 流水线发布平台，深度集成 Harbor 和代码库，多可用区纳管，一键式快速构建、发布、部署，回滚
- 微服务治理，提供 ALB/NLB 负载均衡，集成服务发现与熔断限流。
- 人车家埋点服务，提供海量大数据上报链式服务
多可用区高可用架构：利用多可用区自建机房资源，设计并落地 跨可用区容灾与调度机制，确保云服务在单可用区故障时仍具备持续服务能力。
统一网关与可观测性：构建 统一网关路由与鉴权体系，集成 告警引擎与可观测平台，实现对全链路服务状态、资源使用、业务指标的实时监控与智能告警。包括：
- 日志服务 (SLS)：海量日志采集、索引与实时分析。
- 追踪系统 (Tracing)：基于 OpenTelemetry 协议，解决微服务间的调用链排查。
- 统一告警中心：支持告警收敛、抑制，通过企业微信、电话、钉钉多渠道触达
针对车企场景的专项建设，车联网接入优化、驾驶套件、合规审计
- OTA 云端下发子系统：专门处理车辆固件升级的 CDN 加速与版本灰度控制。
- TSP（车载信息服务平台）能力底座：预集成车辆状态接入、远程控制等标准 API。
- 数据本地化：支持按区域部署实例，满足车联网数据不出境要求
- 审计日志：所有云产品 API 调用全量审计，满足等保合规
- 数据加密：支持租户自主管理 KMS 密钥
- 隐私计算：车端数据脱敏处理后再上云

# 4. “做平台”如何上升到“如何规模化交付云产品”？

要把一个自建机房真正变成“公有云”，核心原则只有一条：把“人”从资源交付的日常链路中彻底踢出去。

过去内部机房的模式是：开发提工单 -> 运维审批 -> 运维去后台敲命令/点界面 -> 交付。

但在批量交付的公有云中，这个模式可不行，所以首先想到的是使用 Ansible 。

使用 Ansible 作为自动化交付引擎是非常务实且广泛采用的方案，特别是在交付基于虚拟机（ECS）或裸金属的复杂云产品（如高可用 RDS、Kafka 集群、Redis 集群）时，Ansible 强大的配置管理能力和海量的模块生态是巨大的优势

维度	Ansible (Core)	AWX
产品性质	开源、免费	开源、免费
使用方式	命令行 (CLI)	Web UI + REST API
目标用户	个人、小团队	中型团队、自建自动化平台的研发
稳定性	极高（核心引擎）	一般（迭代快，社区支持）
在你的“云架构”中的角色	隐藏在底层的执行者	推荐作为中间件，提供 API 供云控制面调用

两个原则：

绝对不要只用 Ansible Core 然后用代码去拼接 shell 命令，这将会难以维护
首选 AWX：它是目前绝大多数自研云平台、DevOps 平台集成 Ansible 的标准做法。部署一套 AWX 集群，在里面配置好相关的凭证和 Playbook 仓库。“云管平台端 (Cloud API Server)” 只需要通过标准的 HTTP POST 请求去调用 AWX 的 Job API，将资源参数（如 IP、规格）作为 extra_vars 传过去即可。