從零開始學架構（二）架構知識領域

更新說明

本篇文章已經整理完很長時間，總感受有些不足，所以一直無法，但願潤色後再發，深感本身水平有限，遲遲沒有動筆。可是收到多位朋友的邀約，思考再三決定逐步完成本系列文章。其中不足，請批評指正，咱們一塊兒進步。

內容摘要

主要從架構方法論，系統劃分，架構原則，通用模式，架構視圖，幾個方面。總體上介紹了架構相關的知識領域，在此基礎上，能夠有目的的學習相關資料。

本篇主題 

2.1架構方法論：面向過程，面向對象，面向方面，面向服務

2.2系統劃分：系統，子系統，模塊，功能，接口

2.3架構基本原則：場景化，抽象， 通用專用，高內聚，鬆耦合 ，職責劃分，關注點分離， 分層架構等

2.4模式：設計模式，架構模式，基礎設施模式

2.5架構視圖：4+1視圖

1、架構方法論

在架構領域主要包括面向過程，面向對象，面向方面，面向組件，面向服務等方法論。每種方法關注的點有所不一樣。並伴隨着軟件工程和系統規模逐漸演化。具體使用哪一種方式，須要根據實際場景，進行合理的技術選型。如下將綜合介紹，主流編程方式的相關知識總結。

1.1面向過程（Procedure-Oriented Programming ）

結構化編程思想的核心：功能分解（自頂向下，逐層細化）。將一個大的問題劃分爲幾個小的問題，再將幾個小的問題劃分爲更小的問題，咱們解決大問題很是困難，可是解決劃分後的最小的問題卻比較容易。

面向過程編程把編程任務劃分紅一個一個的步驟，而後按照步驟分別去執行。其中每完成一個步驟就像是完成一個任務中的單個過程同樣。

公式：程序=算法+數據結構

關注：流程，函數，庫文件

優勢：記帳式代碼，容易理解

缺點：與業務流程強耦合，複用性差

表明語言：Basic，C

1.2面向對象（Object-Oriented Programming）

面向對象編程（Object-Oriented Programming）簡稱OOP技術。面向過程編程經常會致使全部的代碼都包含在幾個模塊中，使程序難以閱讀和維護。在作一些修改時經常牽一動百，使之後的開發和維護難覺得繼。而使用OOP技術，經常要使用許多代碼模塊，每一個模塊都只提供特定的功能，它們是彼此獨立的，這樣就增大了代碼重用的概率，更加有利於軟件的開發、維護和升級。

在面向對象中，算法與數據結構被看作是一個總體，稱做對象，現實世界中任何類的對象都具備必定的屬性和操做，也總能用數據結構與算法二者合一地來描述，因此能夠用下面的等式來定義對象和程序：

對象=（算法+數據結構），程序=（對象+對象+……）

從上面的等式能夠看出，程序就是許多對象在計算機中相繼表現本身，而對象則是一個個程序實體。

面向對象編程思想的核心：一切皆對象，抽象，複用，提升靈活性

面向對象編程思想主要是複用性和靈活性（彈性）。複用性是面向對象編程的一個主要機制。靈活性主要是應對變化的特性，由於客戶的需求是不斷改變的，怎樣適應客戶需求的變化，這是軟件設計靈活性或者說是彈性的問題。

公式：程序=對象+交互【對象=（算法+數據結構），程序=（對象+對象+……）】

關注：抽象，對象，類，繼承，封裝，多態

優勢：複用性，擴展性，靈活性，維護性

缺點：對象化將簡單的問題複雜化，不能解決公用橫切代碼問題

表明語言：Java，C#

方法論：

OOA: Object Oriented Analysis 面向對象分析方法

OOD:Object Oriented Design 面向對象設計

OOP: Object Oriented Programming 面向對象的程序開發

1.3面向組件（Component-Oriented Programming）

面向對象支持重用，可是重用的單元很小，通常是類；而面向組件則不一樣，它能夠重用多個類甚至一個程序（組件）。也就是說面向組件支持更大範圍內的重用，開發效率更高。若是把面向對象比做重用零件，那麼面向組件則是重用部件。

COP比OOP更進一步。一般OOP將數據對象組織到實體中。這種方法具備不少優勢。可是，OOP有一個大的限制：對象之間的相互依賴關係。去掉這個限制的一個好的想法就是組件。組件和通常對象之間的關鍵區別是組件是能夠替代的。

公式：程序=組件+交互

關注點：功能模塊

優勢：將系統組件化設計，提升複用性

缺點：增長了組件維護和升級成本

表明框架：OSGI

1.4面向方面（Aspect-Oriented Programming）

將通用需求功能從不相關類之中分離出來；同時，可以使得不少類共享一個行爲，一旦行爲發生變化，沒必要修改不少類，只要修改這個行爲就能夠。

AOP就是這種實現分散關注的編程方法，它將「關注」封裝在「方面」中。

