分布式SOA架構：
什么是SOA
SOA 全稱為 Service-Oriented Architecture，即面向服務的架構。它可以根據需求通過網絡對松散耦合的粗粒度應用組件(服務)進行分布式部署、組合和使用。
一個服務通常以獨立的形式存在於操作系統進程中。
站在功能的角度，把業務邏輯抽象成可復用、可組裝的服務，通過服務的編排實現業務的快速再生，
目的：把原先固有的業務功能轉變為通用的業務服務，實現業務邏輯的快速復用。
通過上面的描述可以發現 SOA 有如下幾個特點：分布式、可重用、擴展靈活、松耦合
SOA架構
當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求
優點：
抽取公共的功能為服務,提高開發效率
對不同的服務進行集群化部署解決系統壓力
基於ESB/DUBBO減少系統耦合
缺點：
抽取服務的粒度較大
服務提供方與調用方接口耦合度較高
微服務架構：
優點：
通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，小團隊的交付周期將縮短，運維成本也將大幅度下降
微服務遵循單一原則。微服務之間采用Restful等輕量協議傳輸。
缺點：
微服務過多，服務治理成本高，不利於系統維護。
分布式系統開發的技術成本高（容錯、分布式事務等）。
SOA與微服務的關系：
SOA（ Service Oriented Architecture ）“面向服務的架構”:他是一種設計方法，其中包含多個服務， 服務之間通過相互依賴最終提供一系列的功能。
一個服務 通常以獨立的形式存在與操作系統進程中。各個服務之間 通過網絡調用。
微服務架構其實和 SOA 架構類似,微服務是在 SOA 上做的升華，微服務架構強調的一個重點是“業務需要徹底的組件化和服務化”，
原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。
分布式中的遠程調用：
在微服務架構中，通常存在多個服務之間的遠程調用的需求。遠程調用通常包含兩個部分：序列化和通信協議。
常見的序列化協議包括json、xml、hession、protobuf、thrift、text、bytes等，目前主流的遠程調用技術有基於HTTP的RESTful接口以及基於TCP的RPC協議。
（1）RESTful接口：
REST，即Representational State Transfer的縮寫，如果一個架構符合REST原則，就稱它為RESTful架構。
資源（Resources）
所謂"資源"，就是網絡上的一個實體，或者說是網絡上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。
你可以用一個URI（統一資源定位符）指向它，
每種資源對應一個特定的URI。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨一無二的識別符。
REST的名稱"表現層狀態轉化"中，省略了主語。"表現層"其實指的是"資源"（Resources）的"表現層"。
表現層（Representation）
"資源"是一種信息實體，它可以有多種外在表現形式。我們把"資源"具體呈現出來的形式，叫做它的"表現層"（Representation）。
比如，文本可以用txt格式表現，也可以用HTML格式、XML格式、JSON格式表現，甚至可以采用二進制格式；
圖片可以用JPG格式表現，也可以用PNG格式表現。URI只代表資源的實體，不代表它的形式。
嚴格地說，有些網址最后的".html"后綴名是不必要的，因為這個后綴名表示格式，屬於"表現層"范疇，而URI應該只代表"資源"的位置。
狀態轉化（State Transfer）
訪問一個網站，就代表了客戶端和服務器的一個互動過程。在這個過程中，勢必涉及到數據和狀態的變化。
互聯網通信協議HTTP協議，是一個無狀態協議。這意味着，所有的狀態都保存在服務器端。
因此，如果客戶端想要操作服務器，必須通過某種手段，讓服務器端發生"狀態轉化"（State Transfer）。
客戶端用到的手段，只能是HTTP協議。具體來說，就是HTTP協議里面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。
它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。
綜合上面的解釋，我們總結一下什么是RESTful架構：
每一個URI代表一種資源；
客戶端和服務器之間，傳遞這種資源的某種表現層；
客戶端通過四個HTTP動詞，對服務器端資源進行操作，實現"表現層狀態轉化"。
（2）RPC協議
RPC（Remote Procedure Call ） 一種進程間通信方式。允許像調用本地服務一樣調用遠程服務。RPC框架的主要目標就是讓遠程服務調用更簡單、透明。
RPC框架負責屏蔽底層的傳輸方式（TCP或者UDP）、序列化方式（XML/JSON/二進制）和通信細節。
開發人員在使用的時候只需要了解誰在什么位置提供了什么樣的遠程服務接口即可，並不需要關心底層通信細節和調用過程。
（3）區別與聯系
1、HTTP相對更規范，更標准，更通用，無論哪種語言都支持http協議。如果你是對外開放API，例如開放平台，外部的編程語言多種多樣，
你無法拒絕對每種語言的支持，現在開源中間件，基本最先支持的幾個協議都包含RESTful。
2、 RPC 框架作為架構微服務化的基礎組件，它能大大降低架構微服務化的成本，提高調用方與服務提供方的研發效率，
屏蔽跨進程調用函數（服務）的各類復雜細節。讓調用方感覺就像調用本地函數一樣調用遠端函數、讓服務提供方感覺就像實現一個本地函數一樣來實現服務。
分布式中的CAP原理：
現如今，對於多數大型互聯網應用，分布式系統（distributed system）正變得越來越重要。分布式系統的最大難點，就是各個節點的狀態如何同步。
CAP 定理是這方面的基本定理，也是理解分布式系統的起點。
CAP理論由 Eric Brewer 在ACM研討會上提出，而后CAP被奉為分布式領域的重要理論。分布式系統的CAP理論，首先把分布式系統中的三個特性進行了如下歸納：
Consistency（一致性）：數據一致更新，所有數據的變化都是同步的
Availability（可用性）：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求（多節點）
Partition tolerance（分區容錯性）：某個節點的故障，並不影響整個系統的運行（可以將數據存到多個地方）
通過學習CAP理論，我們得知任何分布式系統只可同時滿足二點，沒法三者兼顧，
既然一個分布式系統無法同時滿足一致性、可用性、分區容錯性三個特點，所以我們就需要拋棄一樣：
對於分布式互聯網應用而言，必須保證P，所以要么滿足AP模型、要么滿足CP模型