．网关数据管理
实现一个适合自已的网关，数据管理我们需要考虑如下这些方面
．首先，我们要考虑一下，我们需要管理些什么数据。
本身对数据管理的管理是很弱的。它没有提供数据的持久化方案，它所有的数据都来自初始化，来自它的配置文件（.）。它本身虽然也对外提供了一些管理接口（ ）能力不够，但能力不够，且这些修改都是暂时的，网关一停，数据就消失了。这就要求我们要用一套更完善的方案，把网关的这些数据管理起来，不能让它只能写在配置文件中，而要支持持久化，支持动态变更。再有就是我们对各微服务的治理数据。网关只用来做路由转发，那就太浪费了，统一认证，统一鉴权，访问日志记录，应用访问统计，黑白名单过滤，订阅管理，流量限制，甚至数据格式转换，网络协议转换，都可以在网关中来做。而所有的这些能力，无不需要数据的支持。因此，这些服务的治理配置，也是网关需要管理的数据。
．数据有了，我们还得考虑怎么把它保存起来，不能网关一重启，所有数据就没了。
．还得再考虑一下数据的读取。网关对性能的要求是很高的，每次对过关的数据进行治理，都需要去读取这些配置信息。如果配置信息读取太消耗资源，无疑对网关是不利的。所以，我们还得考虑数据如何缓存，以提高数据的读取性能。
．单个网关，可以处理的请求量是有上限的。为了应对大的流量，我们可能会需要对网关做水平扩容。当多个网关实例共存时，如何保障对网关的修改，能快速同步到每个网关实例呢？数据变更通知也得考虑。
．最多，我们还得考虑一下方案的扩展，数据存储能不能改个地方，通知能不能换种方式？
综合考虑了这些方面之后，我们的网关的架构如下：
-
如图，以上就是我们网关的整体设计。方案设计要点如下：
．网关对外提供治理数据管理接口，微服务治理平台可通过这些接口，将治理配置推送到网关
．网关通过治理数据统一存储接口，将治理配置数据保持至治理数据持久存储（这里我们默认为）
．通过发布订阅能力，将数据的变更通知到各网关实例
．各网关实例收到通知后，将数据从持久存储同步至内部高速缓存
．内部缓存在网关启动时，会自动从持久存储加载对应配置进入缓存. 同时它也支持清空，以及按需加载
．外部业务请求经过网关时，对数据执行鉴权，处理转换，以及灰度策略时，所需要的治理配置，都从内部缓存中获取，以提升性能
．方案中，外部持久存储（默认用的，可以换成，文件，等），以及数据变更通知（默认使用的是的发布订阅，可以换成通知，消息队列，定时扫描等），都是可以通过扩展更换的