හෙලෝ, හබ්ර්!

කොරෝනා වයිරසය හේතුවෙන් වර්තමාන සිදුවීම් ආලෝකය තුළ, අන්තර්ජාල සේවා ගණනාවකට වැඩි බරක් ලැබීමට පටන් ගෙන තිබේ. උදාහරණ වශයෙන්, එක්සත් රාජධානියේ සිල්ලර වෙළඳ ජාලයකින් එකක් එහි මාර්ගගත ඇණවුම් කිරීමේ වෙබ් අඩවිය නතර කළේය., ප්රමාණවත් ධාරිතාවක් නොතිබූ නිසාය. වඩා බලවත් උපකරණ එකතු කිරීමෙන් සේවාදායකයක් වේගවත් කිරීම සැමවිටම කළ නොහැක, නමුත් සේවාදායක ඉල්ලීම් ක්‍රියා කළ යුතුය (නැතහොත් ඒවා තරඟකරුවන් වෙත යයි).

මෙම ලිපියෙන් මම ඔබට වේගවත් සහ වැරදි ඉවසීමේ සේවාවක් නිර්මාණය කිරීමට ඉඩ සලසන ජනප්‍රිය භාවිතයන් ගැන කෙටියෙන් කතා කරමි. නමුත් කළ හැකි සංවර්ධන යෝජනා ක්‍රමවලින් මම තෝරා ගත්තේ දැනට තිබෙන ඒවා පමණයි භාවිතා කිරීමට පහසු. සෑම අයිතමයක් සඳහාම, ඔබට සූදානම් කළ පුස්තකාල තිබේ, නැතහොත් ඔබට වලාකුළු වේදිකාවක් භාවිතයෙන් ගැටළුව විසඳීමට අවස්ථාව තිබේ.

තිරස් පරිමාණය

සරලම හා වඩාත්ම දන්නා කරුණ. සාම්ප්‍රදායිකව, වඩාත් පොදු බර බෙදා හැරීමේ යෝජනා ක්‍රම දෙක වන්නේ තිරස් සහ සිරස් පරිමාණය. පළමු නඩුවේ ඔබ සේවාවන්ට සමාන්තරව ක්‍රියාත්මක වීමට ඉඩ සලසයි, එමඟින් ඒවා අතර බර බෙදා හරිනු ලැබේ. දෙවනුව ඔබ වඩාත් බලවත් සේවාදායකයන් ඇණවුම් කරන්න හෝ කේතය ප්‍රශස්ත කරන්න.

උදාහරණයක් ලෙස, මම වියුක්ත වලාකුළු ගොනු ගබඩාව ගන්නෙමි, එනම් OwnCloud, OneDrive සහ යනාදී සමහර ප්‍රතිසමයක්.

එවැනි පරිපථයක සම්මත පින්තූරයක් පහත දැක්වේ, නමුත් එය පද්ධතියේ සංකීර්ණත්වය පමණක් පෙන්නුම් කරයි. සියල්ලට පසු, අපි කෙසේ හෝ සේවාවන් සමමුහුර්ත කළ යුතුය. පරිශීලකයා ටැබ්ලටයෙන් ගොනුවක් සුරකින අතර පසුව එය දුරකථනයෙන් බැලීමට අවශ්ය නම් කුමක් සිදුවේද?

ප්රවේශයන් අතර වෙනස: සිරස් පරිමාණයේ දී, අපි නෝඩ් වල බලය වැඩි කිරීමට සූදානම් වන අතර, තිරස් පරිමාණය තුළ, බර බෙදා හැරීම සඳහා නව නෝඩ් එකතු කිරීමට අපි සූදානම්.

CQRS

විධාන විමසුම් වගකීම් වෙන් කිරීම තරමක් වැදගත් රටාවක්, එය විවිධ සේවාලාභීන්ට විවිධ සේවාවන් වෙත සම්බන්ධ වීමට පමණක් නොව, එකම සිදුවීම් ප්‍රවාහයන් ලබා ගැනීමට ඉඩ සලසයි. සරල යෙදුමක් සඳහා එහි ප්‍රතිලාභ එතරම් පැහැදිලි නැත, නමුත් කාර්යබහුල සේවාවක් සඳහා එය අතිශයින් වැදගත් (සහ සරල) වේ. එහි සාරය: පැමිණෙන සහ පිටතට යන දත්ත ප්රවාහයන් ඡේදනය නොවිය යුතුය. එනම්, ඔබට ඉල්ලීමක් යවා ප්‍රතිචාරයක් බලාපොරොත්තු විය නොහැක; ඒ වෙනුවට, ඔබ A සේවාව වෙත ඉල්ලීමක් යවන නමුත්, B සේවාවෙන් ප්‍රතිචාරයක් ලැබේ.

මෙම ප්‍රවේශයේ පළමු ප්‍රසාද දීමනාව වන්නේ දිගු ඉල්ලීමක් ක්‍රියාත්මක කිරීමේදී සම්බන්ධතාවය (වචනයේ පුළුල් අර්ථයෙන්) බිඳ දැමීමේ හැකියාවයි. උදාහරණයක් ලෙස, අපි වැඩි හෝ අඩු සම්මත අනුපිළිවෙලක් ගනිමු:

1. සේවාදායකයා සේවාදායකයට ඉල්ලීමක් යවා ඇත.
2. සේවාදායකය දිගු සැකසුම් කාලයක් ආරම්භ කර ඇත.
3. සේවාදායකය සේවාදායකයාට ප්‍රතිඵලය සමඟ ප්‍රතිචාර දැක්වීය.

