從伺服器到雲託管，到底經歷了什麼？

“服務上雲”一直是一個進行時，在2010年-2017年期間，發力點重心都在「自有物理建設」到「IAAS基礎設施即服務」，各個雲廠商都在此基礎上推出網路產品、資料庫產品、儲存產品，提供「PAAS」層面的產品來促進上雲的過程，我們稱為“服務上雲1.0”

“服務上雲1.0”本質上就是將自建的物理服務設施遷移到雲廠商提供的服務設施，並配備了一大批專業的工具。但在這一過程中，內在的關於開發者所選的服務技術架構，卻很少干預觸及；目前大部分流通的都是傳統服務架構模式。

傳統服務架構模式是什麼，有什麼特點？這裡舉幾個例子大家感受一下：

a. 使用本地檔案系統來持久化儲存，資料檔案和應用的檔案混合在一起。

b. 在同一個伺服器上執行很多服務，比如 MySQL、Redis 、Nginx 以及一大堆定時任務。

c. 使用大雜燴式的指令碼和手工流程進行安裝和升級。

d. 配置是儲存在檔案裡的，通常散落在多個位置，並與應用的檔案混在一起。

e. 程序間的通訊是藉助本地檔案系統進行的（比如在磁碟上放一個檔案，另一個程序來讀取），而不是TCP/IP。

f. 按照單個伺服器上只執行一個應用的例項的方式來設計的。

這些特點會在執行維護的過程中暴露出很多問題，比如：

a. 自動化部署很困難，雖然可以通過各種工具來實現，但仍有很大的水分空間存在。

b. 如果需要執行應用的多個不同的例項，很難讓多個例項在同一個伺服器上同時存在。

c. 如果伺服器停機，由於需要手工流程所以需要較長的時間來恢復。

d. 部署新版本的過程基本是手動的，或者大部分是手動的，難以回滾。

e. 很有可能測試環境與生產環境有較大差異，導致一些生產環境問題不能在測試期間發現。

f. 很難通過增加新的例項來進行橫向擴充套件。

這些問題會隨著業務的發展日益突出，最終極大的消耗人力成本，也累積了很多風險因素，即使服務設施上雲，有強大的環境，內部系統的維護問題始終阻礙和影響高質量的服務。

容器技術，規避了傳統服務架構模式所帶來的問題，作為一種新的架構模式開始在近幾年興起。

容器服務，就是通過標準化方式，將業務程式碼和其所依賴的環境資源一起打包成為映象，然後在伺服器中啟動一個例項執行這個映象，就可以提供服務了。

比如你去網咖工作，使用網咖的純淨系統，需要安裝自己所需要的辦公軟體才能夠開始正式工作，這裡就類比你在傳統模式下需要根據服務設施的不同來進行鍼對性運維，才能夠把自己的業務專案執行起來。 容器服務在這個例子中就是，你帶了一塊硬碟（或者一個U盤），將你的辦公系統儲存在其中，到網咖裡直接插入你的硬碟，就可以立刻使用熟悉的系統了。

我們總結容器技術的幾個特點：

a. 部署容易，可以使用新的容器映象直接替換整個老版本。

b. 自動化部署也相對容易，可以完全由 CI 來驅動。

c. 部署失敗時的回滾只要切換到之前的映象就行，非常方便。

d. 應用升級不需要去考慮複雜的升級配置流程，不必執行繁瑣的步驟。

e. 相同的容器映象可以在不同的環境中充分測試，再直接部署到生產環境，確保測試環境與生產環境完全一致。

f. 系統更容易從宕機中恢復，因為可以迅速在新硬體資源上啟動裝有這個應用映象的新容器，並附加到同一資料來源上。

g. 開發人員能在本地以容器的形式，在更逼真的環境裡測試新功能。

h. 硬體資源的利用更高效，在單一主機上可以執行多個容器應用。

i. 容器化是支援零停機升級、金絲雀部署、高可用和橫向擴充套件的堅實基礎。

容器技術和Docker到底是什麼關係？Docker是構建容器的技術工具，是目前流行的。就好比安卓和IOS（Docker）是手機終端作業系統（容器技術）中比較流行的，因為流行，所以各個廠商都會適配，使得技術方案可以暢行無阻沒有門檻。 當我們構建的服務越來越多，同一個服務因為併發可能包含多個容器例項，那麼如何有效的管理協調多個容器的位置資源？如何處理容器與容器之間的通訊？這就需要容器編排技術。

Kubernetes是目前最流通的容器編排技術，提供API來控制容器的執行方式和位置，操作執行Docker容器和調節工作負載，解決在調整跨多部伺服器部署多個容器規模時的一些複雜作業。

我們來看一下標準的容器服務需要的配置，其適用於對容器編排非常熟悉的團隊使用，可以靈活配置，按照自己的需求來調整