​编译 | 影子

策划 | 云昭

云原生时代，选择一家靠谱的云产品，成为了技术人在设计和部署架构时不得不面临的难题。内存、容量、数据库、流量计费等等都是大家常见的可选参数。

然而，官网上那些承诺的“高可用、弹性扩容、实时伸缩”的产品，果真靠谱吗？

一份来自知名云服务商Fly.io公司Leader的“检讨书”，或许能给大家带来答案。

美国初创公司Fly.io，是一个应用服务器提供商，而且即便不考虑其免费套餐，定价也极为亲民，不用担心免费额度用超了以后的价格问题。尤其在容器部署部署方面，颇受开发者追捧：它部署起来极为方便，性价比很高。因而，近几年发展极为快速，但发展快并不总是件好事。

最近，一篇“自我检讨”式的博客：《可靠性：不太好》在了Fly.io的社区中大火，并快速占据头条位置。网友惊呼：感谢你的诚实！

以下是原文：

过去的四个月很难熬。我们遇到的问题比我们能接受的还要多。

我一直犹豫着要不要分享这个，因为，我正在和一种令人颓丧的失败感作斗争。如果我们不改进，我们的公司就不复存在，我真的很喜欢在这家公司工作。

我们面临的一个有趣的问题是：我们的受欢迎程度激增。这听起来多好的事儿！但是我们已经超越了平台最初的设计初衷。我们投入了大量的工作和资源来发展平台，完善我们的工程组织。但这个动作还是太迟了！

然而，这对用户而言，他们并不在乎云产品的受欢迎程度。实际上，用户只是想自信地发布自己的应用程序。

这也是我们产品想要的。但，这真是一种苦力，我们并没有像应该的那样努力奋斗。大家都是开发人员，我应该把其中“肮脏的细节”透露一些。

1、细节曝光

小编提醒：Fly.io是一个应用服务器提供商，提供了一个应用交付网络 (ADN)，旨在帮助网站所有者轻松与客户建立联系。该公司的应用程序交付网络，使用全球服务器网络来接受访客流量，根据请求运行中间件，然后将它们路由到后端应用程序，使网站所有者能够引导访客只需点击几下即可安全地访问。  

我们的平台，说白了就是一堆移动的“部件”，所有这些部件都需要协同工作，这样你就可以部署应用程序，再次部署它，然后走开，24个月后再回来，发现它仍然在工作。以下是实现这一目标的原因：

• 一个集中的API，对数据库进行授权和CRUD；

• WireGuard网关，用于连接到组织的专用网络；

• 远程Docker builder虚拟机flyctl，用于将应用程序构建到Docker镜像中；

• 保存这些Docker镜像的全局Docker镜像注册表；

• 一个机密存储Vault；

• 一个在VM中启动Docker映像的调度器（现在大多都是Nomad）；

• 服务发现传播我们基础架构中运行的所有虚拟机的相关信息；

• 将流量路由到应用程序实例的代理；

• 将应用程序相互连接的网络基础设施。

可是以上这些都做得很失败，简直让人惊掉下巴。我们当然庆幸用户没有发现并注意到。以下是过去4个月发生的一些重大事故，排名不分先后：

（1）服务发现和Corrosion

（2）集中式机密存储

（3）Postgres

（4）容量问题

（5）固定到主机硬件的容量

（6）状态分页

2、服务发现和Corrosion

接口过期、内部DDos

我们在所有地区传播应用实例和健康信息。这样，代理就知道将请求路由到哪里，DNS服务器就知道该返回什么名称。

我们开始用HashiCorp Consul做这个操作。但是我们把Consul硬塞给了一个不适合它的全球服务发现角色，Consul有一个为单个数据中心部署设计的集中式服务器模型。其结果是：持续陈旧的数据、路由到已过期接口的代理，以及经常有陈旧条款的专有DNS。

所有这一切都是我们通过中央服务器集群(通常是跨洲的)往返执行每个状态更新(每个虚拟机的启动和停止)的结果。

