常見的網站伺服器架構有哪些？

12-05

非原創，整理自：大型網站技術架構 (豆瓣)

1. 初始階段的網站架構

一般來講，大型網站都是從小型網站發展而來，一開始的架構都比較簡單，隨著業務複雜和用戶量的激增，才開始做很多架構上的改進。當它還是小型網站的時候，沒有太多訪客，一般來講只需要一台伺服器就夠了，這時應用程序、資料庫、文件等所有資源都在一台伺服器上，網站架構如下圖所示：

2. 應用服務和數據服務分離

隨著網站業務的發展和用戶量的增加，一台伺服器就無法再滿足需求了。大量用戶訪問導致訪問速度越來越慢，而逐漸增加的數據也會導致存儲空間不足。這時就需要將應用和數據分離，應用和數據分離後整個網站使用 3 台伺服器：應用伺服器、文件伺服器和資料庫伺服器。這 3 台伺服器對硬體資源的要求各不相同：

應用伺服器業務邏輯，需要強大的CPU

資料庫伺服器對磁碟讀寫操作很多，需要更快的磁碟和更大的內存

文件伺服器存儲用戶上傳的文件，因此需要更大的磁碟空間

此時，網站系統的架構如下圖所示：

3. 使用緩存改善網站性能

隨著用戶再增加，網站又會一次面臨挑戰：資料庫壓力太大導致整站訪問效率再此下降，用戶體驗受到影響。一個網站，往往 80% 的業務訪問集中在 20% 的數據上，比如微博請求量最多的肯定是那些千萬級粉絲的大 V 的微博，而幾乎沒有人關注的你的首頁，除了自己想起來之外根本不會被打開。既然大部分業務訪問集中在一小部分數據上，那就把這一小部分數據先提前緩存在內存中，而不是每次都去資料庫讀取，這樣就可以減少資料庫的訪問壓力，從而提高整個網站的訪問速度。
網站使用的緩存一般分為緩存到應用伺服器或者緩存在專門的分散式緩存伺服器。緩存到應用伺服器自己的訪問速度快很多，但是受自身內存限制，往往不太適用。遠程分散式緩存使用一個集群專門負責緩存服務，當內存不夠還可以輕鬆得動態擴容。

4. 使用應用伺服器集群改善網站的並發處理能力

使用緩存後，數據訪問壓力得到了緩解，但是單一應用伺服器能夠處理的請求連接有限，在網站訪問高峰期，應用伺服器就成了整個網站的效率瓶頸。使用分散式集群是網站解決高並發、海量數據問題的常用手段。當一台伺服器的處理能力和存儲空間不足時，不要嘗試去更換更強大的伺服器，對大型網站而言，多麼強大的伺服器，都滿足不了網站持續增長的業務需求。這種情況下，更恰當的做法是增加一台伺服器分擔原有伺服器的訪問及存儲壓力。對網站架構而言，只要能通過增加一台伺服器的方式改善負載壓力，就可以以同樣的方式持續增加伺服器不斷改善系統性能，從而實現系統的可伸縮性。應用伺服器實現集群是網站可伸縮架構設計中較為簡單成熟的一種，如下圖所示：

通過負載均衡調度伺服器，可以將來自用戶瀏覽器的訪問請求分發到應用伺服器集群中的任何一台伺服器上，如果有更多用戶，就在集群中加入更多的應用伺服器，使應用伺服器的壓力不再成為整個網站的瓶頸。

5. 資料庫讀寫分離

