HelloFresh最近以零停機(jī)的方式將應(yīng)用遷移到了一個(gè)新的API網(wǎng)關(guān)，其技術(shù)總監(jiān)ítalo Lelis de Vietro在一篇文章中分享了他們所面臨的挑戰(zhàn)以及遷移的過程。

在這次遷移之前，HelloFresh已有的API是單體架構(gòu)的。為了遷移至微服務(wù)架構(gòu)并讓微服務(wù)的創(chuàng)建更加簡(jiǎn)單，同時(shí)還要與他們的基礎(chǔ)設(shè)施進(jìn)行集成，他們構(gòu)建了一個(gè)新的API網(wǎng)關(guān)，這個(gè)網(wǎng)關(guān)會(huì)涵蓋已有的和新的服務(wù)。他們的基礎(chǔ)設(shè)施已經(jīng)有了一些組件，包括服務(wù)發(fā)現(xiàn)、基于Ansible的自動(dòng)化以及廣泛存在的日志和監(jiān)控，這些組件都會(huì)讓微服務(wù)更加易于實(shí)現(xiàn)。為了解決零停機(jī)以及向后兼容的難題，團(tuán)隊(duì)編寫了一個(gè)代理腳本將舊服務(wù)轉(zhuǎn)換為新的模式。遷移過程的第一次嘗試失敗了，然而第二次嘗試按照預(yù)期得到了成功。

HelloFresh已有的基礎(chǔ)設(shè)施使用Consul來實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)，并使用HAProxy實(shí)現(xiàn)客戶端的負(fù)載均衡。這兩個(gè)因素促使他們轉(zhuǎn)向了微服務(wù)。團(tuán)隊(duì)還有一個(gè)約定，那就是所有的新服務(wù)必須要從Ansible自動(dòng)化開始著手。這種自動(dòng)化幾乎涵蓋了整個(gè)技術(shù)棧，包括網(wǎng)絡(luò)、DNS、CI以及機(jī)器的供應(yīng)。在分布式系統(tǒng)多個(gè)服務(wù)存在交互的場(chǎng)景下，可見性（Visibility）是至關(guān)重要的，HelloFresh存在著廣泛的日志和監(jiān)控功能。Statsd和Grafana用于實(shí)現(xiàn)監(jiān)控和儀表盤， ELK則被用來詳細(xì)分析服務(wù)的行為，它們組成了這方面的技術(shù)棧。

除了新的網(wǎng)關(guān)，新的認(rèn)證服務(wù)也已經(jīng)進(jìn)行了規(guī)劃，它將會(huì)代替舊API中的認(rèn)證模塊。這需要舊應(yīng)用進(jìn)行重構(gòu)。

團(tuán)隊(duì)預(yù)遷移的挑戰(zhàn)在于要向后兼容移動(dòng)應(yīng)用，確保所有的服務(wù)通過新的網(wǎng)關(guān)調(diào)用，所有的調(diào)用能夠安全傳輸，已有的API規(guī)則在新的API網(wǎng)關(guān)中能夠繼續(xù)得到遵循。不能對(duì)用戶強(qiáng)制要求移動(dòng)應(yīng)用的更新，因此API要保持向后的兼容性。正在使用的API同時(shí)包含公開的和私有的端點(diǎn)，所有的這些端點(diǎn)必須要使用新的網(wǎng)關(guān)進(jìn)行注冊(cè)。微服務(wù)和網(wǎng)關(guān)之間的服務(wù)調(diào)用傳輸必須是安全的。API按照 OpenAPI格式進(jìn)行文檔化，這是用于描述REST API的一個(gè)標(biāo)準(zhǔn)。這樣的話，團(tuán)隊(duì)就能夠使用Go來編寫導(dǎo)入腳本，它會(huì)在舊API和新API間進(jìn)行轉(zhuǎn)換，并保持像配額（quotas）、CORS設(shè)置以及限速這樣的規(guī)則。

遷移的第一次嘗試包括將舊的API替換為新的，首先在staging環(huán)境，然后是在生產(chǎn)環(huán)境，每一步都有相關(guān)的測(cè)試用例。這次嘗試最終失敗了，因?yàn)檎J(rèn)證數(shù)據(jù)庫(kù)由于大量的請(qǐng)求出現(xiàn)負(fù)荷超載了。團(tuán)隊(duì)低估了負(fù)載，數(shù)據(jù)庫(kù)開始拒絕連接。另外，在導(dǎo)入腳本方面有一些CORS錯(cuò)誤配置。監(jiān)控系統(tǒng)能夠捕獲到問題，遷移過程被回滾了。

第二次部署嘗試基于第一次所學(xué)習(xí)到的經(jīng)驗(yàn)教訓(xùn)。團(tuán)隊(duì)規(guī)劃了一個(gè)藍(lán)綠（blue-green）部署，預(yù)先準(zhǔn)備了一個(gè)使用新網(wǎng)關(guān)的生產(chǎn)環(huán)境副本。這種設(shè)置使得新舊環(huán)境的切換變得更加容易，所需要的是配置的變更。機(jī)器的容量進(jìn)行了重新的規(guī)劃，這基于正在運(yùn)行的應(yīng)用的指標(biāo)以及第一次部署的負(fù)載指標(biāo)所確定的。他們使用了一個(gè)開源的負(fù)載測(cè)試工具Gatling來運(yùn)行性能測(cè)試。認(rèn)證服務(wù)中一些已知的issue也進(jìn)行了修正。

遷移之后，基礎(chǔ)設(shè)施如下圖所示：

圖片來源：http://highscalability.com/blog/2017/2/20/scaling-hellofresh-api-gateway.html

API網(wǎng)關(guān)是HelloFresh基礎(chǔ)設(shè)施的前沿。團(tuán)隊(duì)為什么要構(gòu)建自己的網(wǎng)關(guān)，而不是采用已有的解決方案呢？de Vietro在評(píng)論區(qū)是這樣回應(yīng)的：

我們?cè)?jīng)嘗試Amazon API網(wǎng)關(guān)和Tyk，但是我們有自己的認(rèn)證提供商（provider），將它與AWS網(wǎng)關(guān)集成的效果并不理想。我們必須要處理lambdas（AWS的云服務(wù)——譯注）來添加自定義的認(rèn)證提供商。將相關(guān)指標(biāo)數(shù)據(jù)集成到grafana也會(huì)更加復(fù)雜一些，另外一點(diǎn)就是我們會(huì)鎖定到相同的供應(yīng)商上面。Tyk并沒有在自定義認(rèn)證提供商方面給出什么方案（至少當(dāng)時(shí)如此），我們必須要使用他們的內(nèi)置策略、用戶管理以及ACL，這并不是我們想要的結(jié)果。我覺得現(xiàn)在的產(chǎn)品已經(jīng)有了很大的不同，但這就是當(dāng)時(shí)的原因所在。另外，借助我們自己的網(wǎng)關(guān)，可以版本化git上的路由配置文件，為其保留變更日志對(duì)我們來說至關(guān)重要。

這個(gè)API網(wǎng)關(guān)已經(jīng)在Github上開源了。

查看英文原文：HelloFresh's Migration to a New API Gateway to Enable Microservices