2 වන ස්ථානයේ සම්බන්ධතාවය කැඩී ඇති බව සිතමු (නැතහොත් ජාලය නැවත සම්බන්ධ විය, නැතහොත් පරිශීලකයා වෙනත් පිටුවකට ගොස් සම්බන්ධතාවය බිඳ දැමීය). මෙම අවස්ථාවේදී, සේවාදායකයාට හරියටම සැකසූ දේ පිළිබඳ තොරතුරු සමඟ පරිශීලකයාට ප්රතිචාරයක් යැවීමට අපහසු වනු ඇත. CQRS භාවිතා කරමින්, අනුපිළිවෙල තරමක් වෙනස් වනු ඇත:

1. සේවාදායකයා යාවත්කාලීන සඳහා දායක වී ඇත.
2. සේවාදායකයා සේවාදායකයට ඉල්ලීමක් යවා ඇත.
3. සේවාදායකය "ඉල්ලීම පිළිගෙන ඇත" යනුවෙන් ප්‍රතිචාර දැක්වීය.
4. සේවාදායකය "1" ලක්ෂ්‍යයෙන් නාලිකාව හරහා ප්‍රතිඵලය සමඟ ප්‍රතිචාර දැක්වීය.

ඔබට පෙනෙන පරිදි, යෝජනා ක්රමය ටිකක් සංකීර්ණයි. එපමනක් නොව, අවබෝධාත්මක ඉල්ලීම්-ප්‍රතිචාර ප්‍රවේශය මෙහි නොමැත. කෙසේ වෙතත්, ඔබට පෙනෙන පරිදි, ඉල්ලීමක් සැකසීමේදී සම්බන්ධතා බිඳීමක් දෝෂයකට තුඩු නොදෙනු ඇත. එපමණක් නොව, ඇත්ත වශයෙන්ම පරිශීලකයා උපාංග කිහිපයකින් සේවාවට සම්බන්ධ වී ඇත්නම් (උදාහරණයක් ලෙස, ජංගම දුරකථනයකින් සහ ටැබ්ලටයකින්), ප්රතිචාරය උපාංග දෙකටම පැමිණෙන බවට ඔබට සහතික විය හැකිය.

සිත්ගන්නා කරුණ නම්, පැමිණෙන පණිවිඩ සැකසීමේ කේතය සේවාදායකයා විසින්ම බලපෑමට ලක් වූ සිදුවීම් සඳහා සහ අනෙකුත් සේවාදායකයින් ඇතුළු අනෙකුත් සිදුවීම් සඳහා (100% නොවේ) සමාන වේ.

කෙසේ වෙතත්, යථාර්ථයේ දී අපි ඒකපාර්ශ්වික ප්රවාහය ක්රියාකාරී ශෛලියකින් (RX සහ සමාන භාවිතා කිරීම) හැසිරවිය හැකි නිසා අමතර ප්රසාද දීමනාවක් ලබා ගනිමු. මෙය දැනටමත් බරපතල ප්ලස් එකක් වන අතර, සාරාංශයක් ලෙස යෙදුම සම්පූර්ණයෙන්ම ප්‍රතික්‍රියාශීලී කළ හැකි අතර ක්‍රියාකාරී ප්‍රවේශයක් භාවිතා කළ හැකිය. මේද වැඩසටහන් සඳහා, මෙය සැලකිය යුතු ලෙස සංවර්ධනය සහ ආධාරක සම්පත් ඉතිරි කර ගත හැකිය.

අපි මෙම ප්‍රවේශය තිරස් පරිමාණය සමඟ ඒකාබද්ධ කළහොත්, ප්‍රසාද දීමනාවක් ලෙස අපට එක් සේවාදායකයකට ඉල්ලීම් යැවීමට සහ තවත් සේවාදායකයකින් ප්‍රතිචාර ලබා ගැනීමේ හැකියාව ලැබේ. මේ අනුව, සේවාදායකයාට ඔහුට පහසු සේවාවක් තෝරා ගත හැකි අතර, ඇතුළත පද්ධතිය තවමත් සිදුවීම් නිවැරදිව සැකසීමට හැකි වනු ඇත.

සිදුවීම් මූලාශ්ර

ඔබ දන්නා පරිදි, බෙදා හරින ලද පද්ධතියක ප්රධාන ලක්ෂණයක් වන්නේ පොදු කාලය, පොදු විවේචනාත්මක අංශයක් නොමැති වීමයි. එක් ක්‍රියාවලියක් සඳහා, ඔබට සමමුහුර්ත කිරීමක් සිදු කළ හැකිය (එකම mutexes මත), එය තුළ වෙනත් කිසිවෙකු මෙම කේතය ක්‍රියාත්මක නොකරන බව ඔබට විශ්වාසයි. කෙසේ වෙතත්, බෙදා හරින ලද පද්ධතියකට මෙය භයානක ය, මන්ද එයට උඩිස් වැඩ අවශ්‍ය වන අතර පරිමාණයේ සියලු අලංකාරය ද විනාශ කරනු ඇත - සියලුම සංරචක තවමත් එකක් බලා සිටිනු ඇත.

මෙතැන් සිට අපට වැදගත් කරුණක් ලැබේ - වේගයෙන් බෙදා හරින ලද පද්ධතියක් සමමුහුර්ත කළ නොහැක, මන්ද එවිට අපි කාර්ය සාධනය අඩු කරනු ඇත. අනෙක් අතට, අපට බොහෝ විට සංරචක අතර යම් අනුකූලතාවයක් අවශ්ය වේ. මේ සඳහා ඔබට ප්රවේශය භාවිතා කළ හැකිය අවසාන අනුකූලතාව, අවසාන යාවත්කාලීන කිරීමෙන් පසු යම් කාල පරිච්ඡේදයක් සඳහා දත්ත වෙනස්කම් නොමැති නම් ("අවසානයේ"), සියලු විමසුම් අවසන් යාවත්කාලීන කළ අගය ලබා දෙන බවට සහතික වේ.

