Урок за микроуслуги: Какво е, Archiструктура и пример

Терминът „микро“ се отнася до оразмеряването на микроуслуга, която трябва да се управлява от един екип за разработка (5 до 10 разработчици). В тази методология големите приложения са разделени на най-малките независими единици.

Какво е монолитен Archiтекстура?

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

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

Във всяко приложение за електронна търговия има някои стандартни функции като търсене, Review & Рейтинги и Плащания. Тези функции са достъпни за клиенти, използващи своя браузър или приложения. Когато разработчикът на сайта за електронна търговия внедри приложението, то е единична монолитна единица. Кодът за различни функции като търсене, Review & Ratings и Payments са на един и същи сървър. За да мащабирате приложението, трябва да стартирате множество екземпляри (сървъри) на тези приложения.

В монолита Architecture, всички компоненти се обединяват в един модул. Но в Microservices Archiте се разпространяват в отделни модули (микроуслуги), които комуникират помежду си, както е показано в примера за микроуслуги по-горе.

Комуникацията между микроуслугите е комуникация без състояние, където всяка двойка заявка и отговор е независима. Следователно Microservices могат да комуникират без усилие. В микросервиз Archiструктура, данните са обединени. Всяка микроуслуга има отделно хранилище за данни. Следващият в това Java Урок за микроуслуги, ще научим за разликата между микроуслуги и монолитна архитектура.

Микроуслуги срещу монолитни Archiтекстура

микро Услуги	монолитен Archiтекстура
Всяка единица от цялото приложение трябва да е най-малката и трябва да може да постигне една конкретна бизнес цел.	Единна кодова база за всички бизнес цели
Стартирането на услугата е сравнително бързо	Стартирането на услугата отнема повече време
Изолирането на повредата е лесно. Дори една услуга да спре, друга може да продължи да функционира.	Изолирането на повредата е трудно. Ако някоя конкретна функция не работи, цялата система пада. За да се справи с този проблем, приложението трябва да бъде изградено отново, повторно тествано и също така повторно внедрено.
Всички микроуслуги трябва да бъдат слабо свързани, така че промените, направени в едната, да не засягат другата.	Монолитната архитектура е тясно свързана. Промените в единия модул на кода засягат другия
Бизнесът може да използва повече ресурси за услуги, които генерират по-висока възвръщаемост на инвестициите	Тъй като услугите не са изолирани, индивидуалното разпределение на ресурсите не е възможно
Повече хардуерни ресурси могат да бъдат разпределени за услугата, която често се използва. В примера за електронна търговия по-горе по-голям брой потребители проверяват списъка с продукти и търсят в сравнение с плащанията. Така че повече ресурси могат да бъдат разпределени за микроуслугата за търсене и списък с продукти.	Мащабирането на приложения е предизвикателство, както и разточително.
Микроуслугите винаги остават последователни и непрекъснато достъпни.	Инструментите за разработка се претоварват, тъй като процесът трябва да започне от нулата.
Данните са обединени. Това позволява на индивидуалната Microservice да приеме модел на данни, който е най-подходящ за нейните нужди.	Данните са централизирани.
Малки фокусирани екипи. Паралелно и по-бързо развитие	Необходим е голям екип и значителни усилия за управление на екипа
Промяната в модела на данни на една микроуслуга не засяга други микроуслуги.	Промяната в модела на данни засяга цялата база данни
Взаимодейства с други микроуслуги чрез използване на добре дефинирани интерфейси	Не е приложимо
Микроуслугите работят на принципа, който се фокусира върху продукти, а не върху проекти	Поставете акцент върху целия проект
Няма кръстосани зависимости между кодовите бази. Можете да използвате различни технологии за различни микроуслуги.	Една функция или програма зависи от други.

Микросервизни предизвикателства

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

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

SOA срещу микроуслуги

SOA услугите се поддържат в организацията от регистър, който действа като списък с директории. Приложенията трябва да потърсят услугите в регистъра и да извикат услугата.

