《分布式Java应用之基础与实践》读书笔记一

分布式Java应用的体系结构知识简单分为:

  • 网络通信:包括协议和IO
  • 消息方式的系统间通信:包括基于Java包、基于开源框架、性能角度
  • 远程调用方式的系统间通信:包括基于Java包、基于开源框架、性能角度

大型应用拆分为多个子系统来实现,这些子系统可能部署在同一台机器,或者不同机器的多个不同JVM中,每个子系统对应一个JVM。但这些子系统又不是完全独立的,要相互通信来共同实现业务功能,对于此类Java引用,我们称之为分布式Java引用。通常有两种典型的方法来实现。

  • 基于信息方式实现系统间的通信,通常基于网络协议来实现。
  • 基于远程调用方式实现系统间的通信,通常基于RMI和WebService

消息方式

基于Java自身技术

基于Java自身包实现消息方式的系统间通信的方式有:

  • TCP/IP+BIO
  • TCP/IP+NIO
  • UDP/IP+BIO
  • UDP/IP+NIO
TCP/IP+BIO

在Java中可基于Socket、ServerSocket来实现TCP/IP+BIO的系统间通信。Socket用于实现建立连接及网络IO的操作,ServerSocket用于实现服务器端端口的监听及Socket对象的获取。这种简单的通信模式,运用到实际的系统中,通常需要面对的是客户端同时要发送多个请求到服务器端,服务器端则同时要接受多个连接发送的请求。   为了解决客户端同时要发送多个请求到服务器端的需求,解决办法是:

  • 生成多个Socket,问题是消耗客户端过多的本地资源,消耗服务器端过多的连接数,连接耗时较长导致的系统性能下降。解决方法是采用连接池的方式来维护Socket。连接池的问题是Socket数量有限导致的竞争和等待和如何合理控制等待响应的超时时间。

为了满足服务端能同时接受多个连接发送的请求,解决办法是:

  • 在accept获取Socket后,将此Socket方式放入一个线程中处理,称为一连接一线程。缺点是无论连接上是否有真实的请求,都要耗费一个线程。为防止过多线程导致的服务器端资源耗尽,必须限制创建线程的数量,BIO方式下服务器端所能支撑的连接数有限。
TCP/IP+NIO

在Java中可基于java.nio.channels中的Channel和Selector的相关类来实现TCP/IP+NIO方式的系统间通信。SocketChannel用于建立连接、监听事件及操作读写,ServerSocketChannel用于监听端口及监听连接事件,程序通过Selector来获取是否有要处理的事件。NIO是典型的Reactor模式的实现,通过注册感兴趣的事件及扫描是否有感兴趣的事件发生,从而做相应的动作。这种简单的通信模式,运用到实际的系统中,通常需要面对的是客户端同时要发送多个请求到服务器端,服务器端则同时要接受多个连接发送的请求。

为了解决客户端同时要发送多个请求到服务器端的需求,解决办法是:

  • 采用与TCP/IP+BIO类似的方式,使用多个SocketChannel。但是NIO方式可做到不阻塞,如果服务器端返回的相应能够带上请求标识,客户端则可采用连接复用的方式。对于连接不复用的情况,可基于Socket.setSoTimeout的方式来控制同步请求的超时;对于连接复用的情况,同步请求的超时可基于BlockingQueue、对象的wait/notify机制或Future机制来实现。

为了解决服务端接受多个连接请求的需求,解决办法是:

  • 由一个线程来监听连接的事件,另一个或多个线程来监听网络流读写的时间。当有实际的网络流读写事件发生后,再放入线程池中处理。这种方式称为一请求一线程,好处是可接受很多的连接,这些连接只在有真实的请求时才会创建线程来处理。非常适用于服务端需要支持大量的连接数,但这些连接同时发送的请求不会太多。

对于高访问量的系统而言,TCP/IP+NIO方式结合一定的改造在客户端能够带来更高的性能,在服务端能支持更高的连接数。

UDP/IP+BIO

Java对UDP/IP方式的网络数据传输同样采用Socket机制,只是没有建立连接的要求,同时无法双向通信,除非两端都是UDP Server。在Java中可基于DatagramSocket和DatagramPacket来实现UDP/IP+BIO方式的系统间通信,DatagramSocket负责监听端口及读写数据。DatagramPacket作为数据流对象进行传输。

UDP/IP通信方式的两端不建立连接,不会有TCP/IP通信连接竞争的问题,只是最终读写流的动作是同步的。客户端同时发送多个消息的请求使用多个DatagramPacket即可。服务端同时接收多个请求的需求,采用没接收到一个packet就放入一个线程中进行处理的方式来实现。

