分散式架構，微服務架構，rest風格，rpc協議
一、分散式&微服務
1、分散式：指導節點之間如何通訊
2、微服務：鼓勵按業務劃分模組。
3、微服務架構通過分散式架構來實現。
4、微服務中的各個模組有自己的程式碼，測試流程，上線流程等。
5、微服務通常需要配合自動化測試，部署，服務發現等。（否則成千上萬個服務，人工弄很麻煩。）
二、rest：
REST 不是一種協議,它是一種架構，大部分的REST的實現中使用了RPC的機制，大致與有三部分組成：
1、method：動詞（get,post之類的）
2、Host/post：URI(統一資源標識)、伺服器，埠
3、Path：名詞（路徑，伺服器裡面的某個東西）路徑的結尾是資源的形態(如text, html, image, pdf等)。
即、對host裡面的某個Path裡面的東西做一些get或post操作。
三、rpc:
1、RPC 即遠端過程呼叫, 很簡單的概念, 像呼叫本地服務(方法)一樣呼叫伺服器的服務(方法). 通常的實現有 XML-RPC,JSON-RPC , 通訊方式基本相同, 所不同的只是傳輸資料的格式.
2、通常的呼叫過程，把函式序列化，遠端收到後，再把函式反序列化，完成函式呼叫。
四、rest和rpc的區別
rpc:想對伺服器裡面的資源進行修改，首先需要了解伺服器中各個介面都是幹啥的，然後把相關引數傳給伺服器提供的介面，讓伺服器自己去執行修改。修改程式碼在服務端。所以RPC服務端邏輯更復雜些，伺服器會有很大的工作量，但分工明確，不容易造成失誤。可以基於tcp或http，如果基於tcp,將少一層協議。
REST風格:
五、例子
如果要對服務端資料庫裡面的一個數加1，減1：兩種不同的實現方式如下：
rpc中，服務端應該留兩個介面函式，分別對應加1，減1操作，函式裡面有引數，當客戶端需要進行修改時，先要弄明白那個做加1操作，哪個做減1操作，然後參入相應引數，讓服務端進行加1，減1操作後更改資料庫
rest風格中：服務端只要留一個介面函式就可以，作用是更改資料庫裡面的數（不管它是加了還是減了），然後客戶端有兩個函式，分別進行加操作和減操作，但客戶端操作完都提交給同一個服務端函式，然後更改資料庫。