为此，我们发布了一个名为Corrosion（腐蚀）的项目。Corrosion是一个基于gossip的服务发现系统。当虚拟机启动时，该主机会透露实例信息。Corrosion的目标是在不到一秒的时间内在全球范围内传播变化(并尽可能接近即时)。

可是，基于gossip的一致性问题却成了一个挑战。我们很快关闭了Corrosion项目，因为Consul给用户带来了相当大的困扰。这款新软件引发了两次问题。两者都表现为损坏的全局服务发现状态。

第一次发生在我们的一个进程向Corrosion发送垃圾邮件并进行更新，基本上把它变成了一个内部DDoS。第二次发生在一次例行更新中，竟然搞乱了数据库。

这两个问题造成的结果就是，部署期间应用程序遭到破坏。随着虚拟机来来去去，我们的代理服务器和DNS服务器会发现自己无法处理过时的数据。

Corrosion需要对“失效”有足够的弹性。我们正在做一些渐进措施来改善它(例如，速率限制，减轻“内部DDoS”风险)。同时，我们也在致力于架构的改变。gossip模式很棘手，因为不容易追踪到具体的问题节点，而且传播很快，这正是你不希望出现的。

去除Nomad，也将有助于缓解Corrosion问题。因为Nomad为每次部署创建全新的实例，所以会有大量的服务发现变动；每秒钟有大量的事件更新。还好，Fly 的基于机器的应用程序没有那么疯狂——当我们更新运行在机器上的应用程序时，我们会在适当的位置进行更新。

最后，问题不止于服务发现，我们在一周内对我们的平台部署了很多更改。有时，改动会与用户发生冲突；不合时宜的应用部署，可能会使应用处于不稳定状态。我们正在更新工具，以便在这些时候暂停应用部署。当冲突发生时，我们将尽可能清楚地说明原因。

3、集中式机密存储

查找失败、无法访问

我们在HashiCorp Vault中存储应用程序机密。HashiCorp Vault的工作方式与Consul非常相似，具有中央服务器集群。

我们在Vault方面遇到的问题，几乎与Consul方面遇到的问题同样严重。每次新VM启动时，运行它的工作人员都必须从Vault中获取机密。这有两个基本问题：

• Vault在美国，遥远地区(如MAA)和美国之间的互联网连接可能导致机密查找失败；

• 有些故障情况会导致无法访问Vault。例如，我们的一个Vault服务器出现故障，导致大范围的虚拟机创建失败。

与服务发现一样，Nomad加剧了这些问题，Fly Machines缓解了这些问题。但如果Vault处于不良状态，新的Fly Machine创建也将失败。

现有的开源不是为全球部署而设计的。因此，当我们选择“购买”现有的基础设施软件时，我们通常会在一定程度上为全球范围的韧性付出代价。

4、Postgres集群

我们做了个糟糕的“非托管”决定

我们的Postgres集群有两个主要问题：我们对Stolon和Consul集群的实时连接的依赖以及我们对“非托管Postgres”的错误预期。

第一个是架构问题。Postgres所依赖的Consul集群与我们用于服务发现的集群不同，但它们仍然会以奇怪的方式“失败”。Stolon是我们在Fly Postgres的第一次迭代中构建的Postgres集群软件，它不能很好地处理Consul连接问题。

新的Postgres集群不使用Stolon，而是使用repmgr。epmgr处理集群内的领导者选举，不需要第二个数据库。这些新的Postgres集群仍然使用Consul来共享配置信息，但是如果Consul崩溃，集群会继续运行。

我们正在努力将以前配置的Postgres DB升级到新的repmgr设置。有一些复杂的问题，但我们会继续发布。

Postgres的第二个问题是做出了一个很糟糕的决定。我们决定推出“非托管Postgres”，这样可以为我们争取时间，以等待合适的托管Postgres提供程序出现。问题是，“fly-pg create”意味着人们正在获得一个托管的Postgres集群。这是因为每一个具有“获取一个简单的Postgres”功能的服务程序都会为用户提供一个托管堆栈。