網站在使用緩存後，使對大部分數據讀操作訪問都可以不通過資料庫就能完成，但是仍有一部分讀操作（緩存訪問不命中、緩存過期）和全部的寫操作都需要訪問資料庫，在網站的用戶達到一定規模後，資料庫因為負載壓力過高而成為網站的瓶頸。目前大部分的主流資料庫都提供主從熱備功能，通過配置兩台資料庫主從關係，可以將一台資料庫伺服器的數據更新同步到另一台伺服器上。網站利用資料庫的這一功能，實現資料庫讀寫分離，從而改善資料庫負載壓力。如下圖所示：
應用伺服器在寫數據的時候，訪問主資料庫，主資料庫通過主從複製機制將數據更新同步到從資料庫，這樣當應用伺服器讀數據的時候，就可以通過從資料庫獲得數據。為了便於應用程序訪問讀寫分離後的資料庫，通常在應用伺服器端使用專門的數據訪問模塊，使資料庫讀寫分離對應用透明。

6. 使用反向代理和 CDN 加速網站響應

隨著網站業務不斷發展，用戶規模越來越大，由於中國複雜的網路環境，不同地區的用戶訪問網站時，速度差別也極大。有研究表明，網站訪問延遲和用戶流失率正相關，網站訪問越慢，用戶越容易失去耐心而離開。為了提供更好的用戶體驗，留住用戶，網站需要加速網站訪問速度。主要手段有使用 CDN 和反向代理。如下圖所示：

7. 使用分散式文件系統和分散式資料庫系統

任何強大的單一伺服器都滿足不了大型網站持續增長的業務需求。資料庫經過讀寫分離後，從一台伺服器拆分成兩台伺服器，但是隨著網站業務的發展依然不能滿足需求，這時需要使用分散式資料庫。文件系統也一樣，需要使用分散式文件系統。如下圖所示：

分散式資料庫是網站資料庫拆分的最後手段，只有在單表數據規模非常龐大的時候才使用。不到不得已時，網站更常用的資料庫拆分手段是業務分庫，將不同業務的數據部署在不同的物理伺服器上。

8. 使用 NoSQL 和搜索引擎

隨著網站業務越來越複雜，對數據存儲和檢索的需求也越來越複雜，網站需要採用一些非關係資料庫技術如 NoSQL 和非資料庫查詢技術如搜索引擎。如下圖所示：

NoSQL 和搜索引擎都是源自互聯網的技術手段，對可伸縮的分散式特性具有更好的支持。應用伺服器則通過一個統一數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。

9. 業務拆分

大型網站為了應對日益複雜的業務場景，通過使用分而治之的手段將整個網站業務分成不同的產品線。如大型購物交易網站都會將首頁、商鋪、訂單、買家、賣家等拆分成不同的產品線，分歸不同的業務團隊負責。
具體到技術上，也會根據產品線劃分，將一個網站拆分成許多不同的應用，每個應用獨立部署。應用之間可以通過一個超鏈接建立關係（在首頁上的導航鏈接每個都指向不同的應用地址），也可以通過消息隊列進行數據分發，當然最多的還是通過訪問同一個數據存儲系統來構成一個關聯的完整系統，如下圖所示：

10. 分散式服務

隨著業務拆分越來越小，存儲系統越來越龐大，應用系統的整體複雜度呈指數級增加，部署維護越來越困難。由於所有應用要和所有資料庫系統連接，在數萬台伺服器規模的網站中，這些連接的數目是伺服器規模的平方，導致資料庫連接資源不足，拒絕服務。
既然每一個應用系統都需要執行許多相同的業務操作，比如用戶管理、商品管理等，那麼可以將這些共用的業務提取出來，獨立部署。由這些可復用的業務連接資料庫，提供共用業務服務，而應用系統只需要管理用戶界面，通過分散式服務調用共用業務服務完成具體業務操作。如下圖所示：

大型網站的架構演化到這裡，基本上大多數的技術問題都可以得以解決了。

2013/04/18 更新

[只是大框架介紹，實際使用中的不容易注意的細節太多了，需要經驗的積累，才能運用嫻熟]

以下的架構都是在假設已經優化過linux內核的情況下進行

初級篇：（單機模式）

假設配置：（Dual core 2.0GHz,4GB ram,SSD）

基礎框架：apache(PHP) + Mysql / IIS + MSSQL
（最基礎框架，處理一般訪問請求）

