實戰訓練營：傳統分佈式架構如何進行容器化升級

前言：隨着以Docker爲典型表明的容器化理念逐漸興起，衆多的使用分佈式架構的公司和企業，開始考慮對原有系統進行容器化升級。傳統分佈式架構爲何須要容器化？容器化面臨怎樣的機遇與挑戰？做爲智能大數據服務商的個推如何將容器化落地？將來將有怎樣的發展？本文以個推在容器化上的實踐爲例，與你們一塊兒探討及展望。

傳統分佈式架構的特色

傳統分佈式架構系統，通常具備如下兩個特色：

1、根據業務和資源消耗的不一樣，開發者會對傳統分佈式架構系統進行模塊劃分。例如：根據業務的區分，個推會劃分出不一樣的系統模塊，和手機SDK創建長鏈接的客戶端CM模塊，以及負責消息路由的IM模塊；根據資源消耗的不一樣，個推會將屢次讀寫Redis 和屢次讀寫MySQL的用戶模塊拆開成不一樣的角色。

2、在傳統分佈式架構系統中，相同的角色模塊會有多個實例。這種系統，一方面作到了高可用性，當一個服務器宕機時不影響總體業務。另外一方面，在壓力變大時方便經過擴容提高吞吐率。例如：當偏重Redis讀寫的角色請求較多的時候，系統就只須要擴這個角色的實例。

多年實踐證實，傳統分佈式架構系統具備易拓展、高可靠、高效率、低沉本的顯著優點，但也具備必定的侷限性。

因爲角色模塊紛繁複雜的特性，傳統分佈式架構系統在配置管理、服務資源管理、部署環境等工做中難以經過人工快速地完成。例如：針對每一個業務模塊的不一樣版本，上線前都須要開發者一一作配置修改；當須要修改具體功能時，必然牽涉不少模塊，爲開發者產生大量重複的工單。

那麼，怎樣才能解決這些問題，建立出理想的線上環境和良好的可視化管理系統？這時，咱們想到了容器化。

容器化的機遇與挑戰

容器化可以有效地解決傳統分佈式架構系統的一系列問題。其中Docker和Kubernetes是最經常使用的開源容器引擎和編排工具。

◎Docker

Docker無疑是目前最受歡迎的開源容器引擎。Docker的原理，是將多個應用以及運行所須要的一切環境，都經過集裝箱也就是容器包裝起來，這樣放置就能夠避免不少因不規整而帶來的隱患。例如：Docker能夠有效避免Java環境版本差別、不一樣應用相互影響、使用資源相互競爭等問題。

個推在使用Docker時，沿用了Docker鏡像的分層策略。首先，個推的各個產品線模塊，使用的是各自的基礎鏡像。其次，個推各產品線的服務程序，打在了各自的基礎鏡像層之上，這樣操做能確保各個容器的運行環境互不衝突。

◎Kubernetes

Kubernetes是一個用於容器集羣的自動化部署、擴容以及運維的開源平臺。Kubernetes的理念在於指點每一個集裝箱的擺放，下降服務器資源難度，讓運維管理變得更加簡便。

個推選擇Kubernetes做爲Docker容器編排的工具，主要有兩方面的考量。

1、個推遇到的問題：

版本更新迭代快

應用進程多，服務器資源消耗大

服務器環境不統一

須要推動DevOps

2、Kubernetes的優點：

運維自動化

應用容器一次性構建

計算機硬件資源可以充分利用

編排管理具備突出優點

在應用Docker和Kubernetes的過程當中，個推受益良多，同時也爲個推原有的分佈式系統結構帶來一些壓力。例如：個推系統的原有框架及模塊都須要改動適配；原有系統很是龐大，須要逐步進行遷移；對原有的生態服務必須有所取捨。所以，咱們經過一次落地的容器化實踐來探索這個領域。

個推容器化實踐

在個推的某項目中，咱們進行了一次全程的容器化實踐。

在具體實施前，咱們先肯定總體的架構圖，架構圖包含Kubernetes基本的一些結構。例如：在Master節點部署上，APIserver是整個系統的控制入口，Scheduler負責任務調度、命令下發，Controller Manager則做爲集羣內部的管理控制中心；在Node節點部署上，Kubelet做爲Agent監聽執行該節點的任務，彙報該節點的狀態，而Proxy則負責整個網絡規則的鏈接與轉發。

