Netty in Action (十一) 第四章 第四部分 传输服务使用案例

4.4 Transport use cases


我们已经详细地讨论了所有的传输服务,让我们将这些服务的一些特殊因素考虑进来去为一个具体的应用去选择一个正确的协议,我们之前说过,并不是所有的传输方式应用于所有的核心协议,有些协议限制了你的选择,表4.4向你们展示了截止到当前发布的时间,传输方式与协议直接的支持关系

Netty in Action (十一) 第四章 第四部分 传输服务使用案例_第1张图片

Netty in Action (十一) 第四章 第四部分 传输服务使用案例_第2张图片

尽管只有SCTP协议需要一些具体的配置,但是一些其他的传输服务需要它们自己特定的配置选项要考虑,而且,如果你想支持更高的并发的连接,服务器端可能需要为每一个不同的客户端配置一些不同的参数


以下的一些使用案例可能是你经常使用的:

完全非阻塞库:如果你不想在你的代码中有阻塞调用,或者你想完全限制阻塞调用,那么如果运行在Linux的环境的时候,使用NIO或者epoll会是一个很不错的主意,因为NIO和epoll虽然更加趋向于用于处理高并发连接的场景,但是在较小数量的连接场景下,它们依旧运行的很好,特别是在多个链接中使用同一个线程去管理


阻塞代码库:我们之前说明过,如果你的代码库严重依赖于阻塞的I/O,那么你的应用应该有一个相应的设计,如果你想把你的阻塞操作直接转化成Netty的NIO传输的时候,在且你不是用重写原有代码去完成转化的功能,你可能会遇到一些问题,例如你可以考虑一种迁移场景,你的应用一开始使用OIO,然后迁移到NIO,你需要重新修改你的代码


在同一个JVM上通信,在同一个JVM上通信且不需要通过网络暴露你的服务的场景下,使用本地传输会是一个很棒的决定,这样可以在使用的你代码的基础上,消除所有的网络传输操作上的开销,如果你在以后的时间里想将你的服务暴露出去,你可以将其转化成NIO或者OIO


测试你的ChannelHandler实现,如果你想要为你的channelHandler写一个测试单元的话,你可以考虑使用嵌入式的传输方式,这个方式可以在不需要创造很多mock对象的基础上很轻易地测试你的代码,你可以测试再所有的事件流上的常用的API,且保证你的channelHandler在真实的传输服务上运行正确,在第九章,你会学到更多关于测试channelHandler的知识


表4.5向我们总结了我们刚才谈论的内容:

Netty in Action (十一) 第四章 第四部分 传输服务使用案例_第3张图片



4.5 Summary

在这个章节中,我们学些了传输服务,他们的实现方式和使用方式,还学习了Netty是如何包装这些传输服务给开发者的


我们以Netty的视角去了解了这些协议,并且解释了其中的一些原因,我们也讲解了使用这些传输服务的一些最低的要求,因为并不是所有的传输方式都同一个JDK杜能协作的很好,并且有些传输方式只能在一些特定的操作系统上才能使用,最后我们讨论了在传输服务如何匹配一些特定的使用案例


下一节,我们将分析ByteBuf和ByteBufHolder,Netty的数据容器,我们将向你展示如何使用它们,且如何获取最高的使用性能

你可能感兴趣的:(Netty in Action (十一) 第四章 第四部分 传输服务使用案例)