最近和幾個朋友談到時下流行的Web 2.0，提到了其中最重要的角色——架構(gòu)師。多方各有爭執(zhí)，不外乎是因為職業(yè)背景和視角的緣故。包括架構(gòu)一詞，本身就從建筑學借鑒而來，至于架構(gòu)師，則可以簡單地從建筑學的設(shè)計師來引申，不外乎就是設(shè)計結(jié)構(gòu)，設(shè)計一個大樓的結(jié)構(gòu)。回到軟件本身，那就可以簡單地理解為負責設(shè)計軟件框架的人了。

我們沒有討論清楚架構(gòu)師、軟件架構(gòu)師、系統(tǒng)架構(gòu)師及其Web 架構(gòu)師這些看似相同卻有所區(qū)別的角色的關(guān)鍵區(qū)別，本身見仁見智，也不是一時半會能夠說清楚的，最后我們討論了作為一個Web 2.0 網(wǎng)站架構(gòu)師需要的一些基本的知識和能力（個人看法，難免有失偏頗）：

1，熟知你的業(yè)務(wù)模式和目標人群

這是最重要的，Web 2.0 本質(zhì)上是以Web 作為平臺的應(yīng)用，如果不真正了解你的業(yè)務(wù)，不了解用戶的核心需求，不了解你目標客戶的典型行為，是很難做好網(wǎng)站的。從這個角度來講，一個Web 架構(gòu)師首先必須是一個出色的產(chǎn)品經(jīng)理。大多時候，我們只要做到業(yè)務(wù)技術(shù)領(lǐng)先就足夠了，一味地追求技術(shù)的先進性反倒會深陷泥潭。

在技術(shù)和業(yè)務(wù)之間找到一個平衡，也就意味著必須明白整個業(yè)務(wù)核心的競爭力在哪里？目標人群的基本訴求在哪里？然后選擇最低成本的技術(shù)來實現(xiàn)業(yè)務(wù)需求，但是反過來，又必須適當?shù)貫闃I(yè)務(wù)拓展保留適當?shù)目臻g。

打個比方說，如果是一個以照片分享為目的應(yīng)用，你可以將注冊程序?qū)懙臓€一點（但是不可以爛到不能動），你可以將幫助系統(tǒng)做的不那么好看一點，但是上傳照片和瀏覽照片絕對不可以慢，你可以數(shù)據(jù)庫設(shè)計的不是那么好，但是存儲問題絕對要慎重，絕對不能夠在照片超過1 萬張后，網(wǎng)站速度就和牛一般……

只有真正理解你所要做的事情，技術(shù)那玩意兒才可能變得可愛起來。

2，了解負載均衡策略實現(xiàn)

不管怎樣的Web2.0，怎樣的業(yè)務(wù)，你都必須做一個關(guān)鍵的假設(shè)：你的流量一定會上漲的，單臺機器一定不能夠滿足你業(yè)務(wù)發(fā)展的需求。我相信這樣的假設(shè)是合理的，沒有一個Web 2.0 公司相信他們可以用一臺機器來改變世界。

并不是要求從一開始就設(shè)計一個理想化的負載均衡策略，那樣未免有些過于“未雨綢繆”，但是作為一個Web 架構(gòu)師，一定要給自己留下一些“分家”的余地。因此適當?shù)亓私獠煌瑢用娴呢撦d均衡策略實現(xiàn)是必要的。

