架构设计:系统间通信(2)——概述从“聊天”开始下篇

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-3、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 Thrift。

5-4、MQ

消息队列又是另外一种系统间通信方式的实现。消息队列的规范目前又N多种,针对的场景和实现的性能各不相同。这个系列的博文我们将花一定的篇幅介绍JMS(即Java消息服务 Java Message Service,应用程序接口,是一个Java平台中关于面向消息中间件的API),AMQP(Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议)两种消息队列协议和实现(特别是AMQP协议),然后介绍Kafaka消息队列和使用场景,最后前瞻一下目前号称最快的消息队列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通信框架”开始介绍了。

此处作者回答一个提问者有关Http和RPC有什么本质不同吗?或者我这么问,为什么一个并发量很大的系统,同样的数据接口,用dubbo可以实现很大的并发,http就不可以呢?这个一直有些困惑,期望给与解答。笔者在这觉得原文作者回答的很好,就摘抄下。

答:实际上HTTP和RPC是两个不同层面的概念。HTTP协议属于网络协议,工作在7层网络协议的应用层,在我的《标准Web系统的架构分层》(http://blog.csdn.net/yinwenjie/article/details/46480485)这篇文章中详细提到了HTTP协议一次请求的工作过程。而RPC并不是一个网络协议,解决的不是数据如何通过网络从一端传输到另一端的问题,RPC解决的是“两个业务系统如何进行调用”(是通过HTTP实现还是通过TCP实现,甚至UDP实现只是RPC关注的某一个点而已)。所以更科学的描述应该是:基于HTTP网络协议,实现的RPC协议;又或者“基于TCP网络协议,实现的RPC协议”。以上是其一。其二,HTTP为什么不能实现高并发呢?如果HTTP不能实现高并发,那么您在双11,通过浏览器能够流畅的访问JD、TaoBao、聚美的网页,又该如何解释呢?高并发并不是依靠某一种网络协议实现的,而是由系统的顶层结构决定的,您当然可以在您的顶层架构设计中使用HTTP。那么,您提的问题我是否可以这么理解,实际上您是想问:“为什么基于TCP实现的RPC协议,要比基于HTTP实现的RPC协议,在高并发环境下更有优势?”如果您想问的我呢提我理解对了的话,那么以下就是答案。HTTP工作在7层网络协议的最顶层,也就是应用层,它完成一次请求响应的过程是:传输层TCP完成三次握手(握手过程请参考各种网络资料),然后才开始传输工作在应用层的HTTP数据。当然应用层的HTTP还要经过两次传输才能将HTTP数据传输完毕,接下来再接收两次对方的数据,才完成一个完整的HTTP通讯过程。如果是基于TCP协议的RPC实现,就不会走这个过程。另外Dubbo是服务治理框架,dubbo是RPC协议。

摘自:https://blog.csdn.net/yinwenjie/article/details/48344989

原文地址:https://www.cnblogs.com/Lee_xy_z/p/10477826.html