京东的Netty实践，京麦TCP网关长连接容器架构

背景

早期京麦搭建 HTTP 和 TCP 长连接功能主要用于消息通知的推送，并未应用于 API 网关。随着逐步对 NIO 的深入学习和对 Netty 框架的了解，以及对系统通信稳定能力越来越高的要求，开始有了采用 NIO 技术应用网关实现 API 请求调用的想法，最终在 2016 年实现，并完全支撑业务化运行。

由于诸多的改进，包括 TCP 长连接容器、Protobuf 的序列化、服务泛化调用框架等等，性能比 HTTP 网关提升 10 倍以上，稳定性也远远高于 HTTP 网关。

为什么选择Netty

      了解了Socket通信（IO/NIO/AIO）编程，对于通信模型已经有了一个基本的认识。其实上一篇文章中，我们学习的仅仅是一个模型，如果想把这些真正的用于实际工作中，那么还需要不断的完善、扩展和优化。比如经典的TCP读包写包问题，或者是数据接收的大小，实际的通信处理与应答的处理逻辑等等一些细节问题需要认真的去思考，而这些都需要大量的时间和经历，以及丰富的经验。所以想学好Socket通信不是件容易事，那么接下来就来学习一下新的技术Netty，为什么会选择Netty？因为它简单！使用Netty不必编写复杂的逻辑代码去实现通信，再也不需要去考虑性能问题，不需要考虑编码问题，半包读写等问题。强大的Netty已经帮我们实现好了，我们只需要使用即可。

Netty是最流行的NIO框架，它的健壮性、功能、性能、可定制性和可扩展性在同类框架都是首屈一指的。它已经得到成百上千的商业/商用项目验证，如Hadoop的RPC框架Avro、RocketMQ以及主流的分布式通信框架Dubbox等等。

netty简介

      Netty是基于Java NIO client-server的网络应用框架，使用Netty可以快速开发网络应用，例如服务器和客户端协议。Netty提供了一种新的方式来开发网络应用程序，这种新的方式使它很容易使用和具有很强的扩展性。Netty的内部实现是很复杂的，但是Netty提供了简单易用的API从网络处理代码中解耦业务逻辑。Netty是完全基于NIO实现的，所以整个Netty都是异步的。

网络应用程序通常需要有较高的可扩展性，无论是Netty还是其他的基于Java Nio的框架，都会提供可扩展性的解决方案。Netty中一个关键组成部分是它的异步特性，本片文章将讨论同步（阻塞）和异步（非阻塞）的IO来说明为什么使用异步代码解决扩展性问题以及如何使用异步。

Netty的特性

 

设计

统一的API，适用于不同的协议（阻塞和非阻塞）

基于灵活、可扩展的事件驱动模型

高度可定制的线程模型

可靠的无连接数据Socket支持（UDP）

 

性能

更好的吞吐量，低延迟

更省资源

尽量减少不必要的内存拷贝

 

安全

完整的SSL/TLS和STARTTLS的支持

能在Applet与Android的限制环境运行良好

 

健壮性

不再因过快、过慢或超负载连接导致OutOfMemoryError

不再有在高速网络环境下NIO读写频率不一致的问题

架构

netty架构 

先放上一张漂亮的Netty总体结构图，下面的内容也主要围绕该图上的一些核心功能做分析，但对如Container Integration及Security Support等高级可选功能，本文不予分析。

下面谈一下netty框架的实现，主要针对主reactor多线程这个模型作为示例。 
其流程如下： 

 一、网络结构

客户端通过域名 + 端口访问 TCP 网关，域名不同的运营商对应不同的 VIP，VIP 发布在 LVS 上，LVS 将请求转发给后端的 HAProxy，再由 HAProxy 把请求转发给后端的 Netty 的 IP+Port。

LVS 转发给后端的 HAProxy，请求经过 LVS，但是响应是 HAProxy 直接反馈给客户端的，这也就是 LVS 的 DR 模式。