1.HTTP请求会话协议处理
运用Netty对HTTP请求信息的协议转换，构建网关会话服务，简单响应HTTP请求信息到页面。
- 之所以称之为会话，是因为一次 HTTP 请求，就要完成；建立连接、协议转换、方法映射、泛化调用、返回结果等一些列操作。而在这些操作过程中的各类行为处理，其实也类似于ORM框架，只不过一个是对数据库的处理，一个是对 RPC服务的处理。所有的学习都是举一反三，核心的设计万变不离其宗！
- 此外之所以要单独创建出一个 api-gateway-core 的工程，是因为我们要把这个工程独立于各种容器，例如它并不是直接与 SpringBoot 一起开发，因为那样会让组件失去灵活性。它的存在更应该像是一个 ORM 框架，可以独立使用，谁也都可以结合。
具体实现：
1.定义了一个继承了SimpleChannelInboundHandler<T>的BaseHandler<T>表明为入站处理器，里面定义了一个抽象方法session（也就是会话操作），接下来在handlers包中定义了一个自定义的handler继承BaseHandler<T>，T泛型为FullHttpRequest，里面对session方法进行重写，模拟http请求的响应，最后完成一次会话。
2.定义一个用于初始化channel中的处理器的类SessionChannelInitializer，继承ChannelInitializer<SocketChannel>，重写了initChannel方法，里面向channel添加了自定义的handler以及对http请求编解码的handler。
3.服务创建：创建一个启动会话服务的类SessionServer实现了Callable<Channel>接口，让服务在线程池中启动。在重写的call方法中基于Netty搭建服务端的架子来创建服务，其中事件循环组进行了连接和读写事件的分工，参数配置了最大连接数为128。
2.代理RPC泛化调用
给网关接口绑定对应的RPC服务，建立代理关系封装RPC泛化调用。这样调用网关接口就会调用到对应的RPC服务接口上并返回对应的数据。
- 为什么要建立代理关系进行RPC的调用?调用RPC接口时如果你使用硬编码的方式，调用一个还好，如果注册到网关的RPC服务有很多呢，那你岂不是每一个RPC服务都要提供对应的调用硬编码，这样就会使代码变得冗杂，有许多实现重复逻辑的代码。这时候就离不开代理的操作了，代理将接口调用这些有共性的操作进行代理逻辑包装，这样就可以大大地减少代码量
- 什么是RPC泛化调用？它是 RPC 接口设计中提供的一种反射调用机制，你不需要硬编码调用接口，只需要提供接口的方法名称、入参信息，即可调用到对应的 RPC 接口服务。它不需要像OpenFeign一样，调用方和服务提供方都维持一套相同的接口，只需要在调用方通过代理模式进行调用。具体可查看官方文档：使用泛化调用 | Apache Dubbo
- 关于Cglib动态代理，由于需要对RPC服务进行代理操作，需要选择一种方式来做代理处理，而Cglib 可以满足我们自定义创建接口的方式进行代理，同时又可以再让一个代理类有多个接口。注意：多个接口的意思是，一个接口是用于标准的描述，在于使用上。另外一个接口是自主生成的，生成的是我们的 RPC 描述性接口，相当于自主生成了class字节码。
具体实现：
1.首先创建一个Configuration，会话配置类，里面暂时存储了接口信息，封装了GenericReferenceRegistry（用于将HTTP的请求方法与对应的RPC方法做关系绑定，如何实现的下面会具体讲到）。这个类就相当于ORM框架中的数据源。
2.创建GenericReferenceRegistry，用于注册代理类，将把 HTTP 的请求方法与对应的 RPC 方法做关系绑定。里面封装了一个HashMap，通过这个HashMap进行绑定，key为方法名称，value为泛化调用RPC方法的工厂类。
3.创建代理对象GenericReferenceProxy和代理对象的工厂类GenericReferenceProxyFactory。代理类采用cglib代理，实现MethodInterceptor接口，重写intercept方法，里面进行RPC泛化调用，通过调用GenericService的$invoke方法生成RPC描述性接口，用于真正的RPC调用。工厂类中封装了一个ConcurrentHashMap，key为RPC泛化调用的名字，value为自定义的IGenericReference（统一的泛化调用接口，下面会详细介绍）。通过computeIfAbsent方法遍历ConcurrentHashMap，如果存在该泛化调用代理类实例就直接返回该实例，如果不存在，则创建好后放在这个ConcurrentHashMap里面再返回。
4.定义了一个统一的泛化调用接口IGenericReference，这个接口是用于标准的描述，提供一个标准的 String 的入参和出参类型的泛化调用接口。
下面是类与接口之间的关系：
3.分治处理会话流程
通过分治重构会话流程，细化网络协议、会话、绑定、映射和泛化调用的关系
这一部分主要是重构上面写的代码,重构点包括:
- 拆分session包下会话业务逻辑部分和网络通信部分，做功能实现的隔离。
- 拆分bind包下代理和对RPC接口的泛化调用，这里你可以把RPC当做一种可连接资源，而这种连接资源也不是只有 RPC 一种，同时也因为 RPC 的泛化调用是一种通用方法，并不需要与逻辑绑定，所以它也应该被拆分出来。
- 整个工程结构分治设计包括: bind（绑定）、mapping（映射）、session（会话）、socket（网络）这4大块。
- 整个调用流程以 socket 网络处理协议转换后，获取会话 session 从 session 中得到映射器对象，并根据HTTP接口的 GET/POST 调用到不同的方法上。
- 因为这样的拆分可以方便在网络层做鉴权、限流、熔断、鉴权等功能，它们可以与 session 会话逻辑拆分。这也就是本章节要拆分结构的最核心目的。
- 另外一层关系是 bind 绑定层中，把 RPC 的泛化调用拆分出来，因为这里可以把 RPC 当成一种资源来看待，拆分后更有易于后续的池化、扩展和管理。
4.将连接(RPC\HTTP\其他)抽象为数据源
拆解Dubbo、HTTP调用，抽象为数据源服务，便于后续功能的扩展和使用
API网关的实现对于RPC接口的泛化调用，类似于ORM框架中对数据库的调用。那么我们也可以把 RPC 抽象成一种连接资源，做数据源的管理和池化的实现。这样既可以方便我们扩展新的连接方式，比如各类厂商的 RPC 框架，或者 HTTP 服务，以及你提供的大数据原始接口服务，也都可以被这样包装处理。所以这是抽象连接为数据源的设计目的。
整个InfiniGate网关的通信模型结构已经逐步的清晰，从网络协议转换->开启通信会话->获取映射关系->执行具体的请求方案，到现在要实现的抽象的数据源。把 RPC、HTTP 当做数据源来维护。
数据源服务核心链关系：
具体实现方案：
1.新建一个包datasource,用于抽象数据源调用。在包下创建接口Connection，用于建立连接。创建connection包，里面包含了DubboConnection和HTTPConnection对象实现Connection接口，用于发送RPC或者HTTP请求，这些是不同策略实现的连接类。
2.创建DataSource接口，用于获取连接资源。创建DataSourceFactory接口，用于创建数据源连接池的对象。创建unpooled包，包下创建UnpooledDataSource对象和其工厂对象UnpooledDataSourceFactory分别实现DataSource、DataSourceFactory接口。上面已经有了不同策略实现的连接类，这里就对这些连接的使用进行一个统一的数据源管理，同时将来还可以基于这样的连接信息做池化（限制连接数量，连接的重用）的处理，提供使用效率。
3.会话使用数据源。在网关会话中需要对数据源进行创建使用，在 DefaultGatewaySessionFactory 工厂中构建数据源，在 DefaultGatewaySession 使用数据源。
