【下一代核心技術DevOps】：（一）容器服務的Rancher選型

1. 爲何說是下一代核心技術

         其實通過互聯網的屢次變革提及，早期的C/S架構，到後來的B/S架構，一直到如今最廣泛的M/S架構，他們的背後都是技術不斷的優化改進，以適應促進IT技術的發展

         總體而言在過去10年時間，互聯網技術能夠說是以手工製造的方式爲準，相似於傳統銷售，設計，製做，而後打包銷售。每一個環節都須要大量的人員來操做，也須要不斷

         有人接班學習來延續對應的環節。而將來10年將會是以流水線的方式爲主 ，其主要緣由是互聯網雲計算技術的高速發展及可持續快速交付的業務需求。其對應的DevOps

         方式將完美契合。開發運維一體化確切的說是一種方式，而這種方式須要全新的技術來支撐才行執行下去，咱們將之稱爲下一代核心技術。

 

         2. 傳統技術與下一代核心技術區別

         傳統的技術主要問題是高耦合，其耦合存在於服務器，硬件存儲，內外網之間（網絡通信），應用程序之間，代碼之間，業務模塊之間，雖然通過近幾年的發展，在不斷的

         去耦合化大趨勢下，已經儘量的將這幾大塊之間進行低耦合處理，可是因爲傳統技術的限制，沒法從根本上解決這些問題。好比最經常使用的程序鏈接數據庫。傳統的方式多

          將數據庫鏈接字符串寫到程序的配置文件裏，致使其鏈接數據庫IP不能變，多節點部署程序須要一一手動修改數據庫鏈接字符串。很是麻煩，隨着技術的發展優化，有經驗的

          研發人員會將數據庫鏈接放到JNDI裏面（如Tomcat)，由中間件管理，這樣將程序和數據庫之間進行解耦。這也是傳統技術，架構經常使用的作法。可是對於多節點的部署變動，

          須要改變多個節點Tomcat的JNDI配置，仍是存在易用性，可維護性，可靠性方面的問題。固然也有高級別的中間件來集中解決這些問題，如WebSphere的集羣管理，這都屬於

          爲了解決問題而解決問題，受限於傳統技術，沒法從根因上解決各個組件，軟硬件之間的耦合問題。並且須要商業付費，很是的貴。

           下一代核心技術，受益於雲計算，微服務，容器服務的高速發展，採起DevOps的模式進行整合，實現硬件服務器，存儲，網絡，軟件程序，代碼之間的全低耦合甚至0耦合

           將大大提升交付能力，下降運維成本，實現互聯網產品的快速迭代。

 

            3. 容器服務的Rancher選型

           我以前的文章已經對微服務作了基本分析，本章節及後續章節會陸續對雲計算的分析應用和容器服務的分析應用作逐一的講解。 微服務主要是對軟件代碼層面進行解耦，

           雲計算主要從硬件支撐層進行解耦，而容器服務主要從應用層面進行解耦。容器服務的飛速發展，主要是Docker的巨大功勞，將傳統的虛擬化技術帶到一個全新的層面。

           Docker的優點在此不作多講，主要是其原生的管理基於命令行，對於簡單應用較爲方便。可是在DevOps模式下就須要有一整套的規範接口來統一管理整個流水線。對於

           Docker容器的管理系統目前比較流行的有幾個： K8S，Rancher，Shipyard等，其餘還有一些不是頗有名的在此很少作列舉了，你們能夠自行研究學習。

內容	原生	K8s	Rancher	Shipyard
管理端及易用性	Docker EE （易用性★★★）	K8s管理（易用性★★）	Rancher（易用性★★★★☆）	（易用性★★★★）
引擎/編排工具	Swarm	Kubernetes	Cattle、Swarm、Kubernetes、Mesos，Windows	無
多主（集羣）	支持	支持	支持	不支持
資源看板	★★★	★★	☆	★★★★
DevOps集成	不支持	插件支持	插件支持、原生支持	不支持
插件數量	★	★★★	★★★★	不支持

          通過對比試用選型，在容器管理考慮到易用性包括跨主機通信的管理，DevOps的支持力度等方面，Rancher以各方面優先勝出。Rancher目前在開源社區很是火爆，支持衆多

          的編排引擎，當前最新版本爲 1.6.12  ，你們能夠下載試用。