前言
服務器架構圖多以物理視圖呈現，物理視圖用於描述系統軟件到物理硬件的映射關係，反映出系統的組件是如何部署到一組可計算機器節點上，用於指導系統的部署實施過程。受衆多爲運維和實施人員。
其實服務器架構如何架設完全根據業務場景，數據量或者用戶量等因素進行衡量，並沒有什麼架設方案是一定的，遵循“兩利相權取其重”，經過綜合考量後，選擇最優方案。
以下根據不同場景進行服務器架構架設進行物理視圖展示（以下示例均以物理服務器爲節點，不考慮虛擬化分割和容器部署情況）。
一、單臺服務器
一般在用戶量不多，應用使用頻率不高，數據量不太大，業務場景相對簡單情況下，單臺服務器就可以滿足使用。也就是一臺服務器上只運行應用容器(如tomcat)和數據庫，讓系統運行起來，用戶能通過網絡訪問即可，單臺服務器不存在應用於數據庫網絡連接問題，因爲應用和數據同在一臺服務器，完全的"本地"環境；當然應用訪問壓力和數據負載壓力都由一臺服務器承擔。其實這種完全單臺的情況，一般都用於測試環境或者開發環境，再簡單的生產環境至少再多一個災備服務器會顯得更優雅。
二、應用、數據服務器分離
如果隨着用戶量的增長和數據量的增大，應用服務器與數據服務器分離是邁出"分佈"的第一步。只需要應用服務器新增一個遠程調用數據庫服務器的連接，有效的緩解了應用服務器負載的壓力。當應用服務器和數據服務器需要通過網絡連接時，則有可能由於兩個服務器之間網絡問題導致數據傳輸上丟包或者出現數據丟失情況。不過隨着網絡技術的發展及解決方案的豐富，當數據量或應用訪問不太大的情況下，這種擔憂完全可以忽略。
三、應用、數據、文件服務器"三劍客"
隨着系統使用，當文件越來越多，對應用服務器的硬盤存儲也是一個挑戰，讓文件集中化管理顯得很有必要。應用服務器只管訪問的事兒，數據服務器只存儲應用數據(數據庫數據)，而文件服務器對各種靜態文件集中管理，同時釋放應用服務器存儲空間。
至於文件服務器到底是做成一個FTP協議的"專業"文件服務器，還是隻是把文件分服務器存儲，依然使用http協議，就看業務需要了，不過對於FTP管理、http管理總結了以下對比，FTP:
1、完全基於網絡，具有網絡文件的上傳與下載特性。如支持斷點續傳，不受工作組與IP地址限制等。
2、擁有完善的用戶權限管理系統，比起網絡共享來說，可以詳細設置每個用戶的權限。如只能上傳，不能修改或刪除等。
3、安全性高，可以進行數據的加密傳輸。更好保護個人隱私。
與網絡共享(http)對比：使用上感覺不如網絡共享方便，網絡共享的文件可以像本地文件一樣使用。而FTP必須是下載下來才能使用。
應用服務器與文件服務器分離優缺點
優點：由於處於兩個服務器，可以做到訪問的分流，減少應用服務器壓力，正常用戶訪問和文件下載上傳不共享一個服務器帶寬，做到分帶寬，如果在文件和應用都在一個服務器會存在上傳下載時候，其它訪問很慢。且分開的話文件統一管理比較整潔。
缺點：由於處於兩個服務器，涉及到跨域訪問問題，需要先把網絡傳輸搞定。兩個服務器互相通信時，可能存在網絡丟包現象，需要特殊處理。
備註：如果承載多種類型的文件服務器，可以是文檔格式，可以是視頻，可以是圖片，支持各種類型文件，需要開啓多種協議，比如：HTTP，FTP，RTSP，RTMP。流媒體協議主要是三種：HTTP、RTSP、RTMP。
四、應用集羣，加入負載均衡
對一個應用，利用負載均衡器部署到多臺服務器上(未對業務進行拆分)，優化了訪問請求在服務器組之間的分配，消除了服務器之間的負載不平衡，從而提高了系統的反應速度與總體性能，當然負載均衡器也可以調整每臺服務器負載的權重。同時負載均衡器也可以也可實現故障轉移，當一臺服務器崩潰時候，把訪問轉到另外可用服務器上，提高了系統架構的可靠性。
在此階段，可以在同一服務器下實現動靜分離，也就是最初版的前後端分離，用nginx管理並啓動前端靜態文件工程，tomcat管理後端應用和動態數據。同時一個nginx服務也可以對多個tomcat服務，tomcat服務之間存在負載均衡和故障轉移。
負載均衡器的存在提高了架構的擴展性，簡化了管理難度。關於負載均衡故障轉移有很多內容要講，多囉嗦幾句，負載均衡可大致分爲DNS負載均衡，反向代理負載均衡，基於NAT負載均衡，其中反向代理負載均衡使用較廣。當然如果單臺負載均衡器感覺不夠高可用，也可對負載均衡器進行多臺部署，做好災備。
應用集羣加入負載均衡後，需要注意幾點問題：①單點登錄②使用session+cookie維護用戶③當一臺服務器或者多臺服務器崩潰，所有的請求由原來的均衡分佈瞬間集中到一臺服務器或少數幾臺服務器，需要用戶請求突然集中化的處理機制，防止服務器集中接收過多請求而癱瘓。
五、數據庫集羣，讀寫分離
應用服務器負載均衡後，隨着流量和數據的增加，數據庫服務器遇到瓶頸，需要對數據庫實行集羣策略，對數據庫訪問分流。
實行讀寫分離同時，可以加入數據庫本地緩存策略。如果數據庫讀寫分離，需要注意數據同步問題。
六、加入搜索引擎
加入搜索引擎集羣后，需要注意索引數據同步問題：實時增量、定時全量等。
七、加入緩存服務器
目前最常用的緩存數據庫是redis，一般加入緩存服務，除了分擔讀數據庫的訪問壓力之外，緩存服務還有數據限流、高速隊列、事件發佈訂閱等效果。加入緩存，主要需要注意的兩個問題：緩存穿透與緩存雪崩。
緩存穿透
緩存只是爲了緩解數據庫壓力而添加的一層保護層，當從緩存中查詢不到我們需要的數據就要去數據庫中查詢了。如果被黑客利用，頻繁去訪問緩存中沒有的數據，那麼緩存就失去了存在的意義，瞬間所有請求的壓力都落在了數據庫上，這樣會導致數據庫連接異常。
緩存雪崩
緩存雪崩是指緩存不可用或者大量緩存由於超時時間相同在同一時間段失效，大量請求直接訪問數據庫，數據庫壓力過大導致系統雪崩。
對於緩存相關問題解決方案，網上有很多方法，此處不做描述。到了這一步，服務架構還不算分佈式架構，只能算高可用架構。
八、數據庫水平拆分、垂直拆分
比如，商品和用戶兩個數據庫原來處於同一個數據服務器，由於數據量不斷增長，把商品和用戶兩個數據庫分別放在兩個數據庫服務器，這種按業務分割業務數據，其實就是垂直拆分。垂直拆分後，要注意不同服務器之間數據關聯與同步問題。
如果當商品服務器又達到性能瓶頸，需要對服務器繼續擴展，把同樣的商品數據庫的數據按條件分到擴展服務器上，這種就屬於水平拆分。
九、應用服務器垂直拆分
把應用服務器，按業務進行垂直拆分，A業務服務器只負責A業務，B業務服務器只負責B業務，C業務服務器只負責C業務。並對每個業務服務器做好負載及災備。
例如，按業務拆分的3個服務器的對應三個域名：
urlA.com，urlB.com，urlC.com
根據不同域名請求訪問不同服務器，如果涉及到用戶需要查詢業務A或業務B，直接在用戶服務器裏寫DAO層查詢業務A或業務B數據庫表。
此步需要注意的問題：業務服務器之間調用問題
十、前後端服務器分離
當服務器訪問量繼續加大的時候，可添加專門的用於管理前端工程的服務器，爲前後端在一個服務器做訪問壓力分離。至於前端服務器與後端的應用服務器如何關聯，則由實際業務場景判斷，本文不做描述。至於更多細節，比如CDN服務器等不做描述。
十一、微服務
到此步就不是web應用服務了，應用服務進一步抽離爲服務節點，應用服務通過調用服務節點來實現整體系統，不但讓系統充分解耦，又可以使服務之間緊密相連。這一步已經屬於微服務了，微服務之間的調用和消息是需要注意的重中之重。架構的選擇不需要跟隨"潮流"，不是因爲微服務火就要把所有項目都做成微服務，要充分判斷用戶受衆及用戶量之後，再做架構的選擇。要讓技術爲業務做服務，用技術去驅動業務，驅動發展，而不是要讓業務給技術讓路。
十二、加入數據中心
到這步，應用層已經架構完畢，爲實現數據驅動而加入數據中心，實現數據統一管理。讓不斷增長的數據價值實際落地。
