背景

   华为公有云业务随着近几年的发展，越来越复杂。除了华为自己运营的公有云之外，还存在与国内乃至世界的各大运营商合作伙伴合作运营的云模式。因为各种形式的云（局点）独立运营，不可避免的存在一些功能上的差异。那么，具体到代码开发上而言，如何通过维护一套代码就可以满足这种差异性，成了开发遇到的比较大的挑战。

   华为云的底层基础设施建设是以区域（Region）为基础进行的，所以数据库的后台服务也是以区域为单位部署的，但是数据库控制台前端并不需要直接接触底层资源，没有必要做 Region 级部署，否则会造成资源的浪费。因此前端组件采用的是全局（Global）的部署方式，即一个全局的前端组件，对应多个Region级的后台服务。

  随着业务的扩展，底层建设的Region越来越多，后台部署的区域也会越来越多。当每个版本发布时，按照通常的前后端分离的发布模式，都是先升级后台服务，最后升级前端组件。但是Region的增多，势必会造成升级周期的延长，又因为前端是Global的部署方式，不可以在后台服务升级完成之前就做升级，只能等到所有的Region都升级完成后才能升级。造成的问题就是新开发的功能对用户呈现会存在严重的滞后，而且Region越多，越严重。

   为了解决上面的问题，既能够高效的做到不同形式的云交付差异性，又能够尽早的让用户看到华为云的新功能，华为云数据库控制台前端服务先后经历了三次变革。

阶段一：分支交付

不同的局点使用不同的主干分支，每个分支各自维护要交付的局点功能，每个局点的版本交付从对应的分支拉代码进行开发。各个主干分支生命周期跟局点生命周期一致。这种开发模式，各个局点的功能单独开发，互不干扰，但是其缺点也比较明显：

• 随着交付局点的增多，分支越来越多，维护成本越来越高；

• 同一个功能或者问题单，如果需要交付多个局点，代码需要重复开发，开发效率低下；

• 不能解决先升级前端控制台，后升级后台服务的兼容性问题。

阶段二：配置参数交付

在升级工具做升级的时候，每个局点维护一套自己的配置参数，参数控制相应的功能是否在当前局点交付。每个版本的升级参数通过文档进行维护，并且是增量维护。这种维护方式的缺点：

• 配置参数繁多，不同局点开关维护成本高，特别是新局点交付，运维需要配置的参数多，出错概率大；

• 配置参数通过文档维护，每个版本维护当前版本的增量开关，其他开关继承之前版本的配置。久而久之，难以知道各个局点当前现网的配置是什么，造成升级是参数找不到；

• 需要开关屏蔽或者放开某个功能，需要修改配置参数，做同版本升级才能生效；

• 不能解决先升级前端控制台，后升级后台服务的兼容性问题。

阶段三：开关交付

开关交付是在配置参数交付的基础上，将升级参数中的开关落到后台数据库表中。因为后台数据库的部署是Region级的，每个Region单独维护一张特性表，所以可以做到Region级屏蔽，同时满足不同局点交付不同特性功能的目的。每个版本涉及的开关，通过SQL语句刷到部署包（feature-data包）里面，部署包的部署顺序放在API升级之后。开关交付的特点：

• 配置开关落库，通过 API 查询状态，前端根据接口返回的开关状态进行特性展示或者屏蔽的控制

• 修改实时生效，只要在运维平台把对应的开关状态做修改即可

• feature-data 包升级之前，前端看不到相关的特性；升级之后根据包里面的开关默认值显示是否显示

开关的设计分为两层维度：局点差异及引擎差异。以华为云关系型数据库RDS为例，除了交付多个局点外，RDS还包含了MySQL、PostgreSQL等不同的数据库引擎。局点差异通过Region级的表实现，不同局点的Region是相互独立的，同一局点的Region也是相互独立的。引擎差异通过在表结构里面设置engine字段区分，每个引擎对应自己的开关。前端根据各个Region查询的结果以及同一个Region的引擎支持情况，处理页面上的功能是隐藏还是现实。伪代码判断逻辑如下：

if 开关与引擎先关
  return 当前局点支持 && 当前引擎支持
else 
  return 当前局点支持

经过三个阶段的改造，当前基本可以解决之前遇到的局点特性差异交付，先升级后台在升级前端的兼容性等问题。

但是随着业务的发展，一些基于开源数据库而自研的数据库版本逐渐增多。这样，原有的局点及引擎两层判断逻辑不再能够满足需求。目前的解决方案是新增引擎的某个版本通过特性的方式进行控制。这样导致的问题就是已有的先关开关，会被入侵式的修改，改动点多，出现问题大概率也会增加。后续可以将开关作为下一层的维度，落到数据表中，通过API查询。