?編譯 | 影子

策劃 | 云昭

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

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

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

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

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

以下是原文：

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

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

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

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

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

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

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

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

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

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

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

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

? 一個(gè)機(jī)密存儲(chǔ)Vault；

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

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

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

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

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

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

（2）集中式機(jī)密存儲(chǔ)

（3）Postgres

（4）容量問題

（5）固定到主機(jī)硬件的容量

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

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

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

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

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

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

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

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

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

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

Corrosion需要對“失效”有足夠的彈性。我們正在做一些漸進(jìn)措施來改善它(例如，速率限制，減輕“內(nèi)部DDoS”風(fēng)險(xiǎn))。同時(shí)，我們也在致力于架構(gòu)的改變。gossip模式很棘手，因?yàn)椴蝗菀鬃粉櫟骄唧w的問題節(jié)點(diǎn)，而且傳播很快，這正是你不希望出現(xiàn)的。

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

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

3、集中式機(jī)密存儲(chǔ)

查找失敗、無法訪問

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

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

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

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

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

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

4、Postgres集群

我們做了個(gè)糟糕的“非托管”決定

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

第一個(gè)是架構(gòu)問題。Postgres所依賴的Consul集群與我們用于服務(wù)發(fā)現(xiàn)的集群不同，但它們?nèi)匀粫?huì)以奇怪的方式“失敗”。Stolon是我們在Fly Postgres的第一次迭代中構(gòu)建的Postgres集群軟件，它不能很好地處理Consul連接問題。

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

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

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

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

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

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

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

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

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

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

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

6、volume被限制到主機(jī)硬件

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

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

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

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

這是用戶體驗(yàn)制造錯(cuò)誤期望的另一個(gè)例子。

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

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

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

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

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

8、寫在最后

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

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

有的甚至覺得有的缺點(diǎn)也是優(yōu)點(diǎn)：“如volume與主機(jī)綁定，而不是像EBS那樣浮動(dòng)，是一個(gè)優(yōu)點(diǎn)。EBS速度慢且昂貴。當(dāng)我想運(yùn)行數(shù)據(jù)庫時(shí)，我希望選擇機(jī)器上的volume。因?yàn)槲也恍枰跈C(jī)器之間移動(dòng)磁盤映像，而是對volume或數(shù)據(jù)庫進(jìn)行可靠的備份。”

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

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

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