Архитектура на Microservice - Научете, изградете и внедрете Microservices

Архитектура на микросервиз:

От моя , трябва да имате основни познания за архитектурата на Microservice.Но като професионалист с ще изисква не само основите. В този блог ще влезете в дълбочината на архитектурните концепции и ще ги приложите с помощта на UBER-казус.

В този блог ще научите за следното:

• Определение на архитектурата на Microservice
• Основни концепции на архитектурата на микросервисите
• Плюсове и минуси на архитектурата на Microservice
• UBER - Казус

Можете да се обърнете към , за да разберете основите и предимствата на микроуслугите.

Ще бъде справедливо само ако ви дам определението за микроуслуги.

Определение на микроуслугите

Като такова няма правилна дефиниция на Microservices, известна също като Microservice Architecture, но можете да кажете, че това е рамка, която се състои от малки, индивидуално разгръщащи се услуги, изпълняващи различни операции.

следдипломна диплома срещу магистърска степен

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

Фигура 1: Разлика между монолитна и микросервизна архитектура - Микросервизна архитектура

Вижте диаграмата по-горе, за да разберете разликата между монолитна и микросервизна архитектура.За по-добро разбиране на разликите между двете архитектури можете да се обърнете към предишния ми блог

За да ви разбера по-добре, позволете ми да ви разкажа някои ключови концепции за архитектурата на микросервисите.

Основни концепции на архитектурата на микросервисите

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

Следват някои насоки, които трябва да се следват, докато се обсъждат микроуслугите.

Насоки при проектиране на микроуслуги

• Като разработчик, когато решите да създадете приложение, разделете домейните и бъдете ясни с функционалностите.
• Всяка микроуслуга, която проектирате, трябва да се концентрира само върху една услуга на приложението.
• Уверете се, че сте проектирали приложението по такъв начин, че всяка услуга да може да се разполага поотделно.
• Уверете се, че комуникацията между микроуслуги се осъществява чрез сървър без гражданство.
• Всяка услуга може да бъде допълнително реконструирана в по-малки услуги със собствени микроуслуги.

Сега, след като прочетете основните насоки, докато проектирате микроуслуги, нека разберем архитектурата на микроуслугите.

Как работи архитектурата на Microservice?

Типичната архитектура на Microservice (MSA) трябва да се състои от следните компоненти:

1. Клиенти
2. Доставчици на самоличност
3. API на шлюза
4. Формати за съобщения
5. Бази данни
6. Статично съдържание
7. Управление
8. Откриване на услугата

Вижте диаграмата по-долу.

Фигура 2: Архитектура на микросервизи - Архитектура на микросервизи

Знам, че архитектурата изглежда малко сложна, но некаАзопростете го за вас.

1. Клиенти

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

2. Доставчици на самоличност

как да инициализираме клас в python

След това тези заявки от клиентите се предават на доставчиците на идентичност, които удостоверяват заявките на клиентите и предават заявките на API Gateway. След това заявките се съобщават на вътрешните услуги чрез добре дефиниран API шлюз.

3. API шлюз

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

Предимствата на използването на API шлюз включват:

• Всички услуги могат да бъдат актуализирани, без клиентите да знаят.
• Услугите могат също да използват протоколи за съобщения, които не са удобни за уеб.
• API шлюзът може да изпълнява кръстосани функции като осигуряване на сигурност, балансиране на натоварването и т.н.

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

4. Формати за съобщения

Съществуват два типа съобщения, чрез които те комуникират:

• Синхронни съобщения: В ситуацията, когато клиентите чакат отговорите от дадена услуга, Microservices обикновено са склонни да използват REST (Представителен държавен трансфер) тъй като разчита на липса на състояние, клиент-сървър и HTTP протокол . Този протокол се използва, тъй като е разпределена среда, всяка функционалност е представена с ресурс за извършване на операции
• Асинхронни съобщения: В ситуацията, когато клиентите не чакат отговорите от дадена услуга, Microservices обикновено са склонни да използват протоколи като AMQP, STOMP, MQTT . Тези протоколи се използват в този тип комуникация, тъй като естеството на съобщенията е дефинирано и тези съобщения трябва да бъдат оперативно съвместими между реализациите.

Следващият въпрос, който може да ви хрумне, е как приложенията, използващи Microservices, обработват данните си?

5. Обработка на данни

