第十章 网关注册中心库表设计

设计网关注册中心的库表结构，满足后续功能模块的实现。

库表诉求

网关注册中心，是一个多边服务，管理的是 RPC 服务向网关通信层的关联注册。

这就像美团外卖平台，一边管理着商家、一边服务着用户。让用户的订单由商家生产，再配送给用户。而我们的网关注册中心也是这样，一边管理着通信，一边管理着服务。让RPC注册到通信层，在用户调用HTTP接口时，可以把协议转换后调用到对应的RPC服务上。

基于以上这样的情况，所以我们要在注册中心维护；网关通信表、RPC服务表、以及两个表的关联表。

设计

• 网关服务：指的是管理 api-gateway-core 通信组件的服务，这些服务被分为多组。例如公司中有交易组、账务组、营销组，按照不同组来分配对应的网关服务，各自在注册网关接口时可以做到压力分摊。
• 网关明细：指的是每一组服务下，有 N 个通信核心服务，这 N 个服务需要把所有注册到自己组上的 RPC 接口，都拉取下来完成接口映射。当有HTTP访问的时候，可以均衡的打到这些服务上。
• 网关分配：管理每一个应用的分配，注册到哪一个网关上。当你注册应用的时候，会有一个选项，选择需要注册到哪个网关上。这部分一般也可以在指定的范围内，动态分配。
• 应用系统：描述一个 RPC 应用
• 应用接口：描述这个 RPC 应用下有多少个接口，以及明细
• 应用方法：描述这个 RPC 应用接口下的方法信息，对应 api-gateway-core 通信组件中的 Configuration ，包括；方法名称、入参信息、出参信息【可选】、请求类型、请求地址以及是否鉴权。因为网关返回的结果是 HTTP 方式，所以并不需要强对象描述信息，所以出参信息可选。

注册中心需要管理通信模块（多个）和 RPC 应用服务（多个），这两部分通过注册中心连结，注册中心相当于中间的桥梁
调用流程如下

1. 先在注册中心 (api-gateway-center）上将 RPC 应用服务与网关通信服务模块绑定。
2. 用户通过浏览器请求 RPC 服务，也就是需要 HTTP 转 RPC ，通过绑定关系获取网关通信模块 (api-gateway-core），从而调用下游 RPC 应用服务。
3. 网关的核心通信模块 (api-gateway-core）可以运行多个实例，那么就可以再将多个实例根据业务分组，每组负责指定的业务，减轻网关压力。

比如美团 app 中的餐饮、住宿、娱乐就可以从业务层面定义为3个功能模块，那就为每个功能模块添加网关组，每个组都有各自的网关通信服务集群，即多个 api-gateway-core 实例，那么餐饮模块需要用到的RPC应用服务，只注册到其网关通信组就行。

思考

1. gateway_ distribution 表用于绑定 RPC 应用服务与网关通信模块，属于中间表
2. 但多个网关通信模块实例组成一个组，那么是不是只需要将 RPC 应用服务与通信组绑定即可，再由通信组根据某个算法去具体指定由哪个网关实例处理 RPC 服务请求，获取对应的 gateway_server_detail 信息，而不需要将RPC应用服务与具体的网关模块绑定。
3. 基于上述猜测，gateway_server_detail 就只与 gateway_server 绑定，而不跟 gateway_distritbution 建立联系
4. 但换个角度考虑这种设计，虽然冗余了部分数据却能减少数据库 IO。我感觉这是两种思路，也许后续开发能更好体会到其中的精妙。（后续用于负载均衡）