最近對架構設計系統的學習下，站在一定高度對系統的整體運營是有很好幫助的
a. 硬體法
1. 多個機器併發服務
2. 資料複製多份, 空間換時間
3. 頻寬復用和疊加網路裝置
b. 軟體法
1. 採用高快取. 將訪問量高的資訊放在記憶體中, 直接使用記憶體輸出
2. 精確定位. 減少定位搜尋時間, 包括索引等
3. 分歷史和新聞資訊儲存. 歷史訪問量低, 放在歷史庫. 新聞訪問量高, 放快取
web**架構思想
1.資料庫
資料庫伺服器作業系統的選擇：一般為linux，unix（aix，hpunix,solaires等）
資料庫的選擇 ：目前一般為oracle，mysql，db2，sqlserver
硬體的選擇：根據自己的業務需求
例如：資料庫伺服器作業系統為linux，資料庫選擇oracle10g ，cpu採用至強3g x 2或x4，記憶體8g或16g或以上，目前的cpu發展很快，很少成為瓶頸，我們就拿記憶體來衡量系統的最大併發連線，拿16g的記憶體來說按照oracle推薦的，分配給oracle例項的記憶體為物理記憶體的80%。那麼對於oltp應來，pga_aggregate_target(20%的空間用來進行pga的儲存)的值大約就是 2621mb[(16*1024mb×80%)×20%]。這些記憶體將被分配與pga區域，並且這個是和併發連線有直接關係的，每個併發的連線都需要一定量的pga記憶體以執行sql語句，假設每個使用者session平均需要1m（按照通常的經驗值）的空間來計算，那麼從併發連線數上來講，共可以支援近2600左右個併發連線數。
如果一台資料庫承載不了當前的業務，就要擴充套件；我們現在很幸運，因為已經很有多案例我們可以參考，因為這些案例都是經過實踐長時間驗證的，像擁有億級使用者的myspace社群，可以參考它的按使用者橫向擴充套件，用資料庫快取最終才解決myspace的資料庫瓶頸問題
2、網路架構
常用網路架構大都在硬體防火牆存在tcp併發連線瓶頸。通常平台使用web介面訪問，訪問方式採用tcp短連線方式傳輸資料，我們使用clearsight對與該平台業務類似的**以及阿里巴巴頁面的tcp連線數進行了測試，結果沒個頁面平均短連線數保持在30個左右。目前主流的高階企業防火牆（電信級防火牆除外）在理想情況下（防火牆不受到外界任何攻擊，防火牆不開啟任何附加的保護策略，只使用預設的防火牆策略）每秒tcp連線數可達30000併發，如果tcp連線在1秒內建立完成，則乙個分布式處理中心大約可以承受30000/30=1000個tcp併發。這一點不是非常滿意，這樣一來在分布式處理中心還要做些文章。
3、網路頻寬
對於網路頻寬，假設系統有1000個併發使用者數，網路是100mbps，則有效頻寬為12.5mbytes，每頁面的平均大小按照 100kb計算，那麼不管伺服器本身速度多快，最好的響應時間為：2000user*200kb/(12.5mbytes*1024) = 31.25秒，即：如果網路是100mbps的話，最好的頁面訪問執行時間也就是31.25秒。這樣無論伺服器的響應有多快，總是要在網路上傳輸這麼大的資料量。因此，網路將是乙個很大的瓶頸。如果網路是125mbytes即約1gbps，則響應時間是3.125秒，所以併發飆公升，頻寬費用將是一筆巨大的開支。
4、讀寫
假設最大的讀寫在伺服器，且配置如下：1、cpu：至強3g x 2，或同級別的其他cpu；2、記憶體：2g或以上；3、硬碟：300g x 2做raid 0或146g x 4做raid 1+0。就普通的伺服器而言，其使用的scsi硬碟的理論最大傳輸速度是320m/s，實際可能只有一半。按照系統需求中一般的頁面的響應時間應在5秒內（區域網內為3秒內，網際網路上一般應該在5秒內）的要求計算總流量為800m（按照實際值計算）。如果按照每個頁面上的的平均大小為100k來計算，普通配置伺服器可以承受8000使用者的流量。
有了這些資料我們在做系統架構的時候就知道如果規避種種問題，當然在架構階段盡可能的為公升級留有餘地。我喜歡在建樓之前畫盡可能多的圖紙，做盡可能多的實驗。不管怎樣我們都熱愛這份web大樓的建造，有的三兩層，有的幾十層甚至上百層。高度說明不了問題，關鍵在於你的心是否容的下這所建築！
還有一點，當我們的伺服器裡的很多的話，這也會成為瓶頸，有能力的話可以從新改寫管理的檔案系統，因為一般的檔案系統是通過目錄結構來查詢到資源的，這是很耗時的，如果通過類似索引的結構查詢到，那速度將會提高很大
程式架構思想
程式的架構的思想可以問下面此問題 1.目的 為什麼才有此架構？2.效果 使用此架構後，前後的效果會發生什麼變化。3.成本 使用此架構後開發的週期和成本。4.競品 此類產品的競品是什麼，有沒有更好的方案。4.優缺點 如 為什麼使用spring 目的 解耦，模組化，關注業務 效果 程式模組化，由容器管理...
REST RPC架構思想
rest rpc是乙個改進版的rpc架構，它是為了解決傳統的rpc和rest方案的一些不足之處而生的，它結合了rest api和rpc的優點，同時又克服了rest api和rpc的缺點。我們先來看看傳統的rpc和rest api方案的優點和一些不足之處。傳統的rpc一般是基於protobuf或thr...
架構 RESTful的架構思想
把軟體 software 平台 platform 基礎設施 infrastructure 做成服務 service 是很多it企業都一直在做的事情，這就是大家經常聽到的sass 軟體即服務 pass 平台即服務 和iass 基礎設定即服務 實現面向服務的架構 soa 有諸多的方式，包括rpc 遠端過...