5個(gè)小時(shí),我們將800個(gè)微服務(wù)遷移到了云端
9 月 16 日晚上,我們將 FINN 的生產(chǎn)環(huán)境從本地?cái)?shù)據(jù)中心遷移到了谷歌云平臺(tái)(GCP)。這意味著要遷移一個(gè)高流量的網(wǎng)站,該網(wǎng)站由一個(gè)復(fù)雜的分布式系統(tǒng)支持,由 800 多個(gè)應(yīng)用程序、145 個(gè)數(shù)據(jù)庫(kù)和 16TB 數(shù)據(jù)組成。我們?cè)谝归g有規(guī)劃的停機(jī)時(shí)間窗口,但這一窗口越小越好。我們是怎么做的?請(qǐng)繼續(xù)閱讀本文!
關(guān)于將 FINN.no 移出我們的數(shù)據(jù)中心,并遷移到云平臺(tái)中的內(nèi)部討論始于多年前。此后,我們一直在嘗試各種云技術(shù)和云提供商。當(dāng)我們?cè)?2016 年選擇 Kubernetes 作為平臺(tái)時(shí),我們的指導(dǎo)思想就是在云平臺(tái)中運(yùn)行 FINN。
從很久前開(kāi)始,我們?cè)谒枷肷弦呀?jīng)準(zhǔn)備好將系統(tǒng)遷移到云端了,但一直沒(méi)有制定真正實(shí)現(xiàn)這一目標(biāo)的策略或計(jì)劃。我們產(chǎn)品的某些部件早在 1998 年就開(kāi)始使用了,因此遷移它們是一項(xiàng)艱巨的任務(wù)。但是,隨著數(shù)據(jù)中心愈加不堪重負(fù)、對(duì)更靈活解決方案的需求,以及我們?nèi)ツ瓿晒?Sybase 從 Solaris 遷移到 Linux 的經(jīng)驗(yàn),都給了我們很多動(dòng)力來(lái)認(rèn)真考慮這一計(jì)劃。
我們從 2019 年 1 月開(kāi)始評(píng)估各家云提供商。候選名單包括 AWS、Google Cloud、IBM Cloud 和 Azure。我們參加了很多研討會(huì)、會(huì)議和電話會(huì)議,評(píng)估了自行管理服務(wù)以及將我們的服務(wù)托管于其他云提供商等許多選項(xiàng),最終我們決定采用“多云”方案,而選擇 GCP 作為我們大多數(shù)服務(wù)的首選項(xiàng)。該方案最終于 2019 年 8 月中旬被 Schibsted 批準(zhǔn)。
1. 準(zhǔn)備工作
遷移即將進(jìn)行,我們必須制定一個(gè)計(jì)劃,將我們擁有的一切轉(zhuǎn)移到 GCP,同時(shí)保持 FINN 的正常運(yùn)行。我們決定逐步遷移,使開(kāi)發(fā)人員能夠隨著時(shí)間的推移遷移服務(wù)。但是,時(shí)間過(guò)得真快,我們意識(shí)到可用時(shí)間越來(lái)越少?;A(chǔ)架構(gòu)的惡化、現(xiàn)有數(shù)據(jù)中心計(jì)劃中的網(wǎng)絡(luò)翻新以及資源的匱乏,使我們很難看到逐步遷移的成功前景。全球疫情大流行也讓工作變得更困難了。我們被迫做出一些艱難的決定。
2020 年 6 月,我們了解到,我們需要采取更直接的方法,并確定向 GCP 迅速切換的日期。我們將目標(biāo)日期定為 9 月 15 日,并獲得了 FINN 管理小組批準(zhǔn),準(zhǔn)許 FINN.no 停機(jī)一晚。7 月,云平臺(tái)遷移被設(shè)置為 FINN 的第一要?jiǎng)?wù);這意味著所有團(tuán)隊(duì)必須完成他們負(fù)責(zé)的所有與云平臺(tái)遷移相關(guān)的工作,然后才能進(jìn)行其他計(jì)劃的任務(wù)。是時(shí)候該去(遠(yuǎn)程)工作了。
當(dāng)我們決定放棄逐步遷移,決定快速切換時(shí),擺在我們面前的艱巨任務(wù)就開(kāi)始出現(xiàn)了。我們必須準(zhǔn)備一個(gè)平臺(tái),使我們能夠在一夜之間移動(dòng) 800 多個(gè)應(yīng)用、145 個(gè)數(shù)據(jù)庫(kù)、超過(guò) 16TB 的數(shù)據(jù)以及 183 個(gè)虛擬機(jī)。FINN 的基礎(chǔ)架構(gòu)團(tuán)隊(duì)已經(jīng)為云平臺(tái)遷移做了很長(zhǎng)時(shí)間的準(zhǔn)備,但是這個(gè)決定使我們重新集中精力。現(xiàn)在,我們必須堅(jiān)定地確定優(yōu)先級(jí),在必要時(shí)花時(shí)間深入探索技術(shù),且始終保持目標(biāo)清晰。在某些情況下,這意味著我們需要改變甚至放棄我們?cè)?jīng)投入大量時(shí)間的一些解決方案。
從夏天結(jié)束的那一刻起,我們就努力使這一計(jì)劃取得成功。我們必須對(duì)我們需要花時(shí)間要做的事情和必須等待的事情做出艱難的選擇。但是我們盡量不走捷徑,堅(jiān)持我們的原則,例如基礎(chǔ)設(shè)施即代碼。隨著遷移日越來(lái)越近以及工作量的增加,我們的信心也隨之增加。
該圖顯示了隨著切換時(shí)間的臨近,我們用于維護(hù) FINN 基礎(chǔ)架構(gòu)的一個(gè)存儲(chǔ)庫(kù)的更改頻率不斷增長(zhǎng)
對(duì) FINN.no 的更改通常每天實(shí)行約 350 次。在切換前的最后 24 小時(shí),我們決定建議使用“發(fā)行凍結(jié)”,這意味著那些既不能解決實(shí)時(shí)生產(chǎn)問(wèn)題,又不能解決與云平臺(tái)遷移有關(guān)的更改應(yīng)等到第二天。切換的前一天,更改頻率降低到一半左右,并且在云平臺(tái)切換開(kāi)始前幾分鐘,最后一個(gè)產(chǎn)品部署到了我們的原有內(nèi)部基礎(chǔ)架構(gòu)中。
2. 云平臺(tái)切換
9 月 15 日 23:00 時(shí),基礎(chǔ)架構(gòu)團(tuán)隊(duì)聚在一起(在線),準(zhǔn)備就緒并檢查切換前檢查清單。由于每個(gè)人都在不同的地理位置,因此我們依靠詳細(xì)的運(yùn)行手冊(cè)和視頻會(huì)議進(jìn)行協(xié)作。對(duì) FINN.no 的更改通常在不停機(jī)的情況下進(jìn)行部署,站點(diǎn)停機(jī)是 1 級(jí)嚴(yán)重事件。不過(guò),這不是一個(gè)正常的星期二晚上。午夜時(shí)分,我們將用戶重定向到靜態(tài)后備頁(yè)面后關(guān)閉了 FINN.no。半小時(shí)后,我們關(guān)閉了本地 Kubernetes 集群中的所有應(yīng)用程序。
轉(zhuǎn)換期間在 FINN.no 上顯示的靜態(tài)后備頁(yè)面
然后我們準(zhǔn)備遷移數(shù)據(jù)。Kafka 是我們微服務(wù)架構(gòu)的基礎(chǔ)之一。每天大約有 20 億條消息(平均每秒 30,000 條)通過(guò)我們的 Kafka 集群,其穩(wěn)定性對(duì)于 FINN 的正常運(yùn)轉(zhuǎn)至關(guān)重要。Kafka 小組遷移了我們的 Kafka 群集,該團(tuán)隊(duì)暫時(shí)以“延伸集群”配置運(yùn)行該集群,將我們的本地?cái)?shù)據(jù)中心和云平臺(tái)作為單個(gè)集群。我們提前幾周仔細(xì)計(jì)劃和實(shí)施了延伸集群配置。Kafka 中的主題在切換前一周已復(fù)制到 GCP 的 broker 中,而 GCP 的 broker 在轉(zhuǎn)換過(guò)程中成為主 broker。
需要持久存儲(chǔ)的服務(wù)通常使用我們的 25 個(gè) PostgreSQL 集群之一或我們的 Sybase 集群。我們通過(guò)預(yù)先在 GCP 中設(shè)置數(shù)據(jù)庫(kù)副本,并在切換過(guò)程中所有應(yīng)用程序停止后切換主數(shù)據(jù)庫(kù)來(lái)遷移這些數(shù)據(jù)庫(kù)集群。在切換當(dāng)天的 01:35,Kafka 以及我們所有的 PostgreSQL 和 Sybase 數(shù)據(jù)庫(kù)都運(yùn)行在了 GCP 中。
移動(dòng)持久數(shù)據(jù)后,我們觸發(fā)了所有應(yīng)用程序到新的 Google Container Engine(GKE)集群的部署。到 02:30,所有 800 個(gè)應(yīng)用程序(超過(guò) 1500 個(gè) Kubernetes 的 pod)都已部署到 GKE。至此,我們當(dāng)晚只遇到了一些小的問(wèn)題和延誤,并已經(jīng)準(zhǔn)備好進(jìn)行內(nèi)部測(cè)試。
在切換之夜前,我們?cè)谒蓄I(lǐng)域的遷移準(zhǔn)備和測(cè)試計(jì)劃方面都做得非常出色,當(dāng)午夜測(cè)試開(kāi)始,看到綠燈亮起,我們的基礎(chǔ)架構(gòu)團(tuán)隊(duì)感到非常欣慰。對(duì)平臺(tái)所有不同部分的自組織測(cè)試的效果甚至超出了我們的想象!
經(jīng)過(guò)所有團(tuán)隊(duì)的良好團(tuán)隊(duì)合作,修復(fù)了一些應(yīng)用部署、損壞的數(shù)據(jù)庫(kù)表和其他一些小問(wèn)題之后,云平臺(tái)中的 FINN 于 04:43 啟用,沒(méi)有發(fā)生重大事故。
在 FINN.no 在云平臺(tái)中于 04:43 啟用后,通過(guò)某個(gè)負(fù)載均衡器的請(qǐng)求的速率增長(zhǎng)曲線
我們?yōu)槟軌虺晒M(jìn)行云平臺(tái)切換而感到自豪!
沒(méi)有 FINN Technology 的優(yōu)秀人才,遷移不可能成功。我們?cè)诮M織的各個(gè)部門(mén)都得到支持,當(dāng)行動(dòng)號(hào)召到來(lái)時(shí),每個(gè)人都加入進(jìn)來(lái)并做了應(yīng)做的部分工作。在準(zhǔn)備階段,開(kāi)發(fā)團(tuán)隊(duì)一直在努力處理防火墻、網(wǎng)絡(luò)路由和負(fù)載平衡器,發(fā)現(xiàn)我們新的 GCP 基礎(chǔ)架構(gòu)中的問(wèn)題,并與基礎(chǔ)架構(gòu)團(tuán)隊(duì)合作解決這些問(wèn)題。在切換之夜的前幾個(gè)星期,我們?cè)诠ぷ鲿r(shí)間還針對(duì)開(kāi)發(fā)環(huán)境進(jìn)行了轉(zhuǎn)換演習(xí)。這次“排演”使我們充滿信心,相信我們可以在指定的停機(jī)時(shí)間窗口內(nèi)執(zhí)行轉(zhuǎn)換,幫助我們發(fā)現(xiàn)和糾正工具方面的問(wèn)題,并且對(duì)于完善生產(chǎn)切換的運(yùn)行手冊(cè)非常有幫助。這兩件事都有助于將風(fēng)險(xiǎn)降低到可接受的水平。
由于我們的遷移工作有一個(gè)硬期限,因此許多系統(tǒng)必須采用直接遷移方式進(jìn)行移動(dòng)。當(dāng)我們稍微適應(yīng)云環(huán)境時(shí),我們期待將基礎(chǔ)架構(gòu)的這些部分也變得更加云原生化。