架构设计--仅是软件开发之第二大影响力？！
SDWest2006（譯注1）對我來說是個(gè)有趣的大會。我除了星期三之外（當(dāng)時(shí)我正飛往費(fèi)城參加一個(gè)客戶會議 == 因此錯(cuò)過了Jolt頒獎(jiǎng)部分）每天都在演講。我也參加了一些談話和會議；其中最引人關(guān)注的是Mike Cohn的計(jì)劃與估算的談話。我的兩個(gè)談話都是半天的關(guān)于Ood原則的導(dǎo)引。這些談話都參與的非常好，現(xiàn)場反映也很熱烈。
這里是我談話的幾份演講稿：
- 類設(shè)計(jì)之高級原則??? 在OO設(shè)計(jì)中，掌控類間組合或是關(guān)聯(lián)關(guān)系的原則到底是什么？
- 組件設(shè)計(jì)之高級原則? 在大型OO設(shè)計(jì)中，你該如何掌控組件的組合或關(guān)聯(lián)關(guān)系？
- 首要導(dǎo)向因素????????專業(yè)與否的最低界限是什么？
在星期二我主導(dǎo)了一個(gè)關(guān)于“敏捷與架構(gòu)設(shè)計(jì)”的圓桌會議。很多人是擠著進(jìn)入會議現(xiàn)場的，而且一直參與到會議結(jié)束。配合著討論要點(diǎn)的導(dǎo)航圖，我們將這些要點(diǎn)一一討論過。我的好朋友John Kern也在那兒，還幫助解答了很多提問。你可以從這里了解更多有關(guān)這個(gè)會議的。
會議的一些關(guān)鍵要點(diǎn)如下：
在此次會議前，我從未想到過這點(diǎn)。這里就有一群架構(gòu)師和設(shè)計(jì)師，他們激烈的爭辯著架構(gòu)設(shè)計(jì)的角色和位置，可是我們辛苦爭論出的一致結(jié)論是靈活性，可維護(hù)性和可擴(kuò)展性是處于次要的影響作用的，是編寫測試（測試優(yōu)先于產(chǎn)品代碼）起著最主要的效用。
這好像是吞下了苦黃蓮，而且很多架構(gòu)設(shè)計(jì)師們搞不好立即就會拒絕。然而，沒人認(rèn)為架構(gòu)師不重要，或者認(rèn)為應(yīng)該丟掉它轉(zhuǎn)而去青睞測試。正相反，是測試讓我們無所顧慮的改進(jìn)系統(tǒng)的設(shè)計(jì)。不是測試勝于架構(gòu)設(shè)計(jì)；而應(yīng)該說是測試成全了它！
自動化測試給了我們一個(gè)可靠的方式去了解系統(tǒng)是否運(yùn)行良好。因此我們不必再懼怕一個(gè)設(shè)計(jì)的改變會破壞它。這讓實(shí)施那些能夠改進(jìn)系統(tǒng)的設(shè)計(jì)變得更容易。因此測試的粉末登臺意味著在持續(xù)改進(jìn)系統(tǒng)的結(jié)構(gòu)、設(shè)計(jì)和架構(gòu)時(shí)遇到的阻礙會來得更少。
失去測試，架構(gòu)設(shè)計(jì)就是天方夜譚，因?yàn)橐坏卮蟮拈_發(fā)啟動后設(shè)計(jì)將很難改變。而自動化測試給設(shè)計(jì)留下了空間。設(shè)計(jì)改變所帶來的風(fēng)險(xiǎn)如此之大的被削減，以至于我們可以在肆無忌憚中就讓系統(tǒng)進(jìn)化。
?
譯注：
1，SDWest，全稱Software Development West，即西部開發(fā)者大會，是全美頗受矚目的開發(fā)者大會，著名的Jolt大獎(jiǎng)就在每年一度的大會上頒發(fā)。
2，驗(yàn)收測試，原文acceptance test，又成為容忍測試，敏捷方法認(rèn)為，如果一個(gè)構(gòu)建（build）通過了驗(yàn)收測試，基本上這個(gè)構(gòu)建就可被“接受了”。
?
?（原文鏈接網(wǎng)址：http://www.butunclebob.com/ArticleS.UncleBob.ArchitectureIsaSecondaryEffect; Robert C. Martin的英文blog網(wǎng)址：?http://www.butunclebob.com/ArticleS.UncleBob）?
譯者注：Robert C. Martin是Object Mentor公司總裁，面向?qū)ο笤O(shè)計(jì)、模式、UML、敏捷方法學(xué)和極限編程領(lǐng)域內(nèi)的資深顧問。他不僅是Jolt獲獎(jiǎng)圖書《敏捷軟件開發(fā)：原則、模式與實(shí)踐》（中文版）（《敏捷軟件開發(fā)》（英文影印版））的作者，還是暢銷書Designing Object-Oriented C++ Applications Using the Booch Method的作者。Martin是Pattern Languages of Program Design 3和More C++ Gems的主編，并與James Newkirk合著了XP in Practice。他是國際程序員大會上著名的發(fā)言人，并在C++ Report雜志擔(dān)任過4年的編輯。
架構(gòu)設(shè)計(jì)之性能設(shè)計(jì)經(jīng)驗(yàn)
??? 性能(performance)設(shè)計(jì)非常重要，對于服務(wù)器端實(shí)時(shí)交易系統(tǒng)來說系統(tǒng)性能的重要性不言而喻，對客戶端軟件來說性能好的軟件也會獲得良好的用戶體驗(yàn)，從而給用戶留下高質(zhì)量軟件的良好印象。因此在進(jìn)行架構(gòu)設(shè)計(jì)中性能設(shè)計(jì)非常重要。
??? 但架構(gòu)設(shè)計(jì)實(shí)際是一個(gè)平衡設(shè)計(jì)，在可用性、可擴(kuò)展性、可維護(hù)性、可靠性、高性能等之間做個(gè)妥協(xié)選擇。這些非功能性的需求再加上復(fù)雜的功能性需求，同時(shí)還要考慮到項(xiàng)目管理上tight schedule, low cost, perfect effect的三角難題約束，有時(shí)需求還不是很明確，vision不是很清楚，這種情況下系統(tǒng)架構(gòu)設(shè)計(jì)真是一門藝術(shù)。
??? 單就性能設(shè)計(jì)來說，在架構(gòu)設(shè)計(jì)初期就一定要把系統(tǒng)性能考慮在內(nèi)，否則等開發(fā)完成以后測試發(fā)現(xiàn)性能不好就比較難辦，通常要花費(fèi)較長的時(shí)間來診斷性能瓶頸，找到提升的辦法，甚至要改變架構(gòu)，傷筋動骨，往往造成項(xiàng)目延期。所以性能設(shè)計(jì)首先要有明確的性能目標(biāo)，根據(jù)用戶和軟件本身的性能要求來設(shè)計(jì)，合適的就是最好的。其次，要有適當(dāng)?shù)亩攘繕?biāo)準(zhǔn)和量化的性能指標(biāo)。最后，要有相應(yīng)的設(shè)計(jì)策略，具體的測試方法。
??? 根據(jù)我的經(jīng)驗(yàn)，影響系統(tǒng)性能主要瓶頸在I/O，包括數(shù)據(jù)庫，socket，網(wǎng)絡(luò)通信，文件等，例如頻繁查詢數(shù)據(jù)庫并返回大量結(jié)果集，頻繁操作大文件等，這些昂貴的操作會占用大量的CPU時(shí)間。拿系統(tǒng)響應(yīng)和服務(wù)一個(gè)事務(wù)來說，有幾個(gè)Round trip，要通過哪幾層I/O，如何合理的分配這些I/O的調(diào)用，降低不必要的I/O，都是進(jìn)行系統(tǒng)性能設(shè)計(jì)要考慮的。而有些性能問題在初期并不會表現(xiàn)出來，但當(dāng)拿到實(shí)際上線環(huán)境下，存在多用戶并發(fā)、大數(shù)據(jù)量的情況下就會暴露出嚴(yán)重的問題。所以性能設(shè)計(jì)時(shí)一定要考慮到I/O，同步，并發(fā)，資源爭用，以及大數(shù)據(jù)量等因素。通常，I/O操作、網(wǎng)絡(luò)響應(yīng)、差的算法、數(shù)據(jù)庫、以及其他的低效的資源使用都會導(dǎo)致低劣的性能。
??? 具體可用的設(shè)計(jì)策略有：
??? - 緩存以及緩存層(caching layer)
??? 在數(shù)據(jù)層和應(yīng)用層之間增加數(shù)據(jù)緩存層，提供全局?jǐn)?shù)據(jù)服務(wù)?？梢源蟠鬁p少數(shù)據(jù)庫往返次數(shù)。與讀取數(shù)據(jù)庫和讀取大文件（如XML文件）比，讀取內(nèi)存的速度無疑要快的多。所以對經(jīng)常要訪問的數(shù)據(jù)進(jìn)行緩存是非常好的實(shí)踐方法。因?yàn)楝F(xiàn)在系統(tǒng)往往內(nèi)存很大，可以充分利用大內(nèi)存，而共享內(nèi)存更能實(shí)現(xiàn)數(shù)據(jù)并發(fā)訪問。
??? - 多線程(multi-threading)
??? 現(xiàn)在基本上大部分軟件實(shí)現(xiàn)多線程或多進(jìn)程，多線程對單CPU系統(tǒng)還只是順序利用CPU時(shí)間和改善用戶體驗(yàn)，多CPU系統(tǒng)才是真正的并行。要注意的是多線程不要爭搶訪問同一資源而導(dǎo)致部分串行操作，要做到真正的并行操作多線程并不容易。另外，在多線程間同步一個(gè)龐大的資源，過多創(chuàng)建線程又沒有實(shí)現(xiàn)線程池也會導(dǎo)致系統(tǒng)性能下降。
??? - 負(fù)載平衡(load balancing)
??? 物理上增加地位對等的集群服務(wù)器（Cluster），通過負(fù)載分配算法分配相應(yīng)服務(wù)器來相應(yīng)客戶端請求。很多系統(tǒng)支持負(fù)載均衡，Windows server2003 IIS就支持負(fù)載均衡服務(wù)，其他如WebLogic, WebSphere也有集群版本支持負(fù)載均衡。當(dāng)然你也可以自己實(shí)現(xiàn)負(fù)載分配算法。
??? - 數(shù)據(jù)庫優(yōu)化（database optimization）
??? 如果應(yīng)用程序使用了數(shù)據(jù)庫，可以采取許多步驟來消除訪問和寫入數(shù)據(jù)時(shí)的瓶頸：
??? - 標(biāo)識潛在的索引，但不要?jiǎng)?chuàng)建過多的索引。
??? - 如果使用 SQL Server，則使用 SQL Server 的事件探查器和索引優(yōu)化向?qū)А?/p>
??? - 監(jiān)視處理器的使用；理想范圍是：75-80% 處理器時(shí)間。
??? - 使用查詢分析器分析查詢計(jì)劃以優(yōu)化查詢。
??? - 使用存儲過程優(yōu)化性能。
??? - 標(biāo)準(zhǔn)化寫入的大量數(shù)據(jù) —寫入較少的數(shù)據(jù)。
??? - 取消標(biāo)準(zhǔn)化讀取的大量數(shù)據(jù) —讀取較少的數(shù)據(jù)。
??? 文件系統(tǒng)優(yōu)化
??? 有時(shí)候系統(tǒng)性能不好，但當(dāng)你關(guān)閉寫log的功能，性能一下子提高很多。因?yàn)轭l繁的打開關(guān)閉大log文件時(shí)I/O開銷非常大，同樣記錄log到數(shù)據(jù)庫也一樣。所以，release版盡量減少寫log，或干脆移到裸設(shè)備上。
??? 頻繁打開關(guān)閉文件對系統(tǒng)性能下降程度是驚人的，可以通過一些變通辦法來減少文件的頻繁操作。
??? 例如，原來的緩存持久化實(shí)現(xiàn)是保存在XML文件，每次要獲得一個(gè)配置項(xiàng)，都打開XML文件，通過XPath拿到這個(gè)配置項(xiàng)的值，這樣效率不高，而且容易把這個(gè)XML文件lock住；改進(jìn)的方法是：通過比較XML文件的修改時(shí)間(System.IO.File.GetLastWriteTime)判斷是否要再次打開文件，大大提高了效率；另一個(gè)可以改進(jìn)的方法是：啟動時(shí)讀取所有配置到一個(gè)靜態(tài)的HashTable，每次要獲得一個(gè)配置項(xiàng)都從內(nèi)存HashTable獲取，在最后或適當(dāng)?shù)臅r(shí)候持久化到XML。
??? 代碼性能設(shè)計(jì)
??? 在編程實(shí)現(xiàn)上，代碼性能設(shè)計(jì)也很重要，一些昂貴的操作會占用大量的資源和CPU時(shí)間。例如，字符串相加沒用StringBuilder, 頻繁創(chuàng)建對象，差勁的排序或遞歸算法，過多的裝箱拆箱，過多的使用反射（Reflection），頻繁new HashTable或大的數(shù)組，用異常（Catch Exception）用做正常的邏輯，使用復(fù)雜的正則表達(dá)式，等等。具體可以參考《Effective C++》《Effective C#》等書籍。
??? 語言的選擇
??? 另外，語言選擇也很重要。比如相對于Java, C#, C++, 大多數(shù)OLTP系統(tǒng)用C語言效率高的多，因?yàn)樵谒械母呒壋绦蛟O(shè)計(jì)語言中，C程序設(shè)計(jì)語言的運(yùn)行效率是公認(rèn)的。再比如我們熟悉的一些框架，框架本身是C#或是Java的，但其核心獨(dú)立模塊是C++封裝的，這樣可以達(dá)到最佳的性能。所以對于一些特定的業(yè)務(wù)需求目標(biāo)和數(shù)據(jù)的具體情況，對于核心的模塊或算法，可以用特定的語言來實(shí)現(xiàn)以獲得更好的效率。
??? 應(yīng)用層
??? 比如應(yīng)用層和數(shù)據(jù)庫的API，在.Net中就有就有DataReader、DataSet和IList等的選擇以及轉(zhuǎn)換等，這個(gè)根據(jù)具體情況而定；還有就是大家常采用的數(shù)據(jù)的格式化和壓縮，以及采用分頁，減少傳輸?shù)臄?shù)據(jù)量；是否可以把一部分處理邏輯放在客戶端呢，減少服務(wù)端的工作量。界面端也是有很多針對性能優(yōu)化的考慮，例如繪圖，控件重繪都是非常耗資源的，各控件的數(shù)據(jù)加載和數(shù)據(jù)綁定性能也各不相同，盡量采用惰性加載，異步加載；初始化和啟動速度等都是需要考慮和優(yōu)化的。
架構(gòu)設(shè)計(jì)的三個(gè)維度
架構(gòu)設(shè)計(jì)是一個(gè)非常大的話題，不管寫幾篇文章，接觸到的始終只是冰山一角，更多的是實(shí)踐中去體會。
這篇文章主要介紹的是面向?qū)ο驩O，面向方面AOP，面向服務(wù)SOA這三個(gè)要素在架構(gòu)設(shè)計(jì)中的位置與作用。
一、架構(gòu)設(shè)計(jì)三個(gè)維度
架構(gòu)設(shè)計(jì)有三個(gè)維度，或者說是我們在考慮架構(gòu)時(shí)需要思考的三個(gè)方向。分別為：面向?qū)ο?、面向方面、面向服?wù)。這三個(gè)維度可以看作是正交的，但不同維度會互相印證，互相支撐。
整個(gè)架構(gòu)的示意圖如下所示：
二、面向?qū)ο?/h1>
面向?qū)ο蠹夹g(shù)最初是從面向?qū)ο蟮某绦蛟O(shè)計(jì)開始的，它的出現(xiàn)以60年代simula語言為標(biāo)志，并在Smalltalk語言的完善和標(biāo)準(zhǔn)化過程中得到更多的擴(kuò)展和對以前的思想的重新注解。80年代中后期，面向?qū)ο蟪绦蛟O(shè)計(jì)逐漸成熟，被計(jì)算機(jī)界理解和接受，人們又開始進(jìn)一步考慮面向?qū)ο蟮拈_發(fā)問題。直到現(xiàn)在，面向?qū)ο笠呀?jīng)成為一種非常流行的編程方式，以及軟件設(shè)計(jì)的架構(gòu)。
面向?qū)ο筇岢鲇腥齻€(gè)主要目標(biāo)：重用性、靈活性和擴(kuò)展性，強(qiáng)調(diào)對象的“抽象”、“封裝”、“繼承”、“多態(tài)”。它能讓人們以更加接近于現(xiàn)實(shí)世界的方式來思考程序，這點(diǎn)可以說是面向?qū)ο笞畲蟮倪M(jìn)步。
在OO思想的運(yùn)用上，業(yè)界出現(xiàn)了很多好的經(jīng)驗(yàn)與技巧，從而涌現(xiàn)出大量的設(shè)計(jì)模式?？梢哉f面向?qū)ο笫窍到y(tǒng)分析與設(shè)計(jì)時(shí)的一個(gè)很重要的方面。
三、面向方面
面向方面最初來源于hook技術(shù)，本質(zhì)上就是滿足擴(kuò)展的需求，可以在程序中自由擴(kuò)展功能。
面向方面不僅僅是一門編程技術(shù)，同樣也是一種架構(gòu)設(shè)計(jì)的思路。如果說OO是縱向地分析、切割整個(gè)系統(tǒng)，那么可以認(rèn)為AOP是橫向地對系統(tǒng)作切片。簡單地理解，OO與AOP分別從兩個(gè)不同的角度給我們提供了分析系統(tǒng)的思路。面向方面可以彌補(bǔ)面向?qū)ο蟮娜毕?#xff0c;兩種方式有機(jī)的結(jié)合在一起可以更加有效地分析系統(tǒng)。
我們認(rèn)為OO是接近于人類認(rèn)識自然的思維方式，但對于東方來說卻并不是這樣。當(dāng)西方人看到一個(gè)復(fù)雜系統(tǒng)的時(shí)候，只會有一種思路，就是“分解”——將系統(tǒng)分解成一塊一塊，然后每個(gè)部分作研究。當(dāng)東方人看到一個(gè)復(fù)雜系統(tǒng)的時(shí)候，更多地會關(guān)注系統(tǒng)中存在的關(guān)系，將系統(tǒng)作為一個(gè)有機(jī)的整體進(jìn)行研究。
這兩種思維方式都沒有問題，結(jié)合起來的話分析問題解決問題會更好。面向?qū)ο笈c面向方面也同樣如此，都能對應(yīng)到人類認(rèn)識自然的思維方式上。不過中國人理解AOP可能會有不同的感悟——我寫的文章《讀易[13]·閑談中醫(yī)與AOP》有簡單的說明。
四、面向服務(wù)
面向服務(wù)可以說是最近炒得比較火的概念了。包括現(xiàn)在提到的SaaS——Software as a service，軟件即服務(wù)。準(zhǔn)確說來，面向服務(wù)不僅僅是軟件行業(yè)的概念。這個(gè)要從社會的產(chǎn)業(yè)結(jié)構(gòu)說起。
社會產(chǎn)業(yè)總共分為三個(gè)，第一產(chǎn)業(yè)農(nóng)業(yè)，第二產(chǎn)業(yè)工業(yè)，第三產(chǎn)業(yè)服務(wù)業(yè)。最早社會的主要產(chǎn)業(yè)是第一產(chǎn)業(yè)農(nóng)業(yè)，將近有幾萬年的歷史。十八世紀(jì)下半葉在英國開始的工業(yè)革命，對人們的生活產(chǎn)生了根本性的影響，社會的主要產(chǎn)業(yè)成了第二產(chǎn)業(yè)工業(yè)。
現(xiàn)在仍然屬于工業(yè)時(shí)代，或者有人說的“后工業(yè)時(shí)代”。而在后工業(yè)時(shí)代，社會的經(jīng)濟(jì)體制必定要向第三產(chǎn)業(yè)服務(wù)業(yè)逐漸轉(zhuǎn)型。面向服務(wù)其實(shí)是社會經(jīng)濟(jì)體制重心的一種遷移。
還是說回到軟件行業(yè)，社會的主要產(chǎn)業(yè)將轉(zhuǎn)變成服務(wù)業(yè)，自然軟件行業(yè)也會出現(xiàn)對應(yīng)的變化，那就是這里提到的面向服務(wù)。面向服務(wù)今后會影響到軟件的交付模式，會對整個(gè)軟件行業(yè)的體制產(chǎn)生影響。
而說到架構(gòu)層面，面向服務(wù)是系統(tǒng)發(fā)布功能的一種方式。并且基于這種方式下不同的系統(tǒng)之間能有效地通信、協(xié)作。常見的實(shí)現(xiàn)技術(shù)就是Web Service。
五、軟件全局觀
軟件架構(gòu)設(shè)計(jì)的三個(gè)維度：面向?qū)ο?、面向方面、面向服?wù)。
最年長的一個(gè)維度就是面向?qū)ο?#xff0c;發(fā)展了好幾十年，也是相對來說比較成熟的一個(gè)維度。它解決的問題是系統(tǒng)內(nèi)部結(jié)構(gòu)的設(shè)計(jì)。
面向方面的思想提出來能夠彌補(bǔ)面向?qū)ο蟮娜毕?。面向?qū)ο蟮姆绞讲荒軐?shí)現(xiàn)橫切關(guān)注點(diǎn)的分離，而面向方面正是為了解決這個(gè)問題。面向方面與面向?qū)ο笠粯佣际墙鉀Q系統(tǒng)內(nèi)部結(jié)構(gòu)的設(shè)計(jì)。
面向服務(wù)更多的是涉及到系統(tǒng)的外部，簡單地說就是發(fā)布功能。它并不關(guān)注系統(tǒng)內(nèi)部結(jié)構(gòu)的實(shí)現(xiàn)，所以說面向服務(wù)與面向?qū)ο蠡蛘呙嫦蚍矫娌⒉粵_突。
這三個(gè)維度并不是絕對孤立的，它們之間會互相影響、制約。我們在分析架構(gòu)的時(shí)候需要同時(shí)考慮到這三個(gè)維度的問題。這樣有助于我們設(shè)計(jì)出更加優(yōu)秀的架構(gòu)。
軟件架構(gòu)為誰而設(shè)計(jì)
（節(jié)選自《軟件架構(gòu)設(shè)計(jì)》書稿）?
……如此看來，架構(gòu)師應(yīng)當(dāng)為項(xiàng)目相關(guān)的不同角色而設(shè)計(jì)（如圖5-2所示）：
l??????? 架構(gòu)師要為客戶負(fù)責(zé)，滿足他們的業(yè)務(wù)目標(biāo)和約束條件；
l??????? 架構(gòu)師要為用戶負(fù)責(zé)，使他們關(guān)心的功能需求和運(yùn)行期質(zhì)量屬性得以滿足；
l??????? 架構(gòu)師必須顧及處于協(xié)作分工“下游”的開發(fā)人員，
l??????? 架構(gòu)師還必須考慮“周邊”的管理人員，為他們進(jìn)行分工管理、協(xié)調(diào)控制、評估監(jiān)控等工作提供清晰的基礎(chǔ)。
?
?
圖5-2???軟件架構(gòu)師為誰而設(shè)計(jì)
?
一言以蔽之，軟件架構(gòu)師必須做到內(nèi)外兼顧、各層并重（如圖5-3所示）。只有這樣，軟件架構(gòu)才能和它“包含了關(guān)于如何構(gòu)建軟件的一些最重要的設(shè)計(jì)決策”的“地位”相符。
?
補(bǔ)充三點(diǎn)：
●這個(gè)話題我在2006IBM開發(fā)者大會的預(yù)熱課堂上有過演講，說明了如何運(yùn)用基于多視圖的架構(gòu)設(shè)計(jì)方法應(yīng)對上述問題。
●另外可參考我在IBM DW上發(fā)的文章：運(yùn)用RUP 4+1視圖方法進(jìn)行軟件架構(gòu)設(shè)計(jì)
●其實(shí)，《軟件架構(gòu)設(shè)計(jì)》一書講述的具體方法和4+1方法有所不同……例如，明確引入“質(zhì)量屬性分析”活動來為性能、可伸縮性、可重用性、可擴(kuò)展性等非功能需求制定相應(yīng)的架構(gòu)決策。書的第15章專門介紹質(zhì)量屬性分析（例如如何運(yùn)用“質(zhì)量-場景-決策”表這種思維工具落實(shí)需求、制定設(shè)計(jì)決策等）。
?
總結(jié)
以上是生活随笔為你收集整理的架构设计--仅是软件开发之第二大影响力？！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： C#使用 System.Net.Mail
- 下一篇： C#SMTP发邮件