我大胆预测：Kubernetes和微服务将这样‘误伤’Oracle

光靠开源数据库，真的能撼动Oracle（O）的地位吗？现实给出了否定的答案。MySQL和PostgreSQL（PG）问世这么多年，O依然屹立不倒。回想2018年，我们四处举办“PG干O天天象上”活动，场场爆满，但一年下来，O毫发未伤！

那么，究竟谁能真正动摇O的根基？

我的一个大胆预测是：真正对Oracle构成“降维打击”的，可能是Kubernetes（k8s）。有趣的是，Oracle很可能是在这场技术变革中被“误伤”的。这听起来有些不可思议，毕竟k8s和数据库本是两个领域，Oracle这次真是有点“惨”。

我们来分析一下这个观点是否站得住脚。

随着容器服务的兴起和应用微服务化架构的流行，每个微服务往往搭配一套独立的数据库。这导致数据库被拆分得非常细碎，在大多数场景下，单个数据库的故障影响范围变得很小。最终，数据库软件长期以来引以为傲的稳定性、高可用性能力，其重要性似乎被相对削弱了。

试想，企业会在微服务架构中广泛采用Oracle吗？显然不会。一方面，O价格昂贵；另一方面，O过于“笨重”，一点也不轻量化。传统上，O的用户倾向于构建庞大的数据库实例（网络上不乏优化数十TB大实例或数万高并发的技术文章）。然而，Oracle这些引以为傲的能力，在应用微服务化之后，几乎失去了用武之地。微服务架构中最常用的，是那些轻量、易于管理、对开发者友好的开源数据库，例如 MySQL、PostgreSQL、MongoDB、Redis等。

在Kubernetes平台上，出现了专门管理数据库的产品，例如 KubeBlocks 。从其项目简介可以看出，它提供了标准的接入接口，能为接入的数据库提供最基本的高可用、备份、恢复、创建和释放实例等功能。

KubeBlocks could manage various type of engines, including RDBMSs (MySQL, PostgreSQL), Caches(Redis), NoSQLs (MongoDB), MQs(Kafka, Pulsar), and vector databases(Milvus, Qdrant, Weaviate)... Currently it has supported 32 types of engines.

同时，KubeBlocks支持接入DBdoctor、PawSQL、Bytebase等SQL审核、性能诊断与优化工具，以满足常见的运维需求；接入NineData这类工具来解决数据同步与迁移问题。随着周边工具的不断丰富，数据库的日常使用链路日趋完善，开发者即使不深谙某款数据库产品的所有细节，也能大规模地用好它。

最关键的一点来了：由于开发者已经非常习惯Kubernetes和容器化的操作模式，他们就能非常顺滑地接受并使用像KubeBlocks这类基于k8s的数据库管理平台。

最终，随着开源数据库使用量的爆炸式增长，会反向推动开源数据库生态愈加成熟和稳定。而那些原本在重要场合非Oracle不可的“堡垒”，也会被逐渐蚕食。

等等，我们是不是忘了什么重要问题？

哦，对了！用开源产品，出了问题谁背锅？

兜底问题，尤其是在关键业务中使用的数据库，开源方案如何保障？总不能“白嫖”开源然后出了问题还去找开源作者索赔吧？开源项目可没有这样的SLA（服务等级协议）。

仔细想想，答案其实已经有了：不是还有基于开源的商业数据库厂商吗？所以我们可以看到，PolarDB、OceanBase 等国产开源数据库都已经接入了KubeBlocks。数据库引擎接入KB的方法有公开的文档可供参考。

除了国产开源数据库通过接入KB等平台发起冲击，蚕食Oracle市场份额的还有云厂商及数据库厂商自身提供的云数据库服务（如RDS），以及兼容Oracle语法的产品（如IvorySQL）。当然，也少不了专业的、面向大规模实例的管理工具。

此外，在之前的讨论中提到了一些支撑数据：运营商、金融等行业已经率先大规模推进微服务化。这类大客户的数据库实例数动辄上万，如果全部使用Oracle来支撑微服务化，成本将是一个天文数字。因此，这些头部企业纷纷转向了开源或基于开源的国产化数据库方案。

等着看吧，这次Oracle可能真的遇到大麻烦了！

技术演进的路线上充满了意想不到的交叉与碰撞。有时，最大的挑战并非来自直接的竞争对手，而是来自整个生态范式的转移。对数据库技术趋势的讨论，欢迎来 云栈社区 交流分享你的见解。