單塊架構(gòu)

　　應(yīng)用軟件發(fā)展早期，系統(tǒng)規(guī)模一般很小，特點(diǎn)是應(yīng)用功能集中、代碼和數(shù)據(jù)中心化，表現(xiàn)為一個(gè)軟件發(fā)布包，集中部署，各模塊運(yùn)行在同一個(gè)進(jìn)程的應(yīng)用程序。此時(shí)一般幾臺(tái)機(jī)器就可以完成全部應(yīng)用軟件功能。

　　以Web應(yīng)用程序?yàn)槔赪eb應(yīng)用程序開(kāi)發(fā)的早期，由于受到面向過(guò)程的思維及設(shè)計(jì)方式的影響，所有的邏輯代碼并沒(méi)有明顯的區(qū)分，因此代碼之間的調(diào)用相互交錯(cuò)，錯(cuò)綜復(fù)雜。譬如，我們?cè)缙谑褂玫腁SP、JSP以及PHP，都是將所有的頁(yè)面邏輯、業(yè)務(wù)邏輯以及數(shù)據(jù)庫(kù)訪問(wèn)邏輯放在一起，這是我們通常提到的單塊架構(gòu)。

　　多層架構(gòu)

　　為了解決單塊架構(gòu)擴(kuò)展性差的問(wèn)題，同時(shí)解決代碼集中帶來(lái)的并行開(kāi)發(fā)測(cè)試?yán)щy等問(wèn)題，逐步出現(xiàn)了多層架構(gòu)，把表示層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問(wèn)層適當(dāng)分離，分別打包部署。如通過(guò)實(shí)現(xiàn)Model-View-Controller的模式將數(shù)據(jù)、業(yè)務(wù)、展現(xiàn)進(jìn)行分離。還有一種RPC架構(gòu)，通過(guò)遠(yuǎn)程過(guò)程調(diào)用實(shí)現(xiàn)應(yīng)用架構(gòu)分離。

　　服務(wù)化架構(gòu)

　　多層架構(gòu)盡管大幅提升了應(yīng)用的擴(kuò)展性，但是隨著軟件和系統(tǒng)規(guī)模的不斷擴(kuò)大，垂直應(yīng)用越來(lái)越多，應(yīng)用之間交互不可避免，此時(shí)層間應(yīng)用接口變得越來(lái)越龐大，最終會(huì)變得難以管理。通過(guò)將核心業(yè)務(wù)抽取出來(lái)，作為獨(dú)立的服務(wù)，逐漸形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速地相應(yīng)多變的市場(chǎng)需求，也使不同服務(wù)的獨(dú)立擴(kuò)展成為可能。

　　分布式云化架構(gòu)

　　隨著業(yè)務(wù)不斷發(fā)展，硬件成本的下降，基于X86架構(gòu)的廉價(jià)硬件+分布式軟件的模式日趨成熟，得到了大規(guī)模應(yīng)用，分布式服務(wù)框架逐漸替代傳統(tǒng)的服務(wù)化架構(gòu)，解決了傳統(tǒng)服務(wù)化的弊端，例如企業(yè)集成總線ESB是實(shí)體總線，性能線性擴(kuò)展能力有限，硬件負(fù)載均衡器的壓力越來(lái)越大，不斷擴(kuò)容導(dǎo)致硬件成本增加，隨著業(yè)務(wù)規(guī)模的不斷增長(zhǎng)，傳統(tǒng)的數(shù)據(jù)庫(kù)、配置中心等逐漸成為單點(diǎn)瓶頸。當(dāng)然應(yīng)用也徹底變?yōu)榱藄cale-out架構(gòu)，導(dǎo)致機(jī)器和容器數(shù)量大幅上升。

　　微服務(wù)架構(gòu)是對(duì)上面分布式云化架構(gòu)的拓展、服務(wù)化的進(jìn)一步延伸，通過(guò)對(duì)服務(wù)進(jìn)一步細(xì)化，形成微服務(wù)，運(yùn)行于單獨(dú)的容器平臺(tái)，可實(shí)現(xiàn)云的彈性和敏捷，如彈性伸縮、線上線下一致的環(huán)境、提升自動(dòng)化運(yùn)維能力等。

　　1、硬件和網(wǎng)絡(luò)的自動(dòng)管理

　　其中1、2、3主要是傳統(tǒng)IaaS層關(guān)注的工作內(nèi)容，重點(diǎn)是計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)的自動(dòng)化管理，4到8主要是PaaS層關(guān)注的工作內(nèi)容，IaaS層和PaaS層相互結(jié)合，共同完成自動(dòng)化運(yùn)維。

　　好了，終于到正題了，自動(dòng)化運(yùn)維前世今生來(lái)了…..

　　新生代自動(dòng)化運(yùn)維初探

