---
title: Docker Registry Mirror 的全球网络假设
date: '2019-04-28 11:52:46'
draft: false
summary: 这不只是一个小功能缺失，更说明很多基础设施默认的网络前提和真实环境之间仍然存在明显落差。
slug: docker-third-party-registry-mirror
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/HrHsDFiWt
tags:
- docker
- registry
- mirror
- developer-experience
topics:
- software-engineering
type: post
---

有个 `Docker` 的 issue 我从 `2015` 年就开始关注，就是希望它支持第三方 `registry mirror`。

这里说的并不是“私有镜像仓库”，而是第三方镜像源。`Docker / Moby` 早期的 mirror 机制主要只支持官方 registry，不支持外部第三方 registry 走同样的镜像加速路径。

在一个默认全球网络畅通的环境里，这看起来可能只是个边角功能，甚至会被理解成“先把主链路做好，别把问题复杂化”。

但在国内环境里，这就不是边角问题了。

因为拉各种 `docker registry` 经常会遇到网络摩擦。如果不能通过 mirror 机制透明地解决，用户就只能去改镜像地址、改配置、换仓库前缀，甚至针对不同工具链做不同适配。整件事会变得非常别扭。

所以这个问题真正暴露的，其实不是某个小功能一直没做出来，而是很多基础设施软件默认假设了一个统一、稳定、低摩擦的全球网络。

只要这个假设成立，产品设计就会自然倾向于：

- 官方入口优先
- 第三方镜像源能力弱化
- 网络问题被视为外围问题

可一旦网络现实和这个假设不一致，原本被当成外围的能力，就会立刻变成核心能力。

这也是为什么这个 issue 会反复讨论、反复有人提 `PR`、又反复停住。它背后其实不是实现难度那么简单，而是产品团队未必真的把这类环境当成默认场景。

我一直觉得，很多基础设施工具在全球不同区域的真正体验差距，不在架构层，而在这些看起来“不够优雅”的适配能力上。

因为一旦基础分发链路不顺，再漂亮的上层抽象都会被现实网络条件拖回原形。

<!-- WEIBO_MEDIA_START -->
## 原微博中的媒体

![](./weibo-4366019239844265-1.jpg)

![](./weibo-4366019239844265-2.jpg)
<!-- WEIBO_MEDIA_END -->