සම්භාව්‍ය දත්ත සමුදායන් සඳහා එය බොහෝ විට භාවිතා වන බව තේරුම් ගැනීම වැදගත්ය ශක්තිමත් අනුකූලතාව, සෑම නෝඩයකටම එකම තොරතුරු ඇත (මෙය බොහෝ විට සාක්ෂාත් කරගනු ලබන්නේ ගනුදෙනුව ස්ථාපිත යැයි සැලකෙන්නේ දෙවන සේවාදායකය ප්‍රතිචාර දැක්වීමෙන් පසුව පමණි). හුදකලා මට්ටම් නිසා මෙහි යම් ලිහිල් කිරීම් තිබේ, නමුත් සාමාන්‍ය අදහස එලෙසම පවතී - ඔබට සම්පූර්ණයෙන්ම එකඟ වූ ලෝකයක ජීවත් විය හැකිය.

කෙසේ වෙතත්, අපි මුල් කාර්යය වෙත ආපසු යමු. පද්ධතියේ කොටසක් සමඟ ගොඩනගා ගත හැකි නම් අවසාන අනුකූලතාව, එවිට අපට පහත රූප සටහන සෑදිය හැක.

මෙම ප්රවේශයේ වැදගත් ලක්ෂණ:

• එන සෑම ඉල්ලීමක්ම එක් පෝලිමක තබා ඇත.
• ඉල්ලීමක් ක්‍රියාවට නංවන අතරතුර, සේවාව වෙනත් පෝලිම්වල කාර්යයන් ද තැබිය හැකිය.
• එන සෑම සිදුවීමකටම හඳුනාගැනීමක් ඇත (එය අඩු කිරීම සඳහා අවශ්‍ය වේ).
• පෝලිම මතවාදීව "ඇමිණීම පමණක්" යෝජනා ක්රමයට අනුව ක්රියා කරයි. ඔබට එයින් මූලද්‍රව්‍ය ඉවත් කිරීමට හෝ ඒවා නැවත සකස් කිරීමට නොහැක.
• පෝලිම FIFO යෝජනා ක්රමයට අනුව ක්රියා කරයි (tautology සඳහා සමාවෙන්න). ඔබට සමාන්තරව ක්‍රියාත්මක කිරීමට අවශ්‍ය නම්, එක් අදියරකදී ඔබ වස්තූන් විවිධ පෝලිම් වෙත ගෙන යා යුතුය.

අපි සබැඳි ගොනු ගබඩා කිරීමේ නඩුව සලකා බලන බව මම ඔබට මතක් කරමි. මෙම අවස්ථාවේදී, පද්ධතිය මේ වගේ දෙයක් පෙනෙනු ඇත:

රූප සටහනේ ඇති සේවාවන් අනිවාර්යයෙන්ම වෙනම සේවාදායකයක් අදහස් නොකිරීම වැදගත්ය. ක්රියාවලිය පවා සමාන විය හැකිය. තවත් දෙයක් වැදගත් ය: දෘෂ්ටිමය වශයෙන්, මෙම දේවල් තිරස් පරිමාණය පහසුවෙන් යෙදිය හැකි ආකාරයෙන් වෙන් කරනු ලැබේ.

පරිශීලකයින් දෙදෙනෙකු සඳහා රූප සටහන මේ ආකාරයෙන් පෙනෙනු ඇත (විවිධ පරිශීලකයින් සඳහා අදහස් කරන සේවාවන් විවිධ වර්ණවලින් දැක්වේ):

එවැනි සංයෝජනයකින් බෝනස්:

• තොරතුරු සැකසුම් සේවා වෙන් කර ඇත. පෝලිම් ද වෙන් කර ඇත. අපට පද්ධති ප්‍රතිදානය වැඩි කිරීමට අවශ්‍ය නම්, අපට අවශ්‍ය වන්නේ තවත් සේවාදායක මත තවත් සේවාවන් දියත් කිරීමයි.
• පරිශීලකයෙකුගෙන් අපට තොරතුරු ලැබුණු විට, දත්ත සම්පූර්ණයෙන්ම සුරැකෙන තෙක් බලා සිටීමට සිදු නොවේ. ඊට පටහැනිව, අපි "හරි" පිළිතුරු දිය යුතු අතර පසුව ක්රමයෙන් වැඩ ආරම්භ කරන්න. ඒ අතරම, නව වස්තුවක් එකතු කිරීම ඉක්මනින් සිදු වන බැවින්, පෝලිම උපරිම මට්ටම් සුමට කරයි, සහ පරිශීලකයාට සම්පූර්ණ චක්‍රය හරහා සම්පූර්ණ ගමන් කිරීමක් බලා සිටීමට සිදු නොවේ.
• උදාහරණයක් ලෙස, මම සමාන ගොනු ඒකාබද්ධ කිරීමට උත්සාහ කරන අඩුකිරීමේ සේවාවක් එක් කළෙමි. එය 1% අවස්ථා වලදී දිගු කාලයක් ක්‍රියා කරන්නේ නම්, සේවාදායකයා එය කිසිසේත්ම නොදකිනු ඇත (ඉහත බලන්න), එය විශාල ප්ලස් එකක් වන අතර, අපට තවදුරටත් XNUMX% වේගය සහ විශ්වාසදායක වීමට අවශ්‍ය නොවේ.

කෙසේ වෙතත්, අවාසි වහාම දැකිය හැකිය:

