DevOps困局

開發(fā)、運維之間的“困局”很快引起了一陣DevOps風(fēng)，大家都厭惡了在基礎(chǔ)資源上的等待，厭倦了重復(fù)、枯燥的人工運維，為了按時交付軟件產(chǎn)品和服務(wù)，開發(fā)人員和運營人員必須緊密合作，他們希望能夠形成一套方法論，通過可編程方式來管理和控制基礎(chǔ)架構(gòu)資源，輕松、愉快地解決問題。
DevOps定義了如下明確的目標：

更小、更頻繁的變更意味著更少的風(fēng)險；
讓開發(fā)人員更多地控制生產(chǎn)環(huán)境；
更多地以應(yīng)用程序為中心來理解基礎(chǔ)設(shè)施；
定義簡潔明了的流程，盡可能地自動化；
促成開發(fā)人員與運營人員的協(xié)作；

部分開發(fā)人員轉(zhuǎn)到DevOps的實現(xiàn)工作中，特別是全面自動化運維工具的實現(xiàn)工作。Chef、Puppet、Saltstack等DevOps工具陸續(xù)出現(xiàn)，它們有一致的中心控制-代理的應(yīng)用架構(gòu)，提供了一套可移植、去差異、管理成千上萬臺服務(wù)器的方法。但在可移植性上，必須重新定義一門抽象的語言來覆蓋原各個OS平臺。應(yīng)用升級、文件替換、版本部署等運維操作都可以通過這門語言組合到一個模板中，從而實現(xiàn)復(fù)用、快速交付。開發(fā)人員被告知有越來越多的工具幫助我們快速交付，但運維工具的新語言本身又帶來了復(fù)雜性。誰對這組語言模板負責(zé)，到底是開發(fā)人員還是運維人員？如果是運維人員來負責(zé)，那么僅僅做到了自動化，由于受標準化程度及運維工具本身的復(fù)雜度影響，在不同環(huán)境下的效率和收益會截然不同。而如果是開發(fā)人員負責(zé)，那么他們還需要花很長的時間去掌握一門運維“語言”來實現(xiàn)自動化，在模板、腳本執(zhí)行過程中發(fā)生的任何問題，最終還是要輾轉(zhuǎn)到運維人員處，問題貌似又回到了原點。

DevOps的十字路口

開發(fā)與運維在兩條完全垂直的線路上運行工作，Dev從項目角度出發(fā)，垂直向下。Ops從運營角度筆直向前，他們的交匯處是應(yīng)用版本的發(fā)布，最終的結(jié)果是一個完整可用的系統(tǒng)提供給用戶。

IaaS 幫助有限

云計算是近年來的熱點話題，實際上它僅僅是一種面向服務(wù)的理念，它將原本分散在全球各地的IT資源集中起來，通過虛擬化、分布式、多租戶、自助服務(wù)、自動計費的方式遞送給用戶。云計算很巧妙地將服務(wù)模型劃分為IaaS（基礎(chǔ)設(shè)施即服務(wù)）、PaaS（平臺即服務(wù)）、SaaS（軟件即服務(wù)）。
IaaS關(guān)注基礎(chǔ)架構(gòu)中最基礎(chǔ)的存儲、計算、網(wǎng)絡(luò)三大服務(wù)，它很好地解決了中小IaaS的出現(xiàn)企業(yè)對底層資源管理復(fù)雜性的問題，人們無須再購買硬件、租賃機房、管理OS。但對于解決開發(fā)、運維工作的困局是遠遠不夠的，在存儲、計算、網(wǎng)絡(luò)之上還有支撐應(yīng)用運行的各類中間件，需要將存儲、計算、網(wǎng)絡(luò)、中間件等資源綁定成一個整體，還需要對開發(fā)代碼發(fā)布進行嚴格的安全控制。IaaS面向的用戶是運維人員，PaaS面向的用戶是開發(fā)人員。

IaaS幫助有限

PaaS 及時到來

