talent

t-io和netty的差异

2019-1-19 22:46:00 0 待实现

引言

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,也许你会感觉到前所未有的爽

TCP连接数:, IP数:
    发 送