Web架構(gòu)師應(yīng)該具備哪些能力

最近和幾個(gè)朋友談到時(shí)下流行的Web 2.0，提到了其中最重要的角色——架構(gòu)師。多方各有爭(zhēng)執(zhí)，不外乎是因?yàn)槁殬I(yè)背景和視角的緣故。包括架構(gòu)一詞，本身就從建筑學(xué)借鑒而來(lái)，至于架構(gòu)師，則可以簡(jiǎn)單地從建筑學(xué)的設(shè)計(jì)師來(lái)引申，不外乎就是設(shè)計(jì)結(jié)構(gòu)，設(shè)計(jì)一個(gè)大樓的結(jié)構(gòu)?；氐杰浖旧?，那就可以簡(jiǎn)單地理解為負(fù)責(zé)設(shè)計(jì)軟件框架的人了。

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

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

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

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

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

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

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

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

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

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

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

3，設(shè)計(jì)“合理”的存儲(chǔ)

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

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

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

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

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

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

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

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

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

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

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

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

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

我們都知道Web 2.0 很重視交互，也正因?yàn)槿绱?，大?a target="_blank">工程師耗費(fèi)更多的時(shí)間并不是在后臺(tái)的數(shù)據(jù)處理，而是前臺(tái)的交互。在AJAX 、RIA 大行其道的今天，Web 架構(gòu)師一個(gè)極其重要的職責(zé)是簡(jiǎn)化因?yàn)椤案叨冉换ァ倍鴮?dǎo)致的開(kāi)發(fā)高復(fù)雜度。

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

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

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

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

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

5，性能和故障診斷

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

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

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

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

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