2022年，OceanBase发布4.0版本“小鱼”，并首次公开提出了单机分布式一体化这一理念，旨在适应大小不同规模的工作负载，全面满足用户数据库“从小到大”全生命周期的需求。当时，我们所说的“从小到大”主要聚焦于数据库的“内功”，即数据库内核技术。然而，一个好的数据库产品，仅有深厚的“内功”是远远不够的，还需要有“外功”支撑，即数据库生态产品体系。

接下来，让我们从管控产品的视角，回顾OceanBase在“外功”方面的成长与进步，看看它是如何助力开发者满足从小到大的多样化需求的。

初学者的上手成本

首先来看初学者需要什么？初学者主要关注两个方面——部署成本和部署难度。

1、部署成本

自2021年OceanBase开源以来，我们一直在做产品小型化的迭代，从64G的配置要求优化到如今的2C6G配置要求，期间我们从未讨论存储，因为相比CPU和内存，58GB的存储太廉价了。

直到我们和来自高校的学生交流时，才发现原来我们忽略了一个非常关键的细节。

通常，还未走出校门的学生使用的电脑是Windows或MacOS，而OceanBase目前只支持lLnux系统。很多同学会选择从云厂商购买Linux服务器。下图是主流厂商满足OceanBase配置要求（2C6G）的最廉价的一套配置。

我们发现无论上图中哪种配置都无法满足最低58GB的配置需求，因此，学生在买机器时就需要额外增加存储成本，更糟糕的是，买完机器后发现50GB难以支撑系统运行，还得再买58GB，最终，购买了108GB，这都是额外成本，对学生来说非常敏感。

2024年，我们把58GB的配置要求优化为20GB配置要求，且其中的16GB是真正数据存储，预留4GB日志存储，大大降低首次启动的存储开销，降低学生的上手门槛。

2、部署难度。

分布式系统部署一直都是“老大难”。2023年我们针对易用性做了很多优化，比如OceanBaseD demo快速体验环境、OceanBaseD WED图形化部署，还推出了all in one一键式安装包。但我们发现，不管使用哪套模式，都会遇到共同的问题，那就是用户需要额外下载一个安装器，这并不符合Linux开发者心目中的安装模式。

什么样的安装模式符合Linux开发者预期？在Centos上使用yum isntall，在Ubuntu上使用apt-get install。而在OceanBase 4.2.1版本开始我们支持原生yum/apt-get install，支持使用 systemctl 管理数据库。

同时，我们还与许多操作操作系统社区紧密结合，例如，实现在龙蜥（OpenAnolis）和欧拉（OpenEuler）社区的制品平台上完成从源码到制品的构建，且制品包被两个社区官方仓库收录。这意味着在OpenAnolis和OpenEuler中安装OceanBase将不再需要添加额外的仓库源，开发者只需使用以下两条指令就能快速启动OceanBase数据库。

yum install oceanbase-ce
systemctl start oceanbase

当然我们不会止步于此，未来我们将推动OceanBase与更多的操作系统社区合作，让开发者可以用最简单直接的方式安装OceanBase。

同样的，我们也在积极推进对Windows和MacOS的编译适配工作。任何曾尝试过大型C++项目跨平台编译的开发者都深知，实现像OceanBase这样大型C++项目的跨平台构建既复杂又具有挑战性。

尽管如此，我们仍旧坚持推进下去。也希望开发者们参与共建，在社区和我们一起共同克服困难。

企业开发者需要什么

当一个开发者进入企业或开始管理自己的项目时，他们面临的数据库管理需求显著提升。这时，他们需要的是一个能够提供全面管理功能的数据库管控台，用以高效、便捷地管理数据库环境。为此，OceanBase社区版提供了两款针对性的产品来满足这类需求：OCP 及其轻量版本OCP-Express。

OCP-Express 设计理念是提供一个轻量级的解决方案，它专注于本地集群的管理。该平台的优势在于功能的聚焦性和简化性，部署时不需要额外的MetaDB成本，非常适合初期阶段或小型项目的需求。通过OCP-Express，开发者可以享受到快速、直接的数据库管理体验，无需承担过多的技术和财务负担。

