我是API网关的新手，有一个理解上的问题. 我也尝试在端点后面放置一系列(微)服务.
为此，我建立了一个ASP.NET Core应用程序并添加了软件包 ThreeMammals Ocelot . 借助文档，我已经配置了上游和下游. 到目前为止，一切都很好.
客户端向 mygateway:4242/s1/ {api}发出请求，例如，按预期从Service1获取JSON或XML响应.
mygateway:4242/s2/ {api}的行为相同，并且具有预期结果！
我的理解问题在于Service3. 当我向 mygateway/s3/发送请求时，得到的是index.html作为响应.
index.html本身通过链接标签需要CSS文件'xyz.css'，并强制客户端加载文件.
<head> <link rel="stylesheet" type="text/css" href="xyz.css"> </head>在这种情况下，客户端发送到"mygateway"的请求URL为 mygateway:4242/xyz. css 而不是 mygateway:4242/ s3 /xyz.css，因此响应是找不到404，因为"mygateway"对"xyz.css"一无所知
如何解决此路由(?)问题?
是否可以使用ocelot中间件解决此问题?还是我需要带有SinglePageApplication(SPA)的服务(Service3)的其他东西?
将SPA放置在网关后面也许根本就是不可能或错误吗? 希望您能给我一些提示，以使您能够访问网关后面的SPA或MVC网站.
感谢iBot
更新: 随附了index.html的代码.我认为这很简单.
<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Title</title> <base href="/" /> <link rel="stylesheet" type="text/css" href="dist/xyz.css"> </head> <body> <div id="appContainer"></div> <script src="dist/xyz.js" asp-append-version="true"></script> </body> </html>解决方案
您的架构设计错误！
首先，让我们找出这是什么API网关.
API网关是一种位于应用程序编程接口( API )，并充当已定义微服务组的单个入口点.
使用API网关的主要好处是，它们允许开发人员根据用例以多种方式封装应用程序的内部结构.这是因为，除了可以容纳直接请求之外，网关还可以用于调用多个后端服务并汇总结果.
好吧，名称" API 网关"向我们表明它主要用于API服务！ SPA或MVC应用程序不是后端服务.您不应将前端应用程序放在api网关后面.
通常，您的体系结构应如下所示:
API网关是所有客户端的单个入口点. SPA是您的服务的客户端，应通过API网关调用它.如果您的应用程序具有多个客户端应用程序，那么在识别多种API网关类型时，这可能是主要的枢纽，因此您可以为每个客户端应用程序的需求使用不同的外观.这种情况是一种名为后端的后端"(BFF)的模式，其中每个API网关都可以提供为每种客户端应用类型量身定制的不同API.
如果您不想构建合适的体系结构怎么办?
I am new to API gateways and have a question of understanding. I try too put a series of (micro)services behind an endpoint.
For this purpose, I have set up an ASP.NET Core Application and added the package ThreeMammals Ocelot. With the help of documentation I have configured the Up- and Downstreams. So far, so good.
The client makes a request to mygateway:4242/s1/{api} and, for example, get a JSON or XML response from Service1, as expected.
Same behavior for mygateway:4242/s2/{api} with also the expected result!
My understanding problem is with Service3. When I send a request to mygateway/s3/, I get the index.html as response.
The index.html itself requires the CSS-File 'xyz.css' via link-tag and forces the client to load the file.
<head> <link rel="stylesheet" type="text/css" href="xyz.css"> </head>The request URL the client send to "mygateway" in this case is mygateway:4242/xyz.css and not mygateway:4242/s3/xyz.css and so the respone is a 404 not found, since the "mygateway" knows nothing about a "xyz.css"
How can I fix this routing(?) issue?
Is it possible to solve this problem with ocelot middleware? Or do I need something else for the service (Service3) with the SinglePageApplication (SPA)?
Maybe is it simply not possible or wrong to place the SPA behind the gateway? I hope you can give me some tips to get access to a SPA or MVC website behind a gateway.
Thanks iBot
UPATE: Enclosed the code of index.html. I think that's straight forward.
<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Title</title> <base href="/" /> <link rel="stylesheet" type="text/css" href="dist/xyz.css"> </head> <body> <div id="appContainer"></div> <script src="dist/xyz.js" asp-append-version="true"></script> </body> </html>解决方案
Your architecture design is wrong!
First, let's find out what this the API Gateway.
An API Gateway is programming that sits in front of an application programming interface (API) and acts as a single point of entry for a defined group of microservices.
A major benefit of using API gateways is that they allow developers to encapsulate the internal structure of an application in multiple ways, depending upon use case. This is because, in addition to accommodating direct requests, gateways can be used to invoke multiple back-end services and aggregate the results.
Ok, the name "API Gateway" shows us that it is mostly intended for API services! SPA or MVC applications are not back-end services. You should not put your front-end applications behind the api gateway.
In general, your architecture should look like this:
An API gateway is the single entry point for all clients. SPA is client of your services and should call it through API Gateway. If your application has multiple client apps, that can be a primary pivot when identifying the multiple API Gateways types, so that you can have a different facade for the needs of each client app. This case is a pattern named "Backend for Frontend" (BFF) where each API Gateway can provide a different API tailored for each client app type.
What if you don't want to build a proper architecture?
更多推荐
ASP.NET Core Api
发布评论