Избор на архитектонски стил (дел 1)

Здраво, Хабр. Уписот за нов тек на курсеви е отворен во моментов на OTUS „Архитект на софтвер“. Во пресрет на почетокот на курсот, сакам да ја споделам со вас мојата оригинална статија.

Вовед

Изборот на архитектонски стил е една од основните технички одлуки при изградба на информациски систем. Во оваа серија написи, предлагам да ги анализирам најпопуларните архитектонски стилови за градење апликации и да одговорам на прашањето кога кој архитектонски стил е најпосакуван. Во процесот на презентација, ќе се обидам да нацртам логичен синџир кој го објаснува развојот на архитектонските стилови од монолити до микросервиси.

Малку историја

Ако се обидете да ги прашате програмерите: „Зошто ни се потребни микроуслуги?“, ќе добиете различни одговори. Ќе слушнете дека микросервисите ја подобруваат приспособливоста, го олеснуваат разбирањето на кодот, ја подобруваат толеранцијата на грешки, а понекогаш ќе слушнете дека ви дозволуваат да го „исчистите вашиот код“. Ајде да погледнеме во историјата за да ја разбереме целта зад појавата на микросервисите.

Накратко, микросервисите во нашето сегашно разбирање се појавија на следниов начин: во 2011 година, Џејмс Луис, анализирајќи ја работата на различни компании, го привлече вниманието на појавата на нова шема „микро-апликација“, која го оптимизираше SOA во смисла на забрзување на распоредувањето на услуги. Нешто подоцна, во 2012 година, на самитот за архитектура, моделот беше преименуван во микросервис. Така, првичната цел на воведувањето на микросервисите беше да се подобрат озлогласените време на пазарот.

Микроуслугите беа на бранот возбуда во 2015 година. Според некои студии, ниту една конференција не била комплетна без извештај на тема микроуслуги. Покрај тоа, некои конференции беа посветени исклучиво на микросервисите. Во денешно време, многу проекти почнуваат да го користат овој архитектонски стил, и ако проектот содржи тони наследен код, тогаш веројатно активно се спроведува миграција кон микросервисите.

И покрај сето горенаведено, прилично мал број програмери сè уште можат да го дефинираат концептот на „микросервис“. Но, за ова ќе зборуваме малку подоцна...

Монолит

Архитектонскиот стил што ги спротивставува микросервисите е монолитот (или сè-во-едно). Веројатно нема смисла да се каже што е монолит, па веднаш ќе ги наведам недостатоците на овој архитектонски стил, кој го иницираше понатамошниот развој на архитектонските стилови: големина, поврзаност, распоредување, приспособливост, сигурност и цврстина. Подолу предлагам да го разгледаме секој од недостатоците одделно.

Големина

Монолитот е многу голем. И обично комуницира со многу голема база на податоци. Апликацијата станува преголема за еден развивач воопшто да не ја разбере. Само оние кои потрошиле многу време работејќи на овој код можат добро да работат со монолитот, додека почетниците ќе поминат многу време обидувајќи се да го откријат монолитот и нема гаранција дека ќе го сфатат. Вообичаено, кога работите со монолит, секогаш има некој „условен“ постар кој повеќе или помалку добро го познава монолитот и ги победува другите нови програмери во рок од една и пол година. Секако, таков условен сениор е единствена точка на неуспех, а неговото заминување може да доведе до смрт на монолитот.

Поврзаност

Монолитот е „голема топка од кал“, промените во кои може да доведат до непредвидливи последици. Со правење промени на едно место, можете да го оштетите монолитот на друго (истото „си го изгреба увото, *@ падна“). Ова се должи на фактот дека компонентите во монолитот имаат многу сложени и што е најважно, неочигледни односи.

Распоредување

Распоредувањето на монолитот, поради сложените односи меѓу неговите компоненти, е долг процес со сопствен ритуал. Таквиот ритуал обично не е целосно стандардизиран и се пренесува „усно“.

Приспособливост

Монолитните модули може да имаат конфликтни потреби за ресурси, што бара да се направи компромис во однос на хардверот. Замислете дека имате монолит кој се состои од услуги А и Б. Услугата А бара големината на хард дискот, а услугата Б бара од RAM меморијата. Во овој случај, или машината на која е инсталиран монолитот мора да ги поддржува барањата на двете услуги, или ќе мора рачно, вештачки да оневозможите една од услугите.

Друг пример (покласичен): услугата А е многу попопуларна од услугата Б, така што сакате да има 100 услуги А и 10 услуги Б. Повторно, две опции: или ќе распоредиме 100 полноправни монолити, или на некои потоа услугите Б ќе треба да се оневозможат рачно.

Сигурност

Бидејќи сите услуги се наоѓаат заедно, ако монолитот падне, тогаш сите услуги паѓаат одеднаш. Всушност, ова можеби и не е толку лошо, барем нема да има делумни дефекти во дистрибуираниот систем, но од друга страна, поради грешка во функционалноста што ја користат 0.001% од корисниците, можете да ги изгубите сите корисници на вашиот систем.

Инерција

Поради големината на монолитот, тешко е да се префрлите на нови технологии. Како резултат на тоа, задржувањето на тој многу условен постар се чини дека е посебна задача. Технолошкиот оџак избран на почетокот на проектот може да стане блок што го попречува развојот на производот.

Заклучок

Следниот пат ќе зборуваме за тоа како луѓето се обиделе да ги решат овие проблеми со префрлање на компоненти и SOA.

Прочитај повеќе:

• Зошто SQL Server не гарантира дека ќе ги сортира резултатите без ORDER BY
• Архитектура за програмери и администратори: на кого му требаат какви вештини?

Извор: www.habr.com