.NET企業級應用架構設計系列之技術選型

這裡說的技術選型實際上是指技術方向的選擇，或者叫平台方案的選擇，也或者叫技術路線等，總之是大方向的把握。假定項目背景是要做一個中型WEB系統，公司組建新的技術團隊以及運營團隊來運作。基於這個模糊的項目背景，看看我們能得到些什麼。

首先我們想到的是目標系統的特徵：
A) 穩定性及可服務性：這是對軟體系統最基本的要求，為客戶提供穩定的服務是業務開展的最基礎的保證。這是和客戶的耐心作戰，是贏取客戶和擴充業務縱深度的前提。很難想象有人會在一個不穩定的系統面前花費精力去做一件本該很容易的事情。
B) 整體效能及升級擴容餘地：雖然很多時候對系統壓力的擔心是多餘的，但系統架構必須有一定的應付突發事故的能力以及具備足夠的升級擴容空間來滿足潛在的業務擴張，不然總會有手忙腳亂的一天。系統效能是可服務性的一方面，而升級擴容空間是系統持續長期運作的保障。
C) 可維護性及可管理性：除開靈活的系統實現帶來的可維護性，系統軟體和硬體裝置的選擇同樣對可維護性產生重要的影響。這需要結合團隊的人員架構來共同考慮。在維護性和管理性方面的問題必然帶來升級擴容和應對業務變化方面的巨大困難。

再者，我們會想想想在市面上的方案提供者都能給我們什麼：
目前在WEB系統方面流行的主要是Java和.NET兩個平台級的軟體技術方向，它們之所以流行是因為在許許多多的場合被證明能保障較高的生產效率。兩者提供的解決方案都表現不錯，只不過可能達到相同的目標所帶來的總體擁有成本不一樣而已。也就是說，它們在解決方案特徵方面差異不大。一些重點比對項參考如下：

	Java	.NET	備忘
可移植性	好，能在大多數作業系統平台上順利移植。	差，只有Windows相容平台上移植。	移植性對於最終客戶來說沒有多大意義，但Java運行於Linux系統能降低投入成本。
廠商支援	多，有許多伺服器廠商支援Java。	少，但呈現增多的趨勢。
社區支援人員	多，有許許多多的社區和專業的支援人員廠商。	多，單純Microsoft一家提供的技術文檔就已經相當豐富。	微軟的.NET戰略不止是技術上的戰略，也是針對人的戰略。
開源產品	多，而且有很多非常成熟的產品級開源項目。	少，和Microsoft一家獨斷有曆史因素。	開源軟體的支援人員整體上都不完備。
社會人力資源	多，但兩極分化嚴重。	多，但做過深入開發的人少，特別是.NET 2.0和3.0平台。	結論來自某人才招聘網統計資料。

另外，我們會想想我們的人手，也就是說Team Dev方面我們擁有哪些方面的人和技術。整個系統的開發需要團隊的力量，架構設計和技術方向選型必須關注人的因素。只有合適的人做合適的事情才能產生預期的高位價值。人力資源和技術團隊架構在選擇方向上起重要作用，需要結合人力資源市場的人才分布來思考。團隊的曆史經驗對架構設計有很大影響，因為曆史經驗可以帶來架構重用以及減少學習新技術和新工具的曲線。另外，團隊的素質決定了軟體過程能否順利實施。所以，團隊在架構設計中佔有相當的分量。（這裡，絕不要把架構設計孤立起來看待，它不只是規劃期的事情，因為架構設計是對未來的把握，任何影響因素都要儘可能的考慮進來，特別是一些重大影響因素）。

上面的三點，是一個相互聯絡的整體，合在一起就成了一個三角形，我把它叫做“架構設計三角形”：

圖1：架構設計三角形

 

接下來，結合一些指導原則，它們是許許多多軟體系統成功失敗的經驗總結。其實，看起來也是非常直接的，很容易理解和接受：
A) 尋找最容易找到的技術人員組建團隊。這樣可以將人員流動對項目的影響減到最小，同時也可以快速的組建團隊進入開發期。目前，IT人力資源市場上，Java方向和.NET方向是兩個主要的企業級開發方向，多數IT人才也集中在這兩塊。
B) 使用成熟技術。顯然，Java和.NET都是成熟的技術。在軟體解決方案方面都有各自的長處和優點，但對企業級應用而言都可以勝任。通過這幾年的發展，.NET和Java都形成了豐富的社會技術資源。.NET經過1.0到3.5的發展，在企業級應用方面已經在實踐中變得更加的成熟了。
C) 使用團隊熟悉的技術。避免過於陡峭的學習曲線，可以把對開發人員的的要求降至更低。但這並不等於使用最簡單的技術來完成複雜龐大的企業級應用，應該是在易學易用的前提下構造穩定可維護的目標系統。冒著危險選擇不成熟的技術或者不熟悉的技術都只能得到一個漏洞百出的系統。
D) 側重於開發期的規劃與管理，開發穩定可維護的產品。對團隊的素質側重點放在溝通和編寫穩定可維護代碼的視角，避免目標系統走向紊亂而不可控的地步，從而導致最終失敗的結局。

結合具體實際情況，結論很容易得出了。考慮的方向是：目標系統 + 技術團隊 =〉 解決方案。詳細的結論就不寫了，我這次為項目選擇的是.NET 2.0平台。