PaaS時代來臨，運維人要做哪些準備工作
作者簡介
余何，在運維領域耕耘十余載，07年加入到平安集團旗下的科技公司。2011年，主導集團內***的應用遷徙與架構變更；2012年開展IT運維管理變革，打通橫向條線，實現(xiàn)技能融合。光陰荏苒，日月如梭，運維往事歷歷在目，流過汗，熬過夜，攤過事，也拿過獎，運維是一個從無到有、日積月累、不斷提升的過程，也是一個需耐得住寂寞，頂?shù)米毫Φ男挟?，在此與正奮斗在運維一線的伙伴們共勉。
“工作不代表你，銀行存款不代表你，你開的車也不代表你，皮夾里的東西不代表你，衣服也不代表你，你只是平凡眾生中的其中一個。”
————電影《搏擊俱樂部》
前言
運維人員在忙碌的工作中要面對各種“新概念”潮汐般地沖擊，他們不得不放下精細化的腳本編程，丟下原生態(tài)的性能調優(yōu)方法，隨大流的淹沒在這瞬息萬變的“新時代”，運維水準的高低與這些新概念也扯上了關系，久而久之我們居然忘了運維的本質是什么。
運維到底需要什么
看看我們每天所做的，都是為了一個共同目標，讓應用快速上線、穩(wěn)定運行！那些廣告術語：“彈性擴容、自助服務、按需分配”，以及“成本減少多少，效率提升多少”之類的陳詞濫調與你并沒有太多關系，不是嗎?
實際上所有一切都是圍繞著應用開展的，應用自身決定了快速而穩(wěn)定的80%！面對一個龐大的、遺留的、冗余的、配置雜亂的CRM系統(tǒng)、ERP系統(tǒng)，無論外來新概念如何流弊也解決不了你任何問題，你唯一的出路是好好理解這個系統(tǒng)。
通過一些自動化腳本盡量的減少一些重復性工作，或者你強勢的要求開發(fā)人員改造整個系統(tǒng)，采用全新的應用部署架構，但這又是公司層面問題。重要的事情再說一遍，關于自動部署、快速擴容方面，應用自身決定了80%。如果我們還不明白這一點，而迷信于什么互聯(lián)網(wǎng)神器，那終將無功而返。
它可以給你什么
在基礎架構引入虛擬化后，關于云的暢想一下子被點燃了，讓我看看下面的圖里：
云暢想
姑且讓我們將虛擬化的引入定義為Cloud 1.0，這個時期將物理服務器資源拆解為隔離的虛擬計算單元提供給不同用戶。對于不那么挑剔的用戶，我們完全可以在一臺物理服務器上的OS中提供多個服務給他，這肯定比虛擬化的資源使用率要來得高，但是，我們(運維人員)無法決定與控制應用特性，也就無法避免同一個OS中應用間的干擾，如此一來虛擬化的引入幫助我們解決了大問題。
對于中小企業(yè)停留在Cloud 1.0就足矣，而對于大型企業(yè)、互聯(lián)網(wǎng)企業(yè)，他們很快發(fā)現(xiàn)其所管理的計算資源陡然上升。亞馬遜Amazon率先將這種虛擬化資源商業(yè)化，通過集中管理界面對外兜售，而開源領域Openstack與各虛擬化組件集成，勢必統(tǒng)一行業(yè)標準。
無論是公有云還是私有云，在這一輪Cloud 2.0的戰(zhàn)役中，***的改變是組成了一個更大的虛擬化池，將虛擬機的資源申請、配置管理、服務計費等用另外一種方式加以呈現(xiàn)。而關于虛擬機(OS)之上的東西和以前并無太多差別。是的，亞馬遜Amazon的公有云，他將平時“閑置”的資源兜售給了外部用戶，國內大型“云”提供商，他們很可能是戰(zhàn)略性的“占領”未來行業(yè)市場。
至于大多數(shù)企業(yè)內部的私有Cloud 2.0，則情況又完全是另一番景象。限于這個階段大部分工作是重新梳理了一種配置管理、資產(chǎn)管理以及服務定價的方式，讓我們將Cloud2.0定義為Resource-centric。
事物的發(fā)展總是向前的，盡管在發(fā)展道路上常會偏離軌道，但總將回歸本位，運維的本質是讓應用快速上線、穩(wěn)定運行，對于一個應用本身高度可控的企業(yè)，它們選擇了更進一步，讓應用適應平臺，在公有、私有IaaS上構建Application-centric的Cloud 3.0，亦即PaaS。
在公有、私有IaaS上構建PaaS
PaaS運維服務的本質
PaaS并不是解決一切問題的靈丹妙藥，它專屬于特定領域，這個領域與應用部署架構、業(yè)務場景等緊密相關。如果你發(fā)現(xiàn)組織中有大量需要互聯(lián)網(wǎng)化的應用場景，它們大部分集中在渠道領域，要求應用加快測試、發(fā)布效率，要求隨時進行快速擴容，那么我們可以考慮構建自己的私有PaaS，它可以管理公、私有IaaS資源(虛擬、物理)。
PaaS在業(yè)界的標準并未統(tǒng)一，而充分發(fā)揮PaaS優(yōu)勢的很大一部分決定于應用部署架構。如果你有一個時髦的開發(fā)團隊，他們遵循去中心化、異步消息通信、無狀態(tài)等原則部署應用，那么你可以輕松的將其推送到PaaS。反之，如果有著一大堆跑在Window操作系統(tǒng)上的窗口應用，好吧！PaaS再神奇也于事無補。
至此，讓我們看看在OS之上，運維服務要解決的問題：
1.資源分配
我們大部分時間在進行資源分配，將服務器、存儲、操作系統(tǒng)以及軟件等分配給應用，工作的復雜性圍繞著應用而產(chǎn)生。
2.應用部署
將開發(fā)兄弟提供的業(yè)務邏輯放到我們所分配的資源中去。
3.服務發(fā)現(xiàn)
如果讓用戶找到這個服務，如何讓服務于服務之間可以互訪問。通常的做法有負載均衡、域名解析、配置消息中心等方式解決服務發(fā)現(xiàn)問題。
4.監(jiān)控巡檢
監(jiān)控巡檢是運維之必須，在此不再累述。
在這里，我們討論前三項，資源分配、應用部署于服務發(fā)現(xiàn)。
PaaS平臺功能設計
為了能夠實現(xiàn)PaaS平臺，我們需要保證運維的四個主要工作內容實現(xiàn)自動化，下面這些功能全都是圍繞著實現(xiàn)這個目標而引入的。
1.計算單元打包
虛擬機鏡像、配置管理工具(puppet、saltstack、ansible)所負責的任務就是將應用邏輯計算單元進行打包。計算單元包含了運行業(yè)務系統(tǒng)的全棧組件，其涵蓋了操作系統(tǒng)、中間件、依賴包等。
PaaS平臺中，我們選擇Docker替換原有的方式，作為一個輕量級容器，它比虛擬機更加節(jié)約資源，同時可以基于一份軟件介質運行多個實例，Docker的倉庫、鏡像與容器三元素讓應用邏輯計算單元大大得到了簡化。
誠然，ansible這類軟件配置工具已經(jīng)非常輕巧、快捷，并且滿足95%以上的需求，但當決定將PaaS構建在跨IDC、跨第三方數(shù)據(jù)中心時，基于鏡像的分發(fā)能夠更加穩(wěn)定的滿足我們需求。Docker也有其缺點，例如不支持32位平臺，不支持windows服務器。
Docker+Ansible 完成計算單元打包
2.資源動態(tài)分配
與Cloud 2.0的IaaS不同，用戶并不關注如何獲得CPU、內存、存儲資源。他們僅關注自身應用計算邏輯的運行，他們希望資源是動態(tài)分配、彈性擴容的。
數(shù)據(jù)中心需要一個統(tǒng)一的資源管理者，它將所有資源(無論虛擬、物理)抽象成一個整體，如同一個數(shù)據(jù)中心操作系統(tǒng)。這種資源的抽象不僅僅要滿足服務型計算，還要滿足大數(shù)據(jù)時代的MapReduce計算，以及今后的各種類型計算，這意味著資源分配與任務調度兩部分功能是解耦的。
在分布式資源管理領域，主流的選擇是Mesos、YARN。
◆ Mesos：Mesos最早由美國加州大學伯克利分校AMPLab實驗室開發(fā)，后在Twitter、Apple、Netflix等互聯(lián)網(wǎng)企業(yè)廣泛使用，成熟度高。
◆ YARN：Apache Hadoop YARN是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統(tǒng)，可為上層應用提供統(tǒng)一的資源管理和調度。
其他的選擇還有Kubernetes、CloudFoundry、OpenShift等方案，但這幾種不滿足資源分配與任務調度解耦，對應用規(guī)則要求太高，并不容易兼容現(xiàn)有應用。在我們環(huán)境選擇了Mesos，其獨有的靈活性保證了支持更多類型的上層分布式計算應用。
Mesos 分布式資源管理
數(shù)據(jù)中心OS
3.任務調度功能
任務調度器與資源管理器的***不同在于其要對運行中的應用服務負責，包括啟動、停止服務，監(jiān)控服務以及在服務失效時的故障轉移。最初的分布式架構設計中，人們常常模糊了作業(yè)調度與資源管理二者間的界線。
其一是分布式平臺是為某一專屬計算類型服務，例如Hadoop平臺為MapReduce計算類型服務。
其二，作業(yè)調度與資源管理的交互頻度高，合二為一后的效率更高。但隨后人們發(fā)現(xiàn)資源管理器的功能是相對穩(wěn)定的，而作業(yè)調度因為計算類型多。
并行計算有MapReduce、Stream，普通計算有Service、批處理等，每一種計算類型的作業(yè)調度方式完全不同，如果將資源管理器與作業(yè)調度器綁定在一起則會失去分布式平臺的計算靈活性。
是以Mesos為核心，支持多領域的分布式集群調度框架，包括Docker容器集群調度框架Marathon、分布式 Cron(周期性執(zhí)行任務)集群調度框架Chronos和大數(shù)據(jù)的主流平臺Hadoop和Spark的集群調度框架等，實現(xiàn)系統(tǒng)的資源彈性調度。
Mesos架構示意圖
對于服務型的長任務，我們選擇Marathon作為其任務調度器。
Marathon任務調度
4.服務發(fā)現(xiàn)功能
服務發(fā)現(xiàn)有兩種形態(tài)，一種是用戶(人)來訪問的，一種是應用之間互調的，對于前者需要保持一個穩(wěn)定的入口(不變)，而對于后者，如果在一個寬松的環(huán)境里，是運行變化，并接受變化通知的。而對于長服務型計算類型，除了解決服務發(fā)現(xiàn)外，還要考慮將任務分發(fā)到多個節(jié)點，亦即負載均衡問題。
服務發(fā)現(xiàn)上可選的有通過動態(tài)寫入DNS系統(tǒng)來滿足用戶需求，通過zookeeper之類的分布式協(xié)調系統(tǒng)充當配置中心通知外部系統(tǒng)。而在負載均衡上，企業(yè)級的專用設備，例如F5等都提供了API接口以供調用，而開源軟件上通常采用Haproxy。
通過zookeeper實現(xiàn)服務發(fā)現(xiàn)
Marathon的Haproxy服務發(fā)現(xiàn)方案
5.日志集中管理
在一般情況下，日志以文件的形式存放在本地操作系統(tǒng)上以供查詢，而在分布式系統(tǒng)中，計算單元不會再固定于一個物理節(jié)點上。如果日志仍以文件形式存放在本地，隨著計算單元的漂移，日志將留存在與計算單元沒有關系的物理節(jié)點上。對于系統(tǒng)管理人員、運營人員來說，日志查詢檢索將變成一門繁雜工作。
在分布式平臺上構建集中的日志管理平臺，將各種類型的日志收集、索引好，以消息的形式看待每一條日志將成為分布式平臺上的一個重要功能。采用開源社區(qū)流行的ELK組件(elasticsearch、logstash、kibana)，我們會看到如何將所有節(jié)點的日志導入到一個集中平臺進行可視化管理。
elastic日志集中管理
PaaS下的運維發(fā)展之路
PaaS時代的來臨，對運維職業(yè)發(fā)展將產(chǎn)生深遠影響，一個嚴重的誤區(qū)是認為云計算將徹底取代運維行業(yè)，實際上在IT發(fā)展的過程中，對運維的要求在不斷提高。云計算、大數(shù)據(jù)、物聯(lián)網(wǎng)以及移動互聯(lián)等無一不是這個時代向前發(fā)展的標志， 只要IT越貼近用戶，就會產(chǎn)生更多的數(shù)據(jù)、發(fā)現(xiàn)更多的需求，運維則愈加之重要。
運維職業(yè)發(fā)展的三個硬道理是：
1.不變應萬變
要做到不變應萬變，就必須掌握業(yè)內最基礎、最穩(wěn)固的知識點，打下結實的基礎。相對于開發(fā)應用框架、前端UI的變化，存儲、計算、網(wǎng)絡三大資源知識是非常穩(wěn)固的，即便是變化也一定是建立在基礎原理之上。
互聯(lián)網(wǎng)變化之快，新技術層出不盡，運維人員不能太過于跟風，一定要看清事物背后的本質，與基礎原理相聯(lián)系，深入底層內部思考，這樣才能做到萬變不離其宗。以Linux操作系統(tǒng)為例，運維人員并不需要將所有發(fā)行版的安裝、命令等背誦入流，而是精通一到兩種，并通過操作系統(tǒng)的運行原理來解釋一切問題。
2.精通編程
不會編程的運維人員不是好運維，在開源風潮涌現(xiàn)的年代，可以預見未來對運維人員的開發(fā)能力要求會非常之高。系統(tǒng)開發(fā)與應用開發(fā)在完全不同的兩個維度，系統(tǒng)開發(fā)更貼近于底層，掌握程序的運行原理對編程能力的提升有極大幫助，例如可執(zhí)行文件的結構、在內存中的形態(tài)等。
運維人必須精通一門編程語言，參與到社區(qū)，品讀開源代碼，養(yǎng)成編程習慣。引用Linux之父Torvalds的一句話“just for fun” ，這是運維人看待編程應保持的心態(tài)。
3.敏銳觀察力
時代依然在不斷變化，運維人雖不必立即掌握每一項新出爐的技術，但他們必須保持對行業(yè)的關注度。預留一些時間給自己閱覽社區(qū)新聞，積極參加線下社區(qū)活動，隨著新技術的成熟以及自己的個人興趣，在新興領域投入必要的時間。
Larry Wall是Perl語言的設計者，他屬于運維鼻祖，也就是系統(tǒng)管理員。當時Larry遇到了一個問題，如同我們現(xiàn)在遇到的一樣。他需要在繁雜的內容中萃取文本信息，而手頭的工具只有awk和shell這些工具可以幫助解決問題。
這些工具用起來卻是那么痛苦，Larry太懶了——如果用awk來做的話，要做大量工作，這讓他無法忍受；Larry也太急躁——awk做起來很慢，他可等不及；最終他的高傲促使他完成了一件壯舉，設計一門新語言——Perl，造福整個社區(qū)。是的，你會發(fā)現(xiàn)運維時代在變，但同樣的故事還在發(fā)生，你是否已做好準備?