随着项目规模的扩大和数据管理需求的增长，集群数目也可能随之增加，这种情况下，OCP 成为了更合适的选择。OCP提供了更全面的多集群管理功能，支持规模化的管控操作。这意味着对于那些管理着大规模集群或多项目集群的企业和开发者来说，OCP能够提供更灵活、更强大的数据库管控解决方案。然而，选择OCP的同时也意味着面对更多的部署考虑，包括额外的部署工作及相应的MetaDB成本。

那么，怎么打通从yum/apt-get install到ocp-Express再到ocp的链路呢？这里就需要用到OceanBaseD（OceanBasedeployer）。OceanBaseD是随着OceanBase开源的第一批产品，顾名思义，这是一个专注于部署的软件。但早期开源社区管控的产品不是很成熟，因此我们基于OceanBaseD做了一些轻量的运维功能。当下随着管控生态完善，我们可以使OceanBaseD专注于其本应承担的核心职责——软件包管理和部署。

在OceanBaseD的2.8版本中，我们引入了一项新功能——接管集群。通过一个简单的命令——OceanBased cluster takeover -h host -p password <deploy-name>，开发者可快速将用yum/apt-get install部署的OceanBase集群纳入OceanBaseD的统一管理之下。一旦集群被OceanBaseD接管，便可以在现有基础上增加新的组件。

在OceanBaseD 2.4.0版本新增了组件变更能力，使开发者能在已有的OceanBase集群上加装新的组件，比如 OCP Express。了解OceanBaseD的朋友可能会说，“这个为已有集群安装OCP Express的功能你们一年前就做了，新版上有什么不同吗？”

我们可以看到下图的配置对比。左边是我们旧版本，共51行，其中大量的配置与OceanBase相关。此前由于没办法在已部署的配置上直接追加新组件（如OCP-Express，我们每次添加新组件都需要从头编写一个全新的配置文件，并手动为这些组件添加与其相关组件的配置信息），导致冗长的配置过程，作业繁重且易出错。

现在，请看右边这份新版本的配置，在优雅的区别中，它仅包含18行代码。真正关键的设置只在第17和18行，提供了配置路径和内存规格要求，大部分配置都涉及基础的组件信息和集群拓扑。得益于新版本的功能，我们可以使用depends关键字将OCP-Express与OceanBase集群简洁、有效地关联起来。OCP-Express能够从OceanBase集群中自动获取其需要的设置信息，而OceanBase也能感知到OCP-Express的加入，自动为其创建Meta租户。完成新的配置文件编写后我们只需要一条命令即可完成组件追加——OceanBased cluster component add <deploy-name> -c new_conf.yaml。新版本中的自动化流程，大大简化了整个部署过程，消除了以往繁杂的手动步骤，确保了新增组件的平滑与稳定。

随着业务增长和集群数量的增多，我们需要具有多集群管理能力的OCP。此前，OCP的部署也是一个令人头疼的问题，但随着更新，OCP与OceanBaseD的结合让该问题得到了解决。OceanBaseD现在能够支持通过命令行的方式自动化部署OCP，当然通过之前提到的组件变更功能也同样适用于OCP的部署。但我不推荐大家这么做。虽然OCP可以对自己的MetaDB进行一定的运维管理，但这种管理并非全面。此外，我们不建议拿业务集群来承担OCP的MetaDB。原因在于，业务集群通常需要应对业务带来的压力，一旦业务负载增强，OCP对自身MetaDB的连接可能会受到影响。在业务压力大时，如果不能通过OCP及时对业务集群进行扩容，以缓解负载，就可能陷入一个恶性循环。

为了简化部署过程，推荐大家使用OceanBaseD的Web界面部署的MetaDB和OCP。使用这种方法，MetaDB将由OceanBaseD部署，而OceanBaseD本身就能为该集群提供基础的管理功能，包括但不限于扩容、升级，启停等服务。

OCP部署完成后，我们便可以将现有的OceanBase集群接入到OCP中。OCP自社区版发布起就具备接管OceanBase集群的能力，但过程较为繁琐，需要多达五个步骤——选择连接方法、填写连接信息、添加主机信息、选择主机类型、添加登录证书。为了简化这一流程，OceanBaseD V2.4.0引入了一个新命令 OceanBased cluster export-to-ocp，允许用户一键将OceanBaseD管理的集群导入到OCP中，导入完成后，也便不再需要OCP-Express。这里可以继续使用OceanBaseD的组件管理能力，通过OceanBased cluster component del <deploy-name> ocp-express命令直接从现有的集群中移出OCP-Express。

