本文介绍了SaaS服务私有化部署面临的挑战，如版本化不足，提出了通过统一版本格式和Helm进行版本管理和构建部署的解决方案。文章详细阐述了如何围绕Helm构建日常构建发布流程，并探讨了实践中的一些细节，如镜像tag的管理。最后，提到了云效的AppStack产品，它是对这些实践进行产品化，降低开源工具使用门槛的尝试。
大家好，我是崔力强，我在云效负责Flow流水线的开发工作。近年来，SaaS化部署形态的产品的私有化部署需求越来越多，比如云效自身就有私有化部署的版本。为了能够有效且高效地同时管理SaaS版本和私有化版本的发布过程，云效团队也结合云原生的基础设施和标准化工具（比如helm）进行了一系列的探索和实践，并将其中一些通能的能力进行了产品化。本文会从问题本身出发，讲解解决问题的思路，及如何通过“DIY”的方式来实现这套思路。最终讲解云效AppStack产品是如何对这些实践进行产品化，并使其更容易规模化。
SaaS服务在版本化上的先天不足
软件交付有两种基本场景：面向大版本的交付和面向SaaS的升级更新。
通常来讲，提供本地或私有化部署的软件都属于第一种。比如Jenkins刚刚发布了2.319.2版本，那么这个版本里包含了什么样的特性就是明确的。你拿着这个安装包在任何一台机器上都可以从头安装得到这些功能。
而互联网产品很大一部分是SaaS化的，即只有一套部署，供所有用户使用。软件的维护者更关心的并不是我的产品是否可以在任何一个数据中心从头搭建出来，而是如何在现有的这个运行中的系统上通过更新某个组件或者服务来快速的交付一个特性。
图1：SaaS服务交付和大版本交付的交付节奏
从上述的示意图，可以形象地看到两种交互方式的差异。
面向大版本的交付会明确该版本中包含的特性以及交付时间， 版本的发布时间间隔通常比较长，需要对版本的全新安装以及不同版本之间的升级安装进行详尽的测试。
面向SaaS的升级更新，交付的频率比较高，可以快速响应市场上的需求，但相应的规划性比较差。同时因为“可重复安装能力”的优先级要低于“快速利用已有的服务和能力交付新特性”，因此在架构上可能会逐步产生复杂的依赖，从而进一步地使得全新部署这套服务变的越来越困难。
然而现实并不是非黑即白的。有可能一套互联网产品在发展了若干年之后有了进军海外的需求
最低0.47元/天 解锁文章
1749
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