進階1：替換Apache為Nginx，並在資料庫前加上cache層【資料庫的速度是最大的瓶頸】
Nginx(PHP) + Memcache + Mysql
（此時已經具備處理小型訪問量的能力）

進階2：隨著訪問量的上漲，最先面臨的問題就來了：CGI無法匹配上Nginx的高IO性能，這時候可以通過寫擴展來替代腳本程序來提升性能，C擴展是個好辦法，但是大家更喜歡用簡單的腳本語言完成任務，Taobao團隊開源了一個Nginx_lua模塊，可以用lua寫Nginx擴展，這時候可處理的並發已經超越進階1 一個檔次了。
Nginx(nginx_lua or C) + Memcache + Mysql
（此時處理個同時在線三四千人沒有問題了）

進階3：隨著用戶的增多，Mysql的寫入速度成了又一大瓶頸，讀取有memcache做緩存，但寫入是直接面對Mysql，性能受到了很大阻礙，這時候，要在Nginx和Mysql中間加入一層寫緩存，隊列系統就出場了,就以RabbitMQ為例，所有寫入操作全部丟到這隻兔子的胃裡面，然後屁股後面寫個接應程序，一條條的拉出來再寫入mysql。而RabbitMQ的寫入效率是Mysql的N倍，此時架構的處理能力又上一階層。
|----write------&>RabbitMQ--------
Nginx（lua or c）----- |---------&>Mysql
|----read------&>Memcache--------

(此時的並發吞吐能力已經可以處理萬人左右在線)

中級篇：（分而治之）

此時我們在單機優化上已經算是達到極限，接下來就要集群來顯示作用了。

資料庫篇： 資料庫總是在整個環節中是吞吐能力最弱的，最常見的方法就是sharding。
sharding可以按多種方法來分，沒有定式，看情況。可以按用戶ID區段分，按讀寫分等等，可用參考軟體：mysql proxy（工作原理類似lvs）

緩存篇：memcache一般採用的是構建memcache pool，將緩存分散到多台memcache節點上，如何將緩存數據均勻分散在各節點，一般採用將各節點順序編號，然後hash取余對應到各個節點上去。這樣可以做到比較均勻的分散，但是有一個致命點就是，如果節點數增加或減少，將會帶來幾乎80%的數據遷移，解決方案我們在高級篇再提。

WEB伺服器篇： web伺服器集群的建設，最常見的就是lvs方式(memcache pool同樣可以如此組建)，lvs的核心就是調度節點，調度節點負責將流量通過演算法分散到各個節點上，因調度所耗資源很少，所以可以產生很高的吞吐率，後台節點數量可以任意增刪，但此法弊病就是如果調度節點掛了，則整個集群都掛了，解決方案我們在高級篇提。
方法2:參見 HAProxy - The Reliable, High Performance TCP/HTTP Load Balancer

高級篇：（高可用性+高可擴展性的集群）

單點調度故障解決：
集群的好處顯而易見，但是有一個弊端就是單節點進行調度，如果節點出現故障，則整個集群全部都無法服務，對此的解決方案，我們使用keepalived來解決。Keepalived for Linux
keepalived是基於VRRP協議（VRRP協議介紹）的，請一定先了解VRRP協議後再進行配置。
keepalived可以把多台設備虛擬出一個IP，並自動在故障節點與備用節點之間實現failover切換。這樣我們配置兩台貨多台lvs調度節點，然後配置好keepalived就可以做到lvs調度節點出現故障後，自動切換到備用調度節點。（同樣適用於mysql）

memcache集群擴展解決：
memcache因為我們一般採用的都是hash後除以節點數取余，然後分配到對應節點上，如果節點數出現變化，以前的緩存數據將基本都不能命中。
解決方法：consistent hashing 簡介：一致性哈希

consistent hashing大概的思路就是，把hash後的值保證在 0 ~ (2^32)-1 的數值上，然後把這一連串數字對應映射到一個想像的圓上。

把要存儲的各個值hash後，放到圓上，如圖

