菜鸟笔记
提升您的技术认知

系统间通信1:阻塞与非阻塞式通信b-ag真人游戏

接上篇:系统间通信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.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.1 esb

esb(企业服务总线)是soa的典型实现,各种esb软件它们的共同特点是:将各个(有访问权限的)系统所提供服务集中在一起(进行管理、控制、协调),请求方只需要访问esb软件,然后再由esb软件代其访问指定的服务,最后返回处理结果。esb的功能特点是代理

6.2 服务注册中心

服务注册中心,是soa的另一种实现方式,和esb最大的不同点是:“服务注册中心”主要提供各原子系统的服务注册、服务治理、服务隔离、权限控制。当客户端进行请求时,“服务治理”将告诉客户端到哪里去访问真实的服务,自己并不提供服务的转发。dubbo就是一个典型的服务治理框架。

网站地图