Финтекийн төслүүдийн бодит ертөнцөд тэсвэртэй стратеги

Програм хангамжийн уян хатан байдал гэдэг нь гэнэтийн асуудал, бүтэлгүйтлийн үед ч гэсэн програмын хэвийн, найдвартай ажиллагааг үргэлжлүүлэх чадварыг хэлнэ. Финтекийн төслүүдэд уян хатан байдал нь хэд хэдэн шалтгааны улмаас онцгой чухал байдаг. Нэгдүгээрт, компаниуд зохицуулалтын шаардлагыг хангах үүрэгтэй бөгөөд санхүүгийн зохицуулагчид системийн тогтвортой байдлыг хадгалахын тулд үйл ажиллагааны уян хатан байдлыг онцолдог. Түүгээр ч зогсохгүй дижитал хэрэгслүүдийн тархалт, гуравдагч талын үйлчилгээ үзүүлэгчд найдаж байгаа нь Финтекийн бизнесийг аюулгүй байдлын өндөр аюулд хүргэж байна. Мөн уян хатан байдал нь кибер аюул заналхийлэл, тахал өвчин, геополитикийн үйл явдлууд зэрэг янз бүрийн хүчин зүйлээс үүдэлтэй саатлын эрсдлийг бууруулах, бизнесийн үндсэн үйл ажиллагаа, чухал хөрөнгийг хамгаалахад тусалдаг. Тохиромжтой байдлын хэв маягаар бид програм хангамж нь тасалдлыг тэсвэрлэж, үйл ажиллагаагаа хэвийн байлгахад чиглэсэн шилдэг туршлага, стратегийн багцыг ойлгодог. Эдгээр загварууд нь аюулгүйн тор шиг ажилладаг бөгөөд алдааг зохицуулах, ачааллыг зохицуулах, алдаа дутагдлыг арилгах механизмаар хангадаг бөгөөд ингэснээр сөрөг нөхцөлд програмууд найдвартай, найдвартай хэвээр байх болно. Хамгийн түгээмэл уян хатан байдлын стратегиуд нь хаалт, кэш, нөөц, дахин оролдох, таслуур зэрэг орно. Энэ нийтлэлд би тэдгээрийг шийдвэрлэхэд тусалж болох асуудлын жишээн дээр илүү дэлгэрэнгүй авч үзэх болно. Хаалт Дээрх тохиргоог авч үзье. Бидэнд өгөгдөл авах хэд хэдэн арын хэсэгтэй маш энгийн програм байна. Эдгээр арын хэсэгт холбогдсон хэд хэдэн HTTP клиентүүд байдаг. Тэд бүгд ижил холболтын санг хуваалцаж байгаа нь харагдаж байна! Мөн CPU болон RAM гэх мэт бусад нөөцүүд. Хэрэв арын хэсгийн аль нэг нь хүсэлтийн хоцролт өндөртэй холбоотой зарим төрлийн асуудалтай тулгарвал юу болох вэ? Хариу өгөх хугацаа өндөр байгаа тул холболтын сан бүхэлдээ backend1-ээс хариу хүлээж буй хүсэлтээр бүрэн дүүрэн байх болно. Үүний үр дүнд, сан дууссан тул эрүүл backend2 болон backend3-д зориулагдсан хүсэлтийг үргэлжлүүлэх боломжгүй болно. Энэ нь бидний нэг backend-ийн алдаа нь бүх програмыг бүхэлд нь доголдуулж болзошгүй гэсэн үг юм. Бид зөвхөн бүтэлгүйтсэн backend-тэй холбоотой функцийг доройтуулахыг хүсч байгаа бол бусад програм нь хэвийн ажиллаж байгаа. Хамгаалалтын хэв маяг гэж юу вэ? Bulkhead загвар гэдэг нэр томьёо нь хөлөг онгоцны үйлдвэрлэлээс гаралтай бөгөөд хөлөг дотор хэд хэдэн тусгаарлагдсан тасалгаануудыг бий болгодог. Хэрэв нэг тасалгаанд гоожиж байвал усаар дүүрдэг боловч бусад тасалгаанууд нь нөлөөлөлд өртөөгүй хэвээр байна. Энэхүү тусгаарлалт нь нэг удаагийн эвдрэлийн улмаас хөлөг онгоц бүхэлдээ живэхээс сэргийлдэг. Энэ асуудлыг засахын тулд бид хаалтны загварыг хэрхэн ашиглах вэ? Bulkhead загварыг програмын доторх янз бүрийн төрлийн нөөцийг тусгаарлахад ашиглаж болох бөгөөд нэг хэсэг дэх алдаа нь бүхэл системд нөлөөлөхөөс сэргийлнэ. Үүнийг бид өөрсдийн асуудалд хэрхэн ашиглаж болохыг эндээс үзнэ үү. Холболтын сангуудыг тусгаарлах Бид арын хэсэг (backend1, backend2, backend3) тус бүрд тусдаа холболтын сан үүсгэж болно. Энэ нь backend1-д хариу өгөх хугацаа өндөр эсвэл алдаа гарсан тохиолдолд холболтын сан нь бие даан дуусч, backend2 болон backend3-ын холболтын санд нөлөөлөхгүй байхыг баталгаажуулдаг. Энэ тусгаарлалт нь эрүүл арын хэсэгт хүсэлтийг үргэлжлүүлэн боловсруулах боломжийг олгодог. Суурь үйл ажиллагааны нөөцийг хязгаарлах нь Багцуудыг ашигласнаар бид багцын боловсруулалт эсвэл хуваарьт ажил гэх мэт далд үйл ажиллагаанд тусгай нөөцийг хуваарилж чадна. Энэ нь эдгээр үйл ажиллагаа нь бодит цагийн үйл ажиллагаанд шаардлагатай нөөцийг ашиглахаас сэргийлдэг. Жишээлбэл, бид далд даалгаварт зориулагдсан хэлхээний тоо эсвэл CPU-ийн хэрэглээг хязгаарлаж, ирж буй хүсэлтийг шийдвэрлэхэд хангалттай нөөц байгаа эсэхийг баталгаажуулах боломжтой. Ирж буй хүсэлтэд хязгаарлалт тавих нь Аппликешны өөр өөр хэсгүүдэд ирж буй хүсэлтийн тоог хязгаарлахын тулд багцуудыг ашиглаж болно. Жишээлбэл, бид дээд талын үйлчилгээ тус бүрээр зэрэг боловсруулж болох хүсэлтийн дээд хязгаарыг тогтоож болно. Энэ нь системийг хэт ачаалахаас сэргийлж, ачаалал ихтэй байсан ч бусад арын хэсэг нь үргэлжлүүлэн ажиллах боломжийг олгодог. Cache Манай backend системүүд тус тусдаа алдаа гарах магадлал багатай гэж бодъё. Гэсэн хэдий ч, үйл ажиллагаа нь эдгээр бүх backends-ийг зэрэгцүүлэн асуухад тус бүр нь алдаа гаргаж болно. Эдгээр алдаанууд нь бие даасан байдлаар гардаг тул манай програмын алдааны ерөнхий магадлал нь ямар ч арын хэсгийн алдааны магадлалаас өндөр байна. Хуримтлагдсан алдааны магадлалыг P_total=1−(1−p)^n томъёог ашиглан тооцоолж болно, энд n нь арын системийн тоо юм. Жишээлбэл, хэрэв бид 10 арын хэсэгтэй, тус бүр нь p=0.001 алдааны магадлалтай (99.9% SLA-тай тохирч байна) алдааны магадлал дараах байдалтай байна. P_нийт=1−(1−0.001)^10=0.009955 Энэ нь бидний нэгдсэн SLA ойролцоогоор 99% хүртэл буурдаг гэсэн үг бөгөөд энэ нь олон арын хэсэгт зэрэгцэн асуулга хийх үед ерөнхий найдвартай байдал хэрхэн буурч байгааг харуулж байна. Энэ асуудлыг багасгахын тулд бид санах ойн кэшийг хэрэгжүүлж болно. Бид үүнийг санах ойн кэшээр хэрхэн шийдвэрлэх вэ Санах ойн кэш нь өндөр хурдны өгөгдлийн буфер болж, байнга ханддаг өгөгдлийг хадгалж, удаашралтай эх сурвалжаас бүрд нь татаж авах шаардлагагүй болдог. Санах ойд хадгалагдсан кэш нь сүлжээгээр өгөгдөл татахтай харьцуулахад алдаа гарах магадлал 0% байдаг тул бидний хэрэглээний найдвартай байдлыг ихээхэн нэмэгдүүлдэг. Түүнчлэн кэш хийх нь сүлжээний урсгалыг бууруулж, алдаа гарах магадлалыг улам бүр бууруулдаг. Иймээс бид санах ойн кэшийг ашигласнаар арын системтэй харьцуулахад програмынхаа алдааны түвшинг бүр ч бага гаргаж чадна. Нэмж дурдахад санах ойн кэш нь сүлжээнд суурилсан татан авалтаас илүү хурдан өгөгдөл олж авах боломжийг олгодог бөгөөд ингэснээр програмын хоцролтыг бууруулдаг нь мэдэгдэхүйц давуу тал юм. Санах ойн кэш: Хувийн болгосон кэш Хэрэглэгчийн профайл эсвэл зөвлөмж гэх мэт хувийн мэдээллийн хувьд санах ойн кэшийг ашиглах нь өндөр үр дүнтэй байж болно. Гэхдээ бид хэрэглэгчийн бүх хүсэлтийг тэдгээрт зориулж кэшд хадгалсан өгөгдлийг ашиглахын тулд нэг аппликешны инстанц руу байнга очиж байх ёстой бөгөөд энэ нь наалттай сесс шаарддаг. Наалттай сессийг хэрэгжүүлэх нь хэцүү байж болох ч энэ хувилбарын хувьд бидэнд нарийн төвөгтэй механизм хэрэггүй. Бага зэргийн хөдөлгөөний тэнцвэржүүлэлтийг хүлээн зөвшөөрөх боломжтой тул тогтвортой хэш хийх гэх мэт тогтвортой ачааллыг тэнцвэржүүлэх алгоритм хангалттай байх болно. Үүнээс гадна, зангилаа эвдэрсэн тохиолдолд тогтмол хэш хийх нь зөвхөн бүтэлгүйтсэн зангилаатай холбоотой хэрэглэгчид дахин тэнцвэржүүлж, системийн эвдрэлийг багасгадаг. Энэ арга нь хувийн кэшийн удирдлагыг хялбарчилж, манай програмын ерөнхий тогтвортой байдал, гүйцэтгэлийг сайжруулдаг. Санах ойн кэш: дотоод өгөгдлийг хуулбарлах Хэрэв бидний кэш хийхээр төлөвлөж буй өгөгдөл нь чухал ач холбогдолтой бөгөөд манай системд хандах бодлого, захиалгын төлөвлөгөө эсвэл манай домэйн дэх бусад чухал байгууллагууд гэх мэт хүсэлт бүрт ашиглагдаж байвал эдгээр мэдээллийн эх сурвалж нь манай системд томоохон доголдол үүсгэж болзошгүй. Энэ сорилтыг шийдвэрлэхийн тулд нэг арга бол энэ өгөгдлийг манай програмын санах ойд шууд хуулбарлах явдал юм. Энэ тохиолдолд, хэрэв эх сурвалж дахь өгөгдлийн хэмжээг удирдах боломжтой бол бид програмынхаа эхэнд энэ өгөгдлийн агшин зуурын зургийг татаж авах замаар үйл явцыг эхлүүлж болно. Дараа нь бид кэшэд хадгалагдсан өгөгдлийг эх сурвалжтай синхрончлогдсон хэвээр байлгахын тулд шинэчлэлтийн үйл явдлуудыг хүлээн авах боломжтой. Энэ аргыг хэрэглэснээр бид энэ чухал өгөгдөлд хандах найдвартай байдлыг дээшлүүлдэг, учир нь сэргээх бүр нь санах ойноос 0% алдааны магадлалаар шууд явагддаг. Нэмж дурдахад санах ойноос өгөгдлийг сэргээх нь маш хурдан бөгөөд ингэснээр манай програмын гүйцэтгэлийг оновчтой болгодог. Энэхүү стратеги нь гадны мэдээллийн эх сурвалжид найдахтай холбоотой эрсдлийг үр дүнтэй бууруулж, манай програмын үйл ажиллагаанд чухал мэдээлэлд тууштай, найдвартай хандалтыг баталгаажуулдаг. Дахин ачаалах тохиргоо Гэсэн хэдий ч, програмыг эхлүүлэхэд өгөгдлийг татаж авах, улмаар эхлүүлэх процессыг хойшлуулах шаардлага нь програмыг хурдан эхлүүлэхийг дэмжсэн "12 хүчин зүйлийн хэрэглээний" зарчмуудын нэгийг зөрчиж байна. Гэхдээ бид кэш ашиглахын давуу талыг алдахыг хүсэхгүй байна. Энэ бэрхшээлийг арилгахын тулд боломжит шийдлүүдийг судалж үзье. Түргэн эхлүүлэх нь ялангуяа Кубернетес зэрэг платформуудын хувьд маш чухал бөгөөд програмыг өөр өөр физик зангилаа руу хурдан шилжүүлэхэд тулгуурладаг. Аз болоход Кубернетес нь эхлүүлэх датчик гэх мэт функцуудыг ашиглан удаан ажиллаж байгаа програмуудыг удирдах боломжтой. Бидний тулгарч болох өөр нэг бэрхшээл бол програм ажиллаж байх үед тохиргоог шинэчлэх явдал юм. Ихэнхдээ үйлдвэрлэлийн асуудлыг шийдвэрлэхийн тулд кэшийн цагийг тохируулах эсвэл хүсэлт гаргах хугацаа шаардлагатай байдаг. Бид шинэчлэгдсэн тохиргооны файлуудыг програмдаа хурдан байршуулж чадсан ч эдгээр өөрчлөлтийг хэрэгжүүлэхийн тулд ихэвчлэн дахин эхлүүлэх шаардлагатай болдог. Аппликешн бүрийн эхлүүлэх хугацааг уртасгах тусам дахин эхлүүлэх нь манай хэрэглэгчдэд засвар оруулах ажлыг ихээхэн удаашруулж болзошгүй юм. Үүнийг шийдэхийн тулд нэг шийдэл бол тохиргоог зэрэгцээ хувьсагчид хадгалах ба арын хэлхээг үе үе шинэчлэх явдал юм. Гэсэн хэдий ч, HTTP хүсэлтийн завсарлага гэх мэт зарим параметрүүд нь харгалзах тохиргоо өөрчлөгдөх үед HTTP эсвэл өгөгдлийн сангийн клиентүүдийг дахин эхлүүлэхийг шаардаж болзошгүй тул сорилт үүсгэж болзошгүй. Гэсэн хэдий ч Java-д зориулсан Кассандра драйвер гэх мэт зарим үйлчлүүлэгчид тохиргоог автоматаар дахин ачаалахыг дэмжиж, энэ үйл явцыг хялбаршуулдаг. Дахин ачаалах тохиргоог хэрэгжүүлэх нь програмыг эхлүүлэх урт хугацааны сөрөг нөлөөллийг бууруулж, онцлог шинж чанаруудын хэрэгжилтийг хөнгөвчлөх зэрэг нэмэлт ашиг тусыг өгөх болно. Энэ арга нь тохиргооны шинэчлэлтийг үр дүнтэй удирдахын зэрэгцээ програмын найдвартай байдал, хариу үйлдэл үзүүлэх боломжийг бидэнд олгодог. Буцах Одоо өөр нэг асуудлыг харцгаая: манай системд хэрэглэгчийн хүсэлтийг арын хэсэг эсвэл мэдээллийн сан руу асуулга илгээх замаар хүлээн авч боловсруулах үед хүлээгдэж буй өгөгдлийн оронд заримдаа алдааны хариу ирдэг. Үүний дараа манай систем хэрэглэгчдэд 'алдаа' гэсэн хариу өгдөг. Гэсэн хэдий ч олон хувилбарт хэрэглэгчдэд том улаан алдааны мессеж үлдээхийн оронд бага зэрэг хоцрогдсон өгөгдлийг харуулах нь илүү дээр байж болох юм. Энэ асуудлыг шийдэж, системийн үйл ажиллагааг сайжруулахын тулд бид Fallback загварыг хэрэгжүүлж болно. Энэ загварын цаад ойлголт нь үндсэн эх сурвалжтай харьцуулахад чанар муутай эсвэл шинэлэг мэдээлэл агуулсан хоёрдогч мэдээллийн эх сурвалжтай байх явдал юм. Хэрэв үндсэн өгөгдлийн эх үүсвэр байхгүй эсвэл алдаа буцавал систем нь энэ хоёрдогч эх сурвалжаас өгөгдлийг татаж авах горимд шилжиж, алдааны мессежийг харуулахын оронд зарим төрлийн мэдээллийг хэрэглэгчдэд үзүүлэх боломжтой. Дахин оролдоно уу Хэрэв та дээрх зургийг харвал бидний одоо тулгараад байгаа асуудал болон кэшийн жишээн дээр тулгарсан асуудал хоёрын хооронд ижил төстэй байдал ажиглагдах болно. Үүнийг шийдэхийн тулд бид дахин оролдох гэж нэрлэгддэг загварыг хэрэгжүүлэх талаар бодож болно. Кэш дээр найдахын оронд системийг алдаа гарсан тохиолдолд хүсэлтийг автоматаар дахин илгээхээр зохион бүтээж болно. Энэхүү дахин оролдох загвар нь илүү хялбар хувилбарыг санал болгодог бөгөөд манай программ дахь алдаа гарах магадлалыг үр дүнтэй бууруулж чадна. Өгөгдлийн өөрчлөлтийг зохицуулахын тулд кэшийг хүчингүй болгох нарийн төвөгтэй механизм шаарддаг кэшээс ялгаатай нь бүтэлгүйтсэн хүсэлтийг дахин оролдох нь хэрэгжүүлэхэд харьцангуй хялбар байдаг. Кэшийг хүчингүй болгох нь программ хангамжийн инженерчлэлийн хамгийн хэцүү ажлуудын нэг гэж үздэг тул дахин оролдох стратеги баримталснаар алдааны зохицуулалтыг хялбарчилж, системийн уян хатан чанарыг сайжруулж чадна. Хэлхээ таслагч Гэсэн хэдий ч болзошгүй үр дагаврыг тооцолгүйгээр дахин оролдох стратегийг хэрэгжүүлэх нь цаашдын хүндрэлд хүргэж болзошгүй юм. Манай арын хэсгийн аль нэг нь бүтэлгүйтсэн гэж төсөөлөөд үз дээ. Ийм тохиолдолд бүтэлгүйтсэн арын хэсэг рүү дахин оролдох нь хөдөлгөөний хэмжээг мэдэгдэхүйц нэмэгдүүлэхэд хүргэж болзошгүй юм. Замын хөдөлгөөний гэнэтийн өсөлт нь арын хэсгийг дарж, бүтэлгүйтлийг улам даамжруулж, систем даяар каскадын нөлөөг үүсгэж болзошгүй. Энэ сорилтыг даван туулахын тулд дахин оролдох загварыг таслагчийн загвараар нөхөх нь чухал юм. Хэлхээ таслагч нь доод урсгалын үйлчилгээний алдааны түвшинг хянадаг хамгаалалтын механизм болдог. Алдааны түвшин урьдчилан тодорхойлсон босго хэмжээнээс давсан тохиолдолд таслуур нөлөөлөлд өртсөн үйлчилгээний хүсэлтийг тодорхой хугацаанд тасалдаг. Энэ хугацаанд систем амжилтгүй болсон үйлчилгээний хугацааг сэргээхийн тулд нэмэлт хүсэлт илгээхээс татгалздаг. Тодорхой хугацааны дараа таслуур нь хязгаарлагдмал тооны хүсэлтийг дамжуулж, үйлчилгээ тогтворжсон эсэхийг шалгана. Хэрэв үйлчилгээ сэргэсэн бол хэвийн хөдөлгөөн аажмаар сэргээгддэг; Үгүй бол хэлхээ нь нээлттэй хэвээр байх бөгөөд үйлчилгээг хэвийн ажиллагааг үргэлжлүүлэх хүртэл хүсэлтийг блоклодог. Хэлхээ таслагчийн хэв маягийг дахин оролдох логиктой хамт нэгтгэснээр бид алдааны нөхцөл байдлыг үр дүнтэй удирдаж, арын хэсгийн эвдрэлийн үед системийн хэт ачааллаас сэргийлж чадна. Боож байна Эцэст нь хэлэхэд, эдгээр уян хатан байдлын хэв маягийг хэрэгжүүлснээр бид яаралтай тусламжийн эсрэг програмуудаа бэхжүүлж, өндөр хүртээмжтэй байлгаж, хэрэглэгчдэд саадгүй туршлагыг хүргэж чадна. Нэмж дурдахад телеметр бол төслийн тогтвортой байдлыг хангахад үл тоомсорлож болохгүй өөр нэг хэрэгсэл гэдгийг онцлон тэмдэглэхийг хүсч байна. Сайн бүртгэлүүд болон хэмжүүрүүд нь үйлчилгээний чанарыг мэдэгдэхүйц сайжруулж, гүйцэтгэлийн талаарх үнэ цэнэтэй ойлголтыг өгч, цаашид сайжруулахын тулд үндэслэлтэй шийдвэр гаргахад тусалдаг.