電信行業的容器化改造之道
市場變局
近年來，傳統電信運營商正迎來一個最具挑戰的時代。曾為電信運營商帶來高利潤收益的業務規模正不斷縮水；曾以引為傲的管理模式、業務推廣模式也漸漸成為運營商變革的核心。外有OTT廠商入侵，內有虛擬運營商競爭，隨著一個業務應用上線時分秒必爭來滿足不同群體需求以此快速占領市場的新時代的到來，傳統運營體系已然很難匹配這一市場變化，運營體系重構也必將重建。
語音業務逐漸被數據業務所代替。運營商的網絡從90%以上都是語音業務，到今天變成了80%的業務被數據所主宰。但在這一過程中，運營商尚未建立行之有效的盈利模式;為運營商帶來巨大利潤的語音業務正從收費高的語音通道轉向低價的數據通道，如微信等。運營商被“管道化”的趨勢日益凸顯。
語音為王的時代，三大運營商的競爭更多來自內部。移動互聯網時代，運營商需要面對來自互聯網廠商日益激烈的競爭。話音時代，運營商長期在圍墻之內，進入移動互聯時代，圍墻一下子沒有了，運營商如何直面和適應激烈的競爭環境是個全新的挑戰。
此外，云計算和大數據時代來臨， 運營商的傳統核心能力越來越邊緣化 。目前，從云計算、大數據獲得的收益僅占到中國運營商不到1%的收入，遠遠低于外國同行。這與中國運營商重電信而輕IT不無關系。以網絡為主導的運營商內部存在著大量優秀的電信人才，但優秀的IT技術人才卻是稀缺資源。導致運營商的IT系統仍局限于支撐功能的定位，無法為處在激烈的競爭環境中的運營商提供有效的轉型戰略支持。
行業趨勢
電信公司在技術領域是一個保守和激進的綜合體，在互聯網巨頭出現之前，電話通信交換網絡及其計費系統已經承擔了最大的任務量。電信公司對網絡技術不斷投入，以確保整個網絡的高可用。這其實占據了大量的資金，并產生了許多閑置——低利用率的計算和存儲資源，最終帶來了整個運營的低效率。
我們認為，未來電信行業必然是一個IT、CT融合，電信運營商互聯網化的趨勢，IT所占比重會越來越大，電信行業的盈利模式也會從傳統的提供通道到提供IT資源、提供服務的方向轉變。近幾年隨著大數據、云計算、容器化、微服務、平臺戰略等新技術和新概念的層出不窮和快速發展，在業務支撐、架構能力、平臺擴展性等方面對舊有的煙囪式建設的業務支撐系統提出了巨大的挑戰。因此對現有業務和設備進行容器化改造，則成為了一個必然的選擇。
容器化的優勢
容器技術作為目前一項炙手可熱的新技術，具有以下優勢：
- 極其輕量級的虛擬化技術，大大提高IT資源的利用率；
- 標準化的打包、封裝、搬運機制，有效提高開發運維效率，降低成本；
- 秒級啟動速度，保障業務的穩定性與高可用性；
- 類似于積木的分層機制，提供靈活組合微服務；
- 簡化開發版本管理。
關于微服務
另外一個不得不提的概念是微服務。微服務架構是一種特定的軟件應用程序設計方式——將大型軟件拆分為多個獨立可部署服務組合而成的套件方案。雖然這種架構風格的確切定義還未統一，但并不妨礙其在眾多企業的實際應用中被實踐，并體現出了具備通用特征的業務功能、自動化部署、端點智能化以及對語言與數據的離散化控制能力。
許多如Amazon、eBay、NetFlix等公司都采用微服務結構模式，都在嘗試改進那些需要頻繁更新的，通過網絡提供到用戶的PC、平板和智能手機上的應用程序和服務的持續交付，將應用分解為小的、互相連接的微服務，而不是開發一個巨大的單體式的應用。一個微服務一般完成某個特定的功能，比如下單管理、客戶管理等等，都有自己的業務邏輯和適配器。一些微服務還會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI，運行時每一個實例可能是一個云VM或者是Docker容器。這種微服務架構模式深刻影響了應用和數據庫之間的關系，不像傳統多個服務共享一個數據庫，微服務架構每個服務都可能有自己的數據庫。
Docker 作為一種開源的應用容器引擎，幫助開發者將他們的應用以及依賴打包到一個可移植的容器中，便于應用的部署和擴展。而隨之產生的微容器概念和微服務正好相輔相成，通過 Docker 封裝的應用可以輕松運行在以擴容能力見長的云計算平臺上。
圍繞著云托管環境的如此多的應用程序和服務部署活動，微服務架構已經深度依賴于容器化技術的使用。容器將微服務進程和應用程序隔離到更小的實例里，這些實例僅僅使用虛擬化了的操作系統，而不是整個虛擬機以及VM所包含的整個抽象硬件資源。
微服務不是Docker，但Docker天然是為實現微服務而存在，利用Docker技術可以很方便的對宿主機資源進行隔離、劃分，同時因Docker本身極其輕量化的特點，可以做到宿主機的高密度、高可用性、高彈性的應用，從而做到IT資源利用價值的最大化。
電信企業容器化改造的幾點考量
結合行業經驗，我們認為電信企業容器化改造需要考慮的因素包括：
- 業務層面 ：因運營商對業務的穩定性和連續性有比較高的要求，故容器化的演進路徑必然是從邊緣業務到核心業務，從簡單應用到復雜應用，具體到業務，首先可以考慮在Web前端進行容器化遷移，第一步選擇某些相對獨立的，不涉及BOSS系統的模塊，如網上商城等，第二步逐漸切入到一些涉及用戶數據的非核心業務如積分兌換等，最后遷移與用戶計費直接強相關的業務，如業務套餐辦理等。
- 技術層面 ：目前原生Docker在服務發現、負載均衡、容器生命周期管理、容器間網絡、存儲等方面還存在諸多的不足，因此目前有許多第三方廠家提供的開源解決方案和商業化版本，如Google的Kubenetes、Apache的MESOS、Rancher等，各家方案各具特色，難分高下，當然僅從容器編排引擎的角度來看，Rancher可以兼容Kubenetes、MESOS和Docker SWARM著幾種主流的編排引擎。是固定技術體系框架，還是選擇靈活兼容的模式，是需要慎重考慮的因素之一。
- 兼顧到成本效益 ：綜合考慮容器化付出的成本代價與未來收益之間的平衡。傳統的短信、彩鈴以及客服中心業務因本身業務在萎縮，因此不太建議進行容器化。
- 還要考慮 現有硬件的負載能力 問題，容器化并非包治百病的良藥，某些對并發吞吐量要求更高的業務，直接運行在裸機上，通過系統調優提高性能，容器化未必是最好的選擇。
容器化過程中的注意事項
運營商傳統業務網絡經過多年建設運營，業務模式涵蓋了交易、計費、服務等各種核心業務，系統功能各異復雜度高，并且多個廠商多種系統并存，這些成為容器化遷移的一大障礙。摸清這些系統之間的架構關系，避開不必要的坑，是容器化之前就需要做的工作。
在底層架構考慮方面主要需要考慮操作系統、數據庫等平臺軟件之間的兼容性問題，另外需要考慮收費軟件廠商的支持力度、License管理政策是否允許容器遷移。
雖然Docker以及微服務看起來很美，但是要真正的實施落地，除需要足夠的人才技術儲備，還對運維團隊的自動化流程也提出了更高的要求和挑戰。容器化改造之后，一臺宿主機上運行的容器可以成千上萬，如何對這些容器的故障進行維護，需要對原有的運維流程和團隊進行更新升級以適應新的業務情況。所以選擇專業的產品化的容器技術廠商不失為探索過程中的有力保障。
答疑環節
問：電信行業的容器化與其他行業有何區別？
張鑫：電信行業相對其他行業，IT信息化程度較高，在技術領域是一個保守和激進的綜合體，在互聯網巨頭出現之前，電話通信交換網絡及其計費系統已經承擔了最大的任務量，但近年來，曾為電信運營商帶來高利潤收益的業務規模正不斷縮水；曾以引為傲的管理模式、業務推廣模式也漸漸成為運營商變革的核心。
外有OTT廠商入侵，內有虛擬運營商競爭，語音業務逐漸被數據業務所代替。運營商的網絡從90%以上都是語音業務，到今天，80%的業務被數據所主宰。但在這一過程中，運營商尚未建立行之有效的盈利模式;為運營商帶來巨大利潤的語音業務正從收費高的語音通道轉向低價的數據通道，如微信等。運營商被“管道化”的趨勢日益凸顯。
傳統運營商長期在圍墻之內，進入云計算、大數據、移動互聯時代，圍墻一下子沒有了，運營商如何直面和適應激烈的競爭環境是個全新的挑戰。
問：Rancher與同類容器管理平臺相比有何優勢？
張鑫：Rancher的解決方案設計時就考慮了同時支持虛擬機和容器，而這種實現方式在Google被驗證過，并進行了大規模部署。從2015年4月開始，在 RancherVM項目中已經嘗試了這個方案，并從很多用戶那邊得到了非常好的反饋。在容器中運行虛擬機的好處是可以使用相同的工具來同時管理虛擬機和容器。事實上由于虛擬機和容器的行為方式非常類似，Rancher 為Docker容器所開發的Rancher CLI 命令行和UI圖形界面完全可以無縫地適用于虛擬機。
另一方面通過使用 RancherOS做為融合基礎架構平臺的基礎操作系統。RancherOS的內核被編譯成可以完美支持各種虛擬化平臺。
問：Rancher是基于哪些技術實現，與k8s有何關系，相比其他容器集群管理技術有哪些優缺點？
張鑫：Rancher是基于Cattle調度編排框架，而K8S是一個Docker容器的編排系統，它使用label和pod的概念來將容器換分為邏輯單元。Pods是同地協作（co-located）容器的集合，這些容器被共同部署和調度，形成了一個服務，這是K8S和其他框架的主要區別。相比于基于相似度的容器調度方式（就像Swarm和Mesos），這個方法簡化了對集群的管理。
由于Swarm的原生API，基本上實現了各家編排引擎的核心功能，尤其是內置到Docker Engine中的作用是巨大的。在集群維護和節點管理方面Swarm的確天生就比較優秀，畢竟是采納百家之長，但是真正落到應用管理和服務編排方面，Swarm仍有一些路需要走，而Cattle與Rancher其他組件的融合已經達到了“開箱即用”的水準。
此外，Rancher與其他同類容器平臺相比，部署比較簡單，用戶無需了解Mesos、K8S的架構和細節，Rancher可以快速方便的一鍵部署和升級；
Rancher和底層基礎架構集成良好，如Rancher部署的K8S默認和Rancher的overlay網絡，Rancher-dns，Rancher的負載均衡都進行了集成，方便用戶使用；Rancher-catalog應用編排層面的集成也較好。
問：電信行業使用容器怎么做好安全？
張鑫：容器的確也存在不足，如無熱遷移，網絡隔離性、安全性支持比較薄弱，Docker發布libnetwork增強網絡特性，很多項目也在致力改善容器網絡。電信行業容器化的演進路徑必然是從邊緣業務到核心業務，從簡單應用到復雜應用。
問：電信行業使用容器的自動化測試有什么實踐？
張鑫：目前一些地方運營商正在做進一步POC測試和業務部署，相信很快從集團和地方層面就會有實際應用。
問：電信業務最終落地到Docker上的是什么業務？相對應的規模是怎樣？
張鑫：因運營商對業務的穩定性和連續性有比較高的要求，故容器化的演進路徑必然是從邊緣業務到核心業務，從簡單應用到復雜應用。具體到業務，首先可以考慮在Web前端進行容器化遷移，第一步選擇某些相對獨立的、不涉及BOSS系統的模塊，如網上商城等；第二步逐漸切入到一些涉及用戶數據的非核心業務如積分兌換等；最后遷移與用戶計費直接強相關的業務。
問：電信行業一直在提NFV，容器化能夠很好的支持NFV么，有沒有相關的應用實例？
張鑫：NFV主要還是涉及到網絡虛擬化，容器里目前涉及不是很多。
問：這會不會限制容器技術在電信業的應用？現在各家廠商貌似都在發力NFV，一旦相應的技術方案成型，會不會使得容器化很難做到電信的數據層面？
張鑫：一個新技術的興起和發展，主要還是在于新技術本身的優勢特點、以及給行業客戶帶來的價值，有些技術可能是并存，或者是作為補充。電信行業一般還是愿意創新和敢于嘗試新技術，所以應該還是能做到電信數據層面的，當然也要看推進的方法。
問：容器化改造目前能夠達到什么程度，穩定性怎么樣？會不會容易與一些方面發生沖突，有沒有一些更好的方法將bug控制在很小的范圍？系統如果遭到攻擊那么會不會導致數據丟失，有相關的安全措施嗎，比如定制版本的安全軟件？
張鑫：容器化改造目前還是提升客戶系統效率，降低硬件采購成本，這一點對客戶帶來的價值還是很大的。由于是開源平臺，參與貢獻者較多，版本更新較快，一些bug也會很快解決。
容器只是一組進程，其隔離性不如虛擬機好，如果主機意外掉電有可能引起數據丟失，但是任何安全都是相對的，攻擊的類型也有很多，不能一概而論。
問：運營商有沒有在電信業務上使用容器的案例？電信業務的核心是管道、數據搬運，所以轉發性能非常關鍵，容器技術在這方面有優勢嗎？
張鑫：目前主要是在poc階段，很快就有案例。移動、電信都在推進，具體內容就不方便說了。轉發性能應該是針對路由交換，容器強調的是并發性。
來自：http://www.infoq.com/cn/articles/container-transformation-in-telecommunication-industry