一線架構師實踐指南（二）

Conceptual Architecture階段

       有經驗的架構師不會一上來就關注如何定義「接口」，他們在大型系統架構設計的早期比較注重識別重大需求、特點需求、高風險需求，據此來設計概念架構。概念架構是對系統設計最初構想，就是把最關鍵的設計要素和交互機制肯定下來，而後考慮具體技術的運用，設計出實際架構。概念架構應該抓大局、不拘小節。雖然概念架構都跳不出「架構=組件+交互」的基本定義，但它們描述架構的具體方式仍是有比較大的差別：有點重視邏輯層、有點重視物理層、有的經過隱喻代表機制、有的看上去彷佛就是一些設計元素的組合。不一樣的概念架構視圖中，「連接」表明的含義千差萬別：有的是依賴方向，有的是控制方向，有的是控制方向，有的是控制數據流向，所以，必須根據具體狀況而定。在概念架構設計中，不關注明確的接口定義；以後纔是「模塊+接口」一級的設計。對大型系統而言，這一點偏偏是必需的。

       概念架構界定西塘的高層組件，以及它們之間的關係。概念性架構意在對西塘進行適當分解，而不陷入細節。概念架構規定了每一個組件的非正式規約及架構圖，但不涉及接口細節。

       概念架構知足「架構=組件+交互」的基本定義，只不過概念架構僅關注高層組件。概念架構對高層組件的「職責」進行了籠統的界定，並給出了高層組件之間的相互關係。概念架構不該涉及接口細節。需求不一樣，因此架構不一樣；固然，「需求」不是指「功能需求」，而是包含了功能、質量、約束等方面。進行概念呢架構設計時應確立架構大方向。架構設計貴在有針對性，概念架構設計針對重大問題、特點需求、高風險需求的要求，給出高層次的解決方案，這是概念架構的重要意義。所謂「被選架構方案」常常是概念架構一級的，有助於架構的對比分析、評審優化。

       架構設計的驅動力 = 功能 + 質量 + 約束。用例技術是功能需求實際上的標準，用例技術涉及，但沒法全面涵蓋非功能需求。

       初步設計的目標簡單而明確：那就是發現職責。初步設計無需展開架構設計細節，不然就背上了「包袱」，這是複雜系統架構設計起步時的大忌。初步設計識別出了職責，後續的高層分割方案纔有依據，由於每一個「高層分割單元」都是職責的承載體，而分割的目的也偏偏在於規劃高層職責模型。

       實際的工程化實踐中，需求捕獲、需求分析、系統分析不是徹底孤立進行的。相反，它們每每是相互伴隨、交叉進行的。

       有的書上明確地說「實體對象就是持久化對象」，這是錯誤的。由於實體對象涵蓋更普遍，它能夠是持久化對象，也能夠是內存中的任何對象。實體對象不等於持久化對象，這個正確認識將有助於你的實踐。

       分析與綜合是思惟方向相反的過程。通常是先分析後綜合，沒有分析就不能有綜合；沒有綜合的分析，也只是片面的分析。

       「架構=模塊+接口」的作法，其不足可歸納爲兩點：

第一，忽視了多視圖。「模塊+接口」僅是邏輯架構設計視圖的核心內容，而軟件系統的架構設計還可能涉及開發視圖、運行視圖、物理視圖、數據視圖等多方面的考慮。

第二，忽略了概念架構設計。對規模稍大的系統而言，都必須先根據重大風險（包括功能方面、質量方面、約束方面），有針對性地定製包括「高層分割」在內的設計決策，而後纔是「模塊+接口」一級的設計。

架構設計中「高層分割」的兩種實踐套路：

l   切系統爲系統；

l   切系統爲子系統。

高層分割很重要，但不是概念架構的所有。除了切分決策以外，概念架構還包括技術選擇、權衡策略等種類的決策。

 

 

Refined Architecture階段

       概念架構難以支持並行開發。要支持開發組相對獨立地進行工做，需要提供指導和限制做用更明確的「規約」一級的設計。細化架構和概念架構之間存在以下典型差別：

l   接口。在細化架構中，接口占據很是核心的地位，而概念架構並不關心明確的接口定義（只有抽象的組件和抽象的交互機制）。