в друг свят, SOA е точно като оркестър, където всеки артист свири със своя инструмент, докато музикалният директор дава инструкции на всички.

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

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

Ето подробно сравнение между SOA и Microservices

Параметър	SOA	микро Услуги
Тип дизайн	В SOA софтуерните компоненти са изложени на външния свят за използване под формата на услуги.	Micro Service е част от SOA. Това е имплементация на SOA.
Зависимост	Бизнес единиците са зависими.	Те са независими един от друг.
Размер на софтуера	Размерът на софтуера е по-голям от всеки конвенционален софтуер	Размерът на софтуера винаги е малък в Microservices
Технологичен стек	Технологичният стек е по-нисък в сравнение с Microservice.	Технологичният стек на микросервизите може да бъде много голям
Естество на приложението	Монолитен по природа	Пълен стек сред природата
Независим и фокусиран	SOA приложенията са създадени да изпълняват множество бизнес задачи.	Те са създадени да изпълняват една бизнес задача.
внедряване	Процесът на внедряване отнема много време.	Внедряването е лесно и отнема по-малко време.
Разходи – ефективност	По-рентабилен.	Less рентабилен.
скалируемост	Less в сравнение с Microservices.	Силно мащабируем.
Бизнес логика	Компонентите на бизнес логиката се съхраняват вътре в един домейн на услугата Прости кабелни протоколи (HTTP с XML JSON) API се управлява с SDK/Клиенти	Бизнес логиката може да съществува в корпоративната Service Bus домейни като слоеве между услугите Middleware

Инструменти за микроуслуги

1) Wiremock: Тестване на микроуслуги

WireMock е гъвкава библиотека за заглушаване и подиграване на уеб услуги. Той може да конфигурира отговора, върнат от HTTP API, когато получи конкретна заявка. Използва се и за тестване на микроуслуги.

Изтегляне на връзката:http://wiremock.org/

2) Докер

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

Изтегляне на връзката:https://www.docker.com/

3) Хистрикс

Hystrix е java библиотека с толерантност към грешки. Този инструмент е предназначен за разделяне на точки за достъп до отдалечени услуги, системи и библиотеки на трети страни в разпределена среда като Microservices. Подобрява цялостната система чрез изолиране на неуспешните услуги и предотвратяване на каскадния ефект от повреди.

Връзка за изтегляне:https://github.com/Netflix/Hystrix

Най-добри практики на микроуслуги Archiтекстура

• Отделно хранилище на данни за всяка микроуслуга
• Поддържайте код с подобно ниво на зрялост.
• Отделна компилация за всяка Micro услуга.
• Винаги третирайте – тежко като без гражданство.

Oбобщение

• Микроуслугите са модел на ориентирана към услуги архитектура, в която приложенията са изградени като колекция от различни най-малки независими сервизни единици.
• Микросервиз Architecture е архитектурен стил на разработка, който позволява изграждането на приложение като колекция от малки автономни услуги, разработени за бизнес домейн.
• Монолитната архитектура е като голям контейнер, в който всички софтуерни компоненти на приложение са събрани в един пакет
• В една микроуслуга всяка единица от цялото приложение трябва да е най-малката и трябва да може да постигне една конкретна бизнес цел
• В монолитната архитектура голямата кодова база може да забави целия процес на разработка. Новите версии могат да отнемат месеци. Поддръжката на кода е трудна
• Два вида микроуслуги са 1) без състояние 2) със състояние
• Микроуслуги в Java разчитат един на друг и ще трябва да общуват помежду си. Помага ви да акцентирате върху конкретна функция и бизнес нужди
• Архитектурата, ориентирана към услуги, накратко известна като SOA, е еволюция на разпределените изчисления, базирани на модела на проектиране на заявка или отговор за синхронни и асинхронни приложения
• В SOA софтуерните компоненти са изложени на външния свят за използване под формата на услуги, докато Micro Service е част от SOA. Това е имплементация на SOA
• Wiremock, Docker и Hystrix са някои популярни инструменти за микроуслуги