简介

• 网关主要服务于微服务/API，偏向研发人员
• 反向代理主要面向传统静态web应用，偏向运维
• 而未来趋势是DevOps+网关和反向代理再次融合

发展趋势

WEB1.0/2.0时代，使用前置反向代理，由运维负责 nginx，进行反向代理和负载均衡、安全认证、限流缓存等功能。网站升级频率较低，反向代理大多采用静态配置方式。
微服务时代，API 服务升级频率高，传统的 nginx 动态配置较差，且运维执行效率低，就需要使用动态配置的网关服务，便于研发自主配置。

云原生时代提出更高要求，还需要支持灰度发布。要求网关不仅可动态配置，还要能动态编程，所以出现网关和反向代理融合的趋势，典型产品比如 envoy 和 Traefik。

云原生时代下的可编程网关

在k8s中，和网关等价的概念叫Ingress，像kong/envoy/traefik这些可编程网关，都有支持对接Ingress。

所有不同的端，ios 安卓 h5 web，要不要分，还是要看业务和团队规模，比如携程内部就有超过十套以上面向不同端的网关，总网关集群规模超过百台。对大体量多团队的公司，网关如果分的不够，不同团队容易打架。微服务也是这个道理，服务分分多少多细，也主要看体量和团队规模，小团队不分也没事。

安全认证要求，对于不同部门可能不一样，比如支付部门要求更严格，所以可以独立定制部署。

总之nginx偏运维，spring gateway对中国java程序员更友好。

二者概念区分

如果您意识到它们不是互斥的，则更容易考虑它们。将API网关视为特定类型的反向代理实现。

经常将两者结合使用时，API网关被视为位于反向代理后面的应用程序层，以进行负载平衡和运行状况检查。一个例子就是类似WAF的三层结构，其中Web应用程序防火墙/ API网关被反向代理层夹持，其中一个反向代理层用于WAF本身，另一个用于与之对话的单个微服务。

关于差异，它们非常相似。这只是术语。当进行基本的反向代理设置并开始使用更多功能（如身份验证，速率限制，动态配置更新和服务发现）时，人们更有可能调用该API网关。

反向代理+网关部署架构

• 由于架构演进的历史原因，很多公司都是反向代理和网关并存的架构
  

• 这样就得维护两套系统，肯定比较复杂，所以最好是结合统一：
  

参考

• https://stackoverflow.com/questions/35756663/api-gateway-vs-reverse-proxy

最后

以上就是高大面包为你收集整理的网关V.S反向代理简介发展趋势云原生时代下的可编程网关二者概念区分反向代理+网关部署架构的全部内容，希望文章能够帮你解决网关V.S反向代理简介发展趋势云原生时代下的可编程网关二者概念区分反向代理+网关部署架构所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。