数字主权（Digital Sovereignty）并非意味着要事事亲力亲为，而是要手握一套可行的备选方案（Plan B）。倘若你的核心系统供应商突然大幅涨价、宣布停止产品迭代，并给出产品生命周期终止的最后期限，你的备选方案会是什么？如果一国的基础数字化运转完全依赖于另一地缘政治实体，后果可想而知？如果你的 SaaS 服务权限因国际制裁被突然封禁，又该如何应对？
在本文中，我将深入剖析数字主权的三大维度，并阐释如何通过架构选型与约束条件应对前述各类风险场景。我会分析构建“主权系统”的收益与潜在风险，并结合示例说明这类架构的落地难度往往超出多数人的预期。作为服务过众多大型企业的软件架构师，我将分享以开放标准作为实现数字主权核心支柱之一的实践见解。同时需要说明的是，数字主权本身是一个更为宏大的议题。
数字主权
数字主权是当下的热门话题。这一话题既适用于政府层面，例如欧盟已出台云主权框架等相关指导规范；也适用于那些过度依赖、易被供应商滥用定价权的私营企业。
在软件企业领域，数字主权通常可划分为四个维度：数据主权、技术主权、运营主权以及通用 IT 治理与战略。其中，技术与运营层面的主权一般定义为独立使用、开发和运维数字化解决方案的能力。简言之，核心在于掌握对解决方案的控制权。
治理层面则是明确如何建立管控机制，确保各项主权举措落地执行。本文将重点围绕技术、运营与治理展开论述，因为数据主权通常涉及大量法律相关事宜。
首先，绝对的数字主权是一种空想。在全球化经济体系中，没有任何国家能够完全独立地完成软件的开发与运营。即便身处软件产业前沿的国家（例如美国）拥有显著优势，仍需依赖其他国家提供原材料及部分硬件组件，才能保障复杂软件系统正常运转。对于单一企业而言，想要实现完全自主更是不切实际的。
由于绝对主权无法实现，企业应审慎甄别对业务真正关键的系统，并将主权建设聚焦于这类核心系统与流程。此外，实现主权并不意味着企业凡事都需自主搭建、亲力亲为。
这种误区会让企业误以为必须自建数据中心、自研所有软件。这在现实中不仅难以实现，还会推高运营成本，同时将依赖转嫁至技术栈的更底层。试想，企业难道还要自研硬件、自建发电设施来运维数据中心吗？数字主权的核心在于避免过度依赖单一供应商或单一地缘政治实体。因此，企业即便依赖外部服务商，只要能够以合理成本无缝迁移至同等替代方案，便不存在主权风险。
图 1：依赖栈总是有一个更深的隐藏层
但这种主权真的有必要吗？现有依赖关系在实际场景中引发风险的概率究竟多大？我们来看一个真实案例。我曾为一家规模较大的政府机构搭建容器平台，该平台为各类政府实体提供云服务。在这类场景下，地缘政治层面的主权固然重要，接下来我们重点探讨更为隐性的供应商独立性问题。
政府机构需遵循标准化流程进行大额合同招标并公示（符合世界贸易组织规则），以防范倾向性签约与腐败风险。这类合同设有固定周期，需要定期续签，而每次续签的中标供应商都可能发生变动。因此，过度依赖单一供应商或产品可能带来致命风险，因为原有供应商未必能续签下一轮合同。该案例虽聚焦政府机构，私营企业的情况也大致相似：受法规约束或整体 IT 战略调整影响，企业采购部门通常会要求轮换合作供应商。
此外，过往数年的实践表明，具备强客户锁定能力的厂商可能会大幅调整定价策略。这迫使大量企业仓促迁移、脱离原有服务商，以规避长期高昂成本。这类财务风险同样是组织缺乏数字主权所带来的隐患。
总而言之，数字主权是一个涉及地缘政治、法规合规与财务成本的复杂议题。尽管完全独立并不现实，但上述案例表明，企业必须审慎评估在哪些场景下重度依赖供应商属于可承受的风险。
开放标准
假设你已识别出支撑企业核心业务流程的关键系统，那么投入适量成本与精力提升其可移植性，增强独立性与数字主权，便具备实际的价值。一套成熟可行的迁移方案是系统高效迁移的关键，而系统自身的架构在很大程度上决定了迁移的复杂度与耗时程度。基于开放标准构建业务流程与软件系统是降低迁移成本、保障迁移路径顺畅的可靠方式。
开放标准是一套面向公众免费开放、可供任何人使用的正式规范、约束与准则。这类标准通常具备较高成熟度，并被多家厂商采纳实现，从而让相关产品具备一定的可替代性。常见的开放标准示例包括：
TCP、IP 以及我们熟悉的大多数标准网络协议。
TLS、ACME 及其他安全协议。
SVG、PDF 及其他文档格式。并非所有文档格式都是开放标准的。例如，PDF 在很长一段时间内是专有的，后来才被 Adobe 作为开放标准发布。
硬件设备通信标准 USB 和 PCI。
这些标准大多是协议或数据格式。此外，部分大型开源项目也会演变为事实层面的开放标准。随着众多厂商基于这类项目进行二次开发，其应用普及率迅速提升，使得底层技术在各厂商之间趋于统一。一旦普及范围足够广泛，这些技术便会成为各家厂商共同遵循的事实标准。例如：
PostgreSQL 作为数据库引擎（AWS Aurora、GCP Alloy DB、Azure DB for PSQL，甚至其他开源软件如 CockroachDB）
Kubernetes 作为容器编排引擎和可扩展 API（AWS EKS、GCP GKE、Azure AKS、OpenShift 以及数百家其他供应商）
Kafka 作为事件流平台（AWS MSK、GCP Managed Service for Kafka、Azure Event Hub、Strimzi、Confluent 等）
Prometheus
OpenTelemetry
OpenSearch
Apache Spark
开放标准的形成也常见于开源社区。近年来，不少原本由企业维护的相关标准因厂商修改开源许可条款、试图收回用户使用权而遭遇变局。其中最典型的案例，包括 HashiCorp 对 Terraform、Vault，以及 Redis 的许可证调整。这类变动一度危及原有事实标准的存续，社区随即快速响应，催生了 OpenTofu、OpenBao 与 Valkey 等衍生项目，以此保障相关开放标准能够持续可用。
这些厂商与开源社区之间的许可协议之争充分体现了开放标准的强大价值。若采用脱离通用标准的专有产品，企业将处于被动地位：你只是厂商海量客户中的一员，而该厂商又是其专有产品的唯一提供者，导致你的使用需求缺乏弹性。反之，基于开放标准构建系统，你便不再单独受制于单一厂商。开放生态能够抵御厂商单方面更改规则带来的风险，迫使厂商忌惮客户迁移至遵循同一标准的替代方案。由此，企业对特定产品的依赖被大幅削弱，需求也具备了充分的弹性。
市面上的开放标准已相当丰富，看似不难设计出具备可移植性的解决方案。但在实际落地中，其复杂度往往远超预期。这类难题主要源于容易被忽视的外部依赖，包括对其他系统以及厂商特有功能的依赖。
示例：Kubernetes
第一个例子，以容器平台为例，表面上看实现起来似乎十分简单：一切基于 Kubernetes——无疑是当下最具代表性的事实开放标准，市面上也拥有众多 Kubernetes 发行版厂商，同时还提供完善的标准化接口，便于上层系统开发。因此人们普遍认为，基于这套标准搭建业务便能轻松迁移至不同的服务商。尤其在云原生领域，各类配套系统大多会通过自定义资源与控制器封装出基于 Kubernetes API 的接口层。这意味着，即便是为 Kubernetes 提供支撑的辅助系统也能依托开放标准实现良好的抽象解耦。
然而，如果深入观察，这类抽象的实际复杂度会显著升高。在开发基于 Kubernetes 的系统时，团队是否只依赖原生能力还是同时用到了当前发行版的专属特性？这类依赖可能十分隐蔽，例如存储组件：你在集群中使用的存储方案是否绑定了特定的 Kubernetes 发行版？一旦绑定，便会形成彻底的数据锁定。若要迁移，就必须跨厂商迁移存储卷，而这一过程难度极高。同理，分发 OCI 镜像的镜像仓库、构建部署的 CI/CD 管道也是如此。该如何妥善处理这些无意间形成的外部依赖？
在运营层面，还需要考量体系的独立可控性：是否存在关键知识完全集中在单一外包团队的情况？对于内部员工，是否有人因掌握大量部落知识而成为系统运维不可或缺的核心？此外，自动化成熟度也会影响迁移决策。若资源管理完全依靠人工操作，而非采用 GitOps 等标准化方式，迁移至其他服务商不仅运维风险高，而且耗时漫长。
不难看出，在实际落地中，完全基于开放标准构建系统难度颇高。这类复杂问题大多源于便利性带来的路径依赖：若无企业架构层面设立规范约束，开发人员往往会优先选择最简单、最省事的实现方式。
应对厂商倒闭或战略转向风险
即便你暂时无法切换供应商，基于开放标准构建系统依然能够带来益处。在某些场景下，你可能基于某个开放标准搭建系统，但原有服务商已不再可用，且市场上暂无替代方案。HashiCorp Vault 的许可证变更便是典型案例。在这种情况下，由于底层遵循开放标准，企业可以自行维护项目分支并实现方案自托管。当然，这种方式需要审慎评估，因为它往往意味着高昂的投入，同时要求团队具备专门的技术积累。
不过在多数情况下，市场中往往会涌现出新的替代服务商。这些替代方既可能是社区本身（例如 OpenBao），也可能是看准商机入局的企业。无论属于哪一种，企业都无需自行维护分支，而是直接依赖外部成熟的专业知识。
残酷的事实
我希望以上内容能够清晰阐明我的观点：依托开放标准，考量核心软件系统的可移植性。尽管实现可移植性并非易事，但这是降低对外部主体依赖最有效的方式之一。不过，这种选择需要付出成本，且成本不仅体现在资金层面。
设计具备可移植性的系统能够降低迁移门槛，但也会无形中增加迁移的频次。虽然单次迁移变得更简单、成本更低，但仍需把控整体节奏，避免迁移负担持续累积、无限上升。
此外，若主权风险源于被厂商切断系统访问权限，企业不仅要保证具备迁移能力，还要确保迁移过程无需依赖原有厂商的系统。换言之，必须支持独立切换至替代系统。这一点在技术实现上难度较高，同时企业还需明确自身可接受的数据丢失范围。
最终，企业架构师负责制定规范约束，保障应用与子系统具备可移植性。他们需要引导应用架构师和开发人员按照便于迁移、简化应急运维的思路构建系统。同时，这些规范不能过度增加开发阻力，否则反而会催生各类规避手段，滋生影子 IT 风险。
假设企业配备成熟的架构团队，且部分系统需要具备一定程度的自主可控能力，我强烈建议制定一套系统化方法来持续保障系统的可移植性。明确的可移植性建设策略是提升厂商独立性的核心抓手。尽管实施难度较高，但这套结构化架构方案正是区分被动依赖外部资源的技术消费者与具备数字主权能力企业的关键所在。
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
查看英文原文：https://www.infoq.com/articles/portable-systems-sovereignty/
