去年由于項目的需要，有時間看了看軟件架構(gòu)設(shè)計，讀了些書和論文，以前認為架構(gòu)師做的工作不太多，看完之后，感覺自己和架構(gòu)師還有一段路程，筆者認為架構(gòu)師不僅要熟悉技術(shù)，業(yè)務(wù)和管理，更重要的是要有自己的思想，架構(gòu)設(shè)計在我看來，他不是技術(shù)，而是一種藝術(shù)。我喜歡藝術(shù)，我熱愛架構(gòu)，以前在自己的學(xué)習(xí)道路上總是渺茫，似乎現(xiàn)在找到了方向。
通過一段時間的學(xué)習(xí)讓我認識了互聯(lián)網(wǎng)軟件架構(gòu)，企業(yè)應(yīng)用軟件架構(gòu)，嵌入式軟件架構(gòu)和有線或無線網(wǎng)絡(luò)架構(gòu)。以及在一個方面的各種架構(gòu)，比如我們經(jīng)常忽略的安全架構(gòu)。
希望 blog 友推薦一下，在架構(gòu)方面如何進一步學(xué)習(xí)的方法，如何把自己塑造成一個名副其實的架構(gòu)師。
自己也整理了一個 ppt ，里面有以前公司產(chǎn)品線架構(gòu)圖（自己回憶畫的，如有產(chǎn)權(quán)問題請及時通知）
/Files/Jack2007/jackwang.pdf
優(yōu)庫上的視頻，有時間看看，挺好的！
http://v.youku.com/v_playlist/cz00f1701561o9p0.html
高煥堂老師的視頻------如何成為一個合格的架構(gòu)師，非常棒！！！
http://live.csdn.net/Issue518/LivePlay.aspx
架構(gòu)筆錄：
1、網(wǎng)站流量影響整個網(wǎng)站架構(gòu)的設(shè)計
2、網(wǎng)站架構(gòu)的設(shè)計是一種平衡的設(shè)計，沒有完美的架構(gòu)，架構(gòu)的設(shè)計要簡單靈活，便于擴充，因此找出平衡點是關(guān)鍵
3、網(wǎng)站架構(gòu)的設(shè)計不要過渡，考慮到1~2年內(nèi)的用戶需求即可
4、小網(wǎng)站與大網(wǎng)站的區(qū)別在于，當數(shù)據(jù)量達到一定級別，小問題會變成大問題
5、大的網(wǎng)站架構(gòu)不適合做小事情，小架構(gòu)也做不了大事情
6、即使通過硬件的擴充，架構(gòu)的負荷已經(jīng)超過設(shè)計負荷的5~10倍，就要考慮重新設(shè)計系統(tǒng)的架構(gòu)，舉例來說就是一個研發(fā)團隊是10個人以內(nèi)，可以采用家長式管理，而到100人以內(nèi)，管理方式必須變化，因此架構(gòu)也要根據(jù)負荷情況不斷變化
7、要通過網(wǎng)站的監(jiān)控分析，來找到系統(tǒng)瓶頸的臨界點
8、任何一個網(wǎng)站的開發(fā)都會是從集中式-分布式-高級分布式的方向過渡
9、Google可以通過機器的擴充來達到網(wǎng)站擴展的要求，依賴的是系統(tǒng)架構(gòu)設(shè)計中的線性可擴展性
10、中國的網(wǎng)站架構(gòu)和運營要考慮自身的網(wǎng)絡(luò)運營環(huán)境如網(wǎng)通和電信網(wǎng)絡(luò)的區(qū)別
11、網(wǎng)站架構(gòu)的設(shè)計也要考慮運營成本的問題，能得到的資源往往比預(yù)期的要少
12、架構(gòu)的設(shè)計要考慮安全性和惡意客戶的攻擊
13、網(wǎng)站的負載要通過測試來驗證，并通過監(jiān)控系統(tǒng)進行分析，并且要做好風(fēng)險的應(yīng)對，系統(tǒng)的負載永遠不要超過80%
14、架構(gòu)的設(shè)計中無時無刻不存在折中的情況，痛苦的取舍是必須作出的抉擇
15、架構(gòu)設(shè)計中要充分考慮團隊、領(lǐng)導(dǎo)和用戶間的溝通，龍的那片不能動的鱗也要有策略的動一動
16、架構(gòu)設(shè)計要充分分析數(shù)據(jù)的特性，讀和寫哪個更重要，例如Google的搜索根本不用數(shù)據(jù)庫，甚至連文件系統(tǒng)都進行重寫，以達到最快的數(shù)據(jù)讀取效果
17、網(wǎng)站架構(gòu)的設(shè)計要考慮API接口的開放性
補充1：
1、網(wǎng)站架構(gòu)是一門平衡藝術(shù)，永遠在性能和需求之間尋求平衡
2、Taobao在生態(tài)圈上考慮了很久，很有可能會推出重量級的OpenAPI，具體是什么，值得期待
3、騰訊產(chǎn)品在產(chǎn)品穩(wěn)定性要求很高，單組服務(wù)產(chǎn)品的壓力測試非常嚴格，最終把大訪問問題轉(zhuǎn)化為添加服務(wù)器問題
4、完美的緩存機制需要考慮穩(wěn)定性、事務(wù)處理和分布式，memCache是其中較簡單的實現(xiàn)
5、監(jiān)控程序?qū)崟r報警，比如同期超過5%的正常波動
6、產(chǎn)品經(jīng)理要溶入技術(shù)團隊，避免過度設(shè)計
7、用戶每上一個臺階，架構(gòu)設(shè)計將迥然不同
本博客為學(xué)習(xí)交流用，凡未注明引用的均為本人作品，轉(zhuǎn)載請注明出處，如有版權(quán)問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學(xué)習(xí)進步。