🥇Случајеви употребе сервис мреже

Белешка. трансл.: Аутор овог чланка (Луц Перкинс) је заговорник програмера у организацији ЦНЦФ, која је дом таквих пројеката отвореног кода као што су Линкерд, СМИ (Сервице Месх Интерфаце) и Кума (успут, да ли сте се такође питали зашто је Истио није на овој листи? .). Још једном покушавајући да ДевОпс заједници донесе боље разумевање трендовског хајпа званог „сервисна мрежа“, он наводи 16 карактеристичних могућности које таква решења пружају.

Данас сервисна мрежа ― једна од најтоплијих тема у области софтверског инжењеринга (и то с правом!). Мислим да је ова технологија невероватно обећавајућа и волео бих да је широко прихваћен (када има смисла, наравно). Међутим, и даље је окружен ауром мистерије за већину људи. Истовремено, чак и они који познат са њим је често тешко формулисати његове предности и шта је тачно (укључујући и ваше заиста). У овом чланку покушаћу да исправим ситуацију набрајајући разне случајеви употребе „сервисне мреже“*.

* Белешка превод: овде и даље у чланку управо овај превод („сервисна мрежа”) користиће се за још увек нови термин сервисна мрежа.

Али прво желим да дам неколико коментара:

Никада нисам радио са сервисним мрежама нити их користио ван пројеката започетих за сопствено образовање. С друге стране, ја сам 2015. написао гомилу документације за Твитер-ову интерну сервисну мрежу (тада се није ни звала „сервисна мрежа“) и учествовао у изради веб сајта и документације за Линкерд, па то нешто значи.
Моја листа је приближна и непотпуна. Можда постоје случајеви коришћења који су мени непознати, а нове опције ће се вероватно појавити током времена како се технологија буде развијала и њена популарност расте.
Истовремено, не подржава свака постојећа имплементација сервисне мреже све наведене случајеве употребе. Стога, моје изјаве попут „сервисне мреже могу...“ треба читати као „појединачне, а можда и све популарне имплементације сервисне мреже могу...“.
Редослед примера не прави никакву разлику.

Кратка листа:

откривање услуге;
енкрипција;
аутентификација и ауторизација;
балансирање оптерећења;
прекид струјног кола;
аутоматско скалирање;
канаринац распоређивање;
плаво-зелено распоређивање;
здравствени преглед;
растерећење;
пресликавање саобраћаја;
изолација;
ограничење брзине захтева, покушаји и временска ограничења;
телеметрија;
ревизија;
визуелизација.

1. Откриће услуге

ТЛ;ДР: Повежите се са другим сервисима на мрежи користећи једноставна имена.

Услуге би требало да буду у могућности да аутоматски „пронађу” једна другу користећи адекватна имена – на пример, service.api.production, pets/staging или cassandra. Окружење у облаку је еластично, а једно име може сакрити многе инстанце услуге. Јасно је да је у таквој ситуацији физички немогуће хардкодирати све ИП адресе.

Плус, када једна услуга пронађе другу, требало би да буде у могућности да шаље захтеве тој услузи без страха да ће завршити на улазу њене покварене инстанце. Другим речима, сервисна мрежа мора да надгледа здравље свих инстанци сервиса и да одржава листу хостова што је могуће ажурираном.

Свака сервисна мрежа различито имплементира механизам откривања услуге. У овом тренутку, најчешћи начин је делегирање спољним процесима као што је Кубернетес ДНС. У прошлости смо на Твитеру користили систем именовања за ову сврху Финагле. Поред тога, сервисна мрежа омогућава да се појаве прилагођени механизми именовања (иако још нисам видео ниједну имплементацију СМ-а са таквом функционалношћу).

2. Шифровање

ТЛ;ДР: Ослободите се нешифрованог саобраћаја између услуга и учините овај процес аутоматизованим и скалабилним.

Лепо је знати да нападачи не могу да продру у вашу интерну мрежу. Заштитни зидови одлично раде ово. Али шта се дешава ако хакер уђе унутра? Да ли ће моћи да ради шта хоће са саобраћајем унутар службе? Надајмо се да се ово ипак неће догодити. Да бисте спречили овај сценарио, требало би да примените мрежу са нултим поверењем у којој је сав саобраћај између услуга шифрован. Већина модерних сервисних мрежа то постиже узајамним ТЛС (узајамни ТЛС, мТЛС). У неким случајевима, мТЛС ради у целим облацима и кластерима (мислим да ће међупланетарне комуникације једног дана бити уређене на сличан начин).