l   子系統。細化架構重視經過子系統和模塊來分割整個系統，而且子系統每每有明確的接口；而概念架構中只有抽象的組件，這些組件沒有接口，只有職責，通常是處理組件、數據組件或連接組件中的一種。

l   交互機制。細化架構中的交互機制應是「實在」的，如基於接口編程、消息機制或遠程方法調用等；而概念架構的交互機制是「概念化」的。

固然，概念架構和細化架構都知足軟件架構的定義——不管是「架構=組件+交互」，仍是「架構=重要決策集」。

方案=「項目+需求+架構」 的總攬，方案！=架構的所有。

       架構設計是一門解決複雜問題的實踐藝術，因而，以分而治之爲核心思想的多視圖方法必不可少。Refined Architecture（細化架構）屬於架構設計，不能與Detailed Design（詳細設計）相混淆。

       不一樣涉衆看待軟件架構的視角是不一樣的。多視圖方法有兩方面的實際意義：

l   利於思考（由於分而治之的思惟方式）；

l   便於交流（由於在必定程度上分離了涉衆關注點）  。

5視圖方法包括：邏輯視圖、開發視圖、運行視圖、物理視圖、數據視圖。5視圖各有其「思惟立足點」，分別是：

l   職責劃分（邏輯視圖）

l   程序單元組織（開發視圖）

l   控制流組織（運行視圖）

l   物理節點安排（物理視圖）

l   持久化設計（數據視圖）

看似複雜的5視圖方法其實很簡單，由於其每一個視圖都是從特定角度規劃系統的分割與交互，都是（架構的定義）「組件+交互」的一種體現。

一線架構師最缺的不是理論，也不是技術，而是位於理論和技術之間的「實踐策略」和「實踐套路」。

分層是最經常使用的架構模式。在架構設計初期，100%的系統均可以用分層架構，就算隨之設計的深刻而採用了其餘架構模式也未必和分層架構矛盾。

爲了獲得客戶常常性的反饋，快速迭代有個基本前提：開發應該「深度優先」，而不是「廣度優先」。爲了支持迭代開發，邏輯架構設計中必須引入分區。分區是一種單元，它位於某個層的內部，其粒度比層要小。一旦架構師針對每一個層進行了分區設計，「深度優先」式的迭代開發就很是天然。

機制纔是設計的靈魂所在，不然咱們就將不得不面對一羣沒法相互協做的對象，它們相互推搡着作本身的事情而絕不關心其餘對象。軟件系統中的機制，是指預先定義好的、可以完成預期目標的、基於抽象角色的協做方式。機制不只包含了協做關係，同時也包含了協做流程。對於編程實現而言，在沒有提取機制的狀況下，機制是一種隱式的重複代碼。對於邏輯架構設計而言，機制是一種特殊的子系統，做爲子系統的機制並不能「直接實現」軟件的「最終功能」。在實現不一樣的最終功能時，能夠重用同一個機制，避免重複進行繁瑣的「組裝」工做。

 

子系統劃分的4個重要原則

l   職責不一樣的單元劃歸不一樣子系統（職責分離原則）

l   通用性不一樣的單元劃歸不一樣子系統（通用專用分離原則）

l   須要不一樣開發技能的單元劃歸不一樣子系統（技能分離原則）

l   兼顧工做量的相對平衡，進一步切分太大的子系統（工做量均衡原則）

 

對問題進行分解，分別解決小問題，其實這只是手段。合纔是目的，不能「合」在一塊兒支持更高層次功能模塊，又有何用？

 

硬件強大了，但數據量在增長，計算複雜性也在提升，因此增長硬件未必能解決問題。增長硬件= 增長計算能力！= 軟件的實際服務能力加強

物理架構視圖着重考慮運行軟件的計算機、網絡、硬件設施等狀況，還包括如何將軟件包部署到這些硬件資源上，以及它們運行時的配置狀況。因爲一部分運行時質量屬性須要硬件或網絡的支持，因此物理架構必須關注如何配置硬件和網絡來知足軟件系統的可靠性、可伸縮性、持續可用性、性能、安全性等方面的要求。

物理架構設計有3項任務：

l   硬件的選擇與物理拓撲

l   軟件到硬件的映射關係

l   方案的優化

 

若是系統中，並不許備引入任何並行或併發處理，而且系統也沒有基於SDK、API等基礎軟件進行定製開發，那就不需要設計運行架構的設計。

