Microservice, rejestr usług, bramka API i udostępnianie danych

Question

W rzeczywistości czytam tony artykułów dotyczących architektury mikroserwisów, ale wydaje się, że zajmują się tym w najprostszy możliwy sposób, bez wchodzenia głębiej w wyjaśnienia.

Aby wyjaśnić wam moje pytania, pokażę ci moją małą architekturę rzeczywistego:

Więc oto co chcę używać. Zanim zrobię coś technicznie, potrzebuję więcej teoretycznych informacji.

Opis mojej domeny

Mam klientów mobilnych i przeglądarek opartych, w stanie połączyć się na wniosku, dostając swoje informacje użytkownika i mogą się konsultować informacje rozliczeniowe o tym, co kupić.

Na monolitycznej aplikacji, chciałbym skorzystać z tej architektury: - warstwa prezentacji z telefonu/Angular-Ember - warstwy biznesowej z API REST z Nginx przed tym - DAL ze standardową bazą danych MySQL - Skalowalność byłby zastosowany tylko na osi X:

Chcę użyć w tym przypadku architektury mikroserwisowej, ponieważ jest ona "skalowalna w domenie" i bardzo elastyczna (i aby dowiedzieć się nieco więcej na jej temat).

W schemacie, w każdej usłudze istnieje tylko URL HTTP ujawniony przez dany interfejs API.

Pytania

a/ W (1) topnika, "mobile" wysłać żądanie HTTP w http://myDomain.or/auth.

Moim zdaniem, stacja APIGateway może poprosić o standardowy rejestr usług (Eureka, ZooKeeper lub coś innego) jest w stanie znaleźć, czy AuthSrv jest dostępny i może pobrać jego adres sieciowy. Następnie ApiGateway może zażądać AuthSrv i odpowiedzieć na serwer

Czy to dobry sposób, aby to zadziałało? Czy nie ma problemu z opóźnieniem podczas obsługi maszyn X w celu uzyskania dostępu do danych?

b/ Strumień (2) konsultuje się z rejestrem usług. W jaki sposób rejestr usług może zrozumieć, że każde żądanie na/auth, nawet na adresach URL dzieci, takich jak/auth/other (jeśli zostały ujawnione) są powiązane z tą usługą na tym adresie ip: port?

c/ Strumień (3) pokazuje, że rejestr usług ma dostępny AuthSrv. (3 bis) pokazuje drugą: brak AuthSrv jest dostępny. W małej aplikacji możemy przyznać, że tracimy czasem dyspozycyjność, ale w dużym systemie, w którym jest połączonych setka usług, jak możemy radzić sobie z pogorszeniem usług?

d/ W innym poście, pytałem, jak przechowywać informacje rozliczeniowe, ponieważ są one powiązane z użytkownikiem, z innej usługi i innej bazy danych.

W standardowej architekturze musiałbym:

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

W architekturze microservice ktoś zaleca się stosowanie:

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

Jest to najlepszy sposób, aby obsłużyć "dane usługi udostępniania", a nie łączyć usługi?

e/ Kiedy powinienem preferować używanie protokołu AMQP zamiast protokołu HTTP w tym konkretnym przypadku?

Dzięki za wcześniej

Answer 1

a/

Nie Rejestry usług, takich jak Heca są w pamięci gwarantujący wysoką wydajność i niską latencję.

b/

w służbie Rejestrów jak Heca można zrobić ścieżkę systemu plików podobnego rejestracji usług. Na przykład/App1/Service1 i/App1/Usługa2

c/

Nie bardzo wiadomo, co to jest problem.

d/

Wzór zalecane przez kogoś jest HATEOAS wzór, który jest zalecany dla odpowiedzi interfejsu API.

e/

AMQP jest wymagane tylko wtedy, gdy wymagana komunikacja pomiędzy Services. Nigdy nie powinien bezpośrednio wywoływać interfejsu API innej usługi bezpośrednio z jednej usługi.

EDIT

c/

W takim przypadku należy wdrożyć logiki awaryjnej. Na przykład, jeśli usługa nie jest dostępna, przekroczono limit czasu lub jakąkolwiek inną awarię, należy podjąć pewne działania. Narzędzia takie jak Netflix's Hystrix pomagają to osiągnąć.

e/

Wzór komunikacyjne nie musi być symetryczny asymetryczny. Tak jak poniżej,

Ten wzór umożliwi luźne połączenie między mikroserwisami, umożliwiając w ten sposób elastyczność.