架構設計：系統間通訊（2）——概述從「聊天」開始下篇

4-三、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-一、直接使用單純HTTP請求

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

• 上手快：對於作WEB系統有較豐富積累的公司，並不須要思考「這個接口是給終端用戶的仍是給另一個系統通訊的」，依葫蘆畫瓢就能夠把提供給系統間接口的。

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

• 速度也不算慢：雖然不多有人去比較RMI和HTTP的速度，或者Dubbo和HTTP調用的速度，可是從各類介紹來看後者的速度雖然沒有前 者快，可是後者的速度仍是可接受的。並且併發問題徹底能夠交給其餘方案來解決（Nginx或者Haproxy，這個相關技術的講述在「負載均衡層」技術方 案系列博文中《負載均衡層技術》）

5-二、直接使用HTTP調用的問題

可是直接使用HTTP，仍是有一些問題：

• 因爲其基於HTTP和爲客戶端交互設計的WEB容器，其速度畢竟會是一個問題。在《標準Web系統的架構分層》這篇文章中，我已經詳細講訴了HTTP的通訊過程。

• 雖然HTTP協議中有不少方式能夠優化訪問速度。例如使用keep-alive保持Http Connection的鏈接複用，使用gzip壓縮Body中的傳輸數據。可是受WEB服務器選擇、HTTP通訊特色的影響，速度就會受到影響。

• 很差管理：這裏所說的管理，並非幾百個接口不能使用word文檔進行管理；而是說，當系統持續增大後，接口的複雜性將會成幾何級遞增。終 端客戶端一次請求的處理再也不由一個系統進行處理，而是要使用多個系統進行關聯計算才能獲得結果。那，這時候怎麼辦？固然若是您非要說，各系統怎麼交互調用 交給終端客戶機處理，好吧，我竟無言以對。。。
  

• 實際上這種調用單純HTTP + JSON信息格式的實現速度，真不是最快的。。。多是由於有的團隊並無使用過其餘的調用技術（在生產環境下），就無法比較。我的認爲：沒有最好的技術，只有最合適的技術，因此簡單的業務系統間使用單純的HTTP + JSON信息格式的技術，並無什麼不能夠。

5-二、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-三、MQ

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

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

6-一、ESB

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

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

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

6-二、服務註冊中心

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

6-三、自行實現分佈式調用服務

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