• අපගේ පද්ධතිය එහි දැඩි අනුකූලතාව නැති වී ඇත. මෙයින් අදහස් කරන්නේ, උදාහරණයක් ලෙස, ඔබ විවිධ සේවාවන් සඳහා දායක වන්නේ නම්, න්‍යායාත්මකව ඔබට වෙනත් තත්වයක් ලබා ගත හැකිය (එක් සේවාවකට අභ්‍යන්තර පෝලිමෙන් දැනුම්දීමක් ලැබීමට කාලය නොමැති බැවින්). තවත් ප්රතිවිපාකයක් ලෙස, පද්ධතියට දැන් පොදු කාලයක් නොමැත. එනම්, සේවාදායකයන් අතර ඔරලෝසු සමමුහුර්ත නොවිය හැකි බැවින්, උදාහරණයක් ලෙස, සියලුම සිදුවීම් සරලව පැමිණීමේ වේලාව අනුව වර්ග කිරීම කළ නොහැක (එපමනක් නොව, සේවාදායකයන් දෙකක එකම වේලාව යුතෝපියාවකි).
• කිසිදු සිදුවීමක් දැන් සරලව ආපසු හැරවිය නොහැක (දත්ත සමුදායක් සමඟ කළ හැකි පරිදි). ඒ වෙනුවට, ඔබට නව සිදුවීමක් එක් කිරීමට අවශ්‍යයි - වන්දි සිදුවීම, අවසාන තත්වය අවශ්‍ය තත්වයට වෙනස් කරයි. සමාන ප්‍රදේශයකින් උදාහරණයක් ලෙස: ඉතිහාසය නැවත ලිවීමකින් තොරව (සමහර අවස්ථාවල එය නරකයි), ඔබට git හි කැපවීමක් ආපසු හැරවිය නොහැක, නමුත් ඔබට විශේෂ දෙයක් කළ හැකිය ආපසු හැරීමේ කැපවීම, එය අත්‍යවශ්‍යයෙන්ම පැරණි තත්වය නැවත ලබා දෙයි. කෙසේ වෙතත්, වැරදි කැපවීම සහ ආපසු හැරීම යන දෙකම ඉතිහාසයේ පවතිනු ඇත.
• දත්ත ක්‍රමය නිකුතුවෙන් මුදා හැරීමට වෙනස් විය හැක, නමුත් පැරණි සිදුවීම් තවදුරටත් නව ප්‍රමිතියට යාවත්කාලීන කිරීමට නොහැකි වනු ඇත (සිදුවීම් ප්‍රතිපත්තිමය වශයෙන් වෙනස් කළ නොහැකි බැවින්).

ඔබට පෙනෙන පරිදි, Event Sourcing CQRS සමඟ හොඳින් ක්‍රියා කරයි. එපමණක් නොව, කාර්යක්ෂම හා පහසු පෝලිම් සහිත පද්ධතියක් ක්‍රියාත්මක කිරීම, නමුත් දත්ත ප්‍රවාහයන් වෙන් නොකර, දැනටමත් දුෂ්කර ය, මන්ද ඔබට පෝලිම්වල සමස්ත ධනාත්මක බලපෑම උදාසීන කරන සමමුහුර්තකරණ ලකුණු එකතු කිරීමට සිදුවනු ඇත. ප්රවේශයන් දෙකම එකවර යෙදීම, වැඩසටහන් කේතය තරමක් සකස් කිරීම අවශ්ය වේ. අපගේ නඩුවේදී, සේවාදායකයට ගොනුවක් යැවීමේදී, ප්‍රතිචාරය පැමිණෙන්නේ “ok” පමණි, එයින් අදහස් කරන්නේ “ගොනුව එකතු කිරීමේ ක්‍රියාකාරිත්වය සුරකින ලද” බවයි. විධිමත් ලෙස, වෙනත් උපාංගවල දත්ත දැනටමත් පවතින බව මින් අදහස් නොවේ (උදාහරණයක් ලෙස, අඩුකිරීමේ සේවාවට දර්ශකය නැවත ගොඩනැංවිය හැක). කෙසේ වෙතත්, ටික වේලාවකට පසු, සේවාදායකයාට "ගොනුව X සුරකින ලදි" යන විලාසයෙන් දැනුම්දීමක් ලැබෙනු ඇත.

ප්රතිඵලයක් වශයෙන්:

• ගොනු යැවීමේ තත්ව ගණන වැඩි වෙමින් පවතී: සම්භාව්‍ය “යවන ලද ගොනුව” වෙනුවට අපට දෙකක් ලැබේ: “ගොනුව සේවාදායකයේ පෝලිමට එක් කර ඇත” සහ “ගොනුව ගබඩාවේ සුරකින ලදි.” දෙවැන්නෙන් අදහස් කරන්නේ වෙනත් උපාංග දැනටමත් ගොනුව ලැබීම ආරම්භ කළ හැකි බවයි (පෝලිම් විවිධ වේගයකින් ක්‍රියාත්මක වන බව සඳහා සකස් කර ඇත).
• ඉදිරිපත් කිරීමේ තොරතුරු දැන් විවිධ නාලිකා හරහා ලැබෙන නිසා, ගොනුවේ සැකසුම් තත්ත්වය ලබා ගැනීම සඳහා අපි විසඳුම් ඉදිරිපත් කළ යුතුය. මෙහි ප්‍රතිඵලයක් ලෙස: සම්භාව්‍ය ඉල්ලීම්-ප්‍රතිචාරය මෙන් නොව, ගොනුව සකසන අතරතුර සේවාලාභියා නැවත ආරම්භ කළ හැක, නමුත් මෙම සැකසීමේ තත්ත්වයම නිවැරදි වනු ඇත. එපමණක් නොව, මෙම අයිතමය සාරභූතව, කොටුවෙන් පිටත ක්රියා කරයි. ප්රතිවිපාකයක් ලෙස: අපි දැන් අසාර්ථකත්වයන් වඩාත් ඉවසා සිටිමු.