PaaS將關(guān)注點從原有的基礎(chǔ)資源上升到應(yīng)用層面，它的目標是提供一個可簡單操作的平臺來幫助開發(fā)人員運行、管理Web應(yīng)用，它的關(guān)注點圍繞著開發(fā)者的可運行代碼。PaaS提供一個環(huán)節(jié)給開發(fā)者創(chuàng)建、管理、部署應(yīng)用，其收益不僅包括了IaaS原有的規(guī)模效應(yīng)、固有成本，更看重的是提高代碼發(fā)布的效率。在資源層面，PaaS提供底層計算、存儲、網(wǎng)絡(luò)、虛擬化、中間件等服務(wù)。在部署上，PaaS為了黏合開發(fā)、運維人員之間的關(guān)系，提供了一套自定義的部署工具，工具與企業(yè)的適用程度越高，意味著PaaS越有可能通過私有云方式提供。除了資源提供、環(huán)境部署，具體的PaaS甚至?xí)峁﹫F隊協(xié)作、服務(wù)集成、負載均衡、安全控制、持久化、狀態(tài)管理等各類型服務(wù)，隨著PaaS提供的服務(wù)與代碼的精密度越來越高，其對應(yīng)用本身的約束也就越大。這就導(dǎo)致很難有一個標準的公有平臺滿足絕大多數(shù)企業(yè)的應(yīng)用開發(fā)需求。

PaaS及時到來

PaaS for Ops

Ops每天重復(fù)性運維工作內(nèi)容主要是以下四項：

資源分配
我們大部分時間在進行資源分配，將服務(wù)器、存儲、操作系統(tǒng)以及軟件等分配給應(yīng)用，工作的復(fù)雜性圍繞著應(yīng)用而產(chǎn)生。
應(yīng)用部署
將開發(fā)兄弟提供的業(yè)務(wù)邏輯放到我們所分配的資源中去。
服務(wù)發(fā)現(xiàn)
如果讓用戶找到這個服務(wù)，如何讓服務(wù)于服務(wù)之間可以互訪問。
通常的做法有負載均衡、域名解析、配置消息中心等方式解決服務(wù)發(fā)現(xiàn)問題。
監(jiān)控巡檢
監(jiān)控巡檢是運維之必須，在此不再累述。
在這里我們討論前三項，資源分配、應(yīng)用部署于服務(wù)發(fā)現(xiàn)。

他們依賴于基本的運維管理工具，包括配置管理系統(tǒng)CMDB、監(jiān)控管理系統(tǒng)以及標準的ITIL流程管理。

Ops全局工作圖

既然說PaaS要徹底地填補開發(fā)、運維工作之間的溝壑，讓開發(fā)的全部精力聚焦到業(yè)務(wù)邏輯上，那么我們有必要讓PaaS解決的問題具體化。

PaaS提供的是一個應(yīng)用的聚合，這里包含了功能各異的服務(wù)組件

應(yīng)用服務(wù)中間件：直接包含業(yè)務(wù)邏輯代碼、模塊的中間件容器，提供數(shù)據(jù)庫連接池、事務(wù)控制等接口以掩蓋后端的復(fù)雜性。
數(shù)據(jù)存儲服務(wù)：業(yè)務(wù)數(shù)據(jù)的存儲區(qū)域通過標準的數(shù)據(jù)存儲協(xié)議如文檔型、SQL、key-value等交互。
消息服務(wù)：為了對應(yīng)用組件間進行解耦，常常需要支持點對點、發(fā)布-訂閱的消息服務(wù)。

PaaS要提供服務(wù)發(fā)現(xiàn)、可伸縮性、狀態(tài)管理功能

服務(wù)發(fā)現(xiàn)：組件與組件之間如何查找、發(fā)現(xiàn)對方，如何將最新的地址信息通知到應(yīng)用聚合，如何對外暴露統(tǒng)一的訪問點，這是PaaS要考慮的一個功能點，具體的實現(xiàn)包括可編程的DNS服務(wù)器及IP注冊分配器。
可伸縮性：涉及如何快速地對應(yīng)用進行擴容，組件如何依據(jù)類型請求負載的分配，以及分配的基本機制。
狀態(tài)管理：對于可快速復(fù)制、易擴容的組件，如何管理它們的會話狀態(tài)。