Наравно, за мТЛС сервисну мрежу опционо. Свака услуга може да се брине о сопственом ТЛС-у, али то значи да ћете морати да пронађете начин да генеришете сертификате, дистрибуирате их на хостове сервиса и укључите код у апликацију која ће учитати ове сертификате из датотека. Да, не заборавите да обнављате ове сертификате у редовним интервалима. Сервисне мреже аутоматизују мТЛС са системима као што су СПИФФЕ, који, заузврат, аутоматизују процес издавања и ротације сертификата.

3. Аутентификација и ауторизација

ТЛ;ДР: Утврдите ко је подносилац захтева и дефинишите шта им је дозвољено да раде пре него што захтев уопште стигне до услуге.

Службе често желе да знају који врши захтев (аутентификацију), и користећи ове информације одлучује да датом субјекту је дозвољено да уради (овлашћење). У овом случају, заменица „ко“ може сакрити:

Друге услуге. Ово се зове "аутентификација" вршњак" На пример, услуга web жели да приступи сервису db. Сервисне мреже обично решавају такве проблеме користећи мТЛС: сертификати у овом случају делују као неопходан идентификатор.
Неки људи људи. Ово се зове "аутентификација" захтев" На пример, корисник haxor69 жели да купи нову лампу. Сервисне мреже пружају различите механизме, нпр. ЈСОН веб жетони.
Многи од нас су то урадили у коду апликације. Стиже захтев, гледамо кроз табелу users, пронађите корисника и упоредите лозинку, а затим проверите колону permissions итд. У случају сервисне мреже, ово се дешава пре него што захтев уопште стигне до услуге.

Када утврдимо од кога је дошао захтев, морамо да утврдимо шта је овом ентитету дозвољено да ради. Неке мреже услуга вам омогућавају да поставите основне смернице (о томе ко може шта да ради) као ИАМЛ датотеке или на командној линији, док друге нуде интеграцију са оквирима као што је Опен Полици Агент. Крајњи циљ је да ваше услуге прихвате сваки захтев, безбедно под претпоставком да долази из извора од поверења и ова радња је дозвољена.

4. Балансирање оптерећења

ТЛ;ДР: Распоредите оптерећење на инстанце услуге према одређеном обрасцу.

„Услуга“ у оквиру сервисне секције се често састоји од много идентичних инстанци. На пример, данас сервис cache састоји се од 5 примерака, а сутра њихов број може порасти на 11. Захтеви послати на cache, морају се дистрибуирати у складу са одређеном наменом. На пример, минимизирајте кашњење или повећајте вероватноћу да дођете до радне инстанце. Алгоритам који се најчешће користи је Роунд-робин, али постоје многи други - на пример, пондерисани метод (пондерисано) упити (можете да изаберете жељене циљеве), звоно (прстен) хеширање (користећи доследно хеширање на узводним хостовима) или метод најмањег захтева (предност се даје инстанци са најмање захтева).

Класични балансери имају и друге функције, као што су ХТТП кеширање и ДДоС заштита, али нису много релевантни за саобраћај исток-запад (тј. за саобраћај који тече унутар центра података – прибл. прев.) (типичан опсег сервисне мреже). Наравно, није неопходно користити сервисну мрежу за балансирање оптерећења, али вам омогућава да поставите и контролишете политике балансирања за сваку услугу са централизованог контролног слоја, чиме се елиминише потреба за покретањем и конфигурисањем одвојених балансера оптерећења у мрежном стеку. .

5. Прекид струјног кола

ТЛ;ДР: Зауставите саобраћај до проблематичне услуге и контролишите штету у најгорем случају.

Ако из неког разлога услуга не може да се носи са саобраћајем, сервисна мрежа нуди неколико опција за решавање овог проблема (о осталима ће бити речи у одговарајућим одељцима). Прекид струјног кола је најтежа опција за искључење услуге из саобраћаја. Међутим, само по себи то нема смисла - потребан је резервни план. Може се обезбедити повратни притисак (притисак на леђима) сервисима који упућују захтеве (само не заборавите да конфигуришете своју мрежу сервиса за ово!), или, на пример, обојење статусне странице у црвено и преусмеравање корисника на другу верзију странице са „китом који пада“ („Твитер је доле”).

