企业在概念验证转生产时常遇运维挑战。汽车公司通过IDP解决，强调数据库架构关键性。选择YugabyteDB，因其PostgreSQL兼容性、地理分布与声明式管理，简化运维，加速上市。IDP成功依赖强大基础设施。
译自：How Distributed Databases Power Developer Platforms at Scale
作者：Gaurav Saxena
从概念验证到生产级系统的路径，揭示了企业软件中一个熟悉的模式。团队冲刺式地追求产品与市场的契合，然后花费数年时间应对他们最初未曾设计的操作问题。
在汽车行业中，数据平台决策会影响数百万日常用户，应对这一挑战变得更加重要，使有效的数据管理成为关键任务。
作为一家主要汽车公司的平台工程总监，我亲身经历了这一现实。我致力于一个内部开发者平台（IDP）解决方案，该方案在速度和企业弹性之间取得了平衡。在开发过程中我们了解到，选择正确的分布式数据库架构对于我们平台的成功同样至关重要。
挑战
产品通常始于追求市场契合度，很少关注规模、弹性或质量。我们快速构建、迭代并最终找到市场契合点，但在不知不觉中，我们的概念验证已投入生产。
我亲身经历了这些后果：孤立的团队、零散的工具，以及工程师将更多时间花在管理基础设施而非交付业务价值上。我们都参加过有数百人参与的事故响应电话会议，会议通常以“过去20分钟内有人合并代码了吗？”开头。
这种操作性苦差事从根本上改变了我们分配工程资源的方式，将人才从创新拉向被动维护。解决这个问题需要我们重新思考平台架构和数据层。
构建 IDP 基础
我们没有强制实施僵化的标准，而是构建了一个集中式平台，将可靠性、安全性和治理直接嵌入到开发人员工作流程中。我们的架构包含了四个关键要素：
- 标准化的 SDLC 和 CI/CD 通过自动化反馈循环简化了交付管道，减少了跨团队的人工干预。
- 通过基础设施即代码原则实现的声明式基础设施，为开发人员提供了复杂配置操作的简单接口。
- 集中式可观测性统一了指标和日志，通过消除关联来自不同系统数据的需要，显著缩短了平均恢复时间。
- 内置安全和灾难恢复、自动化合规性检查和弹性模式，在确保企业级保护的同时，消除了重复性任务。
内部开发者平台的力量来自于抽象层，特别是开放应用模型（OAM）。这个框架使开发人员能够根据应用程序的特性（包括服务、配置和存储需求）来定义应用程序。这比运行时细节更有意义。
我们首先要问：真正定义一个应用程序的是什么？它不仅仅是运行时，无论是 Kubernetes 部署还是 Docker 容器。应用程序还需要服务对象、ConfigMaps、PersistentVolumeClaims 等。
通过将这些组件组织为可重用特性，OAM 使我们的云基础设施团队能够独立发展平台，同时应用程序团队保持稳定的 API。关键是，我们需要这种架构模式扩展到数据层。
为什么数据库架构至关重要
对于服务数百万用户的汽车应用程序来说，数据库选择具有战略意义。错误的选择会造成操作瓶颈，限制部署灵活性，并引入单点故障，从而损害我们整个平台的弹性。
我们有一些标准数据库方法无法满足的特定要求：
- 数据主权要求数据必须保留在特定地理区域以符合法规，这排除了集中式数据库服务。
- 地理分布对于我们的汽车平台来说是不可协商的，因为用户遍布各大洲，延迟直接影响用户体验。
- 与我们的云原生架构的操作一致性要求数据库与 Kubernetes 原生模式保持一致，而不是与之对抗。
- PostgreSQL 兼容性使我们的团队能够使用现有技能和工具，无需再培训或进行全面应用程序重写。
评估分布式 SQL 数据库选项
在选择 YugabyteDB 之前，我们评估了 PostgreSQL、Google Spanner 和 CockroachDB。每个选项都提供了不同的权衡。
- 标准 PostgreSQL 提供了熟悉度，但缺乏内置的地理分布功能，并且需要复杂的外部复制管理。
- Google Spanner 提供了地理分布，但将我们锁定在 Google Cloud 中，并要求我们采用新的 SQL 方言。
- CockroachDB 提供了分布式功能，但存在兼容性差距，需要修改应用程序。
鉴于我们数据的性质，以及与部署拓扑和内置复制相关的各种因素，我们主要选择 YugabyteDB 是为了数据主权。
YugabyteDB 的架构与我们的 IDP 愿景完美契合，提供了：
- 原生 PostgreSQL 兼容性
- 跨多个云的灵活部署拓扑
- 无需外部协调的内置数据复制
关键是，YugabyteDB 可以通过我们用于其他基础设施的相同 Crossplane 操作符进行声明式管理。
将分布式 SQL 与开放应用模型集成
我们设计了数据库集成，通过一个三层架构遵循 OAM 模式，将数据库基础设施视为声明式平台资源：
控制平面 API
控制平面 API 集中管理资源，处理数据库实例配置、服务账户创建和 API 密钥管理。此层通过与开发人员用于计算和存储资源相同的声明式接口暴露数据库功能。
数据平面 API
数据平面 API 管理 YugabyteDB 集群的操作生命周期，协调扩展、备份和恢复操作。它允许我们配置灾难恢复策略、复制拓扑和备份计划，这些都无需开发人员干预即可自动应用。
声明式 YugabyteDB 资源
声明式 YugabyteDB 资源通过 Crossplane 操作符进行管理，将数据库配置、角色管理和安全控制抽象为可重用组件。开发人员可以指定数据库要求（大小、复制因子、地理分布等），平台会配置适当的集群。
这个过程将 YugabyteDB 转换为开发人员无需数据库专业知识即可使用的平台原语。当开发人员声明他们需要一个在三个区域具有只读副本的地理复制数据库时，他们只需定义这些要求，平台就会处理实现细节。
结果
我们的架构投资在开发人员生产力和数据库操作方面都带来了可衡量的成果：
- 操作简化来自于消除了手动数据库配置和设置。以前需要数天才能设置 PostgreSQL 复制的团队，现在只需几分钟就能获得生产就绪的分布式数据库。
- 内置弹性意味着灾难恢复和故障转移成为平台功能，而不是每个应用程序的关注点。当区域故障发生时，无需开发人员参与即可自动进行故障转移。
- 实时分析能力由于 YugabyteDB 的分布式架构而得到改善。我们可以独立扩展读取容量，在不降低性能的情况下支持事务性工作负载和分析查询。
- 上市时间加速得益于消除了数据库管理摩擦。发布新服务的团队不再受数据库配置的阻碍，也不必花费大量时间实现复制逻辑。
平台工程的经验教训
我们在这个项目中的经验教会我们一个重要的教训：内部开发者平台的成功或失败取决于其最薄弱的基础设施组件。一个拥有糟糕数据库架构的复杂 IDP 会造成瓶颈，从而损害整个平台的价值主张。
关键是选择与您的平台模型相符的技术。对于基于声明式基础设施和抽象层构建的云原生平台，数据库必须作为可管理的平台资源集成，而不是作为需要专业知识的外部依赖项。
我们的目标很简单：为开发人员提供他们所需的工具，以便快速交付一致、可靠和安全的解决方案。当开发人员成功时，业务自然也会随之发展。
对于正在构建平台工程能力的企业，我的建议也很简单：对平台抽象及其管理的基础设施进行同等投资。
数据库层不仅仅是存储；它是一个基础平台基础设施，决定了应用程序层可能实现的功能。明智地选择，周全地抽象，并从一开始就将未来的架构决策直接嵌入到您的平台中，从而简化它们。
