Иван Гайдаров API икономиката (отваряне на интерфейсите на вътрешните системи

Иван Гайдаров

API стопанската система (отваряне на интерфейсите на вътрешните системи на едно приложение към външния свят с бизнес цели) набира все по-голяма известност, а около нея се чува все по-често и за Microservice архитектурата за микроуслуги за основаване на приложения. Терминът " Microservice " обаче е доста замайващ и неакуратен, тъй като в последна сметка става дума не за архитектура, ориентирана към микроуслуги, а за такава, построена от микрокомпоненти. Това изясни по време на своята презентация в границите на конференцията “IT Compass - трендове, технологии, решения”, Горан Ангелов, шеф на IBS България.



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

“Архитектурата " Microservice " се базира на обособени дребни съставни елементи, които построяват едно изцяло решение. Например имате приложение за е-поща. Ако то е основано на тази технология, съставният елемент за регистрация и дерегистрация на потребителите би бил настрана приложение, което си комуникира с други такива, с цел да даде нужната обща функционалност. Тази материя обаче остава малко позната, тъй като отвън средата за проби и разработка монолитните и компонентните приложения се презентират по безусловно еднакъв начин”, обърна внимание Горан Ангелов.

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

“Microservice архитектурата е обвързвана с капсулирането на съставените елементи в обособени дребни приложения в границите на цялостния артикул. Става дума за капсулиране и на бизнес логиката, и на данните. При монолитното приложение се употребява една огромна база данни и всеки модул си взима каквото му би трябвало. При Microservice всеки съставен елемент би трябвало да употребява своята част от данните, с цел да бъде в действителност самостоятелен от останалите модули”, разяснява Валентин Христов, софтуерен проектант в IBS.

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

“При едно общоприетоо монолитно приложение нормално имаме бизнес логичност, база данни и презентационен пласт. Ако би трябвало да нанесем и най-малката смяна, би трябвало да тестваме цялото приложение, което лишава време и запаси. Microservice архитектурата ни дава доста преимущество в това отношение. Тя разрушава обособените модули на огромното приложение на микрокомпоненти, които могат да бъдат тествани без значение един от различен, и в случай че има потребност от промени, те могат да бъдат нанесени единствено в тези модули, в които трябва”, разяснява още Валентин Христов. Той добави, че връзката при микроуслугите би трябвало да бъде асинхронна и да се употребяват обществени абонантни модели, когато един съставен елемент би трябвало да комуникира с няколко други, а за директна връзка да се разчита на олекотени протоколи.

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

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

Като цяло микрокомпонентната архитектура не е нещо ново. Нови са обаче темповете на развиване, които тя набира напоследък. “Microservice архитектурата стартира да се постанова, тъй като към този момент имаме всички предпоставки да се употребява дейно – мрежите доближиха зрял стадий от своето развиване и обезпечават бистрота на връзките сред софтуерните съставни елементи, има методологии, принадлежности, протоколи за лесна връзка, елементарно ръководство на инфраструктурата и така нататък За да се употребяват нейните благоприятни условия в целия им размер обаче, би трябвало да се съблюдават множесто правила. Едно от най-важните е, че обособените съставни елементи би трябвало да са по този начин построени, че при проблем и повдигане на нова инстанция, това да не се отразява върху приложението и потребителят да има опция да продължи работата си”, поучава Валентин Христов.