?編譯 | 影子

策劃 | 云昭

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

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

一份來自知名云服務(wù)商Fly.io公司Leader的“檢討書”，或許能給大家?guī)泶鸢浮?/p>

美國初創(chuàng)公司Fly.io，是一個應(yīng)用服務(wù)器提供商，而且即便不考慮其免費套餐，定價也極為親民，不用擔(dān)心免費額度用超了以后的價格問題。尤其在容器部署部署方面，頗受開發(fā)者追捧：它部署起來極為方便，性價比很高。因而，近幾年發(fā)展極為快速，但發(fā)展快并不總是件好事。

最近，一篇“自我檢討”式的博客：《可靠性：不太好》在了Fly.io的社區(qū)中大火，并快速占據(jù)頭條位置。網(wǎng)友驚呼：感謝你的誠實！

以下是原文：

過去的四個月很難熬。我們遇到的問題比我們能接受的還要多。

我一直猶豫著要不要分享這個，因為，我正在和一種令人頹喪的失敗感作斗爭。如果我們不改進，我們的公司就不復(fù)存在，我真的很喜歡在這家公司工作。

我們面臨的一個有趣的問題是：我們的受歡迎程度激增。這聽起來多好的事兒！但是我們已經(jīng)超越了平臺最初的設(shè)計初衷。我們投入了大量的工作和資源來發(fā)展平臺，完善我們的工程組織。但這個動作還是太遲了！

然而，這對用戶而言，他們并不在乎云產(chǎn)品的受歡迎程度。實際上，用戶只是想自信地發(fā)布自己的應(yīng)用程序。

這也是我們產(chǎn)品想要的。但，這真是一種苦力，我們并沒有像應(yīng)該的那樣努力奮斗。大家都是開發(fā)人員，我應(yīng)該把其中“骯臟的細(xì)節(jié)”透露一些。

1、細(xì)節(jié)曝光

小編提醒：Fly.io是一個應(yīng)用服務(wù)器提供商，提供了一個應(yīng)用交付網(wǎng)絡(luò) (ADN)，旨在幫助網(wǎng)站所有者輕松與客戶建立聯(lián)系。該公司的應(yīng)用程序交付網(wǎng)絡(luò)，使用全球服務(wù)器網(wǎng)絡(luò)來接受訪客流量，根據(jù)請求運行中間件，然后將它們路由到后端應(yīng)用程序，使網(wǎng)站所有者能夠引導(dǎo)訪客只需點擊幾下即可安全地訪問。  

我們的平臺，說白了就是一堆移動的“部件”，所有這些部件都需要協(xié)同工作，這樣你就可以部署應(yīng)用程序，再次部署它，然后走開，24個月后再回來，發(fā)現(xiàn)它仍然在工作。以下是實現(xiàn)這一目標(biāo)的原因：

? 一個集中的API，對數(shù)據(jù)庫進行授權(quán)和CRUD；

? WireGuard網(wǎng)關(guān)，用于連接到組織的專用網(wǎng)絡(luò)；

? 遠(yuǎn)程Docker builder虛擬機flyctl，用于將應(yīng)用程序構(gòu)建到Docker鏡像中；

? 保存這些Docker鏡像的全局Docker鏡像注冊表；

? 一個機密存儲Vault；

? 一個在VM中啟動Docker映像的調(diào)度器（現(xiàn)在大多都是Nomad）；

? 服務(wù)發(fā)現(xiàn)傳播我們基礎(chǔ)架構(gòu)中運行的所有虛擬機的相關(guān)信息；

? 將流量路由到應(yīng)用程序?qū)嵗拇恚?/p>

? 將應(yīng)用程序相互連接的網(wǎng)絡(luò)基礎(chǔ)設(shè)施。

可是以上這些都做得很失敗，簡直讓人驚掉下巴。我們當(dāng)然慶幸用戶沒有發(fā)現(xiàn)并注意到。以下是過去4個月發(fā)生的一些重大事故，排名不分先后：

（1）服務(wù)發(fā)現(xiàn)和Corrosion

（2）集中式機密存儲

（3）Postgres

（4）容量問題

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

（6）狀態(tài)分頁

2、服務(wù)發(fā)現(xiàn)和Corrosion

接口過期、內(nèi)部DDos

我們在所有地區(qū)傳播應(yīng)用實例和健康信息。這樣，代理就知道將請求路由到哪里，DNS服務(wù)器就知道該返回什么名稱。

我們開始用HashiCorp Consul做這個操作。但是我們把Consul硬塞給了一個不適合它的全球服務(wù)發(fā)現(xiàn)角色，Consul有一個為單個數(shù)據(jù)中心部署設(shè)計的集中式服務(wù)器模型。其結(jié)果是：持續(xù)陳舊的數(shù)據(jù)、路由到已過期接口的代理，以及經(jīng)常有陳舊條款的專有DNS。