Е, всяка Microservice притежава частна база данни за събиране на техните данни и внедряване на съответната бизнес функционалност.Също така, базите данни на Microservices се актуализират само чрез техния API за услуги. Вижте диаграмата по-долу:

Фигура 3: Представяне на обработка на данни от микроуслуги - Архитектура на микросервизи

Услугите, предоставяни от Microservices, се пренасочват към всяка отдалечена услуга, която поддържа комуникация между процесите за различни технологични стекове.

6. Статично съдържание

След като Microservices комуникират вътре в себе си, те разполагат статичното съдържание в облачна услуга за съхранение, която може да ги достави директно на клиентите чрез Мрежи за доставка на съдържание (CDN) .

Освен горните компоненти, има някои други компоненти, които се появяват в типична архитектура на Microservices:

7. Управление

Този компонент е отговорен за балансиране на услугите на възли и идентифициране на грешки.

8. Откриване на услугата

Действа като ръководство за Microservices за намиране на маршрута на комуникация между тях, тъй като поддържа списък с услуги, на които са разположени възлите.

Абонирайте се за нашия канал в YouTube, за да получавате нови актуализации ..!

Сега, нека да разгледаме плюсовете и минусите на тази архитектура, за да разберем по-добре кога да използваме тази архитектура.

Плюсове и минуси на архитектурата на Microservice

Вижте таблицата по-долу.

Нека разберем повече за микроуслугите, като сравним предишната архитектура на UBER с настоящата.

ИЗСЛЕДВАНЕ НА СЛУЧАЙ UBER

Предишната архитектура на UBER

видове трансформации в информатика

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

Фигура 4: Монолитна архитектура на UBER - Микросервизна архитектура

Горната схема изобразява предишната архитектура на UBER.

• Налице е REST API, с който пътникът и водачът се свързват.
• Три различни адаптера се използват с API в тях, за да извършват действия като фактуриране, плащания, изпращане на имейли / съобщения, които виждаме, когато резервираме такси.
• MySQL база данни за съхраняване на всички техни данни.

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

Декларация за проблема

Докато UBER започна да се разширява в световен мащаб, този вид рамка създаде различни предизвикателства. Следват някои от видни предизвикателства

• Всички функции трябваше да бъдат преизграждани, внедрявани и тествани отново и отново, за да се актуализира една функция.
• Коригирането на грешки стана изключително трудно в едно хранилище, тъй като разработчиците трябваше да променят кода отново и отново.
• Мащабирането на функциите едновременно с въвеждането на нови функции в целия свят беше доста трудно да се работи заедно.

Решение

За да избегне подобни проблеми, UBER реши да промени архитектурата си и да последва другите компании за хипер-растеж като Amazon, Netflix, Twitter и много други. По този начин UBER реши да раздели монолитната си архитектура на множество кодови бази, за да формира архитектура на микросервиз.

Вижте диаграмата по-долу, за да разгледате архитектурата на микросервиса на UBER.

Фигура 5: Архитектура на Microservice на UBER - Архитектура на Microservice

• Основната промяна, която наблюдаваме тук, е въвеждането на API шлюз, чрез който всички шофьори и пътници са свързани. От API шлюза всички вътрешни точки са свързани като управление на пътници, управление на водачи, управление на пътувания и други.
• Устройствата са отделни отделни разгръщащи се единици, изпълняващи отделни функционалности.
  • Например: Ако искате да промените нещо в таксуващите микроуслуги, тогава просто трябва да внедрите само фактуриращи микроуслуги и не е нужно да разполагате останалите.
• Всички функции сега бяха мащабирани индивидуално, т.е.взаимозависимостта между всяка и всяка функция беше премахната.
  • Например, всички знаем, че броят на хората, които търсят таксита, е по-сравнително повече от хората, които действително резервират такси и извършват плащания. Това ни дава извод, че броят на процесите, работещи на микроуслугата за управление на пътници, е повече от броя на процесите, работещи върху плащанията.

В тованачин, UBER се възползва от смянасиархитектура от монолитна до микроуслуга.

Надявам се, че ви е било приятно да прочетете този пост за Microservice Architecture.Ще измисля още блогове, които също ще съдържат практически.
Интересувате ли се да научите повече за микроуслугите?

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

Имате въпрос към нас? Моля, споменете го в раздела за коментари на ” Микросервизна архитектура ”И ще се свържа с вас.