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