一般來說，在小規(guī)模發(fā)展初期，適當?shù)乜紤]數(shù)據(jù)庫分拆和按照業(yè)務(wù)進行域名分拆就足夠了。在中等規(guī)模的情況下，可能需要適當?shù)夭杉{硬件或者軟件Load-Balancer，在這種場景中，Web 層面的負載均衡你可以通過F5/NetWare 那樣的硬件來幫你實現(xiàn)，當然了，選擇Apache 或者更加專業(yè)的負載均衡軟件也未嘗不可，比如Windows 下面的NLB 和Linux 下面的LVS 。而為了實現(xiàn)負載均衡，在應(yīng)用服務(wù)器層面作一些適當?shù)恼{(diào)整也是必要的，至少此刻不能夠讓你隨心所欲地使用session 變量了（其實也并不是完全不可用），而一旦你采用了緩存（Web 2.0 有誰不知道MemCached？），如果考慮不夠周全，本來單機環(huán)境下好好的應(yīng)用到頭來就會變得亂七八糟，本質(zhì)上無非是數(shù)據(jù)不同步的問題，其實反過來想，你把流量和壓力分解了，數(shù)據(jù)各自為政了，不出問題也是沒有天理的。

言歸正傳，作為一個Web 架構(gòu)師，必須了解負載均衡策略的不同實現(xiàn)，更要了解負載均衡之后可能引發(fā)的問題和關(guān)鍵點，對此一無所知，在面子上也是說不過去的。

3，設(shè)計“合理”的存儲

該沒有人打算將所有的東西存儲在一個關(guān)系數(shù)據(jù)庫里面吧，也該沒有人可以說，一個Web 2.0 網(wǎng)站用一個關(guān)系數(shù)據(jù)庫可以解決問題。如果說Web 2.0 是以用戶為中心，那么也可以說成是以用戶數(shù)據(jù)為核心價值，應(yīng)用的核心驅(qū)動是數(shù)據(jù)。沒有辦法討論是應(yīng)該用關(guān)系數(shù)據(jù)庫還是不用關(guān)系數(shù)據(jù)庫，許多東西就是在其中找到一個平衡，一個“合理”的平衡。

傳統(tǒng)的存儲會分為SAN 、NAS 和DAS，只不過隨著技術(shù)的發(fā)展，其中的邊界越來越模糊，模糊的可以甚至讓你忘記其中的差別，你盡管看好口袋里的銀子，大致明白有多少銀子能夠辦多少事情就可以了。但是你還是需要去做選擇，對于Web 應(yīng)用而言，大多還是PC 服務(wù)器，也可能許多人熱衷于通過相對廉價的設(shè)備構(gòu)建諸如GFS 那樣的存儲架構(gòu)。

許多人認為Web 2.0 最關(guān)鍵的是業(yè)務(wù)，“用錢可以解決的問題，就不是問題”，這話是對的，在早期如果就將架構(gòu)設(shè)計為未來5-10 年的架構(gòu)，架構(gòu)師的這種“遠見”必定成為日后的笑柄，但是反過來不去考慮任何數(shù)據(jù)分布的可能，如此短見終究會自食其果。

再看看實際情況中，架構(gòu)師應(yīng)該如何面對呢？在啟動階段，簡單而直接的關(guān)系型數(shù)據(jù)庫就可以了，你并不需要花費太多的精力去考慮，只要大致測算出一臺服務(wù)器的容納能力，然后估算出在到達容納能力上限的一半左右，你有多少的時間可以去折騰，如此而已，也真夠了。簡單地說，粗魯一點，一臺文件服務(wù)器，一臺數(shù)據(jù)庫服務(wù)器，只要別犯愚蠢錯誤，諸如文件只有一個目錄，完全不可拆分，如數(shù)據(jù)庫只有一個表，耦合了太多邏輯等等，既然沒有，那就放手去做。而在業(yè)務(wù)發(fā)展到一定規(guī)模，如已經(jīng)有10 萬用戶，不考慮你的存儲已經(jīng)不可能了，此時我們會發(fā)現(xiàn)，諸多性能問題是因為不太合理的存儲問題而導(dǎo)致的，這個時候存儲設(shè)計更多是應(yīng)對性能而考慮的。而在發(fā)展到更大規(guī)模，存儲的可管理性和成本問題逐步成為關(guān)鍵。

對于架構(gòu)師而言，不同時期選擇不同的設(shè)計策略是尤為重要的，沒有最好的，只有合理的架構(gòu)，存儲亦然。

4，異構(gòu)平臺的整合能力

如果從企業(yè)應(yīng)用的角度而言，絕對不贊成一個系統(tǒng)中有多個平臺的，那會無謂地增加集成的成本，過去的“數(shù)據(jù)孤島”是最好的證明。那么究竟Web 架構(gòu)師是在一個平臺上爐火純青就夠了，還是能夠在多個平臺之間漂移為好呢？

我們來重新定義“平臺”的含義， 我簡單地把它理解成兩個層面的，一個是操作系統(tǒng)層面，一個是開發(fā)語言層面，當然討論開來，問題就大了，可以說框架，可以說數(shù)據(jù)庫，可以說協(xié)議等等。但是有一點必須肯定，操作系統(tǒng)是你業(yè)務(wù)軟件層面的基礎(chǔ)，而開發(fā)語言是實現(xiàn)業(yè)務(wù)的工具，而兩者結(jié)合起來，都有一些推薦的經(jīng)典架構(gòu)，.NET 方面是Windows 2003/2008+Sql Server +IIS 6.0，然后通過Visual Studio 2005/2008，以微軟為依托，完全使用他們提供的服務(wù)。LAMP 則是Linux+Apache+MySql+Php， J2EE Web 架構(gòu)則普遍接受為Hibernate+Spring+Struts，至于RoR、Python，這是明星式的后起之秀。

一個Web 架構(gòu)師去仔細考察哪個平臺孰優(yōu)孰劣是愚蠢的，除了能夠精通一個平臺，那樣能夠讓你處理業(yè)務(wù)的時候得心應(yīng)手，但最好還能夠同時熟悉另外一個平臺，雖然我們可以說時代已經(jīng)變了，所有的都是XML，都是標準的REST調(diào)用，但是你真的能夠保證嗎？大多應(yīng)用都是.NET 寫的，需要提供一個論壇，你用了Discuz，你需要適當?shù)匦薷臉I(yè)務(wù)，雖然論壇本身的定制功能很強大，但是要嵌入特定的業(yè)務(wù)，不至于對LAMP 一無所知吧，那樣連統(tǒng)一登錄的問題都不好解決，當然了，也可以為自己說我不需要它，因為有別的可以選擇，但是有一點也是事實，你無法隨心所欲地根據(jù)業(yè)務(wù)需要增加最適合你業(yè)務(wù)的模塊。

