What is private cloud deployment site

2024-12-29

1 什么是专有云局点

专有云局点通俗来说，就是一个部署环境。在云原生的时代，部署环境也由以前的单机部署，拆分为分层部署方式。如下图所示：

如上图，私有化局点分层模型，由底到顶分别是：IaaS（基础设施即服务），PaaS（平台即服务），SaaS（软件即服务）。供应商提供的服务，也可以对号入座，当然做好服务的分层适配是必须要的。

举例来说，如果贵公司提供的是PaaS产品，那么：

该产品不必延伸交付类似IaaS产品，如果客户能够提供设施，该产品也应该能兼容。当然如果产品它不适配所有的芯片架构或者操作系统，也应该在产品的「限制」中枚举出来（或者列出只已交付过项目使用到的架构或操作系统）；
Nice-to-Have：如果贵公司具备了一定的基础设施的构建能力，那肯定能够提高产品售卖成功的概率。

1.1 多元的局点类型

对于一个已经上了轨道SaaS产品公司，会有非常多的局点，它有在家里的，也有在客户侧，有x86架构，也有可能是arm架构，或者混合架构（近几年来一云多芯的也比较流行）。客户侧局点与外界互联网有可能互通的，也有局点只能出流量不能进的，当然大部分是与外界不联通的。考虑到高可用，一般一个客户是双AZ的；再考虑到产品的迭代升级，一般一个客户至少有两个局点（测试局点和生产局点）。总结起来就如下图：

2 家里局点的治理

2.1 局点（环境）在产研阶段的使命

一个私有化产品的新feature开发，在家里需要依赖多个阶段轮转，才能真正落地，并给到客户使用。

如下图所示，这多个阶段大概可以归纳为：本地开发阶段、开发阶段、联调阶段、测试阶段、升级验证阶段。与公有云新feature验证大同小异，但也有他独特的，例如升级验证时需要验证多个芯片架构和操作系统。

产品私有化的各个阶段，都需要至少1个局点环境的支撑，每个局点的作用也不同。

开发会在本机和特性环境进行开发，通过后，推送到联调环境。所有的开发都共用一套联调环境，联调结束之后，统一合并到测试环境中，测试同学在测试环境进行系统测试。项目pm统一卡时间点，当测试结束了，进入到升级验证阶段，在演练环境，交付同学主要关心升级过程是否存在问题，而测试同学为了保险起见，也需要再回归新特性是否有bug，或者bug是否修复完成，验证成功后，才会确定出包的组件集合和关联的镜像版本。

2.2 多阶段局点的困境

上图中有两个比较严重的问题：

开发联调环境只有一个；为了提高机器资源利用率，并非所有的新特性都会部署一个环境去支撑研发自测（一般来说大特性才会部署一个局点），所以联调环境经常会有发布，这样会导致环境经常性的不可用。每天测试群里反馈最多的就是：“环境怎么访问不了了”、”怎么我提交的代码被覆盖了”、“环境什么时候可以用啊！！”。由于前面环境的问题，导致了后续测试的同学也非常痛苦，刚刚验证完的bug，突然又出现了。严重降低了集成的效率；
除了个人开发阶段，在新特性开发阶段、升级验证阶段都需要多个局点。所以如何能够快速部署一套新环境，压缩这两个阶段停留的时间，也正是PM和产研急切期望的。

针对上面说的两个问题，分别在2.3-2.4中提出可实施的建议。

2.3 联调环境的备局点

给联调环境做一个备局点，是能够想到解决局点单点问题最直接的方案。它和传统的主备方案还不太一样，异同点如下：

	主流的主备方案	联调环境的主备局点方案
应用场景	一般常见生产环境	专有云家里的联调环境
数据同步机制	主同步备	主同步备
主备组件镜像版本和数据	一致	按X个小时周期自动同步
主备切换用户感知	无感	有感，数据和版本回退到X小时前

其实主要是主备局点组件版本的差异点，因为每个小时都会有很多研发新版本推送联调环境，与其他特性的相互不兼容，导致某些组件crash而环境不可用，这是就可以人为切换为备局点（对外的访问域名是相同）继续提供服务，避免了其他特性测试被阻断的问题。切换如下图所示：

2.4 快、省

局点的可快速构建、更省的资源（静态资源和动态资源）使用，是在开发阶段和升级验证阶段急切需要的。在这里就需要不断地完善一套底座系统，用于实现私有化场景下，接入、准出、组合交付验证等端到端流程自动化，全面提升工程效率。其中，在线部署模块旨在解决私有化产品接入过程中环境部署复杂、耗时且人力成本高的问题。通过在线部署，只需进行少量配置，便可实现无人值守，并且最快在0.5-1小时内即可自动化搭建一套环境。

这套底座系统，其实也可以按照一个产品去做，它可以实现几个最原始的需求：

快速（0.5-1h）且自动化交付一套局点环境；
支持多芯，多操作系统的适配，包括满足信创要求；
提供公共能力，例如集群管理、租户、API、权限、监控、自愈、故障演练、日志收集和搜索等，以及产品快速&简单接入的能力；
尽可能少的资源占用，包括：存储、CPU和内存。目前来看3 * (8C16G 1T)的资源可以认为是合理的。

3 交付的复杂性

3.1 新交付&迭代

交付又有新交付和迭代升级，这两种场景不一样。

一般来讲新交付局点事情更多，要从计算、网络、存储等IaaS层资源去考虑局点是否具备可部署，各种各样的precheck可能会在预检流程中发现，或者不幸地，在交付实施阶段才发现。然后需要将所有的物料都准备好，做一个整体的局点交付

迭代升级是指在之前已交付的局点上，针对某些应用进行升级。一般来说这种局点的IaaS层基本是维持原样，而升级的是PaaS或SaaS层的应用。这时基本也没有预检的工作，也只需要准备好需要升级的物料。

3.2 离线网络

考虑到大部分的局点与外界都是不通网的，所以只有离线交付一种可能。

当然如果产品本身可能有需要回源到互联网，可能可以利用这点，先考虑有网络的这种简单交付方式。

3.3 黑屏升级

前几次的局点交付肯定是黑屏，而且交付步骤也是写在一个文档上，一线交付人员按步骤进行。这种黑屏交付方式，虽然经过家里环境的验证，但是家里环境并非能100%模拟客户的环境，一旦遇到问题，交付人员也没能在文档中获取有用的信息，导致交付受阻。另外交付人员能力参差不齐，态度也会差异，漏步骤也是经常发生。

所以黑屏操作只使用产品的交付的刚刚起步，随着客户局点的不断增多，白屏交付和升级是必然趋势。而白屏交付的工具也是需要额外的研发投入。