首席架構(gòu)師汪洋坐鎮(zhèn)，歡迎大伙提問啊：軟件架構(gòu)連載討論之二：架構(gòu)設計解惑！

yanyangtian4502

回復  yanyangtian4502


    我認為,企業(yè)分大小,項目不分大小.
    企業(yè)級別的項目,應該是用于生產(chǎn)環(huán) ...
chenyx 發(fā)表于 2011-11-03 18:43

    這位朋友說的很對，其實”企業(yè)級項目“與項目的大小，是否是為公司  政府 組織 無關的！我稍后給出一些“企業(yè)及項目”的緣由和一些特性

sytpb

回復 6# yanyangtian4502


    沒有。

fire_cpp

1、關于“企業(yè)級”。我不太喜歡這個提法，“企業(yè)級”這個詞在大多數(shù)時候是增加你項目談判籌碼的詞匯，而非提高軟件質(zhì)量的詞匯。操作系統(tǒng)內(nèi)核（我更傾向于指開源操作系統(tǒng)）開發(fā)者從來不說自己的軟件是“企業(yè)級”，但其伸縮性、穩(wěn)定性、性能卻是一流的。但人卻是容易受詞語影響的動物：同樣一件事情，用不同的詞語表達，聽者（乃至表達者）都會有不同的、情緒上的微妙區(qū)別。

“企業(yè)級”有不同的提法，很多時候這個詞為交流者之間提供了一個共同的語境。

2、實踐上，我感到設計實在是非常重要。新人很容易陷入寫代碼的“激情”當中，雖然這種激情不可或缺，也可能是每一個人必經(jīng)的階段。不過話說回來，沒做過大項目的人、沒糾結(jié)過的人是無法體會設計的重要性的。而我認為設計的核心能力在于抽象——業(yè)務抽象與系統(tǒng)抽象的結(jié)合。

拿一個項目來說，如果因為系統(tǒng)面對的業(yè)務比較復雜、不確定性比較高（我們的工作不是經(jīng)常面對這種情況嗎？），一旦設計缺乏彈性，那么業(yè)務的變化很有可能讓寫代碼的人抓狂甚至不知從何做起。如果設計時抽象得恰到好處，業(yè)務發(fā)生變化時你會發(fā)現(xiàn)“哦，原來這幾個類可以這樣用�。∵�好當時是這樣設計的！”。

至于基礎設施這一塊，新人容易陷入另一個誤區(qū)：過度陷入優(yōu)化，號稱要榨干軟硬件每一滴血。其實，大規(guī)模的應用，可擴展性更重要，這樣考慮一是基于成本、二是基于可靠性。成本方面，如果能通過增加內(nèi)存或者幾臺服務器提高服務能力，何必花幾個人的半年時間來開發(fā)一個新的算法呢？可靠性方面，如果你把服務器的性能全榨干了，利用率達到了95%甚至100%，那么一旦有突發(fā)事件出現(xiàn)你的系統(tǒng)將很危險。當然不是說算法與優(yōu)化不重要，而是說這應該與成本及其它實際方面取得平衡。我想這也是企業(yè)級系統(tǒng)與科研性質(zhì)系統(tǒng)的區(qū)別吧。所以在實際中我們很少爭論是linux還是freebsd在高負載下誰更優(yōu)秀——如果經(jīng)常處于高負載（比如70%以上）那么從“企業(yè)級”這個詞出發(fā)，你的系統(tǒng)可能應該擴展了。

3、架構(gòu)？
不在行，不是架構(gòu)師啊。



大清早的，不知道說些什么……有感而發(fā)，不著邊際，隨便聊聊而已。

工作中我比較郁悶的是不知道除了經(jīng)驗之外有什么好的辦法（或理論）能確保設計不過度、同時又有充分的彈性？
另外，架構(gòu)師們，CFO會找你們的茬嗎？

yanyangtian4502

回復 13# fire_cpp


    說出來很多的實情，有機會大家交流下？！

fire_cpp

回復  fire_cpp


    說出來很多的實情，有機會大家交流下？！
yanyangtian4502 發(fā)表于 2011-11-07 10:28

    我所知不多，水平不夠，有機會能與您交流肯定獲益不淺。

