比較全的常見的架構設計思想整理
一、MPP 架構
1、MPP架構的基礎概念
MPP (Massively Parallel Processing)，即大規模並行處理，在資料庫非共享集群中，每個節點都有獨立的磁碟存儲系統和記憶體系統，業務數據根據資料庫模型和應用特點劃分到各個節點上，每台數據節點通過專用網路或者商業通用網路互相連接，彼此協同計算，作為整體提供資料庫服務。非共享資料庫集群有完全的可伸縮性、高可用、高性能、優秀的性價比、資源共享等優勢。
簡單來說，MPP是將任務並行的分散到多個伺服器和節點上，在每個節點上計算完成後，將各自部分的結果匯總在一起得到最終的結果(與Hadoop相似)。
MPP 屬於Shared Nothing，根據Shared 的不同，可以分為如下幾種：
Shared Everthting:一般是針對單個主機，完全透明共享CPU/MEMORY/IO，並行處理能力是最差的，典型的代表SQLServer
Shared Disk：各個處理單元使用自己的私有 CPU和Memory，共享磁碟系統。典型的代表Oracle Rac， 它是數據共享，可通過增加節點來提高並行處理的能力，擴展能力較好。其類似於SMP（對稱多處理）模式，但是當存儲器介面達到飽和的時候，增加節點並不能獲得更高的性能 。
Shared Nothing：各個處理單元都有自己私有的CPU/記憶體/硬碟等，不存在共享資源，類似於MPP（大規模並行處理）模式，各處理單元之間通過協議通訊，並行處理和擴展能力更好。典型代表DB2 DPF和hadoop ，各節點相互獨立，各自處理自己的數據，處理後的結果可能向上層匯總或在節點間流轉。
我們常說的 Sharding 其實就是Share Nothing架構，它是把某個表從物理存儲上被水平分割，並分配給多台伺服器（或多個實例），每台伺服器可以獨立工作，具備共同的schema，比如MySQL Proxy和Google的各種架構，只需增加伺服器數就可以增加處理能力和容量。
很多 Nosql資料庫都是基於 MPP Shared Nothing架構的，比如
Greenplum是一種基於PostgreSQL的分散式資料庫。其採用shared nothing架構（MPP），主機，作業系統，記憶體，存儲都是自我控制的，不存在共享。也就是每個節點都是一個單獨的資料庫。節點之間的資訊交互是通過節點互聯網路實現。通過將數據分布到多個節點上來實現規模數據的存儲，通過並行查詢處理來提高查詢性能。
這個就像是把小資料庫組織起來，聯合成一個大型資料庫。將數據分片，存儲在每個節點上。每個節點僅查詢自己的數據。所得到的結果再經過主節點處理得到最終結果。通過增加節點數目達到系統線性擴展。
elasticsearch也是一種MPP架構的資料庫，Presto、Impala等都是MPP engine，各節點不共享資源，每個executor可以獨自完成數據的讀取和計算，缺點在於怕stragglers，遇到後整個engine的性能下降到該straggler的能力，所謂木桶的短板，這也是為什麼MPP架構不適合異構的機器，要求各節點配置一樣。
Spark SQL應該還是算做Batching Processing, 中間計算結果需要落地到磁碟，所以查詢效率沒有MPP架構的引擎（如Impala）高。
2、MPP架構特徵
● 任務並行執行;
● 數據分散式存儲(本地化);
● 分散式計算;
● 私有資源;
● 橫向擴展;
● Shared Nothing架構。
3、基於MPP架構的資料庫架構
這種架構中的每一個節點（node）都是獨立的、自給的、節點之間對等，而且整個系統中不存在單點瓶頸，具有非常強的擴展性。
二、SMP(Symmetric Multi-Processor)架構
SMP又稱對稱多處理器結構，SMP系統內有許多緊耦合多處理器，在這樣的系統中，所有的CPU共享全部資源，如匯流排，記憶體和I/O系統等;
所謂對稱多處理器結構，是指伺服器中多個 CPU 對稱工作，無主次或從屬關係。各 CPU 共享相同的物理記憶體，每個 CPU 訪問記憶體中的任何地址所需時間是相同的，因此 SMP 也被稱為一致存儲器訪問結構 (UMA ： Uniform Memory Access) 。對 SMP 伺服器進行擴展的方式包括增加記憶體、使用更快的 CPU 、增加 CPU 、擴充 I/O( 槽口數與匯流排數 ) 以及添加更多的外部設備 ( 通常是磁碟存儲 ) 。
主要特徵是共享，系統中所有資源 (CPU 、記憶體、 I/O 等 ) 都是共享的。也正是由於這種特徵，導致了SMP 伺服器的主要問題，那就是它的擴展能力非常有限。對於 SMP 伺服器而言，每一個共享的環節都可能造成 SMP 伺服器擴展時的瓶頸，而最受限制的則是記憶體。由於每個 CPU 必須通過相同的記憶體匯流排訪問相同的記憶體資源，因此隨著 CPU 數量的增加，記憶體訪問衝突將迅速增加，最終會造成 CPU 資源的浪費，使 CPU 性能的有效性大大降低。實驗證明， SMP 伺服器 CPU 利用率最好的情況是 2 至 4 個 CPU 。
三、SOA 架構
SOA 即面向服務的架構，將應用程式的不同功能單元（稱為服務）進行拆分，並通過這些服務之間定義良好的介面和協議聯繫起來，介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平台、作業系統和程式語言。這使得構件在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。
面向服務架構，它可以根據需求通過網路對鬆散耦合的粗粒度應用組件進行分散式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟體代理交互的人為依賴性，SOA是一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義介面進行通訊，不涉及底層編程介面和通訊模型。
松耦合系統腳骨的好處有兩點：
1、它的靈活性，它非常的靈活。
2、當組成整個應用程式的每個服務的內部結構和實現逐漸地發生改變時，它能夠繼續存在。與之相反，緊耦合意味著應用程式的不同組件之間的介面與其功能和結構是緊密相連的，因而當需要對部分或整個應用程式進行某種形式的更改時，它們就顯得非常脆弱。
一個服務通常以獨立的形式存在與作業系統進程中。各個服務之間通過網路調用跟SOA 相提並論的還有一個ESB（企業服務匯流排），單來說ESB 就是一根管道，用來連接各個服務節點。為了集成不同系統，不同協議的服務，ESB 做了消息的轉化解釋和路由工作，讓不同的服務互聯互通。
SOA 所解決的核心問題：
1. 系統集成：站在系統的角度，解決企業系統間的通訊問題，把原先散亂、無規劃的系統間的網狀結構，梳理成規整、可治理的系統間星形結構，這一步往往需要引入一些產品，比如ESB、以及技術規範、服務管理規範；
這一步解決的核心問題是【有序】
2. 系統的服務化：站在功能的角度，把業務邏輯抽象成可復用、可組裝的服務，通過服務的編排實現業務的快速再生，目的：把原先固有的業務功能轉變為通用的業務服務，實現業務邏輯的快速復用；這一步解決的核心問題是【復用】
3. 業務的服務化：站在企業的角度，把企業職能抽象成可復用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；「前面兩步都是從技術層面來解決系統調用、系統功能復用的問題」。第三步，則是以業務驅動把一個業務單元封裝成一項服務。
本文作者：張永清 來源出處：//www.cnblogs.com/laoqing/p/13042432.html
四、微服務架構
微服務架構其實和SOA 架構類似,微服務是在SOA 上做的升華，微服務架構強調的一個重點是「業務需要徹底的組件化和服務化」，原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。
組件表示一個可以獨立更換和升級的單元，就像PC 中的CPU、記憶體、顯示卡、硬碟一樣，獨立且可以更換升級而不影響其他單元。如果我們把PC 作為組件以服務的方式構建，那麼這台PC 只需要維護主板和一些必要的外部設備。CPU、記憶體、硬碟都是以組件方式提供服務，PC 需要調用CPU 做計算處理，只需要知道CPU 這個組件的地址即可。
SOA與微服務區別：
1、SOA注重重用，微服務注重重寫
SOA 的主要目的是為了企業各個系統更加容易地融合在一起。
微服務通常由重寫一個模組開始。要把整個巨石型的應用重寫是有很大的風險的，也不一定必要。我們向微服務遷移的時候通常從耦合度最低的模組或對擴展性要求最高的模組開始。
把它們一個一個剝離出來用敏捷地重寫，可以嘗試最新的技術和語言和框架，然後 單獨布署。它通常不依賴其他服務。微服務中常用的 API Gateway 的模式主要目的也不是重用程式碼。
而是減少客戶端和服務間的往來。API gateway 模式不等同與 Facade 模式，我們可以使用如 Future 之類的調用，甚至返回不完整數據。
2、SOA注重水平服務，微服務注重垂直服務
本文作者：張永清 來源出處：//www.cnblogs.com/laoqing/p/13042432.html
SOA 設計喜歡給服務分層(如 Service Layers 模式)。我們常常見到一個 Entity 服務層的設計，美其名曰 Data Access Layer。這種設計要求所有的服務都通過這個 Entity 服務層。來獲取數據。這種設計非常不靈活，比如每次數據層的改動都可能影響到所有業務層的服務。而每個微服務通常有它自己獨立的 Data Store。我們在拆分資料庫時可以適當的做些去範式化，讓它不需要依賴其他服務的數據。
微服務通常是直接面對用戶的，每個微服務通常直接為用戶提供某個功能。類似的功能可能針對手機有一個服務，針對機頂盒是另外一個服務。在 SOA 設計模式中這種情況通常會用到 Multi-ChannelEndpoint 的模式返回一個大而全的結果兼顧到所有的客戶端的需求。
3、SOA注重自上而下，微服務注重自下而上
SOA 架構在設計開始時會先定義好服務合約。它喜歡集中管理所有的服務，包括集中管理業務邏輯，數據，流程，Schema 等。它使用 Enterprise Inventory 和 Service Composition 等方法來集中管理服務。SOA 架構通常會預先把每個模組服務介面都定義好。模組系統間的通訊必須遵守這些介面，各服務是針對他們的調用者。
SOA 架構適用於 TO GAF 之類的架構方法論。
微服務則敏捷得多。只要用戶用得到，就先把這個服務挖出來。然後針對性的，快速確認業務需求，快速開發迭代。
微服務與 SOA 有很多相同之處。兩者都屬於典型的、包含松耦合分散式組件的系統結構。在圍繞著服務的概念創建架構這一方面，微服務提供了一種更清晰、定義更良好的方式。微服務的原則與敏捷軟體開發思想是高度一致的，而它與 SOA 原則的演化的目標也是相同的，則減少傳統的企業服務匯流排開發的高複雜性。兩者之間最關鍵的區別在於，微服務專註於以自治的方式產生價值。但是兩種架構背後的意圖是不同的：SOA 嘗試將應用集成，一般採用中央管理模式來確保各應用能夠交互運作。微服務嘗試部署新功能，快速有效地擴展開發團隊。它著重於分散管理、程式碼再利用與自動化執行。
五、架構設計圖
1、技術架構
從技術層面描述，主要是分層模型，例如持久層、數據層、邏輯層、應用層、表現層等，然後每層使用什麼技術框架，例如Spring、hibernate、ioc、MVC、成熟的類庫、中間件、WebService等，分別說明，要求這些技術能夠將整個系統的主要實現概括
2、系統架構
指的完整系統的組成架構，例如系統分成幾個部分？服務平台、管理門戶、終端門戶、ATM門戶、外部系統以及介面、支撐系統等，將這些系統進行合理的劃分。然後再進行功能分類細分，總之，將整個系統業務分解為邏輯功能模組，並且科學合理，就是系統架構
3、部署架構
指的是系統如何部署，包括應用的節點機器，網路、交換機，防火牆等。比如採用什麼網路，nginx 部署幾台，vip如何轉發、APP應用部署多少個節點等。
4、數據架構
數據架構指導資料庫的設計. 不僅僅要考慮開發中涉及到的資料庫，實體模型，也要考慮物理架構中數據存儲的設計。
5、程式碼架構
子系統程式碼架構主要為開發人員提供切實可行的指導，如果程式碼架構設計不足，就會造成影響全局的架構設計。比如公司內不同的開發團隊使用不同的技術棧或者組件，結果公司整體架構設計就會失控。
程式碼架構主要定義：
①. 程式碼單元:
配置設計框架、類庫。
②. 程式碼單元組織：
編碼規範，編碼的慣例。項目模組劃分頂層文件結構設計，比如mvc設計。依賴關係
未完待續，後續會補充大數據相關的架構
