帶你讀《雲原生應用開發 Operator原理與實踐》第一章引言1.1雲原生介紹（五）

1.1.3        應用雲原生改造

業界雲原生相關的基礎設施已基本成熟。對使用者來說，對已有的傳統架構服務進行改造，加速遷移到雲平台至關重要。

應用的雲原生改造基本分為3個階段：（1）容器化改造；（2）微服務化改造；（3） DevOps 改造。下面分别說明。

1. 容器化改造

  為什麼要對傳統應用進行容器化改造？傳統雲化應用大多運作在虛拟機上，如圖1-5所示，由于增加了虛拟作業系統這一抽象層，虛拟機方案過于複雜備援，存在資源排程困難、使用率低下、難以快速傳遞部署等問題。是以，使用共享核心的輕量級容器技術成為雲原生時代更好的選擇。

圖 1—5虛拟機 vs容器

容器化改造是将傳統應用程式和其所需的運作環境打包在一起形成完整的鏡像，使得應用可以運作在 Docker、KataContainer   或其他類似容器中。容器化改造的具體流程如下。

（1）  抽離環境不同導緻配置項發生變化，用環境變量或參數等形式傳入應用。

（2）   編寫 Dockerfile檔案 ，在 Dockerfile 中安裝程式運作依賴的第三方軟體包。

（3）  根據 Dockerfile 檔案建構容器鏡像，并推送到容器鏡像倉庫。容器化改造後，應用程式将具有如下優勢。

（1） 标準化：隻需配置好 Docker 或其他類似容器的運作時環境，即可消除開發、測試、生産環境的不一緻性，進而實作一次建構，随時可運作。

（2） 快速傳遞，通過建構容器鏡像，可以實作高度定制化的自動傳遞部署機制，以及錯誤復原機制，極大地降低運維流程的複雜度。

（3） 高效：由于容器間互相隔離，確定了應用有序競争資源，進而降低系統整體資源負載。

2. 微服務化改造 

容器化改造本質上是優化了應用運作的環境，并沒有改變傳統應用内部子產品的耦合，存在擴充困難、可靠性低等問題，是以，微服務化改造應運而生。

微服務化改造就是将原有的單體應用按照業務範圍劃分成多個微服務，服務之間互相獨立，通過遠端過程調用協定（RPC，RemoteProcedureCallProtocol）、RESTfulAPI等輕量級通信機制通信，整體形成分布式的架構。

容器化改造結合微服務化改造，應用将具備更多優勢。

（1） 松耦合：由于容器的隔離性，不同服務内部獨立，可以采用不同的開發語言，獨立測試、部署，不需要考慮技術棧的互相影響；個别服務業務變動，重新部署上線也不會影響其他服務。

（2） 擴充性：随着服務複雜度的提升，需要配置設定更多的資源，結合容器技術可針對所需服務進行資源的精準按需配置設定，提高資源使用率；同時當業務需要添加新的第三方依賴時，得益于容器化的輕量性，可以快速啟動依賴服務。

（3）  高可靠：重點服務可大量橫向擴充，以確定服務的高可用性；此外得益于低耦合和容器的快速部署，可動态根據流量規模對部分服務進行動态擴縮容。

結合雲原生平台提供無侵入式的自動化服務發現、監控、容錯、追蹤等微服務網格

（ServiceMesh）的能力，可以進一步發揮微服務改造後應用的優勢。