直播精彩回顾+开奖当Netty大咖遇到ServiceComb首席committer 唇枪舌战为哪般？

Posted 2021-04-30 微服务蜂巢

 

11月29日晚，华为云微服务邀请《Netty进阶之路》作者，和Apache ServiceComb首席committer在云视界直播间为我们讲述Netty和Vert.x在Apache顶级项目ServiceComb中的实践与应用

温馨提示：查看抽奖结果请拉到最底部哦↓↓

话述直播

两位老师详细的为我们剖析了Netty的网络通信线程模型、ApacheServiceComb的同步和异步实现机制、以及在RPC调用中使用HTTP/2带来的各种优势，希望通过本次技术对话，使大家对Netty在ApacheServiceComb微服务框架中的应用和实践有更直观的了解。

在本次直播过程中，我们了解到Netty是个明星网络通信框架，ApacheServiceComb基于Netty和vert.x构建了一套高性能、低时延，同时支持同步和原生Reactive异步的微服务框架，目前已经在华为公司内外得到了非常广泛的应用。大家感兴趣的可以使用华为云微服务云应用平台了解体验下。

提问互动

在直播当晚，两位老师为线上的小伙伴们答疑解惑、指点迷津，并分享如何从技术小白到技术专家的进阶之路。同时，微服务还为五名提出问题并被选中的同学赠送了老师新作《Netty进阶之路》。

由于互动时间有限，部分问题我们在直播之后整理好特邀老师为大家一 一解答，快来看看有没有你提出的问题！

Q1：Netty和Mina有哪些区别？公司的老项目是基于Mina构建的，有必要迁移到Netty吗？

答复：

1）两者相同点：

都是一个高性能的NIO通信框架，历史上两者有一些渊源

都提供了编解解码扩展机制和协议定制能力，可以方便的构建各种协议栈。

2）两者差异：

功能差异，相比较而言，Netty的功能更丰富，提供了HTTP/2、MQTT，支持OpenSSL等

社区活跃度差异，Netty目前应用的范围、版本发布速度等更胜一筹。

3）学习成本：Mina的API更加简洁和清晰，源码学习和维护成本更低一些，Netty的整个架构和代码更复杂一些，学习成本相对较高。

如果公司其它一些项目中使用到了Netty，或者需要使用HTTP/2等Netty独有的新特性，可以考虑切换到Netty；如果是遗留项目，功能上没太多新需求，没有重构的必要性，则不建议切换。

Q2：Netty的高性能体现在哪些方面？

答复：请参考2014年我在infoQ发表的文章《Netty系列之Netty高性能之道》：

https://www.infoq.cn/article/netty-high-performance

Q3：Netty HTTP协议栈与Tomcat的HTTP协议栈有什么区别？

答复：

1）Tomcat的HTTP协议栈是Servlet2/3.X等的一种实现，是基于Servlet实现的，Netty的HTTP协议栈是一种更轻量级实现方式。

2）性能方面，Netty的HTTP协议栈性能更高，大家可以自己做下性能对比测试（Netty通常场景下性能要高2-3倍左右）。

3）在非Web场景下，例如不涉及到JSP、JS、Servlet的解析、执行和Portal展示，纯后台的HTTP调用，则使用Netty性能更高、也更加轻量，可以方便的被各种第三方容器集成。反之，如果是web场景，则仍然需要运行到Web容器中，例如Tomcat、Jetty。

Q4：Netty内部都有哪些队列，如何防止内存泄漏？

答复：Netty内部主要有三个队列，分别如下：

1) 消息发送队列ChannelOutboundBuffer，它是个无界队列，需要通过高低水位 控制来保护消息积压，防止OOM

2) NioEventLoop中的taskQueue，用于执行I/O相关的Task，需要业务自己做保护，如果投递的任务过多，会导致NioEventLoop忙于处理Task而影响消息的读写，如果严重积压会导致OOM

3) NioEventLoop中的scheduledTaskQueue，用于执行I/O相关的定时任务，例如定时发送心跳消息。需要业务自己做保护，防止OOM

上述三个队列都可能会发生OOM，需要对它们的长度和容量做监控和告警，《Netty进阶之路》中有更详细的介绍和示例代码实现。

Q5：在IoT中使用到了Netty，请问有什么性能优化措施？

答复：Netty在IoT中的性能优化，主要有如下几点措施：

1）操作系统参数优化，主要包括：文件描述符、TCP/IP相关参数、多网卡队列和软中断。

2）Netty性能调优，主要包括：线程数、心跳优化、接收和发送缓冲区、内存池、I/O和业务线程分离、线程绑定、连接池以及针对并发连接数的流控等。

3）JVM相关参数优化：GC策略和参数调优等

在《Netty进阶之路》中，专门有一章详细介绍了如果在IoT中对Netty做性能优化。

Q6：servicecomb可以像spring cloud类似，拆开各个组件吗？

答复：

