架构设计：系统间通讯（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实现一个注册和管理中心，固然是一个简单的，只是为了说明服务注册中心的工做方式。