一個創業公司的API閘道器落地實踐

ADVERTISEMENT

HelloFresh是一家食品電商初創公司,使用者根據選定的菜譜下單,HelloFresh把菜譜所需要的食材送至使用者家中。來自HelloFresh的技術負責人Ítalo Lelis在部落格上分享了HelloFresh的API閘道器落地實踐,本文為該博文的譯文,並已獲得原網站的翻譯授權。

HelloFresh的規模一直保持著增長的態勢:我們的產品在持續改進,新的想法不斷湧現出來,我們擁有完全自動化的供應鏈。持續的增長給我們帶來了驚喜,同時也帶來了技術方面的挑戰。

在這篇文章裡,我將會和大家分享我們的基礎設施所經歷的一次重大遷移,這次遷移保證了以後的路我們可以走得更快、更靈活,也更安全。

我們最近開發了一個API閘道器,所以接下來需要在不停機的情況下對閘道器後面的主API(單體系統)進行遷移改造。升級之後,我們希望能夠開發更多的微服務系統,並且無縫對接到目前我們的基礎架構中。

API閘道器處在基礎設施的最外層,它每天需要接收大量的請求,所以我們選擇了Go語言來構建閘道器,因為Go效能好、簡單易用,而且提供了優雅的並發解決方案。

我們手頭已經有很多現成的工具,它們可以簡化我們的遷移工作。

我們使用Consul作為服務發現工具,它和HAProxy配合起來使用可以幫我們解決微服務架構的兩個主要問題:服務發現(新服務上線時會自動註冊)和客戶端負載均衡(把請求均衡地分發到各個伺服器上)。

我們的工具箱裡最有用的工具或許要數基礎設施的自動化。我們使用Ansible在雲端管理資源,包括單機、網路、DNS、執行持續整合工具的主機,等等。按照我們的慣例,開發一個新服務時,我們工程師的第一件事情就是為這個服務建立Ansible指令碼。

從某種程度上說,我們應該監控基礎設施裡的所有東西。在日誌和監控應用方面,我們有一些最佳實踐。

ADVERTISEMENT
  • 辦公室裡有儀錶盤(就是國內公司裡的大電視屏,顯示系統狀態),我們在任何時候都可以檢視系統的執行情況。

  • 我們使用ELK技術棧來收集日誌,從而可以快速地分析服務的執行情況。

  • 我們使用Statsd和Grafana作為監控工具,這些工具總會給我們帶來驚喜。

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

儘管有了這些工具,我們仍然有一個棘手的問題需要解決:理清當前的架構,然後想清楚如何順利地進行遷移。我們花了一些時間對遺留系統進行了重構,讓它們支援新的閘道器,同時我們也加入了認證服務。在這個過程中,我們遇到了一些問題。

  • 雖然我們可以對移動應用進行更新,但也要考慮到有些使用者可能不願意升級,所以我們要保持向後相容,比如DNS,我們要確保舊版本也能正常工作。

  • 我們需要整理出所有公開和私有的API端點,並讓它們自動地註冊到閘道器上。

  • 我們需要把認證工作從主API遷移到新的認證服務上。

  • 確保閘道器和微服務之間通訊的安全性。

為瞭解決這些問題,我們寫了一個Go指令碼,這個指令碼會讀取OpenAPI規範(Swagger)檔案併為API資源建立規則(比如速率限定、配額、CORS等)代理。

我們在staging環境搭建了整個基礎設施,並在上面執行自動化測試,對服務間的通訊進行了測試。不得不說,自動化staging測試在整個遷移過程中起到了很大的作用。我們有很多功能測試用例,這些用例保證了主API的功能是完好的。

在確保了staging環境一切正常之後,我們開始考慮如何將它們推到生產環境。

可以告訴大家的是,我們的第一次嘗試簡直是災難性的。儘管我們已經做足了計劃,不過仍然不足以把它們推向生產環境。先來看看我們的初始計劃。

  • 把最新的API閘道器部署到staging環境

    ADVERTISEMENT
  • 把主API的變更部署到staging環境

  • 在staging環境執行自動化功能測試

  • 通過網站和移動端進行staging環境的手動測試

  • 把最新的API閘道器部署到生產環境

  • 把主API的變更部署到生產環境

  • 在生產環境執行自動化功能測試

  • 通過網站和移動端進行生產環境的手動測試

  • 慶祝勝利

在staging環境一切進展得都很順利,當我們準備進入生產環境時,問題出現了。

  1. 認證服務的資料庫過載:我們低估了請求的流量,造成資料庫拒絕連線

  2. 錯誤的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作為持續整合工具

檢視英文原文:Scaling @ HelloFresh: API Gateway

今日薦文

UCloud下一代VPC架構平滑演進方案和技術詳解

細說雲端計算

「細說雲端計算」是InfoQ旗下關注雲端計算技術的垂直社群,[email protected],註明“細說雲端計算投稿”即可。


» 細說雲端計算

ADVERTISEMENT
ADVERTISEMENT