PaaS中的服務(wù)監(jiān)控、恢復(fù)與容災(zāi)
對于應(yīng)用聚合中的每一個組件，如何做到簡單、自定義地監(jiān)控，并且在服務(wù)異常時啟動服務(wù)的快速恢復(fù)功能。容災(zāi)指跨數(shù)據(jù)中心的平臺級故障恢復(fù)，涉及兩個數(shù)據(jù)中心之間的邏輯計算單元如何保持通信，如何保持唯一性，業(yè)務(wù)數(shù)據(jù)如何進行備份。
PaaS的Portal門戶
PaaS提供了一個對用戶友好的Portal，可以基于UI進行應(yīng)用資源的聚合，并且可以快速地查找到配置信息、計費信息。
ITIL服務(wù)管理的相關(guān)內(nèi)容
在云計算之前，許多大中型企業(yè)的IT管理方式是基于ITIL管理方法論的，它們制訂了一些適用于業(yè)務(wù)與IT服務(wù)穩(wěn)定而快速交付的具體流程、工具和方法，但隨著云平臺、PaaS的出現(xiàn)，ITIL是否就沒有必要存在了呢？筆者認為對于金融、保險行業(yè)生產(chǎn)環(huán)境的服務(wù)，如果能夠?qū)TIL管理中的控制規(guī)則同樣通過自定義的方式集成到PaaS平臺，那么將會提高服務(wù)的可用性。
PaaS平臺的安全管控
PaaS平臺的安全管控包括三方面：PaaS平臺的組成組件自身的安全控制；PaaS中提供的服務(wù)的安全控制；PaaS對外部提供服務(wù)的統(tǒng)一出口的安全控制。
部署發(fā)布的相關(guān)內(nèi)容
最后開發(fā)的代碼如何通過工具自動、快速地發(fā)布到平臺也是要考慮的，這部分與開發(fā)過程相關(guān)，包括代碼單元測試、集成測試、打包、版本控制、部署等。

PaaS平臺功能設(shè)計

為了能夠?qū)崿F(xiàn)PaaS平臺，我們需要保證運維的四個主要工作內(nèi)容實現(xiàn)自動化，下面這些功能全都是圍繞著實現(xiàn)這個目標而引入的。

計算單元
虛擬機鏡像、配置管理工具（puppet、saltstack、ansible）所負責(zé)的任務(wù)就是將應(yīng)用邏輯計算單元進行打包。計算單元包含了運行業(yè)務(wù)系統(tǒng)的全棧組件，其涵蓋了操作系統(tǒng)、中間件、依賴包等。PaaS平臺中我們選擇Docker替換原有的方式，作為一個輕量級容器，它比虛擬機更加節(jié)約資源，同時可以基于一份軟件介質(zhì)運行多個實例，Docker的倉庫、鏡像與容器三元素讓應(yīng)用邏輯計算單元大大得到了簡化。誠然，ansible這類軟件配置工具已經(jīng)非常輕巧、快捷，并且滿足95%以上的需求，但當(dāng)決定將PaaS構(gòu)建在跨IDC、跨第三方數(shù)據(jù)中心時，基于鏡像的分發(fā)能夠更加穩(wěn)定的滿足我們需求。Docker也有其缺點，例如不支持32位平臺，不支持windows服務(wù)器。

