DevOps困局

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

更小、更頻繁的變更意味著更少的風險；
讓開發人員更多地控制生產環境；
更多地以應用程序為中心來理解基礎設施；
定義簡潔明了的流程，盡可能地自動化；
促成開發人員與運營人員的協作；

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

DevOps的十字路口

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

IaaS 幫助有限

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

IaaS幫助有限

PaaS 及時到來

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

PaaS及時到來

PaaS for Ops

Ops每天重復性運維工作內容主要是以下四項：

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

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

Ops全局工作圖

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

PaaS提供的是一個應用的聚合，這里包含了功能各異的服務組件

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

PaaS要提供服務發現、可伸縮性、狀態管理功能

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

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

PaaS平臺功能設計

為了能夠實現PaaS平臺，我們需要保證運維的四個主要工作內容實現自動化，下面這些功能全都是圍繞著實現這個目標而引入的。

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

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

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

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

服務發現的組件選擇
工作流程

Mesos+Marathon+Docker的工作流程

通過zookeeper實現服務發現流程