Отпорни стратегии во реалниот свет за Fintech проекти

Отпорноста во софтверот се однесува на способноста на апликацијата да продолжи да функционира непречено и сигурно, дури и при неочекувани проблеми или неуспеси. Во Fintech проектите, еластичноста е од особено големо значење поради неколку причини. Прво, компаниите се обврзани да ги исполнат регулаторните барања, а финансиските регулатори ја нагласуваат оперативната отпорност за одржување на стабилноста во системот. Покрај тоа, ширењето на дигиталните алатки и потпирањето на трети лица даватели на услуги ги изложуваат бизнисите на Fintech на зголемени безбедносни закани. Отпорноста, исто така, помага да се ублажат ризиците од прекини предизвикани од различни фактори како што се сајбер закани, пандемии или геополитички настани, заштитувајќи ги основните деловни операции и критичните средства. Според моделите на отпорност, разбираме збир на најдобри практики и стратегии дизајнирани да осигурат дека софтверот може да издржи пречки и да ги одржува своите операции. Овие модели делуваат како заштитни мрежи, обезбедувајќи механизми за справување со грешки, управување со оптоварувањето и закрепнување од неуспеси, со што се обезбедуваат апликациите да останат робусни и доверливи под неповолни услови. Најчестите стратегии за еластичност вклучуваат преграда, кеш, резерва, повторно обид и прекинувач. Во оваа статија, ќе разговарам за нив подетално, со примери на проблеми што можат да помогнат да се решат. Преграда Дозволете ни да ја погледнеме горната поставка. Имаме многу обична апликација со неколку бекенд зад нас за да добиеме некои податоци. Постојат неколку HTTP-клиенти поврзани со овие позадини. Излегува дека сите го делат истиот базен за поврзување! И, исто така, други ресурси како процесорот и RAM меморијата. Што ќе се случи. Поради големото време на одговор, целиот базен за поврзување ќе стане целосно окупиран од барања кои чекаат одговори од backend1. Како резултат на тоа, барањата наменети за здравиот backend2 и backend3 нема да можат да продолжат бидејќи базенот е исцрпен. Ова значи дека неуспехот во еден од нашите задни делови може да предизвика дефект на целата апликација. Идеално, сакаме само функционалноста поврзана со неуспешниот заден дел да доживее деградација, додека остатокот од апликацијата продолжува да работи нормално. Што е моделот на преградата? Терминот, преграда шема, произлегува од бродоградба, тој вклучува создавање на неколку изолирани прегради во рамките на бродот. Ако дојде до истекување во едната преграда, таа се полни со вода, но другите прегради остануваат непроменети. Оваа изолација го спречува потонувањето на целиот сад поради едно пробивање. Како можеме да го искористиме моделот на преградата за да го решиме овој проблем? Шаблонот Bulkhead може да се користи за изолирање на различни видови ресурси во апликацијата, спречувајќи дефект во еден дел да влијае на целиот систем. Еве како можеме да го примениме на нашиот проблем: Изолирање на базени за поврзување Можеме да создадеме одделни базени за поврзување за секој заден дел (backend1, backend2, backend3). Ова осигурува дека ако backend1 доживува високи времиња на одговор или неуспеси, неговиот базен за поврзување ќе се исцрпи независно, оставајќи ги базените за поврзување за backend2 и backend3 непроменети. Оваа изолација им овозможува на здравите задни делови да продолжат нормално да ги обработуваат барањата. Ограничување на ресурсите за активности во заднина Со користење на прегради, можеме да доделиме конкретни ресурси за активности во заднина, како што се сериска обработка или закажани задачи. Ова ги спречува овие активности да трошат ресурси потребни за операции во реално време. На пример, можеме да го ограничиме бројот на нишки или користење на процесорот посветени на задачите во заднина, осигурувајќи дека остануваат достапни доволно ресурси за справување со дојдовните барања. Поставување ограничувања за дојдовни барања Преградите може да се применат и за ограничување на бројот на дојдовни барања на различни делови од апликацијата. На пример, можеме да поставиме максимално ограничување на бројот на барања што може да се обработуваат истовремено за секоја услуга нагоре. Ова го спречува секој поединечен заден дел да го надвладее системот и гарантира дека другите задни делови можат да продолжат да функционираат дури и ако некој е под тежок товар. Сache Да претпоставиме дека нашите задни системи имаат мала веројатност да наидат на грешки поединечно. Меѓутоа, кога операцијата вклучува барање на сите овие задни делови паралелно, секој може самостојно да врати грешка. Бидејќи овие грешки се случуваат независно, вкупната веројатност за грешка во нашата апликација е поголема од веројатноста за грешка на која било поединечна основа. Кумулативната веројатност за грешка може да се пресмета со формулата P_total=1−(1−p)^n, каде n е бројот на задни системи. На пример, ако имаме десет задни страници, секој со веројатност за грешка од p=0,001 (што одговара на SLA од 99,9%), веројатноста за грешка што произлегува е: P_total=1−(1−0,001)^10=0,009955 Ова значи дека нашата комбинирана SLA паѓа на приближно 99%, што илустрира како се намалува севкупната доверливост при паралелно пребарување на повеќе задни делови. За да го ублажиме овој проблем, можеме да имплементираме кеш во меморијата. Како можеме да го решиме со кешот во меморијата Кешот во меморијата служи како бафер за податоци со голема брзина, складирајќи често пристапувани податоци и елиминирајќи ја потребата да се преземаат од потенцијално бавните извори секој пат. Бидејќи кешовите складирани во меморијата имаат 0% шанса за грешка во споредба со преземањето податоци преку мрежата, тие значително ја зголемуваат веродостојноста на нашата апликација. Покрај тоа, кеширањето го намалува мрежниот сообраќај, што дополнително ја намалува можноста за грешки. Следствено, со користење на кеш во меморијата, можеме да постигнеме уште помала стапка на грешки во нашата апликација во споредба со нашите задни системи. Дополнително, кешовите во меморијата нудат побрзо преземање податоци отколку преземањето базирано на мрежа, со што се намалува доцнењето на апликацијата - забележлива предност. Кеш во меморијата: персонализирани кешови За персонализирани податоци, како што се кориснички профили или препораки, користењето кешови во меморијата може да биде исто така високо ефективно. Но, ние треба да обезбедиме сите барања од корисникот постојано да одат во истиот примерок на апликација за да ги искористиме податоците што се кеширани за нив, што бара лепливи сесии. Спроведувањето на лепливи сесии може да биде предизвик, но за ова сценарио, не ни требаат сложени механизми. Мало ребалансирање на сообраќајот е прифатливо, така што ќе биде доволен стабилен алгоритам за балансирање на оптоварување како конзистентно хаширање. Уште повеќе, во случај на неуспех на јазолот, конзистентното хаширање осигурува дека само корисниците поврзани со неуспешниот јазол се подложени на ребалансирање, минимизирајќи го нарушувањето на системот. Овој пристап го поедноставува управувањето со персонализираните кешови и ја подобрува целокупната стабилност и перформанси на нашата апликација. Кеш во меморијата: репликација на локални податоци Ако податоците што имаме намера да ги кешираме се критични и се користат во секое барање со кое се справува нашиот систем, како што се политиките за пристап, плановите за претплата или други витални ентитети во нашиот домен - изворот на овие податоци може да претставува значајна точка на неуспех во нашиот систем. За да се одговори на овој предизвик, еден пристап е целосно да се реплицираат овие податоци директно во меморијата на нашата апликација. Во ова сценарио, ако обемот на податоци во изворот може да се управува, можеме да го иницираме процесот со преземање слика од овие податоци на почетокот на нашата апликација. Последователно, можеме да примаме настани за ажурирање за да се осигураме дека кешираните податоци остануваат синхронизирани со изворот. Со прифаќање на овој метод, ја подобруваме веродостојноста на пристапот до овие клучни податоци, бидејќи секое преземање се случува директно од меморијата со 0% веројатност за грешка. Дополнително, преземањето податоци од меморијата е исклучително брзо, а со тоа се оптимизираат перформансите на нашата апликација. Оваа стратегија ефикасно го ублажува ризикот поврзан со потпирањето на надворешен извор на податоци, обезбедувајќи постојан и сигурен пристап до критичните информации за работата на нашата апликација. Конфигурација што може повторно да се вчита Меѓутоа, потребата за преземање податоци за стартување на апликацијата, со што се одложува процесот на стартување, прекршува еден од принципите на „апликацијата со 12 фактори“ што се залага за брзо стартување на апликацијата. Но, не сакаме да ги изгубиме придобивките од користењето кеширање. За да ја решиме оваа дилема, ајде да истражиме потенцијални решенија. Брзото стартување е од клучно значење, особено за платформи како Kubernetes, кои се потпираат на брза миграција на апликации до различни физички јазли. За среќа, Kubernetes може да управува со апликации кои бавно стартуваат користејќи функции како сонди за стартување. Друг предизвик со кој може да се соочиме е ажурирање на конфигурациите додека апликацијата работи. Честопати, прилагодувањето на времето на кешот или истекувањето на барањето е неопходно за да се решат проблемите со производството. Дури и ако можеме брзо да распоредиме ажурирани конфигурациски датотеки на нашата апликација, примената на овие промени обично бара рестартирање. Со продолженото време за стартување на секоја апликација, повторното рестартирање може значително да го одложи распоредувањето на поправките за нашите корисници. За да се справите со ова, едно решение е да се зачуваат конфигурациите во истовремена променлива и да се има позадинска нишка периодично да се ажурира. Сепак, одредени параметри, како што е истекувањето на барањето HTTP, може да бараат реиницијализирање на HTTP или клиентите на базата на податоци кога соодветната конфигурација се менува, што претставува потенцијален предизвик. Сепак, некои клиенти, како двигателот Cassandra за Java, поддржуваат автоматско повторно вчитување на конфигурациите, поедноставувајќи го овој процес. Спроведувањето на конфигурации за повторно вчитување може да го ублажи негативното влијание од долгите времиња на стартување на апликациите и да понуди дополнителни придобивки, како што е олеснување на имплементацијата на знаменцето за функции. Овој пристап ни овозможува да ја одржиме доверливоста и одговорноста на апликацијата додека ефикасно управуваме со ажурирањата на конфигурацијата. Резервација Сега да погледнеме уште еден проблем: во нашиот систем, кога барањето од корисникот е примено и обработено со испраќање барање до заднина или база на податоци, повремено, се добива одговор на грешка наместо очекуваните податоци. Последователно, нашиот систем одговара на корисникот со „грешка“. Меѓутоа, во многу сценарија, можеби е подобро да се прикажат малку застарени податоци заедно со порака што укажува дека има доцнење со освежување на податоците, наместо да го оставите корисникот со голема црвена порака за грешка. За да го решиме овој проблем и да го подобриме однесувањето на нашиот систем, можеме да ја имплементираме шаблонот за враќање. Концептот зад оваа шема вклучува поседување секундарен извор на податоци, кој може да содржи податоци со послаб квалитет или свежина во споредба со примарниот извор. Ако примарниот извор на податоци е недостапен или врати грешка, системот може да се врати на враќање на податоците од овој секундарен извор, осигурувајќи се дека некоја форма на информација е претставена на корисникот наместо да се прикаже порака за грешка. Обидете се повторно Ако ја погледнете сликата погоре, ќе забележите сличност помеѓу проблемот со кој се соочуваме сега и оној што го наидовме со примерот на кешот. За да го решиме, можеме да размислиме за спроведување на шема позната како повторно обид. Наместо да се потпира на кеш меморија, системот може да биде дизајниран така што автоматски повторно го испраќа барањето во случај на грешка. Оваа шема за повторно обиди нуди поедноставна алтернатива и може ефикасно да ја намали веројатноста за грешки во нашата апликација. За разлика од кеширањето, кое често бара сложени механизми за поништување на кешот за да се справи со промените на податоците, повторното обид за неуспешни барања е релативно едноставно за спроведување. Бидејќи поништувањето на кешот нашироко се смета за една од најпредизвикувачките задачи во софтверското инженерство, усвојувањето стратегија за повторно обид може да го рационализира справувањето со грешките и да ја подобри еластичноста на системот. Прекинувач Сепак, усвојувањето стратегија за повторно обид без да се земат предвид потенцијалните последици може да доведе до дополнителни компликации. Ајде да замислиме дека еден од нашите заднини ќе доживее неуспех. Во такво сценарио, иницирањето повторни обиди за неуспешниот заден дел може да резултира со значително зголемување на обемот на сообраќај. Овој ненадеен наплив на сообраќај може да го надвладее задниот дел, влошувајќи го неуспехот и потенцијално предизвикувајќи каскаден ефект низ системот. За да се справите со овој предизвик, важно е да ја надополните шемата за повторно обиди со шемата на прекинувачот. Автоматскиот прекинувач служи како заштитен механизам кој ја следи стапката на грешка на долните услуги. Кога стапката на грешка ќе го надмине однапред дефинираниот праг, прекинувачот ги прекинува барањата до засегнатата услуга за одредено времетраење. Во текот на овој период, системот се воздржува од испраќање дополнителни барања за да се овозможи враќање на неуспешното време на услугата. По назначениот интервал, прекинувачот внимателно дозволува да поминат ограничен број барања, проверувајќи дали услугата е стабилизирана. Ако услугата се опорави, нормалниот сообраќај постепено се враќа; во спротивно, колото останува отворено, продолжувајќи да блокира барања додека услугата не продолжи со нормална работа. Со интегрирање на шемата на прекинувачот заедно со логиката за повторно обид, можеме ефикасно да управуваме со ситуациите на грешки и да спречиме преоптоварување на системот за време на дефекти на задниот дел. Завиткување Како заклучок, со имплементирање на овие модели на отпорност, можеме да ги зајакнеме нашите апликации против итни случаи, да одржуваме висока достапност и да им понудиме беспрекорно искуство на корисниците. Дополнително, би сакал да нагласам дека телеметријата е уште една алатка што не треба да се занемари кога се обезбедува отпорност на проектот. Добрите дневници и метрика можат значително да го подобрат квалитетот на услугите и да обезбедат вредни сознанија за нивните перформанси, помагајќи да се донесат информирани одлуки за нивно дополнително подобрување.