网关卸载模式
将共享或特殊的服务功能卸载到网关代理中。此模式可通过将共享类的服务(如SSL证书)从应用程序的其他部分移动到网关中,从而简化应用程序的开发。
问题背景
某些功能需要跨多服务,这些功能需要配置、管理和维护。在分布式环境中被一些服务共享的应用程序,在部署时会增加额外的管理开销和出错的可能性。对共享服务的任何更新都必须再次部署在引用该服务的所有服务中。
要正确的处理安全问题(令牌验证、加密、SSL证书管理)和其他复杂任务需要团队成员具有安全方面的专业技能。例如,必须在所有应用程序实例上配置并安装应用程序所需的证书。对于每次新部署,必须对证书进行管理以确保它不会过期。任何到期的证书都必须在每个应用程序部署中被更新、测试和验证。
其他常见服务(如身份验证、授权、日志记录、监视或限制)可能很难进行大规模的部署和管理。最好是对这类功能进行整合,从而减少开销和出错的机会。
解决方案
将某些功能卸载到API网关中处理,特别是跨域问题,如证书管理、身份验证、SSL、监视、协议转换或限制。
下图显示了外部SSL连接内接API网关的情形。显示了请求会从API网关上游的任何HTTP服务器进入。
此模式包括以下优点:
将资源分发与维护(如web服务器证书和安全网站的配置)集中管理,简化了服务的开发。降低了管理复杂的并提高了可伸缩性,并使服务升级更简单。
可以有专门的团队来管理安全方面的功能。这使核心团队能够专注于应用程序的功能开发,将这些贯穿各领域的问题留给相关专家来管理。
为请求和响应日志记录与监视提供了一致性视图。即使服务未被正确检测,也可以配置网关,以保证基本的监视和日志记录。
问题和注意事项
需要确保API网关具有很高的可用性和对故障的适应性。可以部署API网关的多个实例来避免单点故障。
确保网关的设计考虑到了应用的可扩展性。不会成为应用程序的瓶颈,具有足够的可伸缩性。
对应用程序的整体功能进行卸载管理,如安全性和数据传输。
不应将业务逻辑放到API网关。
如果需要跟踪事务,可根据不同目的生成相关id。
何时使用此模式
在以下情况下使用此模式:
应用程序部署面临共同的问题,如SSL证书或加密。
在对资源有不同要求(如内存资源、存储容量或网络连接)的应用程序中,部署通用功能。
希望将网络安全、带宽限制或其他网络问题的责任转移到更专业的团队进行维护。
如果引入了跨服务耦合,此模式可能不合适。
例子
使用Nginx作为ssl卸载装置,以下配置将截取SSL连接,并将连接分发到HTTP服务器的三个上游之一。
相关阅读
为前端构建后端(https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends)
网关聚合模式(https://docs.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation)
网关路由模式(https://docs.microsoft.com/en-us/azure/architecture/patterns/gateway-routing)
将共享或特殊的服务功能卸载到网关代理中。此模式可通过将共享类的服务(如SSL证书)从应用程序的其他部分移动到网关中,从而简化应用程序的开发。
问题背景
某些功能需要跨多服务,这些功能需要配置、管理和维护。在分布式环境中被一些服务共享的应用程序,在部署时会增加额外的管理开销和出错的可能性。对共享服务的任何更新都必须再次部署在引用该服务的所有服务中。
要正确的处理安全问题(令牌验证、加密、SSL证书管理)和其他复杂任务需要团队成员具有安全方面的专业技能。例如,必须在所有应用程序实例上配置并安装应用程序所需的证书。对于每次新部署,必须对证书进行管理以确保它不会过期。任何到期的证书都必须在每个应用程序部署中被更新、测试和验证。
其他常见服务(如身份验证、授权、日志记录、监视或限制)可能很难进行大规模的部署和管理。最好是对这类功能进行整合,从而减少开销和出错的机会。
解决方案
将某些功能卸载到API网关中处理,特别是跨域问题,如证书管理、身份验证、SSL、监视、协议转换或限制。
下图显示了外部SSL连接内接API网关的情形。显示了请求会从API网关上游的任何HTTP服务器进入。
此模式包括以下优点:
将资源分发与维护(如web服务器证书和安全网站的配置)集中管理,简化了服务的开发。降低了管理复杂的并提高了可伸缩性,并使服务升级更简单。
可以有专门的团队来管理安全方面的功能。这使核心团队能够专注于应用程序的功能开发,将这些贯穿各领域的问题留给相关专家来管理。
为请求和响应日志记录与监视提供了一致性视图。即使服务未被正确检测,也可以配置网关,以保证基本的监视和日志记录。
问题和注意事项
需要确保API网关具有很高的可用性和对故障的适应性。可以部署API网关的多个实例来避免单点故障。
确保网关的设计考虑到了应用的可扩展性。不会成为应用程序的瓶颈,具有足够的可伸缩性。
对应用程序的整体功能进行卸载管理,如安全性和数据传输。
不应将业务逻辑放到API网关。
如果需要跟踪事务,可根据不同目的生成相关id。
何时使用此模式
在以下情况下使用此模式:
应用程序部署面临共同的问题,如SSL证书或加密。
在对资源有不同要求(如内存资源、存储容量或网络连接)的应用程序中,部署通用功能。
希望将网络安全、带宽限制或其他网络问题的责任转移到更专业的团队进行维护。
如果引入了跨服务耦合,此模式可能不合适。
例子
使用Nginx作为ssl卸载装置,以下配置将截取SSL连接,并将连接分发到HTTP服务器的三个上游之一。
upstream iis {
server 10.3.0.10 max_fails=3 fail_timeout=15s;
server 10.3.0.20 max_fails=3 fail_timeout=15s;
server 10.3.0.30 max_fails=3 fail_timeout=15s;
}
server {
listen 443;
ssl on;
ssl_certificate /etc/nginx/ssl/domain.cer;
ssl_certificate_key /etc/nginx/ssl/domain.key;
location / {
set $targ iis;
proxy_pass http://$targ;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
}
}
相关阅读
为前端构建后端(https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends)
网关聚合模式(https://docs.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation)
网关路由模式(https://docs.microsoft.com/en-us/azure/architecture/patterns/gateway-routing)