好资源和短想法
为什么Netty的ServerBootstrap需要两个EventLoopGroup呢
从应用程序开发人员的角度来看，Netty 的主要组件是 ChannelHandler，它充当了所有 处理入站和出站数据的应用程序逻辑的容器。这是可行的，因为 ChannelHandler 的方法是 由网络事件(其中术语“事件”的使用非常广泛)触发的。事实上，ChannelHandler 可专 门用于几乎任何类型的动作，例如将数据从一种格式转换为另外一种格式，或者处理转换过程 中所抛出的异常。
一个 EventLoopGroup 包含一个或者多个 EventLoop;
一个 EventLoop 在它的生命周期内只和一个 Thread 绑定;
所有由 EventLoop 处理的 I/O 事件都将在它专有的 Thread 上被处理;
一个 Channel 在它的生命周期内只注册于一个 EventLoop;
一个 EventLoop 可能会被分配给一个或多个 Channel。 注意，在这种设计中，一个给定 Channel 的 I/O 操作都是由相同的 Thread 执行的，实际
上消除了对于同步的需要。
一个 EventLoop 在它的生命周期内只和一个 Thread 绑定;
所有由 EventLoop 处理的 I/O 事件都将在它专有的 Thread 上被处理;
一个 Channel 在它的生命周期内只注册于一个 EventLoop;
一个 EventLoop 可能会被分配给一个或多个 Channel。 注意，在这种设计中，一个给定 Channel 的 I/O 操作都是由相同的 Thread 执行的，实际
上消除了对于同步的需要。
我们对于 Channel、EventLoop 和 ChannelFuture 类进行的讨论
本章主要内容
Netty 的技术和体系结构方面的内容
Channel、EventLoop 和 ChannelFuture ChannelHandler 和 ChannelPipeline 引导
3.1 Channel、EventLoop 和 ChannelFuture 31
Channel— Socket;
EventLoop— 控制流、多线程处理、并发; ChannelFuture— 异步通知。
本章主要内容
Netty 的技术和体系结构方面的内容
Channel、EventLoop 和 ChannelFuture ChannelHandler 和 ChannelPipeline 引导
3.1 Channel、EventLoop 和 ChannelFuture 31
Channel— Socket;
EventLoop— 控制流、多线程处理、并发; ChannelFuture— 异步通知。
Netty:
由于本书剩下的部分都建立在这份材料的基础之上，所以我们将从两个不同的但却又密切相 关的视角来探讨 Netty:类库的视角以及框架的视角。对于使用 Netty 编写高效的、可重用的和 可维护的代码来说，两者缺一不可。
从高层次的角度来看，Netty 解决了两个相应的关注领域，我们可将其大致标记为技术的和 体系结构的。首先，它的基于 Java NIO 的异步的和事件驱动的实现，保证了高负载下应用程序 性能的最大化和可伸缩性。其次，Netty 也包含了一组设计模式，将应用程序逻辑从网络层解耦， 简化了开发过程，同时也最大限度地提高了可测试性、模块化以及代码的可重用性。
由于本书剩下的部分都建立在这份材料的基础之上，所以我们将从两个不同的但却又密切相 关的视角来探讨 Netty:类库的视角以及框架的视角。对于使用 Netty 编写高效的、可重用的和 可维护的代码来说，两者缺一不可。
从高层次的角度来看，Netty 解决了两个相应的关注领域，我们可将其大致标记为技术的和 体系结构的。首先，它的基于 Java NIO 的异步的和事件驱动的实现，保证了高负载下应用程序 性能的最大化和可伸缩性。其次，Netty 也包含了一组设计模式，将应用程序逻辑从网络层解耦， 简化了开发过程，同时也最大限度地提高了可测试性、模块化以及代码的可重用性。
这篇文章介绍了tracert和traceroute的实现原理，可以对照着复习一下相应的网络基础
https://www.inetdaemon.com/tutorials/troubleshooting/tools/traceroute/definition.shtml
https://www.inetdaemon.com/tutorials/troubleshooting/tools/traceroute/definition.shtml
远程调用的流程
启动服务端(服务提供者)并发布服务到注册中心
启动客户端(服务消费者)并去注册中心订阅感兴趣的服务
客户端收到注册中心推送的服务地址列表
调用者发起调用, Proxy从服务地址列表中选择一个地址并将请求信息<group, providerName, version>, methodName, args[]等信息序列化为字节数组并通过网络发送到该地址上
服务端收到收到并反序列化请求信息, 根据<group, providerName, version>从本地服务字典里查找到对应providerObject, 再根据<methodName, args[]>通过反射调用指定方法, 并将方法返回值序列化为字节数组返回给客户端
客户端收到响应信息再反序列化为Java对象后由Proxy返回给方法调用者
以上流程对方法调用者是透明的, 一切看起来就像本地调用一样,
重要概念: RPC三元组 <ID, Request, Response>
启动服务端(服务提供者)并发布服务到注册中心
启动客户端(服务消费者)并去注册中心订阅感兴趣的服务
客户端收到注册中心推送的服务地址列表
调用者发起调用, Proxy从服务地址列表中选择一个地址并将请求信息<group, providerName, version>, methodName, args[]等信息序列化为字节数组并通过网络发送到该地址上
服务端收到收到并反序列化请求信息, 根据<group, providerName, version>从本地服务字典里查找到对应providerObject, 再根据<methodName, args[]>通过反射调用指定方法, 并将方法返回值序列化为字节数组返回给客户端
客户端收到响应信息再反序列化为Java对象后由Proxy返回给方法调用者
以上流程对方法调用者是透明的, 一切看起来就像本地调用一样,
重要概念: RPC三元组 <ID, Request, Response>
