微服務入門——服務部署

最新 03-30

本文是微服務入門系列的第四篇文章，本系列一共有如下內容：

《走進微服務的世界》

《微服務架構下的分散式事務基礎入門》

《微服務架構下的分散式事務解決方案》

《資料庫的服務化切分》

《服務部署》

當我們完成業務代碼的開發後，就需要進入部署階段。在部署過程中，我們將會引入持續集成、持續交付、持續部署，並且闡述如何在微服務中使用他們。

在介紹這三個概念之前，我們首先來了解下使用了這三個概念之後的軟體開發流程，如下圖所示：

首先是代碼的開發階段，當代碼完成開發後需要提交至代碼倉庫，此時需要對代碼進行編譯、打包，打包後的產物被稱為「構建物」，如：對Web項目打包之後生成的war包、jar包就是一種構建物。此時的構建物雖然沒有語法錯誤，但其質量是無法保證的，必須經過一系列嚴格的測試之後才能具有部署到生產環境的資格。我們一般會給系統分配多套環境，如開發環境、測試環境、預發環境、生產環境。每套環境都有它測試標準，當構建物完成了一套環境的測試，並達到交付標準時，就會自動進入下一個環境。構建物依次會經過這四套環境，構建物每完成一套環境的驗證，就具備交付給下一套環境的資格。當完成預發環境的驗證後，就具備的上線的資格。

測試和交付過程是相互伴隨的，每一套環境都有各自的測試標準。如在開發環境中，當代碼提交後需要通過編譯、打包生成構建物，在編譯的過程中會對代碼進行單元測試，如果有任何測試用例沒通過，整個構建流程就會被中止。此時開發人員需要立即修復問題，並重新提交代碼、重新編譯打包。

當單元測試通過之後，構建物就具備了進入測試環境的資格，此時它會被自動部署到測試環境，進行新一輪的測試。在測試環境中，一般需要完成介面測試和人工測試。介面測試由自動化腳本完成，這個過程完成後還需要人工進行功能性測試。人工測試完成後，需要手動觸發進入下一個階段。

此時構建物將會被部署到預發環境。預發環境是一種「類生產環境」，它和生產環境的伺服器配置需要保持高度一致。在預發環境中，一般需要對構建物進行性能測試，了解其性能指標是否能滿足上線的要求。當通過預發驗證後，構建物已經具備了上線的資格，此時它可以隨時上線。

上述過程涵蓋了持續集成、持續交付、持續部署，那麼下面我們就從理論角度來介紹這三個概念。

「集成」指的是修改後/新增的代碼向代碼倉庫合併的過程，而「持續集成」指的是代碼高頻率合併。這樣有什麼好處呢？大家不妨想一想，如果我們集成代碼的頻率變高了，那麼每次集成的代碼量就會變少，由於每次集成的時候都會進行單元測試，從而當出現問題的時候問題出現的範圍就被縮小的，這樣就能快速定位到出錯的地方，尋找問題就更容易了。此外，頻繁集成能夠使問題儘早地暴露，這樣解決問題的成本也就越低。因為在軟體測試中有這樣一條定律，時間和bug修復的成本成正比，也就是時間越長，bug修復的成本也就越大。所以持續集成能夠儘早發現問題，並能夠及時修復問題，這對於軟體的質量是非常重要的。

「持續部署」指的是當存在多套環境時，當構建物成完上一套環境的測試後，自動部署到下一套環境並進行一系列的測試，直到構建物滿足上線的要求為止。

當系統通過了所有的測試之後，就具備了部署到生產環境的資格，這個過程也就被稱為「交付」。「持續交付」指的是每個版本的構建物都具有上線的資格，這就要求每當代碼庫中有新的版本後，都需要自動觸發構建、測試、部署、交付等一系列流程，當構建物在某個階段的測試未通過時，就需要開發人員立即解決這個問題，並重新構建，從而保證每個版本的構建物都具備上線的資格，可以隨時部署到生產環境中。

當我們了解了持續集成後，下面來介紹微服務如何與持續集成相整合。當我們對系統進行了微服務化後，原本單一的系統被拆分成多個課獨立運行的微服務。單服務系統的持續集成較為簡單，代碼庫、構建和構建物之間都是一對一的關係。然而，當我們將系統微服務化後，持續集成就變得複雜了。下面介紹兩種在微服務中使用持續集成的方法，分別是單庫多構建和多庫多構建，並依次介紹這兩種方式的優缺點及使用場景。

「單庫」指的是單個代碼倉庫，即整個系統的多個模塊的代碼均由一個代碼倉庫維護。「多構建」指的是持續集成平台中的構建項目會有多個，每個構建都會生成一個構建物，如下如所示：