这对于我们来说是一个非常沉痛的教训。我们最终展示了很多有关用户体验的承诺，但却没有坚持到贯彻。我们不是那种会写价值观口号的公司，如果是，我们会加上一句“不要违背开发者的期望来制造令人讨厌的伪惊喜”。

要解决托管Postgre，我们需要一段时间才能实现，但它是基础架构堆栈的核心组件，我们不能假装不需要这样。

5、容量问题：想当然了

新用户的涌入使我们在多个地区耗尽了服务器容量，有时不止一次。这是两个层面上的失败——其一，我们没有足够快地响应，去购买服务器。其二，我们没有好的工具来减轻特定地区的压力。

去年，我们想当然了，以为就算我们遇到容量问题，我们也可以做到防止新的用户在特定区域启动。然而，打脸了。

Heroku是一个支持多种编程语言的平台，它打破了我们的“想当然”。在Heroku之前，我们运行的大多数应用程序都是跨地区的。而且：我们每个月增长15%左右。但是后Heroku时代，我们只在几个热点地区有大量的应用程序涌入——每月30%。

事后看来，我应该更早就开始，在我们还有融资的时候。

我们在容量规划和物流方面做得越来越好。我把容量规划列入我的工作清单。公司需要比我能力更强的人才。我们重新招聘，调整了组织架构；现在情况有所好转，而且会迅速好转。

6、volume被限制到主机硬件

内存不够就宕机

fly-volumes命令在特定主机硬件上创建块设备。当我们第一次发布它时，我们有很多内容解释了这种方法的局限性。我们设计了volume，使其以2+为单位运行。

这意味着，如果你所在的主机容量宕掉，你的应用程序就会宕机。如果主机没有足够的内存或CPU来运行应用程序VM，您可能无法部署。

然而，这些细节随着我们的文档的改进而丢失，这导致了一些令人讨厌的意外。这也是违反直觉的。人们习惯了AWS EBS的魔力。但我们的volume不是EBS。

这是用户体验制造错误期望的另一个例子。

7、状态分页：吹嘘自家产品，解答模糊

在我们状态页面上有一些含糊不清的发帖，受到了很多合理的批评。与此同时，我们在博客上无耻地吹嘘我们的技术。问题时有发生，当问题发生时，我们没有积极地沟通。

工作的原因令我们迷失而忘掉了初心。从“计算机技术”的角度看，我在这里写的一些挑战是困难的。但这个问题不是。这是不可原谅的，我们需要做到立即沟通。

我们招聘了一位非常优秀的人来构建我们的基础架构/运维团队。除了强化该团队使其不再模棱两可的发帖之外，还标准化了事件响应。当开发者遇到问题时，我们希望尽可能缩短处理链路，这样就能更快地获得信息。

我们还推出了个性化的状态页面。随着规模的增长，我们服务器的数量也越来越多，遇到硬件故障的可能性也随之增加。这使得我们很难保持一个完全透明的状态页面。个性化状态页面将使我们能够更轻松地告诉受硬件故障影响的特定客户“嘿，该地区有一个驱动器坏了，我们正在解决”。

8、写在最后

对于这份自我检讨，许多Fly.io客户表示可以理解，“我确信这是一个艰难的过程，但这项艰巨的工作，是你为自己和客户创造长期价值的地方。”

“坚持住！我很欣赏这种透明度，作为一名创业老手，我表示同情。虽然我最近对Fly感到失望了一两次，但我仍然是一个付费客户，并且相信你们都会成功。”

有的甚至觉得有的缺点也是优点：“如volume与主机绑定，而不是像EBS那样浮动，是一个优点。EBS速度慢且昂贵。当我想运行数据库时，我希望选择机器上的volume。因为我不需要在机器之间移动磁盘映像，而是对volume或数据库进行可靠的备份。”

其实文中很多的问题，或多或少都会在其他的云产品中出现，通过“自我检讨”的公布，让大家知道所使用的产品有哪些软肋，以及为之正在采取的措施，Fly.io正在迎来前所未有的信任度和好感。

毕竟，“透明度”是获取信任最好的途径！

原文链接：https://community.fly.io/t/reliability-its-not-great/11253/2