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容器，其速度畢竟會是一個問題。在《標準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規則以外，重要的功能還放在了服務治理的實現；

幾位大神告訴我，如果不寫RPC，那麼這個系列的博文稱為“系統間通訊”就會變得有名無實或者文不對題了。所以，不管怎麼都必須寫。我大致的寫作思路是：首先講解RPC的概念、發展情況、工作原理。然後以自己實際工作中用到的RPC實現，進行使用的講解。除了講解使用，我們還會講解幾款HTTP-RPC、非HTTP-RPC的效能比較。當然，要寫RPC就註定了這個系列中的一些觀點，會被推到風口浪尖進行批判，到時候各位隨意吐槽就是了。在這個系列的博文中，我們將重點講解 特殊的RPC服務——JAVA RMI、阿里的RPC框架Dubbo（服務治理也會一起講解）、Apache Thift。

5-3、MQ

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

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

6-1、ESB

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

這個系列的博文，我們將花比較大的篇幅，講解Apache Camel的原理和使用，從而間接講解ESB中的若干重要概念（服務順序編排/定義，服務實現隔離、多協議支撐、協議翻譯、轉發代理、事務控制等）。如果有多出來的富裕時間，我們將講解一個基於Apache Camel的真實工程。

目前市面上的共享/商用的ESB軟體還有很多，例如JBossESB、普元EOS、還有IBM和ORACLE的ESB產品。不過還是那句話，理解原理和技術特點才是最關鍵的。

6-2、服務註冊中心

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

6-3、自行實現分散式呼叫服務

這個系列的博文，我們將基於zookeeper實現一個註冊和管理中心，當然是一個簡單的，只是為了說明服務註冊中心的工作方式。

7、後文介紹

下篇文章我們就從“NIO、BIO通訊框架”開始介紹了。