Reactor是1995年由道格拉斯提出的一种高性能网络编程模式。由于好多年了，当时的一些概念与现在略有不同，reactor模式在网络编程中是非常重要的，可以说是NIO框架的典型模式，一些经典的框架，比如Mina、Netty、Cindy都是此模式的实现。
ChannelHandler组件包含了业务处理核心逻辑，是由用户自定义的内容，开发人员百分之九十的代码都是ChannelHandler。Netty提供2个重要的 ChannelHandler 子接口，用来自定义ChannelHandler：
前面的内容对netty进行了介绍，写了一个入门例子。作为一个netty的使用者，我们关注更多的还是业务代码。也就是netty中这两种组件：
在正式学习netty之前，我们先来回顾一下NIO编程。NIO代码是比较麻烦和复杂的，大家可以考虑一下，如果让我们自己封装NIO，哪些角度和部分是需要考虑的？如何简化编程？
Java I/O是阻塞的，为了让它支持多个并发，就要针对每个链接启动线程，这种方式的结果就是在海量链接的情况下，会创建海量的线程，就算用线程池去缓解，也是治标不治本。所以，Java I/O 不适合高并发高性能的网络编程需求。
Selector是Java NIO中的一个组件，用于检查一个或多个NIO Channel的状态是否处于可读、可写。如此可以实现单线程管理多个channels,也就是可以管理多个网络链接。
所有的 NIO 操作始于通道，通道是数据来源或数据写入的目的地，主要地，java.nio 包中主要实现的以下几个Channel：
NIO 1是在JSR51里面定义的，在JDK1.4中引入，因为BolckingIO不支持高并发网络编程，这也是Java1.4以前被人诟病的原因。NIO 2是在JSR203中定义的，在JDK1.7中引入，这是JavaNIO整个的发展历程。NIO 1和NIO 2并不是一个新旧替代的关系，而是一个补充的关系，NIO 2补充了1中缺少的一些东西。我们可以看一下两个的内容：
BIO的流程比较简单，在服务端创立一个ServerSocket去监听，等待连接。客户端创建一个Socket连接过来，服务器端就能接收到连接请求，建立一个连接。连接建立起来后，服务端和客户端就能通过一个流式API进行一个数据通信，进行一些读写操作。
Netty是一个NIO客户端服务器框架，可以快速轻松地开发协议服务器和客户端等网络应用程序。它极大地简化并简化了TCP和UDP套接字服务器等网络编程。
关于oauth2.0，最后我们再来学习一下单点登录。前面介绍过单点登录的定义，单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
前面介绍的项目都是授权服务和资源服务单独两个，这样在资源服务中的 check_token 地址都是写死的地址 ：
一个应用要求 OAuth 授权，必须先到对方网站登记，让对方知道是谁在请求。举个例子，下面是github的登记页面：
前面介绍了授权码模式和刷新令牌两种获取最新令牌的方法，下面来看一下其它模式。首先看密码模式，我们默认配置的三种模式中其实就包含密码模式的支持：
产生的授权码默认是 6 位的，产生以后并没有做任何管理，可以说是一个临时性的授权码，oauth2也提供了将授权码使用jdbc进行管理的功能，首先在数据库中创建表 oauth_code ：
可以看到我们只用setSigningKey方法配置了一个秘钥，这里使用的是简单的对称加密的方式来加密jwt内容，同时资源服务器中使用的也是同样的秘钥配置jwt转换器：
前面的例子和配置都是从头开始申请授权码和令牌，现在来看一下如何根据获取令牌时，回参中的 refresh_token 来刷新令牌。现在在项目中配置的是内存模式的默认用户名密码，第一步先改成数据库查询的方式，具体过程参考前面的文章即可，来看security配置类：
我们来继续授权服务代码的下一个优化。现在授权服务中，token的存储是存储在内存中的，我们使用的是 InMemoryTokenStore ：
前面的例子使用了默认的jdbc配置来动态从数据库查询客户端信息，下面来改用更加灵活的mybatis来实现，改用mybatis，首先pom中换成mybatis的依赖：
这个流程就像第三方登录成功后，提问是否允许获取昵称和头像信息的页面一样，这个过程其实是可以自动同意的，需要在客户端配置中，增加一个自动批准：
