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

Какво представляват микроуслугите?

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

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

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

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

монолитен Archiструктура на приложението за електронна търговия

Във всяко приложение за електронна търговия има някои стандартни функции като търсене, RevПреглед и оценки, както и Плащания. Тези функции са достъпни за клиенти, използващи техния браузър или приложения. Когато разработчикът на сайта за електронна търговия внедри приложението, то представлява едно цяло. Кодът за различни функции като търсене, Rev„Преглед и оценки“ и „Плащания“ са на един и същ сървър. За да мащабирате приложението, трябва да стартирате множество екземпляри (сървъри) на тези приложения.

Какво е Microservice Archiтекстура?

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

Нека вземем пример за приложение за електронна търговия, разработено с микросървисна архитектура. В този пример за микросървисна архитектура, всяка микросървисна услуга е фокусирана върху една бизнес възможност. Търсене, Оценяване и Revview и Payment имат свой собствен екземпляр (сървър) и комуникират помежду си.

микро Услуги Archiтекстура

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

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

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

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

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

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

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

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

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

Параметър	SOA	микро Услуги
Тип дизайн	В SOA софтуерните компоненти са изложени на външния свят за използване под формата на услуги.	Micro Service е част от SOA. Това е имплементация на SOA.
Зависимост	Бизнес единиците са зависими.	Те са независими един от друг.
Размер на софтуера	Размерът на софтуера е по-голям от всеки конвенционален софтуер.	Размерът на софтуера винаги е малък в микросървисите.
Технологичен стек	Технологичният стек е по-нисък в сравнение с 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 библиотека. Този инструмент е предназначен да разделя точките на достъп до отдалечени услуги, системи и библиотеки на трети страни в разпределена среда, като например микросървиси. Той подобрява цялостната система, като изолира отказващите услуги и предотвратява каскадния ефект на отказите.

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

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

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

Въпроси и Отговори