Рэальныя ўстойлівыя стратэгіі для фінтэх-праектаў

Устойлівасць праграмнага забеспячэння адносіцца да здольнасці прыкладання працягваць бесперабойную і надзейную працу нават ва ўмовах нечаканых праблем або збояў. У фінтэх-праектах устойлівасць асабліва важная па некалькіх прычынах. Па-першае, кампаніі абавязаны выконваць нарматыўныя патрабаванні, а фінансавыя рэгулятары падкрэсліваюць аперацыйную ўстойлівасць для падтрымання стабільнасці ў сістэме. Больш за тое, распаўсюджванне лічбавых інструментаў і залежнасць ад старонніх пастаўшчыкоў паслуг падвяргае фінтэх-бізнес павышаным пагрозам бяспекі. Устойлівасць таксама дапамагае знізіць рызыкі адключэнняў, выкліканых рознымі фактарамі, такімі як кіберпагрозы, пандэміі або геапалітычныя падзеі, абараняючы асноўныя бізнес-аперацыі і важныя актывы. Пад шаблонамі ўстойлівасці мы разумеем набор перадавых практык і стратэгій, прызначаных для таго, каб праграмнае забеспячэнне магло супрацьстаяць збоям і падтрымліваць сваю працу. Гэтыя шаблоны дзейнічаюць як сеткі бяспекі, забяспечваючы механізмы для апрацоўкі памылак, кіравання нагрузкай і аднаўлення пасля збояў, тым самым гарантуючы, што прыкладанні застаюцца трывалымі і надзейнымі ў неспрыяльных умовах. Найбольш распаўсюджаныя стратэгіі ўстойлівасці ўключаюць пераборку, кэш, рэзервовы рэжым, паўторную спробу і аўтаматычны выключальнік. У гэтым артыкуле я абмяркую іх больш падрабязна з прыкладамі праблем, якія яны могуць дапамагчы вырашыць. Пераборка Давайце паглядзім на прыведзены вышэй параметр. У нас ёсць вельмі звычайнае прыкладанне з некалькімі бэкэндамі, з якіх можна атрымаць некаторыя даныя. Ёсць некалькі HTTP-кліентаў, падлучаных да гэтых бэкэндаў. Аказваецца, усе яны маюць адзін і той жа пул злучэнняў! А таксама іншыя рэсурсы, такія як працэсар і аператыўная памяць. Што адбудзецца, калі адзін з бэкэндаў сутыкнецца з нейкімі праблемамі, што прывядзе да вялікай затрымкі запытаў? З-за высокага часу адказу ўвесь пул злучэнняў будзе цалкам заняты запытамі, якія чакаюць адказу ад бэкэнда1. У выніку запыты, прызначаныя для спраўнага бэкэнда 2 і бэкэнда 3, не змогуць працягнуць, таму што пул вычарпаны. Гэта азначае, што збой у адным з нашых бэкэндаў можа выклікаць збой ва ўсім дадатку. У ідэале мы хочам, каб пагаршалася толькі функцыянальнасць, звязаная з няспраўным бэкэндам, у той час як астатняя частка прыкладання працягвала нармальна працаваць. Што такое ўзор пераборкі? Тэрмін "узор пераборкі" паходзіць ад караблебудавання і прадугледжвае стварэнне некалькіх ізаляваных адсекаў на караблі. Калі ўцечка адбываецца ў адным адсеку, ён запаўняецца вадой, але іншыя адсекі застаюцца незакранутымі. Гэтая ізаляцыя прадухіляе патапленне ўсяго судна з-за аднаго пралому. Як мы можам выкарыстоўваць шаблон пераборкі, каб выправіць гэтую праблему? Шаблон Bulkhead можна выкарыстоўваць для ізаляцыі розных тыпаў рэсурсаў у дадатку, прадухіляючы збой у адной частцы ад уплыву на ўсю сістэму. Вось як мы можам прымяніць гэта да нашай праблемы: Ізаляваныя пулы злучэнняў Мы можам ствараць асобныя пулы злучэнняў для кожнага бэкэнда (бэкэнд1, бэкэнд2, бэкэнд3). Гэта гарантуе, што калі бэкэнд1 сутыкаецца з вялікім часам водгуку або збоямі, яго пул злучэнняў будзе вычарпаны самастойна, пакідаючы незакранутымі пулы злучэнняў для бэкэнда2 і бэкэнд3. Гэтая ізаляцыя дазваляе спраўным бэкэндам працягваць нармальна апрацоўваць запыты. Абмежаванне рэсурсаў для фонавых дзеянняў Выкарыстоўваючы пераборкі, мы можам вылучыць пэўныя рэсурсы для фонавых дзеянняў, такіх як пакетная апрацоўка або запланаваныя задачы. Гэта прадухіляе гэтыя дзеянні ад спажывання рэсурсаў, неабходных для аперацый у рэальным часе. Напрыклад, мы можам абмежаваць колькасць патокаў або выкарыстанне ЦП, прысвечаных фонавым задачам, гарантуючы, што дастаткова рэсурсаў застаецца даступным для апрацоўкі ўваходных запытаў. Наладжванне абмежаванняў на ўваходныя запыты Пераборкі таксама могуць прымяняцца для абмежавання колькасці ўваходных запытаў у розныя часткі прыкладання. Напрыклад, мы можам усталяваць максімальны ліміт на колькасць запытаў, якія могуць быць апрацаваны адначасова для кожнай вышэйстаячай службы. Гэта прадухіляе перагрузку сістэмы любым асобным бэкэндам і гарантуе, што іншыя бэкэнды могуць працягваць функцыянаваць, нават калі адзін знаходзіцца пад вялікай нагрузкай. Кэш Давайце выкажам здагадку, што нашы серверныя сістэмы маюць нізкую імавернасць асобных памылак. Аднак, калі аперацыя прадугледжвае паралельны запыт усіх гэтых бэкэндаў, кожны можа незалежна вярнуць памылку. Паколькі гэтыя памылкі ўзнікаюць незалежна адзін ад аднаго, агульная верагоднасць памылкі ў нашым дадатку вышэй, чым верагоднасць памылкі любога асобнага бэкэнда. Сукупную імавернасць памылкі можна вылічыць па формуле 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, падтрымліваюць аўтаматычную перазагрузку канфігурацый, што спрашчае гэты працэс. Укараненне перазагружаемых канфігурацый можа змякчыць негатыўны ўплыў доўгага часу запуску прыкладанняў і даць дадатковыя перавагі, такія як садзейнічанне рэалізацыі сцяжкоў функцый. Такі падыход дазваляе нам падтрымліваць надзейнасць і хуткасць рэагавання прыкладанняў пры эфектыўным кіраванні абнаўленнямі канфігурацыі. Запасны варыянт Зараз давайце паглядзім на іншую праблему: у нашай сістэме, калі запыт карыстальніка атрымлівае і апрацоўваецца шляхам адпраўкі запыту ў бэкэнд або базу дадзеных, час ад часу атрымліваецца адказ з памылкай замест чаканых даных. У далейшым наша сістэма адказвае карыстальніку «памылкай». Тым не менш, у многіх выпадках можа быць больш пераважным адлюстроўваць трохі састарэлыя даныя разам з паведамленнем аб затрымцы абнаўлення даных, а не пакідаць карыстальніку вялікае чырвонае паведамленне пра памылку. Каб вырашыць гэтую праблему і палепшыць паводзіны нашай сістэмы, мы можам рэалізаваць шаблон "Запасны варыянт". Канцэпцыя гэтага шаблону прадугледжвае наяўнасць другаснай крыніцы даных, якая можа ўтрымліваць даныя больш нізкай якасці або свежасці ў параўнанні з асноўнай крыніцай. Калі асноўная крыніца даных недаступная або вяртае памылку, сістэма можа вярнуцца да атрымання даных з гэтай другаснай крыніцы, гарантуючы, што некаторая форма інфармацыі будзе прадстаўлена карыстальніку замест адлюстравання паведамлення пра памылку. Паўтарыць Калі вы паглядзіце на малюнак вышэй, вы заўважыце падабенства паміж праблемай, з якой мы зараз сутыкаемся, і той, з якой мы сутыкнуліся ў прыкладзе кэша. Каб вырашыць гэта, мы можам разгледзець магчымасць рэалізацыі шаблону, вядомага як паўторная спроба. Замест таго, каб спадзявацца на кэш, сістэму можна спраектаваць для аўтаматычнай паўторнай адпраўкі запыту ў выпадку памылкі. Гэты шаблон паўтору прапануе больш простую альтэрнатыву і можа эфектыўна паменшыць верагоднасць памылак у нашым дадатку. У адрозненне ад кэшавання, якое часта патрабуе складаных механізмаў анулявання кэша для апрацоўкі змяненняў дадзеных, паўтарыць няўдалыя запыты адносна проста ў рэалізацыі. Паколькі ануляцыя кэша шырока лічыцца адной з самых складаных задач у распрацоўцы праграмнага забеспячэння, прыняцце стратэгіі паўторных спроб можа спрасціць апрацоўку памылак і павысіць устойлівасць сістэмы. Аўтаматычны выключальнік Аднак прыняцце стратэгіі паўтарэння без уліку магчымых наступстваў можа прывесці да далейшых ускладненняў. Давайце ўявім, што адзін з нашых бэкэндаў адчувае збой. У такім сцэнарыі ініцыяванне паўторных спроб да няспраўнага бэкэнда можа прывесці да значнага павелічэння аб'ёму трафіку. Гэты раптоўны ўсплёск трафіку можа перагрузіць бэкэнд, пагоршыўшы збой і патэнцыйна выклікаючы эфект каскаду ў сістэме. Каб справіцца з гэтай праблемай, важна дапоўніць схему паўторных спроб схемай аўтаматычнага выключальніка. Аўтаматычны выключальнік служыць ахоўным механізмам, які кантралюе ўзровень памылак ніжэйстаячых службаў. Калі частата памылак перавышае зададзены парог, аўтаматычны выключальнік перапыняе запыты да пашкоджанай службы на пэўны час. На працягу гэтага перыяду сістэма ўстрымліваецца ад адпраўкі дадатковых запытаў, каб даць магчымасць аднавіцца часу, які не ўдалося абслугоўваць. Пасля вызначанага інтэрвалу аўтаматычны выключальнік асцярожна дазваляе прайсці абмежаваную колькасць запытаў, правяраючы, ці стабілізавалася паслуга. Калі паслуга аднавілася, нармальны трафік паступова аднаўляецца; у адваротным выпадку ланцуг застаецца адкрытым, працягваючы блакаваць запыты, пакуль служба не аднавіць нармальную працу. Дзякуючы інтэграцыі шаблону аўтаматычнага выключальніка разам з логікай паўторных спроб, мы можам эфектыўна кіраваць сітуацыямі з памылкамі і прадухіляць перагрузку сістэмы падчас збояў бэкэнда. Падвядзенне вынікаў У заключэнне, укараняючы гэтыя шаблоны ўстойлівасці, мы можам узмацніць нашы прыкладанні супраць надзвычайных сітуацый, падтрымліваць высокую даступнасць і забяспечваць бесперашкодны вопыт для карыстальнікаў. Акрамя таго, я хацеў бы падкрэсліць, што тэлеметрыя - гэта яшчэ адзін інструмент, які нельга выпускаць з-пад увагі пры забеспячэнні ўстойлівасці праекта. Добрыя журналы і паказчыкі могуць значна павысіць якасць паслуг і даць каштоўную інфармацыю аб іх прадукцыйнасці, дапамагаючы прымаць абгрунтаваныя рашэнні па іх далейшаму паляпшэнню.