　　下面重點(diǎn)介紹幾個(gè)自動(dòng)化運(yùn)維工具或平臺(tái)：

　　Openstack

　　Openstack是IaaS層目前最活躍的一個(gè)開(kāi)源的云計(jì)算 IaaS 平臺(tái)，即云操作系統(tǒng)，類似于AWS（亞馬遜的云服務(wù)），通過(guò)各種開(kāi)源組件實(shí)現(xiàn)了不同功能，目前大部分云管理平臺(tái)均基于Openstack實(shí)現(xiàn)計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)的統(tǒng)一管理，Openstack支持如下功能組件：

　　計(jì)算服務(wù)（Nova）：按需提供計(jì)算資源，創(chuàng)建和管理批量虛擬機(jī) ，動(dòng)態(tài)虛擬機(jī)管理：創(chuàng)建、重啟、調(diào)整大小、遷移等。

　　對(duì)象存儲(chǔ)服務(wù)（Swift）：基于普通硬件的大規(guī)模存儲(chǔ)，無(wú)中心節(jié)點(diǎn)，分布式存儲(chǔ)、水平擴(kuò)展，同時(shí)多數(shù)據(jù)備份，保證安全，通過(guò)API接口對(duì)外訪問(wèn)。

　　塊存儲(chǔ)服務(wù)（Cinder)：為虛擬機(jī)提供云硬盤(pán)。

　　網(wǎng)絡(luò)服務(wù)（Neutron）：為虛擬機(jī)提供網(wǎng)絡(luò)訪問(wèn)能力。

　　編排服務(wù)（Heat）：提供自動(dòng)化部署及管理服務(wù)。

　　數(shù)據(jù)庫(kù)服務(wù)（Trove）：提供數(shù)據(jù)庫(kù)管理服務(wù)。

　　認(rèn)證服務(wù)（Keystone）：提供身份認(rèn)證機(jī)制服務(wù)。

　　鏡像服務(wù)（Glance）：提供虛擬機(jī)鏡像存儲(chǔ)服務(wù)。

　　監(jiān)控服務(wù)（Ceilometer）：提供計(jì)量與監(jiān)控服務(wù)。

　　Dashboard（Horizon）：自服務(wù)、權(quán)限、圖形化界面。

　　1、Openstack版本眾多，如何選擇是一個(gè)難題。

　　例如存在社區(qū)版、發(fā)行版、商業(yè)公司定制版本等，如何選擇是一個(gè)難題，而且Openstack每半年一個(gè)穩(wěn)定版本，演進(jìn)很快。一般認(rèn)為對(duì)Openstack項(xiàng)目中的開(kāi)源代碼進(jìn)行修改定制是個(gè)不錯(cuò)的主意，但這從長(zhǎng)期角度來(lái)看不一定優(yōu)質(zhì)。“定制云”很可能需要付出高昂的代價(jià)，不僅投資巨大、成本高昂，企業(yè)用戶還將被迫面對(duì)一大堆后續(xù)的管理及維護(hù)開(kāi)銷(xiāo)，并被綁定在單一供應(yīng)商或版本身上。

　　建議企業(yè)如果有很強(qiáng)的技術(shù)能力的話，可以根據(jù)自己的需求做定制，但需要把握好和社區(qū)發(fā)展的關(guān)系。 一般來(lái)說(shuō)，需要根據(jù)自己的需求，選擇合適的版本，盡量不改變社區(qū)版本，定制化需求盡量在外圍進(jìn)行改動(dòng)。如果采用了廠商的版本，實(shí)際上也是某種綁定，可能離社區(qū)越來(lái)越遠(yuǎn)。

　　2、需要慎重選擇相關(guān)組件合功能

　　由于Openstack理念是分布式、最終一致性，因此所有的原始功能組件都是基于這一設(shè)計(jì)，企業(yè)用戶考慮采納Openstack之前，必須對(duì)企業(yè)業(yè)務(wù)應(yīng)用進(jìn)行分析：應(yīng)用程序是否有可擴(kuò)展性和彈性伸縮的要求？ 應(yīng)用程序是否可以接受最終一致性？ 應(yīng)用程序是否無(wú)狀態(tài)化？ 應(yīng)用程序的性能要求？應(yīng)用程序的可靠性要求？ 應(yīng)用程序的安全要求？ 應(yīng)用程序的容災(zāi)備份需求？ 不同的要求決定了Openstack不同的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等模塊設(shè)計(jì)。

　　3、Openstack對(duì)PaaS層和物理機(jī)管理較弱，需借助其他工具實(shí)現(xiàn)