當具體實踐時，有狀態組件怎樣才能成功部署，內外網如何實現互通，須要怎樣的配置中心，監控怎麼作，都是開發者容易遇到的問題。

◎有狀態組件的部署

在Kubernetes中，存在不少無狀態組件，它們對於Pod的管理都是基於無狀態、一次性的理念。如Replication Controller，它只是簡單地保證可提供服務的Pod數量。若是一個Pod被認定爲非健康 的狀態，那麼Kubernetes就會以很是簡單粗暴的態度對待這個Pod：刪掉、重建、自動擴縮容。這種處理方式一般適用於業務邏輯處理和內存計算型程序。

可是， Kubernetes能夠經過StatefulSet的方式，給Pod提供惟一的標誌，從而保證ZooKeeper、MySQL、Redis等有狀態組件的成功部署和有序擴展。

但在系統中，若是要知足服務的Pod不管被置於何處，數據都要落地到同一目錄的要求，當有狀態組件被放置到容器中時，掛載就確定須要通過網絡。然而，使用網絡捲進行掛載沒有本地掛載可靠，網絡的性能損耗也是高於本地的幾十倍上百倍。同時，這種組件的維護操做並不頻繁，沒有爲運維帶來太多便利。所以，通過綜合考慮，個推沒有將這類有狀態組件放到容器中。

◎內外網絡的互通

內外網絡的互通是容器化過程當中容易遇到的典型問題。個推使用calico進行虛擬地址的分配，因此同個集羣內的網絡能夠實現互通。集羣內的服務訪問外部的時候，能夠直接使用真實的物理地址。集羣外的服務訪問內部的時候，須要經過iproute的方式，將虛擬ip映射到真實ip，才能實現內部服務的訪問。

◎配置中心

關於配置中心，能夠先整理羅列一些需求點，標出重點後逐個去解決。個推這次容器化實踐過程當中重點關注的需求點包括配置中心集羣化，提供WEB界面化管理和權限管理，支持多種環境配置，開發集成簡單，本地有備份等。

在對一系列開源配置中心進行調研後，經過對比QConf、diamond、Xdiamond、disconf、Apollo、mconf以及xxl-conf的各項功能，個推選擇了功能更加齊全的Apollo。

（註釋：調研具備時效性，圖中某些配置中心的最新版本，如今可能已經支持當時還未支持的功能）

◎監控採集

運行在Kubernetes裏的應用程序，容易產生如網絡同外部隔離、生存週期受集羣管理、運行節點不固定等問題。咱們經過對自有的監控系統進行一些調整，好比將主服務部署在Kubernetes集羣外部，在集羣每一個Pod裏面部署Agent，從而實現數據的採集監控並彙報主服務。

容器化的後續展望

最後，個推但願在吸收本次經驗的同時，對將來的容器化實踐有所規劃與展望。例如，咱們能夠考慮從業務監控和擴縮容結合、自動化測試、Stateful服務等方面繼續深刻探索。

業務監控和擴縮容結合，能識別出假死，判斷出業務壓力。自動化測試，經過補充各個業務和模塊的自動化測例，便能在很大程度上節省迴歸測試的成本，更好地實現快速迭代持續交付的目標，是DevOps進程中很是重要的一步。Stateful服務，後續隨着Kubernetes相關技術的發展，可以幫助咱們找到更多合適的容器化方式，從而作到完整的容器化，甚至是雲服務化。

結語：

現階段容器化大行其道，容器化在控制成本、保障服務穩定性、提升工做效率上都有極大的優點，然而傳統分佈式架構卻每每因其基礎組件和架構的定型，增長了容器化轉型的難度，致使船大難掉頭。本文但願經過做者的分享，可以幫助開發者在容器化過程當中更好地理清本身的思路。

須要注意的是，容器化實踐並非爲容器化而容器化，而是在充分理解現有業務需求和解決方案的基礎上，經過容器化提供更高效、更穩定的系統服務，這纔是容器化真正的價值所在。