版權聲明：本文引用https://yinwj.blog.csdn.net/article/details/48274255

接上篇：系統間通信1：阻塞與非阻塞式通信A

4.3 NIO通信框架

目前流行的NIO框架非常的多。在論壇上、互聯網上大家討論和使用最多的有以下幾種：

• 原生JAVA NIO框架：
  JAVA NIO通信框架基于多路復用IO原理，我們將詳細講解它的工作原理。

• APACHE MINA 2：
  是一個網絡應用程序框架，用來幫助用戶簡單地開發高性能和高可擴展性的網絡應用程序。它提供了一個通過Java NIO在不同的傳輸例如TCP/IP和UDP/IP上抽象的事件驅動的異步API。

• NETTY 4/5：
  Netty是由JBOSS提供的一個java開源框架。Netty提供異步的、事件驅動的網絡應用程序框架和工具，用以快速開發高性能、高可靠性的網絡服務器和客戶端程序。我們將講解NETTY 4 的工作原理。另外說一句：MANA和NETTY的主要作者是同一人Trustin Lee。

• Grizzly：
  Grizzly是一種應用程序框架，專門解決編寫成千上萬用戶訪問服務器時候產生的各種問題。使用JAVA NIO作為基礎，并隱藏其編程的復雜性。

這個系列的博客文章中，我們將花費一些篇幅講解java 5.0以后提供的java原生NIO框架（IO復用模式）來深入實現原理，然后我們再以Netty 4.0.X框架為線路進行重點講解。主要是為了讓您理解Channel、Buffer、Selection（SelectableChannel、SelectionKey、Selecotor）在NIO思想中的重要地位。

5. 通信方式

我們都是通過聲帶發聲，通過口型和舌頭控制音調、音量。聲音傳到對方的耳朵里，經過對方的大腦處理，再通過對方發聲傳到我們的耳朵里，于是我們的大腦得到了答案。

5.1 直接使用單純HTTP請求

您對“簡潔”的理解是什么樣的呢？快速開發，快速部署、快速理解，還是調用速度快，并發支持高呢？無論您怎樣理解“簡潔”，有一個是事實您是無法否定的，很大一部分公司都是用單純Http協議（使用標準WEB容器）+JSON信息格式的方式進行系統間通信。這種做法有幾個好處：

• 上手快：對于做WEB系統有較豐富積累的公司，并不需要思考“這個接口是給終端用戶的還是給另外一個系統通信的”，依葫蘆畫瓢就可以把提供給系統間接口的。

• 實現快：就像上面提到的一樣，在不考慮實現細節的情況下，任務開發過WEB系統開發人員都可以接手這個工作，并且在分鐘級別的時間內，就可以把接口功能實現出來。

• 速度也不算慢：雖然很少有人去比較RMI和HTTP的速度，或者Dubbo和HTTP調用的速度，但是從各種介紹來看后者的速度雖然沒有前者快，但是后者的速度還是可接受的。而且并發問題完全可以交給其他方案來解決（Nginx或者Haproxy，這個相關技術的講述在“負載均衡層”技術方案系列博文中《負載均衡層技術》）

5.2 直接使用HTTP調用的問題

但是直接使用HTTP，還是有一些問題：

• 由于其基于HTTP和為客戶端交互設計的WEB容器，其速度畢竟會是一個問題。HTTP的通信過程如下：
  
• 雖然HTTP協議中有很多方式可以優化訪問速度。例如使用keep-alive保持Http Connection的連接復用，使用gzip壓縮Body中的傳輸數據。但是受WEB服務器選擇、HTTP通信特點的影響，速度就會受到影響。
• 不好管理：這里所說的管理，并不是幾百個接口不能使用word文檔進行管理；而是說，當系統持續增大后，接口的復雜性將會成幾何級遞增。終端客戶端一次請求的處理不再由一個系統進行處理，而是要使用多個系統進行關聯計算才能得到結果。那，這時候怎么辦？當然如果您非要說，各系統怎么交互調用交給終端客戶機處理，好吧，我竟無言以對。。。
  
• 實際上這種調用單純HTTP + JSON信息格式的實現速度，真不是最快的。。。可能是因為有的團隊并沒有使用過其他的調用技術（在生產環境下），就沒法比較。個人認為：沒有最好的技術，只有最合適的技術，所以簡單的業務系統間使用單純的HTTP + JSON信息格式的技術，并沒有什么不可以。

5.2 RPC

本來在規劃這個系列的文章指出，我沒有計劃要專門寫RPC調用方式的，因為RPC的實現錯中復雜，根本不可能幾篇文章就說清楚。例如：在能夠找到的文章中，有的人把protocol buffer歸結為一種RPC的實現；而更多的文章會直接將RPC和服務治理聯系起來；還有文章將RPC框架作為一種SOA（面向服務的架構）的實現進行講述。
實際上RPC技術之所以難以和其他技術/規范 區分開，除了上面描述的表面現象外，更重要的原因是，目前實現了RPC框架的軟件，往往都是把各種相互交錯的技術規范/定義進行整合實現，又或者借鑒了RPC中的部分思想。例如，阿里的RPC框架Dubbo，除了遵循RPC規則以外，重要的功能還放在了服務治理的實現；

5.3 MQ

消息隊列又是另外一種系統間通信方式的實現。消息隊列的規范目前有很多種，針對的場景和實現的性能各不相同。這個系列的博文我們將花一定的篇幅介紹JMS、AMQP兩種消息隊列協議和實現（特別是AMQP協議），然后介紹Kafka消息隊列和使用場景，最后前瞻一下目前號稱最快的消息隊列ZMQ。

6. 整合手段——ESB和服務治理

6.1 ESB

ESB（企業服務總線）是SOA的典型實現，各種ESB軟件它們的共同特點是：將各個（有訪問權限的）系統所提供服務集中在一起（進行管理、控制、協調），請求方只需要訪問ESB軟件，然后再由ESB軟件代其訪問指定的服務，最后返回處理結果。ESB的功能特點是代理。

6.2 服務注冊中心

服務注冊中心，是SOA的另一種實現方式，和ESB最大的不同點是：“服務注冊中心”主要提供各原子系統的服務注冊、服務治理、服務隔離、權限控制。當客戶端進行請求時，“服務治理”將告訴客戶端到哪里去訪問真實的服務，自己并不提供服務的轉發。Dubbo就是一個典型的服務治理框架。

總結

以上是生活随笔為你收集整理的系统间通信1：阻塞与非阻塞式通信B的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。