微服务，服务注册表，API网关和数据共享 [英] Microservice, service registry, API gateway and data sharing

问题描述

我实际上是在阅读有关微服务体系结构的文章，但是，似乎他们正在以最简单的方式处理这些事情，而无需进行更深入的解释.

I m actually reading tones of articles concerning microservices architecture, but, it seems that they are dealing the things the easiest way possible, without going deeper in explanations.

为了向您解释我的问题，我将向您展示我的实际小体系结构:

To explain you my questions, I will show you my actual little architecture :

所以，这就是我要使用的.在进行技术性制作之前，我需要更多的理论信息.

So, here's what I want to use. Before making anything technically, I need more theoretical informations.

我的域说明

我有一些基于移动和浏览器的客户，他们能够在应用程序上建立联系，获得他们的用户信息，并能够查询有关所购买商品的账单信息.

I have some mobile and browser based customers, able to connect themselves on an application, getting their user informations and able to consult billing informations about what they bought.

在整体应用程序中，我将使用以下架构: -带有Mobile/Angular-Ember的表示层 -带有REST API和NGINX的业务层 -具有标准MySQL数据库的DAL -可扩展性仅适用于X轴

On a monolithic application, I would use this architecture : - Presentation layer with Mobile / Angular-Ember - Business layer with a REST API with NGINX in front of that - DAL with a standard MySQL database - Scalability would be applied only on X-axis

在这种情况下，我想使用微服务架构，因为它是域可扩展的"并且非常灵活(当然，还要进一步了解它).

I want to use a microservice architecture in this case, because it's "domain scalable" and really flexible (and to learn a bit more about it of course).

在架构上，在每个服务中，只有相关API公开的HTTP URL.

On the schema, in each service, there is the only HTTP URL exposed by the API concerned.

问题

a/在(1)流量中，移动"在 http上发送一个http请求. ://myDomain.or/auth .

a/ In the (1) flux, "mobile" send an http request on http://myDomain.or/auth.

在我看来，APIGateway能够询问标准的服务注册表(Eureka，ZooKeeper或其他)能够找到AuthSrv是否可访问并可以检索其网络地址.然后，ApiGateway可以请求AuthSrv并响应服务器

In my mind, the APIGateway is able to ask a standard Service Registry (Eureka, ZooKeeper, or something else) is able to find if a AuthSrv is accessible and can retrieve his network address. Then the ApiGateway can request the AuthSrv and respond to the server

这是使它正常工作的好方法吗?用X机器访问数据时是否没有延迟问题?

Is that a good way to make it work ? Isn't there a latency problem when dealing with X machines to access a data ?

b/通量(2)咨询服务注册表.服务注册中心如何才能理解/auth上的每个请求，甚至是子目录url上的/auth/other之类的请求(如果已公开)都与此地址ip:port上的该服务相关?

b/ The flux (2) consults the service registry. How can the service registry understand that every requests on /auth, even on children url like /auth/other (if it was exposed) are related to this service on this address ip:port ?

c/流量(3)显示服务注册表具有可用的AuthSrv. (3之二)显示另一个:没有AuthSrv可用.在一个很小的应用程序中，我们可以承认我们失去了一段时间的责任感，但是在一个大型系统中，如果有数百个服务链接在一起，我们该如何处理服务不足?

c/ The flux (3) is showing that the service registry has an available AuthSrv. The (3 bis) show the other : no AuthSrv is available. In a little application, we can admit that we lose sometime of disponibility, but in a big system, where hundred of services are linked, how can we handle service deficiency ?

d/在另一篇文章中，我问如何存储帐单信息，因为它与用户，另一项服务和另一个数据库有关.

d/ In an other post, I was asking how to store a billing information because it's related to a user, from another service, and another database.

在标准体系结构中，我将:

In a standard architecture I would have :

{
   billingInformations:{...},
   billingUser:ObjectId("userId")
}

在微服务架构中，建议有人使用:

In a microservice architecture, somebody recommended to use :

{
    billingInformations:{...},
    billingUser:"/user/12365" // URL corresponding the the user Resource in the other service
}

这是处理服务数据共享"而不耦合服务的最佳方法吗?

Is this the best way to handle "service data sharing" and not couple the services ?

e/在这种特定情况下，我什么时候应该更喜欢使用AMQP协议而不是HTTP协议?

e/ When should I prefer using AMQP protocol instead of HTTP protocol in this specific case ?

感谢前进

推荐答案

a/

不，像Zookeeper这样的服务注册中心都在内存中，以确保高吞吐量和低延迟.

No, Service Registries like Zookeeper are in-memory guaranteeing high throughput and low latency.

b/

在诸如Zookeeper之类的服务注册表中，您可以创建文件系统路径，例如注册服务.例如/App1/Service1和/App1/Service2

In Service Registries like Zookeeper you can make filesystem path like registering of services. For example /App1/Service1 and /App1/Service2

c/

不太清楚是什么问题.

d/

有人推荐的模式是 HATEOAS 模式，建议对API进行响应.

The pattern recommended by somebody is the HATEOAS pattern which is recommended for API response.

e/

仅当服务之间需要通信时才需要AMQP.永远不要直接从一个服务直接调用另一个服务的API.

AMQP is only required when communication required in between Services. Should never directly call the API of another service directly from one service.

编辑

c/

在这种情况下，您需要实现后备逻辑.例如，如果服务不可用，超时或任何其他故障，则需要采取一些措施. Netflix的 Hystrix 之类的工具有助于实现这一目标.

In that case you need to implement fallback logic. For example if a service is not available, times out or any other failure some actions need to be taken. Tools like Netflix's Hystrix helps to achieve this.

e/

通信模式必须对称而不是非对称.就像下面一样，

The communication pattern must be symmetric not asymmetric. Just like below,

此模式将允许微服务之间的松散耦合，从而实现灵活性.

This pattern will enable loose coupling between microservices thus enabling flexibility.

这篇关于微服务，服务注册表，API网关和数据共享的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！