Здравейте на всички! Имаме страхотни новини, през юни OTUS отново стартира курс , поради което традиционно споделяме с вас полезен материал.
Ако сте се сблъскали с всичките тези истории за микросервизи без никакъв контекст, напълно ви е простимо да ги смятате за малко странни. Разделянето на приложението на фрагменти, свързани помежду си с мрежа, задължително означава добавяне на сложни механизми за отказоустойчивост в получената разпределена система.
Въпреки че този подход включва разделяне на множество независими услуги, крайната цел е много по-голяма от просто функциониране на тези услуги на различни машини. Струва се да се говори за взаимодействието с околния свят, който по своята същност също е разпределен. Не в техническия смисъл, а по-скоро в смисъл на екосистема, състояща се от много хора, екипи и приложения, и всяка от тези части по един или друг начин трябва да върши своята работа.
Компаниите, например, представляват набор от разпределени системи, които в съвкупност допринасят за постигането на определена цел. Игнорирали сме този факт през десетилетията, опитвайки се да постигнем обединение, прехвърляйки файлове по FTP или използвайки корпоративни интеграционни инструменти, фокусирайки се върху собствените си индивидуални цели. Но с появата на услугите всичко се промени. Услугите ни помогнаха да погледнем отвъд хоризонта и да видим света на взаимозависимите приложения, които работят заедно. Въпреки това, за да работи успешно, е необходимо да разберем и проектираме два принципиално различни свята: външния свят, в който живеем в екосистема от много други услуги и нашия собствен, вътрешен свят, в който царуваме самостоятелно.
Такъв разпределен свят се различава от този, в който сме израснали и на който сме свикнали. Принципите за изграждане на традиционната монолитна архитектура не издържат на каквато и да е критика. Затова правилното разбиране на такива системи е нещо повече от създаването на чудесна схема на бяла дъска или страхотно доказателство за концепция. Става дума за това, че такава система успешно да функционира дълго време. За щастие, услугите съществуват от доста време, макар и да изглеждат по различен начин. все още са актуални, дори подправени с Docker, Kubernetes и леко износени от хипстърски бради.
И така, днес ще разгледаме как се промениха правилата, защо трябва да преосмислим нашия подход към услугите и данните, които те предават помежду си, и защо ще ни трябва съвсем различен инструментариум за това.
Инкапсулацията не винаги ще бъде ваш приятел.
Микросервисите могат да работят независимо един от друг. Именно това свойство им придава най-голяма стойност. То позволява на услугите да се мащабират и развиват. Не толкова в смисъл на мащабиране до квадрилиони потребители или петабайти данни (макар че и в това те могат да помогнат), колкото в смисъл на мащабиране от гледна точка на хората, тъй като екипите и организациите неуморно растат.
Въпреки това независимостта е двуостър меч. Тоест, услугата сама по себе си може да работи лесно и безпроблемно. Но ако в рамките на услугата се реализира функция, която изисква взаимодействие с друга услуга, в крайна сметка ще трябва да внесем промени и в двете услуги почти едновременно. В монолита това е лесно — просто правите промяна и я пускате в продукция, но в случая на синхронизация на независими услуги проблемите ще бъдат повече. Координацията между екипите и цикъла на пускане разрушава гъвкавостта.
В рамките на стандартния подход, нежеланите прекъсващи промени се избягват, като се разделя ясно функционалността между услугите. Услугата за единичен вход в системата тук може да бъде добър пример. Тя има ясно определена роля, която я отличава от другите услуги. Такова ясно разделение означава, че в свят на бързо променящи се изисквания към околните услуги, услугата за единичен вход в системата едва ли ще се променя. Тя съществува в рамките на строго определен контекст.
Проблемата е, че в реалния свят бизнес услугите не могат постоянно да поддържат чиста разделеност на ролите. Например, тези бизнес услуги по-скоро работят с данни, идващи от други подобни услуги. Ако се занимавате с онлайн търговия, обработката на потока поръчки, каталога на продуктите или информацията за потребителите ще стане изискване за много от услугите ви. На всеки от услугите ще е нужен достъп до тези данни.
Повечето бизнес услуги използват един и същ поток от данни, така че работата им неизменно се преплита.
Така стигнахме до важен момент, за който трябва да говорим. Докато услугите работят добре за инфраструктурни компоненти, които функционират в значителна степен отделно, повечето бизнес услуги са много по-тясно свързани.
Дихотомия на данните
Подходи, ориентирани към услуги, може вече да съществуват, но все още има малко информация за това как да се обменят големи обеми данни между услугите.
Основната проблема е, че данните и услугите са неразривно свързани. От една страна, инкапсулацията ни призовава да скрием данните, за да можем да отделим услугите една от друга и да улесним техния растеж и бъдещи промени. От друга страна, трябва да можем свободно да споделяме и управляваме общите данни, точно както всякакви други. Става въпрос за това да можем да започнем работа незабавно, също толкова свободно, колкото в която и да е друга информационна система.
Но информационните системи имат малко общо с инкапсуацията. Всъщност дори обратното. Базите данни правят всичко възможно, за да предоставят достъп до съхраняваните в тях данни. Те предлагат мощен декларативен интерфейс, който позволява да трансформирате данните, както е необходимо. Тази функционалност е важна в етапа на предварителните изследвания, но не и за управление на нарастващата сложност на постоянно развиващата се услуга.
И тук възниква дилемата. Противоречието. Дихотомията. Защото информационните системи са свързани с предоставянето на данни, а услугите – с тяхното скриване.
Тези две сили са основополагаещи. Те са в основата на по-голямата част от нашата работа, като постоянно се състезават за превъзходство в системите, които създаваме.
С нарастването и еволюцията на системите за услуги, виждаме различни проявления на последствията от дихотомията на данните. Или интерфейсът на услугата ще расте, предоставяйки все по-широк набор от функции и ще започне да изглежда като много странна направена вкъщи база данни, или ще се сблъскаме с разочарование и ще реализираме някакъв начин да извлечем или преместваме масиви от данни от услуга в услуга.
От своя страна, създаването на нещо, което изглежда като странна направена вкъщи база данни, ще доведе до редица проблеми. Няма да се задълбочаваме в детайлите за опасностите от shared database, просто ще кажем, че представлява значителни скъпи инженерни и оперативни за компания, която се опитва да я използва.
По-лошо е, че обемите на данните умножават проблемите с границите на услугите. Колкото повече общи данни се намират в услугата, толкова по-сложен става интерфейсът и толкова по-трудно е да се обединят наборите от данни, идващи от различни услуги.
Алтернативният подход с извличане и преместване на цели набори от данни също има свои проблеми. Популярният подход към този въпрос изглежда като просто извличане и съхранение на набора от данни цялостно, а след това съхранение на него локално във всяка услуга-потребител.
Проблемът е, че различните услуги интерпретират данните, които консумират, по различен начин. Тези данни винаги са под ръка. Те се променят и обработват локално. Доста бързо те спират да имат нещо общо с данните в източника.
Колкото по-мутабилни са копията, толкова повече данните ще се различават с течение на времето.
Какво още е по-лошо, такива данни е трудно да се коригират ретроспективно ( тук наистина може да се окаже полезно). Всъщност някои от трудните технологични проблеми, с които бизнеса се сблъсква, произтичат от хетерогенни данни, множащи се от приложение на приложение.
За да намерим решение на този проблем с общите данни, трябва да мислим по различен начин. Те трябва да станат обекти от първокласен клас в архитектурите, които изграждаме. таки данни се наричат "външни", и това е много важна характеристика. Нуждаем се от инкапсулация, за да не разкрием вътрешната структура на услугата, но трябва да улесним достъпа на услугите до споделените данни, за да могат те да изпълняват работата си правилно.
Проблемът е, че нито един от подходите днес не е актуален, тъй като нито интерфейсите на услугите, нито обменът на съобщения, нито Shared Database предлагат добро решение за работа с външни данни. Интерфейсите на услугите не са подходящи за обмен на данни в какъвто и да е мащаб. Обменът на съобщения прехвърля данни, но не ги съхранява историята, затова с времето данните се повреждат. Shared Databases са твърде фокусирани на едно място, а това задържа напредъка. Ние неизбежно попадаме в цикъл на несъстоятелност на данните:
Цикъл на несъстоятелност на данните
Потокове: децентрализираният подход към данните и услугите
В идеалния случай трябва да променим подхода към това как услугите работят със споделени данни. В момента всеки подход се сблъсква с вече споменатата дихотомия, тъй като няма магическа пудра, с която да можем да я поръсим и да я накараме да изчезне. Въпреки това можем да преразгледаме проблема и да достигнем до компромис.
Този компромис предполага известна степен на централизация. Можем да се възползваме от механизма на разпределените логове, тъй като той осигурява надеждни, мащабируеми потоци. Сега е необходимо услугите да могат да се присъединяват и да работят с тези общи потоци, но искаме да избегнем сложни централизирани God Service, които извършват такава обработка. Затова най-добрият вариант е вграждането на потоковата обработка във всяка услуга-потребител. Така услугите ще могат да комбинират набори данни от различни източници и да работят с тях, както им е необходимо.
Един от начините да постигнем такъв подход е използването на стриминг платформа. Съществуват много опции, но днес ще разгледаме именно Kafka, тъй като използването на нейния Stateful Stream Processing позволява ефективно да решаваме представения проблем.
Използването на механизма за разпределено логиране ни позволява да следваме вече утвърдена пътека и да използваме обмяната на съобщения, за да работим с . Счита се, че този подход осигурява по-добро мащабиране и разделение в сравнение с механизма "запитване-отговор", тъй като контролът върху потока се предоставя на получателя, а не на изпращача. Въпреки това, за всичко в живота трябва да се плати, и тук ще ви трябва брокер. Но за големи системи този компромис си струва (за разлика от вашите средностатистически уеб приложения).
Ако за разпределеното логиране отговаря брокер, а не традиционната система за обмен на съобщения, можете да се възползвате от допълнителни функции. Транспортът може да се мащабира линейно почти толкова добре, колкото разпределена файлова система. Данните могат да се съхраняват в логовете достатъчно дълго, така че получаваме не само обмен на съобщения, но и хранилище на информация. Мащабируемо хранилище без страх от промяна на общото състояние.
След това можете да използвате механизма за обработка на потоци с запазено състояние (stateful stream processing), за да добавите декларативни инструментариум за бази данни към потребителските услуги. Това е много важна идея. Докато данните се съхраняват в общи потоци, до които имат достъп всички услуги, комбинирането и обработката, която прави услугата, са частни. Те остават изолирани в строго ограничен контекст.
Избавете се от дихотомията на данни, разделяйки имутируем поток от състояния. След това добавете тази функция в всяка услуга с помощта на обработка на потоци с запазено състояние.
Така че, ако вашата услуга трябва да работи с поръчки, каталог на продукти, склад, тя ще има пълен достъп: само вие ще решавате кои данни да комбинирате, къде да ги обработвате и как трябва да се променят с времето. Въпреки че данните са общи, работата с тях е напълно децентрализирана. Тя се произвежда вътре в всяка услуга, в свят, където всичко върви по вашите правила.
Споделяте данни така, че да не се нарушава тяхната цялост. Инкапсулирайте функция, а не източник, в услугите, на които е необходима.
Понякога е необходимо да се преместват данни в голям мащаб. Понякога услугата се нуждае от локален исторически набор данни в избраната база данни. Важно е да се гарантира, че при необходимост копия може да бъде възстановена от източника чрез механизма на разпределено логване. Конекторите в Kafka отлично се справят с тази задача.
Следователно, разглежданият днес подход има няколко предимства:
- Данните се използват под формата на общи потоци, които могат да се съхраняват дълго време в логовете, а самият механизъм за работа с общите данни е интегриран в контекста, което позволява на услугите да работят лесно и бързо. По този начин можем да балансираме дихотомията на данните.
- Данните, идващи от различни услуги, могат лесно да се обединят в набори. Така се улеснява взаимодействието с общите данни и изчезва необходимостта от поддръжка на локални набори данни в базата данни.
- Stateful Stream Processing само кешира данните, а източникът на истината остават общите логове, затова проблемът с повреждането на данните с времето не е така остър.
- По същество, услугите се управляват от данни, така че въпреки постоянния ръст на обема на данните, услугите все още могат бързо да реагират на бизнес събития.
- Проблемите с мащабируемостта лежат върху брокера, а не върху услугите. По този начин значително се намалява сложността на написването на услуги, тъй като няма нужда да се мисли за мащабируемост.
- Добавянето на нови услуги не изисква промяна на старите, така че свързването на новите услуги става по-лесно.
Както виждате, това е повече от просто REST. Получихме набор от инструменти, които позволяват работа с общи данни децентрализирано.
В днешната статия не бяха разкрити всички аспекти. Все още трябва да разберем как да балансираме между парадигмата на 'запитване-отговор' и събитийно ориентираната парадигма. Но с това ще се справим следващия път. Има теми, които заслужават по-добро познаване, например, защо Stateful Stream Processing е толкова полезен. За това ще говорим в третата статия. Има и други мощни конструкции, на които можем да разчитаме, като например, . С нея се променят правилата на играта за разпределените бизнес системи, тъй като тази конструкция осигурява транзакционни гаранции за в мащабируема форма. За това ще стане дума в четвъртата статия. И накрая, трябва да разгледаме детайлите за реализацията на тези принципи.
Но засега просто запомнете следното: дихотомията на данните е силата, с която се сблъскваме при създаването на бизнес услуги. И трябва да помним за това. Фокусът е да обърнем всичко наопаки и да започнем да разглеждаме общите данни като обекти от първи клас. Stateful Stream Processing предлага уникален компромис за това. Той избягва централизирани “God Components”, които задържат напредъка. Освен това, той осигурява оперативност, мащабируемост и устойчивост на отказ на стрийминг pipelin-ите и ги добавя към всяка услуга. Следователно, можем да се фокусираме върху общия поток на съзнанието, към който може да се свърже всяка услуга и да работи с нейните данни. Така услугите стават по-мащабируеми, взаимозаменяеми и автономни. Те не само ще изглеждат добре на маркерните дъски и при проверките на хипотези, но и ще работят и ще се развиват десетилетия наред.
Източник: habr.com
