1、MPP 架構html
一、MPP架構的基礎概念node
MPP (Massively Parallel Processing)，即大規模並行處理，在數據庫非共享集羣中，每一個節點都有獨立的磁盤存儲系統和內存系統，業務數據根據數據庫模型和應用特色劃分到各個節點上，每臺數據節點經過專用網絡或者商業通用網絡互相鏈接，彼此協同計算，做爲總體提供數據庫服務。非共享數據庫集羣有徹底的可伸縮性、高可用、高性能、優秀的性價比、資源共享等優點。nginx
簡單來講，MPP是將任務並行的分散到多個服務器和節點上，在每一個節點上計算完成後，將各自部分的結果彙總在一塊兒獲得最終的結果(與Hadoop類似)。sql
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）高。
二、MPP架構特徵
● 任務並行執行;
● 數據分佈式存儲(本地化);
● 分佈式計算;
● 私有資源;
● 橫向擴展;
● Shared Nothing架構。
三、基於MPP架構的數據庫架構
這種架構中的每個節點（node）都是獨立的、自給的、節點之間對等，並且整個系統中不存在單點瓶頸，具備很是強的擴展性。
2、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 。
3、SOA 架構
SOA 即面向服務的架構，將應用程序的不一樣功能單元（稱爲服務）進行拆分，並經過這些服務之間定義良好的接口和協議聯繫起來，接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操做系統和編程語言。這使得構件在各類各樣的系統中的服務能夠以一種統一和通用的方式進行交互。
面向服務架構，它能夠根據需求經過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用。服務層是SOA的基礎，能夠直接被應用調用，從而有效控制系統中與軟件代理交互的人爲依賴性，SOA是一種粗粒度、鬆耦合服務架構，服務之間經過簡單、精肯定義接口進行通信，不涉及底層編程接口和通信模型。
鬆耦合系統腳骨的好處有兩點：
一、它的靈活性，它很是的靈活。
二、當組成整個應用程序的每一個服務的內部結構和實現逐漸地發生改變時，它可以繼續存在。與之相反，緊耦合意味着應用程序的不一樣組件之間的接口與其功能和結構是緊密相連的，於是當須要對部分或整個應用程序進行某種形式的更改時，它們就顯得很是脆弱。
一個服務一般以獨立的形式存在與操做系統進程中。各個服務之間經過網絡調用跟SOA 相提並論的還有一個ESB（企業服務總線），單來講ESB 就是一根管道，用來鏈接各個服務節點。爲了集成不一樣系統，不一樣協議的服務，ESB 作了消息的轉化解釋和路由工做，讓不一樣的服務互聯互通。
SOA 所解決的核心問題：
1. 系統集成：站在系統的角度，解決企業系統間的通訊問題，把原先散亂、無規劃的系統間的網狀結構，梳理成規整、可治理的系統間星形結構，這一步每每須要引入一些產品，好比ESB、以及技術規範、服務管理規範；
這一步解決的核心問題是【有序】
2. 系統的服務化：站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，經過服務的編排實現業務的快速再生，目的：把原先固有的業務功能轉變爲通用的業務服務，實現業務邏輯的快速複用；這一步解決的核心問題是【複用】
3. 業務的服務化：站在企業的角度，把企業職能抽象成可複用、可組裝的服務；把原先職能化的企業架構轉變爲服務化的企業架構，進一步提高企業的對外服務能力；「前面兩步都是從技術層面來解決系統調用、系統功能複用的問題」。第三步，則是以業務驅動把一個業務單元封裝成一項服務。
本文做者：張永清 來源出處：https://www.cnblogs.com/laoqing/p/13042432.html
4、微服務架構
微服務架構其實和SOA 架構相似,微服務是在SOA 上作的昇華，微服務架構強調的一個重點是「業務須要完全的組件化和服務化」，原有的單個業務系統會拆分爲多個能夠獨立開發、設計、運行的小應用。這些小應用之間經過服務完成交互和集成。
組件表示一個能夠獨立更換和升級的單元，就像PC 中的CPU、內存、顯卡、硬盤同樣，獨立且能夠更換升級而不影響其餘單元。若是咱們把PC 做爲組件以服務的方式構建，那麼這臺PC 只須要維護主板和一些必要的外部設備。CPU、內存、硬盤都是以組件方式提供服務，PC 須要調用CPU 作計算處理，只須要知道CPU 這個組件的地址便可。
SOA與微服務區別：
一、SOA注重重用，微服務注重重寫
SOA 的主要目的是爲了企業各個系統更加容易地融合在一塊兒。
微服務一般由重寫一個模塊開始。要把整個巨石型的應用重寫是有很大的風險的，也不必定必要。咱們向微服務遷移的時候一般從耦合度最低的模塊或對擴展性要求最高的模塊開始。
把它們一個一個剝離出來用敏捷地重寫，能夠嘗試最新的技術和語言和框架，而後 單獨佈署。它一般不依賴其餘服務。微服務中經常使用的 API Gateway 的模式主要目的也不是重用代碼。
而是減小客戶端和服務間的往來。API gateway 模式不等同與 Facade 模式，咱們可使用如 Future 之類的調用，甚至返回不完整數據。
二、SOA注重水平服務，微服務注重垂直服務
本文做者：張永清 來源出處：https://www.cnblogs.com/laoqing/p/13042432.html
SOA 設計喜歡給服務分層(如 Service Layers 模式)。咱們經常見到一個 Entity 服務層的設計，美其名曰 Data Access Layer。這種設計要求全部的服務都經過這個 Entity 服務層。來獲取數據。這種設計很是不靈活，好比每次數據層的改動均可能影響到全部業務層的服務。而每一個微服務一般有它本身獨立的 Data Store。咱們在拆分數據庫時能夠適當的作些去範式化，讓它不須要依賴其餘服務的數據。
微服務一般是直接面對用戶的，每一個微服務一般直接爲用戶提供某個功能。相似的功能可能針對手機有一個服務，針對機頂盒是另一個服務。在 SOA 設計模式中這種狀況一般會用到 Multi-ChannelEndpoint 的模式返回一個大而全的結果兼顧到全部的客戶端的需求。
三、SOA注重自上而下，微服務注重自下而上
SOA 架構在設計開始時會先定義好服務合同。它喜歡集中管理全部的服務，包括集中管理業務邏輯，數據，流程，Schema 等。它使用 Enterprise Inventory 和 Service Composition 等方法來集中管理服務。SOA 架構一般會預先把每一個模塊服務接口都定義好。模塊系統間的通信必須遵照這些接口，各服務是針對他們的調用者。
SOA 架構適用於 TO GAF 之類的架構方法論。
微服務則敏捷得多。只要用戶用獲得，就先把這個服務挖出來。而後針對性的，快速確認業務需求，快速開發迭代。
微服務與 SOA 有不少相同之處。二者都屬於典型的、包含鬆耦合分佈式組件的系統結構。在圍繞着服務的概念建立架構這一方面，微服務提供了一種更清晰、定義更良好的方式。微服務的原則與敏捷軟件開發思想是高度一致的，而它與 SOA 原則的演化的目標也是相同的，則減小傳統的企業服務總線開發的高複雜性。二者之間最關鍵的區別在於，微服務專一於以自治的方式產生價值。可是兩種架構背後的意圖是不一樣的：SOA 嘗試將應用集成，通常採用中央管理模式來確保各應用可以交互運做。微服務嘗試部署新功能，快速有效地擴展開發團隊。它着重於分散管理、代碼再利用與自動化執行。
5、架構設計圖
一、技術架構
從技術層面描述，主要是分層模型，例如持久層、數據層、邏輯層、應用層、表現層等，而後每層使用什麼技術框架，例如Spring、hibernate、ioc、MVC、成熟的類庫、中間件、WebService等，分別說明，要求這些技術可以將整個系統的主要實現歸納
二、系統架構
指的完整系統的組成架構，例如系統分紅幾個部分？服務平臺、管理門戶、終端門戶、ATM門戶、外部系統以及接口、支撐系統等，將這些系統進行合理的劃分。而後再進行功能分類細分，總之，將整個系統業務分解爲邏輯功能模塊，而且科學合理，就是系統架構
三、部署架構
指的是系統如何部署，包括應用的節點機器，網絡、交換機，防火牆等。好比採用什麼網絡，nginx 部署幾臺，vip如何轉發、APP應用部署多少個節點等。
四、數據架構
數據架構指導數據庫的設計. 不只僅要考慮開發中涉及到的數據庫，實體模型，也要考慮物理架構中數據存儲的設計。
五、代碼架構
子系統代碼架構主要爲開發人員提供切實可行的指導，若是代碼架構設計不足，就會形成影響全局的架構設計。好比公司內不一樣的開發團隊使用不一樣的技術棧或者組件，結果公司總體架構設計就會失控。
代碼架構主要定義：
①. 代碼單元:
配置設計框架、類庫。
②. 代碼單元組織：
編碼規範，編碼的慣例。項目模塊劃分頂層文件結構設計，好比mvc設計。依賴關係
未完待續，後續會補充大數據相關的架構