网关的设计与实现

接收网络请求以及处理网络情况

在高并发大流量的情况下，往往客户端存在每秒数十万的请求，因此服务器如何高效的接收网络以及处理网络请求是非常重要的一项能力。为了达到这一性能要求，我们选用epoll IO多路复用机制，IO模型采用同步非阻塞模式，即NIO模式，这样便能使用较小的系统开销处理较大的网络请求

java nio

加解密与签名

为了增加请求响应的安全性，往往会对请求响应进行加解密以及参数签名处理，以进行验证用户身份，加解密的密钥可以采用静态或动态两种方式，静态时密钥不变且统一，动态可以采用用户登录后发放，实现一用户一密钥的方式，加解密算法可采用常见的加解密算法，如RSA、AES、DES等。签名时首先对参数进行排序，以便客户端与服务端验证一致，后将排序后的参数进行拼接，最后生成签名串，签名算法可采用HmacSHA256、HmacSHA1等算法

鉴权认证

鉴权认证是对用户身份及操作权限的安全检查，是安全的重要保障。网关鉴权类型有Basic认证（基本认证）、Digest认证(摘要认证)、JWT认证、OAuth2认证、自建鉴权认证等方式

1.Basic认证：将username和password使用冒号（:）拼起来，使用base64编码，将编码后的字符串放在HTTP头Authorization中，发送给服务端

2.Digest认证：在Basic认证的基础上，增加了：1. 请求方需要对用户名、密码和域进行md5传输，保证不明文。2. 增加了随机数（nonce）和 qop（quality of protection），保证md5不固定

3.JWT认证：用户使用用户名和口令到认证服务器上请求认证。认证服务器验证用户名和口令后生成JWT Token（HMAC-SHA256对称加密），然后将 base64(header).base64(payload).signature 作为 JWT Token返回客户端。客户端在请求应用服务器资源时，带上JWT Token。应用服务器将JWT Token传给认证服务器检查 JWT Token，确认签名是正确的。认证服务器检查JWT Payload 和签名，验证通过后，告诉应用服务器。应用服务认为请求合法，返回请求的资源。

4.OAuth2认证：OAuth2.0有两种主要的方式：授权码模式和凭证模式。授权码模式是最常使用的OAuth 2.0的授权许可类型，它适用于用户给第三方应用授权访问自己信息的场景。凭证模式是一个简化版的API认证，主要是用于认证服务器到服务器的调用，也就是没有用户参与的的认证流程。

5.客户端请求携带的凭证信息（即Token）的形式是业务方自定义的格式，服务端收到请求后对Token进行鉴权验证，Token为登录用户身份后发放

访问日志与链路追踪

网关作为流量的入口，是追踪用户操作的入口，因而从网关打印访问日志，建立访问日志搜索，从访问日志追踪链路是一项对于研发提升排查问题效率的重要手段。对于链路追踪的建立，业界中受到Google Dapper论文影响最大，后续随着标准规范的发展，链路追踪逐渐遵循OpenTracing的标准，OpenTracing 是一个中立的（厂商无关、平台无关）分布式追踪的 API 规范，提供了统一接口方便开发者在自己的服务中集成一种或者多种分布式追踪的实现。

链路追踪的一种呈现

限流

1.网关在超额流量下，首先要对网关的总请求量进行控制，同时也要对同时处理的请求进行线程控制，避免请求被积压堆积造成大量的超时

2.对单个网关接口进行限流，避免下游服务被超额流量冲击压垮

3.对用户、ip、设备维度进行限流，降低机器刷接口的可能

限流通常有单机限流与集群限流两种方式，限流算法包含有固定窗口限流算法、滑动窗口限流算法、漏桶算法、令牌桶算法等。集群限流一般实现方式基于令牌桶算法思想，我们建立一个token server，从token server获取令牌，达到集群限流的目的，但在限流设计时我们需考虑token server不稳定的因素，当token server不稳定时，我们应当首先保障请求的正常，因此当token server不稳定时，我们需将限流从集群限流退化到单机限流的模式，以保障网关的稳定可用

协议转换与路由

随着微服务的普及落地，内部系统间采用着RPC协议进行着通讯，外部的请求通常为HTTP协议，因此网关承担着将HTTP协议转换为内部RPC协议的作用，网关需要完成的工作包括：获取HTTP请求参数、Context本地参数，拼装后端服务参数，完成HTTP协议到后端服务的协议转换，调用后端服务获取响应结果并转换为HTTP响应结果。路由策略采用RPC路由策略即可，因此我们需要接入注册中心这样的应用，缓存服务器目标

熔断降级

网关的下游服务处于随时可能发生故障的状态，当下游发生故障时，网关rpc请求耗时增加，引起请求失败与积压，正在请求的用户面临失败的请求可能会进行不断的重试，造成处理量增加，请求排队的情况，从而引起网关负载的上升，因此我们需要在下游发生故障时，具备熔断降级的能力，屏蔽掉下游服务故障，避免网关发生负载陡升。熔断降级限于篇幅这里也不详细讲述了，后续再详细进行介绍，常见的开源熔断降级方案包含有hystrix、sentinel等

实时监控

一个系统的运行情况需要建立一套实时监控面板来进行观察，避免黑盒情况的运行，因此我们需要对网关的各种运行状态进行观察，其中应当包括：请求量、请求耗时、请求状态码、正在处理的请求数、处理的请求异常量、流量、rpc转发量、rpc异常量与分布、rpc耗时、鉴权认证熔断降级限流量等等

内部调试与灰度发布

在研发过程时，往往存在着多人研发同一服务的场景，或者研发与测试共同进行验证到同一服务的场景，此时便产生了使用的冲突，导致研发测试效率的冲突，团队还经常产生争议。因此在内部调试与测试时，我们需要支持多泳道部署的能力，不同场景使用不同的泳道，如下图：

泳道部署运行

这样便能支持不同人群不同的使用场景验证，解决掉内部调试、测试之间的冲突，提升研发效率。同样对于线上发布时，我们需要验证一部分人群，这时需要使用泳道的方式将部分人群灰度到新发布的集群，达到灰度发布的能力。网关作为链路中的节点，需要支持泳道的能力，常见的方案是使用上下文中携带染色路由tag的方式，tag在链路中传递，路由时根据tag优先找到同一tag的服务注册节点进行路由选择

管理能力

1.域管理能力。我们在面临多业务场景时，应当具备多业务域场景的管理能力，因此需要支持多域的快速配置管理的能力，支持域场景的能力

2.接口配置能力。在业务场景内，需要将对外发布的接口配置在网关内，也需将对外接口与内部RPC的映射关系配置在内，以便内部路由转发时使用

3.多环境部署能力。在研发过程中研发人员在测试环境中配置了大量的待上线接口，待到上线时我们需要将测试环境要上线的接口快速导入到线上环境中，而非手工重新录入，手工重新录入通常存在操作失误的情况，我们要像代码部署一样，接口配置同样具备持续集成能力

4.发布管控能力。任何部署上线的变动应当都在管控范围内，降低随意操作变动造成大范围故障的风险，其中应当包含发布权限控制、发布审批、灰度发布、发布时间控制等