wx.request 的get请求支持通过body传json吗?_您可以在Kubernetes中使用API??网关公开微服务吗？...

最新推荐文章于 2024-05-05 18:00:00 发布

weixin_39683368

最新推荐文章于 2024-05-05 18:00:00 发布

阅读量223

点赞数

文章标签： wx.request 的get请求支持通过body传json吗? yii2 请求外部api 笔记本可以当网关吗

在Kubernetes中，Ingress是一个组件，可将流量从群集外部路由到群集中的服务和Pod。
简而言之，Ingress充当反向代理或负载平衡器：所有外部流量都路由到Ingress，然后路由到其他组件。

尽管最受欢迎的Ingress是ingress-nginx项目，但是在选择和使用Ingress时还有其他几种选择。

您可以从以下Ingress控制器中选择：

处理诸如Contour或Treafik Ingress之类的HTTP流量
支持UDP和TCP流量，例如Citrix Ingress
支持Websocket，例如HAProxy Ingress

还有其他混合式Ingress控制器可以与现有的云提供商集成，例如Zalando的Skipper Ingress。

当谈到Kubernetes中的API网关时，有一些流行的选择可供选择。

选项1 — API网关之王：Kong

如果要构建API，则可能会对Kong Ingress提供的功能感兴趣。
Kong是建立在Nginx之上的API网关。
Kong专注于API管理，并提供身份验证，速率限制，重试，断路器等功能。
Kong的有趣之处在于它以Kubernetes Ingress的形式打包。
因此，它可以在您的群集中用作用户和后端服务之间的网关。
您可以使用标准Ingress对象将API暴露给外部流量：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: api-service
              servicePort: 80

但是

在安装过程中，Kong的控制器会注册自定义资源定义（CRD）。
这些自定义扩展之一与Kong的插件有关。
如果您希望通过IP地址限制对Ingress的请求，则可以使用以下方法创建限制的定义：

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rl-by-ip
config:
  hour: 100
  limit_by: ip
  second: 10
plugin: rate-limiting

您可以在Ingress中使用以下注释来引用限制：

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    plugins.konghq.com: rl-by-ip
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: api-service
              servicePort: 80

您可以在官方文档中浏览有关Kong的自定义资源定义（CRD）。
但是Kong不是唯一的选择。

选项2 –Ambassador，现代API网关

Ambassador是另一个基于Envoy构建的Kubernetes Ingress，它提供了强大的API网关。
Ambassador Ingress是Kubernetes Ingress控制器的现代代表，它提供了强大的协议支持以及速率限制，身份验证API和可观察性集成。
与Kong的主要区别在于Ambassador是为Kubernetes构建的，并与它很好地集成在一起。

Kong于2015年开源，当时Kubernetes Ingress控制器还不那么先进。

即使在设计Ambassador时就考虑到Kubernetes，它也不会利用熟悉的Kubernetes Ingress。

而是使用注释将服务公开给外界：

apiVersion: v1
kind: Service
metadata:
  labels:
    service: api-service
  name: api-service
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v0
      kind: Mapping
      name: example_mapping
      prefix: /
      service: example.com:80
      host_rewrite: example.com
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80
  selector:
    service: api-backend

新颖的方法非常方便，因为您可以在一个地方为Deployments和Pod定义所有路由。
但是，将YAML作为注释中的自由文本可能会导致错误和混乱。
在标准YAML中很难正确设置格式，更不用说在更多YAML中使用字符串了。
如果您希望对API应用速率限制，这就是Ambassador中的样子。
您有一个RateLimiting对象，它定义了需求：

apiVersion: getambassador.io/v1beta1
kind: RateLimit
metadata:
 name: basic-rate-limit
spec:
 domain: ambassador
 limits:
  - pattern: [{x_limited_user: "false"}, {generic_key: "qotm"}]
    rate: 5
    unit: minute
  - pattern: [{x_limited_user: "true"}, {generic_key: "qotm"}]
    rate: 5
    unit: minute

您可以通过以下方式在服务中引用速率限制：

apiVersion: v1
kind: Service
metadata:
  name: api-service
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: RateLimitService
      name: basic-rate-limit
      service: "api-service:5000"
spec:
  type: ClusterIP
  selector:
    app: api-service
  ports:
    - port: 5000
      targetPort: http-api

Ambassador提供了有关速率限制的出色教程，因此，如果您对使用该功能感兴趣，可以直接转到Ambassador的官方文档。
您可以使用用于路由的自定义过滤器扩展Ambassador，但它没有像Kong那样提供充满活力的插件生态系统。

选项3-集大成者gloo

Ambassador并不是唯一可以用作API网关的由Envoy驱动的Ingress。
Gloo是Kubernetes Ingress，也是API网关。它能够提供速率限制，熔断，重试，缓存，外部身份验证和授权，转换，服务网格集成和安全性。
Gloo的卖点是它能够自动发现您的应用程序的API端点并自动理解参数。
可能很难相信（有时他们的文档也无济于事），所以这里有个例子。
假设您有一个通讯录的REST API。

该应用程序公开以下端点：

GET /users/{id}，获取用户的个人资料
GET /users，获取所有用户
POST /users/find，找到一个特定的用户

如果您的API是使用标准工具（例如OpenAPI）开发的，那么Gloo会自动使用OpenAPI定义来内省您的API并存储三个端点。
如果在发现阶段之后列出了Gloo服务的所有端点，那么您将看到：