然後把cache節點也用同樣的hash方法，映射到圓上，然後每個剛才hash過的value順時針尋找離自己最近的節點，這個節點就是存儲它的節點。

為了提高存儲的平衡性，演算法還可以加入虛擬節點的概念，即每個實際cache節點，會在圓上對應N個虛擬的節點，這樣可以提高演算法的命中率，更加平衡。

consistent hashing原理：Consistent hashing and random trees

完結。
另：以上圖片來自互聯網，未找到原創者，故未標註來源。
歡迎署名轉載。

系統架構演化歷程-初始階段架構

初始階段的小型系統應用程序、資料庫、文件等所有的資源都在一台伺服器上通俗稱為LAMP

特徵：
應用程序、資料庫、文件等所有的資源都在一台伺服器上。

描述：
通常伺服器操作系統使用linux，應用程序使用PHP開發，然後部署在Apache上，資料庫使用Mysql，彙集各種免費開源軟體以及一台廉價伺服器就可以開始系統的發展之路了。

系統架構演化歷程-應用服務和數據服務分離

好景不長，發現隨著系統訪問量的再度增加，webserver機器的壓力在高峰期會上升到比較高，這個時候開始考慮增加一台webserver

特徵：
應用程序、資料庫、文件分別部署在獨立的資源上。

描述：
數據量增加，單台伺服器性能及存儲空間不足，需要將應用和數據分離，並發處理能力和數據存儲空間得到了很大改善。

系統架構演化歷程-使用緩存改善性能

特徵：
資料庫中訪問較集中的一小部分數據存儲在緩存伺服器中，減少資料庫的訪問次數，降低資料庫的訪問壓力。

描述：
系統訪問特點遵循二八定律，即80%的業務訪問集中在20%的數據上。
緩存分為本地緩存和遠程分散式緩存，本地緩存訪問速度更快但緩存數據量有限，同時存在與應用程序爭用內存的情況。

系統架構演化歷程-使用應用伺服器集群

在做完分庫分表這些工作後，資料庫上的壓力已經降到比較低了，又開始過著每天看著訪問量暴增的幸福生活了，突然有一天，發現系統的訪問又開始有變慢的趨勢了，這個時候首先查看資料庫，壓力一切正常，之後查看webserver，發現apache阻塞了很多的請求，而應用伺服器對每個請求也是比較快的，看來是請求數太高導致需要排隊等待，響應速度變慢

特徵：
多台伺服器通過負載均衡同時向外部提供服務，解決單台伺服器處理能力和存儲空間上限的問題。

描述：
使用集群是系統解決高並發、海量數據問題的常用手段。通過向集群中追加資源，提升系統的並發處理能力，使得伺服器的負載壓力不再成為整個系統的瓶頸。

系統架構演化歷程-資料庫讀寫分離

享受了一段時間的系統訪問量高速增長的幸福後，發現系統又開始變慢了，這次又是什麼狀況呢，經過查找，發現資料庫寫入、更新的這些操作的部分資料庫連接的資源競爭非常激烈，導致了系統變慢

特徵：
多台伺服器通過負載均衡同時向外部提供服務，解決單台伺服器處理能力和存儲空間上限的問題。

描述：
使用集群是系統解決高並發、海量數據問題的常用手段。通過向集群中追加資源，使得伺服器的負載壓力不在成為整個系統的瓶頸。

系統架構演化歷程-反向代理和CDN加速

特徵：
採用CDN和反向代理加快系統的訪問速度。

描述：
為了應付複雜的網路環境和不同地區用戶的訪問，通過CDN和反向代理加快用戶訪問的速度，同時減輕後端伺服器的負載壓力。CDN與反向代理的基本原理都是緩存。

系統架構演化歷程-分散式文件系統和分散式資料庫

隨著系統的不斷運行，數據量開始大幅度增長，這個時候發現分庫後查詢仍然會有些慢，於是按照分庫的思想開始做分表的工作

特徵：
資料庫採用分散式資料庫，文件系統採用分散式文件系統。

