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

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

1，熟知你的業務模式和目標人群

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

在技術和業務之間找到一個平衡，也就意味著必須明白整個業務核心的競爭力在哪里？目標人群的基本訴求在哪里？然后選擇最低成本的技術來實現業務需求，但是反過來，又必須適當地為業務拓展保留適當的空間。

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

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

2，了解負載均衡策略實現

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

并不是要求從一開始就設計一個理想化的負載均衡策略，那樣未免有些過于“未雨綢繆”，但是作為一個Web 架構師，一定要給自己留下一些“分家”的余地。因此適當地了解不同層面的負載均衡策略實現是必要的。

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

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

3，設計“合理”的存儲

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

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

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

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

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

4，異構平臺的整合能力

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

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

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

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

一個好的架構師，是應該有處理異構平臺的能力的，必須記住，Web 本身就是異構的。

5，設計更好的交互

說到交互，大多人會想到是產品設計范疇的交互式設計，Web 2.0 強調以用戶為中心，而交互，也是以用戶為驅動的交互設計。但是我在這里談及的，更多是通常意義的Web前端設計，也可以稱之為“表現層架構”。

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

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

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

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

那我可以簡單地理解，在這個層面的交互架構師的關鍵職責是定義到底是不是用jQuery， 不同的界面應該用怎樣的html，應該采用怎樣的服務器界面技術，應該采用怎樣的遠程處理框架。

定義這些交互技術的目標是用最簡單的方式實現最好的交互，這個也正是架構的職責所在。

5，性能和故障診斷

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

一個好的架構師，在這個時候應該能夠協助進行一些診斷和優化，基于業務的、技術的判斷，在愈加復雜的系統中，找出核心的問題所在。通常來說，一個應用系統的性能和SQL 的水平是有關系的，但是到底哪些SQL 有問題，問題影響的程度如何，需要作出快速、準確的判斷。

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

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

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