微服務、容器、DevOps的三角戀

JavaEdge發表於2024-11-28
微服務dev

0 前言

容器的普及，帶來了微服務架構和DevOps的高速發展。

1 微服務的弊端

1.1 測試、釋出工作量劇增

單體應用拆分成多個微服務後，雖能實現快速開發迭代，但帶來更大測試和運維部署的成本。

  1. 很多業務早期就是一個大的單體Web應用，測試和運維時，只需把Web應用打WAR包，部署到Tomcat完事
  2. 拆成微服務後，很多業務需求就需同時修改多個服務的程式碼，那麼這些服務都要打包、測試和釋出上線，還要測試這些服務介面的功能，最後釋出上線多個系統，測試和運維工作量增都劇增。這個時候就需要有辦法能夠減輕測試和運維的負擔，我在上一講給出的解決方案是DevOps。

DevOps可理解為開發和運維的結合，服務的開發者不再只負責服務的程式碼開發，還要負責服務的測試、上線釋出甚至故障處理等全生命週期過程，就能把測試和運維從微服務拆分後所帶來的複雜工作中解放。
DevOps要求開發、測試和釋出流程自動化，這就需保證開發人員將自己本地部署測試透過的程式碼和執行環境，能夠複製到測試環境，測試透過後再複製到線上環境釋出。雖然看上去就是複製程式碼，但實際上本地環境、測試環境及線上環境往往是隔離，軟體配置環境差異很大，導致開發、測試和釋出流程割裂。

1.2 機器初始化複雜度劇增

彈性擴縮容時不同微服務所要求軟體執行環境差異帶來的機器初始化複雜度的提升。拆分後的微服務相比原來大單體應用更靈活，經常要根據實際訪問量做線上擴縮容，而且通常會採用在公有云上建立的ECS擴縮容。
這又給運維帶來挑戰，因為公有云上建立的ECS通常只包含基本os環境，微服務執行依賴的軟體配置等需運維單獨初始化，因不同微服務的軟體配置依賴不同，比如Java服務依賴JDK，就需在ECS安裝JDK，而且可能不同微服務JDK版本也不同，服務部署的初始化工作十分繁瑣。

2 還好有你:容器

容器技術解決了本地、測試、線上環境的隔離，解決部署服務初始化繁瑣的問題。
容器，即Container可翻譯成集裝箱，在港口把貨物用集裝箱封裝起來，然後經過貨輪從海上運輸到另一個港口，再在港口解除安裝後透過大貨車運送到目的地。如此貨物便可在任何地方流轉時，都封裝在集裝箱，無需根據是在貨輪還是大貨車而對貨物重新裝配。
軟體的容器也就這麼個作用，它封裝的是軟體的執行環境。容器本質是Linux裡的程序，但容器透過Namespace和Cgroups，可有自己的root檔案系統、網路配置、程序空間，甚至自己的使用者ID空間，如此容器裡的程序就像執行在宿主機上的另外一個單獨的os內，從而實現與宿主機os裡執行的其他程序隔離。

Docker即是基於Linux核心的Cgroups、Namespace實現程序的封裝和隔離。
雖然容器解決了應用程式執行時隔離問題，但要想實現應用能從一臺機器遷移到另外一臺機器上還能正常執行，就必須保證另外一臺機器上的os一致，而且應用程式依賴的各種環境也必須一致。Docker映象就解決了這個痛點。
即Docker映象不僅可打包應用程式本身，而且還可打包應用程式的所有依賴，甚至包含整個os。這樣在本機上執行透過的應用程式，就可使用Docker映象把應用程式檔案、所有依賴的軟體以及os都打包成一個映象，可在任何一個安裝了Docker的地方執行。

Docker映象解決了DevOps中微服務執行的環境難以在本地環境、測試環境以及線上環境保持一致的難題。如此一來，開發就可以把在本地環境中執行測試透過的程式碼，以及依賴的軟體和作業系統本身打包成一個映象，然後自動部署在測試環境中進行測試，測試透過後再自動釋出到線上環境上去，整個開發、測試和釋出的流程就打通了。

無論使用內部物理機還是公有云的機器部署服務，都可利用Docker映象封裝微服務執行環境，從而遮蔽機器內部物理機和公有云機器執行環境的差異，實現同等對待，降低運維複雜度。

3 微服務容器化實踐

Docker解決服務執行環境遷移問題，因為在使用Docker映象時並非把：

  • 業務程式碼
  • 依賴的軟體環境
  • os

直接打包成映象，而是利用Docker映象的分層機制，在每層編寫Dockerfile逐層打包映象。因為雖不同微服務依賴軟體環境不同，但還是存在相同部分。因此打包Docker映象時，可分層設計、逐層複用，減少每層映象檔案大小。

4 業務案例

某Docker映象分四層：

  • 基礎環境層：定義os執行的版本、時區、語言、yum源、TERM等
  • 執行時環境層：定義業務程式碼的執行時環境，如Java程式碼的執行時環境JDK的版本
  • Web容器層：定義業務程式碼執行的容器的配置，如Tomcat容器的JVM引數
  • 業務程式碼層：定義實際的業務程式碼的版本，如是V4業務還是blossom業務

如此，每層映象都基於上層再添新內容，如V4業務的Dockerfile：

# FROM代表上層映象檔案為tomcat_feed:jdk8.0.40_tomcat7.0.81_g1_dns，可見該層包含JDK和Tomcat及其版本和JVM引數等
FROM registry.intra.xxx.com/xxx_rd_content/tomcat_feed:jdk8.0.40_tomcat7.0.81_g1_dns

# ADD，要在該層映象新增的檔案，主要包含業務的程式碼和配置
ADD confs /data1/confs/
ADD node_pool /data1/node_pool/
ADD authconfs /data1/authconfs/
ADD authkey.properties /data1/
ADD watchman.properties /data1/
ADD 200.sh /data1/xxx/bin/200.sh
ADD 503.sh /data1/xxx/bin/503.sh
ADD catalina.sh /data1/xxx/bin/catalina.sh
ADD server.xml /data1/xxx/conf/server.xml
ADD logging.properties /data1/xxx/conf/logging.properties
ADD ROOT /data1/xxx/webapps/ROOT/

# RUN，該層映象啟動時需要執行的命令
RUN chmod +x /data1/xxx/bin/200.sh /data1/xxx/bin/503.sh /data1/xxx/bin/catalina.sh

# WORKDIR，該層映象啟動後的工作目錄。如此便可透過Dockerfile基於上層映象完成該層映象製作
WORKDIR /data1/xxx/bin

5 總結

正因Docker可做到一處透過、到處執行，對業務價值極大，解決以前應用程式在開發、測試及生產環境間移植難，提高運維自動化水平，也為DevOps理念流行和業務上雲提供基礎。

當然Docker也帶來新問題，如舊的針對物理機的運維模式無法適應，需要新的容器運維模式。

本文已收錄在Github，關注我，緊跟本系列專欄文章，咱們下篇再續！

作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。

各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。

負責：

  • 中央/分銷預訂系統效能最佳化
  • 活動&券等營銷中臺建設
  • 交易平臺及資料中臺等架構和開發設計
  • 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
  • LLM Agent應用開發
  • 區塊鏈應用開發
  • 大資料開發挖掘經驗
  • 推薦系統專案

目前主攻市級軟體專案設計、構建服務全社會的應用系統。

參考：

  • 程式設計嚴選網

本文由部落格一文多發平臺 OpenWrite 釋出！

相關文章