近年來，應用開發和部署發生了一些變化。這些變化是由兩方面促成的，一方面是大型單體應用被拆解為更多小型的微服務，另一方面是應用程序運行所依賴的基礎架構發生了變化。理解這些變化，將使我們更好的看到使用k8s和容器化技術(比如Docker)帶來的好處。

1. 從單體應用到微服務

單體應用由緊密耦合在一起的多個組件構成，由于這些組件在同一個操作系統進程中運行，所以在開發、部署和管理時必須以同一個實體進行。

如果對應用某一組件進行了修改，就需要對整個應用進行重新部署。組件缺乏嚴格的邊界定義，相互依賴，日積月累導致系統復雜度提升，整體質量也急劇惡化。如下圖所示的單體應用：

單體應用

運行一個單體應用程序通常需要少量的能夠為運行應用程序提供足夠資源的高性能的服務器。為了應對不斷增長的系統負荷，我們通常采用增加更多的CPU、內存和其他系統資源的方式來對服務器做垂直擴展，或者通過添加額外的服務器和運行應用的多個副本的方式對整個系統進行水平擴展。雖然垂直擴展通常不需要應用程序做任何變化，但是成本很快會越來越高，而且在實踐中總是有上限。水平擴展在硬件方面相對便宜些，但是需要對應用程序代碼做很大的修改，比如應用程序的某些部分非常難于甚至不太可能去做水平擴展(比如關系型數據庫)。

如果單體應用的任何一部分不能擴展，那整個應用就不能擴展，除非我們想辦法把它拆分開。

雖然垂直擴展通常不需要應用程序做任何變化，但是成本很快會越來越高，而且在實踐中總是有上限。水平擴展在硬件方面相對便宜些，但是需要對應用程序代碼做很大的修改，比如應用程序的某些部分非常難于甚至不太可能去做水平擴展(比如關系型數據庫)。

如果單體應用的任何一部分不能擴展，那整個應用就不能擴展，除非我們想辦法把它拆分開。

將應用拆分為微服務

這些問題迫使我們將復雜的單體應用拆解為更小的、可獨立部署的微服務組件。每個微服務以一個獨立的進程運行，通過簡單且定義良好的API接口與其他微服務通信。如下圖：

基于微服務的應用

微服務之間可以通過同步協議(如HTTP)進行通信，也可通過異步協議(如AMQP)進行通信。 基于HTTP，微服務可以對外提供RESTful API接口。這些協議比較簡單，能夠被大多數開發人員理解，而且不依賴于某一種編程語言。每個微服務可以通過最適合自己的編程語言來實現。

由于每個微服務都是獨立的進程，提供相對靜態的API，所以可以獨立的開發和部署每個微服務。對某個服務進行了修改，并不需要對其他服務進行更改或者重新部署，只要API沒有變化，或者只是以向后兼容的方式發生了變化。

擴展微服務

單體應用需要把系統作為一個整體來進行擴展，而微服務的擴展是通過基于單個服務來完成的，這意味著我們可以選擇只擴展哪些需要更多資源的服務而讓其他服務仍然維持在原有的規模。如下圖所示：

單體應用的擴展與微服務的擴展

某個組件被復制出三份，并且以多進程的方式運行在不同的服務器上。而其他組件卻以單個進程的方式運行。當單體應用因為其中一部分無法擴展而整體被限制擴展時，可以把應用拆分成多個微服務，將那些能進行擴展的組件進行水平擴展，不能進行擴展的組件進行垂直擴展。

部署微服務

當然，微服務也有缺點。如果你的系統僅包含少許可部署的組件，管理這些組件還是很容易的。完全沒必要去選擇將每個組件部署到哪里，因為本來選擇就不多。當組件數量增加時，部署相關的決定變得越來越困難。因為不僅部署組合數增加了，而且組件間相互依賴的組合數也在增加。

微服務之間是以團隊的形式執行工作的，因此它們需要發現彼此并與之通信。部署微服務時，需要正確的配置所有服務以使它們作為一個單一的系統協同工作。隨著微服務數量的增加，配置工作將變得繁瑣而且更易出錯。

微服務也會帶來一些問題，比如調試代碼和追蹤程序執行變得困難，因為服務是以多進程方式運行且部署到多個服務器上的。幸運的是，這些問題如今已經被諸如ZipKin這種分部署追蹤系統解決了。

2. 為應用程序提供一個一致的環境

微服務中的各個組件不僅是被獨立部署的，而且也是被獨立開發的。由于它們的獨立性，不同團隊開發各自的組件是很常見的情況，每個團隊都可能使用不同的依賴庫并在需求變化的時候替換它們。

