|
|
最近看了下《架構之美這本書》，摘錄了部分書中的內容，在摘錄書里面內容前先談談我自己對架構的看法。架構應該包括了功能性架構和非功能性架構兩個方面的內容。我們常說的J2EE，DotNET標準架構框架更多的是非功能性架構的范疇；而談的子系統，組件劃分，接口設計，復用等內容涉及到功能性架構的內容。J2EE架構的標準模板很容易找到和借用，但是并不代表你是一個合格的架構師，架構師必須深入到功能性架構中，真正的做好需求和實現中間的橋梁。正如現在好的PPT模板一大堆，但是并不代表你能夠做出好的PPT來，PPT的模板僅僅是術，而PPT內容和思維才是道，而這里又是我們經常講到的模式的問題，即根據我們的目標如何選擇相應的圖表和模板來最合理，最簡單的展現我們的內容。
從靜態分析的角度來考慮，架構的核心即是分解和集成。我們面對的現實業務和需求可能太龐大了，如果不去分解我們的構建根本都無法下手，我們就無法真正理解業務細節。因此子系統和組件劃分是分解重要內容，分解重要原則又是高內聚，松耦合。由于分解產生了組件間的交互，因此需要根據關注接口的分析和設計，架構師的一個關鍵職能就是要屏蔽系統本身復雜性，將復雜性作為一個黑盒控制在自己手里，對外只需要暴露盡可能簡單的接口。而在分解的時候又必須要考慮集成，架構師在自己腦海里面已經有了目標系統的樣子，他們會很有信心分解的組件能夠通過當初定義的接口很好的集成在一起。正如汽車制造一樣，所有的零備件都出來了卻發現它們根本無法組裝成一臺汽車，這對架構師是最大的悲哀。系統都還沒有出來，而架構師就能夠游刃有余的做這些事情，靠的不僅僅是多年的設計和開發實踐，更多的則是在實踐過程中的抽象思維和模式總結。
從動態分析的角度來考慮，現實世界中的原始需求進入，最終出來的則是滿足需求的功能實現，在這個過程中涉及到一系列的內部程序流轉流程，前臺界面，業務邏輯，數據訪問，數據實體，公用組件等，這些層次之間應該怎樣去交互是在架構設計中必須要考慮清楚的問題。在這方面我喜歡用架構機制這個詞語，機制往往并不是靜態詞匯，因為要深究機制就必須要搞清楚事件觸發，功能調用，訪問順序等一系列問題。簡單的講，架構機制要回答一個重要的問題，即你設計出的分布式框架如何能夠滿足輸入的需求變成最終輸出的功能，中間究竟經歷了哪些步驟？安全性如何保證？性能如何保證？可擴展性又如何保證？要回答這些問題你都必須給出這些問題的解決方案的運行機制，而只有大家認可了運行機制，或者新出來的模塊已經在新架構上運行驗證了，才能夠講從架構框架上基本上已經成熟了。
架構本身不是目標，而簡單實用并且支持靈活擴展的系統才是我們追求的目標。架構師思維意識里面更加重要的是實用性和經濟性而非理想化，由于業務域和問題域的不同沒有完全可以照搬的架構，在架構設計上追求一定的可擴展性，要杜絕過度架構和架構理想化的問題。就如何建造一個建筑，如果我們最終得不到一個實用的的建筑物，你再怎么向客戶吹噓你的設計圖紙和建造框架如何合理都是徒勞的。
在《人月神話》里面談到，給我看你的流程圖而隱藏起你的表，我將仍然莫名其妙；而給我看你的表，我將不再需要你的流程圖，因為它們太明顯了。足見架構中靜態分析的成分遠遠的大于了動態分析，而靜態分析的重點即我們所說的對象，我需要觀察現實世界有哪些對象以及這些對象之間存在的關系，而這些內容通過抽象之后正是我們談的數據架構。在SOA的參考模型中ESB層面的重點則是通過流程分析和分解后形成的數據集成架構，有了這個才可能進一步的進行基于流程編排的動態架構。即我們先拋開流程，首先通過分解方法來找尋數據形成靜態的數據架構，然后再結合流程來觀察數據的形成和轉化過程。
以下內容摘錄自《架構之美》一書:
有人問過我：架構的最主要產出是什么？我的答案是圖。這里面有兩層含義：一層含義是如同建筑師描繪的藍圖一樣，用于引導實施者；另一層含義是架構師頭腦中清晰的目標系統。如果架構師頭腦中沒有清晰的圖像，他是沒有辦法把它畫出來的。
架構是一個過程，而非一個結果。架構是架構師洞見內在結構、規律、原則和邏輯的過程。真正的架構師是可以將自己放在系統中去的(例如作為系統中的任何一個角色)，只有清晰地理解系統，才能簡潔的描述它。而當架構師拿出了他所描述的作品的時候，架構這個過程就已經結束了。
美麗的架構應盡可能的精益，并且是演進式發展的。當你架構一個支持億萬人同時在線的大規模網站系統的時候，你無法從一開始就提供最完善的解決方案，它應該是隨著用戶的增長而可擴展的。精益的實現讓你避免過度設計，也使架構不斷演進并趨于完美。
美麗的架構無法定義，而它卻是一種自然的，簡單的，可復用的，人文的，甚至是外行人也可以細細品味其思想的。當我看到超市的多個收銀臺前排滿長隊，便想到服務器并發處理性能和容量；當我看到十字路口的車輛需要等待轉彎的時候，便想到用緩存的思想來提高交通吞吐量。
如何設計出美麗的架構？從代碼邏輯到物理網絡，從單機到分布式，無數的技術可以供架構師選擇；如分層，組件化，服務化，標準化，緩存，分離，隊列，復制，冗余，代理等，不過它們僅僅是術的范疇，而何時何處如何恰到好處地使用它們才是道的范疇，比如頓悟變化的道理，在博弈中尋找平衡，以系統化的角度來分析問題，尋找相對與絕對的奧秘，開放的心態。
在軟件設計中，設計師需要考慮多方面的關注點。漂亮的架構設計讓這些關注點盡可能分離，然后以一種最簡單的機制結合在一起，從而得到高內聚，低耦合的系統。愛因斯坦說過，“讓它盡可能簡單，但不要過于簡單”，我們所需要考慮所有必須考慮的關注點，然后用簡單漂亮的架構來體現我們的關注點，以體現架構設計的經濟性。
架構提供一種共同的方法來解決我們軟件開發中面臨的實際問題，架構的核心是概念完整性，即一組抽象和規則，在整個系統中盡可能簡單的使用他們。好的建筑應該通過美觀，堅固和實用三個方面來衡量，而好的架構也正是這三方面的平衡和配合，沒有哪一個方面比其它方面更加重要。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