最經常使用於實際控制流的手段有3種：

l   進程

l   線程

l   中斷服務程序

 

開發架構的設計應完成下列工做：

l   將「邏輯職責」映射爲「程序單元」

Ø  要自主編寫的源程序

Ø  可重用的庫、框架

Ø  其餘方式（如shell腳步、平臺支持下的配置文件）

l   開發技術選型

Ø  開發語言

Ø  開發工具

l   「程序單元」間關係

Ø  Project劃分

Ø  Project目錄結構

Ø  編譯依賴關係

 

非功能需求的考慮是「貫穿環節」，在概念架構設計階段，以及細化架構設計階段都應重視。對大型系統而言，開發架構設計中的「Project劃分」是不可或缺的。

 

肯定數據分佈方案是數據架構設計的難點。越是大系統，數據分佈越關鍵。所謂分佈式系統，不僅僅是程序的分佈，還涉及數據的分佈。常採用不一樣的數據分佈存儲與處理手段有：

Ø  獨立Schema（Separate-schema）

Ø  集中（Centralized）

Ø  分區（Partitioned）

Ø  複製（Replicated）

Ø  子集（subset）

Ø  重組（Reorganized）

分區方式包括水平分區和垂直分區兩種類型。水平分區的特色能夠歸納爲「兩個相同，兩個不一樣」——相同的應用程序、不一樣的應用程序部署實例（instance）相同的數據模型，不一樣的數據值。在實踐中，水平分區的應用很是普遍，而垂直分區的的做用相比之下要小得多。

在整個分佈式系統中，數據保存多個副本，而且以某種機制（實時或快照）保持多個數據副本之間的數據一致性，這就是複製方式的數據分佈策略。

「子集」是「複製」的特殊方式，就是某節點因功能或非功能考慮而保存全體數據的一個相對固定的子集。

重組這種數據分佈策略，就是不一樣數據節點因要支持的功能不一樣，而以不一樣的Schema保存數據——但本質上這些數據是同源的。因而，重組策略要進行數據傳遞，而不是數據的「原樣」複雜，而是以「從新組織」的格式進行傳遞或保存。根據典型的應用背景，重組分爲兩種類型：統計性重組和結構性重組。

 

非功能目標的方法論

       軟件架構設計爲何這麼難？由於架構設計不是簡單地處理「純粹的技術問題」，而是要面對「技術與業務的關係問題」。最終，要求架構師不只懂技術、懂業務，並且可以理順複雜的技術和業務之間的關係。

       從面向業務的需求，到最終的面向技術的軟件系統，要跨越很大的鴻溝。軟件架構設計就是要完成從面向業務到面向技術的轉換，在鴻溝上架起一座橋樑。軟件架構師根據各類需求進行架構設計，最終的軟件架構包含告終構、協做、技術等方面的重要決策，爲系統化的開發活動創建了基礎。精通需求，是對架構師最基本要求之一，不瞭解需求是如今許多架構師職業發展道理上的瓶頸。值得強調的是，需求分析師和架構師這兩個角色要掌握的需求知識並不徹底同樣。經典的觀點師認爲架構師應該掌握的需求知識師需求分析師的一個子集，其實否則。架構師必須懂需求。雖然無需研究諸如需求捕獲等技術，但需求類型、需求影響架構的原理、質量屬性間的相互影響關係都是必須精通的。

       架構設計實踐中，面對非功能需求目標時是容易犯「拍腦殼」這個經典錯誤的。非功能目標的設計是以場景技術爲核心手段、以目標-場景-決策表爲思惟工具，致力於支撐非功能目標的理性設計過程。非功能需求不願能是「速決戰」，它必然是「持久戰」，連編碼都會影響到性能等非功能屬性，更況且概念架構設計和細化架構設計呢？因此架構師必須注意，非功能目標的考慮是縱穿架構始終的環節。

       軟件的質量是設計出來的，這是公認的一個基本觀點。實踐中，架構師必須對場景進行評估，以決定是否支持這個場景。架構師常常要考慮的場景評估因素包括：

l   價值大小

l   代價大小

l   開發難度高低

l   技術趨勢

最後，必須提醒的是「不支持某場景」偏偏是架構師的一種重要決策——若是每一個場景都給予支持，理性設計就無從談起，過分設計就在所不免了。