一、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. 業務的服務化：站在企業的角度，把企業職能抽象成可復用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能復用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。
本文作者：張永清 來源出處：
https://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注重水平服務，微服務注重垂直服務
本文作者：張永清 來源出處：
https://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設計。 依賴關系
