系統架構師的修煉

zenzuguo發表於2008-01-30

系統架構師的修煉

首先,何謂系統架構師?

IBM工程師的說明是:
架構師的主要責任是提供開發人員和專案經理之間的共用溝通媒體。他們負責讓業務規則及需求與工程實踐及限制相適應,以確保成功

中文Wiki上的說明是:
系統架構師負責設計系統整體架構,從需求到設計的每個細節都要考慮到,把握整個專案,使設計的專案儘量效率高,開發容易,維護方便,升級簡單

這兩個解釋,加起來基本說明了系統架構師的定義。

JAVA系統架構師應該看的幾本書

Thinking in Java
Effective Java

UML基礎、案例與應用
UML入門提高

軟體工匠
設計模式——可複用物件導向軟體的基礎

重構-改善既有程式碼的設計
敏捷軟體開發-原則、模式、實踐

企業應用架構模式
Expert One-on-One J2EE Development without EJB

軟體工程——實踐者的研究方法
軟體領導--成功開發軟體的指導準則

後面的兩本書,其實已經有點屬於專案經理的範疇了,不過還不是很深入,看看對做成功的系統架構師是很有好處。
企業應用的系統架構師應該關注的幾個方面

資料持久層的設計
在Spring和Hibernate,ibatis出來以前,幾乎每家公司都有自己的一套方法和架構,而架構師的50%的精力也會集中到這上面,EJB只是增加架構師的負擔。在Spring出來以後,基本上,大多數的架構師都從重複設計這個輪子的無用功中解脫出來了。 Rod的輪子太好用了,基本上,大家只要套上去就行了,或者,剩下最重要的事情,是選擇一個合適的資料庫連線池的開源專案吧

MVC架構的具體設計
MVC只是個概要的概念,具體如何實現的具體技術很多,根據專案設計最恰當的架構

大併發性訪問
使用快取,在資料量達到一定程度時,使用叢集技術,優先考慮利用伺服器的叢集,其次是硬體叢集,最後才是應用本身加入叢集功能

超大資料量返回結果
儘量使用分頁,最佳化SQL語句,迴圈處理資料時儘可能共用物件,只保留關鍵資料,及時釋放記憶體佔用

超大檔案的讀取和生成
儘可能快的讀取大檔案,並進行分析。寫入大檔案時,如何及時釋放記憶體。學會適當利用作業系統的命令列資源來更快完成任務。

多執行緒的應用和管理
執行緒池的管理和監控,執行緒的啟動(包括定時啟動),結束,回收,執行緒資源的釋放

使用者介面可用性設計
平衡速度和可用性,恰當的使用非同步和同步技術,展現關鍵資料為重點

分散式的資料交流和整合
選擇恰當的資料互動方式,從最氾濫低效的Web Service到最實用的檔案共享

群集系統的管理
如何確保快取的同步?如何確保物件唯一性?如何保證各臺機器的同步?
是否採用EJB?如何利用J2EE的特性(例如JNDI)

複雜的業務規則
規則引擎和工作流引擎場景和應用

其實,作為一個真正的系統架構師,不應該侷限於企業應用的系統,這種系統往往有資料庫的侷限性,有時候,應該考慮是否可以橫向跨越,直接對其它系統做一些架構考慮,在沒有豐富的實戰經驗的前提下,而只是看了其它人的系統和程式碼,就能夠給出有效的設計指導。

例如對於一個下載軟體,可以有如下考慮:

1. 未明和非法url的檢驗,已經下載失敗的容許,資訊記錄
2. 多執行緒下載一個檔案,檔案的切分和拼合,部分切片丟失的拼合可能性
3. 下載執行緒管理
4. 伺服器或者P2P的機器之間的通訊協議
5. 速度監控和限制
6. 下載進度的監控和顯示

作為一個線上播放軟體,可以做如下考慮

1. 播放速度的保證
機器的問題基本不存在了,關鍵是網路問題。如何在檢測網路速度,根據影片的質量,並緩衝足夠多的內容,保證播放一直儘可能順利的完成。

2. 播放質量的保證
如何利用DirectX等技術,最快的進行渲染,是自己寫底層,還是利用已有的API

由於沒做過類似的專案,可以寫的東西還是少很多了。
系統架構師應該有的素質:

1、 實際的程式設計經驗
最少2年吧,多了就不說了,其實從大學就開始鑽研的話,

2、 書面表達能力和口頭交流能力
綜合利用架構圖,UML圖,文字和程式碼片斷,表達自己設計思想,至於是Word還是ppt,應該通吃

在開發人員中發現架構師的最有價值標準是有效的溝通。您需要技術嫻熟、經驗豐富的開發人員,這樣的人員需要有就專案中的業務相關問題進行溝通的經歷。架構師經常必須對理解方面的差距進行預計,然後才能有所貢獻。他們必須願意克服困難來確保技術和業務觀點的融合。他們並不必對意見交換工作進行計劃和協調;這仍然主要是專案經理的工作。他們的任務是確定表述系統設計時的最佳工具和構件,以促進有效的意見交換。他們必須能夠判斷當前方法顯得不足而需要採用新方法的情況。寫作技能也非常重要,還需要具有製作草圖的技能或使用製圖軟體的能力。

3、 自覺主動;積極解決設計問題
架構師的日常工作目標經常並不明確。很多開發人員直接參考功能規範來列出任務清單。架構師通常則是向這些開發人員提供所需結構的人員,以便儘可能提高工作效率。好的候選者不僅進行溝通方面的工作,而且也會預計各種設計問題並加以解決——通常在沒有任何具體指示的情況下自覺進行。無論所分配的職責如何,積極參與專案的開發人員都有機會從一起工作的人員中脫穎而出。

4、 抽象思維能力和總結能力
架構師,顧名思義,在系統未搭建好之前,就要能夠有一個草圖在心。而如果是對現有系統的改造,那麼能在看過系統的文件(如果有的話)和程式碼後,就能總結出系統的架構特點。
架構師必須能夠理解表述模糊的概念並將其變成相關各方能夠理解的專案構件。他們必須能夠理解抽象概念,並以具體的語言對其進行溝通。開發人員中好的候選者經常要求或自己主動解釋開發生命週期中容易混淆的問題。他們能迅速評估各種想法並將其納入後續工作的操作建議中。

開發人員經常具有很強的數學能力,而好的架構師則傾向於表現出更強的口頭表達能力。管理人員經常說開發人員具有“工程意識”,而這是一個用於評估架構師的非常有意義的方面。架構師應該具有很強的解決技術問題的能力,但還必須能夠準確獲知更為全面的人員如何與技術互動的資訊。這要求具有某種形式的抽象思維(而不再是程式碼的細節),這種思維能力可能較難形成。

5、 全面的技術資訊吸收能力和選擇鑑別能力
作為開發人員出身,對於某一個具體問題的研究能力(雖然很多人總結為google能力),已經相當具備了。但是對技術資訊的全面接受和選擇性深入瞭解能力,並且做出正確的判斷,那些技術無非是廠家的噱頭,而那些技術是真正可以用到專案,提高專案質量的好技術,這種能力確實至關重要的。

[@more@]

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/106285/viewspace-998761/,如需轉載,請註明出處,否則將追究法律責任。

相關文章