තියුණු කිරීම

ඉහත විස්තර කර ඇති පරිදි, සිද්ධි මූලාශ්‍ර පද්ධති දැඩි අනුකූලතාවයක් නොමැත. මෙයින් අදහස් කරන්නේ අපට ඒවා අතර සමමුහුර්තකරණයකින් තොරව ගබඩා කිහිපයක් භාවිතා කළ හැකි බවයි. අපගේ ගැටලුව වෙත ළඟා වන විට, අපට:

• වර්ගය අනුව ගොනු වෙන් කරන්න. උදාහරණයක් ලෙස, පින්තූර/වීඩියෝ විකේතනය කර වඩාත් කාර්යක්ෂම ආකෘතියක් තෝරාගත හැක.
• රට අනුව ගිණුම් වෙන් කරන්න. බොහෝ නීති නිසා, මෙය අවශ්ය විය හැකිය, නමුත් මෙම ගෘහ නිර්මාණ යෝජනා ක්රමය ස්වයංක්රීයව එවැනි අවස්ථාවක් ලබා දෙයි

ඔබට එක් ගබඩාවක සිට තවත් ගබඩාවකට දත්ත මාරු කිරීමට අවශ්‍ය නම්, සම්මත මාධ්‍යයන් තවදුරටත් ප්‍රමාණවත් නොවේ. අවාසනාවකට මෙන්, මෙම අවස්ථාවේදී, ඔබ පෝලිම නැවැත්විය යුතුය, සංක්රමණය කරන්න, ඉන්පසු එය ආරම්භ කරන්න. සාමාන්‍ය අවස්ථාවෙහිදී, “පියාසරයේදී” දත්ත මාරු කළ නොහැක, කෙසේ වෙතත්, සිදුවීම් පෝලිම සම්පූර්ණයෙන්ම ගබඩා කර ඇත්නම් සහ ඔබට පෙර ගබඩා තත්ත්වයන් පිළිබඳ ඡායාරූප තිබේ නම්, අපට සිදුවීම් පහත පරිදි නැවත ධාවනය කළ හැකිය:

• සිදුවීම් මූලාශ්‍රය තුළ, සෑම සිදුවීමකටම තමන්ගේම හඳුනාගැනීමක් ඇත (ඉතා මැනවින්, අඩු නොවන). මෙයින් අදහස් කරන්නේ අපට ගබඩාවට ක්ෂේත්‍රයක් එක් කළ හැකි බවයි - අවසන් වරට සැකසූ මූලද්‍රව්‍යයේ id.
• සියලුම සිදුවීම් ස්වාධීන ගබඩා කිහිපයක් සඳහා සැකසිය හැකි වන පරිදි අපි පෝලිම අනුපිටපත් කරන්නෙමු (පළමු එක දත්ත දැනටමත් ගබඩා කර ඇති අතර, දෙවැන්න නව, නමුත් තවමත් හිස්). දෙවන පෝලිම, ඇත්ත වශයෙන්ම, තවමත් සකස් කර නැත.
• අපි දෙවන පෝලිම දියත් කරමු (එනම්, අපි සිදුවීම් නැවත ධාවනය කිරීමට පටන් ගනිමු).
• නව පෝලිම සාපේක්ෂ වශයෙන් හිස් වූ විට (එනම්, මූලද්‍රව්‍යයක් එකතු කිරීම සහ එය ලබා ගැනීම අතර සාමාන්‍ය කාල වෙනස පිළිගත හැකි ය), ඔබට නව ගබඩාව වෙත පාඨකයන් මාරු කිරීම ආරම්භ කළ හැක.

ඔබට පෙනෙන පරිදි, අපගේ පද්ධතියේ දැඩි අනුකූලතාවයක් අපට නොතිබුණි, සහ තවමත් නොමැත. එහි ඇත්තේ අවසාන ස්ථාවරත්වය පමණි, එනම් සිදුවීම් එකම අනුපිළිවෙලකට (නමුත් විවිධ ප්‍රමාදයන් සමඟ) සැකසෙන බවට සහතිකයක් ඇත. තවද, මෙය භාවිතා කිරීමෙන්, පද්ධතිය නැවැත්වීමකින් තොරව අපට සාපේක්ෂව පහසුවෙන් දත්ත මාරු කළ හැකිය ලෝකයේ අනෙක් පැත්තට.

මේ අනුව, ගොනු සඳහා සබැඳි ගබඩා කිරීම පිළිබඳ අපගේ උදාහරණය දිගටම කරගෙන යාම, එවැනි ගෘහ නිර්මාණ ශිල්පයක් දැනටමත් අපට බෝනස් ගණනාවක් ලබා දෙයි:

• අපට වස්තු ගතික ආකාරයෙන් පරිශීලකයින්ට සමීප කළ හැකිය. මේ ආකාරයෙන් ඔබට සේවාවේ ගුණාත්මකභාවය වැඩි දියුණු කළ හැකිය.
• අපි සමාගම් තුළ සමහර දත්ත ගබඩා කළ හැක. උදාහරණයක් ලෙස, ව්‍යවසාය භාවිතා කරන්නන් බොහෝ විට තම දත්ත පාලිත දත්ත මධ්‍යස්ථානවල ගබඩා කිරීම අවශ්‍ය වේ (දත්ත කාන්දු වීම වැළැක්වීම සඳහා). sharding හරහා අපිට මේකට පහසුවෙන් සහය වෙන්න පුළුවන්. පාරිභෝගිකයාට ගැළපෙන වලාකුළක් තිබේ නම් කාර්යය වඩාත් පහසු වේ (උදාහරණයක් ලෙස, Azure self hosted).
• ඒ වගේම වැදගත්ම දේ තමයි අපි මේක කරන්න ඕන නැහැ. සියල්ලට පසු, ආරම්භ කිරීමට, අපි සියලු ගිණුම් සඳහා එක් ගබඩාවක් සමඟ ඉතා සතුටු වනු ඇත (ඉක්මනින් වැඩ ආරම්භ කිරීමට). තවද මෙම පද්ධතියේ ප්රධාන ලක්ෂණය වන්නේ එය පුළුල් කළ හැකි වුවද, ආරම්භක අදියරේදී එය තරමක් සරල ය. වෙනම ස්වාධීන පෝලිම් මිලියනයක් සමඟ ක්‍රියා කරන කේතයක් ඔබට වහාම ලිවීමට අවශ්‍ය නැත. අවශ්ය නම්, මෙය අනාගතයේදී සිදු කළ හැකිය.

