本文将为您提供关于几种部署GokuAPIGateway的方式，最快一分钟可使用上网关的详细介绍，我们还将为您解释gateway搭建网关的相关知识，同时，我们还将为您提供关于.netcore微服务之Ap
本文将为您提供关于几种部署 Goku API Gateway 的方式，最快一分钟可使用上网关的详细介绍，我们还将为您解释gateway搭建网关的相关知识，同时，我们还将为您提供关于.net core 微服务之 Api 网关（Api Gateway）、5分钟了解Kubernetes Ingress和Gateway API、API Gateway 作为 DynamoDB 代理 - API Gateway 中的更改响应、API Gateway 是否可以将 a 指向 Web 服务 (SOAP)，或者可以在微服务中使用 SOAP 以便 API Gateway 指向它？的实用信息。
本文目录一览：- 几种部署 Goku API Gateway 的方式，最快一分钟可使用上网关（gateway搭建网关）
- .net core 微服务之 Api 网关（Api Gateway）
- 5分钟了解Kubernetes Ingress和Gateway API
- API Gateway 作为 DynamoDB 代理 - API Gateway 中的更改响应
- API Gateway 是否可以将 a 指向 Web 服务 (SOAP)，或者可以在微服务中使用 SOAP 以便 API Gateway 指向它？
几种部署 Goku API Gateway 的方式，最快一分钟可使用上网关（gateway搭建网关）
本文将介绍几种部署 Goku API Gateway 的方式，最快一分钟可使用上为网关，详情请看全文。
什么是 Goku API Gateway？
Goku API Gateway （中文名：悟空 API 网关）是一个基于 Golang 开发的运行在企业系统服务边界上的微服务网关。当您构建网站、App、IOT 甚至是开放 API 交易时，Goku API Gateway 能够帮你将内部系统中重复的组件抽取出来并放置在 Goku 上运行，如进行用户授权、访问控制、防火墙、数据转换等；并且 Goku 提供服务编排的功能，让企业可以快速从各类服务上获取需要的数据，对业务实现快速响应。
Goku API Gateway 的社区版本（CE）拥有完善的使用指南和二次开发指南，代码使用纯 Go 语言编写，拥有良好的性能和扩展性，并且内置的插件系统能够让企业针对自身业务进行定制开发。使用 Goku API Gateway 能让业务开发团队更加专注地实现业务。
一套完整的 Goku API Gateway 由一个 控制台 和 若干个 网关节点 组成。节点通过 IP 地址注册在控制台中，控制台内的配置项会对所有节点生效。控制台用于配置网关的运行信息，例如访问策略、转发的 API 信息等等；节点用于实际的转发。当控制台上发布了最新的配置，所有节点都会主动更新自己的运行配置；在控制台发布的配置支持版本管理，可以手动发布和回滚。
Goku API Gateway 支持管理多个网关节点的集群，实现让用户访问不同的集群从而访问不同的服务地址的目的。
下面是以两个 DC（Data Center）为例的部署架构简图： 
Goku 的网关节点除了能够直接获取控制台的配置外，也支持采用直接读取配置文件的方式来使用。配置文件可以通过 EOLINKER 官方提供的线上控制台来导出，线上控制台可让用户方便修改配置，修改完后导出配置文件，放到节点的服务器上即可。
线上控制台地址：http://goku-console.eolinker.com
使用线上控制台的话无法区分不同集群，如需使用更强功能建议还是部署自己的私有云控制台。
本文给出几种 Goku API Gateway 的部署方式：
一、节点 docker + 线上控制台
二、节点 docker + 线上控制台 Docker
三、使用安装包直接安装
部署安装时需要用到的链接：
- 节点 Docker：https://hub.docker.com/r/eolinker/goku-api-gateway-ce-node
- 控制台 Docker：https://hub.docker.com/r/eolinker/goku-api-gateway-ce-console
- 线上控制台：http://goku-console.eolinker.com
- 安装包地址：https://github.com/eolinker/goku-api-gateway
一、节点 Docker + 线上控制台
Goku API Gateway 提供节点 Docker 和控制台 Docker，最快的方式就是仅部署节点 Docker，然后通过线上控制台来配置网关信息，配置完成后导出文件并上传到节点服务器，最后启动节点 Docker。
使用步骤
1、配置完毕后，在线上控制台的首页导出配置： 
2、将配置上传到服务器，启动 docker：
docker run -dt -p {转发端口号}:6689 \
-v {日志挂载地址}:/app/goku-ce/node/work \
-v {配置文件地址}:/app/goku-ce/node/work/goku-node.json \
eolinker/goku-api-gateway-ce-node
完整配置示例如下：
docker run -dt -p 6689:6689 \
-v /app/goku-ce/node/work:/app/goku-ce/node/work \
-v /app/goku-ce/node/versionConfig_b14a1af4-b961-4dfb-8bfe-d4d157dd651e.json:/app/goku-ce/node/work/goku-node.json \
eolinker/goku-api-gateway-ce-node
用户通过网关访问 API 地址为：{{节点 IP: 端口}}/{{转发 URL}} 。
二、节点 Docker + 控制台 Docker
（一）部署控制台
1、 创建 goku-ce 专属网络
docker network create --driver bridge --subnet=172.18.12.0/24 --gateway=172.18.12.1 goku-ce
2、运行控制台程序
docker run -dt -p {浏览器访问端口号}:7000 \
-v {sqlite数据库挂载地址}:/app/goku-ce/console/work \
-e GOKU_ADMIN_PASSWORD={控制台admin密码} \
--network=goku-ce \
--ip 172.18.12.2 \
--name goku-ce-console \
eolinker/goku-api-gateway-ce-console
完整示例启动如下：
docker run -dt -p 7000:7000 \
-v /app/goku-ce/work:/app/goku-ce/console/work \
-e GOKU_ADMIN_PASSWORD=123456 \
--network=goku-ce \
--ip 172.18.12.2 \
--name goku-ce-console \
eolinker/goku-api-gateway-ce-console
3、 登录控制台
打开浏览器，输入 域名 / IP + 浏览器访问端口号，进入控制台页面，输入用户名（admin）及密码（启动设置的 admin 密码）进行登录: 
（二）部署网关节点
1、进入控制台，新建节点
节点 IP 需要和启动节点 docker 容器时绑定的 IP 一致： 
点击查看 新建节点详细教程
2、在控制台生成并发布配置
发布配置后，节点会读取控制台的最新配置来运行。
点击查看 发布配置的教程链接
3、启动节点 docker 容器
docker run -dt -p {转发端口号}:6689 \
--network goku-ce \
--ip {节点IP} \
-v {日志挂载地址}:/app/goku-ce/node/work \
-e GOKU_ADMIN_ADDRESS={控制台IP}:7005 \
eolinker/goku-api-gateway-ce-node
完整示例如下：
docker run -dt -p 6689:6689 \
--network goku-ce \
--ip 172.18.12.3 \
-v /app/goku-ce/work:/app/goku-ce/node/work \
-e GOKU_ADMIN_ADDRESS=172.18.12.2:7005 \
eolinker/goku-api-gateway-ce-node
4、查看节点运行状态
进入节点管理页面，若节点的状态显示为运行中，则节点正常启动： 
三、通过安装包直接部署
安装准备：到 Github 上下载最新的 Release 包。
项目地址：https://github.com/eolinker/goku-api-gateway
（一）安装控制台
1、安装命令:
mkdir -p {install dir} mv console-{version}.tar.gz {tmp}/ cd {tmp}/ tar -xzf console-{version}.tar.gz cd console-{version} && ./install.sh {install dir} cd {install dir}
2、首次安装进入 {install dir}/console/config 文件夹，编辑配置文件内容，配置语法参照 yaml。
goku.conf 如下：
admin_bind: 绑定节点获取配置的地址，形如 IP:Port，填写内网地址或本机地址 listen_port: 管理后台监听端口，可以开放给外网访问 db_type: 数据库类型，v3.1.0 只支持 sqlite db_path: sqlite db 的文件路径
3、进入 {install dir}/console 文件夹，运行 run.sh 文件以启动控制台。
首次运行：
./run.sh start {config file} 管理员账号 管理员密码
示例：
./run.sh start config/goku.conf admin 123456
非首次运行：
./run.sh start|restart
4、在浏览器输入服务器 IP + 程序监听端口号，进入控制台页面
注：程序监听端口号为 goku.conf 的配置项 listen_port 的值
（二）、节点安装
1、安装命令：
mkdir -p {install dir}
mv goku-node-{version}.tar.gz {tmp}/
cd {tmp}/
tar -xzf goku-node-{version}.tar.gz
cd goku-node-{version} && ./install.sh {install dir}
cd {install dir}
2、在控制台新建节点
（1）登录控制台，一级菜单选择 网关节点，创建集群： 
（2）进入相应的集群，为不同集群 添加节点： 
（3）点击 新增节点 按钮，填写节点信息后点击 确定：
- 新建节点时的节点 IP 字段填写内网 IP 或本地 IP
- 若配置文件（goku.conf）中的 admin_bind 字段值 IP 部分为 127.0.0.1 或 localhost，此处节点 IP 必须填写 127.0.0.1
3、启动节点程序：
{install dir}/run.sh {start|stop|reload|restart|force-reload} [admin url] [port]
此处的 admin url 值与配置文件（goku.conf）中的 admin_bind 字段值一致。
示例：
{install dir}/run.sh start 127.0.0.1:7005 7702
4、检查节点是否正常运行：
进入控制台的网关节点页面，若节点的状态显示为运行中，则节点正常启动： 
最后，你也可以通过编译 Github 上 Master 分支的代码，编译最新的内容来安装，编译教程：https://help.eolinker.com/#/tutorial/?groupID=c-372&productID=19
相关链接
节点 Docker：https://hub.docker.com/r/eolinker/goku-api-gateway-ce-node
控制台 Docker：https://hub.docker.com/r/eolinker/goku-api-gateway-ce-console
新上控制台：http://goku-console.eolinker.com
项目地址：https://github.com/eolinker/goku-api-gateway
项目官网：https://www.eolinker.com
原文出处：https://www.cnblogs.com/dc20181010/p/11821475.html
.net core 微服务之 Api 网关（Api Gateway）
原文: .net core 微服务之 Api 网关（Api Gateway）
微服务网关目录
- 1、 微服务引子
- 2、使用 Nginx 作为 api 网关
- 3、自创 api 网关（重复轮子）
- 3.1、构建初始化
- 3.2、构建中间件
- 4、结语
- 引用链接
1、 微服务引子
首先恭喜你，进入微服务的开发世界。微服务属于架构演进中的一种阶段，其特点是根据业务模块水平划分服务种类，每个服务可以独立部署并互相隔离，并对外提供轻量的 Api 调用，服务具有高可用特性。
微服务应遵循的设计原则：
- 单一职责原则： 每个微服务只需要实现自己的业务逻辑
- 服务自治原则： 每个微服务都是独立的，不依赖其他模块
- 轻量级通信原则：一般采用 Http + Json 方式
- 接口明确原则：接口尽量做的更通用，更灵活，从而尽量避免接口参数的来回修改。
我从 2017 年 12 月开始接触微服务概念，并开始着手构建公司的微服务平台，系统架构采用 .net core webapi 方式组织，随着微服务的增多，越来越需要一个统一入口管理这些微服务。
2、使用 Nginx 作为 api 网关
Nginx 是由 IgorSysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，一个高性能的 HTTP 和反向代理服务器。2012 年，Nginx 荣获年度云计算开发奖，并成长为世界第二大 Web 服务器。全世界流量最高的前 1000 名网站中，超过 25% 都使用 Nginx 来处理海量的互联网请求。
Nginx 很牛掰，业界公认的首选，选择它作为 api 网关，可以说不用开发介入，只需要运维的同学好好规划配置即可。
网关配置规划如下：
/api/ServiceA —> ServiceA
/api/ServiceB —> ServiceB
/api/ServiceC —> ServiceC
外部统一的访问入口是 Nginx，然后根据服务名称路由到不同的微服务站点。
api 网关的路由难题解决了，其他熔断，灰度发布，线上测试，日志拦截等功能 nginx 做起来相对比较吃力，不过对于中小型平台已经够用了。
3、自创 api 网关（重复轮子）
半年后，换了家公司，公司微服务平台搭建采用 Thrift RPC 作为各个微服务的通讯协议，由于当时的无知（Socket 协议已被 Nginx 支持），所以决定写个 Api 代理类，没敢叫 Api 网关，是因为实现的功能仅限于路由！
仅仅是路由，当然是祭出 .net core Web 应用。
3.1、构建初始化
MVC 框架包就别包含了，轻量的性能才能好！
Main 函数初始化线程池大小
//初始化线程池最小大小 为 300
ThreadPool.GetMinThreads(out var wt, out var ct);
if (wt < 300 || ct < 300)
{
ThreadPool.SetMinThreads(Math.Max(wt, 300), Math.Max(ct, 300));
}
** 注意：** 线程池不是越大越好，最佳选择约等于 cpu 内核的 2 倍，有个公式参考：
多说一句吧，思考下：
为什么 Nginx 只用 4 个线程发挥出的性能就大大超越了 100 个进程的 Apache HTTPD？回想一下计算机科学的基础知识，答案其实是很明显的。
我要支持跨域访问：
public void ConfigureServices(IServiceCollection services)
{
services.AddCors(options =>
{
options.AddPolicy("AllowAll", p => p.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader().AllowCredentials());
});
}
配置下使用中间件
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseCors("AllowAll");
app.UseMiddleware<ProxyMiddleware>();
// app.UseMvc();
}
3.2、构建中间件
路由转发，一个中间件即可搞定。
public class ProxyMiddleware
{
private readonly RequestDelegate m_Next;
public ProxyMiddleware(RequestDelegate next)
{
this.m_Next = next;
}
public Task Invoke(HttpContext context)
{
if (context.Request.Method?.ToUpper() == "GET")
{
var path = context.Request.Path.HasValue ? context.Request.Path.ToString().ToLower() : string.Empty;
if (string.IsNullOrEmpty(path) || path.Equals("/") || path.Equals("/api") || path.Equals("/api/"))
{
return this.SendConstRespond(context);
}
//增加一个代理网关接口，返回微服务列表
else if (path.EndsWith("/getallservices"))
{
return this.SendServiceListRespond(context);
}
return this.SendStringRespond(context);
}
if (context.Request.ContentType == null || context.Request.ContentType.IndexOf("application/json") < 0)
{
context.Response.StatusCode = 403;
context.Response.ContentType += "application/json;charset=utf-8;";
return context.Response.WriteAsync("Please set ContentType=application/json");
}
return this.SendStringRespond(context);
}
private Task SendStringRespond(HttpContext context)
{
context.Response.StatusCode = 200;
context.Response.ContentType += "application/json;charset=utf-8;";
Task task = new Task(() =>
{
if (ServerSetting.Config.QuantumConfig.RpcService.ServerType==ServerType.HttpWebApi)
{
string constResp = QuantumHttpProxy.SendHttp(context);
using (var strStream = new StreamWriter(context.Response.Body))
{
strStream.Write(constResp);
strStream.Flush();
}
}
else
{
QuantumHttpProxy.Send(context);
}
});
task.Start();
return task;
}
private Task SendConstRespond(HttpContext context)
{
context.Response.StatusCode = 200;
context.Response.ContentType += "application/json;charset=utf-8;";
Task task = new Task(() =>
{
var constResp = new
{
rid = string.Empty,
c = 200,
msg = "Access api gateway success!"
};
using (var strStream = new StreamWriter(context.Response.Body))
{
strStream.Write(JsonConvert.SerializeObject(constResp));
strStream.Flush();
}
});
task.Start();
return task;
}
private Task SendServiceListRespond(HttpContext context)
{
context.Response.StatusCode = 200;
context.Response.ContentType += "application/json;charset=utf-8;";
Task task = new Task(() =>
{
var svrs = ServerSetting.Config?.HttpProxy?.Items?.Select(x => x.Name)?.ToList() ?? new List<string>();
var constResp = new
{
rid = Guid.NewGuid().ToString("N"),
c = 200,
v = svrs,
};
using (var strStream = new StreamWriter(context.Response.Body))
{
strStream.Write(JsonConvert.SerializeObject(constResp));
strStream.Flush();
}
});
task.Start();
return task;
}
}
上面的代码里 有 QuantumHttpProxy，是我们封装的 rpc 调用，因此各位同学要用此类，请自行修改之。
4、结语
没有重试，熔断也没有降级，是否很 low？
这就是实际实践的力量，不必耗费太多精力在一些非关键点上！
好吧，我承认我研究了 **polly** 类库，重试，熔断，降级都准备好了，你就起航吧～～～
另外：造轮子只适合特定场景，小投入就可以完成的某些特定功能，比如上面的路由功能！如果你是云服务，可以重点考虑下 阿里 API 网关，亚马逊 api 网关！
引用链接
- 口袋代码仓库
- 在线计算器
- 本节源码：github
5分钟了解Kubernetes Ingress和Gateway API
了解Kubernetes Ingress和Gateway API之间的差异，以实现有效的流量管理。原文: Kubernetes Ingress Vs Gateway API
概述
Kubernetes如今被广泛应用于容器管理、微服务编排解决方案。对于如何控制微服务的入口流量，Kubernetes提供了两种选择: Ingress和Gateway API。这篇文章将对比Ingress API和Gateway API，比较两者各自的适用场景。
2022年5月份Kubernetes Gateway API才发布了Beta版本，当前大多数组织应该还在使用稳定的Ingress API。
- 为什么需要新的API来管理入口流量?
- 新的Gateway API解决了Ingress API的哪些缺点?
本文将介绍Ingres API和Gateway API之间的区别和应用。
通过Ingress公开服务
Kubernetes Ingress定义了如何将外部流量定向到集群内部的服务。作为负载均衡器，处理来自集群外部的请求，发送给集群内运行的适当服务。定义入口规则的YAML文件描述了一组基于主机名或URL路径的流量路由指南，基本设置和示例可参考Kubernetes Ingress with NGINX Ingress Controller Example一文。
只有在K8s集群中运行Ingress控制器，才能使ingress资源生效。
Kubernetes有很多不同的Ingress控制器，参考Kubernetes Additional controllers。
本文将以Nginx ingress及其ingress控制器为例。
通常在创建ingress类的同时创建ingress。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-example
spec:
rules:
- host: sub.example.com
http:
paths:
- path: /auth
pathType: Prefix
backend:
service:
name: http-echo-server
port:
number: 8080
- path: /api
pathType: Prefix
backend:
service:
name: api-svc
port:
number: 9090
ingressClassName: nginx以上代码是基于路径路由的一个简单的ingress示例，/auth请求重定向到http-echo-server服务，而/api请求重定向到api-svc。
根据ingressClassName的值，特定的ingress控制器将管理ingress对象。
对于ingress对象，唯一可配置的字段是SSL/TLS密钥，其他配置就只能通过annotations实现，比如路径重写、代理消息体和头域。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-myservicea-two
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /uat/$2
spec:
rules:
- host: sub.example.com
http:
paths:
- path: /auth/api(/|$)(.*)
pathType: Prefix
backend:
service:
name: http-echo-server
port:
number: 8080
ingressClassName: nginx上面的配置将/auth/api/example/1这样的URL路径重写为/uat/example/1。
Nginx ingress控制器不支持任何CRD，然而，GCE的ingress提供了各种各样的CRD，与注释相比，CRD可以支持灵活的路由配置。
以下是一个CRD示例，来自GCE ingress的BackendConfig，参考文档Parameters from a BackendConfig CRD。
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: http-hc-config
spec:
healthCheck:
checkIntervalSec: 15
port: 15020
type: HTTPS
requestPath: /healthzGCE ingress的ManagedCertificate也是一个CRD对象的好例子。
Gateway API
Ingress提供了某些字段配置，通过annotations进行配置也很有挑战性。Ingress API是管理传入流量的单个对象，但由于它是整个集群共享的单一资源，因此集群开发人员可以访问或修改，而集群/基础设施团队对此却一无所知。
资源 ——GatewayClass、Gateway、HTTPRoute、TCPRoute、Service等，旨在通过表达性的、可扩展的、面向角色的接口来定义Kubernetes服务网络，接口由众多供应商提供实现，并拥有广泛的行业支持。
Gateway API在Ingress API的基础上增加了更多特性，例如HTTP头匹配、加权流量分割、多协议支持(如HTTP、gRpc)以及其他各种后端功能(如桶、函数)。
kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
metadata:
name: bar-route
namespace: bar
labels:
gateway: external-https
spec:
hostnames:
- "bar.example.com"
rules:
- forwardTo:
- serviceName: bar-v1
port: 8080
weight: 90
- serviceName: bar-v2
port: 8080
weight: 10
- matches:
- headers:
values:
env: canary
forwardTo:
- serviceName: bar-v2
port: 8080另外，Gateway API比Ingress API更好的分离了关注点。使用Ingress，集群运维人员和应用开发人员在同一个Ingress对象上操作，却不知道彼此的角色，可能会导致设置错误。
Route和Gateway对象是由Gateway API独立于配置创建的，从而为集群运维人员和应用开发人员提供了自主权。
如果需要解耦角色，就可以改为使用Gateway API(仍处于测试阶段)。如果需求比较简单，并且对Nginx ingress或任何其他ingress控制器感到满意，那么最好坚持用下去，直到需要更多灵活性或支持特定的配置要求。
你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。微信公众号：DeepNoMind
本文由mdnice多平台发布
API Gateway 作为 DynamoDB 代理 - API Gateway 中的更改响应
如何解决API Gateway 作为 DynamoDB 代理 - API Gateway 中的更改响应？
我正在使用 AWS API Gateway 直接向 DynamoDB 表（没有 Lambda）发出 Delete 请求。
它有效，但总是返回状态 200，即使该项目在开始时不存在。
我想更改回复：
- 如果项目存在并被删除 -> 状态 200 响应
- 如果项目不存在 -> 状态 404 响应
通过使用以下映射模板更改 API Gateway 控制台中的集成响应，我能够更改 Get 请求的响应：
#set($inputRoot = $input.path(''$''))
$input.json("$")
#if(!$inputRoot.toString().contains("Item"))
#set($context.responSEOverride.status = 404)
#end
我正在检查响应是否包含“Item”，如果不包含则返回 404。这可能不是最干净的方法，因为检查错误消息会更好，但我在响应中找不到错误消息来自 Dynamo，所以我用这个技巧来检查一个 Item 是否在 body 中返回。它有效。
我的 DeleteItem 问题 -> 它总是返回 200 并带有 空体！至少我无法在我的映射模板中使用的响应中找到任何错误消息或任何其他属性。 还是我在此回复中遗漏了什么？：
Mon Dec 28 14:13:55 UTC 2020 : Sending request to https://dynamodb.eu-central-1.amazonaws.com/?Action=DeleteItem
Mon Dec 28 14:13:55 UTC 2020 : Received response. Status: 200,Integration latency: 12 ms
Mon Dec 28 14:13:55 UTC 2020 : Endpoint response headers: {Server=Server,Date=Mon,28 Dec 2020 14:13:55 GMT,Content-Type=application/x-amz-json-1.0,Content-Length=2,Connection=keep-alive,x-amzn-RequestId=SFFGMNCHC80JDNT6MSJ1N1SIORVV4KQNSO5AEMVJF66Q9ASUAAJG,x-amz-crc32=2745614147}
Mon Dec 28 14:13:55 UTC 2020 : Endpoint response body before transformations: {}
Mon Dec 28 14:13:55 UTC 2020 : Method response body after transformations:
Mon Dec 28 14:13:55 UTC 2020 : Method response headers: {X-Amzn-Trace-Id=Root=1-5fe9e823-89a49250c7e12b524ac89e38,Content-Type=application/json}
Mon Dec 28 14:13:55 UTC 2020 : Successfully completed execution
Mon Dec 28 14:13:55 UTC 2020 : Method completed with status: 200
无论项目是否存在，dynamodb 总是返回：
Mon Dec 28 14:13:55 UTC 2020 : Endpoint response body before transformations: {}
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）
API Gateway 是否可以将 a 指向 Web 服务 (SOAP)，或者可以在微服务中使用 SOAP 以便 API Gateway 指向它？
如何解决API Gateway 是否可以将 a 指向 Web 服务 (SOAP)，或者可以在微服务中使用 SOAP 以便 API Gateway 指向它？？
所以我使用的是 dotnet core 3.1，并与需要访问 Web 服务的客户端一起工作。我想知道是否可以使用/集成 API 网关架构，以便 API 网关指向该 Web 服务（SOAP 消息）？我正在研究，当然首选是使用 Ocelot，但我仍处于检查可行性的阶段。这里需要考虑的重要一点是，我使用 API Gateway 方法的原因是因为会有其他端点（其他客户端）确实需要它，因此将微服务与这些端点一起使用会更容易，包括所有RestAPI 和整个所有shebang...
我不太熟悉的另一件事是，是否可以将 Web 服务容器化为微服务以实现目标。
感谢您的回复。
干杯！！！
此外，如果有更好的方法来解决这个问题，我非常愿意“听到”它
这里有一张图片可以提供更好的参考，请记住，其中一个微服务不是 Web API，而是 SOAP Web 服务
解决方法
从架构的角度来看，您当然可以在微服务和 SOAP 服务 if it makes sense to do so 之前放置一个网关。
如果您将 SOAP 网络服务包装到一个与所有其他微服务具有类似通信类型的微服务中，或者如果您只是直接调用您的 SOAP 网络服务，则取决于网关实现。网关（您的示例：ocelot）可以进行 SOAP 调用吗？还是所有后端服务都需要使用相同的“语言”进行通信？
从架构的角度来看，您的解决方案有意义且可行。这只是您如何“按摩”组件之间的通信的问题，这样网关的客户端就不必关心他们的请求是到达微服务还是 SOAP 网络服务。
附言我在这里谈论 SOAP 服务和“其他”微服务以突出它们与网关之间的不同集成类型，但您当然可以仅使用 SOAP 构建微服务架构。您可以从 SOAP 服务和 REST 服务（这似乎是构建微服务的首选方式；主要是由于历史原因，因为 SOAP 经常被用作与单体的集成选项）。
,我会以咆哮的形式回答。
<rant> 所以我对此类事情的建议是，做对你和你的公司有用的事情。 “霸主”可能会讨厌我说你可以在你的微服务实现中使用基于肥皂的产品，但他们不必支持你的系统，你做。做有意义的事。我使用 OSB 之类的转换将 SOAP 转换为 ReST，我使用了翻译服务，您不能将技术决策视为是/否。它们必须是对您和您的需求有意义的权衡。 </rant>
关于几种部署 Goku API Gateway 的方式，最快一分钟可使用上网关和gateway搭建网关的问题我们已经讲解完毕，感谢您的阅读，如果还想了解更多关于.net core 微服务之 Api 网关（Api Gateway）、5分钟了解Kubernetes Ingress和Gateway API、API Gateway 作为 DynamoDB 代理 - API Gateway 中的更改响应、API Gateway 是否可以将 a 指向 Web 服务 (SOAP)，或者可以在微服务中使用 SOAP 以便 API Gateway 指向它？等相关内容，可以在本站寻找。
本文标签：
