系統(tǒng)架構(gòu)是靈活的，根據(jù)需求的不同，不一定每一層的技術(shù)都需要使用。例如：一些簡單的
CRM系統(tǒng)可能在產(chǎn)品初期并不需要K-V作為緩存朦佩；一些系統(tǒng)訪問量不大，并且可能只有一臺業(yè)務(wù)服務(wù)器存在庐氮，所以不需要運用負載均衡層吕粗。業(yè)務(wù)系統(tǒng)間通信層并沒有加入傳統(tǒng)的
HTTP請求方式。這是因為HTTP請求-響應(yīng)的延遲比較高旭愧，并且有很多次和正式請求無關(guān)的通信（這在下面的內(nèi)容中會詳細講到）颅筋。所以，傳統(tǒng)的HTTP請求方式并不適合在兩個高負載系統(tǒng)之間使用输枯，其更多的應(yīng)用場景是各種客戶端（WEB议泵、IOS、Android等）->服務(wù)器端的請求調(diào)用桃熄。我們把業(yè)務(wù)編碼中常使用的緩存系統(tǒng)歸入到數(shù)據(jù)存儲層先口，是因為類似于
Redis這樣的K-V存儲系統(tǒng)，從本質(zhì)上講是一種鍵值數(shù)據(jù)庫瞳收。為什么Redis會很快以至于可以作為緩存使用碉京，我將在隨后的文章中進行詳細的描述。還有一點需要注意的是螟深，上面架構(gòu)圖中的每層之間實際上不存在絕對的聯(lián)系（例如負載層一定會把請求轉(zhuǎn)送的業(yè)務(wù)層谐宙，這樣的必然性是不存在的），在通常情況下各層是可以跨越訪問的界弧。舉例說明：如果
HTTP訪問的是一張圖片資源凡蜻，負載層不會把請求送到業(yè)務(wù)層，而是直接到部署的分布式文件系統(tǒng)上尋找圖片資源并返回垢箕。再比如運用LVS做Mysql負載時划栓，負載層是直接和數(shù)據(jù)存儲層進行合作。
