天下大勢，分久必合，合久必分。——《三國演義》第一回;越簡單越穩(wěn)定，越高級越脆弱，遞弱代償。——《物演通論》王東岳

[[320099]]

圖片來自 Pexels

軟件項目最初沒有的運維部門

大概 12 年前，最初進入軟件開發(fā)領(lǐng)域，那時一個人需要學(xué)很多的開發(fā)技能和運維技能，上能后端做服務(wù)，下能前端寫頁面，左能做 DBA，右能做架構(gòu)，中間還能運維。

那時開發(fā)和運維其實沒有界限，基本都是一體的，當(dāng)然也有可能因為公司規(guī)模不是特別大，所以分工也沒有那么細，也聽說過專門有運維部門的公司，但是那時軟件運維人員的水平也只能做重復(fù)性的工作。

硬件和網(wǎng)絡(luò)運維這里不講，而那種比較貴的 DBA，中小公司一般不會請，所以基本上開發(fā)≈運維。

軟件生命周期中最長的部分在運維階段，在那個時候開發(fā)是要負責(zé)整個生命周期的。

那個時候架構(gòu)很簡單，有的應(yīng)用程序、數(shù)據(jù)庫、文件都部署在一臺服務(wù)器上：

或者是分開部署，將應(yīng)用程序、數(shù)據(jù)庫、文件各自部署在獨立的服務(wù)器上，并且根據(jù)服務(wù)器的用途配置不同的硬件，達到最佳的性能效果：

數(shù)據(jù)庫的選擇一般情況下有三個：大、中型系統(tǒng)使用 Oracle 或者 MSSQL，畢竟會有廠商進行支持，DBA 的質(zhì)量也比較高。

小型系統(tǒng)一般使用 MySQL，使用的好壞基本依賴開發(fā)人員對 MySQL 的熟悉程度。

然而到了今天，會有專業(yè)的人在做開源或者非開源數(shù)據(jù)庫的維護，數(shù)據(jù)庫市場也迎來了百花齊放的春天。

隨著業(yè)務(wù)擴展開始出現(xiàn)分工

當(dāng)越來越多的人開始使用軟件系統(tǒng)，開發(fā)的工作日漸繁忙，多數(shù)時候在忙著寫代碼和做項目，運維的工作很多時候無法抽身。

這個時候會將幾個之前開發(fā)系統(tǒng)的程序員組成一個新的組織，這個就是軟件運維部門的雛形，他們?yōu)榱私鉀Q一些性能上的問題，可能改變系統(tǒng)架構(gòu)與部署，比如加入緩存：

在大部分系統(tǒng)中，都會利用緩存技術(shù)改善系統(tǒng)的性能，使用緩存主要源于熱點數(shù)據(jù)的存在，大部分訪問都遵循 28 原則(即 80% 的訪問請求，最終落在 20% 的數(shù)據(jù)上)。

所以我們可以對熱點數(shù)據(jù)進行緩存，減少這些數(shù)據(jù)的訪問路徑，提高用戶體驗。

緩存實現(xiàn)常見的方式是本地緩存、分布式緩存。本地緩存，顧名思義是將數(shù)據(jù)緩存在應(yīng)用服務(wù)器本地，可以存在內(nèi)存中，也可以存在文件，OSCache 就是常用的本地緩存組件。

本地緩存的特點是速度快，但因為本地空間有限所以緩存數(shù)據(jù)量也有限。

分布式緩存的特點是，可以緩存海量的數(shù)據(jù)，并且擴展非常容易，在軟件系統(tǒng)中常常被使用，速度按理沒有本地緩存快，常用的分布式緩存是 Memcached、Redis。

當(dāng)然在用戶量繼續(xù)增長的情況下，應(yīng)用服務(wù)器作為系統(tǒng)的入口，會承擔(dān)大量的請求，我們往往通過應(yīng)用服務(wù)器集群來分擔(dān)請求數(shù)。

應(yīng)用服務(wù)器前面部署負載均衡服務(wù)器調(diào)度用戶請求，根據(jù)分發(fā)策略將請求分發(fā)到多個應(yīng)用服務(wù)器節(jié)點這時：

常用的負載均衡技術(shù)硬件的有 F5，價格比較貴，軟件的有 LVS、Nginx、HAProxy。

LVS 是四層負載均衡，根據(jù)目標(biāo)地址和端口選擇內(nèi)部服務(wù)器，Nginx 是七層負載均衡和 HAProxy 支持四層、七層負載均衡，可以根據(jù)報文內(nèi)容選擇內(nèi)部服務(wù)器。

