本文是小编为大家收集整理的关于Api网关和共享服务模式的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
我的问题的简短版本是，我正试图围绕模型如何在 API 网关和内部微服务之间"共享".我假设网关可以负责转换对多个服务的调用并返回数据的新聚合表示.网关如何知道微服务的可用模型?
在我的简单示例中.我有:
- API 网关
- 用户服务
- 餐厅服务
用户服务
这个休息服务会暴露一个 /api/users 端点
型号
{
"id": 12345,
"name": "Joe Bloggs",
"e-mail": "joe@bloggs.com",
"lastloggedin": "05/10/2017"
}
餐厅服务
这个休息服务会暴露一个 /api/dishes 端点
型号
{
"dishes": [
{
"userId": 12345,
"isActive": true,
"type": "italian",
"sub-types": [
"pizza",
"pasta"
]
},
{
"userId": 12345,
"isActive": false,
"type": "american",
"sub-types": [
"burgers",
"steaks"
]
}
]
}
API 网关
API 网关可以允许某人调用 /api/user/12345/dishes 或 /api/dishes，它会为厨师返回菜肴.以及一些基本的用户详细信息.
型号
{
"cook": "Joe Bloggs",
"lastloggedin": "05/10/2017",
"dishes": [
{
"type": "italian",
"sub-types": [
"pizza",
"pasta"
]
}
]
}
此时.我已经确定了 3 个模型(即 C# 类).2 来自内部服务，1 用于从 API 网关返回的数据的新表示.我不确定 API 网关如何知道用户和餐厅服务模型，而无需将这些模型直接耦合到 API 网关.本质上是在网关和微服务之间共享代码，我认为这是不可取的.
推荐答案
我不确定 API 网关如何知道用户和餐厅服务模型，无需将这些模型直接耦合到API 网关也是如此
API 网关就是这样:网关.
根据EAA的P，网关定义为:
<块引用>封装对外部系统或资源的访问的对象.
所以网关是关于访问的.网关并没有说它需要关心暴露在它上面的类型.事实上，通过服务公开的类型与网关本身之间没有耦合，至少在设计时是这样.
API 网关，例如 Ocelot，将愉快地处理请求中的任何类型并传递它们通过下游服务.如果您更改服务类型，那太好了！您无需更改网关.它会继续工作，就像什么都没发生一样.
问题描述
The short version of my question is that I'm trying to wrap my head around how models are "shared" between an API Gateway and internal microservices. I assume that the gateway can be responsible for transforming calls to multiple services and returning a new aggregated representation of the data. How does the gateway know about the available models from the microservices?
In my simple example. I have:
- API Gateway
- User Service
- Restaurant Service
User Service
This rest service would expose an /api/users endpoint
Model
{
"id": 12345,
"name": "Joe Bloggs",
"e-mail": "joe@bloggs.com",
"lastloggedin": "05/10/2017"
}
Restaurant Service
This rest service would expose an /api/dishes endpoint
Model
{
"dishes": [
{
"userId": 12345,
"isActive": true,
"type": "italian",
"sub-types": [
"pizza",
"pasta"
]
},
{
"userId": 12345,
"isActive": false,
"type": "american",
"sub-types": [
"burgers",
"steaks"
]
}
]
}
API Gateway
The API Gateway could allow for someone to call /api/user/12345/dishes or /api/dishes and it would return dishes for cooks. Along with some basic user details.
Model
{
"cook": "Joe Bloggs",
"lastloggedin": "05/10/2017",
"dishes": [
{
"type": "italian",
"sub-types": [
"pizza",
"pasta"
]
}
]
}
At this point. I've identified 3 models (i.e. C# classes). 2 from the internal services and 1 for the new representation of the data being returned from the API Gateway. I am unsure as to how the API Gateway knows about the User and Restaurant service models without coupling those models directly to the API Gateway as well. Essentially sharing code between the Gateway and the Microservices, which I believe is not desirable.
推荐答案
I am unsure as to how the API Gateway knows about the User and Restaurant service models without coupling those models directly to the API Gateway as well
An API gateway is just that: A gateway.
According to P of EAA, a gateway is defined as:
An object that encapsulates access to an external system or resource.
So the gateway is about access. There is nothing about a gateway which says it needs to care about the types being exposed over it. In fact, there is no coupling between the types exposed over your service and the gateway itself, at least at design-time.
An API gateway, such as Ocelot, will happily handle any types in the request and pass them through to the downstream service. If you change the service types, great! You don't need to change the gateway. It will continue working as if nothing happened.
更多相关问答
联系站长