yanyangtian4502

在很多的時候，每次和一些技術(shù)人員討論有關架構(gòu)的話題，特別是在實現(xiàn)方面，很多的朋友，也包括很多的網(wǎng)上的文章  總是將架構(gòu)與模式等同起來：每談架構(gòu)，比談模式。

其實架構(gòu)設計絕不是等于模式（設計模式，架構(gòu)模式，集成模式等），架構(gòu)設計 不僅僅涉及到技術(shù)的成分，并且還涉及到很多的“軟”技能，并且 這些技能的重要  甚至比技術(shù)更加重要

yanyangtian4502

如果 硬是要把架構(gòu)設計 與模式 放在一起 ，那么 可以這樣說：模式 僅僅只是架構(gòu)設計中的所涉及到的技術(shù)的一部分，甚至只是很小的一部分，如果把整個架構(gòu)設計的技術(shù)體系比喻為一個大樓，那么模式 僅僅只是其中的幾塊磚而已

litdong

架構(gòu)模式難道不是應用到架構(gòu)上嗎？

設計模式我的理解就像戰(zhàn)場上連排的戰(zhàn)術(shù)技巧，比如如何利用手中兵器有效組織步兵火力，班組如何保持戰(zhàn)術(shù)隊形，各個班組間如何通訊等等，屬于戰(zhàn)術(shù)范疇，一個人不行還不至于影響他人。

架構(gòu)模式那就是團師高級別的，戰(zhàn)役目的是啥，如何分配兵力，如何預留預備隊，各團如何組織進攻，各團如何區(qū)分戰(zhàn)斗范圍，各團如何做相得益彰的協(xié)同，炮火如何支援，如何運用特種兵器打擊敵人等等，屬于戰(zhàn)役范疇了，水平高低取決于指揮員和參謀的水準，這幾個人不行，那基本就完了。

不同的項目也是不同的作戰(zhàn)形式，比如平原作戰(zhàn)，山地作戰(zhàn)，叢林作戰(zhàn)，平原作戰(zhàn)就要發(fā)揮裝甲部隊快速突擊的能力，山地就是要強調(diào)輕裝部隊等等。這些不同的地形引發(fā)的裝備（技術(shù)）的改變，班組單兵作戰(zhàn)方式（設計模式）的改變，甚至組織形式的（構(gòu)件）改變這就叫架構(gòu)的改變。

crazyhadoop

要做好架構(gòu)設計我覺得要有2點要做的非常優(yōu)秀：
1）系統(tǒng)分解和設計
  設計者需要將系統(tǒng)整體分解為更小的子系統(tǒng)和組件，從而形成不同的邏輯層或服務。關鍵一點是要松耦合的確定各層的接口，層與層相互之間的關系，個人感覺這里需要熟練掌握設計模式，但并不拘泥于設計模式，以便系統(tǒng)后期橫向和縱向都能無縫，順利的擴容。

2）技術(shù)選擇
例如最近NoSQL數(shù)據(jù)庫非常火熱，很多項目都用Mongodb來存儲數(shù)據(jù)，并搭配Hadoop來處理數(shù)據(jù)，為什么要選擇Mongodb，使用這個數(shù)據(jù)庫，技術(shù)人員能否穩(wěn)妥的把握住Mongodb的行為，最近有一篇非�；鸬奈恼拢�盤點Mongdb的8宗罪。http://hb.qq.com/a/20111111/000205.htm  這對系統(tǒng)的未來走向很重要

最后就是要有系統(tǒng)設計文檔，最起碼要給后來的維護者一個大致的概念，每個系統(tǒng)的設計功能是什么？有什么要注意的地方，需要做哪些改進，我看很多公司都沒有這樣的東西，哪怕在代碼里能說上也行啊

crazyhadoop

回復 1# 無風之谷


    其實企業(yè)級這個概念我覺得已經(jīng)過時了，現(xiàn)在很多服務都是互聯(lián)網(wǎng)級別的概念，就算不是整個互聯(lián)網(wǎng)，也是面對著一個特定的人群，服務范圍已經(jīng)延伸了