如果是新產(chǎn)品，在設(shè)計(jì)階段運(yùn)維就有必要參與進(jìn)來了，因?yàn)樽龀鰜淼漠a(chǎn)品最終都要交付上線，放到服務(wù)器上給用戶提供服務(wù)，一是運(yùn)維更加了解線上環(huán)境，研發(fā)階段簡易的demo開發(fā)環(huán)境放到線上會(huì)遇到各種問題；二是開發(fā)過程如果缺少運(yùn)維意識(shí)，上線后在做資源彈性調(diào)整及其它策略改變可能會(huì)遇到各種麻煩；另外運(yùn)維人員會(huì)根據(jù)模塊屬于不同的IO消耗型、cpu消耗型、內(nèi)存消耗型等需求提出更加合理的上線服務(wù)器環(huán)境，提前參與產(chǎn)品中也可對(duì)節(jié)省成本的同時(shí)提高性能有很大幫助。根據(jù)經(jīng)驗(yàn)，我總結(jié)了4個(gè)要素，同樣如果對(duì)于已經(jīng)做好的產(chǎn)品，從優(yōu)化的角度去提升產(chǎn)品性能同時(shí)減少故障，也是從這“4要素”出發(fā)：

一、整個(gè)系統(tǒng)的功能要模塊化（微服務(wù)），單個(gè)模塊高內(nèi)聚低耦合；

  大型互聯(lián)網(wǎng)應(yīng)用面對(duì)全國乃至世界范圍的使用，要面對(duì)開發(fā)分工、迭代、擴(kuò)容等各種場景，使用中要保證優(yōu)秀的用戶體驗(yàn)、良性的迭代升級(jí)和業(yè)務(wù)擴(kuò)展，一定要使用微服務(wù)的架構(gòu)設(shè)計(jì)思想進(jìn)行模塊拆分，一個(gè)沒有模塊劃分的系統(tǒng)是不可能完成這項(xiàng)任務(wù)的，想想幾百號(hào)人圍繞著一套代碼轉(zhuǎn)是個(gè)什么樣子。一個(gè)優(yōu)秀的大型互聯(lián)網(wǎng)應(yīng)用會(huì)在設(shè)計(jì)之初就進(jìn)行模塊化，每個(gè)模塊各司其職，模塊間通過HTTP API或者消息隊(duì)列進(jìn)行通信，各模塊根據(jù)工作量和難度分給不同項(xiàng)目組負(fù)責(zé)，最后單個(gè)模塊形成高內(nèi)聚、模塊之間形成低耦合的模型，該是誰的事兒就找誰，當(dāng)然功能模塊怎么劃分更加科學(xué)，就需要做研討了，研討中要從當(dāng)前開發(fā)的科學(xué)性和后期上線可運(yùn)維性兩個(gè)維度來做考慮。

二、每個(gè)功能模塊相對(duì)獨(dú)立易部署、所需資源彈性可擴(kuò)展；

    要應(yīng)對(duì)線上變化的環(huán)境、用戶量的自然及突發(fā)性增長、開發(fā)者的人員變動(dòng)，每個(gè)功能模塊在做到功能獨(dú)立高內(nèi)聚的同時(shí)，要做到運(yùn)維的可交付、資源的可彈性擴(kuò)展。

    運(yùn)維的可交付體現(xiàn)在模塊的易部署（越簡單越好），部署過程不依賴修改源代碼，所需的配置文件、代碼可以做到統(tǒng)一下發(fā)。

    資源的彈性擴(kuò)展是為了應(yīng)對(duì)用戶量的自然及突發(fā)性增長，比如說要做一個(gè)活動(dòng)，訪問量會(huì)突發(fā)翻倍，這時(shí)模塊要能做到易擴(kuò)展，可以彈性的通過簡單的擴(kuò)容服務(wù)器來增加系統(tǒng)吞吐量，不至于造成系統(tǒng)瓶頸，每個(gè)模塊做到了彈性可擴(kuò)展，整個(gè)應(yīng)用才會(huì)變成一個(gè)彈性可伸縮的強(qiáng)大產(chǎn)品。

