DevOps困局

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

• 更小、更頻繁的變更意味著更少的風(fēng)險(xiǎn)舶衬；
• 讓開發(fā)人員更多地控制生產(chǎn)環(huán)境埠通；
• 更多地以應(yīng)用程序?yàn)橹行膩砝斫饣A(chǔ)設(shè)施；
• 定義簡潔明了的流程逛犹，盡可能地自動(dòng)化端辱；
• 促成開發(fā)人員與運(yùn)營人員的協(xié)作；

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

DevOps的十字路口

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

IaaS 幫助有限

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

IaaS幫助有限

PaaS 及時(shí)到來

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

PaaS及時(shí)到來

PaaS for Ops

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

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

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

Ops全局工作圖

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

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

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

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

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

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

PaaS平臺(tái)功能設(shè)計(jì)

為了能夠?qū)崿F(xiàn)PaaS平臺(tái)，我們需要保證運(yùn)維的四個(gè)主要工作內(nèi)容實(shí)現(xiàn)自動(dòng)化跳仿，下面這些功能全都是圍繞著實(shí)現(xiàn)這個(gè)目標(biāo)而引入的诡渴。

1. 計(jì)算單元
   虛擬機(jī)鏡像、配置管理工具（puppet菲语、saltstack妄辩、ansible）所負(fù)責(zé)的任務(wù)就是將應(yīng)用邏輯計(jì)算單元進(jìn)行打包。計(jì)算單元包含了運(yùn)行業(yè)務(wù)系統(tǒng)的全棧組件山上，其涵蓋了操作系統(tǒng)眼耀、中間件、依賴包等佩憾。PaaS平臺(tái)中我們選擇Docker替換原有的方式畔塔，作為一個(gè)輕量級(jí)容器，它比虛擬機(jī)更加節(jié)約資源鸯屿，同時(shí)可以基于一份軟件介質(zhì)運(yùn)行多個(gè)實(shí)例澈吨，Docker的倉庫、鏡像與容器三元素讓應(yīng)用邏輯計(jì)算單元大大得到了簡化寄摆。誠然谅辣，ansible這類軟件配置工具已經(jīng)非常輕巧、快捷婶恼，并且滿足95%以上的需求桑阶，但當(dāng)決定將PaaS構(gòu)建在跨IDC柏副、跨第三方數(shù)據(jù)中心時(shí)，基于鏡像的分發(fā)能夠更加穩(wěn)定的滿足我們需求蚣录。Docker也有其缺點(diǎn)割择，例如不支持32位平臺(tái)，不支持windows服務(wù)器萎河。
   
   計(jì)算單元, 容器化替代虛擬機(jī)+軟件配置
2. 資源分配
   與Cloud2.0的IaaS不同荔泳，用戶并不關(guān)注如何獲得CPU、內(nèi)存虐杯、存儲(chǔ)資源玛歌。他們僅關(guān)注自身應(yīng)用計(jì)算邏輯的運(yùn)行，他們希望資源是動(dòng)態(tài)分配擎椰、彈性擴(kuò)容的支子。數(shù)據(jù)中心需要一個(gè)統(tǒng)一的資源管理者，它將所有資源（無論虛擬达舒、物理）抽象成一個(gè)整體值朋，如同一個(gè)數(shù)據(jù)中心操作系統(tǒng)，這種資源的抽象不僅僅要滿足服務(wù)型計(jì)算巩搏，還要滿足大數(shù)據(jù)時(shí)代的MapReduce計(jì)算吞歼，以及今后的各種類型計(jì)算，這意味著資源分配與任務(wù)調(diào)度兩部分功能是解耦的塔猾。
   在分布式資源管理領(lǐng)域，主流的選擇是Mesos稽坤、YARN
   Mesos：Mesos最早由美國加州大學(xué)伯克利分校AMPLab實(shí)驗(yàn)室開發(fā)丈甸，后在Twitter、Apple尿褪、Netflix等互聯(lián)網(wǎng)企業(yè)廣泛使用睦擂，成熟度高。
   YARN：Apache Hadoop YARN一種新的 Hadoop 資源管理器杖玲，它是一個(gè)通用資源管理系統(tǒng)顿仇，可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度。
   其他的選擇還有Kubernetes摆马、CloudFoundry臼闻、OpenShift等方案，但這幾種不滿足資源分配與任務(wù)調(diào)度解耦囤采，對應(yīng)用規(guī)則要求太高述呐，并不容易兼容現(xiàn)有應(yīng)用。在我們環(huán)境選擇了Mesos蕉毯，其獨(dú)有的靈活性保證了支持更多類型的上層分布式計(jì)算應(yīng)用乓搬。
   
   Mesos資源管理是符合兼容性的最佳選擇