ස්ථිතික අන්තර්ගත සත්කාරකත්වය

මෙම කරුණ තරමක් පැහැදිලිව පෙනෙන්නට ඇත, නමුත් එය තවමත් වැඩි හෝ අඩු සම්මත පැටවූ යෙදුමක් සඳහා අවශ්ය වේ. එහි සාරය සරලයි: සියලුම ස්ථිතික අන්තර්ගතයන් බෙදා හරිනු ලබන්නේ යෙදුම පිහිටා ඇති එකම සේවාදායකයෙන් නොව, මෙම කාර්යය සඳහා විශේෂයෙන් කැප වූ විශේෂ අයගෙන් ය. එහි ප්‍රතිඵලයක් වශයෙන්, මෙම මෙහෙයුම් වේගයෙන් සිදු වේ (කොන්දේසි සහිත nginx ජාවා සේවාදායකයකට වඩා ඉක්මනින් හා අඩු වියදමකින් ලිපිගොනු සේවය කරයි). ප්ලස් CDN ගෘහ නිර්මාණ ශිල්පය (අන්තර්ගත බෙදා හැරීමේ ජාලය) අපගේ ලිපිගොනු අවසාන පරිශීලකයින්ට සමීපව ස්ථානගත කිරීමට අපට ඉඩ සලසයි, එය සේවාව සමඟ වැඩ කිරීමේ පහසුව කෙරෙහි ධනාත්මක බලපෑමක් ඇති කරයි.

ස්ථිතික අන්තර්ගතයේ සරලම සහ වඩාත්ම සම්මත උදාහරණය වන්නේ වෙබ් අඩවියක් සඳහා ස්ක්‍රිප්ට් සහ රූප සමූහයකි. ඔවුන් සමඟ සෑම දෙයක්ම සරලයි - ඒවා කල්තියා දන්නා අතර, පසුව ලේඛනාගාරය CDN සේවාදායකයන් වෙත උඩුගත කරනු ලැබේ, ඒවා අවසන් පරිශීලකයින් වෙත බෙදා හරිනු ලැබේ.

කෙසේ වෙතත්, යථාර්ථයේ දී, ස්ථිතික අන්තර්ගතය සඳහා, ඔබට lambda ගෘහ නිර්මාණ ශිල්පයට තරමක් සමාන ප්රවේශයක් භාවිතා කළ හැකිය. අපි පරිශීලකයින්ට ගොනු බෙදා හැරීමට අවශ්‍ය වන අපගේ කාර්යයට (මාර්ගගත ගොනු ගබඩාව) ආපසු යමු. සරලම විසඳුම නම්, එක් එක් පරිශීලක ඉල්ලීම සඳහා, අවශ්‍ය සියලුම චෙක්පත් (අවසර ලබා දීම, ආදිය) සිදු කරන සේවාවක් නිර්මාණය කිරීම සහ පසුව අපගේ ගබඩාවෙන් ගොනුව කෙලින්ම බාගත කිරීමයි. මෙම ප්‍රවේශයේ ප්‍රධාන අවාසිය නම් ස්ථිතික අන්තර්ගතය (සහ යම් සංශෝධනයක් සහිත ගොනුවක් ඇත්ත වශයෙන්ම ස්ථිතික අන්තර්ගතයකි) ව්‍යාපාර තර්කනය අඩංගු එකම සේවාදායකය විසින් බෙදා හැරීමයි. ඒ වෙනුවට, ඔබට පහත රූප සටහන සෑදිය හැකිය:

• සේවාදායකය බාගත කිරීමේ URL එකක් සපයයි. එය file_id + යතුර පෝරමය විය හැක, යතුර යනු ඉදිරි පැය 24 සඳහා සම්පත් වෙත ප්‍රවේශ වීමට අයිතිය ලබා දෙන කුඩා ඩිජිටල් අත්සනකි.
• ගොනුව පහත විකල්ප සමඟ සරල nginx මගින් බෙදා හරිනු ලැබේ:
  • අන්තර්ගත හැඹිලිගත කිරීම. මෙම සේවාව වෙනම සේවාදායකයක ස්ථානගත කළ හැකි බැවින්, නවතම බාගත කළ ගොනු සියල්ල තැටියේ ගබඩා කිරීමේ හැකියාව ඇති අනාගතය සඳහා අප විසින්ම වෙන් කර ඇත.
  • සම්බන්ධතාවය නිර්මාණය කිරීමේදී යතුර පරීක්ෂා කිරීම