基本定義：將通用功能與業務邏輯分離

關注點：切面，通知，鏈接點，織入

實現技術：動態代理

表明框架：Spring AOP

1.5面向服務（Service-Oriented Programming）

SOP是一種體系結構，目標是在軟件代理交互中得到鬆散耦合。一個服務是一個服務提供者爲一個服務消費者得到其想要的最終結果的一個工做單元。服務者與消費者都以軟件代理表明他們本身的角色。

    這聽起來有些太抽象，可是SOP確實無處不在。讓咱們在你的住房中找到一個SOP的例子。例如播放一個CD,你能夠將要播放的CD放入CD機中，CD機將爲你播放這張CD，CD機提供了一個CD播放服務。這裏的好處就是你能夠用不一樣的CD機去播放同一張CD。他們能提供一樣的CD播放服務，可是服務質量是不一樣的。

    SOP的思想明顯不一樣於面向對象的編程，面向對象編程強烈的建議你應該將數據與其操做綁定。所以在面向對象編程風格中，每張CD 有它本身的CD播放機，他們之間不能被拆開。這聽起來很奇怪，可是這就是咱們創建許多已存軟件系統的方式。

而SOP就不同了，爲了減小異構性、互操做性和不斷改變的要求的問題，這樣的體系結構應該提供平臺來構建具備下列特徵的應用程序服務：

鬆散耦合、位置透明、協議獨立

    基於這樣的面向服務的體系結構，服務使用者甚至沒必要關心與之通訊的特定服務，由於底層基礎設施或服務「總線」將表明使用者作出適當的選擇。基礎設施對請求者隱藏了儘量多的技術。特別地，來自不一樣實現技術（如 J2EE 或 .NET）的技術規範不該該影響 SOP用戶。若是已經存在一個服務實現，咱們就還應該從新考慮用一個「更好」的服務實現來代替，新的服務實現必須具備更好的服務質量。

公式：系統=服務+交互

關注點：服務化，業務拆分，獨立部署，服務粒度

演變：Rpc，服務框架，服務治理，微服務

優勢：提供業務粒度的複用組件，能夠有效利用資源提升性能

缺點：維護，部署成本高，須要自動化

表明框架：Dubbo，Zero Ice，Spring boot

2、系統拆分

要解決複雜系統的架構問題，在需求分析的基礎上，要首先進行系統的拆分，將大系統拆分爲小的系統，小的系統拆分爲模塊。採用分而治之的方式，進行系統架構設計。關於拆分的粒度與實際的項目和團隊狀況，有所差別。本節只介紹通用的系統拆分方法。

系統的拆分能夠按照縱向和橫向切分，縱向是指按照業務系統或功能模塊進行拆分。橫向是按照分層架構進行切分。

2.1垂直拆分（縱向）

縱向切分可分爲：系統，子系統，模塊，功能，接口

系統：

子系統：根據職責劃分的，具備不一樣的業務意義切分的系統。好比用戶子系統，訂單子系統。

模塊：實現某一個功能的集合，解決某一特定問題。好比會員模塊。

功能：模塊中的一個功能點，實現某種能力，好比會員註冊功能。

接口：對外暴露，提供對外訪問自身功能的能力。

縱向切分是從粗到細的過程，通過分析很好的定義了系統的功能分解結構。可根據分解結構，進行功能細化或項目預估。

2.2水平拆分（橫向）

橫向切分可按照物理或邏輯方式切分，物理切分是指將一個系統進行橫向切分後的每一層或多層一塊兒部署，每一個部署實例表明一層或多層。好比接入層，服務層，資源層等。

邏輯切分是不考慮實際部署，從系統的邏輯角度出發進行分層。可分爲表現層，業務層，資源整理層，資源層。具體的部署，多是集中也多是分開部署。

設計要點：每一層都有本身的邊界，關注點和職責，上層依賴底層，避免跨層調用。

3、架構基本原則

架構設計，須要依據一些基本原則進行設計，在原則的基礎上進行權衡，取捨，得到最終的架構決策。本節介紹，幾種經常使用的架構原則。

場景化：每一個需求都應該有適應的場景，基於場景進行設計，避免無目標或設計過渡。

抽象：將具體的事物，根據共性進行抽象，將公有行爲抽象爲接口，將共有邏輯抽象爲基類。

高內聚：指部件的內部關係，將屬於本身的屬性，行爲進行封裝，對外暴露必要的接口。當內部改變時，不影響外部的使用。

鬆耦合：指部件之間的依賴關係，應該是弱依賴，而不是強依賴，可經過接口或異步實現解藕。

關注點/職責分離：將不一樣職責或關注點不一樣的進行拆分，使其只負責本身的事情，而不負責其餘的事情。基本要求是分離不相關的，分離不穩定的。

分層架構：將系統進行物理層和邏輯層拆分，每層只關注本身負責的事情，並提供對外訪問接口。分層能夠將系統進行拆分，易於層級複用，代碼維護性好，可根據工種分工。

