项目笔记
未读提取 Netty 通信服务配置信息，包括：IP、端口、线程数等，到会话的 Configuration 配置类中进行统一的维护和管理，便于外部调用方向内部传递信息。
设计对于第16章内容的处理，主要来自于在第17章开发的api-gateway-assist-03 网关通信助手组件，对于网关通信服务的启动，可以指定配置下 Netty 服务的IP地址和端口信息。
之前这部分配置是写死在 GatewaySocketServer 类中的，所以要对这部分内容进行处理。此外由于我们需要对 api-gateway-core 进行组件打包 Jar 给 api-gateway-assist 引入使用，那么还需要优化下 POM 配置，避免每次打包都做对 test 进行操作
这里还有一个细节点，api-gateway-assist 引入 api-gateway-core 以后，如果希望把这个 Jar 包打入到 api-gateway-assist 中。那么api-gateway-core 的包结构最好是有一个区分的。但目前是 cn.ray.gateway 之后就是各个分层功能了，所以我们调整为 cn.ray. ...
结合13章组件的开发与14章数据结构的提供，在第15章中重构网关助手组件服务，并把组件引入到 SpringBoot 中使用。
设计
结合着第13章，网关算力的助手组件初步实现，本章需要进行扩展以及验证使用。
在本章需要完成从第14章中提供的网关聚合配置信息，拉取到网关算力中，打通这部分的接口调用。后续章节再处理映射操作，因为映射还需要把网关核心算力引入到助手组件中进行包装使用。
在本章除了开发新的组件助手功能外，还需要完成测试工程的使用。
另外对于从注册中心调用的接口，还需要做一些包装处理，方便统一管理。
实现
service 包拆分到 domain 领域层，把所需的服务处理都封装到这里来提供服务。这样拆分后，以后只要看这部分代码，就知道domain 就是处理服务的，不用在乱找了。
RegisterGatewayService 网关注册服务1234567891011121314151617181920212223242526272829303132333435363738394041424344454647package cn.ray.gateway.assist.domain.ser ...
以封装 api-gateway-core 为目的，搭建 SpringBoot Starter 组件，用于服务注册发现的相关内容处理。
设计
本章内容属于注册中心所需提供的接口，因为在服务发现模块中需要从网关注册中心拉取服务配置。这个服务配置其实就是各个 RPC 服务配置【系统、接口、方法】把这些信息拉取下来，注册到网关算力中，完成 RPC 映射的过程。
首先通过 gatewaydistribution 表，把网关和 RPC 应用服务关联起来，方便知道哪个网关算力处理哪些RPC映射管理。有了这个映射关系后，就可以把对应的 application_interface、application interface method、application systemn 三个表维护应用的配置信息关联起来了。
实现【infrastructure层】网关配置仓储服务123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646 ...
以封装 api-gateway-core 为目的，搭建 SpringBoot Starter 组件，用于服务注册发现的相关内容处理。
设计
本章最大目的在于搭建起用于封装网关算力服务的 api-gateway-core 系统为目的，提供网关服务注册发现能力的组件。那么之所以要开发一个这样的组件，也就是 SpringBoot Starter，是因为我们希望把这样的统一公用能力进行一致的管理，如果没有这样的组件服务，那么将需要每一个 SpringBoot 服务都要做类似这样的事情，整体来看就会耗费很大的成本，所以要把这样的功能进行收口。
api-gateway-core 是网关的算力服务，api-gateway-center 是网关的注册中心，那么为了把这块服务链接起来，中间则需要一套 api-gateway-engin 网关的引擎，用于启动网关的算力服务。
但由于启动网关的算力服务还需要一些功能的整合，来包装网关算力到注册中心的连接，所以这部分需要整合到 api-gateway-assist 这个辅助组件，它是一个 SpringBoot Starter ，起到包装和连接的作用。
通常 ...
在网关注册中心提供服务接口的注册服务，便于后续服务启动后向网关中心注册信息。
设计
十一章我们实现了网关的服务注册，接下来我们需要提供用于 RPC 服务注册的接口。在一个 RPC 的服务注册中，需要包括三个部分：RPC 服务系统信息、这个服务下的所有接口信息、接口下的所有方法信息。分批的向网关中心完成注册操作。所有信息注册完成后，才能让网关算力服务 core 与 RPC 的接口进行关联，也就是把 RPC 接口分配到处理的网关服务上去。
网关中心维护 RPC 服务注册的库表：
application_ system 维护 RPC 服务的系统信息，如系统名称、注册中心等。
application_ interface 维护每个 RPC 服务下所有的接口信息，如接口地址、接口名称等。
application_interface_method 维护 RPC 服务下每个接口下的方法信息，如方法名称、入参类型、HTTP 请求类型、uri 以及是否鉴权等。
那么本章需要开发这样一块的功能接口，允许外部通过 HTTP 接口进行注册 RPC 服务接口。
实现【infrastructure层 ...
在网关注册中心提供网关算力节点的注册服务接口，便于后续网关启动后向网关中心注册信息。
设计
网关注册中心首先要接收来自各个网关服务的注册，任何一组用于处理 HTTP 协议请求的网关算力节点，都要注册到网关中心进行统一维护和管理。只有注册到网关中心才能把 RPC 服务分配到各个网关算力节点上进行使用。
网关中心维护网关算力节点的库表：
gateway_server 维护网关服务分组信息
gateway_server_detail 维护分组内具体的网关服务信息
目前先不用引入 zookeeper 这样的注册中心去探活服务。后期功能地额外完成后再进行陆续补充。
先来开发这样一块的功能接口：允许外部通过 HTTP 接口进行注册网关算力节点服务，使其能被注册中心调用，便于后续分配 RPC 服务。
实现【infrastructure层】网关配置仓储服务1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636 ...
项目笔记
未读设计网关注册中心的库表结构，满足后续功能模块的实现。
库表诉求网关注册中心，是一个多边服务，管理的是 RPC 服务向网关通信层的关联注册。
这就像美团外卖平台，一边管理着商家、一边服务着用户。让用户的订单由商家生产，再配送给用户。而我们的网关注册中心也是这样，一边管理着通信，一边管理着服务。让RPC注册到通信层，在用户调用HTTP接口时，可以把协议转换后调用到对应的RPC服务上。
基于以上这样的情况，所以我们要在注册中心维护；网关通信表、RPC服务表、以及两个表的关联表。
设计
网关服务：指的是管理 api-gateway-core 通信组件的服务，这些服务被分为多组。例如公司中有交易组、账务组、营销组，按照不同组来分配对应的网关服务，各自在注册网关接口时可以做到压力分摊。
网关明细：指的是每一组服务下，有 N 个通信核心服务，这 N 个服务需要把所有注册到自己组上的 RPC 接口，都拉取下来完成接口映射。当有HTTP访问的时候，可以均衡的打到这些服务上。
网关分配：管理每一个应用的分配，注册到哪一个网关上。当你注册应用的时候，会有一个选项，选择需要注册到哪个网关上。这部分一般也可以 ...
整理整个网关调用链路流程，梳理核心服务。并完成网关中心简单DDD模型结构工程的搭建，与库表连通可以查询接口映射数据。
流程梳理
如图所示，api-gateway-core 是最核心的通信层。那么它还需要把注册的网关接口在通信核心服务中启动起来。
这个启动过程首先来自于 api-gateway-sdk(类似 SpringbootStart 组件，通过注解方式管理 RPC 接口推送) 向 api-gateway-center 推送注册接口，之后在通过网关引擎 api-gateway-engine 拉取接口并在本地服务完成注册。
最后再调用到网关接口时，则是通过 api-gateway-core 调用到对应的 RPC 应用中。
那么api-gateway-sdk 并不是主要工程，没有它的是可以通过 api-gateway-admin(类似前端工程手动配置) 配置。
所以 在整个流程中 api-gateway-center、api-gateway-core 是两个核心工程，能更好的串联流程。
实现
之前章节都是在网关的 Netty 服务启动时，使用硬编码的方式将服务接口信息注入 Confg ...
项目笔记
未读通过拆分 Handler 通信管道处理器，引入 Shiro + JWT 到 AuthorizationHandler 中处理鉴权操作。
设计一次网络请求经过 Netty 处理可以分为三段；消息接收、请求鉴权、消息处理。这样就由原来我们只是在接收消息后直接把消息协议转换后请求到 RPC 服务，转换为三层 Handler 来处理简单的消息接收、请求鉴权以及 RPC 泛化调用处理。
实现Authorization 部分：
提供出进行 Shiro + JWT 进行鉴权的接口。
Mapping 部分：
在 HttpStatement 中新增布尔类型的 auth 属性，用于标记每个HTTP请求是否需要鉴权。例如GET请求并不一定需要鉴权，可以以游客的身份访问；用户账户信息则需要鉴权后才能访问。
将 IGenericReference 接口返回类型由 Object 具体为 SessionResult，方便后续直接使用包装的结果，而不用强转类型。
DataSource部分：
无变动
Session部分：
在 Configuration 中新增 AuthService 鉴权服务以及使用 ...
引入 Shiro + JWT ，提供权限认证服务。
设计在现在实现的 API 网关中，当接收 HTTP 请求以后，开始调用对应的 RPC 接口前，其实还应该做一步权限验证。也就是当前调用的 HTTP 接口是否含有网关授予的 Token 信息，这个 Token 是否在有效期范围等控制，这样才能保证一个 HTTP 的调用和返回结果是安全可靠的。
关于网关中权限的校验会使用到 Shiro + JWT， 同时还要提供单独的 Handler 来处理 Netty 中的通信对信息的校验处理。但鉴于这部分属于两块功能，所以本章只先完成关于 Shiro + JWT 部分。
傻傻分不清之 Cookie、Session、Token、JWT - 掘金
什么是 Cookie
HTTP 是无状态的协议（对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）：每个请求都是完全独立的，服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。所以服务器与浏览器为了进行会话跟踪（知道是谁在访问我），就必须主动的去维护一个状态，这个状态用于告知服务端前后两 ...
