HelloFresh的規(guī)模一直保持著增長的態(tài)勢，我們的產(chǎn)品在持續(xù)改進，新的想法不斷涌現(xiàn)出來，我們擁有完全自動化的供應(yīng)鏈。持續(xù)的增長給我們帶來了驚喜，同時也帶來了技術(shù)方面的挑戰(zhàn)。 在這篇文章里，我將會和大家分享我們的基礎(chǔ)設(shè)施所經(jīng)歷的一次重大遷移，這次遷移保證了以后的路我們可以走得更快、更靈活，也更安全。 我們最近開發(fā)了一個API網(wǎng)關(guān)（github.com/hellofresh/janus），所以接下來需要在不停機的情況下對網(wǎng)關(guān)后面的主API（單體系統(tǒng)）進行遷移改造。升級之后，我們希望能夠開發(fā)更多的微服務(wù)系統(tǒng)，并且無縫對接到目前我們的基礎(chǔ)架構(gòu)中。 API網(wǎng)關(guān)處在基礎(chǔ)設(shè)施的最外層，它每天需要接收大量的請求，所以我們選擇了Go語言來構(gòu)建網(wǎng)關(guān)，因為Golang性能好、簡單易用，而且提供了優(yōu)雅的并發(fā)解決方案。我們手頭已經(jīng)有很多現(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ù)集成工具的主機，等等。按照我們的慣例，開發(fā)一個新服務(wù)時，我們工程師的第一件事情就是為這個服務(wù)創(chuàng)建Ansible腳本。 從某種程度上說，我們應(yīng)該監(jiān)控基礎(chǔ)設(shè)施里的所有東西。在日志和監(jiān)控應(yīng)用方面，我們有一些最佳實踐。
Grafana的儀表盤為性能度量指標提供了非常完美的視角。 盡管有了這些工具，我們?nèi)匀挥幸粋€棘手的問題需要解決：理清當(dāng)前的架構(gòu)，然后想清楚如何順利地進行遷移。我們花了一些時間對遺留系統(tǒng)進行了重構(gòu)，讓它們支持新的網(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)境。先來看看我們的初始計劃。
在staging環(huán)境一切進展得都很順利，當(dāng)我們準備進入生產(chǎn)環(huán)境時，問題出現(xiàn)了。
數(shù)據(jù)庫被沖垮，我們不得不馬上回滾。幸運的是，我們的監(jiān)控系統(tǒng)捕獲到了從認證服務(wù)獲取令牌的問題。 從第一次失敗中吸取了教訓(xùn)，我們知道我們還沒有為進入生產(chǎn)環(huán)境做好準備，于是在回滾之后，立即對問題展開診斷。在再次嘗試之前，我們做了一些改進。
我們花費了一個禮拜來完成上述的工作，之后的部署進展得很順利，中間沒有停機。不過盡管部署進展得很順利，我們?nèi)匀话l(fā)現(xiàn)了一些在自動化測試中沒有發(fā)現(xiàn)的個別問題，不過這些問題最終得到修復(fù)，并沒有對系統(tǒng)造成太大影響。 最終的架構(gòu)如下圖所示。 主API
4個應(yīng)用服務(wù)器
4個應(yīng)用服務(wù)器
其它
今日薦文點擊下方圖片即可閱讀 
InfoQ觀察：Java EE的未來 |
|
|