通用專用：將通用部件和專用部件進行拆分，下降耦合度，提升複用性和可維護性。

平衡：沒有最好的架構，只有更合適的架構，權衡需求，技術，約束，質量，成本等影響因素作出最好的決策。是架構師必須把握的第一方法論。

其餘原則：SOLID

4、模式

模式是針對某一問題的通用解決方案，是前人智慧的結晶。經過應用模式，能夠快速有效的找到最佳解決方案。系統架構中涉及三種模式，設計模式，架構模式，基礎設施模式，分別解決代碼結構，系統結構以及網絡和硬件部署的問題。

4.1設計模式

解決的問題：代碼設計層面，通用問題的通用解決方案。

模式分類：建立型（5），結構型（7），行爲型（11）

建立型：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

結構型：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

行爲型：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

模式彙總：借用一張圖：出處（23種設計模式全解析）：https://www.cnblogs.com/geek6/p/3951677.html

 

4.2架構模式

解決的問題：肯定系統中關鍵架構設計的架構和交互機制。

模式分類：

一、模塊結構(From Mud to Structure)型。幫助架構師將系統合理劃分，避免造成一個對象的海洋。 包括 Layers （分層）模式、 Blackboard （黑板）模式、 Pipes/Filters （管道/過濾器）模式等。

 

二、

分散系統（Distributed Systems）型。爲分散式系統提供完整的架構設計，包 括像 Broker（中介）模式等。

三、人機互動（Interactive Systems）型，支持包含有人機互動介面的系統的架構設計，例子包括 MVC（Model-View-Controller）模式、PAC （Presentation-Abstraction-Control）模式等。

 

四、

 Adaptable Systems 型， 支持應用系統適應技術的變化、 軟件功能需求的變化。 如 Reflection（反射）模式、Microkernel（微核）模式等。

模式小結：此圖出處（10種常見的軟件架構模式）：https://www.cnblogs.com/IcanFixIt/p/7518146.html

 

4.3基礎設施模式

解決的問題：硬件，網絡等底層設計和基礎架構問題。

模式分類：涉及硬件，網絡，中間件，安全等方面。

可詳見書籍《基礎設施設計模式》

 5、架構視圖

  架構視圖是從不一樣的涉衆看問題的角度出發，設計符合不一樣涉衆需求的架構設計方案。用於全面，精確的分析和設計符合不一樣涉衆要求的系統架構。業界使用比較多的是4+1視圖。

 

5.1邏輯視圖

邏輯架構的目的是職責的劃分，並明確其與協做關係；其中職責的劃分注意邏輯的分層、子系統以及關鍵類的定義；協做的定義關注接口的定義與協做關係的明確。

5.2開發視圖

開發架構的目的是肯定程序單元以及程序單元的組織結構；其中程序單元包括源文件、配置文件、程序庫、框架、目標單元；程序單元組織包括project劃分、project目錄結構、編譯依賴關係。

5.3數據視圖

數據架構的目的是肯定要存儲的數據以及存儲格式；其中存儲的數據能夠是文件、關係數據庫、實時數據庫；存儲格式包括文件格式、數據庫圖表

5.4物理視圖

物理架構的目的是肯定物理節點和物理節點的拓撲結構；其中物理節點包括服務器、PC機、專用機、軟件安裝部署燒寫以及系統軟件的選型；拓撲結構明確物理節點的關係。

5.5運行視圖

運行架構的目的是肯定控制流和控制流的組織；其中控制流包括進程、線程、服務程序；控制流組織包括系統的啓動與停機、控制流通信、同步與加鎖。

6、擴展知識

本部門內容可自行學習瞭解。

6.1插件架構和開發

6.2微服務架構

6.3UML建模

7、本篇總結

主要從架構方法論，系統劃分，架構原則，通用模式，架構視圖，幾個方面。總體上介紹了架構相關的知識領域，在此基礎上，能夠有目的的學習相關資料。

8、參考資料

從面向過程到面向對象:http://blog.csdn.net/hjf19790118/article/details/6919578

面向對象編程（OOP）、面向組件編程（COP）、面向方面編程（AOP）和麪向服務編程（SOP）:http://blog.csdn.net/ocean181/article/details/6720371

面向對象，面向組件，面向接口，面向方面，面向服務編程的一些比較

http://chunniux.blog.163.com/blog/static/148497192012012101549604/

面向對象程序設計與面向過程程序設計解析

http://blog.csdn.net/tianfeng701/article/details/8040304

軟件架構設計-五視圖方法論:https://blog.csdn.net/nnsword/article/details/78109126

軟件架構設計-五視圖方法論:https://www.cnblogs.com/hongbo819/p/4871412.html

9、下篇預告

第三篇 UML建模

3.1架構模型

3.2靜態模型

3.3動態模型

3.4建模案例