HelloFresh是一家食品電商初創(chuàng)公司，用戶根據(jù)選定的菜譜下單，HelloFresh把菜譜所需要的食材送至用戶家中。來自HelloFresh的技術(shù)負責(zé)人ítalo Lelis在博客上分享了HelloFresh的API網(wǎng)關(guān)落地實踐，本文為該博文的譯文，并已獲得原網(wǎng)站的翻譯授權(quán)。

HelloFresh的規(guī)模一直保持著增長的態(tài)勢：我們的產(chǎn)品在持續(xù)改進，新的想法不斷涌現(xiàn)出來，我們擁有完全自動化的供應(yīng)鏈。持續(xù)的增長給我們帶來了驚喜，同時也帶來了技術(shù)方面的挑戰(zhàn)。

在這篇文章里，我將會和大家分享我們的基礎(chǔ)設(shè)施所經(jīng)歷的一次重大遷移，這次遷移保證了以后的路我們可以走得更快、更靈活，也更安全。

挑戰(zhàn)

我們最近構(gòu)建了一個API網(wǎng)關(guān)，接下來需要在不停機的情況下對網(wǎng)關(guān)后面的主API（單體系統(tǒng)）進行遷移改造，這對我么來說是一個很大的挑戰(zhàn)。

架構(gòu)

API網(wǎng)關(guān)處在基礎(chǔ)設(shè)施的最外層，它每天需要接收大量的請求，所以我們選擇了Go語言來構(gòu)建網(wǎng)關(guān)，因為Go性能好、簡單易用，而且提供了優(yōu)雅的并發(fā)解決方案。

我們手頭已經(jīng)有很多現(xiàn)成的工具，它們可以簡化我們的遷移工作。

服務(wù)發(fā)現(xiàn)和客戶端負載均衡

我們使用Consul作為服務(wù)發(fā)現(xiàn)工具，它和HAProxy配合起來使用可以幫我們解決微服務(wù)架構(gòu)的兩個主要問題：服務(wù)發(fā)現(xiàn)（新服務(wù)上線時會自動注冊）和客戶端負載均衡（把請求均衡地分發(fā)到各個服務(wù)器上）。

自動化

我們的工具箱里最有用的工具或許要數(shù)基礎(chǔ)設(shè)施的自動化。我們使用Ansible在云端管理資源，包括單機、網(wǎng)絡(luò)、DNS、運行持續(xù)集成工具的主機，等等。按照我們的慣例，當(dāng)有新服務(wù)被創(chuàng)建，我們的工程師第一件事情就是為這個服務(wù)創(chuàng)建Ansible腳本。

日志和監(jiān)控

從某種程度上說，基礎(chǔ)設(shè)施里的所有東西都應(yīng)該被監(jiān)控起來。在記錄日志和監(jiān)控應(yīng)用方面，我們有一些最佳實踐。

辦公室里有儀表盤，我們在任何時候都可以查看系統(tǒng)的運行情況。我們使用ELK技術(shù)棧來收集日志，從而可以快速地分析服務(wù)的運行情況。我們使用Statsd和Grafana作為監(jiān)控工具，這些工具總會給我們帶來驚喜。

Grafana的儀表盤為性能度量指標提供了非常完美的視角。

理解當(dāng)前的架構(gòu)

盡管有了這些工具，我們?nèi)匀挥幸粋€棘手的問題需要解決：理清當(dāng)前的架構(gòu)，然后想清楚如何順利地進行遷移。我們花了一些時間對遺留系統(tǒng)進行了重構(gòu)，讓它們支持新的網(wǎng)關(guān)，同時我們也加入了認證服務(wù)。在這個過程中，我們遇到了一些問題。

雖然我們可以對移動應(yīng)用進行更新，但也要考慮到有些用戶可能不愿意升級，所以我們要保持向后兼容，比如DNS，我們要確保舊版本也能正常工作。我們需要整理出所有公開和私有的API端點，并讓它們自動地注冊到網(wǎng)關(guān)上。我們需要把認證工作從主API遷移到新的認證服務(wù)上。確保網(wǎng)關(guān)和微服務(wù)之間通信的安全性。

為了解決這些問題，我們寫了一個Go腳本，這個腳本會讀取OpenAPI規(guī)范（Swagger）文件并為API資源創(chuàng)建規(guī)則（比如速率限定、配額、CORS等）代理。