基于Kubernetes的新运维

随着全面上云时代的到来，OceanBase也不例外，为了迎合不同用户的需求，提供了多样化的选择方案。对于喜欢公有云服务的用户，可直接在各大云平台上购买OceanBase的公有云服务，享受便捷的数据库体验。而对于那些偏好将数据库系统完全掌握于手中的用户，我们推出了一套基于Kubernetes operator的方案——OceanBase-Operator。OceanBase-Operator项目首次亮相于2022年4月，在2023年的开发者大会上的workshop上同大家一起体验了基于yaml编排的方法创建和管理集群。

为了进一步简化操作，我们引入了operator Dashboard，通过这个可视化界面，用户可以更加便捷地管理其集群。仅需四条简单的命令，就能完成OceanBase-operator和Dashboard的部署。随后就可以完全摆脱YAML文件，在图形化的界面中运维集群。

那么，在Kubernetes上，我们能获得的全新体验是什么？

在传统的物理机环境下，向OCP添加一个节点需要经过一系列繁琐的步骤，包括准备物理机、将其加入OCP，接着加入相应的Zone，并最后提交任务。现在，利用Kubernetes的能力，这个过程变得极其简单，不再需要在考虑新的物理机在哪里，只需要在Dashboard 上调整副本数——比如从1增加到2并提交即可。OceanBase-Operator随后自动完成所有必要操作，实现快速而无缝的扩容。

如果出现节点或整个可用区故障的情况，传统的运维方式将是一场噩梦。运维人员需要将新的主机一台台加入OCP，并一一配置到对应的Zone中。而在Kubernetes中，这一切将完全自动化。一旦OceanBase-Operator检测到副本数量减少，它会自动调度新的Pod来恢复服务，无需任何手动干预。OceanBase-Operator根据存储介质是否可用，OceanBase-Operator会自动决策是重启服务，还是通过挂载新的PV以扩容形式迅速恢复服务。

我们计划未来将支持HPA（Horizontal Pod AutoScaler）功能。用户将通过设定具体的扩缩容指标，OceanBase-Operator能在系统负载升高时自动进行扩容，负载下降时则自动缩容。这一功能在极大减轻运维人员的工作压力的同时还为企业节约了成本。

统一运维接口

上面提到的都是OceanBase原厂提供的管控服务，而对于那些有自建管控平台需求或希望将OceanBase 集成到已有自建平台中的用户，可以使用OceanBaseShell。在OceanBase 4.2.1或更高版本中，我们可以在OceanBaseserver执行文件旁边发现一个新的二进制文件，名为OceanBaseshell。OceanBaseShell是一个结合命令行操作和OpenAPI的软件，它不仅适用于日常运维，还能在OCP或OceanBaseD出现故障时提供应急运维支持，如应急启停、扩缩容、升级等。

OceanBaseShell还提供了一套统一的运维API，为运维动作提供了标准接口。利用OceanBaseShell实现的功能，我们实现了yum/apt-get install部署集群，未来，我们还将基于OceanBaseShell完善这套方案，包括扩容、缩容、升级等。同时OceanBaseD也部分接入了OceanBaseShell，这也是其能接管yum/apt-get install部署的集群的原因。后续我们将继续推进管控产品全面接入OceanBaseShell，以实现统一标准的运维和任务状态的同步。

此前当一个由OceanBaseD部署的集群被OCP接管之后，我们会建议用户不再使用OceanBaseD对该集群进行运维操作，以避免可能发生的运维冲突。全线接入OceanBaseShell之后，所有的运维任务都将通过OceanBaseShell的接口下发，从而确保无论任务是由OceanBaseD、OCP还是用户自建的管控台发起的，都不会发生冲突。

目前，社区已经准备好了OceanBaseShell的GO语言SDK，并计划提供包括Python在内的更多语言的SDK。如果大家需要其他语言的SDK，欢迎在社区提出需求。

同时，我们欢迎开发者加入社区，一起参与OceanBaseShell以及其他生态产品的建设。