描述：
任何強大的單一伺服器都滿足不了大型系統持續增長的業務需求，資料庫讀寫分離隨著業務的發展最終也將無法滿足需求，需要使用分散式資料庫及分散式文件系統來支撐。
分散式資料庫是系統資料庫拆分的最後方法，只有在單表數據規模非常龐大的時候才使用，更常用的資料庫拆分手段是業務分庫，將不同的業務資料庫部署在不同的物理伺服器上。

系統架構演化歷程-使用NoSQL和搜索引擎

特徵：
系統引入NoSQL資料庫及搜索引擎。

描述：
隨著業務越來越複雜，對數據存儲和檢索的需求也越來越複雜，系統需要採用一些非關係型資料庫如NoSQL和分資料庫查詢技術如搜索引擎。應用伺服器通過統一數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。

系統架構演化歷程-業務拆分

特徵：
系統上按照業務進行拆分改造，應用伺服器按照業務區分進行分別部署。

描述：
為了應對日益複雜的業務場景，通常使用分而治之的手段將整個系統業務分成不同的產品線，應用之間通過超鏈接建立關係，也可以通過消息隊列進行數據分發，當然更多的還是通過訪問同一個數據存儲系統來構成一個關聯的完整系統。

縱向拆分：
將一個大應用拆分為多個小應用，如果新業務較為獨立，那麼就直接將其設計部署為一個獨立的Web應用系統

縱向拆分相對較為簡單，通過梳理業務，將較少相關的業務剝離即可。

橫向拆分：將復用的業務拆分出來，獨立部署為分散式服務，新增業務只需要調用這些分散式服務

橫向拆分需要識別可復用的業務，設計服務介面，規範服務依賴關係。

系統架構演化歷程-分散式服務

特徵：
公共的應用模塊被提取出來，部署在分散式伺服器上供應用伺服器調用。

描述：
隨著業務越拆越小，應用系統整體複雜程度呈指數級上升，由於所有應用要和所有資料庫系統連接，最終導致資料庫連接資源不足，拒絕服務。

這個問題之寬泛已經跨越銀河系了_(:з」∠)_
哥哥我只能從初級到高級一點點解釋了~~~~