upstreamSpec:
  kube:
    selector:
      app: addressbook
    serviceName: addressbook
    serviceNamespace: default
    servicePort: 8080
    serviceSpec:
      rest:
        swaggerInfo:
          url: http://addressbook.default.svc.cluster.local:8080/swagger.json
        transformations:
          findUserById:
            body:
              text: '{"id": {{ default(id, "") }}}'
            headers:
              :method:
                text: POST
              :path:
                text: /users/find
              content-type:
                text: application/json
          getUser:
            body: {}
            headers:
              :method:
                text: GET
              :path:
                text: /user/{{ default(id, "") }}
              content-length:
                text: '0'
              content-type: {}
              transfer-encoding: {}
          getUsers:
            body: {}
            headers:
              :method:
                text: GET
              :path:
                text: /users
              content-length:
                text: '0'
              content-type: {}
              transfer-encoding: {}

Gloo具有端点列表之后，您可以使用该列表在传入请求到达后端之前将转换应用于传入请求。
例如，您可能希望从传入的请求中收集所有标头，然后在请求到达应用程序之前将它们添加到JSON有效负载中。
或者，您可以公开JSON API，并让Gloo应用转换以在消息到达旧组件之前将消息呈现为SOAP。
能够发现API和应用转换使Gloo特别适用于具有多种技术的环境-或当您正处于从旧系统到新堆栈的迁移过程中。
Gloo可以发现其他种类的终端节点，例如AWS Lambdas。
当您希望混合搭配Kubernetes和无服务器时，这使其成为完美的伴侣。

将Istio用作API网关

API网关和服务网格之间有什么区别？
难道两个都没有做同一件事吗？
两者都提供：

路由流量
验证，例如OAuth，JWT等。
限速
断路器
重试
等等

但是，有一个区别。

诸如Kong和Ambassador之类的API网关主要侧重于处理外部流量并将其路由到集群内部。
外部流量是一个广泛的标签，其中包括：

快速和慢速的客户
行为良好且恶意的用户

换句话说，API网关旨在保护您的应用程序不受外界干扰。

相反，服务网格主要用于观察和保护基础结构中的应用程序。

服务网格的典型用途包括：

监视和观察应用之间的请求
使用加密（相互TLS）保护服务之间的连接
通过断路器，重试等提高弹性

由于服务网格是与您的应用程序一起部署的，因此它们受益于：

低延迟和高带宽
不太可能被滥用

换句话说，服务网格的主要目的是管理内部服务到服务的通信，而API网关主要用于外部客户端到服务的通信。

但这并不意味着您不能将Istio用作API网关。
不过，可能会阻止您的是Istio的首要任务不是处理外部流量。
让我们看一个例子。

通常的做法是，通过JWT或OAuth身份验证在API网关后面保护您的API调用。
Istio提供了JWT，但是您必须在Lua中注入自定义代码才能使其与OAuth一起使用。
另一方面，Kong为此提供了一个插件，因为这是常见的要求。
企业API网关（例如Google Apigee）具有计费功能。
这些功能不太可能在服务网格中复制，因为重点不在管理API上。
如果您不关心计费该怎么办，还可以将服务网格用作API网关吗？
是的，您可以，还有一些您应该知道的事情。

关于API网关和服务网格的一般说明

根据您要实现的目标，服务网格和API网关的功能可能会大大重叠。
由于每个主要的API网关供应商都在扩展到服务网格，因此它们将来可能会重叠得更多。

Kong宣布了Kuma一个可以与Kong或Istio集成的服务网格
http://Solo.io宣布了与Gloo集成的服务网格SuperGloo
Containous宣布Maesh与Traefik集成的服务网格

而且，看到更多服务网格决定像Istio一样启动API网关也就不足为奇了。

总结

如果必须为Kubernetes选择API网关，应该使用哪一个？

如果您需要经过生产验证的API网关，那么Kong仍然是您的最佳选择。它可能不是最光辉的，但是该文档非常有用，在线资源丰富。与其他网关相比，它的生产里程也最多。
如果您需要一个灵活的API网关，可以很好地与新旧基础架构配合使用，则应该看看Gloo。自动发现API和转换请求的能力引人注目。
如果您希望在服务中轻松设置所有网络，则应考虑使用Ambassador。它具有出色的教程和文档入门。请注意，YAML缩进是一个自由字符串。

如果必须选择API网关或服务网格，则应使用哪一个？
从API网关开始仍然是确保内部应用程序不受外部客户端保护的最佳选择。
随着应用程序数量的增加，您可以探索如何利用服务网格来观察，监视和保护它们之间的流量。

PS：本文属于翻译，原文

weixin_39683368

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
wx.request 的get请求支持通过body传json吗?_您可以在Kubernetes中使用API??网关公开微服务吗？...

在Kubernetes中，Ingress是一个组件，可将流量从群集外部路由到群集中的服务和Pod。简而言之，Ingress充当反向代理或负载平衡器：所有外部流量都路由到Ingress，然后路由到其他组件。尽管最受欢迎的Ingress是ingress-nginx项目，但是在选择和使用Ingress时还有其他几种选择。您可以从以下Ingress控制器中选择：处理诸如Contour或Treafik In...
复制链接

扫一扫