三、每個(gè)功能模塊無單點(diǎn)故障點(diǎn)，如遇后端依賴故障可以降級(jí)服務(wù)；

    為了讓開發(fā)和運(yùn)維人員能夠睡個(gè)好覺，一個(gè)好產(chǎn)品的每個(gè)模塊必須能夠做到服務(wù)器間容災(zāi)且無單點(diǎn)故障，就是說一臺(tái)服務(wù)器掛了不會(huì)影響到模塊服務(wù)，進(jìn)而影響到整個(gè)應(yīng)用的癱瘓，每臺(tái)服務(wù)器模塊都是一個(gè)獨(dú)立的個(gè)體，互不影響，當(dāng)某臺(tái)服務(wù)器掛了之后剩余的服務(wù)器能把活兒接起來，當(dāng)然這是最理想的模型，如果實(shí)在無法做到熱備，最起碼得做到無需人工干預(yù)的冷備。

    模塊之間都是協(xié)同工作的，每個(gè)模塊都可能承上啟下相互依賴，在向前端輸出任務(wù)處理結(jié)果時(shí)也依賴后端其它模塊的處理結(jié)果，這時(shí)就要考慮到萬一依賴的后端模塊掛了或者超時(shí)怎么辦的情況，以防出現(xiàn)雪崩的連鎖反應(yīng)，這時(shí)模塊就有必要設(shè)置降級(jí)預(yù)案機(jī)制，比如說當(dāng)那不到結(jié)果或?yàn)榭諘r(shí)向前端返回一個(gè)默認(rèn)的或最近處理的結(jié)果，應(yīng)付一下用戶，總比返回錯(cuò)誤信息要強(qiáng)，然后騰出時(shí)間解決問題，再比如是個(gè)新聞?lì)悜?yīng)用，可以返回一個(gè)近期的靜態(tài)頁面。

四、每個(gè)模塊的日志健全，做到可分析、可監(jiān)控。

    日志的健全性很重要，日志可以及時(shí)的發(fā)現(xiàn)問題、分析問題、分析模塊的性能、故障點(diǎn)等等，總之日志可以反應(yīng)出各種問題，其包含但不限于操作系統(tǒng)日志、業(yè)務(wù)日志（訪問、超時(shí)、錯(cuò)誤）、后端資源依賴日志等，分析的結(jié)果同時(shí)正向反饋到下一步的產(chǎn)品迭代研發(fā)中去。

    對(duì)于監(jiān)控，也分為了基礎(chǔ)監(jiān)控、應(yīng)用軟件監(jiān)控、業(yè)務(wù)監(jiān)控、依賴監(jiān)控四個(gè)層面，簡單介紹一下，基礎(chǔ)監(jiān)控指服務(wù)器各種基本指標(biāo)包含cpu、負(fù)載、io、內(nèi)存使用、網(wǎng)卡流量等的監(jiān)控，應(yīng)用軟件只nginx、tomcat、php-fpm等應(yīng)用軟件本身性能的監(jiān)控，業(yè)務(wù)監(jiān)控是指訪問后或?qū)τ谌蝿?wù)處理情況的日志監(jiān)控，比如說nginx的訪問日志，依賴監(jiān)控是指其依賴模塊或資源的監(jiān)控，比如說MC、redis等。

    寫在最后：如果一個(gè)大型互聯(lián)網(wǎng)應(yīng)用能夠做到這“4要素”，這個(gè)產(chǎn)品就是一個(gè)很高級(jí)的妖怪了，能夠抵抗狂風(fēng)暴雨。（所說“產(chǎn)品”是技術(shù)層面產(chǎn)品，并不是為網(wǎng)民設(shè)計(jì)的接入層用戶體驗(yàn)類邏輯產(chǎn)品）