我們在staging環(huán)境搭建了整個基礎(chǔ)設(shè)施，并在上面運行自動化測試，對服務(wù)間的通信進行了測試。不得不說，自動化staging測試在整個遷移過程中起到了很大的作用。我們有很多功能測試用例，這些用例保證了主API的功能是完好的。

在確保了staging環(huán)境一切正常之后，我們開始考慮如何將它們推到生產(chǎn)環(huán)境。

第一次嘗試

可以告訴大家的是，我們的第一次嘗試簡直是災(zāi)難性的。盡管我們已經(jīng)做足了計劃，不過仍然不足以把它們推向生產(chǎn)環(huán)境。先來看看我們的初始計劃。

把最新的API網(wǎng)關(guān)部署到staging環(huán)境把主API的變更部署到staging環(huán)境在staging環(huán)境運行自動化功能測試通過網(wǎng)站和移動端進行staging環(huán)境的手動測試把最新的API網(wǎng)關(guān)部署到生產(chǎn)環(huán)境把主API的變更部署到生產(chǎn)環(huán)境在生產(chǎn)環(huán)境運行自動化功能測試通過網(wǎng)站和移動端進行生產(chǎn)環(huán)境的手動測試慶祝勝利

在staging環(huán)境一切進展得都很順利，當(dāng)我們準備進入生產(chǎn)環(huán)境時，問題出現(xiàn)了。

認證服務(wù)的數(shù)據(jù)庫過載：我們低估了請求的流量，造成數(shù)據(jù)庫拒絕連接錯誤的CORS配置：部分端點的CORS規(guī)則配置錯誤，造成請求無法獲得資源

數(shù)據(jù)庫被沖垮，我們不得不馬上回滾。幸運的是，我們的監(jiān)控系統(tǒng)捕獲到了從認證服務(wù)獲取令牌的問題。

第二次嘗試

從第一次失敗中吸取了教訓(xùn)，我們知道我們還沒有為進入生產(chǎn)環(huán)境做好準備，于是在回滾之后，立即對問題展開診斷。在再次嘗試之前，我們做了一些改進。

準備藍綠（blue-green）部署過程。我們?yōu)樯a(chǎn)環(huán)境創(chuàng)建了一個副本，包括已經(jīng)部署好的網(wǎng)關(guān)，通過一些簡單的配置變更就能讓整個集群運行起來，如果需要回滾，也只需做一些簡單的配置變更。從當(dāng)前的系統(tǒng)收集更多的度量指標，這樣可以幫助我們決定該使用多少機器來處理負載。我們利用第一次嘗試時所使用的數(shù)據(jù)作為探針，并使用Gatling來運行負載測試，確保我們可以應(yīng)付預(yù)期的流量。再次進入生產(chǎn)環(huán)境之前，我們對認證服務(wù)的已知問題進行了修復(fù)，包括一個大小寫問題、一個JWT簽名的性能問題，并添加了更多的日志和監(jiān)控。

我們花費了一個禮拜來完成上述的工作，之后的部署進展得很順利，中間沒有停機。不過盡管部署進展得很順利，我們?nèi)匀话l(fā)現(xiàn)了一些在自動化測試中沒有發(fā)現(xiàn)的個別問題，不過這些問題最終得到修復(fù)，并沒有對系統(tǒng)造成太大影響。

結(jié)果

最終的架構(gòu)如下圖所示。

　　主API

10多個主API部署在裝配了高端CPU的主機上主從MySQL（3個副本）

認證服務(wù)

4個應(yīng)用服務(wù)器主從PostgreSQL（2個副本）RabbitMQ用于異步地處理用戶的更新操作

API網(wǎng)關(guān)

4個應(yīng)用服務(wù)器主從MongoDB（4個副本）

其它

使用Ansible批量管理遠程服務(wù)器使用Amazon CloudFront作為CDN/WAF使用Consul和HAProxy作為服務(wù)發(fā)現(xiàn)和客戶端負載均衡工具使用Stasd和Grafana收集系統(tǒng)度量指標并觸發(fā)告警使用ELK技術(shù)棧從不同的服務(wù)收集日志使用Concourse CI作為持續(xù)集成工具

查看英文原文：Scaling @ HelloFresh: API Gateway