Здравейте всички! Имаме страхотни новини, OTUS стартира курса отново през юни , във връзка с което традиционно споделяме полезни материали с вас.
Ако сте се натъкнали на цялото това нещо с микроуслугите без никакъв контекст, ще ви бъде простено да го сметнете за малко странно. Разделянето на приложение на фрагменти, свързани с мрежа, задължително означава добавяне на сложни режими на устойчивост на грешки към получената разпределена система.
Въпреки че този подход включва разделянето му на много независими услуги, крайната цел е много повече от просто тези услуги да работят на различни машини. Тук говорим за взаимодействие с външния свят, което също е разпределено в своята същност. Не в технически смисъл, а по-скоро в смисъл на екосистема, която се състои от много хора, екипи, програми и всяка от тези части по някакъв начин трябва да си върши работата.
Компаниите, например, са набор от разпределени системи, които колективно допринасят за постигането на някаква цел. Ние пренебрегвахме този факт в продължение на десетилетия, опитвайки се да постигнем унификация чрез FTP файлове или използване на инструменти за корпоративна интеграция, като същевременно се фокусирахме върху собствените си изолирани цели. Но с появата на услугите всичко се промени. Услугите ни помогнаха да погледнем отвъд хоризонта и да видим свят от взаимозависими програми, които работят заедно. Въпреки това, за да работим успешно, е необходимо да разпознаем и проектираме два фундаментално различни свята: външния свят, където живеем в екосистема от много други услуги, и нашия личен, вътрешен свят, където управляваме сами.
Този разпределен свят е различен от този, в който сме израснали и с който сме свикнали. Принципите на изграждане на традиционната монолитна архитектура не издържат на критика. Така че правилната работа на тези системи е нещо повече от създаване на страхотна диаграма на бяла дъска или страхотно доказателство за концепцията. Въпросът е да се гарантира, че такава система работи успешно за дълъг период от време. За щастие, услугите съществуват от доста време, въпреки че изглеждат различно. все още са актуални, дори подправени с Docker, Kubernetes и леко опърпани хипстърски бради.
Затова днес ще разгледаме как са се променили правилата, защо трябва да преосмислим начина, по който подхождаме към услугите и данните, които те си предават един на друг, и защо ще имаме нужда от напълно различни инструменти, за да го направим.
Капсулирането не винаги ще бъде ваш приятел
Микроуслугите могат да работят независимо една от друга. Именно това свойство им придава най-голяма стойност. Същото това свойство позволява услугите да се мащабират и растат. Не толкова в смисъл на мащабиране до квадрилиони потребители или петабайти данни (въпреки че и те могат да помогнат там), а в смисъл на мащабиране по отношение на хора, тъй като екипите и организациите растат непрекъснато.
Независимостта обаче е нож с две остриета. Тоест самата услуга може да работи лесно и естествено. Но ако функция е внедрена в рамките на услуга, която изисква използването на друга услуга, тогава в крайна сметка трябва да направим промени и в двете услуги почти едновременно. В монолит това е лесно да се направи, просто правите промяна и я изпращате за освобождаване, но в случай на синхронизиране на независими услуги ще има повече проблеми. Координацията между екипите и циклите на освобождаване разрушава гъвкавостта.
Като част от стандартния подход те просто се опитват да избегнат досадните промени от край до край, като ясно разделят функционалността между услугите. Услугата за единично влизане може да бъде добър пример тук. Той има ясно дефинирана роля, която го отличава от другите услуги. Това ясно разделение означава, че в свят на бързо променящи се изисквания към услугите около него, услугата за единично влизане е малко вероятно да се промени. Съществува в строго ограничен контекст.
Проблемът е, че в реалния свят бизнес услугите не могат да поддържат същото чисто разделение на ролите през цялото време. Например същите бизнес услуги работят в по-голяма степен с данни, идващи от други подобни услуги. Ако се занимавате с онлайн търговия на дребно, обработката на потока от поръчки, продуктовия каталог или потребителската информация ще се превърнат в изискване за много от вашите услуги. Всяка от услугите ще се нуждае от достъп до тези данни, за да работи.
Повечето бизнес услуги споделят един и същ поток от данни, така че тяхната работа е неизменно преплетена.
Така стигаме до важен момент, за който си струва да говорим. Докато услугите работят добре за инфраструктурни компоненти, които работят до голяма степен изолирано, повечето бизнес услуги в крайна сметка се преплитат много по-тясно.
Дихотомия на данните
Подходи, ориентирани към услуги, може вече да съществуват, но все още им липсва представа за това как да се споделят големи количества данни между услугите.
Основният проблем е, че данните и услугите са неразделни. От една страна, капсулирането ни насърчава да скрием данните, така че услугите да могат да бъдат отделени една от друга и да улесни техния растеж и по-нататъшни промени. От друга страна, ние трябва да можем свободно да разделяме и завладяваме споделени данни, точно както всички други данни. Въпросът е да можете да започнете да работите веднага, толкова свободно, колкото във всяка друга информационна система.
Информационните системи обаче нямат много общо с капсулирането. Всъщност е точно обратното. Базите данни правят всичко възможно, за да осигурят достъп до данните, които съхраняват. Те идват с мощен декларативен интерфейс, който ви позволява да променяте данните според нуждите си. Подобна функционалност е важна на етапа на предварителни проучвания, но не и за управление на нарастващата сложност на непрекъснато развиваща се услуга.
И тук възниква една дилема. Противоречие. Дихотомия. В крайна сметка информационните системи са за предоставяне на данни, а услугите за скриване.
Тези две сили са фундаментални. Те са в основата на голяма част от нашата работа, като постоянно се борят за съвършенство в системите, които изграждаме.
Тъй като системите за услуги растат и се развиват, ние виждаме последствията от дихотомията на данните по много начини. Или интерфейсът на услугата ще се разрасне, за да предостави все по-широка гама от функционалности и ще започне да изглежда като много изискана домашна база данни, или ще се разочароваме и ще приложим някакъв начин за извличане или масово преместване на цели набори от данни от услуга на услуга.
На свой ред създаването на нещо, което изглежда като изискана домашна база данни, ще доведе до множество проблеми. Няма да навлизаме в подробности защо е опасно споделена база данни, нека просто кажем, че представлява значителни скъпи инженерни и оперативни разходи за компанията, която се опитва да го използва.
По-лошото е, че обемите данни увеличават проблемите с границите на услугата. Колкото повече споделени данни има в една услуга, толкова по-сложен ще стане интерфейсът и толкова по-трудно ще бъде комбинирането на набори от данни, идващи от различни услуги.
Алтернативният подход за извличане и преместване на цели набори от данни също има своите проблеми. Обичайният подход към този въпрос изглежда като просто извличане и съхраняване на целия набор от данни и след това съхраняването му локално във всяка консумираща услуга.
Проблемът е, че различните услуги интерпретират данните, които консумират, по различен начин. Тези данни са винаги под ръка. Те се модифицират и обработват локално. Много бързо те престават да имат нищо общо с данните в източника.
Колкото по-променливи са копията, толкова повече данните ще варират във времето.
За да влошат нещата, такива данни е трудно да се коригират в ретроспекция ( Това е мястото, където наистина може да дойде на помощ). Всъщност някои от трудноразрешимите технологични проблеми, с които се сблъскват фирмите, възникват от различни данни, които се умножават от приложение на приложение.
За да намерим решение на този проблем, трябва да мислим по различен начин за споделените данни. Те трябва да станат първокласни обекти в архитектурите, които изграждаме. нарича такива данни „външни“ и това е много важна характеристика. Нуждаем се от капсулиране, за да не излагаме вътрешната работа на дадена услуга, но трябва да улесним достъпа на услугите до споделени данни, за да могат да вършат работата си правилно.
Проблемът е, че нито един от двата подхода не е актуален днес, тъй като нито интерфейсите на услугата, нито съобщенията, нито споделената база данни предлагат добро решение за работа с външни данни. Сервизните интерфейси не са подходящи за обмен на данни във всякакъв мащаб. Съобщенията преместват данни, но не съхраняват тяхната история, така че данните се повреждат с времето. Споделените бази данни се фокусират твърде много върху една точка, което забавя напредъка. Неизбежно се забиваме в цикъл на повреда на данните:
Цикъл на отказ на данни
Потоци: децентрализиран подход към данни и услуги
В идеалния случай трябва да променим начина, по който услугите работят със споделени данни. В този момент и двата подхода се сблъскват с гореспоменатата дихотомия, тъй като няма магически прах, който може да бъде поръсен върху него, за да изчезне. Въпреки това можем да преосмислим проблема и да постигнем компромис.
Този компромис включва известна степен на централизация. Можем да използваме механизма за разпределени журнали, защото той осигурява надеждни, мащабируеми потоци. Сега искаме услугите да могат да се присъединяват и да работят върху тези споделени нишки, но искаме да избегнем сложни централизирани Божествени услуги, които извършват тази обработка. Следователно най-добрият вариант е да се вгради поточна обработка във всяка потребителска услуга. По този начин услугите ще могат да комбинират набори от данни от различни източници и да работят с тях по начина, по който се нуждаят.
Един от начините за постигане на този подход е чрез използването на платформа за стрийминг. Има много опции, но днес ще разгледаме Kafka, тъй като използването на неговата Stateful Stream Processing ни позволява ефективно да разрешим представения проблем.
Използването на механизъм за разпределено регистриране ни позволява да следваме добре утъпкания път и да използваме съобщения, за да работим с . Счита се, че този подход осигурява по-добро мащабиране и разделяне от механизма заявка-отговор, тъй като дава контрол върху потока на получателя, а не на подателя. Все пак за всичко в този живот трябва да се плаща, а тук трябва брокер. Но за големи системи компромисът си заслужава (което може да не е така за вашето средно уеб приложение).
Ако брокер е отговорен за разпределено регистриране, а не за традиционна система за съобщения, можете да се възползвате от допълнителни функции. Транспортът може да се мащабира линейно почти толкова добре, колкото и разпределена файлова система. Данните могат да се съхраняват в регистрационни файлове за доста дълго време, така че получаваме не само обмен на съобщения, но и съхранение на информация. Мащабируемо хранилище без страх от променливо споделено състояние.
След това можете да използвате обработка на поток със състояние, за да добавите декларативни инструменти за база данни към консумиращите услуги. Това е много важна идея. Въпреки че данните се съхраняват в споделени потоци, до които всички услуги имат достъп, агрегирането и обработката, извършвана от услугата, е частна. Те се оказват изолирани в строго ограничен контекст.
Елиминирайте дихотомията на данните чрез разделяне на неизменния поток от състояния. След това добавете тази функционалност към всяка услуга, използвайки Stateful Stream Processing.
Така, ако вашата услуга трябва да работи с поръчки, продуктов каталог, склад, тя ще има пълен достъп: само вие ще решавате какви данни да комбинирате, къде да ги обработвате и как да се променят във времето. Въпреки факта, че данните са споделени, работата с тях е напълно децентрализирана. Произвежда се във всяка услуга, в свят, където всичко върви според вашите правила.
Споделяйте данни, без да нарушавате целостта им. Капсулирайте функцията, а не източника, във всяка услуга, която се нуждае от нея.
Случва се данните да се преместват масово. Понякога дадена услуга изисква локален исторически набор от данни в избраната база данни. Номерът е, че можете да гарантирате, че ако е необходимо, копие може да бъде възстановено от източника чрез достъп до механизма за разпределено регистриране. Конекторите в Kafka вършат страхотна работа за това.
И така, обсъжданият днес подход има няколко предимства:
- Данните се използват под формата на общи потоци, които могат да се съхраняват в регистрационни файлове за дълго време, а механизмът за работа с общи данни е твърдо свързан във всеки отделен контекст, което позволява на услугите да работят лесно и бързо. По този начин може да се балансира дихотомията на данните.
- Данните, идващи от различни услуги, могат лесно да се комбинират в набори. Това опростява взаимодействието със споделените данни и елиминира необходимостта от поддържане на локални набори от данни в базата данни.
- Stateful Stream Processing само кешира данни, а източникът на истината остават общите регистрационни файлове, така че проблемът с повредата на данните във времето не е толкова остър.
- В основата си услугите са управлявани от данни, което означава, че въпреки непрекъснато нарастващите обеми от данни, услугите все още могат да реагират бързо на бизнес събития.
- Проблемите с мащабируемостта падат върху брокера, а не върху услугите. Това значително намалява сложността на писане на услуги, тъй като няма нужда да мислите за мащабируемост.
- Добавянето на нови услуги не изисква промяна на стари, така че свързването на нови услуги става по-лесно.
Както можете да видите, това е нещо повече от REST. Получихме набор от инструменти, които ви позволяват да работите със споделени данни по децентрализиран начин.
Не всички аспекти бяха обхванати в днешната статия. Все още трябва да разберем как да балансираме между парадигмата заявка-отговор и парадигмата, управлявана от събития. Но ще се занимаваме с това следващия път. Има теми, които трябва да опознаете по-добре, например защо Stateful Stream Processing е толкова добър. Ще говорим за това в третата статия. Има и други мощни конструкции, от които можем да се възползваме, ако прибегнем до тях, напр. . Той променя играта за разпределени бизнес системи, защото предоставя транзакционни гаранции за в мащабируема форма. Това ще бъде обсъдено в четвъртата статия. И накрая, ще трябва да разгледаме подробностите за прилагането на тези принципи.
Но засега просто запомнете това: дихотомията на данните е сила, с която се сблъскваме, когато създаваме бизнес услуги. И ние трябва да помним това. Номерът е да обърнете всичко с главата надолу и да започнете да третирате споделените данни като първокласни обекти. Stateful Stream Processing предоставя уникален компромис за това. Избягва централизирани „божествени компоненти“, които възпрепятстват прогреса. Освен това, той гарантира гъвкавостта, мащабируемостта и устойчивостта на тръбопроводите за поточно предаване на данни и ги добавя към всяка услуга. Следователно можем да се съсредоточим върху общия поток на съзнанието, към който всяка услуга може да се свърже и да работи със своите данни. Това прави услугите по-мащабируеми, взаимозаменяеми и автономни. Така че те не само ще изглеждат добре на бели дъски и тестове за хипотези, но и ще работят и ще се развиват в продължение на десетилетия.
Източник: www.habr.com