Ўсім прывітанне! У нас выдатныя навіны, у чэрвені OTUS зноў запускае курс , у сувязі з чым мы традыцыйна дзелімся з вамі карысным матэрыялам.
Калі вы сутыкнуліся з усёй гэтай гісторыяй з мікрасэрвісамі без якога-небудзь кантэксту, то вам даравальна лічыць яе крыху дзіўнай. Разбіццё прыкладання на фрагменты, звязаныя паміж сабой сеткай, абавязкова азначае даданне складаных рэжымаў адмоваўстойлівасці ў атрыманую размеркаваную сістэму.
Нягледзячы на тое, што такі падыход уключае ў сябе разбіццё на мноства незалежных сэрвісаў, канчатковая мэта куды больш, чым проста праца гэтых сэрвісаў на розных машынах. Размова тут ідзе аб узаемадзеянні з навакольным светам, які па сваёй сутнасці таксама размеркаваны. Не ў тэхнічным сэнсе, а хутчэй у сэнсе экасістэмы, якая складаецца са мноства людзей, каманд, праграм, і кожная з гэтых частак так ці інакш павінна выконваць сваю працу.
Кампаніі, напрыклад, уяўляюць з сябе набор размеркаваных сістэм, якія ў сукупнасці спрыяюць дасягненню некаторай мэты. Мы ігнаравалі гэты факт на працягу дзесяцігоддзяў, спрабуючы дабіцца аб'яднання, перадаючы файлы па FTP або карыстаючыся інструментамі карпаратыўнай інтэграцыі, пры гэтым засяроджваючыся на сваіх асабістых адасобленых мэтах. Але з прыходам сэрвісаў усё змянілася. Сэрвісы дапамаглі нам зазірнуць за гарызонт і ўбачыць свет узаемазалежных праграм, якія працуюць разам. Аднак, каб працаваць паспяхова, неабходна ўсвядоміць і спраектаваць два прынцыпова розных свету: знешні свет, дзе мы жывем у экасістэме мноства іншых сэрвісаў, і наш асабісты, унутраны свет, дзе мы кіруем у адзіночку.
Такі размеркаваны свет адрозніваецца ад таго, у якім мы выраслі і да якога абвыклі. Прынцыпы пабудовы традыцыйнай маналітнай архітэктуры не вытрымліваюць ніякай крытыкі. Таму правільнае разуменне такіх сістэм - гэта нешта большае, чым стварэнне класнай схемы на белай маркернай дошцы або круты доказ канцэпцыі. Размова ідзе аб тым, каб такая сістэма паспяхова працавала на працягу доўгага часу. На шчасце, сэрвісы існуюць ужо даўнавата, хоць і выглядаюць па-рознаму. усё яшчэ актуальныя, нават запраўленыя Docker, Kubernetes і злёгку патрапаныя хіпсцерскімі бародамі.
Такім чынам, сёння мы паглядзім на тое, як змяніліся правілы, чаму нам трэба пераасэнсаваць наш падыход да сэрвісаў і даных, якія яны перадаюць адзін аднаму, і чаму нам для гэтага спатрэбіцца зусім іншы інструментарый.
Інкапсуляцыя не заўсёды будзе вам сябрам
Мікрасэрвісы могуць працаваць незалежна адзін ад аднаго. Менавіта гэтая ўласцівасць надае ім найбольшую каштоўнасць. Гэтая ж уласцівасць дазваляе сэрвісам маштабавацца і расці. Не столькі ў сэнсе маштабавання да квадрыльёнаў карыстальнікаў або петабайт дадзеных (хоць і тут яны могуць дапамагчы), колькі ў сэнсе маштабавання з пункту гледжання людзей, паколькі каманды і арганізацыі растуць бесперапынна.
Аднак незалежнасць - гэта палка аб двух канцах. Гэта значыць сэрвіс сам па сабе можа круціцца лёгка і нязмушана. Але калі ўсярэдзіне сэрвісу рэалізуецца функцыя, якая патрабуе задзейнічаць іншы сэрвіс, то ў канчатковым выніку нам даводзіцца ўносіць змены ў абодва сэрвісу амаль адначасова. У маналіце гэта зрабіць лёгка, вы проста ўносіце змену і адпраўляеце ў рэліз, а вось у выпадку сінхранізацыі незалежных сэрвісаў праблем будзе больш. Каардынацыя паміж камандамі і рэлізнымі цыкламі разбурае гнуткасць.
У рамках стандартнага падыходу прыкрых скразных змен імкнуцца проста пазбягаць, выразна падзяляючы функцыянал паміж сэрвісамі. Сэрвіс адзінага ўваходу ў сістэму тут можа быць добры прыклад. У яго ёсць дакладна вызначаная роля, якая адрознівае яго ад іншых сэрвісаў. Такі выразны падзел азначае, што ў свеце хутка якія змяняюцца патрабаванняў да навакольных яго сэрвісаў, сэрвіс адзінага ўваходу ў сістэму ці наўрад будзе змяняцца. Ён існуе ў рамках строга абмежаванага кантэксту.
Праблема заключаецца ў тым, што ў рэальным свеце бізнес-сэрвісы не могуць пастаянна захоўваць аднолькава чысты падзел роляў. Напрыклад, тыя ж бізнэс-сэрвісы ў большай ступені працуюць з дадзенымі, якія паступаюць ад іншых такіх жа сэрвісаў. Калі вы займаецеся анлайн-рытэйлам, то апрацоўка струменя заказаў, каталога прадукцыі ці інфармацыі аб карыстачах стане патрабаваннем да шматлікіх вашых сэрвісаў. Кожнаму з сэрвісаў спатрэбіцца доступ да гэтых дадзеных.
Большасць бізнэс-сэрвісаў выкарыстоўваюць адзін і той жа струмень дадзеных, таму іх праца нязменна пераплятаецца.
Такім чынам мы падышлі да важнага моманту, пра які варта паразмаўляць. У той час як сэрвісы добра працуюць для кампанентаў інфраструктуры, якія працуюць у значнай ступені адасоблена, большасць бізнес-сэрвісаў аказваюцца пераплеценымі куды больш цесна.
Дыхатамія дадзеных
Падыходы, арыентаваныя на сэрвісы, магчыма, ужо існуюць, аднак у іх усё яшчэ мала інфармацыі аб тым, як абменьвацца вялікімі аб'ёмамі дадзеных паміж сэрвісамі.
Асноўная праблема заключаецца ў тым, што дадзеныя і сэрвісы неразлучныя. З аднаго боку, інкапсуляцыя заклікае нас хаваць дадзеныя, каб сэрвісы можна было аддзяліць сябар ад сябра і палегчыць іх рост і далейшыя змены. З іншага боку, нам трэба мець магчымасць свабодна падзяляць і панаваць над агульнымі дадзенымі, як і над любымі іншымі. Гаворка ідзе аб тым, каб мець магчымасць адразу ж пачаць працу, таксама свабодна, як і ў любой іншай інфармацыйнай сістэме.
Аднак у інфармацыйных сістэм мала агульнага з інкапсуляцыяй. Насамрэч нават наадварот. Базы дадзеных робяць усё, што могуць, каб даць доступ да якія захоўваюцца ў іх дадзеных. Яны пастаўляюцца з магутным дэкларатыўным інтэрфейсам, які дазваляе відазмяняць дадзеныя як вам трэба. Такі функцыянал важны на этапе папярэдніх даследаванняў, але не для кіравання расце складанасцю пастаянна развіваецца сэрвісу.
І тут узнікае дылема. Супярэчнасць. Дыхатамія. Бо інфармацыйныя сістэмы - гэта пра прадастаўленне дадзеных, а сэрвісы - пра ўтойванне.
Гэтыя дзве сілы фундаментальныя. Яны ляжаць у аснове большай часткі нашай працы, якія пастаянна змагаючыся за перавагу ў сістэмах, якія мы ствараем.
Па меры таго, як растуць і эвалюцыянуюць сістэмы сэрвісаў, мы бачым розныя праявы наступстваў дыхатаміі дадзеных. Або інтэрфейс сэрвісу будзе расці, падаючы ўсё шырэйшы набор функцый і пачне выглядаць як вельмі цудоўная дамарослая база дадзеных, альбо нас спасцігне расчараванне, і мы рэалізуем які-небудзь спосаб здабываць ці перамяшчаць масава цэлыя наборы дадзеных з сэрвісу ў сэрвіс.
У сваю чаргу стварэнне чаго-небудзь, што выглядае як цудоўная дамарослая база дадзеных прывядзе да цэлага шэрагу праблем. Мы не будзем удавацца ў падрабязнасці таго, чым небяспечная shared database, проста скажам, што яна ўяўляе з сябе значныя дарагія інжынерныя і аперацыйныя для кампаніі, якая спрабуе яе выкарыстоўваць.
Горш тое, што аб'ёмы даных прымнажаюць праблемы з межамі сэрвісаў. Чым больш агульных дадзеных ляжыць усярэдзіне сэрвісу, тым складаней стане інтэрфейс і тым складаней будзе аб'яднаць наборы дадзеных, якія паступаюць з розных сэрвісаў.
Альтэрнатыўны падыход з атрыманнем і перамяшчэннем цэлых набораў даных таксама мае свае праблемы. Распаўсюджаны паход да гэтага пытання выглядае як простае выманне і захоўванне набору дадзеных цалкам, а затым захоўванне яго лакальна ў кожным сэрвісе-спажыўцу.
Праблема заключаецца ў тым, што розныя сэрвісы па-рознаму інтэрпрэтуюць дадзеныя, якое яны спажываюць. Гэтыя дадзеныя заўсёды пад рукой. Яны мяняюцца і апрацоўваюцца лакальна. Даволі хутка яны перастаюць мець штосьці агульнае з дадзенымі ў крыніцы.
Чым больш мутабельныя копіі, тым больш дадзеныя будуць адрознівацца з цягам часу.
Што яшчэ горш, такія дадзеныя складана выправіць у рэтраспектыве ( тут сапраўды можа прыйсці на дапамогу). Насамрэч некаторыя з цяжкавырашальных тэхналагічных праблем, з якімі сутыкаецца бізнэс, узнікаюць з-за разнастайных дадзеных, якія множацца ад прыкладання да дадатку.
Каб знайсці вырашэнне гэтай праблемы аб агульных дадзеных трэба думаць інакш. Яны павінны стаць аб'ектамі першага класа ў архітэктурах, якія мы будуем. называе такія дадзеныя "вонкавымі", і гэта вельмі важная асаблівасць. Нам патрэбна інкапсуляцыя, каб не расчыняць унутраную прыладу сэрвісу, але мы павінны палегчыць сэрвісам доступ да сумесна выкарыстоўваных дадзеных, каб яны маглі карэктна выконваць сваю працу.
Праблема складаецца ў тым, што ніводны з падыходаў сёння ўжо не актуальны, паколькі ні інтэрфейсы сэрвісу, ні абмен паведамленнямі, ні Shared Database не прапануюць добрага рашэння для працы з вонкавымі дадзенымі. Інтэрфейсы сэрвісу дрэнна падыходзяць для абмену дадзенымі ў любым маштабе. Абмен паведамленнямі перамяшчае дадзеныя, але не захоўвае іх гісторыю, таму з часам дадзеныя пашкоджваюцца. Shared Databases занадта моцна факусуюцца ў адной кропцы, што стрымлівае развіццё прагрэсу. Мы непазбежна захрасваем у цыкле неплацежаздольнасці даных:
Цыкл неплацежаздольнасці даных
Патокі: дэцэнтралізаваны падыход да дадзеных і сэрвісаў
У ідэале нам трэба змяніць падыход да таго, як сэрвісы працуюць з агульнымі дадзенымі. На дадзены момант любы падыход сутыкаецца з вышэйзгаданай дыхатаміяй, паколькі не існуе ніякага чарадзейнага пылка, якой можна было б яго шчодра пасыпаць і зрабіць так, каб ён знік. Аднак мы можам пераасэнсаваць праблему і прыйсці да кампрамісу.
Гэты кампраміс мяркуе пэўную ступень цэнтралізацыі. Мы можам скарыстацца механізмам размеркаваных логаў, паколькі ён забяспечвае надзейныя якія маштабуюцца струмені. Цяпер трэба, каб сэрвісы маглі далучацца і працаваць гэтымі агульнымі патокамі, аднак мы хочам пазбегнуць складаных цэнтралізаваных God Service'аў, якія выконваюць такую апрацоўку. Таму лепшы варыянт - гэта ўбудаваць струменевую апрацоўку ў кожны сэрвіс-спажывец. Так сэрвісы змогуць аб'ядноўваць наборы даных з розных крыніц і працаваць з імі так, як ім трэба.
Адзін са спосабаў дасягнуць такога падыходу - гэта выкарыстанне стрымінгавай платформы. Існуе мноства варыянтаў, але сёння мы разгледзім менавіта Kafka, паколькі выкарыстанне яе Stateful Stream Processing дазваляе эфектыўна вырашаць прадстаўленую праблему.
Выкарыстанне механізму размеркаванага лагіравання дазваляе нам ісці па пратаптанай сцяжынцы, і выкарыстоўваць абмен паведамленнямі, каб працаваць з . Лічыцца, што такі падыход забяспечвае лепшае маштабаванне і падзел, чым механізм "запыт-адказ", паколькі ён аддае кіраванне патокам атрымальніку, а не адпраўніку. Аднак за ўсё ў гэтым жыцці даводзіцца плаціць, і тут вам спатрэбіцца брокер. Але для вялікіх сістэм гэты кампраміс таго варта (чаго не скажаш аб вашых сярэднестатыстычных вэб-прыкладаннях).
Калі за размеркаванае лагіраванне адказвае брокер, а не традыцыйная сістэма абмену паведамленнямі, можна скарыстацца дадатковымі асаблівасцямі. Транспарт можна лінейна маштабаваць амаль таксама добра, як размеркаваную файлавую сістэму. Дадзеныя могуць захоўвацца ў логах дастаткова доўга, таму мы атрымліваем не толькі абмен паведамленнямі, але і сховішча інфармацыі. Маштабаванае сховішча без страху атрымаць змяняецца агульны стан.
Затым можна выкарыстоўваць механізм stateful stream processing (апрацоўка патоку з захаваннем стану) для дадання дэкларатыўных інструментаў базы даных у сэрвісы-спажыўцы. Гэта вельмі важная думка. Пакуль дадзеныя захоўваюцца ў агульных плынях, да якіх могуць атрымліваць доступ усе сэрвісы, аб'яднанне і апрацоўка, якую робіць сэрвіс, з'яўляюцца прыватнымі. Яны аказваюцца ізаляванымі ўнутры строга абмежаванага кантэксту.
Пазбаўцеся ад дыхатаміі дадзеных, падзяліўшы імутабельны струмень станаў. Затым дадайце гэтую функцыю ў кожны сэрвіс з дапамогай Stateful Stream Processing.
Такім чынам, калі ваш сэрвіс павінен працаваць з замовамі, каталогам прадуктаў, складам, у яго будзе поўны доступ: толькі вы будзеце вырашаць, якія дадзеныя аб'ядноўваць, дзе іх апрацоўваць і як яны павінны мяняцца з цягам часу. Нягледзячы на тое, што гэтыя агульныя, работа з імі поўнасцю дэцэнтралізавана. Яна вырабляецца ўнутры кожнага сэрвісу, у свеце, дзе ўсё ідзе па вашых правілах.
Дзяліцеся дадзенымі так, каб не парушалася іх цэласнасць. Інкапсулюйце функцыю, а не крыніца, у кожным сэрвісе, якому ён патрэбен.
Так здараецца, што дадзеныя трэба масава перамясціць. Часам сэрвісу патрабуецца лакальны гістарычны набор дадзеных у абраным рухавіку базы дадзеных. Фокус у тым, што можна гарантаваць, што пры патрэбе копія можа быць адноўлена з крыніцы з дапамогай звароту ў механізм размеркаванага лагавання. Канектары ў Kafka выдатна спраўляюцца з гэтай задачай.
Такім чынам, у разгледжанага сёння падыходу ёсць некалькі пераваг:
- Дадзеныя выкарыстоўваюцца ў выглядзе агульных патокаў, якія могуць доўга захоўвацца ў логах, а сам механізм працы з агульнымі дадзенымі зашыты ў кожным асобным кантэксце, што дазваляе сэрвісам працаваць лёгка і хутка. Такім спосабам можна ўраўнаважыць дыхатамію дадзеных.
- Дадзеныя, якія паступаюць з розных сэрвісаў, могуць лёгка аб'ядноўвацца ў наборы. Такім чынам спрашчаецца ўзаемадзеянне з агульнымі дадзенымі і знікае неабходнасць у падтрымцы лакальных набораў дадзеных у базе даных.
- Stateful Stream Processing толькі кэшуе дадзеныя, а крыніцай ісціны застаюцца агульныя логі, таму праблема пашкоджання дадзеных з цягам часу стаіць не так востра.
- Па сваёй сутнасці, сэрвісы кіруюцца дадзенымі, гэта значыць нягледзячы на пастаянны рост аб'ёмаў дадзеных, сэрвісы ўсё яшчэ могуць хутка рэагаваць на бізнес-падзеі.
- Праблемы маштабаванасці кладуцца на брокера, а не на сэрвісы. Такім чынам значна памяншаецца складанасць напісання сэрвісаў, паколькі адсутнічае неабходнасць задумвацца аб маштабаванасці.
- Даданне новых сэрвісаў не патрабуе змены старых, таму падлучэнне новых сэрвісаў становіцца лягчэйшым.
Як бачыце, гэта больш, чым проста REST. Мы атрымалі набор інструментаў, які дазваляе працаваць з агульнымі дадзенымі дэцэнтралізавана.
У сённяшнім артыкуле былі раскрыты далёка не ўсе аспекты. Нам усё яшчэ трэба вызначыцца з тым, як балансаваць паміж парадыгмай «запыт-адказ» і падзейна-арыентаванай парадыгмай. Але з гэтым мы разбярэмся наступным разам. Ёсць тэмы, з якімі трэба пазнаёміцца лепей, напрыклад, чым так добры Stateful Stream Processing. Пра гэта мы пагаворым у трэцім артыкуле. А яшчэ існуюць іншыя магутныя канструкцыі, якімі мы можам скарыстацца, калі звернемся да іх, напрыклад, . З яе дапамогай мяняюцца правілы гульні для размеркаваных бізнес-сістэм, паколькі гэтая канструкцыя забяспечвае транзакцыйныя гарантыі для у маштабуецца форме. Пра гэта размова пойдзе ў чацвёртым артыкуле. І нарэшце нам трэба будзе прабегчыся па дэталях рэалізацыі гэтых прынцыпаў.
Але пакуль проста запомніце наступнае: дыхатамія дадзеных - гэта тая сіла, з якой мы сутыкаемся пры стварэнні бізнес-сэрвісаў. І мы павінны пра гэта памятаць. Фокус у тым, каб перавярнуць усё з ног на галаву і пачаць лічыць агульныя дадзеныя аб'ектамі першага класа. Stateful Stream Processing дае для гэтага ўнікальны кампраміс. Ён пазбягае цэнтралізаваных "God Components" якія стрымліваюць развіццё прагрэсу. Больш таго, ён забяспечвае аператыўнасць, маштабаванасць і адмоваўстойлівасць пайплайнаў стрымінгу дадзеных і дадае іх у кожны сэрвіс. Таму мы можам сфакусавацца на агульным струмені прытомнасці, да якога можа падлучыцца любы сэрвіс і працаваць з яго дадзенымі. Так сэрвісы атрымліваюцца больш якія маштабуюцца, узаемазаменнымі і аўтаномнымі. Таму яны будуць не толькі добра выглядаць на маркерных дошках і пры праверцы гіпотэз, але і працаваць і развівацца дзесяцігоддзямі.
Крыніца: habr.com