?編譯 | 影子

策劃 | 云昭

云原生時代，選擇一家靠譜的云產品，成為了技術人在設計和部署架構時不得不面臨的難題。內存、容量、數據庫、流量計費等等都是大家常見的可選參數。

然而，官網上那些承諾的“高可用、彈性擴容、實時伸縮”的產品，果真靠譜嗎？

一份來自知名云服務商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)和美國之間的互聯網連接可能導致機密查找失?。?/p>

? 有些故障情況會導致無法訪問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客戶表示可以理解，“我確信這是一個艱難的過程，但這項艱巨的工作，是你為自己和客戶創造長期價值的地方?！?/p>

“堅持??！我很欣賞這種透明度，作為一名創業老手，我表示同情。雖然我最近對Fly感到失望了一兩次，但我仍然是一個付費客戶，并且相信你們都會成功。”

有的甚至覺得有的缺點也是優點：“如volume與主機綁定，而不是像EBS那樣浮動，是一個優點。EBS速度慢且昂貴。當我想運行數據庫時，我希望選擇機器上的volume。因為我不需要在機器之間移動磁盤映像，而是對volume或數據庫進行可靠的備份。”

其實文中很多的問題，或多或少都會在其他的云產品中出現，通過“自我檢討”的公布，讓大家知道所使用的產品有哪些軟肋，以及為之正在采取的措施，Fly.io正在迎來前所未有的信任度和好感。

畢竟，“透明度”是獲取信任最好的途徑！

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