新聞中心
一份云的公開檢討書走紅:我們不靠譜,網(wǎng)友:理解!
譯文 精選
作者:影子 2023-03-09 17:42:34
云計(jì)算
云原生 最近,一篇“自我檢討”式的博客:《可靠性:不太好》在了Fly.io的社區(qū)中大火,并快速占據(jù)頭條位置。網(wǎng)友驚呼:感謝你的誠(chéng)實(shí)!

專業(yè)領(lǐng)域包括網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、商城網(wǎng)站制作、微信營(yíng)銷、系統(tǒng)平臺(tái)開發(fā), 與其他網(wǎng)站設(shè)計(jì)及系統(tǒng)開發(fā)公司不同,成都創(chuàng)新互聯(lián)公司的整合解決方案結(jié)合了幫做網(wǎng)絡(luò)品牌建設(shè)經(jīng)驗(yàn)和互聯(lián)網(wǎng)整合營(yíng)銷的理念,并將策略和執(zhí)行緊密結(jié)合,為客戶提供全網(wǎng)互聯(lián)網(wǎng)整合方案。
?編譯 | 影子
策劃 | 云昭
云原生時(shí)代,選擇一家靠譜的云產(chǎn)品,成為了技術(shù)人在設(shè)計(jì)和部署架構(gòu)時(shí)不得不面臨的難題。內(nèi)存、容量、數(shù)據(jù)庫(kù)、流量計(jì)費(fèi)等等都是大家常見的可選參數(shù)。
然而,官網(wǎng)上那些承諾的“高可用、彈性擴(kuò)容、實(shí)時(shí)伸縮”的產(chǎn)品,果真靠譜嗎?
一份來(lái)自知名云服務(wù)商Fly.io公司Leader的“檢討書”,或許能給大家?guī)?lái)答案。
美國(guó)初創(chuàng)公司Fly.io,是一個(gè)應(yīng)用服務(wù)器提供商,而且即便不考慮其免費(fèi)套餐,定價(jià)也極為親民,不用擔(dān)心免費(fèi)額度用超了以后的價(jià)格問(wèn)題。尤其在容器部署部署方面,頗受開發(fā)者追捧:它部署起來(lái)極為方便,性價(jià)比很高。因而,近幾年發(fā)展極為快速,但發(fā)展快并不總是件好事。
最近,一篇“自我檢討”式的博客:《可靠性:不太好》在了Fly.io的社區(qū)中大火,并快速占據(jù)頭條位置。網(wǎng)友驚呼:感謝你的誠(chéng)實(shí)!
以下是原文:
過(guò)去的四個(gè)月很難熬。我們遇到的問(wèn)題比我們能接受的還要多。
我一直猶豫著要不要分享這個(gè),因?yàn)?,我正在和一種令人頹喪的失敗感作斗爭(zhēng)。如果我們不改進(jìn),我們的公司就不復(fù)存在,我真的很喜歡在這家公司工作。
我們面臨的一個(gè)有趣的問(wèn)題是:我們的受歡迎程度激增。這聽起來(lái)多好的事兒!但是我們已經(jīng)超越了平臺(tái)最初的設(shè)計(jì)初衷。我們投入了大量的工作和資源來(lái)發(fā)展平臺(tái),完善我們的工程組織。但這個(gè)動(dòng)作還是太遲了!
然而,這對(duì)用戶而言,他們并不在乎云產(chǎn)品的受歡迎程度。實(shí)際上,用戶只是想自信地發(fā)布自己的應(yīng)用程序。
這也是我們產(chǎn)品想要的。但,這真是一種苦力,我們并沒(méi)有像應(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ò)來(lái)接受訪客流量,根據(jù)請(qǐng)求運(yùn)行中間件,然后將它們路由到后端應(yīng)用程序,使網(wǎng)站所有者能夠引導(dǎo)訪客只需點(diǎn)擊幾下即可安全地訪問(wèn)。
我們的平臺(tái),說(shuō)白了就是一堆移動(dòng)的“部件”,所有這些部件都需要協(xié)同工作,這樣你就可以部署應(yīng)用程序,再次部署它,然后走開,24個(gè)月后再回來(lái),發(fā)現(xiàn)它仍然在工作。以下是實(shí)現(xiàn)這一目標(biāo)的原因:
? 一個(gè)集中的API,對(duì)數(shù)據(jù)庫(kù)進(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鏡像注冊(cè)表;
? 一個(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è)施。
可是以上這些都做得很失敗,簡(jiǎn)直讓人驚掉下巴。我們當(dāng)然慶幸用戶沒(méi)有發(fā)現(xiàn)并注意到。以下是過(guò)去4個(gè)月發(fā)生的一些重大事故,排名不分先后:
(1)服務(wù)發(fā)現(xiàn)和Corrosion
(2)集中式機(jī)密存儲(chǔ)
(3)Postgres
(4)容量問(wèn)題
(5)固定到主機(jī)硬件的容量
(6)狀態(tài)分頁(yè)
2、服務(wù)發(fā)現(xiàn)和Corrosion
接口過(guò)期、內(nèi)部DDos
我們?cè)谒械貐^(qū)傳播應(yīng)用實(shí)例和健康信息。這樣,代理就知道將請(qǐng)求路由到哪里,DNS服務(wù)器就知道該返回什么名稱。
我們開始用HashiCorp Consul做這個(gè)操作。但是我們把Consul硬塞給了一個(gè)不適合它的全球服務(wù)發(fā)現(xiàn)角色,Consul有一個(gè)為單個(gè)數(shù)據(jù)中心部署設(shè)計(jì)的集中式服務(wù)器模型。其結(jié)果是:持續(xù)陳舊的數(shù)據(jù)、路由到已過(guò)期接口的代理,以及經(jīng)常有陳舊條款的專有DNS。
所有這一切都是我們通過(guò)中央服務(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的一致性問(wèn)題卻成了一個(gè)挑戰(zhàn)。我們很快關(guān)閉了Corrosion項(xiàng)目,因?yàn)镃onsul給用戶帶來(lái)了相當(dāng)大的困擾。這款新軟件引發(fā)了兩次問(wèn)題。兩者都表現(xiàn)為損壞的全局服務(wù)發(fā)現(xiàn)狀態(tài)。
第一次發(fā)生在我們的一個(gè)進(jìn)程向Corrosion發(fā)送垃圾郵件并進(jìn)行更新,基本上把它變成了一個(gè)內(nèi)部DDoS。第二次發(fā)生在一次例行更新中,竟然搞亂了數(shù)據(jù)庫(kù)。
這兩個(gè)問(wèn)題造成的結(jié)果就是,部署期間應(yīng)用程序遭到破壞。隨著虛擬機(jī)來(lái)來(lái)去去,我們的代理服務(wù)器和DNS服務(wù)器會(huì)發(fā)現(xiàn)自己無(wú)法處理過(guò)時(shí)的數(shù)據(jù)。
Corrosion需要對(duì)“失效”有足夠的彈性。我們正在做一些漸進(jìn)措施來(lái)改善它(例如,速率限制,減輕“內(nèi)部DDoS”風(fēng)險(xiǎn))。同時(shí),我們也在致力于架構(gòu)的改變。gossip模式很棘手,因?yàn)椴蝗菀鬃粉櫟骄唧w的問(wèn)題節(jié)點(diǎn),而且傳播很快,這正是你不希望出現(xiàn)的。
去除Nomad,也將有助于緩解Corrosion問(wèn)題。因?yàn)镹omad為每次部署創(chuàng)建全新的實(shí)例,所以會(huì)有大量的服務(wù)發(fā)現(xiàn)變動(dòng);每秒鐘有大量的事件更新。還好,F(xiàn)ly 的基于機(jī)器的應(yīng)用程序沒(méi)有那么瘋狂——當(dāng)我們更新運(yùn)行在機(jī)器上的應(yīng)用程序時(shí),我們會(huì)在適當(dāng)?shù)奈恢眠M(jìn)行更新。
最后,問(wèn)題不止于服務(wù)發(fā)現(xiàn),我們?cè)谝恢軆?nèi)對(duì)我們的平臺(tái)部署了很多更改。有時(shí),改動(dòng)會(huì)與用戶發(fā)生沖突;不合時(shí)宜的應(yīng)用部署,可能會(huì)使應(yīng)用處于不穩(wěn)定狀態(tài)。我們正在更新工具,以便在這些時(shí)候暫停應(yīng)用部署。當(dāng)沖突發(fā)生時(shí),我們將盡可能清楚地說(shuō)明原因。
3、集中式機(jī)密存儲(chǔ)
查找失敗、無(wú)法訪問(wèn)
我們?cè)贖ashiCorp Vault中存儲(chǔ)應(yīng)用程序機(jī)密。HashiCorp Vault的工作方式與Consul非常相似,具有中央服務(wù)器集群。
我們?cè)赩ault方面遇到的問(wèn)題,幾乎與Consul方面遇到的問(wèn)題同樣嚴(yán)重。每次新VM啟動(dòng)時(shí),運(yùn)行它的工作人員都必須從Vault中獲取機(jī)密。這有兩個(gè)基本問(wèn)題:
? Vault在美國(guó),遙遠(yuǎn)地區(qū)(如MAA)和美國(guó)之間的互聯(lián)網(wǎng)連接可能導(dǎo)致機(jī)密查找失??;
? 有些故障情況會(huì)導(dǎo)致無(wú)法訪問(wèn)Vault。例如,我們的一個(gè)Vault服務(wù)器出現(xiàn)故障,導(dǎo)致大范圍的虛擬機(jī)創(chuàng)建失敗。
與服務(wù)發(fā)現(xiàn)一樣,Nomad加劇了這些問(wèn)題,F(xiàn)ly Machines緩解了這些問(wèn)題。但如果Vault處于不良狀態(tài),新的Fly Machine創(chuàng)建也將失敗。
現(xiàn)有的開源不是為全球部署而設(shè)計(jì)的。因此,當(dāng)我們選擇“購(gòu)買”現(xiàn)有的基礎(chǔ)設(shè)施軟件時(shí),我們通常會(huì)在一定程度上為全球范圍的韌性付出代價(jià)。
4、Postgres集群
我們做了個(gè)糟糕的“非托管”決定
我們的Postgres集群有兩個(gè)主要問(wèn)題:我們對(duì)Stolon和Consul集群的實(shí)時(shí)連接的依賴以及我們對(duì)“非托管Postgres”的錯(cuò)誤預(yù)期。
第一個(gè)是架構(gòu)問(wèn)題。Postgres所依賴的Consul集群與我們用于服務(wù)發(fā)現(xiàn)的集群不同,但它們?nèi)匀粫?huì)以奇怪的方式“失敗”。Stolon是我們?cè)贔ly Postgres的第一次迭代中構(gòu)建的Postgres集群軟件,它不能很好地處理Consul連接問(wèn)題。
新的Postgres集群不使用Stolon,而是使用repmgr。epmgr處理集群內(nèi)的領(lǐng)導(dǎo)者選舉,不需要第二個(gè)數(shù)據(jù)庫(kù)。這些新的Postgres集群仍然使用Consul來(lái)共享配置信息,但是如果Consul崩潰,集群會(huì)繼續(xù)運(yùn)行。
我們正在努力將以前配置的Postgres DB升級(jí)到新的repmgr設(shè)置。有一些復(fù)雜的問(wèn)題,但我們會(huì)繼續(xù)發(fā)布。
Postgres的第二個(gè)問(wèn)題是做出了一個(gè)很糟糕的決定。我們決定推出“非托管Postgres”,這樣可以為我們爭(zhēng)取時(shí)間,以等待合適的托管Postgres提供程序出現(xiàn)。問(wèn)題是,“fly-pg create”意味著人們正在獲得一個(gè)托管的Postgres集群。這是因?yàn)槊恳粋€(gè)具有“獲取一個(gè)簡(jiǎn)單的Postgres”功能的服務(wù)程序都會(huì)為用戶提供一個(gè)托管堆棧。
這對(duì)于我們來(lái)說(shuō)是一個(gè)非常沉痛的教訓(xùn)。我們最終展示了很多有關(guān)用戶體驗(yàn)的承諾,但卻沒(méi)有堅(jiān)持到貫徹。我們不是那種會(huì)寫價(jià)值觀口號(hào)的公司,如果是,我們會(huì)加上一句“不要違背開發(fā)者的期望來(lái)制造令人討厭的偽驚喜”。
要解決托管Postgre,我們需要一段時(shí)間才能實(shí)現(xiàn),但它是基礎(chǔ)架構(gòu)堆棧的核心組件,我們不能假裝不需要這樣。
5、容量問(wèn)題:想當(dāng)然了
新用戶的涌入使我們?cè)诙鄠€(gè)地區(qū)耗盡了服務(wù)器容量,有時(shí)不止一次。這是兩個(gè)層面上的失敗——其一,我們沒(méi)有足夠快地響應(yīng),去購(gòu)買服務(wù)器。其二,我們沒(méi)有好的工具來(lái)減輕特定地區(qū)的壓力。
去年,我們想當(dāng)然了,以為就算我們遇到容量問(wèn)題,我們也可以做到防止新的用戶在特定區(qū)域啟動(dòng)。然而,打臉了。
Heroku是一個(gè)支持多種編程語(yǔ)言的平臺(tái),它打破了我們的“想當(dāng)然”。在Heroku之前,我們運(yùn)行的大多數(shù)應(yīng)用程序都是跨地區(qū)的。而且:我們每個(gè)月增長(zhǎng)15%左右。但是后Heroku時(shí)代,我們只在幾個(gè)熱點(diǎn)地區(qū)有大量的應(yīng)用程序涌入——每月30%。
事后看來(lái),我應(yīng)該更早就開始,在我們還有融資的時(shí)候。
我們?cè)谌萘恳?guī)劃和物流方面做得越來(lái)越好。我把容量規(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)容解釋了這種方法的局限性。我們?cè)O(shè)計(jì)了volume,使其以2+為單位運(yùn)行。
這意味著,如果你所在的主機(jī)容量宕掉,你的應(yīng)用程序就會(huì)宕機(jī)。如果主機(jī)沒(méi)有足夠的內(nèi)存或CPU來(lái)運(yùn)行應(yīng)用程序VM,您可能無(wú)法部署。
然而,這些細(xì)節(jié)隨著我們的文檔的改進(jìn)而丟失,這導(dǎo)致了一些令人討厭的意外。這也是違反直覺(jué)的。人們習(xí)慣了AWS EBS的魔力。但我們的volume不是EBS。
這是用戶體驗(yàn)制造錯(cuò)誤期望的另一個(gè)例子。
7、狀態(tài)分頁(yè):吹噓自家產(chǎn)品,解答模糊
在我們狀態(tài)頁(yè)面上有一些含糊不清的發(fā)帖,受到了很多合理的批評(píng)。與此同時(shí),我們?cè)诓┛蜕蠠o(wú)恥地吹噓我們的技術(shù)。問(wèn)題時(shí)有發(fā)生,當(dāng)問(wèn)題發(fā)生時(shí),我們沒(méi)有積極地溝通。
工作的原因令我們迷失而忘掉了初心。從“計(jì)算機(jī)技術(shù)”的角度看,我在這里寫的一些挑戰(zhàn)是困難的。但這個(gè)問(wèn)題不是。這是不可原諒的,我們需要做到立即溝通。
我們招聘了一位非常優(yōu)秀的人來(lái)構(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ā)者遇到問(wèn)題時(shí),我們希望盡可能縮短處理鏈路,這樣就能更快地獲得信息。
我們還推出了個(gè)性化的狀態(tài)頁(yè)面。隨著規(guī)模的增長(zhǎng),我們服務(wù)器的數(shù)量也越來(lái)越多,遇到硬件故障的可能性也隨之增加。這使得我們很難保持一個(gè)完全透明的狀態(tài)頁(yè)面。個(gè)性化狀態(tài)頁(yè)面將使我們能夠更輕松地告訴受硬件故障影響的特定客戶“嘿,該地區(qū)有一個(gè)驅(qū)動(dòng)器壞了,我們正在解決”。
8、寫在最后
對(duì)于這份自我檢討,許多Fly.io客戶表示可以理解,“我確信這是一個(gè)艱難的過(guò)程,但這項(xiàng)艱巨的工作,是你為自己和客戶創(chuàng)造長(zhǎng)期價(jià)值的地方?!?/p>
“堅(jiān)持住!我很欣賞這種透明度,作為一名創(chuàng)業(yè)老手,我表示同情。雖然我最近對(duì)Fly感到失望了一兩次,但我仍然是一個(gè)付費(fèi)客戶,并且相信你們都會(huì)成功?!?/p>
有的甚至覺(jué)得有的缺點(diǎn)也是優(yōu)點(diǎn):“如volume與主機(jī)綁定,而不是像EBS那樣浮動(dòng),是一個(gè)優(yōu)點(diǎn)。EBS速度慢且昂貴。當(dāng)我想運(yùn)行數(shù)據(jù)庫(kù)時(shí),我希望選擇機(jī)器上的volume。因?yàn)槲也恍枰跈C(jī)器之間移動(dòng)磁盤映像,而是對(duì)volume或數(shù)據(jù)庫(kù)進(jìn)行可靠的備份?!?/p>
其實(shí)文中很多的問(wèn)題,或多或少都會(huì)在其他的云產(chǎn)品中出現(xiàn),通過(guò)“自我檢討”的公布,讓大家知道所使用的產(chǎn)品有哪些軟肋,以及為之正在采取的措施,F(xiàn)ly.io正在迎來(lái)前所未有的信任度和好感。
畢竟,“透明度”是獲取信任最好的途徑!
原文鏈接:https://community.fly.io/t/reliability-its-not-great/11253/2
當(dāng)前題目:一份云的公開檢討書走紅:我們不靠譜,網(wǎng)友:理解!
當(dāng)前路徑:http://m.fisionsoft.com.cn/article/dpdosip.html


咨詢
建站咨詢