計算單元, 容器化替代虛擬機+軟件配置
資源分配
與Cloud2.0的IaaS不同，用戶并不關(guān)注如何獲得CPU、內(nèi)存、存儲資源。他們僅關(guān)注自身應(yīng)用計算邏輯的運行，他們希望資源是動態(tài)分配、彈性擴容的。數(shù)據(jù)中心需要一個統(tǒng)一的資源管理者，它將所有資源（無論虛擬、物理）抽象成一個整體，如同一個數(shù)據(jù)中心操作系統(tǒng)，這種資源的抽象不僅僅要滿足服務(wù)型計算，還要滿足大數(shù)據(jù)時代的MapReduce計算，以及今后的各種類型計算，這意味著資源分配與任務(wù)調(diào)度兩部分功能是解耦的。
在分布式資源管理領(lǐng)域，主流的選擇是Mesos、YARN
Mesos：Mesos最早由美國加州大學(xué)伯克利分校AMPLab實驗室開發(fā)，后在Twitter、Apple、Netflix等互聯(lián)網(wǎng)企業(yè)廣泛使用，成熟度高。
YARN：Apache Hadoop YARN一種新的 Hadoop 資源管理器，它是一個通用資源管理系統(tǒng)，可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度。
其他的選擇還有Kubernetes、CloudFoundry、OpenShift等方案，但這幾種不滿足資源分配與任務(wù)調(diào)度解耦，對應(yīng)用規(guī)則要求太高，并不容易兼容現(xiàn)有應(yīng)用。在我們環(huán)境選擇了Mesos，其獨有的靈活性保證了支持更多類型的上層分布式計算應(yīng)用。

Mesos資源管理是符合兼容性的最佳選擇
任務(wù)調(diào)度
任務(wù)調(diào)度器與資源管理器的最大不同在于其要對運行中的應(yīng)用服務(wù)負責(zé)，包括啟動、停止服務(wù)，監(jiān)控服務(wù)以及在服務(wù)失效時故障轉(zhuǎn)移。最初的分布式架構(gòu)設(shè)計中，人們常常模糊了作業(yè)調(diào)度與資源管理二者間的界線，其一是分布式平臺是為某一專屬計算類型服務(wù)，例如Hadoop平臺為MapReduce計算類型服務(wù)。其二，作業(yè)調(diào)度與資源管理的交互頻度高，合二為一后的效率更高。但隨后人們發(fā)現(xiàn)資源管理器的功能是相對穩(wěn)定的，而作業(yè)調(diào)度因為計算類型多，并行計算有MapReduce、Stream，普通計算有Service、批處理等，每一種計算類型的作業(yè)調(diào)度方式完全不同，如果將資源管理器與作業(yè)調(diào)度器綁定在一起則會失去分布式平臺的計算靈活性。
是以Mesos為核心，支持多領(lǐng)域的分布式集群調(diào)度框架，包括Docker容器集群調(diào)度框架Marathon、分布式 Cron（周期性執(zhí)行任務(wù)）集群調(diào)度框架Chronos和大數(shù)據(jù)的主流平臺Hadoop和Spark的集群調(diào)度框架等，實現(xiàn)系統(tǒng)的資源彈性調(diào)度。

Marathon到目前為止是最靈活的長服務(wù)任務(wù)調(diào)度框架
服務(wù)發(fā)現(xiàn)
服務(wù)發(fā)現(xiàn)有兩種形態(tài)，一種是用戶（人）來訪問的，一種是應(yīng)用之間互調(diào)的，對于前者需要保持一個穩(wěn)定的入口（不變），而對于后者，如果在一個寬松的環(huán)境里，是運行變化，并接受變化通知的。而對于長服務(wù)型計算類型，除了解決服務(wù)發(fā)現(xiàn)外，還要考慮將任務(wù)分發(fā)到多個節(jié)點，亦即負載均衡問題。
服務(wù)發(fā)現(xiàn)上可選的有通過動態(tài)寫入DNS系統(tǒng)來滿足用戶需求，通過zookeeper之類的分布式協(xié)調(diào)系統(tǒng)充當(dāng)配置中心通知外部系統(tǒng)。而在負載均衡上，企業(yè)級的專用設(shè)備，例如F5等都提供了API接口以供調(diào)用，而開源軟件上通常采用Haproxy。

服務(wù)發(fā)現(xiàn)的組件選擇
工作流程

Mesos+Marathon+Docker的工作流程

通過zookeeper實現(xiàn)服務(wù)發(fā)現(xiàn)流程