API-Gateway

作者：昱坤 在公有云方案日益火爆的今天，公有云应用越来越广泛。随之而来的，公有云也遇到了一些挑战：  传统数据中心产品不一定支持云环境  传统的产品不一定支持云弹性的部署以及模块化的部署  云架构的部署思路与传统物理环境部署环境完全不同  传统的安全防护很难在多云环境提供统一安全解决方案  遇到最多的问题就是：我们云环境一定要和物理数据中心架构一样 而在企业进行公有云迁移时对于安全和自动化的要求，AWS上有了新的安全自动部署方案： 在该方案中，可以将防火墙部署在Transit VPC中，以实现VPC与VPC间/VPC与Internet间等的安全加固需求。此文仅介绍Fortinet AWS 的安全解决方案。 Fortinet云部署实例要求 如果要在AWS上部署FortiGate-VM，那么实例需要满足以下要求： Fortinet常见云部署模式 针对AWS云上部署，Fortinet提供两种常见的部署方案： NGFW 和ELB部署形式  两个AZ的FW与WAF工作在AA模式  入向流量通过ELB负载分摊  FW开启NGFW威胁检测功能  FW将流量映射至内部ELB FQDN NGFW以及WAF 和ELB部署形式  FW与WAF完全集成将HTTP转至WAF  WAF对HTTP流量进行深度检测  WAF将HTTP流量映射至内部ELB 在该部署模式下

传统业务实现 Websocket 并不难，然而函数计算基本上都是事件驱动，不支持长链接操作。如果将函数计算与 API 网关结合，是否可以有 Websocket 的实现方案呢？ API 网关触发器实现 Websocket WebSocket 协议是基于 TCP 的一种新的网络协议。它实现了浏览器与服务器全双工 (full-duplex) 通信，即允许服务器主动发送信息给客户端。WebSocket 在服务端有数据推送需求时，可以主动发送数据至客户端。而原有 HTTP 协议的服务端对于需推送的数据，仅能通过轮询或 long poll 的方式来让客户端获得。 由于云函数是无状态且以触发式运行，即在有事件到来时才会被触发。因此，为了实现 WebSocket，云函数 SCF 与 API 网关相结合，通过 API 网关承接及保持与客户端的连接。您可以认为云函数与 API 网关一起实现了服务端。当客户端有消息发出时，会先传递给 API 网关，再由 API 网关触发云函数执行。当服务端云函数要向客户端发送消息时，会先由云函数将消息 POST 到 API 网关的反向推送链接，再由 API 网关向客户端完成消息的推送。 具体的实现架构如下： 对于 WebSocket 的整个生命周期，主要由以下几个事件组成： 连接建立：客户端向服务端请求建立连接并完成连接建立； 数据上行

目录 文章目录 目录 微服务架构中的 API 问题 API Gateway API 的组合/聚合 Kong Gateway APIGW vs ServiceMesh 微服务架构中的 API 问题 根据 Gartner 对微服务的定义：“ 微服务是范围狭窄、封装紧密、松散耦合、可独立部署且可独立伸缩的应用程序组件 。” 与将模块高度耦合并部署为一个大的应用程序相比，微服务的目标是将应用程序充分分解或者解耦为松散耦合的许多微服务或者模块，这样做对下面几点有很大帮助： 每个微服务都可以独立于应用程序中的同级服务进行部署、升级、扩展、维护和重新启动。 通过自治的跨职能团队进行敏捷开发和敏捷部署。 运用技术时具备灵活性和可扩展性。 在微服务架构中，我们根据各自的特定需求部署不同的松耦合服务，其中每个服务都有其更细粒度的 API 模型，用以服务于不同的客户端（Web，移动和第三方 API）。 在考虑客户端与每个已部署的微服务直接通信的问题时，应考虑以下挑战： 如果微服务向客户端公开了细粒度的 API，则客户端应向每个微服务发出请求。在典型的单页中，可能需要进行多次服务器往返，才能满足请求。对于较差的网络条件下运行的设备（例如：移动设备），这可能会更糟。 微服务中存在的多种通信协议（例如：gRpc、thrift、REST、AMQP 等）使客户端很难轻松采用所有这些协议。

