Microservice, service registry, API gateway and data sharing

Question

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.

Description of my domain

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.

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).

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

Questions

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

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

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/ 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/ 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/ 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/ When should I prefer using AMQP protocol instead of HTTP protocol in this specific case ?

Thanks for advance

Answer 1

a/

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

b/

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

c/

Not really clear what is the problem is.

d/

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

e/

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

EDIT

c/

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.