Микрослуги вътрешна комуникация - микро услуги

Разчитах на Микросервизната архитектура, но все още не мога да разбера механизма за комуникация между микро-услугите.
В много статии се казва, че микрослужбите саобикновено изложени на RESTful API. Но когато търсите в интернет, винаги виждате реализации, базирани на съобщения и събития за задните комуникации.

Така че аз съм объркан, REST API ли е стандарт за всички микрослужби или можем да видим микроуслуги без REST крайни точки.

Отговори:

За вашия проблем, първо ви позволява да разберете начините, по които една услуга взаимодейства помежду си, позволява създаването на две услуги за поръчки на услуги и обслужване на клиенти:

1. Една услуга се нуждае от данни от друга услугаобработват заявките си, например: позволява да кажем, че искате да направите поръчка, така че от ui трябва да натиснете http заявка за поръчка на услуга (която може да бъде почивка или да имате api шлюз между n, който използва друг протокол като protobu), за да се обадите Поръчайте услугата за даване на поръчка, сега приемете услугата за поръчка, за да проверите валидността на клиента, така че услугата за поръчка трябва да се обади в синхрон с обслужването на клиенти - най-вероятно ще ударите почивка или ще създадете протобоф или ще имате постоянна връзка между услугата и след това след отговор от страна на обслужването на клиентите, поръчката се движи напред.

В този случай комуникацията на синхронизацията трябва да бъде имитирана, един директен подход е почивка или протобоф, или да се имитира чрез съобщения

2. Въз основа на едно събитие от услугата искате да актуализиратедруга услуга: в този принцип предпочитаният стил е шина за съобщения, където една услуга излъчва събитие и множество други услуги имат слушател на шината за съобщения и реагират съответно. Например: позволява да кажем за актуализиране на името на клиента в обслужването на клиенти, искате да актуализирате кешираното име на клиента в услуга за поръчки, в това, когато името се актуализира в обслужването на клиенти, той излъчва събитие с име на клиента, услугата за поръчки, след това реагирайте на него

Третият ви въпрос е, възможно ли е да имате услуга без крайни точки за почивка ::: да е възможно, но всяка услуга трябва да бъде достъпна. Така че използвайте почивка или друга форма е необходимо

Горепосочената връзка: microservices.io е много добро, преминете през него отново

REST не е единственият стил, достъпен за microservice-to-microservice (известен още като комуникация между процесите / IPC), но това е най - известен IPC технология, използвана от приложения, базирани на архитектура, оформена в микрослужби, Има и други технологии като Apache Thrift и gRPC които могат да служат на същата цел. По същество всички тези технологии са индустриални реализации на RPC (Отдалечено извикване на процедура).

Горещо ви препоръчвам да прочетете това връзка от Microservices Expert - Крис Ричардсън

Един от ползи от използването на микрослужби (ако не и най-голямата) е, че тя елиминира всякадългосрочен ангажимент към технологичен стак. При разработването на нова услуга можете да изберете нов технологичен стек. По подобен начин, когато правите големи промени в съществуваща услуга, можете да я пренапишете с нов технологичен стек.

Значи можеш изберете какъвто и да е комуникационен механизъм, който искате, стига да не ви пречи да промените технологичния стек, REST над HTTP е добър избор, защото тойскрива технологиите, използвани от микросервиза, за генериране на отговорите в синхронен стил на заявка-отговор. Съобщенията, базирани на съобщения, също са подходящи, тъй като съобщенията могат също така да скрият технологиите, използвани за тяхното създаване (стига да не използвате вградената сериализация на продуцентския програмен език), т.е. RabbitMQ или Апачи Кафка.

REST се поддържа универсално, като се приема на всички езици, ако всички ваши бекенд услуги се изпълняват на едно и също място, може да не виждате много по-различна пропускателна способност.

Както и да е добра идея да инвестирате и да научите gRPCили Спестовност, както е споменато по-горе, можете да конвертирате всички ваши вътрешни услуги в gRPC например (поддържани на повечето езици) и да направите преобразуване между gRPC и REST на вашия Universal Gateway.

Има два подхода към вътрешнотоархитектура, CQRS срещу обикновени REST разговори. Eventing / messaging е пример за CQRS, където можете да отделите операции за четене / запис и всички операции на страниците за писане могат да се изпълняват чрез eventing за по-добра мащабируемост и производителност.