因此 LVS 分發(fā)路徑優(yōu)于 Nginx 和 HAProxy，性能要高些，而 Nginx 和 HAProxy 則更具配置性，如可以用來做動靜分離(根據(jù)請求報文特征，選擇靜態(tài)資源服務(wù)器還是應(yīng)用服務(wù)器)。

隨著用戶量繼續(xù)增加，數(shù)據(jù)庫成為最大的瓶頸，改善數(shù)據(jù)庫性能常用的手段是進行讀寫分離以及分表，讀寫分離顧名思義就是將數(shù)據(jù)庫分為讀庫和寫庫，通過主備功能實現(xiàn)數(shù)據(jù)同步。

分庫分表則分為水平切分和垂直切分，水平切換則是對一個數(shù)據(jù)庫特大的表進行拆分，例如用戶表。

垂直切分則是根據(jù)業(yè)務(wù)不同來切換，如用戶業(yè)務(wù)、商品業(yè)務(wù)相關(guān)的表放在不同的數(shù)據(jù)庫中：

業(yè)務(wù)量越來越大，產(chǎn)生的文件越來越多，單臺的文件服務(wù)器已經(jīng)不能滿足需求。需要分布式的文件系統(tǒng)支撐。

常用的分布式文件系統(tǒng)有 NFS：

由于項目數(shù)據(jù)量持續(xù)增加，數(shù)據(jù)庫的壓力會越來越大，并且傳統(tǒng)關(guān)系型數(shù)據(jù)無法處理海量數(shù)據(jù)。

這時需要分離數(shù)據(jù)存儲，對于海量數(shù)據(jù)的查詢和分析，我們使用 NoSQL 數(shù)據(jù)庫和大數(shù)據(jù)技術(shù)再加上搜索引擎可以達到更好的性能。

常用的 NoSQL 數(shù)據(jù)庫有 MongoDB、HBase(依賴 Hadoop 大數(shù)據(jù))、Redis，搜索引擎有 Lucene、Solr、Elasticsearch 等：

單獨軟件運維部門

當(dāng)越來越多的開源或者非開源技術(shù)加入到項目中，項目成員也會變得越來越多，開始各司其職對現(xiàn)在使用的各種軟件進行運行維護和實施部署。

一個項目的具體實施并不是編寫一個應(yīng)用程序那么簡單，還涉及到為應(yīng)用程序提供支撐的其他軟件，這為單獨成立軟件運維部門提供了條件。

項目運行時間長了以后，會因為技術(shù)落后或者性能瓶頸而進行重構(gòu)，軟件運維部門會和開發(fā)部門合作，對項目架構(gòu)進行重構(gòu)。

一般情況下開發(fā)會拆分業(yè)務(wù)，形成分布式應(yīng)用程序，而應(yīng)用拆分成分布式，可以使用阿里的 Dubbo 或者 Spring Cloud 搭建服務(wù)：

為了實現(xiàn)分布式系統(tǒng)，這里需要用到消息隊列，消息隊列的主要作用有 3 個：解耦、異步、削峰。

消息隊列可以選擇：RabbitMQ、ZeroMQ 、ActiveMQ 、Kafka。

軟件運維部門和開發(fā)部門融合

隨著技術(shù)的發(fā)展，近幾年自動化運維，自動化部署，自動化測試的興起，特別是 DevOps 概念的提出，運維部門和開發(fā)部門融合的趨勢越來越明顯。又開始了開發(fā)即是運維的輪回，但這次不同的是，機器替代了人肉運維。

DevOps 就是開發(fā)(Development)和運維(Operations)這兩個領(lǐng)域的合并，那么，為什么要合并這兩個領(lǐng)域?

原因很多，但首要原因是：目前的兩個領(lǐng)域工作流程是脫節(jié)的，絕對的脫節(jié)。很多公司的開發(fā)部門和運維部門之間存在的深刻矛盾，其實就是這個“脫節(jié)”造成的。

為了解決“脫節(jié)”問題，需要使用到很多自動化工具，以及自動化維護平臺。于是架構(gòu)進一步升級：

持續(xù)開發(fā)

與瀑布模型不同的是，軟件可交付成果被分解為短開發(fā)周期的多個任務(wù)節(jié)點，在很短的時間內(nèi)開發(fā)并交付。

這個階段包括編碼和構(gòu)建階段，并使用 Git 和 SVN 等工具來維護不同版本的代碼，以及 Ant、Maven、Gradle 等工具來構(gòu)建/打包代碼到可執(zhí)行文件中，這些文件可以轉(zhuǎn)發(fā)給自動化測試系統(tǒng)進行測試。

持續(xù)測試

在這個階段，開發(fā)的軟件將被持續(xù)地測試 Bug。對于持續(xù)測試，使用自動化測試工具，如 Selenium、TestNG、JUnit 等。