Сервисне мреже не само да вам омогућавају да дефинишете када уследиће гашење и да ово ће уследити. У овом случају, „када“ може укључити било коју комбинацију наведених параметара: укупан број захтева за одређени период, број паралелних веза, захтева на чекању, активних поновних покушаја итд.

Вероватно не желите да злоупотребљавате прекид струјног кола, али лепо је знати да имате резервни план у случају нужде.

6. Аутоматско скалирање

ТЛ;ДР: Повећајте или смањите број инстанци услуге у зависности од наведених критеријума.

Сервисне мреже нису планери, па нису извршити скалирање себе. Међутим, они могу дати информације на основу којих ће планери заснивати своје одлуке. Пошто сервисне мреже имају приступ целокупном саобраћају између сервиса, оне имају опсежне информације о томе шта се дешава: које услуге имају проблеме, које услуге су веома мало оптерећене (капацитет који им је додељен је изгубљен) итд.

На пример, Кубернетес скалира услуге на основу ЦПУ-а и употребе меморије подова (погледајте наш извештај "Аутоматско скалирање и управљање ресурсима у Кубернетесу“ – прибл. превод), али ако одлучите да скалирате на основу било које друге метрике (у нашем случају која се односи на саобраћај), биће вам потребна посебна метрика. Менаџмент овако показује како се то ради са изасланик, Истио и Прометеј, али сам процес је прилично компликован. Желели бисмо да сервисна мрежа ово поједностави дозвољавајући нам да једноставно поставимо услове као што су „повећати број инстанци услуге auth, ако број захтева на чекању пређе праг у року од једног минута.“

7. Цанари распоређивање

ТЛ;ДР: Тестирајте нове функције или верзије услуга на подскупу корисника.

Рецимо да развијате СааС производ и намеравате да уведете његову нову кул верзију. Тестирали сте га у инсценацији и одлично је функционисало. Али и даље постоје одређене забринутости око њеног понашања у стварним условима. Другим речима, морате да тестирате нову верзију на стварним проблемима без ризика од поверења корисника. Цанари имплементације су одличне за ово. Они вам омогућавају да демонстрирате нову функцију подскупу корисника. Овај подскуп може се састојати од најлојалнијих корисника или оних који раде са бесплатном верзијом производа, или корисника који су изразили жељу да буду „заморци“.

Сервисне мреже имплементирају ово тако што вам омогућавају да одредите критеријуме који одређују ко ће видети коју верзију апликације и усмеравати саобраћај у складу са тим. Међутим, ништа се не мења за саме услуге. Верзија 1.0 сервиса верује да сви захтеви долазе од корисника који би требало да је виде, а верзија 1.1 верује исто за своје кориснике. У међувремену, можете променити проценат саобраћаја између старе и нове верзије, преусмеравајући све већи број корисника на нову ако она ради стабилно и ваши „заморци“ дају зелено светло.

8. Плаво-зелено распоређивање

ТЛ;ДР: Представите нову нову функцију, али будите спремни да одмах вратите све.

Значење плаво-зелено распоређивање је да уведемо нову „плаву” услугу, лансирајући је паралелно са старом, „зеленом”. Ако све прође глатко и нова услуга добро ради, онда се стара може постепено онемогућити. (Авај, једног дана ће ова нова „плава” услуга поновити судбину „зеленог” и нестати...) Плаво-зелене примене се разликују од канарских по томе што нова функција покрива све одједном корисници (не део); Поента је да имамо спремну „сигурну луку“ у случају да нешто крене наопако.

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

Белешка. трансл.: Више о различитим стратегијама примене у Кубернетес-у (укључујући поменутог канаринца, плаво/зеленог и друге) можете прочитати у Овај чланак.

9. Здравствени преглед

ТЛ;ДР: Пратите које инстанце услуге су функционалне и одговорите на оне које више нису функционалне.

Здравствени преглед (здравствени преглед) помаже да се одлучи да ли су инстанце услуге спремне да прихвате и обрађују саобраћај. На пример, у случају ХТТП услуга, провера здравља може изгледати као ГЕТ захтев до крајње тачке /health... Одговор 200 OK ће значити да је инстанца здрава, било која друга - да није спремна за пријем саобраћаја. Сервисне мреже вам омогућавају да одредите и начин на који ће се функционалност проверавати и учесталост којом ће се ова провера обављати. Ове информације се затим могу користити у друге сврхе - на пример, за балансирање оптерећења и прекид кола.

Дакле, провера здравља није самосталан случај употребе, већ се обично користи за постизање других циљева. Такође, у зависности од резултата провере здравља, могу бити потребне радње које нису у односу на друге циљеве мреже: на пример, ажурирање странице статуса, креирање проблема на ГитХуб-у или попуњавање ЈИРА тикета. А сервисна мрежа нуди згодан механизам за аутоматизацију свега овога.

10. Скидање оптерећења

ТЛ;ДР: Преусмери саобраћај као одговор на привремени пораст употребе.

Ако је одређена услуга преоптерећена саобраћајем, можете привремено да преусмерите део овог саобраћаја на другу локацију (тј. „избацивање“, „пренос“ (шупа) него тамо). На пример, у сервис резервних копија или центар података, или у стални преса тема. Као резултат тога, услуга ће наставити да обрађује неке захтеве уместо да се сруши и потпуно заустави обраду свега. Раскид оптерећења је пожељнији од прекидања струјног кола, али се ипак не препоручује злоупотреба. Помаже у спречавању каскадних кварова који доводе до пада услуга на нижем току.

11. Паралелизација/зрцаљење саобраћаја

ТЛ;ДР: Пошаљите један захтев на више места одједном.

Понекад постоји потреба да се захтев (или одређени избор захтева) пошаље на неколико сервиса одједном. Типичан пример је слање дела продукцијског саобраћаја у сценску услугу. Главни производни веб сервер шаље захтев низводном сервису products.production и само њему. А сервисна мрежа интелигентно копира овај захтев и шаље га на products.staging, чега веб сервер није ни свестан.

Још један сродни случај коришћења мреже сервиса који се може применити на паралелизацију саобраћаја је регресија тестирање. То укључује слање истих захтева различитим верзијама услуге и проверу да ли се све верзије понашају исто. Још нисам наишао на имплементацију сервисне мреже са интегрисаним системом регресионог тестирања као што је Диффи, али сама идеја изгледа обећавајуће.

12. Изолација

ТЛ;ДР: Разбијте своју мрежу услуга на мини мреже.

Такође познат као сегментацијаИзолација је уметност поделе сервисне мреже на логички различите сегменте који не знају ништа један о другом. Изолација је помало попут стварања виртуелних приватних мрежа. Основна разлика је у томе што и даље можете уживати у свим предностима сервисне мреже (као што је откривање услуга), али уз додатну сигурност. На пример, ако нападач може да продре у услугу на једној подмрежи, неће моћи да види које услуге раде на другим подмрежама нити да пресреће њихов саобраћај.

Поред тога, користи могу бити и организационе. Можда ћете желети да подмрежите своје услуге на основу структуре ваше компаније и да ослободите програмере когнитивног оптерећења да морају да имају на уму целу мрежу услуга.

13. Ограничавање брзине захтева, покушаји и временска ограничења

ТЛ;ДР: Више не морате да укључујете детаљне задатке управљања захтевима у своју базу кодова.

Све ове ствари би се могле сматрати засебним случајевима коришћења, али сам одлучио да их комбинујем због једне заједничке карактеристике: оне преузимају задатке управљања животним циклусом захтева којима се обично баве библиотеке апликација. Ако развијате веб сервер у Руби он Раилс (није интегрисан са сервисном мрежом) који шаље захтеве позадинским услугама преко гРПЦ, апликација ће морати да одлучи шта да ради ако Н захтева не успе. Такође ћете морати да сазнате колико саобраћаја ће ове услуге моћи да обраде и хардкодирају ове параметре користећи специјалну библиотеку. Поред тога, апликација ће морати да одлучи када је време да одустане и дозволи да захтев нестане (на основу временског ограничења). А да бисте променили било који од горе наведених параметара, веб сервер ће морати да се заустави, поново конфигурише и поново покрене.

Пребацивање ових задатака на сервисну мрежу не само да значи да програмери услуга неће морати да размишљају о њима, већ и да их се може посматрати на глобалнији начин. Ако се користи сложени ланац услуга, рецимо А -> Б -> Ц -> Д -> Е, мора се узети у обзир цео животни циклус захтева. Ако је задатак да се продужи временско ограничење у сервису Ц, логично је да се то уради одједном, а не у деловима: ажурирањем сервисног кода и чекањем док се захтев за повлачењем не прихвати и ЦИ систем примени ажурирани сервис.

14. Телеметрија

ТЛ;ДР: Прикупите све потребне (и не сасвим) информације од услуга.

Телеметрија је општи термин који укључује метрику, дистрибуирано праћење и евиденције. Сервисне мреже нуде механизме за прикупљање и обраду сва три типа података. Овде ствари постају мало мутне јер је број могућих опција превелик. За прикупљање метрике постоји Прометеј и други алати који се могу користити за прикупљање трупаца флуентд, локи, вектор итд (на пример ЦлицкХоусе са нашим брвнара за К8с - прибл. превод), за дистрибуирано праћење постоји Стрелац и тако даље. Свака сервисна мрежа може подржавати неке алате, а друге не. Биће занимљиво видети да ли пројекат може Отворите телеметрију обезбеди извесну конвергенцију.

У овом случају, предност технологије сервисне мреже је у томе што контејнери за бочне приколице могу, у принципу, да прикупљају све горе наведене податке из својих услуга. Другим речима, имате на располагању један систем прикупљања телеметрије, а сервисна мрежа може да обрађује све ове информације на различите начине. На пример:

таил логс из одређене услуге у ЦЛИ;
прати обим захтева са контролне табле сервисне мреже;
прикупи дистрибуиране трагове и проследи их систему као што је Јаегер.

Пажња, субјективна процена: Уопштено говорећи, телеметрија је област у којој су јаке сметње мреже сервиса непожељне. Прикупљање основних информација и праћење у ходу неких златних метрика као што су стопа успешности захтева и кашњење је у реду, али надајмо се да нећемо видети да се појављују Франкенштајн стекови који покушавају да замене специјализоване системе, од којих су се неки већ доказали и добро проучени .

15. Ревизија

ТЛ;ДР: Они који забораве лекције историје осуђени су да их понављају.

Ревизија је уметност посматрања важних догађаја у систему. У случају мреже услуга, то би могло значити праћење ко је упутио захтеве одређеним крајњим тачкама за одређене услуге или колико пута се неки догађај везан за безбедност догодио у последњем месецу.

Јасно је да је ревизија веома блиско повезана са телеметријом. Разлика је у томе што се телеметрија обично повезује са стварима као што су продуктивност и технички интегритет, док се ревизија може односити на правна и друга питања која превазилазе стриктно техничку сферу (на пример, усаглашеност са ГДПР – Општом уредбом ЕУ о заштити података).

16. Визуелизација

ТЛ;ДР: Живео Реацт.јс - неисцрпни извор фенси интерфејса.

Можда постоји бољи термин, али ја га не знам. Једноставно мислим на графички приказ сервисне мреже или неке њене компоненте. Ове визуелизације могу укључивати индикаторе као што су просечне латенције, информације о конфигурацији приколице, резултати провере здравља и упозорења.

Рад у окружењу оријентисаном на услуге подразумева много веће когнитивно оптерећење у поређењу са Његовим Величанством Монолитом. Стога, когнитивни притисак треба смањити по сваку цену. Једноставан графички интерфејс за сервисну мрежу са могућношћу да кликнете на дугме и добијете жељени резултат могао би бити одлучујући за раст популарности ове технологије.

Нису уврштени на листу

Првобитно сам намеравао да укључим још неколико случајева употребе на листу, али сам онда одлучио да не. Ево их, заједно са разлозима за моју одлуку:

Центар за више података. По мом мишљењу, ово није толико случај употребе колико уска и специфична област примене сервисних мрежа или неког скупа функција попут откривања сервиса.
Улазак и излазак. Ово је сродна област, али сам се ограничио (можда вештачки) на случај употребе „саобраћај исток-запад“. Улазак и излазак заслужују посебан чланак.

Закључак

То је све за сада! Опет, ова листа је веома произвољна и највероватније непотпуна. Ако мислите да сам нешто пропустио или погрешио, контактирајте ме на Твитеру (@луцкеркинс). Молимо вас да поштујете правила пристојности.

ПС од преводиоца

Насловна илустрација за чланак је заснована на слици из чланка „Шта је сервисна мрежа (и када је користити)?"(од Грегорија Мекинона). Показује како су неке функционалности из апликација (у зеленој боји) прешле у сервисну мрежу која обезбеђује међусобне везе између њих (плаво).

Прочитајте и на нашем блогу:

Извор: ввв.хабр.цом