3. 任務(wù)調(diào)度
   任務(wù)調(diào)度器與資源管理器的最大不同在于其要對運(yùn)行中的應(yīng)用服務(wù)負(fù)責(zé)思犁，包括啟動(dòng)、停止服務(wù)进肯，監(jiān)控服務(wù)以及在服務(wù)失效時(shí)故障轉(zhuǎn)移激蹲。最初的分布式架構(gòu)設(shè)計(jì)中，人們常常模糊了作業(yè)調(diào)度與資源管理二者間的界線江掩，其一是分布式平臺(tái)是為某一專屬計(jì)算類型服務(wù)学辱，例如Hadoop平臺(tái)為MapReduce計(jì)算類型服務(wù)。其二频敛，作業(yè)調(diào)度與資源管理的交互頻度高项郊，合二為一后的效率更高。但隨后人們發(fā)現(xiàn)資源管理器的功能是相對穩(wěn)定的斟赚，而作業(yè)調(diào)度因?yàn)橛?jì)算類型多着降，并行計(jì)算有MapReduce、Stream拗军，普通計(jì)算有Service任洞、批處理等，每一種計(jì)算類型的作業(yè)調(diào)度方式完全不同发侵，如果將資源管理器與作業(yè)調(diào)度器綁定在一起則會(huì)失去分布式平臺(tái)的計(jì)算靈活性交掏。
   是以Mesos為核心，支持多領(lǐng)域的分布式集群調(diào)度框架刃鳄，包括Docker容器集群調(diào)度框架Marathon盅弛、分布式 Cron（周期性執(zhí)行任務(wù)）集群調(diào)度框架Chronos和大數(shù)據(jù)的主流平臺(tái)Hadoop和Spark的集群調(diào)度框架等，實(shí)現(xiàn)系統(tǒng)的資源彈性調(diào)度叔锐。
   
   Marathon到目前為止是最靈活的長服務(wù)任務(wù)調(diào)度框架
4. 服務(wù)發(fā)現(xiàn)
   服務(wù)發(fā)現(xiàn)有兩種形態(tài)挪鹏，一種是用戶（人）來訪問的，一種是應(yīng)用之間互調(diào)的愉烙，對于前者需要保持一個(gè)穩(wěn)定的入口（不變）讨盒，而對于后者，如果在一個(gè)寬松的環(huán)境里步责，是運(yùn)行變化返顺，并接受變化通知的。而對于長服務(wù)型計(jì)算類型蔓肯，除了解決服務(wù)發(fā)現(xiàn)外遂鹊，還要考慮將任務(wù)分發(fā)到多個(gè)節(jié)點(diǎn)，亦即負(fù)載均衡問題蔗包。
   服務(wù)發(fā)現(xiàn)上可選的有通過動(dòng)態(tài)寫入DNS系統(tǒng)來滿足用戶需求稿辙，通過zookeeper之類的分布式協(xié)調(diào)系統(tǒng)充當(dāng)配置中心通知外部系統(tǒng)。而在負(fù)載均衡上气忠，企業(yè)級(jí)的專用設(shè)備邻储，例如F5等都提供了API接口以供調(diào)用赋咽，而開源軟件上通常采用Haproxy。
   
   服務(wù)發(fā)現(xiàn)的組件選擇
5. 工作流程
   
   Mesos+Marathon+Docker的工作流程
   
   
   通過zookeeper實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)流程

關(guān)于PaaS的架構(gòu)設(shè)計(jì)以及實(shí)現(xiàn)細(xì)節(jié)可參考如下著作：

PaaS實(shí)現(xiàn)與運(yùn)維管理.png

TO PaaS for Dev

開發(fā)人員的主要工作

容器化dockerfile與Jenkins集成發(fā)布是必備武器.png