api网关综述.md

API 网关的历史

流量治理和 API 网关之间的关系密切且互补。它们在网络和软件架构领域中的应用可以增强系统的稳定性、可用性和性能。以下是流量治理和 API 网关之间的主要关系及其在网络和软件开发领域中的应用：

1. 功能交叉：

   • API 网关 提供了一个集中的入口点，用于处理进出微服务架构的所有请求。它可以执行请求的路由、认证、授权、监控以及其他一些功能。
   • 流量治理 是管理网络流量的一种方法，它包括负载均衡、流量分配、限流、熔断和流量监控等功能。

2. 流量控制：

   • API 网关 可以实现流量治理的某些功能，例如通过限流和负载均衡来管理不同服务之间的流量，确保系统的稳定运行。
   • 流量治理 通常在 API 网关中实现，以确保对服务的访问是可控且合理的，防止系统过载并保持高可用性。

3. 安全和监控：

   • API 网关 能够提供一定的安全防护，例如通过身份验证和授权来保护后端服务。同时，它也可以通过日志和监控来提供对系统流量的实时视图。
   • 流量治理 通过监控网络流量和实施安全策略，也能够增强系统的安全性。

4. 性能优化：

   • API 网关 和 流量治理 可以通过缓存、请求优化和响应转换等方式，帮助优化系统的性能。

5. 故障处理：

   • 通过在 API 网关 中实现 流量治理 的熔断机制，可以在后端服务发生故障时保持系统的可用性，通过重试、回退和重定向等策略来处理失败的请求。

6. 集中式管理：

   • 通过 API 网关，可以实现对多个服务和流量的集中式管理，这在微服务架构中尤为重要。

综上所述，流量治理和 API 网关是相互补充的，它们共同作用于网络和软件架构领域，以确保系统的稳定性、可用性和性能。在实际应用中，API 网关通常会集成流量治理的功能，为微服务架构提供统一、可控且高效的网络流量管理解决方案。

API 网关的过去、现在和未来

1. 标题和源头:

   • infoQ

2. 日期和作者:

   • 记录资讯的发布日期和作者，以了解资讯的时效性和作者的背景。

3. 摘要:

   • 创建一个简短的摘要，概述资讯的主要内容和观点。这将帮助您快速回顾资讯的核心信息。

