原文地址：http://chuansong.me/n/1650350951816
作者｜Ítalo Lelis編輯｜薛命燈HelloFresh是一家食品電商初創公司，用戶根據選定的菜譜下單，HelloFresh把菜譜所需要的食材送至用戶家中。來自HelloFresh的技術負責人Ítalo Lelis在博客上分享了HelloFresh的API網關落地實踐，本文為該博文的譯文，並已獲得原網站的翻譯授權。
HelloFresh的規模一直保持着增長的態勢，我們的產品在持續改進，新的想法不斷涌現出來，我們擁有完全自動化的供應鏈。持續的增長給我們帶來了驚喜，同時也帶來了技術方面的挑戰。
在這篇文章里，我將會和大家分享我們的基礎設施所經歷的一次重大遷移，這次遷移保證了以后的路我們可以走得更快、更靈活，也更安全。
我們最近開發了一個API網關（github.com/hellofresh/janus），所以接下來需要在不停機的情況下對網關后面的主API（單體系統）進行遷移改造。升級之后，我們希望能夠開發更多的微服務系統，並且無縫對接到目前我們的基礎架構中。
API網關處在基礎設施的最外層，它每天需要接收大量的請求，所以我們選擇了Go語言來構建網關，因為Golang性能好、簡單易用，而且提供了優雅的並發解決方案。我們手頭已經有很多現成的工具，它們可以簡化我們的遷移工作。
服務發現和客戶端負載均衡
我們使用Consul作為服務發現工具，它和HAProxy配合起來使用可以幫我們解決微服務架構的兩個主要問題：服務發現（新服務上線時會自動注冊）和客戶端負載均衡（把請求均衡地分發到各個服務器上）。
自動化
我們的工具箱里最有用的工具或許要數基礎設施的自動化。我們使用Ansible在雲端管理資源，包括單機、網絡、DNS、運行持續集成工具的主機，等等。按照我們的慣例，開發一個新服務時，我們工程師的第一件事情就是為這個服務創建Ansible腳本。
日志和監控
從某種程度上說，我們應該監控基礎設施里的所有東西。在日志和監控應用方面，我們有一些最佳實踐。
-
辦公室里有儀表盤（就是國內公司里的大電視屏，顯示系統狀態），我們在任何時候都可以查看系統的運行情況。
-
我們使用ELK技術棧來收集日志，從而可以快速地分析服務的運行情況。
-
我們使用Statsd和Grafana作為監控工具，這些工具總會給我們帶來驚喜。
Grafana的儀表盤為性能度量指標提供了非常完美的視角。
理解當前的架構
盡管有了這些工具，我們仍然有一個棘手的問題需要解決：理清當前的架構，然后想清楚如何順利地進行遷移。我們花了一些時間對遺留系統進行了重構，讓它們支持新的網關，同時我們也加入了認證服務。在這個過程中，我們遇到了一些問題。
-
雖然我們可以對移動應用進行更新，但也要考慮到有些用戶可能不願意升級，所以我們要保持向后兼容，比如DNS，我們要確保舊版本也能正常工作。
-
我們需要整理出所有公開和私有的API端點，並讓它們自動地注冊到網關上。
-
我們需要把認證工作從主API遷移到新的認證服務上。
-
確保網關和微服務之間通信的安全性。
為了解決這些問題，我們寫了一個Go腳本，這個腳本會讀取OpenAPI規范（Swagger）文件並為API資源創建規則（比如速率限定、配額、CORS等）代理。
我們在staging環境搭建了整個基礎設施，並在上面運行自動化測試，對服務間的通信進行了測試。不得不說，自動化staging測試在整個遷移過程中起到了很大的作用。我們有很多功能測試用例，這些用例保證了主API的功能是完好的。
在確保了staging環境一切正常之后，我們開始考慮如何將它們推到生產環境。
第一次嘗試
可以告訴大家的是，我們的第一次嘗試簡直是災難性的。盡管我們已經做足了計划，不過仍然不足以把它們推向生產環境。先來看看我們的初始計划。
-
把最新的API網關部署到staging環境
-
把主API的變更部署到staging環境
-
在staging環境運行自動化功能測試
-
通過網站和移動端進行staging環境的手動測試
-
把最新的API網關部署到生產環境
-
把主API的變更部署到生產環境
-
在生產環境運行自動化功能測試
-
通過網站和移動端進行生產環境的手動測試
-
慶祝勝利
在staging環境一切進展得都很順利，當我們准備進入生產環境時，問題出現了。
-
認證服務的數據庫過載：我們低估了請求的流量，造成數據庫拒絕連接
-
錯誤的CORS配置：部分端點的CORS規則配置錯誤，造成請求無法獲得資源
數據庫被沖垮，我們不得不馬上回滾。幸運的是，我們的監控系統捕獲到了從認證服務獲取令牌的問題。
第二次嘗試
從第一次失敗中吸取了教訓，我們知道我們還沒有為進入生產環境做好准備，於是在回滾之后，立即對問題展開診斷。在再次嘗試之前，我們做了一些改進。
-
准備藍綠（blue-green）部署過程。我們為生產環境創建了一個副本，包括已經部署好的網關，通過一些簡單的配置變更就能讓整個集群運行起來，如果需要回滾，也只需做一些簡單的配置變更。
-
從當前的系統收集更多的度量指標，這樣可以幫助我們決定該使用多少機器來處理負載。我們利用第一次嘗試時所使用的數據作為探針，並使用Gatling來運行負載測試，確保我們可以應付預期的流量。
-
再次進入生產環境之前，我們對認證服務的已知問題進行了修復，包括一個大小寫問題、一個JWT簽名的性能問題，並添加了更多的日志和監控。
我們花費了一個禮拜來完成上述的工作，之后的部署進展得很順利，中間沒有停機。不過盡管部署進展得很順利，我們仍然發現了一些在自動化測試中沒有發現的個別問題，不過這些問題最終得到修復，並沒有對系統造成太大影響。
最終結果
最終的架構如下圖所示。
主API
-
10多個主API部署在裝配了高端CPU的主機上
-
主從MySQL（3個副本）
-
認證服務
4個應用服務器
-
主從PostgreSQL（2個副本）
-
RabbitMQ用於異步地處理用戶的更新操作
-
API網關
4個應用服務器
-
主從MongoDB（4個副本）
其它
-
使用Ansible批量管理遠程服務器
-
使用Amazon CloudFront作為CDN/WAF
-
使用Consul和HAProxy作為服務發現和客戶端負載均衡工具
-
使用Stasd和Grafana收集系統度量指標並觸發告警
-
使用ELK技術棧從不同的服務收集日志
-
使用Concourse CI作為持續集成工具