自从 Google Spanner[1] 在很多年前(OSDI 2012)提出和使用了 True Time 高精度时钟及其 API 以来，不少公司都在跟进。虽然 Google 高精度的最初精度是 10 毫秒级，但是从其论文等宣传看已经演进到了微秒级，甚至亚微秒级。十多年以来，国外的 AWS、Meta、Azure 都提供了类似的基础设施，甚至对外提供了服务。例如 AWS 2017 年发布了 Time Sync 服务[2]，可以取代 NTP，虽然只能在 EC2 上使用。 2023 年，它可以在公网也就是 AWS 之外的设备上使用了，提供的域名为 time.aws.com[3]，并且支持了微秒级的精度。此外，其新推出的 AWS Aurora Limitless 数据库也用上了时钟服务。Meta 在开源开放上做得比较出色，开放了一个开源的实现[4]，也在文章[5]中详细说明了其高精度时钟的软硬件设计方案。Microsoft Azure 的虚拟机也可以用它们自建的 GPS 时钟源[6]。

无论是软件还是硬件，从公开资料看，在高精度时钟领域国内厂商都应该是可以比较经济的实现的。原子钟可以是 GPS 或北斗。之所以还没有看到它们推出类似的服务，推测厂商还是不愿意提前在基础设施上做投入，尤其是这种短期看起来没法变现的基础设施。从实现角度看，高精度时钟服务需要对已有机房做一些物理改造，包括安装原子钟、网络设备、布线等，软件也得做配套的修改和变更发布。估计这些成本还需要设法在内部各个部门和服务之间分摊。从应用的角度看，最需要高精度时钟的其实是 NTP 以及间接采用时间的常规服务 - 例如打印日志、应用程序中的取时等等。它们的应用范围广，而且对时钟的可靠性以及精度要求都可以稍微放松一点。更高级的应用是类似 Spanner 的全球分布式数据库服务，但是它对时钟的可靠性和精度要求都比较严格，尤其是不能容忍时钟出问题了数据库还不能及时知道 - 事务乱套了错误往往会放大比传递到下游应用。至于到底有多少应用需要 Spanner 或类似的系统，还是说用 CockroachDB、TiDB、OceanBase 就够了呢？这就是另外一个话题了。

除了物理网络不能自建外，难道时钟又要成了国内云计算☁️的另一个软肋？

[1] Spanner: Google’s Globally-Distributed Database

[2] Introducing the Amazon Time Sync Service

[3] Amazon Time Sync Service now supports microsecond-accurate time

[4] Open-sourcing a more precise time appliance

[5] How Precision Time Protocol is being deployed at Meta

[6] Time sync for Windows VMs in Azure