1、系統架構圖如下：

2、系統各層介紹

以上採用五層的邏輯架構，第一層客戶層，第二層前端優化層，第三層應用層，第四層服務層，第五層數據存儲層，每層的介紹如下：

1、客戶層：支持PC瀏覽器和手機APP，可以直接通過IP訪問，反向代理伺服器。

2、前端層：使用DNS負載均衡，CDN本地加速及反向代理服務。

3、應用層：網站應用集群；按照業務進行垂直拆分，比如應用商城，產品服務等。

4、服務層：提供公共服務，比如產品升級服務，搜索服務，賬號管理服務等。

5、數據層：支持關係型資料庫集群（支持讀寫分離），NOSQL集群，分散式文件系統集群，及分散式Cache

3、各部分技術介紹

3.1 基礎設施技術介紹：

分散式緩存

        在高併發環境下，大量的讀、寫請求涌向資料庫，磁碟的處理速度和記憶體處理顯然不在一個數量級，從減輕資料庫壓力和提高系統響應速度兩個角度來考慮，一般都會在資料庫之前加一層緩存。由於單台機器的記憶體資源和承載能力有限，並且如果大量使用本地緩存，也會使相同的數據被不同的節點存儲多份，對記憶體資源造成較大的浪費，因此才催生出分散式緩存。

持久化存儲

        隨著科技的不斷發展，越來越多的人參與到互聯網中，人們在網路上的活動，如發表心情動態、微博、購物、評論等，這些信息最終被轉換為二進位位元組的數據存儲下來。面對併發訪問量的激增和數據幾何級的增長，如何存儲正在迅速膨脹並且不斷積累的數據，以及應對日益增長的用戶訪問頻次，成為亟待解決的問題。

消息系統

        在分散式系統中，消息系統應用十分廣泛，消息可以作為應用間通信的一種方式，消息被保存在隊列中，知道被接收者取出，由於消息發送者不需要同步等待消息接收者的響應，消息的非同步接收降低了系統集成的耦合度，提升了分散式系統協作的效率，使得系統能夠更快地響應用戶，提供更高的吞吐。當系統處理峰值壓力時，分散式消息隊列還能夠作為緩衝，削峰填谷，緩解集群的壓力，避免整個系統被壓垮。

        開源的消息系統有很多，包括Apache的ActiveMQ，Apache的Kafka、RabbitMQ、memcacheQ等。

搜索引擎

         這裡說的垂直化搜索引擎，與大家所熟知的Google和Baidu等互聯網搜索引擎存在著一些差別，垂直搜索引擎主要針對企業內部的自由數據的檢索，而不像Google和Baidu等搜索平臺，採用網路爬蟲對全網數據進行爬取，從而建立索引並提供給用戶進行檢索、模糊匹配的需求，解決資料庫like查詢效率低下的問題，又能夠解決分散式環境下，由於採用分庫分表或者使用NoSQL資料庫，導致無法進行多表聯合查詢或者進行複雜查詢的問題。

其它

        除了前面所提到的分散式緩存、持久化存儲、分散式消息系統、搜索引擎，大型的分散式系統的背後，還依賴於其他支撐系統，還包含實時計算、離線計算、分散式文件系統、日誌收集系統、監控系統、數據倉庫等，還有CDN系統、負載均衡系統、消息推送系統、自動化運維繫統等。

3.2 基礎設施技術技術特點

4、開發中的故障案例分析

（1）寫日誌引發的故障：

故障分析：由於日誌等級為info或debug，導致產生的日誌異常多，磁碟被撐爆。

實例： 在圖片伺服器的Nginx伺服器上，由於日誌列印的過多，導致磁碟爆滿，最終導致不能寫入數據信息。

解決方案： 需要將Nginx的配置信息修改為Error，定時檢測磁碟空間是否滿，及時增加硬碟空間。

（2） 高併發訪問資料庫引發的故障：

故障分析：當SQL的執行頻率非常高時，會使得資料庫的Load持續升高，影響資料庫的性能。

解決方案：儘量增加表的索引，減少全表掃描，嘗試使用分散式緩存和緩存設備。

（3）高併發情況下，鎖引發的故障：

故障分析：由於鎖的使用，某個操作，執行時間較長（如遠程過程調用），長期占有鎖，導致程式阻塞，當這個鎖被釋放時，其它            線程得以執行。

解決方案：使用鎖操作時要謹慎，慎之又慎。

（4）緩存應發的故障

故障分析：由於緩存伺服器集群的關閉，導致數據查詢的壓力全部都到資料庫層面，導致資料庫的壓力較大。

解決方案：緩存伺服器是當今網站中不可或缺的一部分，我們要像管理其他伺服器一樣，認真管理緩存伺服器。

（5）應用啟動不同步引發的故障

故障分析：由於啟動應用伺服器的不同步，如 Apahce + Tomcat 應用，服務 Apache先啟動，會導致過多的請求到Apache上，導致Tomcat已啟動後，過多的請求壓力到Tomcat上，嚴重情況下導致Tomcat的崩潰。

解決方案：要嚴格按照指定的順序進行啟動應用，避免“姑娘還沒有穿好衣服，老鴇就把客人給領進來了”，所以老鴇領客人進來時，要先確認姑娘有沒有準備好。

（6）大文件讀寫獨占磁碟引起的故障

故障分析：文件伺服器中保存的有大文件和小文件，小文件有幾十K  到上百K，大文件有幾十M到上百M，會導致用戶下載大文件時，獨占磁碟操作，影響小文件的讀寫操作。

解決方案：將圖片伺服器小的文件，使用專用的存儲伺服器如阿裡的分散式文件伺服器，大的文件使用分散式文件伺服器如HDFS伺服器

（7）濫用生產環境引起的故障

故障分析：開發人員儘量不要對運行環境進行處理

解決方案：將正式庫的許可權交給運維人員，嚴禁開發人員對正式數據進行處理。

（8）不規範流程引起的故障

故障分析：應用發佈後，引起資料庫LOAD迅速飆升，檢查用戶代碼是否有變化，是否緩存給註釋掉。如註釋掉緩存代碼。

解決方案：代碼提交前一定要對代碼進行DIFF比較，確認沒有提交不該提交的代碼（如測試註釋的代碼，正式部署需要使用的）

（9）不好的編程習慣引起的故障

故障分析：程式在處理一個輸入的對象時，不明確輸入的對象是否為空。

解決方案：要養成好的編碼習慣，輸入的對象儘量保證不為空，必要時構造空對象。

5、開發過程中的心得體會