UDP/IP+NIO

在Java中通过DatagramChannel和ByteBuffer来实现UDP/IP+NIO方式的系统间通信,DatagramChannel负责监听端口及进行读写,ByteBuffer则用于数据流传输。

对于UDP/IP方式,NIO带来的好处是只在有流要读取或可写入流时才做相应的IO操作,而不用像BIO方式直接阻塞当前线程。

多播的实现

以上都是基于Java包的一对一的系统间通信方式,实际场景中,可能需要将消息发送给多台机器,针对此场景有两种解决办法:

  • 为每个目标机器建立一个连接,缺点是对消息发送端造成很大的网络流量压力
  • 利用基于UDP/IP扩展出来的多播协议,在Java中可基于MulticastSocket和DatagramPakcet来实现多播网络通信。在多播通信中,接收数据端加入多播组来进行数据的接收,发送数据也要求加入多播组进行发送,多播的目标地址具有指定的地址范围,在224.0.0.0和239.255.255.255之间。

在Java应用中,多播通常用于多台机器的状态的同步。

基于开源框架

Mina是Apache的顶级项目,基于Java NIO构建,同时支持TCP/IP和UDP/IP两种协议,Mina对外屏蔽了Java NIO使用的复杂性,并在性能上做了不少优化。

在使用Mina时,关键的类为IoConnector、IoAcceptor、IoHandler及IoSession,Mina采用Filter Chain的方式封装消息发送和接收的流程,在这个Filter Chain的过程中可进行消息的处理、消息的发送和接收等。

  • IoConnector 负责配置客户端的消息处理器、IO事件处理线程池、消息发送/接收的Filter Chain 等。
  • IoAcceptor 负责配置服务器端的IO事件处理线程池、消息发送/接收的Filter Chain等。
  • IoHandler 作为Mina和应用的接口,当发生了连接事件、IO事件或异常事件时,Mina都会通知应用所实现的IoHandler。
  • IoSession 类似于SocketChannel的封装,不过Mina对连接做了进一步的抽象,因此可进行更多连接的控制及流信息的输出。

除了Mina之外,现在JBoss Netty也是现在一个广受关注的Java通信框架,据评测JBoss Netty的性能浩宇Mina。

小结

使用Java包来实现基于消息方式的系统间通信还是比较麻烦。为了让开发人员更加专注于对数据进行业务处理,而不用过多关注纯技术细节,开源业界诞生了很多优秀的基于以上各种协议的系统间通信的框架,比如Mina。

时间: 2024-10-07 02:12:39

《分布式Java应用之基础与实践》读书笔记一的相关文章

构建之法——读书笔记(8)

