0

聊聊t-io和netty的差异

 2 years ago
source link: https://segmentfault.com/a/1190000040768062
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

聊聊t-io和netty的差异

发布于 11 分钟前

引言
t-io和netty的差异,这是个被大量问及的问题,在此,作为t-io作者,列一些差异化的东西
t-io的最大优势
API设计易懂,尽量避免引入自创概念——最大限度降低学习成本
接管了大量业务资源的绑定与自动解绑,开发人员只需要无脑地调用API即可完成绑定与解绑功能,这个处理如果丢给业务开发人员是极其复杂易错的:

多线程环境下的集合管理都是要同步安全的,同步的设计既要安全又要高效
一是容易忘记释放资源从而导致OOM,二是容易忘记加锁或是加了死锁从而导 致系统假死
其它同类框架为何以各种理由逃避实现这些功能?
    和业务挂钩的都不好抽象
    会消耗框架性能
    复杂易错

内置了丰富的易用的API,开发人员一个方法就能搞定很多业务事情
提供了生产级别的showcase示范工程

有经验的开发人员稍事修改即可用在生产环境
没经验的开发人员可以当作入门的示范代码

文档集中在官网,用户不需要到处学习无用的、错误的文档——进一步降低学习成本和试错成本
netty的最大优势
大量公有协议的实现
大量基于netty的高层框架
其它对比
netty有大量公有协议的实现,t-io官方目前提供的仅有http和websocket
netty用到了零拷贝,这一点t-io在均衡再三之后,放弃了零拷贝,原因如下:
零拷贝只是改善性能的手段(或叫算法),对用户而言,框架采用什么算法并不重要,重要的是最终的目的是否达成——netty用零拷贝来改善性能,t-io自创同步安全线程池来改善性能,都是手段,殊途同归。

零拷贝在减少拷贝过程的同时,也消耗了计算机其它资源
堆外资源的管理势必增加t-io代码的复杂度,使t-io用户难以在源代码层驾驭t-io
部分同类框架引入堆外资源管理后,在某些场景的确是提升了性能,但这个过程也增加了很多严重BUG
t-io的性能已经足够好,把精力花在服务业务上,而不是性能PK场上

t-io自创了同步线程池,正是有了这个,t-io内部调度线程时就显得尤为简单,与netty的零拷贝一样,这也是改善性能与简化编程的手段,而不是最终目的。
t-io内置了业务数据管理能力,这是个非常重要的能力,网络编程数据绑定和释放是件极其考验开发人员水平的功能,哪怕是经验丰富的资深开发工程师也极容易死锁和OOM,甚至因此导致整个项目的失败。

举例一:你做im,你要做群组与群员关系映射吧?在t-io中,您只需要Tio.bindGroup()即可完成tcp连接和这个群组关系的绑定
举例二:点对点消息,你要针对用户id发消息吧?在t-io中,您只需要Tio.bindUser()即可完成tcp连接和user的关系绑定
通过Tio.bindXxx()绑定的业务资源,不用担心TCP连接断开后资源释放不掉,t-io拥有严格的算法保证这些资源得到快速有序地释放(不得不提醒:释放资源涉及到多线程操作,极易出错)!

netty有大量书籍可供查阅;t-io提供了拥有即战力的showcase工程( 付费文档用户可下载最新版 ),用户并不需要太多时间即可完成可用于生产项目的网络编程脚手架
t-io和netty的编程模型和API差异极大

t-io的API设计更多的是让工程师用起来舒服,所以特意增加了一个Tio.java,专门放置常用的API,这样用户找起来就非常方便,不用满大街找方法调用
netty的部分API是把设计模式暴露出来了,让内行人一看就知道这是个什么设计模式做的

在性能测试上的差异

在TFB平台上,netty的性能远超t-io,当然t-io的性能排名依然十分靠前,排在t-io后面的大有人在(t-io现在的性能比刚出来时的t-io差了很多,因为业务数据管理能力、阻塞发送能力、同步发送能力、流量监控与回调,是比较消耗性能的),请参考:TFB性能PK平台
带上业务进行PK时,t-io性能经常优于netty,这其中的原因大概就是:用netty需要自己写代码完成业务数据的管理、流量监控等工作,而这些工作拖了裸netty的后腿,而这些工作已经被t-io内置了,所以给t-io带来的性能损耗就很有限,请参考 netty和t-io对比测试结果

t-io提供了极其便捷的阻塞发送、同步发送,这些能力在netty中貌似没有,需要用户写较多的代码才能实现

阻塞发送:消息发送到对方后,才往下执行代码
同步发送:对方收到消息,并回了同样的synSeq消息,才往下执行代码

易学程度:从市场反馈来看,t-io设计的概念似乎更容易被工程师们所理解与接受,2014年老板想让我用netty,所以简单地看过《netty权威指南》,这本书是我放弃netty的最后一根稻草,真的看不太懂,提供的示例我很难将其用在生产项目中(真实感受,当然也许是我太菜,我另一个非常优秀且年轻的同事也看过这本书,同样表示云里雾里)
不少用户在抉择时,觉得t-io文档没有netty多,转而投netty,实际上,一个好框架,并不需要太多的文档,t-io在刚出来时,只有几个showcase工程,第一批t-io用户用这些showcase就完成了自己的项目,并且口碑迅速散开。现在t-io官方已经提供了相对完整的文档,再配上含金量十足的showcase工程,使用t-io已经很容易了
如果曾经使用过netty或mina,再来使用t-io,也许你会感觉到前所未有的爽!
具体请参考: https://www.tiocloud.com/doc/...


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK