站务联系
在微服务构架中，你可以通过网路配置将服务保留在DMZ（保护区）中，并通过API网段将其公开给客户端。该网段还可以处理多种身分验证方式，例如，你可以同时支持基于cookie跟token的身分验证。
具有认证功能的 API 网关 数据汇总
在微服务机制结构中，可能会发生客户端还要不同聚合级别的数据的状况，例如对各类微服务中形成的数据实体进行非规范化。在这些状况下微端服务器，我们可以使用我们的API网段来解决这种依赖关系并从多个服务中搜集数据。
在右图中，你可以听到API 网关 如何合并用户跟信用信息，并作为一条数据返回给客户端。请注意，它们由不同的微服务拥有跟管理。
协议转换
微服务构架容许多语言合同传输因而荣获不同技术的弊端。但是，大多数客户端仅支持一种合同。在这些状况下，我们还要为客户端转化服务合同。
限速跟缓存
在上面的实例中，你可以听到我们可以把通用的共享逻辑（如身分验证）放在 API 网关中。除了身分验证此外，你还可以在 API 网关中实现速度限制，缓存以及各类可靠性功能。
超负荷的 API 网关
实现API网段时，应避免将非通用逻辑（例如特定领域的数据转换）放入网段。服务应一直对其数据域拥有完全所有权。构建一个超负荷的API网段，让微服务团队来控制，这违反了微服务的观念。
这就是为何你应当慎重使用API网段中的数据聚合的成因，使用上去或许功能强悍，但也应避免的特定于域的数据转化或规则处理逻辑。
始终为你的 API 网关定义明晰的责任，并且只包括其中的通用共享逻辑。
Node.js API 网关
当你希望在 API 网关中执行简略的操作，比如将恳求路由至特定服务，你可以使用象 nginx 这样的反向代理。但在这些时侯，你或许还要实现通常代理不支持的逻辑。在这些状况下，你可以在 Node.js 中实现自己的 API 网关。
在 Node.js 中，你可以使用http-proxy软件包简略地代理对特定服务的恳求，也可以使用更多丰富功能的express-gateway来争创 API 网关。
在我们的第一个 API 网关样例中，我们在将代码委托给 user 服务之前验证恳求。
const express = require('express')
const httpProxy = require('express-http-proxy')
const app = express()
const userServiceProxy = httpProxy('https://user-service')
// 身份认证
app.use((req, res, next) => {
// TODO: 身份认证逻辑
next()
})
// 代理请求
app.get('/users/:userId', (req, res, next) => {
userServiceProxy(req, res, next)
})