<构建之法>第十&十一章 主要讲述了在软件设计前期的需求分析问题上的方法和实践经验,分为"典型用户和场景"以及"软件设计与实现". 其中第十章大部分内容包含: 用户的分类(典型用户可以包括以下内容: 1. 名字(越自然越好) 2. 年龄(不同年龄和收入的用户有不同的需求) 3. 收入 4. 代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要 5. 使用这个软件的典型场景 6. 使用本软件/服务的

构建之法读书笔记之五

今天我学习了构建之法的第五章——典型用户与典型场景.我们都知道,软件开发最终都是服务于用户,所以用户主导着我们的开发方向.软件开发离不开用户,所以能够搞清楚用户隐藏的要求也是软件开发过程中的的一个重要的课题,这就涉及到了典型用户. 典型用户,顾名思义,能够代表大部分用户的用户.很多时候,不考虑典型用户的话,软件的开发不可能把所有的方面都做的尽善尽美,开发人员不可能把所有的方面都能考虑到.这时候,典型用户就站了出来.但同时,典型用户也有两面性——受欢迎的与不受欢迎的.那些能够按照开发者期望进行操作

软件 = 程序 + 软件工程(构建之法读书笔记一)

在我正式开始阅读这本书之前,我对于软件工程这个词汇的概念还是模糊的,认为它只是停留在是一门学科,一个专业,或者是一大堆硬生生的理论知识,然而当我读完构建之法这本书的推荐序和第一,第二版前言开始,我就深刻意识到我之前对于软件工程的肤浅认识是多么错误. 我看书一般喜欢从从书的封面开始看起,或许这也是大多数人看书的习惯,·在本书的封面素描着一副鲁班锁,刚开始让人感觉有点奇怪,明明是一本讲软件工程的书,为什么要用鲁班锁做为封面图案呢?原来玄机深藏于鲁班锁的内部,这鲁班锁从外部看,是严丝合缝的十字立方体,

构建之法读书笔记

周末我抽空将<构建之法>第一章读完,感觉对软件工程又有了新的认识. <构建之法>开篇便写到:软件=程序+软件工程.我认为这是对软件的一种及其精炼的解释.程序即是指一行行代码,软件工程则包含了各种软件开发活动,包括构建管理.源代码管理.软件设计.软件测试.项目管理等等,是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程. 作为一名机械专业的学生,我认为软件设计是我们必须掌握的一门技能.机械行业,除了大家普遍所能看到的机械结构,每一个设备还包含有控制.软件等部分,一个

构建之法读书笔记_1

本周我快速地阅读了一遍<构建之法>,提出以下几个问题: 1在满足客户需要的同时,我们有些什么原则需要坚持. 2软件测试方法有什么?做软件测试只是找BUG吗? 3什么是敏捷流程?怎样去根据自己的项目选择开发方法? 4第三章中有提及考级的相关内容,但是在社会工作中,实践经验比证书更重要,我们应该如何平衡理论知识与实践之间的关系? 5当今市场对软件有哪些主要需求,安全软件并不能填满所有的漏洞,它的发展前景真的有那么好吗?

构建之法读书笔记之三

在学习了构建之法第四章,第五章之后,写一下我的感想. 代码规范一直是我们在学习过程中一个老生常谈的话题.专业技能过硬与否只是一方面,代码规范同样也是一个举足轻重的方面.比如最开始的注释,在我们写一些很短的代码十几行,几十行代码的时候,如果不写注释,说白了,那么短的代码,谁都能找得到.但是,万一代码量上了三位数呢.几百行的代码,找那么一个错误,难度可是不小.再加点难度,四位数,五位数,甚至做项目的时候呢.没有注释,八成项目经理都不要你了. 代码规范有很多方面,处了注释,还有缩进,行宽,括号,分行,

构建之法读书笔记之二

由于近几周进行构建之法的学习很少,所以这周一下子看了三个周期的内容. 既然选择了软件工程专业,就决定了我们将来要朝着软件工程师的方向发展.那么,问题来了,如何成为一名合格的软件工程师,在成为一名软件工程师的过程中,我们又有那些需要注意和学习的地方呢. 软件工程师的成长道路上,首先对我们自己的专业技能有很高的要求.所以第一步,我们要丰富自己的专业技能,并奇瑞要很好的衡量自己的能力.这样一来,就有涉及到了衡量我们能力的标准.这里又有一个问题,对于这些衡量标准,我们不能抱着仅仅不被OUT的态度,不能只

构建之法读书笔记3

软件开发流程: 写了再改模式:适合只用一次的小程序 RUP统一流程:将不同类型的工作划分为规程和工作流. 老板驱动的流程:老板在整个流程中占据领导地位. 渐进交付的流程:现发布一个版本,然后根据反馈进行修改然后再发布,不断反复直到用户满意或无法进行下去时停止.MVP:最小可行产品,即先做出一个实现了关键功能的很小的软件供用户使用体验,然后根据用户反馈继续开发.MBP:最强最美产品,即等到产品做得完美了后再进行发布. TSP原则:优秀的模式和流程的共同点的总结. 瀑布模型以及瀑布模型的各种变形:适

构建之法——读书笔记(6)

第8章 需求分析 8.1 软件需求 寻找需求: 1. 获取和引导需求(Elicitation) 软件团队需要找到软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出对软件的需求. 2. 分析和定义需求(Analysis&Specification) 这是指对从各个方面获取的需求进行规整,定义需求的内涵,从各个角度将需求量化(需求实现的最后期限,实现需求大致所需的时间和资源成本,各个不同需求的优先级,需求带来的收益,等等). 3. 验证需求(Validation) 软件团队要跟利益相关者沟

构建之法读书笔记01

第一章讲述了学生与老师的关系,很多内容都是老师上课所涉及到的,那就是如何让我们学好软件工程,在很多时候我们都是有惰性的,需要老师给与压力,也就是老师说的要想让我们真的学会游泳,就要下水,同时老师还需要踹我们一脚,不仅是在学士或者在游泳的过程中,都要让我们感到压力,那样才能激发我们求生的本能,同时能够让我们创造奇迹. 软件工程融汇了很多技术,书中更是列出了十多种相关科目,在感觉到博大精深的同时,有深深的感觉学习这门的压力,看到了软件工程的目标,就是创造“足够好”的软件,而足够好也是给我们纠正了,不