服務器之間的通信
通常我們交互除了P2P等協議，大多數都是基於C/S架構的通信場景，比如FTP, HTTP, DNS等。但是再射一一些安全協議方案的時候通常包括多方服務器和用戶。此時應該如何通信那？比如傳遞命令和傳輸密鑰。
Socket
一般情況下比如我們設計一個後端服務，包括多個服務器：數據庫服務器，web服務器，文件服務器、緩存服務器等的通信，一般是通過socket來設計專門的通信協議，因爲比較高效。比如MySQL，MS SQL等也都是有知名的專用端口號。這個場景大多是在一個內網中，所以通信效率一般沒問題。
（1）大學畢業設計，我是採用socket編程來實現客戶端與服務器之間的通信，所以當需要服務器之間通信的時候，我也採用了socke的方法，只不過請求的服務器變成了“客戶端”。所以相當於各方既是C也是S。只不過主動發起的一方是C，被動監聽的一方是S。
（2）Socket通訊簡單的方法是發送方用1個固定連接發送(比如SMTP/POP3等)，或發送方每個請求數據包新建一個連接發送(比如PHP/Ruby連MySQL)。
Http
（2）服務器和服務器直接同樣可以用HTTP，特別現在最常用的RESTful風格的通信方式。這時通信的時候就不需要瀏覽器了，比如服務器A可以使用curl系列命令向服務器B發出HTTP請求，獲取數據，格式可以用通用的JSON或XML。也可以用java自帶的HttpURLConnection，或者Apache的HttpClient等Http客戶端來實現。
RMI
如果用socket的話，需要自己封裝協議來處理不同的通訊請求，但效率要高些。如果用rmi的話，實現要簡單，但效率可能要低些。RMI=socket +object 也比較底層。
RPC
RPC 的全稱是 Remote Procedure Call，是進程間通信的一種方式，常見的分佈式系統通信可以用http，socket或rpc來實現，但rpc相比於http性能更高，相比於純socket實現會更輕量更容易。目前比較火的微服務架構一般是基於rpc框架的，微服務是指開發一個單個小型的但有業務功能的服務，每個服務都有自己的處理和輕量通訊機制，可以部署在單個或多個服務器上。基於rpc的微服務架構優點如下:每個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
微服務是鬆耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的,單個服務方便擴展。一般來講RPC主要分爲四個部分，分別是序列化層、函數調用層、網絡傳輸層和服務器端處理框架，具體實現機制如下：
序列化層：序列化主要作用是將結構化對象轉爲字節流以便於通過網絡進行傳輸或寫入持久存儲，在RPC框架中，它主要用於將用戶請求中的參數或者應答轉化成字節流以便跨機器傳輸。常用的序列化方式有xml，json，hessian，pb等。
函數調用層：函數調用層主要功能是定位要調用的函數並執行該函數，可以採用Java反射機制與動態代理實現函數調用。
網絡傳輸層：網絡傳輸層描述了Client與Server之間消息傳輸的方式。
服務器端處理框架：服務器端處理框架可被抽象爲網絡I/O模型，它描述了客戶端與服務器端間信息交互方式，它的設計直接決定着服務器端的併發處理能力，常見的網絡I/O模型有阻塞式I/O、非阻塞式I/O、事件驅動I/O等，而Hadoop RPC採用了基於Reactor設計模式的事件驅動I/O模型。
提供一臺服務器作爲調用的中轉，業務調用者和提供者都連接該中心服務器，該中心服務器用於服務的具體調用。rpc主要解決的一個痛點在於服務調用的高度透明化。
透明化是指隱藏socket通信細節，比如http這種是應用層透明，但是rpc站的高度比應用層更高，是代碼級的透明。
rpc是站在比http更上層的調用，也就相當於多了一層封裝，僅此而已，下層可以依賴http、json、或者你自己定義的元數據協議，任何能清晰描述出“座標、服務類、服務名、調用參數”的whatever都可以。多了這層封裝使我們在調用的時候不必關注這些底層細節。而rpc這層封裝其實技術含量很低，反射加強制轉換罷了。
rpc試圖將遠程調用包裝成本地調用，但是網絡調用的情況比本地調用要複雜的多，並且網絡調用本身應該也是無狀態，冪等性的，和本地調用背離，隨便舉個例子，你在本地會自然而然的寫諸如i++，i--這種，但是在rpc上面不能這麼用，一旦網絡情況複雜i++可能會被調用多次導致結果就不正確。
當前的普遍場景是：對內rpc，對外rest。RPC 更適合集羣內部通訊。
所以在當前網絡環境下，並不值得去推廣和使用。
服務器集羣中的服務器之間的通信（當前未用到，轉載）
多用遠程過程調用協議RPC（Remote Procedure Call Protocol)。
發佈-訂閱，請求-應答模式
Thrift，具體可以利用JMS/CORBA/RMI,XMLRPC/SOAP等
消息隊列：簡單的可以用zeromq做，稍微複雜一點可以用rabbitmq/activemq/qpid等等各種成熟方案。
在做服務器集羣時，集羣中的服務器需要通信，比如Client1（簡稱C1）連接到Server1（簡稱S1），Client2連接到Server2，Client1需要向Client2發消息，S1並不知道C2已連接到S2。
A方案：採用組播（或廣播），S1在接收到C1消息後，發送廣播包查詢C2位於哪個Server上，這時S2向S1回覆，S1再將消息發送到S2，S2轉發給C2，但是udp是不可靠的，雖然Server都位於同一局域網內，如果消息丟了，那C2就接收不到C1的消息了。
B方案：增加一個路由服務器，所有Server都連接到路由服務器（tcp長連接），S1將消息轉發給路由服務器，路由服務器再廣播給所有Server，由各個Server自行判斷，但這樣程序複雜度就上升了，每個Server都會處理本來不屬於自己處理的消息，而且路由服務器會成爲瓶頸，消息數量大規模增加的話。
rabbitmq
MQ全稱爲Message Queue, 消息隊列（MQ）是一種應用程序對應用程序的通信方法。應用程序通過讀寫出入隊列的消息（針對應用程序的數據）來通信，而無需專用連接來鏈接它們。消息傳遞指的是程序之間通過在消息中發送數據進行通信，而不是通過直接調用彼此來通信，直接調用通常是用於諸如遠程過程調用的技術。排隊指的是應用程序通過 隊列來通信。隊列的使用除去了接收和發送應用程序同時執行的要求。其中較爲成熟的MQ產品有IBM WEBSPHERE MQ等等。
ActiveMQ
1、ActiveMQ是消息隊列技術，爲解決高併發問題而生！
2、ActiveMQ生產者消費者模型（生產者和消費者可以跨平臺、跨系統）有中間平臺
3、ActiveMQ支持兩種消息傳輸方式
1）Queue，隊列模式，生產者生產了一個消息，只能由一個消費者進行消費
2）Topic，發佈/訂閱模式，生產者生產了一個消息，可以由多個消費者進行消費
Qpid
AMQP是一種用於業務消息的開放網絡協議。他定義了一種允許雙方進行可靠業務消息傳遞的二進制線級協議。該協議的目標是成爲所有消息中間件之間進行互操作的標準協議。
消息隊列是一種進程間通信線程或同一進程的不同線程間的通信方式。
Qpid則是由Apache開發的一種消息隊列，實現了AMQP協議，並且支持多種語言與多種平臺。
zeromq
這是個類似於Socket的一系列接口，他跟Socket的區別是：普通的socket是端到端的（1:1的關係），而ZMQ卻是可以N：M 的關係，人們對BSD套接字的瞭解較多的是點對點的連接，點對點連接需要顯式地建立連接、銷燬連接、選擇協議（TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細節，讓你的網絡編程更爲簡單。ZMQ用於node與node間的通信，node可以是主機或者是進程。
引用官方的說法： “ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ的明確目標是“成爲標準網絡協議棧的一部分，之後進入Linux內核”。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的“傳統”BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網絡應用程序極爲簡單和有趣。”