應用程序組件之間依賴關系的差異性是不可避免的。如下圖所示，部署到同一臺機器上的多個應用程序會依賴同一個庫的不同版本：

同一臺主機上多個應用的依賴庫版本沖突

如果動態鏈接的應用依賴不同版本的共享庫或者其他環境相關細節，那么在生產服務器對其進行部署和管理將變成運維團隊的噩夢。部署到同一臺機器上的組件數越多，管理它們各自的依賴以滿足需求將會變得更加困難。

無論我們當前正在開發和部署的組件有多少，開發人員和運維團隊不得不面對的一個問題就是應用程序運行環境的差異性。這種巨大的差異不僅體現在開發和生產環境之間，甚至存在于各個生產服務器之間。

另一個不可避免的事實是，生產服務器所處的環境會隨著時間的推移而變化。這些差異體現在從硬件到操作系統再到每臺機器上可用的依賴庫上。生產環境通常由運維團隊進行管理，而開發者常常比較關心他們自己的開發環境。這兩組人對系統管理的理解程度是不同的，這個理解偏差導致兩個環境系統有較大的差異，系統管理員更重視保持系統更新，對系統應用最近的安全補丁，而大多數開發人員則并不太關心這點。

生產系統可能會運行多個應用，這些應用來自開發人員或者部署團隊。而開發人員的個人PC就不存在這種情況了。一個生產系統必須提供合適的環境供應用程序部署，即使這些程序需要不同的甚至沖突的依賴庫的版本。

為了減少這些在生產環境才會暴露的問題，比較理想的做法是讓應用在開發和生產階段運行在完全一樣的環境中，以便應用程序擁有相同的操作系統、庫、系統配置、網絡環境以及其他所有資源。如果可能的話，我們不希望這個環境隨著時間的推移而變化。同時我們也希望在向服務器部署新應用時不會影響到該服務器上的其他應用。

3.邁向持續交付：DevOps和NoOps

在過去，開發團隊完成應用開發之后會將其交付給運維團隊，然后由運維團隊進行部署和監管。但是現在越來越多的組織開始意識到，由同一個團隊負責應用從開發、部署到運維的整個生命周期會更好。這意味著開發人員、QA和運維團隊之間的合作需要貫穿整個流程。這種實踐被稱作DevOps。

有什么優點？

讓開發人員更多地在生產環境運行應用，能夠使他們對用戶的需求、問題以及運維團隊維護應用時所遇到的問題有一個更好的理解。應用開發人員如今更傾向于更早地向用戶交付應用，然后收集用戶的反饋以作進一步的開發。

為了更頻繁地發布應用的新版本，我們需要簡化部署流程。理想的狀態是開發人員能夠自己部署應用，而不需要交付給運維人員操作。但是部署應用通常需要具備對數據中心底層基礎設施以及硬件架構的理解。開發人員通常不知道甚至不想了解這些細節。

術業有專攻

雖然開發人員和系統管理員的共同目標是成功運行應用并服務于客戶，但是他們也有著不同的個人目標和驅動因素。開發人員熱衷于創造新的功能和提升用戶體驗。他們通常不太關心諸如底層操作系統是否已經更新所有安全補丁這種事情，而是更愿意把這些事交給系統管理員。

運維團隊負責生產環境的應用部署以及底層的硬件基礎設施。他們關心系統安全、資源利用率以及其他對于開發者來說優先級不太高的東西。運維人員不希望處理所有應用組件之間暗含的依賴關系，也不想考慮底層操作系統或者基礎設施的改變會怎樣影響到應用程序，但是他們不得不關注這些事情。

理想的狀態是，開發人員自己部署應用，不需要了解硬件基礎設施，不需要與運維團隊打交道。這被稱作NoOps。很顯然，我們仍然需要一些人來關心硬件基礎設施，但是理想情況下，他們不用再關心每個應用的獨特性。

在后面的學習中，你會看到，Kubernetes能幫我們實現所有這些想法。通過對硬件進行抽象并將其對外暴露為一個單一的平臺來部署和運行應用程序，使開發人員能夠配置和部署自己的應用程序，而不再需要系統管理員的任何協助。這也使得系統管理員專注于保持底層基礎設施運轉正常的同時， 不需要關注實際運行在平臺上的應用程序。

總結

以上是生活随笔為你收集整理的某系统有6台输出设备 有多个进程均需要使用2台_从零开始学K8s: 2.开发与部署方式的演变...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。