Skip to content

Latest commit

 

History

History
123 lines (106 loc) · 9.18 KB

README.md

File metadata and controls

123 lines (106 loc) · 9.18 KB

License

许可协议 Apache License.

项目

第 1 章 Netty ——异步和事件驱动

第 2 章 你的第一款 Netty 应用程序

第 4 章 传输

第 5 章 ByteBuf

  • ByteBuf示例代码
    • Unpooled.copiedBuffer 最大容量是初始长度,所以write时可能越界

第 6 章 ChannelHandler和ChannelPipeline

第 7 章 EventLoop和线程模型

第 8 章 引导

第 9 章 单元测试

第 10 章 编解码器框架

第 11 章 预制的ChannelHandler和编解码器

第 12 章 WebSocket

第 13 章 使用UDP广播事件

第 14 章 案例研究,第一部分

  • 14.1 Droplr——构建移动服务:Netty做管道的例子很有意思,总体上来说可以参考的
    • 并发能力:几百到几千/s
    • cpu: 很少超过5%
    • 内存:-Xms1G -Xmx2G,基本上是1G
  • 14.2 Firebase—— 实时的数据同步服务
    • 相同端口的不同协议支持:http、websocket、ssl,我想如果实现:不同域名的https支持也能实现
    • 流量统计:入站和出站
    • 性能从来不是问题
    • netty的解耦(业务和网络)恰到好处
  • 14.3 Urban Airship—— 构建移动服务
    • 轻松编写与APNS对接的二进制协议
    • 自建消息通道:单进程4G的堆能支持近百万持久化TCP连接
    • Urban Airship 小结—跨越防火墙边界
      • 内部RPC框架通讯基础
      • 性能和负载测试:得益于Netty强大的性能
      • 同步协议的异步客户端

第 15 章 案例研究,第二部分

  • Netty 在 Facebook 的使用: Nifty 和 Swift
    • Nifty一套RPC客户端/服务器,构建在Netty和Thrift之上
    • Swift:一种更快的构建 Java Thrift 服务的方式
    • 性能:和C++构建的能保持在一个数量级,稳定性强
  • Netty 在 Twitter 的使用: Finagle,API端点从Ruby切换到Netty后
    • 延迟从数百毫秒降低到数十毫秒
    • 机器从3位数减少到个位数
    • 推特消息记录(2013年):143,199/s

感受

  • 架构简单、设计精妙、线程约定精妙绝伦、大量已实现的ChannelHandler
  • 异步服务器、API网关
  • 与nginx相比的想法:我对nginx代码无研究,也只是用用而已,所以提出的一些感受可能不正确
    • nginx的目标是网络服务器、而且发展多年:网络层面和业务方面耦合紧密
    • netty设计时定位就是屏蔽网络层面的复杂性,设计确实精妙所以如果涉及网络层面时相比基于nginx来做更加灵活
    • 比如:API网关https支持,可以轻松做到多域名(多租户)不同证书,这里的租户可能多达几万,而nginx需要配置很多很多