• විකල්ප: ප්‍රවාහ අන්තර්ගත සැකසුම්. උදාහරණයක් ලෙස, අපි සේවාවේ ඇති සියලුම ගොනු සම්පීඩනය කළහොත්, අපට මෙම මොඩියුලය තුළ සෘජුවම unzip කිරීම කළ හැකිය. ප්රතිවිපාකයක් ලෙස: IO මෙහෙයුම් සිදු කරනු ලබන්නේ ඒවා අයත් වන තැනිනි. Java හි ලේඛනාගාරයක් පහසුවෙන් අමතර මතකයක් වෙන් කරනු ඇත, නමුත් ව්‍යාපාරික තර්කනය සහිත සේවාවක් Rust/C++ කොන්දේසි වලට නැවත ලිවීමද අකාර්යක්ෂම විය හැක. අපගේ නඩුවේදී, විවිධ ක්‍රියාවලි (හෝ සේවා පවා) භාවිතා කරනු ලබන අතර, එබැවින් අපට ව්‍යාපාර තර්කනය සහ IO මෙහෙයුම් බෙහෙවින් ඵලදායී ලෙස වෙන් කළ හැක.

මෙම යෝජනා ක්‍රමය ස්ථිතික අන්තර්ගතය බෙදා හැරීමට එතරම් සමාන නොවේ (අපි සම්පූර්ණ ස්ථිතික පැකේජය කොතැනක හෝ උඩුගත නොකරන බැවින්), නමුත් යථාර්ථයේ දී, මෙම ප්‍රවේශය නිශ්චිතවම වෙනස් කළ නොහැකි දත්ත බෙදා හැරීම සම්බන්ධයෙන් සැලකිලිමත් වේ. එපමනක් නොව, මෙම යෝජනා ක්රමය අන්තර්ගතය සරලව ස්ථිතික නොවන වෙනත් අවස්ථාවන් සඳහා සාමාන්යකරණය කළ හැකිය, නමුත් වෙනස් කළ නොහැකි සහ මකා දැමිය නොහැකි කොටස් (ඒවා එකතු කළ හැකි වුවද) කට්ටලයක් ලෙස නිරූපණය කළ හැකිය.

තවත් උදාහරණයක් ලෙස (reinforcement සඳහා): ඔබ Jenkins/TeamCity සමඟ වැඩ කර ඇත්නම්, විසඳුම් දෙකම ජාවා වලින් ලියා ඇති බව ඔබ දන්නවා. ඒවා දෙකම ගොඩනඟන වාද්‍ය වෘන්දය සහ අන්තර්ගත කළමනාකරණය යන දෙකම හසුරුවන ජාවා ක්‍රියාවලියකි. විශේෂයෙන්, ඔවුන් දෙදෙනාටම "සේවාදායකයෙන් ගොනුවක් / ෆෝල්ඩරයක් මාරු කිරීම" වැනි කාර්යයන් ඇත. උදාහරණයක් ලෙස: කෞතුක වස්තු නිකුත් කිරීම, ප්‍රභව කේතය මාරු කිරීම (නියෝජිතයා ගබඩාවෙන් කෙලින්ම කේතය බාගත නොකරන විට, නමුත් සේවාදායකය ඔහු වෙනුවෙන් එය කරන විට), ලඝු-සටහන් වෙත ප්‍රවේශය. මෙම සියලු කාර්යයන් ඔවුන්ගේ IO භාරයේ වෙනස් වේ. එනම්, සංකීර්ණ ව්‍යාපාර තර්කනය සඳහා වගකිව යුතු සේවාදායකයට ඒ සමඟම විශාල දත්ත ප්‍රවාහයන් ඵලදායී ලෙස තල්ලු කිරීමට හැකි විය යුතු බව පෙනේ. වඩාත් සිත්ගන්නා කරුණ නම්, එවැනි මෙහෙයුමක් හරියටම එකම යෝජනා ක්‍රමයට අනුව එකම nginx වෙත පැවරිය හැකි වීමයි (දත්ත යතුර ඉල්ලීමට එකතු කළ යුතු හැර).

කෙසේ වෙතත්, අපි අපගේ පද්ධතියට ආපසු ගියහොත්, අපට සමාන රූප සටහනක් ලැබේ:

ඔබට පෙනෙන පරිදි, පද්ධතිය රැඩිකල් ලෙස වඩාත් සංකීර්ණ වී ඇත. දැන් එය දේශීයව ගොනු ගබඩා කරන කුඩා ක්‍රියාවලියක් පමණක් නොවේ. දැන් අවශ්‍ය වන්නේ සරලම සහය, API අනුවාද පාලනය යනාදිය නොවේ. එබැවින්, සියලු රූප සටහන් ඇඳීමෙන් පසු, විස්තාරණය පිරිවැය වටී ද යන්න විස්තරාත්මකව ඇගයීමට ලක් කිරීම වඩාත් සුදුසුය. කෙසේ වෙතත්, ඔබට පද්ධතිය පුළුල් කිරීමට අවශ්‍ය නම් (ඊටත් වඩා විශාල පරිශීලකයින් සංඛ්‍යාවක් සමඟ වැඩ කිරීමට ඇතුළුව), එවිට ඔබට සමාන විසඳුම් වෙත යාමට සිදුවේ. එහෙත්, ප්රතිඵලයක් වශයෙන්, පද්ධතිය වැඩි බරක් සඳහා වාස්තුවිද්යාත්මකව සූදානම් වේ (සෑම සංරචකයක්ම පාහේ තිරස් පරිමාණය සඳහා ක්ලෝන කළ හැක). පද්ධතිය එය නතර නොකර යාවත්කාලීන කළ හැක (සරලව සමහර මෙහෙයුම් තරමක් මන්දගාමී වනු ඇත).