4. 关键点和数据:

   早期的互联网

   • web 应用的体系结构为经典的 n 层体系结构，由数据库层、应用程序层和表示层组成。n 层体系结构是水平可扩展的 – 随着流量的增加，可以添加更多应用程序体系结构和表示层的实例。
   • 将应用程序或表示层的多个实例连接到 Internet 需要数据中心边缘的第一次迭代：负载平衡器。在这个时代，负载均衡器负责在应用程序的不同实例之间路由流量，确保高可用性和可扩展性。负载平衡器通常是一种硬件设备。
   • 2001 年 HAProxy 的发布开始普及软件负载平衡器的概念

   网络 2.0

   • Darcy DiNucci 在 2 年创造了 Web 0.1999 一词，指的是互联网从单向媒介演变为用户参与网站的双向媒介。Web 2.0 网站不是被动的内容消费者，而是让用户积极贡献和相互参与。AJAX（异步 JavaScript 和 XML）开发技术变得无处不在。通过将数据交换与表示分离，AJAX 为最终用户创造了更丰富的用户体验。这种架构还创建了许多“聊天”客户端，因为这些客户端会不断地从 Web 应用程序发送和接收数据。
   • 电子商务开始起飞，信用卡信息的安全传输首次成为主要问题。Netscape 引入了安全套接字层 （SSL），后来演变为传输层安全 （TLS），以确保客户端和服务器之间的安全连接。
   • 网络的这些转变 - 加密通信和许多长期连接请求 - 推动了边缘从标准硬件/软件负载平衡器向更专业的应用交付控制器（ADC）的演变。ADC 包括各种所谓的应用程序加速功能，包括 SSL 卸载、缓存和压缩。这种功能的增加意味着配置复杂性的增加。出现了各种专有配置标准，例如 VCL、SSI。负载均衡器不再只是负载均衡！

   网络规模时代

   • 扩展问题：2010 年代初期，许多云优先公司的用户群呈指数级增长。这些公司背后的软件最初是使用易于使用的 Web 框架（如 Ruby on Rails 和 Django）构建为单体 Web 应用程序。随着他们的用户群膨胀到天文数字，这些公司发现网络规模问题确实是一种不同类型的问题，它决定了不同的架构。
   • 单体架构重构： Twitter、Facebook 和 New Relic 等公司开始将关键功能从其单体架构中重构为独立部署的服务。通过将关键业务功能部署为服务，这些组织能够独立扩展和管理其整个应用程序的不同方面。流向这些独立服务的流量通过单体架构进行路由。对路由的任何更改都意味着开发人员经常不得不重新部署整个单体。这成为变革速度的瓶颈。

   API 网关的兴起

   • 从单体到微服务：早期的技术公司在从单体应用向微服务架构转变时，发现原先的单体应用主要承担路由功能。
   • API 网关的诞生：这个观察促成了 API 网关的开发，API 网关承担了原单体中的路由功能，并为整个应用提供了一个共同的外观（facade）。
   • 集中化跨服务功能：API 网关集中了跨应用的公共功能，如速率限制、身份验证和路由。
   • 减少重复功能：这种集中化减少了在每个单独服务中所需的重复功能的数量，优化了整个服务架构。

   云原生时代：微服务

   • API 网关为适应微服务架构的需求而不断演进，其现代化的关键点包括：

     • 支持跨应用层面的关注点：如身份验证、速率限制、API 发布和指标收集。
     • 集成了流量管理功能：这些功能在传统的应用交付控制器中常见，包括高级负载均衡、缓存以及自动重试和超时等。
     • 支持实时服务发现：在诸如 Kubernetes 或无服务器环境这样短暂的环境中部署微服务时，实时发现每个微服务实例的网络位置至关重要。

   全周期开发：云原生工作流

   • 拥抱全生命周期开发
     • 缩放发布和部署
       • 部署是在生产基础结构上安装代码更新的过程。发布是向实际生产用户公开代码更新的过程。虽然组织可以将部署和发布视为一个操作（所谓的“就地发布”模型），但这会向生产用户暴露实际的部署风险。例如，缺少必需的配置参数可能会导致最终用户在就地释放模型中出现可见的中断。通过将这两个阶段分开，部署风险永远不会暴露给最终用户。
       • 数据中心网关在发布中起着至关重要的作用。通过控制流向特定版本微服务的流量，网关负责向最终用户实际发布更新。此外，网关服务支持增量发布策略，例如金丝雀发布（随着时间的推移，一定比例的流量用于新的更新）或蓝/绿部署。全周期开发团队需要对网关进行控制，以便编排发布。这些控制包括路由（哪个版本的服务应该接收生产流量）以及更细粒度的控制，例如加权路由（金丝雀版本需要）和流量镜像（为测试目的创建服务测试版本的流量副本）。通过使开发团队能够管理发布和部署，组织能够扩展这些流程以支持高度复杂的应用程序。
     • 监视服务范围
       • 网关通过分析流入和流出微服务的所有流量，提供对微服务行为的可视化分析。这使网关能够报告延迟、吞吐量和错误率等指标，从而深入了解应用程序运行状况。通过使用 OpenTracing 等标准在请求数据上引入相关标识符，实现了这种功能。最后，网关堆栈收集的所有这些指标都可配置的可视化工具向这些全周期开发团队公开。

   网关策略管理

   • 关键点和重点概述：

     • 网关管理传统问题：传统上，网关的所有组件都由运维管理，而运维界面对于全周期开发团队中的应用开发者并不友好。
     • 独立操作的网关组件：网关组件通常独立操作，缺乏统一的操作界面。
     • 全周期开发者的需求：全周期开发者不是全职运维人员，他们需要能够为特定需求操作网关设备。
     • Kubernetes 生态系统的指导：Kubernetes 模型中，用户用通用的 YAML 配置语言声明他们的意图，通过声明性模型实现策略的代码化，可通过源代码控制系统（如 GitOps）进行管理。
     • 声明性模型的好处：提供审计能力、版本控制和透明性。
     • 分散的策略支持：多个策略文件被聚合为整个集群的全局策略配置。
     • API 网关模型的采纳：API 网关采纳了这种模型，例如 Azure Application Gateway 和 Kong 的入口控制器。
     • 向边缘扩展声明性配置模型：对于全周期开发团队至关重要，每个团队可以独立维护自己的网关策略，并与微服务代码一起在源代码控制中进行管理。

5. 图表和图片:

   • 

   • 

   • 

   • 

   • 

6. 个人评价和思考:

   • 这篇文章是关于对 API 网关的综述性文档，对其发展历史中重要的节点部分作了简要描述，通过部分事例使读者能窥见 API网关所要解决的问题和发展的因果，写作思路和内容都非常有参考价值。

7. 相关链接和参考资料:

   • 无

8. 标签和分类:

   • API网关
   • API gateway

9. 后续行动和提醒:

   • 后续整理现代 API网关方面的模块清单

10. 保存和归档:

    • 略