圈子裡有一個偉人說過一句話：
億萬級的架構是逐步演化出來的，傻缺才會上來就直接照著億萬級的來搭(′?`) ...（沒錯這個偉人就是我），所以這裡只是解釋下不同量級下的架構形式，具體要看業務規模和體量。

補一個，中小型網站推薦的技術選型LAMP ( linux+apache+mysql+php )。
大型網站的架構技術則可以靈活選擇。

新生兒：
最初的網站一般只是個demo，老闆拿去給朋友們看看，恩，小夥子網站做的不錯，給你加工資∠( ? 」∠)＿，這個時期資源成本和時間成本第一，一般程序，資料庫，文件都放在一台伺服器，如下圖：

這個時期可以說不存在太多架構的概念，apache/ IIS + MYSQL/MSSQL + PHP/JAVA/NET 等選型都可以，具體看公司的技術合伙人的方向，技術合伙人來確定方案和選型即可。

1周歲：
度過了前期的磨合，業務量開始穩步上升之後就建議開始做分離的工作了，可以根據伺服器的用途不同，選用不同的配置安排：

假設業務情況涉及到的文件會比較多，建議可以做多台文件伺服器對文件進行儲存，比如電商類的商品文描圖片及主圖，多域名，多伺服器儲存。
即便是業務初期，也建議至少有一台熱備伺服器，不需要太高的配置，實時對業務資料庫進行備份即可。

2周歲：
一般到了這個階段之後，為了減輕資料庫壓力防止鎖死，以及提高訪問速度，可以開始考慮對核心業務做分散式緩存處理了。
一般來講，業務初期可以考慮使用一些成熟的緩存引擎，比如resin等，將搜索，商品詳情，CMS等頁面基於此做緩存處理。
另外就是現在CDN服務的費用目前來講成本要比以往低很多了，所以這個階段可以考慮購買CDN的服務了：

5周歲：
如果進入這個階段，那麼首先恭喜你，開始走上正軌了&<(￣▽￣)&>
一般到了這個階段，隨著訪問量逐漸增加，即便有緩存的存在，資料庫仍舊會有很大的瓶頸，尤其是電商類網站高並發下單的場景，或者知乎這類一堆人給我點贊刷評論的情況（雖然並沒有╮(╯_╰)╭，一般初步改善資料庫壓力的方案就是做讀寫分離，然後進一步的操作就是分庫分表。

另外一點就是，考慮到業務量極大，為了防止出現線上事故影響服務，另外就是分擔網站入口的請求，因此需要部署負載均衡伺服器。因為網站是一輛需要一直跑的汽車，不能停車換輪，負載均衡的作用之一就是保證每次修輪胎的時候，車子仍然在跑：

------------------------------------------
啊...要忙了，回來接著寫，如果點贊的人多，就給你們看看我們集團的服務中心的架構~~~

可以看看這本書
http://book.douban.com/subject/25723064/

大型網站技術架構

開源流行的架構幾乎都是下面這些技術拼裝的
LAMP LNMP NOSQL /Memcached/Redis LVS KeepAlived Haproxy HeartBeat ......

其實很多大公司都會把自己的架構公開，只有國內公司藏著掖著

Evernote：http://blog.evernote.com/tech/2011/05/17/architectural-digest/
Dropbox：http://www.youtube.com/watch?v=PE4gwstWhmc
Facebook：http://www.makeuseof.com/tag/facebook-work-nuts-bolts-technology-explained/
StackOverflow：http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html P.S. 僅有的一個Windows-based技術堆棧

其他慢慢補充

一行字就可以描述：

根據瓶頸的優先順序拆流水線到多台機器上，使得總吞吐率得以達標並且流水線的每個環節的吞吐率前後匹配

初始階段的網站架構

應用服務和數據服務分離

使用緩存改善網站性能

使用應用伺服器集群改善網站的並發處理能力

資料庫讀寫分離

使用反向代理和 CDN 加速網站響應

使用分散式文件系統和分散式資料庫系統

使用 NoSQL 和搜索引擎

業務拆分

分散式服務

Atitit 常用的軟體架構與架構模式（相對固定總結的架構方法） attilax總結

1.1. 主進化路線Cs》》 bs 》3層架構》 SOA》rest》MSA(微服務架構 1

1.2. 做軟體架構設計時,根據不同的抽象層次可分為三種不同層次的模式：架構模式(Architectural Pattern)、設計模式(Design Pattern)、代碼模式(Coding Pattern)。 1

2. 架構模式常常劃分成如下的幾種：類型 2

3. 常用的軟體架構（hybrid， 2

3.1. Cs》》 bs 》3層架構》 SOA》rest》MSA(微服務架構 2

3.2. 分層架構是使用最多的架構模式 Layers模式也稱Tiers模式 2

3.3. MVC架構 3

3.4. 微內核架構 ?Microkernel（微核）模式 3

3.5. 元模型架構： 3

3.6. 管道-過濾器架構： 2.2.2　Pipes and Filters模式 3

3.7. 點對點（Peer to Peer）對等風格 3

3.8. 其他架構 3

1.1. 主進化路線Cs》》 bs 》3層架構》 SOA》rest》MSA(微服務架構

1.2. 做軟體架構設計時,根據不同的抽象層次可分為三種不同層次的模式：架構模式(Architectural Pattern)、設計模式(Design Pattern)、代碼模式(Coding Pattern)。

架構模式是一個系統的高層次策略，涉及到大尺度的組件以及整體性質和力學。架構模式的好壞可以影響到總體布局和框架性結構。

設計模式是中等尺度的結構策略。這些中等尺度的結構實現了一些大尺度組件的行為和它們之間的關係。模式的好壞不會影響到系統的總體布局和總體框架。設計模式定義出子系統或組件的微觀結構。

代碼模式（或成例）是特定的範例和與特定語言有關的編程技巧。

2. 架構模式常常劃分成如下的幾種：類型

一、模塊結構(From Mud to Structure)型。幫助架構師將系統合理劃分，避免形成一個對象的海洋。包括Layers（分層）模式、Blackboard（黑板）模式、Pipes/Filters（管道/過濾器）模式等。

二、分散系統（Distributed Systems）型。為分散式系統提供完整的架構設計，包括像Broker（中介）模式等。

三、人機互動（Interactive Systems）型，支持包含有人機互動介面的系統的架構設計，例子包括MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。

四、Adaptable Systems型，支持應用系統適應技術的變化、軟體功能需求的變化。如Reflection（反射）模式、Microkernel（微核）模式等。

3. 常用的軟體架構（hybrid，

3.1. Cs》》 bs 》3層架構》 SOA》rest》MSA(微服務架構

3.2. 分層架構是使用最多的架構模式Layers模式也稱Tiers模式

3.3. MVC架構

3.4. 微內核架構?Microkernel（微核）模式

3.5. 元模型架構：

元模型架構就是有元數據支撐的架構，現在使用的也很廣泛，比如：ORM,.Net 類的設計等都是元數據支持的。元數據有自我描述性比如ORM會描述類對應資料庫中的表屬性對應資料庫里的欄位，還有IOC類中的引用需要注入哪個類等等都會通過元數據的形式實現。IOC框架通過解析元數據信息使注入和被注入類只通過介面依賴，這樣替換注入類很方便。元數據架構是很靈活的架構，可發展空間非常大，元數據架構會經常用反射技術或者動態代碼生成技術。我之前做了一個ORM就是用到的元數據架構，我還想給ORM添加依賴注入面向切面編程等特性都很方便的。

3.6. 管道-過濾器架構： 2.2.2　Pipes and Filters模式　

5.這個模式就像是工廠的流水線，生產原料通過流水線經過很多環節進行處理變成產品。軟體也是一樣的，網路OSI7層就是消息通過管道內部的很多步處理對消息進行加工過濾轉換。再舉一個例子，兩家企業需要信息交換，但是企業的信息格式和描述規則都不相同，如果想達到交換必須經過處理，所以我們就得用管道過濾器模式，通過管道過濾器模式信息進入管道我們會在管道里添加各種處理功能，比如：數據驗證，信息加密，信息解密，信息壓縮，信息解壓縮，格式轉換等功能，對消息進行處理以符合我們要求的消息格式，而且如果需要添加一個新的處理只要把處理的功能插入到管道中即可，這樣達到最大的靈活性。應用此模式的有：ASP.Net請求模型，Spring 對象構造，Structs 數據請求等。

3.7. 點對點（Peer to Peer）對等風格

3.8. 其他架構

2.2.3　Blackboard模式　

SSH架構 ssm架構，java net lamp架構大泥球風格批量順序處理風格分發-訂閱風格 map-reduce風格 orm ioc

[分享] 軟體架構設計之常用架構模式介紹 - chunjuzhong的專欄 - 博客頻道 - CSDN.NET.html

主要軟體類型　適用　的幾種典型的　架構模式 - dzldzl - 博客園.html

軟體架構模式基本概念及三者區別 - jsd2root的博客 - 博客頻道 - CSDN.NET.html

《面向模式的軟體架構，卷1：模式系統》(（德）布施曼　等著)【簡介_書評_在線閱讀】 - 噹噹圖書.html

《恰如其分的軟體架構(軟體架構設計新經典)》(（美）George Fairbanks 著 )【簡介_書評_在線閱讀】 - 噹噹圖書.html

其實，計算機專業本科程度的演算法與數據結構，已經給出了網站伺服器的完整架構原理，從簡單到複雜，從單機到分散式跨地域。你只需要熟知這些組件即可。

http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html