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

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

Најчешће стратегије отпорности укључују преграду, кеш меморију, резервни, поновни покушај и прекидач. У овом чланку ћу их детаљније размотрити, уз примере проблема које могу помоћи да се реше.

Преграда

Хајде да погледамо горњу поставку. Имамо врло обичну апликацију са неколико бацкенд-а иза нас да добијемо неке податке. Постоји неколико ХТТП клијената повезаних са овим бацкендовима. Испоставило се да сви они деле исти скуп веза! А такође и други ресурси као што су ЦПУ и РАМ.

Шта ће се десити, ако један од позадинских делова искуси неку врсту проблема који резултира великим кашњењем захтева? Због великог времена одговора, цео скуп веза ће постати у потпуности заузет захтевима који чекају одговоре од бацкенд1. Као резултат тога, захтеви намењени здравим бацкенд2 и бацкенд3 неће моћи да се наставе јер је скуп исцрпљен. То значи да квар у једном од наших позадинских делова може изазвати квар у целој апликацији. У идеалном случају, желимо да само функционалност повезана са неисправним позадинским делом доживи деградацију, док остатак апликације настави да ради нормално.

Како можемо да користимо шаблон преграде да решимо овај проблем?

Шаблон Булкхеад се може користити за изоловање различитих типова ресурса унутар апликације, спречавајући да квар у једном делу утиче на цео систем. Ево како то можемо применити на наш проблем:

1. Изоловање скупова конекција Можемо креирати одвојене скупове конекција за сваку позадину (бацкенд1, бацкенд2, бацкенд3). Ово осигурава да ако бацкенд1 има велико време одговора или грешке, његово спремиште веза ће бити исцрпљено независно, остављајући скупове веза за бацкенд2 и бацкенд3 непромењене. Ова изолација омогућава здравим бацкендовима да нормално наставе са обрадом захтева.
2. Ограничавање ресурса за позадинске активности Коришћењем преграда можемо доделити специфичне ресурсе за позадинске активности, као што су групна обрада или заказани задаци. Ово спречава ове активности да троше ресурсе потребне за операције у реалном времену. На пример, можемо ограничити број нити или коришћење ЦПУ-а посвећених задацима у позадини, обезбеђујући да довољно ресурса остане на располагању за руковање долазним захтевима.
3. Постављање ограничења за долазне захтеве Преграде се такође могу применити да би се ограничио број долазних захтева на различите делове апликације. На пример, можемо да поставимо максимално ограничење броја захтева који се могу обрадити истовремено за сваку узводну услугу. Ово спречава да било који позадински систем преплави систем и осигурава да други позадински системи могу да наставе да функционишу чак и ако је један под великим оптерећењем.

Сацхе

Претпоставимо да наши позадински системи имају малу вероватноћу да појединачно наиђу на грешке. Међутим, када операција укључује паралелно испитивање свих ових позадина, сваки може независно да врати грешку. Пошто се ове грешке јављају независно, укупна вероватноћа грешке у нашој апликацији је већа од вероватноће грешке било ког појединачног позадинског дела. Кумулативна вероватноћа грешке се може израчунати коришћењем формуле П_тотал=1−(1−п)^н, где је н број позадинских система.

На пример, ако имамо десет позадинских делова, сваки са вероватноћом грешке п=0,001 (што одговара СЛА од 99,9%), резултујућа вероватноћа грешке је:

П_укупно=1−(1−0,001)^10=0,009955

То значи да наш комбиновани СЛА пада на приближно 99%, што илуструје како се укупна поузданост смањује када се истовремено испитује више позадинских система. Да бисмо ублажили овај проблем, можемо имплементирати кеш меморију.

Како то можемо решити помоћу кеша у меморији

Кеш меморија у меморији служи као бафер података велике брзине, чувајући податке којима се често приступа и елиминишући потребу да их сваки пут преузимате из потенцијално спорих извора. Пошто кеш меморија има 0% шансе за грешку у поређењу са преузимањем података преко мреже, они значајно повећавају поузданост наше апликације. Штавише, кеширање смањује мрежни саобраћај, додатно смањујући шансе за грешке. Сходно томе, коришћењем кеша у меморији, можемо постићи још нижу стопу грешака у нашој апликацији у поређењу са нашим позадинским системима. Поред тога, кеш меморије нуди брже преузимање података од преузимања заснованог на мрежи, чиме се смањује кашњење апликације – приметна предност.

Кеш меморија: Персонализоване кеш меморије

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

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

Кеш меморија: локална репликација података

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

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

Релоадабле цонфиг

Међутим, потреба за преузимањем података о покретању апликације, чиме се одлаже процес покретања, крши један од принципа '12-факторске апликације' који се залаже за брзо покретање апликације. Али, не желимо да изгубимо предности коришћења кеширања. Да бисмо решили ову дилему, истражимо потенцијална решења.

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

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

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

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

Фаллбацк

Хајде сада да погледамо још један проблем: у нашем систему, када се кориснички захтев прими и обради слањем упита на позадину или базу података, повремено се прима одговор на грешку уместо очекиваних података. Након тога, наш систем одговара кориснику 'грешком'.

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

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

Покушајте поново

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

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

Прекидач

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

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

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

Враппинг Уп

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