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

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

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

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

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

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

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

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

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

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

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

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

    對于監(jiān)控，也分為了基礎(chǔ)監(jiān)控、應(yīng)用軟件監(jiān)控、業(yè)務(wù)監(jiān)控、依賴監(jiān)控四個層面，簡單介紹一下，基礎(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等。

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