මම ආරම්භයේදීම කී පරිදි, දැන් අන්තර්ජාල සේවා ගණනාවකට වැඩි බරක් ලැබීමට පටන් ගෙන තිබේ. ඔවුන්ගෙන් සමහරක් නිවැරදිව වැඩ කිරීම නැවැත්වීමට පටන් ගත්හ. ඇත්ත වශයෙන්ම, ව්‍යාපාරය මුදල් ඉපයීමට නියමිත මොහොතේ පද්ධති හරියටම අසාර්ථක විය. එනම්, කල් දැමූ බෙදාහැරීම වෙනුවට, "ඉදිරි මාස සඳහා ඔබේ බෙදා හැරීම සැලසුම් කරන්න" යනුවෙන් පාරිභෝගිකයින්ට යෝජනා කරනවා වෙනුවට, පද්ධතිය සරලව පැවසුවේ "ඔබේ තරඟකරුවන් වෙත යන්න" යන්නයි. ඇත්ත වශයෙන්ම, මෙය අඩු ඵලදායිතාවයේ මිල වේ: ලාභය ඉහළම වන විට පාඩු සිදුවනු ඇත.

නිගමනය

මෙම සියලු ප්රවේශයන් කලින් දැන සිටියහ. එම VK විසින් රූප ප්‍රදර්ශනය කිරීම සඳහා Static Content Hosting යන අදහස බොහෝ කලක සිට භාවිතා කර ඇත. බොහෝ සබැඳි ක්‍රීඩා ක්‍රීඩකයින් කලාපවලට බෙදීමට හෝ ක්‍රීඩා ස්ථාන වෙන් කිරීමට ෂර්ඩිං ක්‍රමය භාවිතා කරයි (ලෝකයම එකක් නම්). Event Sourcing ප්‍රවේශය විද්‍යුත් තැපෑලෙහි සක්‍රියව භාවිතා වේ. දත්ත නිරන්තරයෙන් ලැබෙන බොහෝ වෙළඳ යෙදුම් ඇත්ත වශයෙන්ම ලැබුණු දත්ත පෙරීමට හැකි වන පරිදි CQRS ප්‍රවේශයක් මත ගොඩනගා ඇත. හොඳයි, තිරස් පරිමාණය බොහෝ සේවා වල සෑහෙන කාලයක් තිස්සේ භාවිතා කර ඇත.

කෙසේ වෙතත්, වඩාත්ම වැදගත් දෙය නම්, මෙම සියලු රටා නවීන යෙදුම්වල යෙදීම ඉතා පහසු වී ඇත (ඒවා සුදුසු නම්, ඇත්ත වශයෙන්ම). විවිධ දත්ත මධ්‍යස්ථානවල විවිධ කැපවූ සේවාදායකයන් ඇණවුම් කිරීමට වඩා පහසු වන, වලාකුළු වහාම ෂර්ඩින් සහ තිරස් පරිමාණය ලබා දෙයි. RX වැනි පුස්තකාල සංවර්ධනය නිසා පමණක් නම් CQRS වඩාත් පහසු වී ඇත. මීට වසර 10 කට පමණ පෙර, දුර්ලභ වෙබ් අඩවියක් මේ සඳහා සහාය විය හැකිය. Apache Kafka සමඟ සූදානම් කළ බහාලුම්වලට ස්තූතිවන්ත වන පරිදි Event Sourcing සැකසීමටද ඇදහිය නොහැකි තරම් පහසු වේ. මීට වසර 10 කට පෙර මෙය නවෝත්පාදනයක් වනු ඇත, දැන් එය සාමාන්ය දෙයක්. ස්ථිතික අන්තර්ගත සත්කාරකත්වය සම්බන්ධයෙන්ද එයම වේ: වඩාත් පහසු තාක්ෂණයන් (විස්තරාත්මක ලියකියවිලි සහ පිළිතුරු විශාල දත්ත ගබඩාවක් තිබීම ඇතුළුව), මෙම ප්‍රවේශය වඩාත් සරල වී ඇත.

එහි ප්‍රතිඵලයක් වශයෙන්, තරමක් සංකීර්ණ වාස්තු විද්‍යාත්මක රටා ගණනාවක් ක්‍රියාත්මක කිරීම දැන් වඩාත් සරල වී ඇත, එයින් අදහස් කරන්නේ එය කල්තියා සමීපව බැලීම වඩා හොඳ බවයි. වසර දහයක් පැරණි යෙදුමක ක්‍රියාත්මක කිරීමේ සහ ක්‍රියාත්මක කිරීමේ අධික පිරිවැය හේතුවෙන් ඉහත විසඳුම් වලින් එකක් අතහැර දමා ඇත්නම්, දැන්, නව යෙදුමක හෝ ප්‍රතිනිර්මාණය කිරීමෙන් පසුව, ඔබට දැනටමත් වාස්තු විද්‍යාත්මකව පුළුල් කළ හැකි සේවාවක් නිර්මාණය කළ හැකිය ( කාර්ය සාධනය අනුව) සහ ගනුදෙනුකරුවන්ගෙන් නව ඉල්ලීම් සඳහා සූදානම් (උදාහරණයක් ලෙස, පුද්ගලික දත්ත දේශීයකරණය කිරීමට).

සහ වඩාත්ම වැදගත් දෙය: ඔබට සරල යෙදුමක් තිබේ නම් කරුණාකර මෙම ප්‍රවේශයන් භාවිතා නොකරන්න. ඔව්, ඒවා ලස්සන හා සිත්ගන්නා සුළුය, නමුත් පුද්ගලයින් 100 දෙනෙකුගේ උපරිම සංචාරයක් සහිත වෙබ් අඩවියක් සඳහා, ඔබට බොහෝ විට සම්භාව්‍ය මොනොලිතයකින් ලබා ගත හැකිය (අවම වශයෙන් පිටතින්, ඇතුළත ඇති සියල්ල මොඩියුලවලට බෙදිය හැකිය, ආදිය).

මූලාශ්රය: www.habr.com