這些工具允許質(zhì)量管理系統(tǒng)完全并行地測試多個代碼庫，以確保功能中沒有缺陷。

在這個階段，使用 Docker 容器實時模擬“測試環(huán)境”也是首選。一旦代碼測試通過，它就會不斷地與現(xiàn)有代碼集成。

持續(xù)集成

這是支持新功能的代碼與現(xiàn)有代碼集成的階段。由于軟件在不斷地開發(fā)，更新后的代碼需要不斷地集成，并順利地與系統(tǒng)集成，以反映對最終用戶的需求更改。

更改后的代碼，還應(yīng)該確保運行時環(huán)境中沒有錯誤，允許我們測試更改并檢查它如何與其他更改發(fā)生反應(yīng)。

Jenkins 是一個非常流行的用于持續(xù)集成的工具。使用 Jenkins，可以從 Git 存儲庫提取最新的代碼修訂，并生成一個構(gòu)建，最終可以部署到測試或生產(chǎn)服務(wù)器。

可以將其設(shè)置為在 Git 存儲庫中發(fā)生更改時自動觸發(fā)新構(gòu)建，也可以在單擊按鈕時手動觸發(fā)。

持續(xù)部署

它是將代碼部署到生產(chǎn)環(huán)境的階段。在這里，我們確保在所有服務(wù)器上正確部署代碼。

如果添加了任何功能或引入了新功能，那么應(yīng)該準(zhǔn)備好迎接更多的網(wǎng)站流量。因此，系統(tǒng)運維人員還有責(zé)任擴展服務(wù)器以容納更多用戶。

由于新代碼是連續(xù)部署的，因此配置管理工具可以快速，頻繁地執(zhí)行任務(wù)。Puppet，Chef，SaltStack 和 Ansible 是這個階段使用的一些流行工具。

容器化工具在部署階段也發(fā)揮著重要作用。Docker 和 Kubernetes 是流行的工具，有助于在開發(fā)，測試，登臺和生產(chǎn)環(huán)境中實現(xiàn)一致性。除此之外，它們還有助于輕松擴展和縮小實例。

持續(xù)監(jiān)控

通過監(jiān)控軟件的性能來提高軟件的質(zhì)量。這種做法涉及運營團隊的參與，他們將監(jiān)視用戶活動中的錯誤/系統(tǒng)的任何不正當(dāng)行為。

這也可以通過使用專用監(jiān)控工具來實現(xiàn)，該工具將持續(xù)監(jiān)控應(yīng)用程序性能并突出問題。

使用的一些流行工具是 Splunk、ELK Stack、Nagios、NewRelic 和 Sensu。

這些工具可幫助密切監(jiān)視應(yīng)用程序和服務(wù)器，以主動檢查系統(tǒng)的運行狀況。它們還可以提高生產(chǎn)率并提高系統(tǒng)的可靠性，從而降低 IT 支持成本。

發(fā)現(xiàn)的任何重大問題都可以向開發(fā)團隊報告，以便可以在持續(xù)開發(fā)階段進行修復(fù)。

小結(jié)

軟件架構(gòu)不是一蹴而就的，系統(tǒng)架構(gòu)并不是一開始設(shè)計時就具備完整的高性能、高可用、高伸縮等特性的，它是隨著用戶量的增加，業(yè)務(wù)功能的擴展逐漸演變完善的。

在這個過程中，開發(fā)模式、技術(shù)架構(gòu)、設(shè)計思想也發(fā)生了很大的變化，就連技術(shù)人員也從幾個人發(fā)展到一個部門甚至一條產(chǎn)品線。

這就像物種的演變，從簡單到復(fù)雜，但是越是復(fù)雜的生物，要生存所付出的代價也會越多。反而簡單的生物存活的更久更好更成功，這就是遞弱代償。

系統(tǒng)架構(gòu)越來越復(fù)雜，確實能應(yīng)付很多情況，但付出的運維成本也會越來越大，于是又開始將分工出去的運維部分融合，也許過一段時間，又會出現(xiàn)新的分工，誰知道呢?

作者：李博文

簡介：新炬網(wǎng)絡(luò)高級工程師。精通 Java 開發(fā)和運維，開發(fā)過運營商系統(tǒng)，物聯(lián)網(wǎng)系統(tǒng)，電網(wǎng)系統(tǒng)，燃氣系統(tǒng)，高校系統(tǒng)等大型系統(tǒng)，擁有 ITSS 服務(wù)經(jīng)理，項目管理師，架構(gòu)師等認證，擁有豐富的開發(fā)經(jīng)驗，擅長軟件開發(fā)與運維。