http://www.infoq.com/cn/news/2017/04/hellofresh-api-migration

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

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

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

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

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

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

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

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

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

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

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

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

https://github.com/hellofresh/janus

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

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9251421.html

總結(jié)

以上是生活随笔為你收集整理的HelloFresh迁移至新的API网关，实现微服务架构的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。