所有這一切都是我們通過中央服務(wù)器集群(通常是跨洲的)往返執(zhí)行每個狀態(tài)更新(每個虛擬機的啟動和停止)的結(jié)果。

為此，我們發(fā)布了一個名為Corrosion（腐蝕）的項目。Corrosion是一個基于gossip的服務(wù)發(fā)現(xiàn)系統(tǒng)。當(dāng)虛擬機啟動時，該主機會透露實例信息。Corrosion的目標(biāo)是在不到一秒的時間內(nèi)在全球范圍內(nèi)傳播變化(并盡可能接近即時)。

可是，基于gossip的一致性問題卻成了一個挑戰(zhàn)。我們很快關(guān)閉了Corrosion項目，因為Consul給用戶帶來了相當(dāng)大的困擾。這款新軟件引發(fā)了兩次問題。兩者都表現(xiàn)為損壞的全局服務(wù)發(fā)現(xiàn)狀態(tài)。

第一次發(fā)生在我們的一個進程向Corrosion發(fā)送垃圾郵件并進行更新，基本上把它變成了一個內(nèi)部DDoS。第二次發(fā)生在一次例行更新中，竟然搞亂了數(shù)據(jù)庫。

這兩個問題造成的結(jié)果就是，部署期間應(yīng)用程序遭到破壞。隨著虛擬機來來去去，我們的代理服務(wù)器和DNS服務(wù)器會發(fā)現(xiàn)自己無法處理過時的數(shù)據(jù)。

Corrosion需要對“失效”有足夠的彈性。我們正在做一些漸進措施來改善它(例如，速率限制，減輕“內(nèi)部DDoS”風(fēng)險)。同時，我們也在致力于架構(gòu)的改變。gossip模式很棘手，因為不容易追蹤到具體的問題節(jié)點，而且傳播很快，這正是你不希望出現(xiàn)的。

去除Nomad，也將有助于緩解Corrosion問題。因為Nomad為每次部署創(chuàng)建全新的實例，所以會有大量的服務(wù)發(fā)現(xiàn)變動；每秒鐘有大量的事件更新。還好，F(xiàn)ly 的基于機器的應(yīng)用程序沒有那么瘋狂——當(dāng)我們更新運行在機器上的應(yīng)用程序時，我們會在適當(dāng)?shù)奈恢眠M行更新。

最后，問題不止于服務(wù)發(fā)現(xiàn)，我們在一周內(nèi)對我們的平臺部署了很多更改。有時，改動會與用戶發(fā)生沖突；不合時宜的應(yīng)用部署，可能會使應(yīng)用處于不穩(wěn)定狀態(tài)。我們正在更新工具，以便在這些時候暫停應(yīng)用部署。當(dāng)沖突發(fā)生時，我們將盡可能清楚地說明原因。

3、集中式機密存儲

查找失敗、無法訪問

我們在HashiCorp Vault中存儲應(yīng)用程序機密。HashiCorp Vault的工作方式與Consul非常相似，具有中央服務(wù)器集群。

我們在Vault方面遇到的問題，幾乎與Consul方面遇到的問題同樣嚴(yán)重。每次新VM啟動時，運行它的工作人員都必須從Vault中獲取機密。這有兩個基本問題：

? Vault在美國，遙遠(yuǎn)地區(qū)(如MAA)和美國之間的互聯(lián)網(wǎng)連接可能導(dǎo)致機密查找失敗；

? 有些故障情況會導(dǎo)致無法訪問Vault。例如，我們的一個Vault服務(wù)器出現(xiàn)故障，導(dǎo)致大范圍的虛擬機創(chuàng)建失敗。

與服務(wù)發(fā)現(xiàn)一樣，Nomad加劇了這些問題，F(xiàn)ly Machines緩解了這些問題。但如果Vault處于不良狀態(tài)，新的Fly Machine創(chuàng)建也將失敗。

現(xiàn)有的開源不是為全球部署而設(shè)計的。因此，當(dāng)我們選擇“購買”現(xiàn)有的基礎(chǔ)設(shè)施軟件時，我們通常會在一定程度上為全球范圍的韌性付出代價。

4、Postgres集群

我們做了個糟糕的“非托管”決定

我們的Postgres集群有兩個主要問題：我們對Stolon和Consul集群的實時連接的依賴以及我們對“非托管Postgres”的錯誤預(yù)期。

第一個是架構(gòu)問題。Postgres所依賴的Consul集群與我們用于服務(wù)發(fā)現(xiàn)的集群不同，但它們?nèi)匀粫云婀值姆绞健笆　薄tolon是我們在Fly Postgres的第一次迭代中構(gòu)建的Postgres集群軟件，它不能很好地處理Consul連接問題。

新的Postgres集群不使用Stolon，而是使用repmgr。epmgr處理集群內(nèi)的領(lǐng)導(dǎo)者選舉，不需要第二個數(shù)據(jù)庫。這些新的Postgres集群仍然使用Consul來共享配置信息，但是如果Consul崩潰，集群會繼續(xù)運行。

