軟件項(xiàng)目最初沒(méi)有的運(yùn)維部門(mén)
大概12年前，最初進(jìn)入軟件開(kāi)發(fā)領(lǐng)域，那時(shí)一個(gè)人需要學(xué)很多的開(kāi)發(fā)技能和運(yùn)維技能，上能后端做服務(wù)，下能前端寫(xiě)頁(yè)面，左能做DBA，右能做架構(gòu)，中間還能運(yùn)維。
那時(shí)開(kāi)發(fā)和運(yùn)維其實(shí)沒(méi)有界限，基本都是一體的，當(dāng)然也有可能因?yàn)楣疽?guī)模不是特別大，所以分工也沒(méi)有那么細(xì)，也聽(tīng)說(shuō)過(guò)專門(mén)有運(yùn)維部門(mén)的公司，但是那時(shí)軟件運(yùn)維人員的水平也只能做重復(fù)性的工作。
硬件和網(wǎng)絡(luò)運(yùn)維這里不講，而那種比較貴的DBA，中小公司一般不會(huì)請(qǐng)，所以基本上開(kāi)發(fā)≈運(yùn)維。
軟件生命周期中最長(zhǎng)的部分在運(yùn)維階段，在那個(gè)時(shí)候開(kāi)發(fā)是要負(fù)責(zé)整個(gè)生命周期的。
那個(gè)時(shí)候架構(gòu)很簡(jiǎn)單，有的應(yīng)用程序、數(shù)據(jù)庫(kù)、文件都部署在一臺(tái)服務(wù)器上：
或者是分開(kāi)部署，將應(yīng)用程序、數(shù)據(jù)庫(kù)、文件各自部署在獨(dú)立的服務(wù)器上，并且根據(jù)服務(wù)器的用途配置不同的硬件，達(dá)到最佳的性能效果：
數(shù)據(jù)庫(kù)的選擇一般情況下有三個(gè)：大、中型系統(tǒng)使用Oracle或者M(jìn)SSQL，畢竟會(huì)有廠商進(jìn)行支持，DBA的質(zhì)量也比較高。
小型系統(tǒng)一般使用MySQL，使用的好壞基本依賴開(kāi)發(fā)人員對(duì)MySQL的熟悉程度。
然而到了今天，會(huì)有專業(yè)的人在做開(kāi)源或者非開(kāi)源數(shù)據(jù)庫(kù)的維護(hù)，數(shù)據(jù)庫(kù)市場(chǎng)也迎來(lái)了百花齊放的春天。
隨著業(yè)務(wù)擴(kuò)展開(kāi)始出現(xiàn)分工
當(dāng)越來(lái)越多的人開(kāi)始使用軟件系統(tǒng)，開(kāi)發(fā)的工作日漸繁忙，多數(shù)時(shí)候在忙著寫(xiě)代碼和做項(xiàng)目，運(yùn)維的工作很多時(shí)候無(wú)法抽身。
這個(gè)時(shí)候會(huì)將幾個(gè)之前開(kāi)發(fā)系統(tǒng)的程序員組成一個(gè)新的組織，這個(gè)就是軟件運(yùn)維部門(mén)的雛形，他們?yōu)榱私鉀Q一些性能上的問(wèn)題，可能改變系統(tǒng)架構(gòu)與部署，比如加入緩存：
在大部分系統(tǒng)中，都會(huì)利用緩存技術(shù)改善系統(tǒng)的性能，使用緩存主要源于熱點(diǎn)數(shù)據(jù)的存在，大部分訪問(wèn)都遵循28原則(即80%的訪問(wèn)請(qǐng)求，最終落在20%的數(shù)據(jù)上)。
所以我們可以對(duì)熱點(diǎn)數(shù)據(jù)進(jìn)行緩存，減少這些數(shù)據(jù)的訪問(wèn)路徑，提高用戶體驗(yàn)。
緩存實(shí)現(xiàn)常見(jiàn)的方式是本地緩存、分布式緩存。本地緩存，顧名思義是將數(shù)據(jù)緩存在應(yīng)用服務(wù)器本地，可以存在內(nèi)存中，也可以存在文件，OSCache就是常用的本地緩存組件。
本地緩存的特點(diǎn)是速度快，但因?yàn)楸镜乜臻g有限所以緩存數(shù)據(jù)量也有限。
分布式緩存的特點(diǎn)是，可以緩存海量的數(shù)據(jù)，并且擴(kuò)展非常容易，在軟件系統(tǒng)中常常被使用，速度按理沒(méi)有本地緩存快，常用的分布式緩存是Memcached、Redis。
當(dāng)然在用戶量繼續(xù)增長(zhǎng)的情況下，應(yīng)用服務(wù)器作為系統(tǒng)的入口，會(huì)承擔(dān)大量的請(qǐng)求，我們往往通過(guò)應(yīng)用服務(wù)器集群來(lái)分擔(dān)請(qǐng)求數(shù)。
應(yīng)用服務(wù)器前面部署負(fù)載均衡服務(wù)器調(diào)度用戶請(qǐng)求，根據(jù)分發(fā)策略將請(qǐng)求分發(fā)到多個(gè)應(yīng)用服務(wù)器節(jié)點(diǎn)這時(shí)：
常用的負(fù)載均衡技術(shù)硬件的有F5，價(jià)格比較貴，軟件的有LVS、Nginx、HAProxy。
LVS是四層負(fù)載均衡，根據(jù)目標(biāo)地址和端口選擇內(nèi)部服務(wù)器，Nginx是七層負(fù)載均衡和HAProxy支持四層、七層負(fù)載均衡，可以根據(jù)報(bào)文內(nèi)容選擇內(nèi)部服務(wù)器。
因此LVS分發(fā)路徑優(yōu)于Nginx和HAProxy，性能要高些，而Nginx和HAProxy則更具配置性，如可以用來(lái)做動(dòng)靜分離(根據(jù)請(qǐng)求報(bào)文特征，選擇靜態(tài)資源服務(wù)器還是應(yīng)用服務(wù)器)。
隨著用戶量繼續(xù)增加，數(shù)據(jù)庫(kù)成為最大的瓶頸，改善數(shù)據(jù)庫(kù)性能常用的手段是進(jìn)行讀寫(xiě)分離以及分表，讀寫(xiě)分離顧名思義就是將數(shù)據(jù)庫(kù)分為讀庫(kù)和寫(xiě)庫(kù)，通過(guò)主備功能實(shí)現(xiàn)數(shù)據(jù)同步。
分庫(kù)分表則分為水平切分和垂直切分，水平切換則是對(duì)一個(gè)數(shù)據(jù)庫(kù)特大的表進(jìn)行拆分，例如用戶表。
垂直切分則是根據(jù)業(yè)務(wù)不同來(lái)切換，如用戶業(yè)務(wù)、商品業(yè)務(wù)相關(guān)的表放在不同的數(shù)據(jù)庫(kù)中：
業(yè)務(wù)量越來(lái)越大，產(chǎn)生的文件越來(lái)越多，單臺(tái)的文件服務(wù)器已經(jīng)不能滿足需求。需要分布式的文件系統(tǒng)支撐。
常用的分布式文件系統(tǒng)有NFS：
由于項(xiàng)目數(shù)據(jù)量持續(xù)增加，數(shù)據(jù)庫(kù)的壓力會(huì)越來(lái)越大，并且傳統(tǒng)關(guān)系型數(shù)據(jù)無(wú)法處理海量數(shù)據(jù)。
這時(shí)需要分離數(shù)據(jù)存儲(chǔ)，對(duì)于海量數(shù)據(jù)的查詢和分析，我們使用NoSQL數(shù)據(jù)庫(kù)和大數(shù)據(jù)技術(shù)再加上搜索引擎可以達(dá)到更好的性能。
常用的NoSQL數(shù)據(jù)庫(kù)有MongoDB、HBase(依賴Hadoop大數(shù)據(jù))、Redis，搜索引擎有Lucene、Solr、Elasticsearch等：
單獨(dú)軟件運(yùn)維部門(mén)
當(dāng)越來(lái)越多的開(kāi)源或者非開(kāi)源技術(shù)加入到項(xiàng)目中，項(xiàng)目成員也會(huì)變得越來(lái)越多，開(kāi)始各司其職對(duì)現(xiàn)在使用的各種軟件進(jìn)行運(yùn)行維護(hù)和實(shí)施部署。
一個(gè)項(xiàng)目的具體實(shí)施并不是編寫(xiě)一個(gè)應(yīng)用程序那么簡(jiǎn)單，還涉及到為應(yīng)用程序提供支撐的其他軟件，這為單獨(dú)成立軟件運(yùn)維部門(mén)提供了條件。
項(xiàng)目運(yùn)行時(shí)間長(zhǎng)了以后，會(huì)因?yàn)榧夹g(shù)落后或者性能瓶頸而進(jìn)行重構(gòu)，軟件運(yùn)維部門(mén)會(huì)和開(kāi)發(fā)部門(mén)合作，對(duì)項(xiàng)目架構(gòu)進(jìn)行重構(gòu)。
一般情況下開(kāi)發(fā)會(huì)拆分業(yè)務(wù)，形成分布式應(yīng)用程序，而應(yīng)用拆分成分布式，可以使用阿里的Dubbo或者SpringCloud搭建服務(wù)：
為了實(shí)現(xiàn)分布式系統(tǒng)，這里需要用到消息隊(duì)列，消息隊(duì)列的主要作用有3個(gè)：解耦、異步、削峰。
消息隊(duì)列可以選擇：RabbitMQ、ZeroMQ、ActiveMQ、Kafka。
軟件運(yùn)維部門(mén)和開(kāi)發(fā)部門(mén)融合
隨著技術(shù)的發(fā)展，近幾年自動(dòng)化運(yùn)維，自動(dòng)化部署，自動(dòng)化測(cè)試的興起，特別是DevOps概念的提出，運(yùn)維部門(mén)和開(kāi)發(fā)部門(mén)融合的趨勢(shì)越來(lái)越明顯。又開(kāi)始了開(kāi)發(fā)即是運(yùn)維的輪回，但這次不同的是，機(jī)器替代了人肉運(yùn)維。
DevOps就是開(kāi)發(fā)(Development)和運(yùn)維(Operations)這兩個(gè)領(lǐng)域的合并，那么，為什么要合并這兩個(gè)領(lǐng)域?
原因很多，但首要原因是：目前的兩個(gè)領(lǐng)域工作流程是脫節(jié)的，絕對(duì)的脫節(jié)。很多公司的開(kāi)發(fā)部門(mén)和運(yùn)維部門(mén)之間存在的深刻矛盾，其實(shí)就是這個(gè)“脫節(jié)”造成的。
為了解決“脫節(jié)”問(wèn)題，需要使用到很多自動(dòng)化工具，以及自動(dòng)化維護(hù)平臺(tái)。于是架構(gòu)進(jìn)一步升級(jí)：
持續(xù)開(kāi)發(fā)
與瀑布模型不同的是，軟件可交付成果被分解為短開(kāi)發(fā)周期的多個(gè)任務(wù)節(jié)點(diǎn)，在很短的時(shí)間內(nèi)開(kāi)發(fā)并交付。
這個(gè)階段包括編碼和構(gòu)建階段，并使用Git和SVN等工具來(lái)維護(hù)不同版本的代碼，以及Ant、Maven、Gradle等工具來(lái)構(gòu)建/打包代碼到可執(zhí)行文件中，這些文件可以轉(zhuǎn)發(fā)給自動(dòng)化測(cè)試系統(tǒng)進(jìn)行測(cè)試。
持續(xù)測(cè)試
在這個(gè)階段，開(kāi)發(fā)的軟件將被持續(xù)地測(cè)試Bug。對(duì)于持續(xù)測(cè)試，使用自動(dòng)化測(cè)試工具，如Selenium、TestNG、JUnit等。
這些工具允許質(zhì)量管理系統(tǒng)完全并行地測(cè)試多個(gè)代碼庫(kù)，以確保功能中沒(méi)有缺陷。
在這個(gè)階段，使用Docker容器實(shí)時(shí)模擬“測(cè)試環(huán)境”也是首選。一旦代碼測(cè)試通過(guò)，它就會(huì)不斷地與現(xiàn)有代碼集成。
持續(xù)集成
這是支持新功能的代碼與現(xiàn)有代碼集成的階段。由于軟件在不斷地開(kāi)發(fā)，更新后的代碼需要不斷地集成，并順利地與系統(tǒng)集成，以反映對(duì)最終用戶的需求更改。
更改后的代碼，還應(yīng)該確保運(yùn)行時(shí)環(huán)境中沒(méi)有錯(cuò)誤，允許我們測(cè)試更改并檢查它如何與其他更改發(fā)生反應(yīng)。
Jenkins是一個(gè)非常流行的用于持續(xù)集成的工具。使用Jenkins，可以從Git存儲(chǔ)庫(kù)提取最新的代碼修訂，并生成一個(gè)構(gòu)建，最終可以部署到測(cè)試或生產(chǎn)服務(wù)器。
可以將其設(shè)置為在Git存儲(chǔ)庫(kù)中發(fā)生更改時(shí)自動(dòng)觸發(fā)新構(gòu)建，也可以在單擊按鈕時(shí)手動(dòng)觸發(fā)。
持續(xù)部署
它是將代碼部署到生產(chǎn)環(huán)境的階段。在這里，我們確保在所有服務(wù)器上正確部署代碼。
如果添加了任何功能或引入了新功能，那么應(yīng)該準(zhǔn)備好迎接更多的網(wǎng)站流量。因此，系統(tǒng)運(yùn)維人員還有責(zé)任擴(kuò)展服務(wù)器以容納更多用戶。
由于新代碼是連續(xù)部署的，因此配置管理工具可以快速，頻繁地執(zhí)行任務(wù)。Puppet，Chef，SaltStack和Ansible是這個(gè)階段使用的一些流行工具。
容器化工具在部署階段也發(fā)揮著重要作用。Docker和Kubernetes是流行的工具，有助于在開(kāi)發(fā)，測(cè)試，登臺(tái)和生產(chǎn)環(huán)境中實(shí)現(xiàn)一致性。除此之外，它們還有助于輕松擴(kuò)展和縮小實(shí)例。
持續(xù)監(jiān)控
通過(guò)監(jiān)控軟件的性能來(lái)提高軟件的質(zhì)量。這種做法涉及運(yùn)營(yíng)團(tuán)隊(duì)的參與，他們將監(jiān)視用戶活動(dòng)中的錯(cuò)誤/系統(tǒng)的任何不正當(dāng)行為。
這也可以通過(guò)使用專用監(jiān)控工具來(lái)實(shí)現(xiàn)，該工具將持續(xù)監(jiān)控應(yīng)用程序性能并突出問(wèn)題。
使用的一些流行工具是Splunk、ELKStack、Nagios、NewRelic和Sensu。
這些工具可幫助密切監(jiān)視應(yīng)用程序和服務(wù)器，以主動(dòng)檢查系統(tǒng)的運(yùn)行狀況。它們還可以提高生產(chǎn)率并提高系統(tǒng)的可靠性，從而降低IT支持成本。
發(fā)現(xiàn)的任何重大問(wèn)題都可以向開(kāi)發(fā)團(tuán)隊(duì)報(bào)告，以便可以在持續(xù)開(kāi)發(fā)階段進(jìn)行修復(fù)。
小結(jié)
軟件架構(gòu)不是一蹴而就的，系統(tǒng)架構(gòu)并不是一開(kāi)始設(shè)計(jì)時(shí)就具備完整的高性能、高可用、高伸縮等特性的，它是隨著用戶量的增加，業(yè)務(wù)功能的擴(kuò)展逐漸演變完善的。
在這個(gè)過(guò)程中，開(kāi)發(fā)模式、技術(shù)架構(gòu)、設(shè)計(jì)思想也發(fā)生了很大的變化，就連技術(shù)人員也從幾個(gè)人發(fā)展到一個(gè)部門(mén)甚至一條產(chǎn)品線。
這就像物種的演變，從簡(jiǎn)單到復(fù)雜，但是越是復(fù)雜的生物，要生存所付出的代價(jià)也會(huì)越多。反而簡(jiǎn)單的生物存活的更久更好更成功，這就是遞弱代償。
系統(tǒng)架構(gòu)越來(lái)越復(fù)雜，確實(shí)能應(yīng)付很多情況，但付出的運(yùn)維成本也會(huì)越來(lái)越大，于是又開(kāi)始將分工出去的運(yùn)維部分融合，也許過(guò)一段時(shí)間，又會(huì)出現(xiàn)新的分工，誰(shuí)知道呢?
作者：李博文
簡(jiǎn)介：新炬網(wǎng)絡(luò)高級(jí)工程師。精通Java開(kāi)發(fā)和運(yùn)維，開(kāi)發(fā)過(guò)運(yùn)營(yíng)商系統(tǒng)，物聯(lián)網(wǎng)系統(tǒng)，電網(wǎng)系統(tǒng)，燃?xì)庀到y(tǒng)，高校系統(tǒng)等大型系統(tǒng)，擁有ITSS服務(wù)經(jīng)理，項(xiàng)目管理師，架構(gòu)師等認(rèn)證，擁有豐富的開(kāi)發(fā)經(jīng)驗(yàn)，擅長(zhǎng)軟件開(kāi)發(fā)與運(yùn)維。
