在金融信息科技领域，集中式数据库向分布式数据库的转型正在如火如荼地开展。相较于集中式数据库将所有数据存放在一个节点中的做法，分布式数据库将数据分布到多个独立的节点中，每个节点都有自己的计算和存储单元，相互之间通过网络连接。这样的架构带来的好处是，可以通过大量节点来构建支持海量存储的数据库，大大增加了系统容量，同时还可以通过增加、删除节点的方式来进行动态扩缩容。另外，通过在不同节点上存储数据的多个副本，当某个节点损坏时，其它的节点可以接替故障节点继续对外服务，以提供高可用的能力。

分布式数据库在国内蓬勃发展，目前主要的部署方式是本地部署，即通过产品内置的部署工具，直接在裸金属服务器（下称物理机）上执行安装，数据库程序直接运行在物理机上。本地部署的优点是简洁明了，但同时也存在一些不可忽视的缺点。首先，本地部署方式下，数据库系统独占硬件资源，无法与其它系统共享硬件资源池，资源利用率低；其次，部署方式是封闭的，无法实现DBaaS，使得最终用户能按需申请数据库服务；

基于此，中兴通讯旗下金篆信科GoldenDB分布式数据库结合某国有大行PaaS平台环境，对本地部署方式进行改造，探索出了云化部署方式。依托行内PaaS平台，达成了以下两个目标：一是GoldenDB从PaaS中动态获取硬件资源，而非直接独占裸金属服务器；二是构建GoldenDB私有云，数据库管理员可以通过行内云管平台，实现分布式数据库动态部署。

GoldenDB的逻辑架构如图 1所示，整个数据库由管理节点与多个租户组成。租户是可以独立对应用提供数据库服务的基本单位，它由计算节点（CN）、存储节点（DN）和全局事务管理器（GTM）组成，并且，不同租户的节点相互隔离。每个租户中，计算节点负责向应用提供接入服务，CN可以有多个，是无状态的。存储节点则负责存储数据，有主备之分。租户的数据被分散存储到多个主节点，每个主节点又可以有多个备节点。GTM负责分配和管理分布式事务（跨分片事务）的ID。管理节点负责管理这些租户，记录租户下所有节点的地址、隶属的租户、DN的主备关系等等信息，这些信息称为元数据，同时，管理节点还会对各节点的运行状态进行监控，在节点发生故障时，执行主备切换。

图 1 GoldenDB逻辑架构

在本地部署模式下，每个节点都直接部署在物理机上，一个节点可以独占一台物理机，同时也允许多个节点共享一台物理机。部署前，需要人工判断物理机剩余资源是否能满足节点要求，另外，多个节点共享物理机的情况下，无法对节点使用的资源进行控制，可能发生节点之间争抢资源的情况，影响系统稳定性。

在实现云化部署的同时，也要尽可能兼容本地部署方式，确保方案的简洁性、产品的统一性。在此原则下，GoldenDB设计了如图 2所示的云化部署架构。

图 2 GoldenDB云化部署架构

首先，将数据库租户节点放到容器中运行，管理节点可继续在物理机中运行。管理节点占用资源相对固定，且一次部署后通常不再变化，因此动态资源分配等特性不是必须的，保持本地部署可以降低改造工作量。另外，租户节点的部署需要依赖管理节点，因此也需要先使用本地部署方式安装好管理节点，作为后续租户云化部署的基础条件。租户节点容器化可以带来诸多好处，其一，容器实现了节点资源的按需分配，其二，行内有成熟的容器平台（下称PaaS平台）基础设施，无需重复建设，其三，改造方便，将节点的安装文件制作成镜像，就可以完成容器化部署。

其次，向管理节点登记租户节点，完成租户的部署。分布式数据库的租户由节点和节点间的关系组成，容器化只完成了节点的创建，之后我们还需要对节点间的关系进行登记管理。例如节点与租户的隶属关系、DN所属的分片、DN的主备角色等信息，这些关系信息登记纳管到管理节点中后，才能算真正意义上完成了租户的创建，可以对外服务。因此，还需要对管理节点进行改造，开放创建租户的接口，将节点清单及节点关系作为参数传入，最终完成租户的部署。

GoldenDB云化部署有两个关键点。一是节点容器化，将数据库的节点运行环境从物理机改为容器，并以行内PaaS平台（如k8s）为底座，使得数据库和其它各类服务能共享统一的硬件资源池；二是管理节点开放纳管接口，将容器节点及其相互之间的关系登记到管理节点中，实际意义上完成租户的创建。

目前为止，已经可以在容器环境中部署租户，但还剩最后一个目标待完成，即统一的部署入口。数据库需要与其它基础设施一样，支持统一的部署入口，以达到DBaaS的效果。管理员或者最终用户可以在云管平台门户上申请数据库资源，填写所需规格和租户信息，即可完成环境的部署和交付。云管平台需要做少量的改造，从而能将容器创建、节点纳管等部署流程串接起来。

图 3 GoldenDB云化部署流程

最终的部署流程如下：

管理员或最终用户通过云管平台发起部署申请，填写节点类型、节点数、节点主备关系等信息；

云管平台调用PaaS平台，拉取预先制作的节点镜像，创建相应的容器，分配IP地址等；

云管平台调用GoldenDB管理节点元数据登记接口，将节点元数据、容器IP地址等信息作为参数传递；

GoldenDB管理节点解析收到的参数，对节点进行初始化，比如建立DN的主备复制关系；

GoldenDB管理节点最终将节点的元数据信息写入自身存储，至此，租户建立完成，可以对外服务。

分布式数据库与PaaS平台有一个重叠的功能，即高可用。前文提到，分布式数据库本地部署时，管理节点会对其它节点的运行状况进行监控，如果发生节点故障，管理节点会发起故障切换，以保证数据库的高可用。而云化部署下，容器发生故障时，PaaS平台也有自动重建容器的能力。那么在云化部署下，数据库的高可用应该依靠管理节点还是容器来实现呢？答案是仍然依赖管理节点。

原因有二。首先，数据库的高可用并不是简单地拉起节点，尤其对于有状态的DN节点。DN节点宕机后，必须仔细处理数据的一致性，而PaaS平台显然无法做到这一点。其次，继续由管理节点提供高可用能力，使得本地部署和云化部署模式下，高可用的行为一致、使用体验高度统一，简化了系统复杂度。

综上，GoldenDB通过与PaaS的有机结合，实现了分布式数据库的云化部署。这种方式兼容业界主流的容器化生态，架构简洁清晰，与云管平台简单适配后，可快速落地。同时，在最终使用和运维的体验上，与本地部署方式高度统一，降低了应用开发和运维的成本，是分布式数据库云化部署的有效实践。

目前在行内已经全面实现云化部署，并且已用于生产环境，已累计为10多个应用的测试和生产环境部署了近200个租户，达成了节点资源按需分配、资源隔离、快速部署等目标。后续还将继续改进管理节点的租户管理能力，支持海量节点（1000以上）管理及节点在管理节点间迁移的能力。