在我個人的理解，一個好的架構(gòu)師最好能夠同時熟悉兩種操作系統(tǒng)，兩個以上的開發(fā)語言，一個方面是現(xiàn)實世界的業(yè)務(wù)復(fù)雜度使然，一個方面是既然會存在不同的平臺，那必定有其合理性，博取眾家之長，能夠幫助一個架構(gòu)師在他的工作平臺上更加理性、公正地看待問題本身，其實反過來看.NET 、Java 或者PHP，也不就是相互借鑒其優(yōu)點嘛。

一個好的架構(gòu)師，是應(yīng)該有處理異構(gòu)平臺的能力的，必須記住，Web 本身就是異構(gòu)的。

5，設(shè)計更好的交互

說到交互，大多人會想到是產(chǎn)品設(shè)計范疇的交互式設(shè)計，Web 2.0 強調(diào)以用戶為中心，而交互，也是以用戶為驅(qū)動的交互設(shè)計。但是我在這里談及的，更多是通常意義的Web前端設(shè)計，也可以稱之為“表現(xiàn)層架構(gòu)”。

我們都知道Web 2.0 很重視交互，也正因為如此，大多工程師耗費更多的時間并不是在后臺的數(shù)據(jù)處理，而是前臺的交互。在AJAX 、RIA 大行其道的今天，Web 架構(gòu)師一個極其重要的職責是簡化因為“高度交互”而導(dǎo)致的開發(fā)高復(fù)雜度。

我們討論AJAX，但不是讓每個開發(fā)人員都去操作XmlHttpRequest，不是讓每個人去了解HTML DOM 、JavaScript 和CSS，然后組合的眼花繚亂。所有人都知道，讓很多開發(fā)人員吐血的不是后臺代碼調(diào)試，而是JavaScript 和CSS，因為需要無比的耐心和技巧。而架構(gòu)的職責呢，就是定義行之有效的規(guī)范和實現(xiàn)。

簡單一點地說，開發(fā)人員要彈出一個類似Facebook 的框，總不至于讓每個開發(fā)人員各顯神通去拼吧，然后絞盡腦汁地去兼容不同的瀏覽器，兼容不同的版本，再然后兼容不同頁面。我需要從后臺取數(shù)據(jù)，需要每個開發(fā)人員去自己寫，需要一個隱藏的效果，也需要各顯神通。

于是，有人會說，上面的幾個問題jQuery 可以解決，也有開發(fā)人員會采用這個類庫，但是也會有人用Prototype或ExtJs，而架構(gòu)師的職責，就是規(guī)定應(yīng)該用什么，怎么用，而哪些又是不可用的。

那我可以簡單地理解，在這個層面的交互架構(gòu)師的關(guān)鍵職責是定義到底是不是用jQuery， 不同的界面應(yīng)該用怎樣的html，應(yīng)該采用怎樣的服務(wù)器界面技術(shù)，應(yīng)該采用怎樣的遠程處理框架。

定義這些交互技術(shù)的目標是用最簡單的方式實現(xiàn)最好的交互，這個也正是架構(gòu)的職責所在。

5，性能和故障診斷

本來不應(yīng)該把這個問題列入其中的，但是考慮到典型的Web 2.0 是永遠的beta 版，換句話說，問題是永遠存在的，你不可能一開始就做出一個完美的應(yīng)用。隨著業(yè)務(wù)的增長，出現(xiàn)性能問題和系統(tǒng)故障的情況是不可避免的。場景很平常： 流量上去了， 卻發(fā)現(xiàn)整體網(wǎng)站變得奇慢無比，有些頁面間歇性地出現(xiàn)錯誤， 更加要命的是， 開發(fā)人員也進行了代碼復(fù)查， 卻還是沒有找到“低級”的錯誤。

一個好的架構(gòu)師，在這個時候應(yīng)該能夠協(xié)助進行一些診斷和優(yōu)化，基于業(yè)務(wù)的、技術(shù)的判斷，在愈加復(fù)雜的系統(tǒng)中，找出核心的問題所在。通常來說，一個應(yīng)用系統(tǒng)的性能和SQL 的水平是有關(guān)系的，但是到底哪些SQL 有問題，問題影響的程度如何，需要作出快速、準確的判斷。

我不太贊成事后諸葛亮，但是一個好的Web 架構(gòu)師還是應(yīng)該能夠洞察到性能導(dǎo)致的問題所在，也會提出一套行之有效的故障診斷方案：是數(shù)據(jù)庫、程序還是網(wǎng)絡(luò)，是操作系統(tǒng)還是硬件本身的問題，或者都兼而有之？

性能和故障診斷涉及到的層面太多了，有操作系統(tǒng)、數(shù)據(jù)庫、配置文件、程序代碼，甚至還會和網(wǎng)絡(luò)有關(guān)，每個方面都需要用一本書來說明，也許還不夠。但是作為架構(gòu)師，是必須對此有感覺的。

這是我個人對于Web 2.0 架構(gòu)師所需要素質(zhì)的一些理解，但是我想還有很多方面的能力是需要的，比如溝通的能力，抽象的能力，平衡的能力等等，也希望各位來幫忙補充。