1. 概述
在本文中，我们将介绍 Spinnaker，一个由 Netflix 开源的持续交付平台。我们可以使用它在多个云服务商上部署应用程序。
✅ Spinnaker 基于 Spring Boot 构建，支持多种云服务商。
我们会了解它是如何工作的，以及适合哪些场景。
2. 背景知识
回顾软件开发的历史：
- 最初采用瀑布模型，发布频率低。
- 后来转向敏捷开发，每轮迭代交付功能。
- 但即便如此，我们并没有每轮都部署到生产环境，导致用户无法及时使用新功能。
为什么部署频率不高？
- 部署步骤通常需要手动执行，容易出错。
- 有人认为频繁部署会增加风险。
✅ 如今我们普遍认为，小步快跑反而风险更低。即使出错，也更容易定位和修复。
3. Spinnaker 简介
Spinnaker 支持持续交付（Continuous Delivery）和持续部署（Continuous Deployment）。
- ✅ 持续交付（CD）：所有部署准备就绪，但需要人工审批后才部署。
- ✅ 持续部署（CD）：完全自动化，无需人工干预，代码提交后自动部署到生产环境。
从代码提交到生产部署，中间可以执行多个步骤，比如：
- 编译代码
- 单元测试
- 部署到测试环境
- 执行功能测试
这些步骤通过“Pipeline（流水线）”进行配置。
✅ Spinnaker 允许我们创建这样的流水线，并支持部署到几乎所有主流云平台。
4. 核心组件
Spinnaker 主要由两个部分组成：
- 云服务商抽象层
- 持续交付工具
4.1. 传统云部署的问题
各大云服务商提供的服务大致相同，例如：
- 虚拟机实例
- 无服务器架构（Serverless）
- 容器支持
⚠️ 但它们的配置方式差异巨大，这导致切换云服务商成本高，形成“云厂商锁定”。
Netflix 希望能灵活切换云服务商，因此构建了统一的抽象层。
4.2. 抽象层设计
使用 Spinnaker 时，无论使用哪个云服务商，操作体验都是一致的。
它支持：
- Amazon Web Services（AWS）
- Microsoft Azure
- Google Cloud Platform（GCP）
- OpenStack
- Google App Engine
- Kubernetes
✅ 这意味着我们可以轻松切换云服务商，甚至同时部署到多个平台，实现高可用性。
另一个关键设计是“以应用为中心”的理念：
- 传统云平台展示的是资源（如 EC2 实例）
- Spinnaker 展示的是应用，资源只是附属信息
✅ 我们更关心的是应用是否运行正常，而不是具体用了哪些资源。
4.3. 持续交付平台
Spinnaker 在抽象层之上构建了完整的持续交付平台。
它类似于 Jenkins，但对云平台集成更好，配置更简洁。
常见的触发方式包括：
- Jenkins 构建
- Docker 镜像上传
- Git 提交代码
部署过程可以包括：
- 构建镜像
- 启动容器
- 自动化测试
- 手动审批
- 多种部署策略
例如，我们可以在部署新版本时选择“蓝绿部署”或“金丝雀发布”，确保新版本稳定后再替换旧版本。
5. Netflix 的云模型
每个应用由一个或多个“Server Group（服务器组）”组成，每个服务器组中运行的是同一版本的应用。
命名规范如下：
<应用名>-<（可选）环境>-<（可选）描述>-<版本号>
示例：
myapp-prod-db-1.0.0
prod表示该服务器组用于生产环境db表示用途是数据库服务
Cluster（集群） 包含一个或多个 Server Group，它们具有相同的名称、环境和描述，但运行的是不同版本的应用。
如果某个实例失败，系统会自动替换。
✅ 还可以根据负载自动扩容服务器组。
6. 部署策略
Spinnaker 默认采用“Red/Black（红/黑）”部署策略。
流程如下：
- 部署新的 Server Group（新版本）
- 检查新版本是否健康
- 启用新 Server Group
- 禁用旧 Server Group
⚠️ 这种策略的好处是便于回滚。如果新版本出问题，只需重新启用旧 Server Group 即可。
7. 为什么选择 Spinnaker
- ✅ 专注于应用本身，而非底层资源
- ✅ 支持多云部署
- ✅ 灵活切换云服务商
- ✅ 提供丰富的部署策略
对于需要在多个云平台上部署和管理应用的团队来说，Spinnaker 是一个非常理想的工具。
8. 总结
Spinnaker 凝聚了 Netflix 在云原生部署方面的丰富经验。
我们可以直接利用这些经验，快速构建自动化部署流程，而无需重复造轮子。
✅ 推荐阅读：《Continuous Delivery with Spinnaker》电子书（免费下载）