dgate是一款基于Vert.x的API Gateway，它不同于大多数其他API Gateway，主要表现在两个地方：
- 轻量级配置，所有路由规则都定义在文件中，不需要后端DB。
- 除了服务于产品环境，它还支持测试场景，提供Mock机制，让前后端的接口通过配置文件得以固化。
本文将对dgate的主要特性一一进行简要的说明，方便读者对dgate有进一步的了解。
基于Groovy的配置DSL
以下是一个简单的配置文件的例子：
import io.vertx.core.http.HttpMethod
apiGateway {
port = 7000
host = 'localhost'
urls {
"/url1" {
required = ['param1', 'param2']
methods = ['GET', 'POST']
upstreamURLs = [
[host: 'localhost', port: 8080, url: '/test']
]
}
"/url2" {
required = ['param1', 'param2']
methods = ['GET', 'POST']
upstreamURLs = [
[host: 'localhost', port: 8080, url: '/test1'],
[host: 'localhost', port: 8080, url: '/test2']
]
}
}
}
语法非常简单，基本无需做过多的解释。将其应用到dgate的命令如下（其中的conf为文件名）：
java -jar dgate-版本号-fat.jar -Dconf=conf
支持测试的Mock URL
Mock URL主要是为了简化前后端分离（包括Mobile和后台）环境下的开发和测试。还是通过例子来看看：
"/mock" {
expected {
statusCode = 200
payload = [test: true]
}
}
跟前面的例子一样，这个语法也是不言自明，其中expected部分只需放入前后端开发人员商量好的接口即可。这样完全避免了前端等后端的情形，开发时采用Mock配置，产品环境下采用真实配置即可。
同时，为了更好地支持测试，dgate还有这些特性：
- 支持按HTTP Method进行Mock
- statusCode和payload都支持闭包，以其返回值为最终结果，支持动态Mock。
灵活的上游请求
一般来讲，一个前端页面在加载过程中会向后端发起多个请求，dgate完全支持这种场景。参见上面的“/url2”，对于前端只是暴露统一的/url2，但它对应后端的两个请求。
dgate会同时发起多个请求，并将结果汇总，统一返还给前端。这样不仅仅降低了前端页面面对的后端URL数，而且通过引入中间层，让接口和实现得到分离。
并且，对于某些有特殊需要的场景，dgate提供了before和after闭包，允许开发者在前端请求转发到后端和后端结果发往前端之前“为所欲为”。具体使用可以参见相应的文档。
其他值得一提的特性
除了上面的主要功能，dgate还具备以下特性：
- 支持URL Path Parameters
- 支持JWT，token获取和token刷新
- 支持CORS
- 灵活的login配置
- 支持断路器，对于每个发往后端的请求，dgate会将其包裹在一个断路器中。可视为对于后端API的decorator。
各位可以从用户指南中了解进一步的细节。
限制
作为一篇介绍工具的短文，不讲限制和缺陷是不完整的，这里我就说说dgate的不足：
- 前端请求经过dgate之后，都会变成【HTTP METHOD + Request BODY】的形式，Form请求也不例外。
- 虽然支持JWT，但整个验证过程仍需结合外部。因为，我们相信这里并没有一刀切的方式。
- 上游服务的地址时硬编码，这在未来将会改进
- 仅支持HTTP方式的调用，未来会考虑支持gRPC
dgate虽然已经用于我们的开发和产品环境，但离完美还有相当的一段距离。这里的所有功能都是首先为了满足我们自己的需要而开发的。因此，很难说dgate是否能完全适用于你的产品环境。
但是，我对dgate会促进和简化你的开发和测试很有信心，为何不尝试一下，;)？
