Http API网关服务模块设计方案
1. 概述
网关作为服务生产者和服务消费者之间的接口，一方面通过“服务路由”为服务消费找到所需服务的具体位置并调用；另一方面为后台服务器提供负载均衡、安全、流量控制、身份认证等相关功能。
2. 模块需求描述
需求 | 模块 | 描述 |
API请求服务路由 | 服务路由模块 | 对业务请求进行路由，后台服务接收到服务请求后将执行结果交给服务网关，服务网关将结果转发给请求客户端 |
后台服务管理 | 服务管理模块 | 实现对后台服务的统一管理，注册、修改、删除 |
网关访问管理 | 访问控制模块 | 对访问请求进行管理，过滤掉非法、无意义的访问请求 |
记录网关访问日志 | 访问日志记录模块 | 将访问记录永久化存储，以便通过访问记录实现对非业务功能的支持 |
业务连续性支持 | 心跳模块 | 通过心跳发送相关通知消息，保障业务连续性 |
3. 整体架构
图1
4. 模块设计
4.1服务路由模块
4.1.1业务功能请求、应答流程
客户端的所有请求都首先经过服务网关，然后由它将请求路由到合适的微服务，网关经常会通过调用多个微服务并合并结果来处理一个请求。
图2
4.1.2业务服务请求流程的剖析
1. 在（1）、（2）过程中，网关收到消费者的服务请求后，需要解析消费者所请求的具体服务，因此需要定义一个消息结构，如：
Request struct {
//如果请求多个服务，对服务进行组装，
//网关拿到后对其解析，这对每个服务做出请求
Service_name string; //服务名称，唯一
Service_ID float; // 服务ID,唯一
Service_Position url/ip;//服务所在的地址、url
Service_request requester; //服务请求者
Service_load param_data; //服务调用所需的参数
}
网关通过解析这个Request结构体找到服务ID、服务所在的具体位置，解析过程需要用到一个服务注册表，结构大体如下：
Service_Table {
Service_name :“add_service”
Service_version：版本
Sevice_position: “.../path/add.html” 或者可以直接是一个IP地址
Service_descrition: 服务描述
Service_creator : 责任人
}
服务注册表来自于服务注册模块，当后台需要添加一个服务时，需要向服务注册模块注册，服务注册模块将其添加到服务注册表中，在之后的服务调用中通过读取服务注册表找到服务所在的具体位置。服务注册表的存储、读取实现通过数据库模块来实现。
2、在（2）中的协议解析完成后，在第三步（3）中根据获取到的服务地址与具体的服务通信，不关心所提交的Service_load里面的具体内容，这个内容由服务自己进行解析，服务端根据服务功能提供服务结果（第4步），请求可以失败，无论如何会提供一个服务的返回结果。
3、在5、6、7步中，网关收到各个服务请求的返回结果后，进行合并，将结果返回给服务消费者。
服务请求与返回结果的结构体格式定义可以分开来做，网关只负责服务路由，请求的内容和返回结果由服务消费者和服务提供者自己来封装、解析，事先二者做好协议定义。
4.1.3微服务访问结果的合并
每个业务请求内可能包含对多个微服务的请求，API网关收到服务请求后，对请求服务进行解析，并发对每个服务进行请求，每个服务的请求结果返回后，API网关对服务结果进行合并，将其返回给服务请求者。
如果每个业务请求只包含一个对后台服务的请求，可以通过Nginx配置文件的方式将请求路由到后台服务器；如果每个业务请求包含对多个微服务的请求，则需要定义请求结构体和结果返回结构体，以完成服务请求者和服务提供者间的通信。图3展示了，请求中包含多个微服务时，API网关的响应流程。
图3
(1) 服务请求Request A向 API网关发送服务请求信息，里面包括对三个服务的请求，及请求服务的名字和每个请求要用到的参数；
(2、3)网关收到服务请求后通过服务的名字，在服务注册表中找到服务所在的服务器位置；
(4、5)后台服务收到请求后对服务进行处理，并将结果返回
(6)网关将请求的结果合并返回给服务请求者，并不是请求的每个微服务都会正确回应，但是网关会把所有的微服务结果都返回
4.2服务管理模块
4.2.1服务注册
后台服务器提供很多微服务，服务管理模块对这些微服务进行统一的管理，主要是服务的注册、注销、修改。图4为服务注册流程，后台微服务较多，并且服务内容不会经常变动，从开发角度讲，不可能针对每个微服务提供服务注册方法，因此服务注册由服务提供商发起，服务注册模块提供两方面的接口：
1.与服务注册商交互的接口。接收请求，返回请求操作结果。
2. 操作数据库的接口。（本质上就是，服务注册商通过服务注册模块实现服务注册表的操作）
图4
目前未涉及到服务提供商的问题，可以由管理员直接将服务注册表写入到数据库中，管理员对其进行运维，如图5。对于数据库的选择，遵循以下原则：数据一致性、冗余备份策略
图 5
4.2.2服务可用性的周期性检测
服务注册模块可以实现对服务注册表的操作，方式是读取服务注册表所在的数据库数据，获得所有服务所在的位置，建立服务测试请求（定义服务测试请求规范），如果服务能够正常访问则跳过；如果服务不能正常访问，则告知管理员。
4.3访问日志记录模块与访问控制模块（具体细节参考实际业务场景）
访问日志记录：
记录对API网关访问的日志，通过分析日志获得一些有用的信息，如通过流量监控判断是否存在类似ddos的攻击，判断是否存在安全测试行为
访问控制模块：
访问合法性的检查，无论是对内网还是外网的接口都需要做身份认证，而认证在一些规模大点的公司都会有统一的单点登录系统，如果每个微服务系统都是做对接单点登录系统的工作，那么显然比较浪费资源，开发效率低。可以将认证的部分抽取到网关层，然后微服务系统无需关注认证的逻辑只关注自身业务即可。
对一些特定的接口设置白名单，访问次数，访问频率等各类设置，这些非业务功能的配置以及变更不会影响微服务的实现可以在网关层单独做操作。
4.4心跳模块（具体细节参考实际业务场景）
