微服務、容器、DevOps的三角戀看得清嗎?
容器的普及，帶來了微服務架構和DevOps的高速發展。
1 微服務的弊端
1.1 測試、發布工作量劇增
單體應用拆分成多個微服務后，雖能實現快速開發迭代，但帶來更大測試和運維部署的成本。
- 很多業務早期就是一個大的單體Web應用，測試和運維時，只需把Web應用打WAR包，部署到Tomcat完事
- 拆成微服務后，很多業務需求就需同時修改多個服務的代碼，那么這些服務都要打包、測試和發布上線，還要測試這些服務接口的功能，最后發布上線多個系統，測試和運維工作量增都劇增。這個時候就需要有辦法能夠減輕測試和運維的負擔，我在上一講給出的解決方案是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鏡像。某Docker鏡像分為四層。
- 基礎環境層
定義操作系統運行的版本、時區、語言、yum源、TERM等
- 運行時環境層
定義了業務代碼的運行時環境，比如Java代碼的運行時環境JDK的版本。
- Web容器層
定義了業務代碼運行的容器的配置，比如Tomcat容器的JVM參數
- 業務代碼層
定義了實際的業務代碼的版本，比如是V4業務還是blossom業務。
如此每層鏡像都基于上層添加新內容，比如V4業務的Dockerfile
- FROM registry.intra.xxx.com/xxx_rd_content/tomcat_feed:jdk8.0.40_tomcat7.0.81_g1_dns
- 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 chmod +x /data1/xxx/bin/200.sh /data1/xxx/bin/503.sh /data1/xxx/bin/catalina.sh
- WORKDIR /data1/xxx/bin
- FROM代表上層鏡像文件為tomcat_feed:jdk8.0.40_tomcat7.0.81_g1_dns”，可見該層包含了Java運行時環境JDK和Web容器Tomcat及Tomcat版本和JVM參數等
- ADD，即要在該層鏡像添加的文件，主要包含業務的代碼和配置
- RUN，該層鏡像啟動時需要執行的命令
- WORKDIR，該層鏡像啟動后的工作目錄。如此便可通過Dockerfile基于上層鏡像完成該層鏡像制作
5 總結
正是因為Docker可做到一處通過、到處運行，對業務價值極大，解決了以前應用程序在開發環境、測試環境及生產環境間移植難，提高了運維自動化水平，也為DevOps理念的流行和業務上云提供了基礎。
當然Docker也會帶來新問題，如舊的針對物理機的運維模式就無法適應了，需要一種新的針對容器的運維模式。