在這種持續集成的模式中，整個項目的所有代碼均在同一個代碼倉庫中維護。但在持續集成平台中，每一項服務都有各自獨立的構建，從而持續集成平台能夠為每一項服務產出各自的構建物。

這種持續集成的模式在微服務架構中顯然是不合理的。首先，一個系統的可能會有很多服務構成，如果將這些服務的代碼均在同一個代碼倉庫中維護，那麼一個程序員在開發服務A代碼的時候很有可能會因為疏忽，修改了服務B的代碼，此時服務B構建之後就會存在安全隱患，如果這個問題在服務B上線前被發現，那麼還好，但無疑增加了額外的工作量；但如果這個問題及其隱諱，導致之前的測試用例沒有覆蓋到，從而服務B會帶著這個問題進入生產環境，這可能會給企業帶來巨大的損失。所以，在微服務架構中，盡量選擇多庫多構建模式來實現持續集成，它將帶來更大的安全性。

雖然這種模式不合理，但它也有存在的必要性，當我們在項目建設初期的時候，這種模式會給我們帶來更多的便利性。因為項目在建設初期，服務之間的邊界往往是比較模糊的，而且需要經過一段時間的演化才能夠構建出穩定的邊界。所以如果在項目建設初期直接使用微服務架構，那麼服務邊界頻繁地調整會極大增加系統開發的複雜度，你要知道，在多個系統之間調整邊界比在單個系統的多個模塊之間調整邊界的成本要高很多。所以在項目建設初期，我們可以使用單服務結構，服務內部採用模塊作為未來各個微服務的邊界，當系統演化出較為清晰、穩定的邊界後再將系統拆分成多個微服務。此時代碼在同一個代碼倉庫中維護是合理的，這也符合敏捷開發中快速迭代的理念。

當系我們的系統擁有了穩定、清晰的邊界後，就可以將系統向微服務架構演進。與此同時，持續集成模式也可以從單庫多構建向多庫多構建演進。

在多庫多構建模式中，每項服務都有各自獨立的代碼倉庫，代碼倉庫之間互不干擾。開發團隊只需關注屬於自己的某幾項服務的代碼倉庫即可。每一項服務都有各自獨立的構建。這種方式邏輯清晰，維護成本較低，而且能避免單庫多構建模式中出現的影響其他服務的問題。

持續集成平台對源碼編譯、大包後生成的產物稱為「構建物」。根據打包的粒度不同，可以將構建物分為如下三種：平台構建物、操作系統構建物和鏡像構建物。

平台構建物指的是由某一特定平台生成的構建物，比如JVM平台生成的Jar包、War包，Python生成的egg等都屬於平台構建物。但平台構建物運行需要部署在特定的容器中，如war需要運行在Servlet容器中，而Servlet容器又依賴的JVM環境。所以若要部署平台構建物，則需要先給它們提供好運行所需的環境。

操作系統構建物是將系統打包成一個操作系統可執行程序，，如CentOS的RPM包、Windows的MSI包等。這些安裝包可以在操作系統上直接安裝運行。但和平台構建物相同的是，操作系統構建物往往也需要依賴於其他環境，所以也需要在部署之前搭建好安裝包所需的依賴。此外，配置操作系統構建物的複雜度較大，構建的成本較高，所以一般不使用這種方式，這裡僅作介紹。

平台構建物和操作系統構建物都有一個共同的缺點就是需要安裝構建物運行的額外依賴，增加部署複雜度，而鏡像構建物能很好地解決這個問題。

我們可以把鏡像理解成一個小型操作系統，這個操作系統中包含了系統運行所需的所有依賴，並將系統也部署在這個「操作系統」中。這樣當持續集成平台構建完這個鏡像後，就可以直接運行它，無需任何依賴的安裝，從而極大簡化了構建的複雜度。但是，鏡像往往比較龐大，構建鏡像的過程也較長，從而當我們將生成的鏡像從持續集成伺服器發布到部署伺服器的時間將會很長，這無疑降低了部署的效率。不過好在Docker的出現解決了這一問題。持續集成平台在構建過程中並不需要生成一個鏡像，而只需生成一個鏡像的Dockerfile文件即可。Dockerfile文件用命令定義了鏡像所包含的內容，以及鏡像創建的過程。從而持續集成伺服器只需將這個體積較小的鏡像文件發布到部署伺服器上即可。然後部署伺服器會通過docker build命令基於這個Dockerfile文件創建鏡像，並創建該鏡像的容器，從而完成服務的部署。

相對於平台構建物和操作系統構建物而言，鏡像構建物在部署時不需要安裝額外的環境依賴，它把環境依賴的配置都在持續集成平台構建Dockerfile文件時完成，從而簡化了部署的過程。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！