实验说明: 在先前的中，我们讲到使用 AWS CLI 对 S3 中的对象进行操作，在配置 AWS CLI 的 时候，我们创建了 IAM Access Key 和 Secret Key，这种 Key 属于 Long Term Key，也就意味 着如果您不 rotate Key，那么 key 将长期有效，如果 Key 不慎丢失，就需要在 AWS IAM 界 面删除这个 key 或者停用 key。当我们将服务部署在 AWS EC2 的时候，还有另外一个可选 方案，即使用 EC2 Role(角色)的方式，使 EC2 具有访问 AWS 资源的权限，这样就不需要在 EC2 实例上或我们的应用代码中指定 IAM Key，可进一步加强服务的安全性。 实验概要: 本次实验中，我们将对 EC2 绑定一个 IAM 角色，在不配置 EC2 Access Key 和 Secret Key 的 情况下，使 EC2 具有通过 AWS CLI 操作 S3 存储桶的能力。 实验步骤: 打开 IAM 界面，然后点击”角色”----“创建角色” 选择受信任的实体类型为”AWS 产品”---EC2， 在 Attach 权限策略处，搜索 AmazonS3FullAccess 策略，然后勾选这条策略，点击”下一步: 标签” 添加标签界面可直接点击”下一步: 审核”，角色名称可以随便写，比如 EC2AccessS3，然后 点击

网关介绍 网关其实就是将我们写好的API全部放在一个统一的地址暴露在公网，提供访问的一个入口。在 .NET Core下可以使用 Ocelot 来帮助我们很方便的接入API 网关。与之类似的库还有 ProxyKit ，微软也发布了一个反向代理的库 YARP 。 关于网关的介绍不多说了，网上文章也挺多的，这些都是不错的选择，听说后期 Ocelot 将会使用 YARP 来重写。本篇主要实践一下在.NET Core环境下使用 Ocelot 。 Ocelot官网：https://threemammals.com/ocelot Ocelot文档：https://ocelot.readthedocs.io GitHub：https://github.com/ThreeMammals/Ocelot Ocelot资源汇总：https://www.cnblogs.com/shanyou/p/10363360.html 接入使用 接口示例 先创建几个项目用于测试，创建两个默认的API项目，Api_A和Api_B，在创建一个网关项目Api_Gateway，网关项目可以选择空的模板。 现在分别在Api_A和Api_B中写几个api，将默认的 WeatherForecastController 中返回模型 WeatherForecast 添加一个字段Source，用于区分是哪个API返回的数据。 using

1. 前言 4月25号，Sentinel 1.6.0 正式发布，带来 Spring Cloud Gateway 支持、控制台登录功能、改进的热点限流和注解 fallback 等多项新特性，该出手时就出手，紧跟时代潮流，昨天刚发布，今天我就要给大家分享下如何使用！ 2. 介绍（本段来自Sentinel文档） Sentinel 1.6.0 引入了 Sentinel API Gateway Adapter Common 模块，此模块中包含网关限流的规则和自定义 API 的实体和管理逻辑： GatewayFlowRule：网关限流规则，针对 API Gateway 的场景定制的限流规则，可以针对不同 route 或自定义的 API 分组进行限流，支持针对请求中的参数、Header、来源 IP 等进行定制化的限流。 ApiDefinition：用户自定义的 API 定义分组，可以看做是一些 URL 匹配的组合。比如我们可以定义一个 API 叫 myapi，请求 path 模式为 /foo/ 和 /baz/ 的都归到 myapi 这个 API 分组下面。限流的时候可以针对这个自定义的 API 分组维度进行限流。 其中网关限流规则 GatewayFlowRule 的字段解释如下： • resource：资源名称，可以是网关中的 route 名称或者用户自定义的 API 分组名称。 •

首先要知道的是Spring Cloud是微服务架构。 微服务架构是一种架构模式，它将单一的应用程序划分成一组很小的服务，服务之间相互协调、互相配合。每个服务都运行在独立的进程中，服务与服务间采用轻量级通信机制（通常是HTTP协议的RESTful API）。每个服务都有着自己的业务，并且能够被独立的部署到生产环境、类生产环境等，对于具体的一个服务而言，应该根据上下文，选择合适的语言、工具对其进行构建。 Spring Cloud中是一种微服务架构，项目案例：www.1b23.com，其中包含如下功能： 服务注册与发现、服务调用、服务熔断、负载均衡、服务降级、服务消息队列、配置中心管理、服务网关、服务监控、全链路追踪、自动化构建部署、服务定时任务。 但是在项目中一般只会用到如下几种： 服务注册与发现：EUREKA 服务负载与调用：NETFLIX OSS RIBBON、NETFLIX FEIGN 服务熔断降级：HYSTRIX 服务网关：NETFLIX Zuul 服务器分布式配置：Spring Coloud Config 服务开发：Spring Boot 下面来看下官方解析 Cloud 分布式系统的开发与一般的系统来说是具有挑战性的。服务之间的交流更为密切，Cloud把项目的工作重点由应用层移到了网络层。代码想要连接到Cloud服务需要12个因素，如配置文件，状态，日志，连接到后端的服务