ServiceComb本身是微内核的架构，自身的各个组件都是以插件的方式挂接上去的。consumer开发模式（透明RPC、springMVC）、producer开发模式（透明RPC、JAX-RS、springMVC）、transport（highway、vertx rest、servlet rest）都可以N选1或几种，随意组合，治理也提供了各种路由策略、流控、灰度、熔断、容错、降级等等组件，可以根据自己的需求组合使用。

Q7：你好 您讲的接口两种支持切换 事实上这个里面有业务代码 如何理解 是不是说切换成本较小?

答复：

问题有些模糊，不知道是不是指这个问题：开发模式与传输解耦，所以业务不需要事先纠结，传输是选择高性能的TCP+二进制，还是更开放的rest，可以随时通过配置切换。

传统上，业务会在业务逻辑中被动或主动地做与传输相关的工作，导致传输与业务绑定，无法动态切换，典型的有如下场景：

• protobuf、thrift、grpc等等框架生成的代码，里面混杂着业务数据模型、编解码逻辑，还可能有传输逻辑，必然绑架用户只能使用二进制相关的通信方式

• RESTful开发，有一些从传统Servlet继承过来的开发经验，导致开发人员直接针对网络传输来描述业务逻辑

• 入参使用HttpServletRequest、HttpServletResponse，直接读取输入流，在业务逻辑中解码；或在业务逻辑中编码，直接写输出流

  关于这个场景，还有一个更严重的后果，往往一段时间后，开发人员自己都搞不清楚输入、输出是什么了，因为全部混杂在业务逻辑中，需要去通读每一个分支，才有可能提取出输入、输出。

• 业务方法的输入、输出不明确定义数据模型，比如User类型的数据，但是开发人员，在方法上将它声明为String，然后手动解码或是手动编码

而在ServiceComb中：

• 业务方法的输入、输出都是POJO表示的数据模型

• 开发人员在业务方法中专心表达业务逻辑即可，不要做任何跟传输、编解码相关的事

  
  

编解码和传输相关的功能，由框架完成，所以只要依赖相应的transport并配置监听端口，即可实现传输切换，甚至同一个业务实例，同时支持highway和rest的接入。

Q8：请教个服务端reactive问题，io线程和业务线程通过队列传递阻塞任务，对队列的put和get是需要同步的，这个对io线程的阻塞不考虑吗？

答复：

io线程与业务线程池队列的锁竞争问题，肯定是需要考虑的，考虑清楚之后，再决策是否需要处理，以及如何处理。

如果任务量并不大，不造成激烈的锁竞争，则完全不必处理；如果竞争激烈，可以考虑将多个线程池包装为一个线程池，包装池在分发任务时，将io线程与内部的线程池进行绑定，这样可以大大降低冲突概率。比如ServiceComb中默认线程池FixedThreadExecutor就是这个策略，默认2组线程池，每组中有CPU数的线程；组数以及组内线程数均可配置。

还可以考虑，针对不同的业务方法使用不同的线程池，避免某几个慢速方法将整个池都挂住，导致其他任务都排队等待。ServiceComb中支持进程、Schema、Operation三个级别的线程池配置，最小粒度可以配置每个Operation各自独占一个线程池（当然真的给每个Operation都配置一个独占池肯定是不合适的）

对于慢速任务，还可以考虑使用ForkJoinPool，这种池中每个线程都有一个自己的队列，每个线程完成自己队列中的任务后，会去偷其他线程队列中的任务来执行。

Q9：如果consumer异步化后，transport线程池是不是恶化的比较严重?

答复：

传统异步的概念，很多时候还是要在业务线程与io线程之间切换，从单个调用上来看，线程该切换还是要切换，成本跟同步调用也差不了太多。这个时候异步的好处是，允许业务在同步逻辑中，同时发起多个调用，等这些调用都完成或某几个完成后，即进行下一步操作，减小了等待的时间。

而reactive模式下（需要满足无阻塞的前提条件），io线程即是业务线程，不需要做显式的线程切换，成本最低，性能最高。

担心io线程恶化，应该是感觉业务逻辑在io线程中执行，占用了io线程的资源。这个问题我们可以换个角度来看：

• 业务逻辑与网络操作都是必须完成的任务，无论哪种模式都绕不过

• 传统的同步在必须的任务基础上增加了多次线程切换，也就是需要完成更多的任务。

• CPU资源是有限的，在消耗同样CPU的前提下，肯定是不干多余的任务，性能更高。

关于reactive与同步的性能对比，直播中的PPT有展示，大家可以参考一下。

铛铛铛！幸运鹅们新鲜出炉啦~

精彩回顾

有小伙伴在直播评论里说没法看直播？？

No problem! 可直接复制链接 

http://t.cn/ELYW023 

到浏览器打开 或点击文末【阅读原文】观看精彩回放！

关注云原生，专为技术发声

开发云原生应用，尽在ServiceStage

 

点击文末的【阅读原文】，快来看直播回放哟O(∩_∩)O~