服務器架構，說簡單不簡單，說復雜不復雜，前段時間我們請到了國內服務器頂級攻城獅，他把服務器那點事講得如此通透簡單。
對於一個剛起步的創業公司，不需要考慮太多復雜的服務器架構，能把業務跑起來就行了。但是在早期業務邏輯設計時，懂一些稍微復雜的服務器架構的邏輯，后面可以少走很多彎路。
下面這個圖估計大家都明白，這就是最基礎的服務器架構。傻瓜式的方法是把應用服務器、文件服務器、數據庫服務器全部混合在一起，呵呵呵！但這並不是最科學的。
當業務量持續增加到一定量以后，執行應用程序、讀寫文件、訪問數據庫應該有所區分，保證各自的需求都能得到滿足，這時候你需要考慮把應用服務器、文件服務器、數據庫服務器分離，這個時候的服務器架構應該是下面這樣的，它是由三個獨立的服務器組成，各司其職。
隨着業務量持續增加，應用程序訪問緩存數據會成為瓶頸，這個時候需要增加本地緩存，有的也需要分布式緩存。分布式緩存是指緩存部署在多個服務器組成的服務器集群中，以集群的方式提供緩存服務，其架構方式主要有兩種，一種是以JBoss Cache為代表的需要同步更新的分布式緩存，一種是以Memchached為代表的互不通信的分布式緩存。如下圖：
接下來，應用服務器需要更多台以應對復雜的業務邏輯，那么就需要負載均衡調度服務器來調度和分配應用服務器的工作任務。
再往后，需要考慮數據庫服務器的承壓能力，通常可以采用主從式數據庫服務器架構，把讀、寫兩部分分開，既可以提高數據訪問的安全性，也能提高數據讀寫的效率。
隨着業務量暴增，單一區域的服務器帶寬將不能承載全國的業務需求，這時候需要增加反向代理和CDN服務器。CDN系統能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上。其目的是使用戶可就近取得所需內容，解決 Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度。
同樣，服務器架構師應該分析文件服務器和數據庫服務器的網絡讀寫速度，進一步部署分布式的架構。
對於有搜索和大量查詢的網絡業務，還需要增加獨立的搜索引擎和NoSQL服務器。
對於更復雜的系統，還需要進一步拆分應用服務器，增加消息隊列服務器。增加消息隊列服務器有以下幾點好處：
1，由於消息隊列服務器的速度遠遠高於數據庫服務器，所以能夠快遞處理並返回數據；
2，消息隊列服務器具有更好的擴展性；
3，在高並發的情況下，延遲寫入數據庫，可以有效降低數據庫的壓力。
對於一些超大型綜合互聯網業務，應用服務器也需要分布式的架構，這個時候在不同業務的應用服務器之間做好消息協同會有較大的挑戰。
原文：https://blog.csdn.net/daogla/article/details/72877153