　　Openstack已經(jīng)能夠支持很多的IaaS自動(dòng)化運(yùn)維和部分PaaS自動(dòng)化運(yùn)維任務(wù)，但不能滿足全部，如批量運(yùn)維、深入監(jiān)控、軟件管理等功能缺少，特別是對(duì)物理機(jī)運(yùn)維較弱，一般需要結(jié)合其他PaaS層管理進(jìn)一步完善自動(dòng)化運(yùn)維體系。

　　SaltStack+定制

　　PaaS層自動(dòng)化運(yùn)維工具就太多了，例如監(jiān)控就有Nagios、Ganglia、Zabbix等，運(yùn)維工具則有Puppet、Chef、SaltStack、Ansible等，不同企業(yè)根據(jù)企業(yè)自身開(kāi)發(fā)實(shí)力、結(jié)合配置管理工具的資源豐富程度、依賴復(fù)雜程度考慮，會(huì)有不同的選擇。通過(guò)對(duì)運(yùn)維工具本身的研究，結(jié)合運(yùn)維人員的運(yùn)維經(jīng)驗(yàn)和評(píng)估企業(yè)未來(lái)的規(guī)模，下面以開(kāi)源SaltStack+定制實(shí)現(xiàn)的方案進(jìn)行介紹。

　　SaltStack是繼 Puppet、Chef 之后新出現(xiàn)的S配置管理及遠(yuǎn)程執(zhí)行工具，與 Puppet 相比，SaltStack較為輕量；不像 Puppet有一套自己的 DSL 用來(lái)寫(xiě)配置，SaltStack 使用 YAML 作為配置文件格式，相對(duì)簡(jiǎn)單，同時(shí)也便于動(dòng)態(tài)生成；此外，SaltStack 在遠(yuǎn)程執(zhí)行命令時(shí)的速度快，由于使用了ZeroMQ，這個(gè)下發(fā)過(guò)程可以并行執(zhí)行，速度比Ansible的無(wú)agent ssh通信快得多，是一個(gè)分布式遠(yuǎn)程執(zhí)行系統(tǒng)，用來(lái)在遠(yuǎn)程節(jié)點(diǎn)（可以是單個(gè)節(jié)點(diǎn)，也可以是任意規(guī)則挑選出來(lái)的節(jié)點(diǎn)）上執(zhí)行命令和查詢數(shù)據(jù)。

　　從部署結(jié)構(gòu)上看，SaltStack的在部署上可以分為master和minion兩個(gè)部分，其中master相當(dāng)于統(tǒng)領(lǐng)所有機(jī)器的總管，而minion則是部署在被管理機(jī)器上面的agent進(jìn)程，master通過(guò)網(wǎng)絡(luò)將配置管理相關(guān)的操作下發(fā)到minion，由minion在對(duì)應(yīng)機(jī)器的本地執(zhí)行。典型的部署例子如下圖所示：

　　容器

　　有了Openstack和SaltStack為代表的的PaaS層自動(dòng)化工具還不夠，針對(duì)應(yīng)用自動(dòng)化運(yùn)維場(chǎng)景，如彈性伸縮、DevOps（開(kāi)發(fā)運(yùn)維一體化、開(kāi)發(fā)測(cè)試一致的環(huán)境、自動(dòng)資源調(diào)度、應(yīng)用日志統(tǒng)一管控、應(yīng)用服務(wù)的編排、微服務(wù)管理等），此時(shí)出現(xiàn)了容器技術(shù)，容器技術(shù)實(shí)現(xiàn)有很多種，但最流行的是Docker。

　　傳統(tǒng)容器技術(shù)相較虛擬機(jī)優(yōu)勢(shì)不是特別大。Docker能夠流行一大重要因此就是它的創(chuàng)新–Docker鏡像。Docker構(gòu)建了一整套構(gòu)建、發(fā)布、運(yùn)行體系：容器（Container）、倉(cāng)庫(kù)（Repository）、鏡像（Images）。傳統(tǒng)容器只解決了容器運(yùn)行（run）的問(wèn)題。而Docker定義了一套容器構(gòu)建（build）分發(fā)（ship）的標(biāo)準(zhǔn)，使應(yīng)用管理非常便捷，尤其適合微服務(wù)管理。

　　注意容器對(duì)應(yīng)用有特定的要求，并不是所有應(yīng)用都適合，例如需要無(wú)狀態(tài)化、鏡像文件不能太大等。

　　自動(dòng)化運(yùn)維需要注意的幾點(diǎn)：

　　自動(dòng)化運(yùn)維工具眾多，各有所長(zhǎng)，應(yīng)結(jié)合熟悉程度、技術(shù)特點(diǎn)進(jìn)行針對(duì)性選擇。

　　多層的自動(dòng)化管理工具，多頭的配置管理是個(gè)難題，建議考慮定制化，設(shè)計(jì)統(tǒng)一的CMDB，做到一點(diǎn)配置，多點(diǎn)更新。