我們正在努力將以前配置的Postgres DB升級到新的repmgr設(shè)置。有一些復(fù)雜的問題，但我們會繼續(xù)發(fā)布。

Postgres的第二個問題是做出了一個很糟糕的決定。我們決定推出“非托管Postgres”，這樣可以為我們爭取時間，以等待合適的托管Postgres提供程序出現(xiàn)。問題是，“fly-pg create”意味著人們正在獲得一個托管的Postgres集群。這是因為每一個具有“獲取一個簡單的Postgres”功能的服務(wù)程序都會為用戶提供一個托管堆棧。

這對于我們來說是一個非常沉痛的教訓(xùn)。我們最終展示了很多有關(guān)用戶體驗的承諾，但卻沒有堅持到貫徹。我們不是那種會寫價值觀口號的公司，如果是，我們會加上一句“不要違背開發(fā)者的期望來制造令人討厭的偽驚喜”。

要解決托管Postgre，我們需要一段時間才能實現(xiàn)，但它是基礎(chǔ)架構(gòu)堆棧的核心組件，我們不能假裝不需要這樣。

5、容量問題：想當(dāng)然了

新用戶的涌入使我們在多個地區(qū)耗盡了服務(wù)器容量，有時不止一次。這是兩個層面上的失敗——其一，我們沒有足夠快地響應(yīng)，去購買服務(wù)器。其二，我們沒有好的工具來減輕特定地區(qū)的壓力。

去年，我們想當(dāng)然了，以為就算我們遇到容量問題，我們也可以做到防止新的用戶在特定區(qū)域啟動。然而，打臉了。

Heroku是一個支持多種編程語言的平臺，它打破了我們的“想當(dāng)然”。在Heroku之前，我們運行的大多數(shù)應(yīng)用程序都是跨地區(qū)的。而且：我們每個月增長15%左右。但是后Heroku時代，我們只在幾個熱點地區(qū)有大量的應(yīng)用程序涌入——每月30%。

事后看來，我應(yīng)該更早就開始，在我們還有融資的時候。

我們在容量規(guī)劃和物流方面做得越來越好。我把容量規(guī)劃列入我的工作清單。公司需要比我能力更強的人才。我們重新招聘，調(diào)整了組織架構(gòu)；現(xiàn)在情況有所好轉(zhuǎn)，而且會迅速好轉(zhuǎn)。

6、volume被限制到主機硬件

內(nèi)存不夠就宕機

fly-volumes命令在特定主機硬件上創(chuàng)建塊設(shè)備。當(dāng)我們第一次發(fā)布它時，我們有很多內(nèi)容解釋了這種方法的局限性。我們設(shè)計了volume，使其以2+為單位運行。

這意味著，如果你所在的主機容量宕掉，你的應(yīng)用程序就會宕機。如果主機沒有足夠的內(nèi)存或CPU來運行應(yīng)用程序VM，您可能無法部署。

然而，這些細(xì)節(jié)隨著我們的文檔的改進而丟失，這導(dǎo)致了一些令人討厭的意外。這也是違反直覺的。人們習(xí)慣了AWS EBS的魔力。但我們的volume不是EBS。

這是用戶體驗制造錯誤期望的另一個例子。

7、狀態(tài)分頁：吹噓自家產(chǎn)品，解答模糊

在我們狀態(tài)頁面上有一些含糊不清的發(fā)帖，受到了很多合理的批評。與此同時，我們在博客上無恥地吹噓我們的技術(shù)。問題時有發(fā)生，當(dāng)問題發(fā)生時，我們沒有積極地溝通。

工作的原因令我們迷失而忘掉了初心。從“計算機技術(shù)”的角度看，我在這里寫的一些挑戰(zhàn)是困難的。但這個問題不是。這是不可原諒的，我們需要做到立即溝通。

我們招聘了一位非常優(yōu)秀的人來構(gòu)建我們的基礎(chǔ)架構(gòu)/運維團隊。除了強化該團隊使其不再模棱兩可的發(fā)帖之外，還標(biāo)準(zhǔn)化了事件響應(yīng)。當(dāng)開發(fā)者遇到問題時，我們希望盡可能縮短處理鏈路，這樣就能更快地獲得信息。

我們還推出了個性化的狀態(tài)頁面。隨著規(guī)模的增長，我們服務(wù)器的數(shù)量也越來越多，遇到硬件故障的可能性也隨之增加。這使得我們很難保持一個完全透明的狀態(tài)頁面。個性化狀態(tài)頁面將使我們能夠更輕松地告訴受硬件故障影響的特定客戶“嘿，該地區(qū)有一個驅(qū)動器壞了，我們正在解決”。

8、寫在最后

對于這份自我檢討，許多Fly.io客戶表示可以理解，“我確信這是一個艱難的過程，但這項艱巨的工作，是你為自己和客戶創(chuàng)造長期價值的地方。”

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

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

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

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

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