හෙලෝ, මගේ නම Evgeniy. මම Yandex.Market සෙවුම් යටිතල ව්‍යුහයේ වැඩ කරමි. මට හබ්ර් ප්‍රජාවට වෙළඳපොලේ අභ්යන්තර කුස්සිය ගැන පැවසීමට අවශ්‍යයි - මට කියන්නට බොහෝ දේ ඇත. පළමුවෙන්ම, වෙළඳපල සෙවීම ක්රියා කරන ආකාරය, ක්‍රියාවලි සහ ගෘහ නිර්මාණ ශිල්පය. හදිසි අවස්ථා සමඟ කටයුතු කරන්නේ කෙසේද: එක් සේවාදායකයක් ක්රියා විරහිත වුවහොත් කුමක් සිදුවේද? එවැනි සේවාදායකයන් 100 ක් තිබේ නම් කුමක් කළ යුතුද?
අපි එකවර සේවාදායක පොකුරක් මත නව ක්‍රියාකාරීත්වය ක්‍රියාත්මක කරන ආකාරයද ඔබ ඉගෙන ගනු ඇත. පරිශීලකයින්ට කිසිදු අපහසුතාවයක් ඇති නොකර නිෂ්පාදනයේදී අපි සංකීර්ණ සේවාවන් සෘජුවම පරීක්ෂා කරන්නේ කෙසේද. පොදුවේ ගත් කල, සෑම කෙනෙකුටම හොඳ කාලයක් ගත වන පරිදි වෙළඳපල සෙවීම ක්රියා කරන ආකාරය.
අප ගැන ටිකක්: අපි විසඳන ගැටලුව කුමක්ද?
ඔබ පෙළ ඇතුළත් කරන විට, පරාමිති අනුව නිෂ්පාදනයක් සොයන්න, හෝ විවිධ ගබඩාවල මිල ගණන් සංසන්දනය කරන විට, සියලු ඉල්ලීම් සෙවුම් සේවාව වෙත යවනු ලැබේ. සෙවීම වෙළඳපොලේ විශාලතම සේවාවයි.
අපි සියලුම සෙවුම් ඉල්ලීම් සකසන්නෙමු: sites market.yandex.ru, beru.ru, Supercheck සේවාව, Yandex.Advisor, ජංගම යෙදුම්. අපි yandex.ru හි සෙවුම් ප්‍රතිඵලවල නිෂ්පාදන පිරිනැමීම් ද ඇතුළත් කරමු.
සෙවුම් සේවාවෙන් මම අදහස් කරන්නේ සෙවීම පමණක් නොව, වෙළඳපොලේ ඇති සියලුම දීමනා සහිත දත්ත සමුදායක් ද වේ. පරිමාණය මෙයයි: දිනකට සෙවුම් ඉල්ලීම් බිලියනයකට වඩා සකසනු ලැබේ. තවද සෑම දෙයක්ම බාධාවකින් තොරව ඉක්මනින් වැඩ කළ යුතු අතර සෑම විටම අපේක්ෂිත ප්රතිඵලය නිපදවිය යුතුය.
කුමක්ද: වෙළඳපල ගෘහ නිර්මාණ ශිල්පය
වෙළඳපොලේ වර්තමාන ගෘහ නිර්මාණ ශිල්පය මම කෙටියෙන් විස්තර කරමි. පහත රූප සටහන මගින් එය දළ වශයෙන් විස්තර කළ හැක.
අපි හිතමු හවුල්කාර ගබඩාවක් අපි ළඟට එනවා කියලා. ඔහු කියනවා මට සෙල්ලම් බඩුවක් විකිණීමට අවශ්‍යයි: මේ නපුරු බළලා කෑ ගසන්නෙකු සමඟ. ඒවගේම තවත් කෝපාවිෂ්ට පූසෙක් කෑගහන්නෙ නැතුව. සහ පූසෙක් විතරයි. එවිට ගබඩාව වෙළඳපල සොයන දීමනා සකස් කළ යුතුය. ගබඩාව පිරිනැමීම් සමඟ විශේෂ xml ජනනය කරන අතර අනුබද්ධ අතුරු මුහුණත හරහා මෙම xml වෙත මාර්ගය සන්නිවේදනය කරයි. ඉන්ඩෙක්සර් විසින් මෙම xml වරින් වර බාගත කරයි, දෝෂ සඳහා පරීක්ෂා කර සියලු තොරතුරු විශාල දත්ත ගබඩාවකට සුරකියි.
එහෙම save කරපු xmls ගොඩක් තියෙනවා. මෙම දත්ත සමුදායෙන් සෙවුම් දර්ශකයක් සාදනු ලැබේ. දර්ශකය අභ්යන්තර ආකෘතියෙන් ගබඩා කර ඇත. දර්ශකය නිර්මාණය කිරීමෙන් පසුව, පිරිසැලසුම් සේවාව එය සෙවුම් සේවාදායකයන් වෙත උඩුගත කරයි.
එහි ප්රතිඵලයක් වශයෙන්, squeaker සමඟ කෝපාවිෂ්ඨ බළලයක් දත්ත ගබඩාවේ දිස්වන අතර, බළලුන්ගේ දර්ශකය සේවාදායකයේ දිස්වේ.
සෙවුම් ගෘහ නිර්මාණ ශිල්පය පිළිබඳ කොටසේ අපි බළලෙකු සොයන ආකාරය මම ඔබට කියමි.
වෙළඳපල සෙවුම් ගෘහ නිර්මාණ ශිල්පය
අපි ජීවත් වන්නේ ක්ෂුද්‍ර සේවා ලෝකයක: පැමිණෙන සෑම ඉල්ලීමක්ම උප විමසීම් රාශියක් ඇති කරන අතර සේවා දුසිම් ගණනක් ඔවුන්ගේ සැකසීමට සම්බන්ධ වේ. රූප සටහන පෙන්වන්නේ කිහිපයක් පමණි:
සරල කළ ඉල්ලීම් සැකසීමේ ක්‍රමය
සෑම සේවාවකටම අපූරු දෙයක් ඇත - අද්විතීය නමක් සහිත තමන්ගේම සමතුලිතකය:
සේවාව කළමනාකරණය කිරීමේදී සමතුලිතය අපට වැඩි නම්‍යශීලී බවක් ලබා දෙයි: ඔබට, උදාහරණයක් ලෙස, යාවත්කාලීන කිරීම් සඳහා බොහෝ විට අවශ්ය වන සේවාදායකයන් ක්රියා විරහිත කළ හැකිය. සමතුලිතකරු සේවාදායකය නොමැති බව දකින අතර ස්වයංක්රීයව ඉල්ලීම් වෙනත් සේවාදායක හෝ දත්ත මධ්‍යස්ථාන වෙත හරවා යවයි. සේවාදායකයක් එකතු කිරීමේදී හෝ ඉවත් කිරීමේදී, භාරය ස්වයංක්රීයව සේවාදායකයන් අතර නැවත බෙදා හරිනු ලැබේ.
සමතුලිතයේ අද්විතීය නම දත්ත මධ්යස්ථානය මත රඳා නොපවතී. A සේවාව B වෙත ඉල්ලීමක් කරන විට, පෙරනිමියෙන් සමතුලිත B විසින් ඉල්ලීම වත්මන් දත්ත මධ්යස්ථානය වෙත හරවා යවයි. සේවාව ලබා ගත නොහැකි නම් හෝ වත්මන් දත්ත මධ්‍යස්ථානයේ නොමැති නම්, ඉල්ලීම වෙනත් දත්ත මධ්‍යස්ථාන වෙත හරවා යවනු ලැබේ.
සියලුම දත්ත මධ්‍යස්ථාන සඳහා තනි FQDN සේවාව A ස්ථානවලින් සම්පූර්ණයෙන්ම වියුක්ත කිරීමට ඉඩ සලසයි. B සේවාව සඳහා ඔහුගේ ඉල්ලීම සෑම විටම සකසනු ලැබේ. ව්යතිරේකයක් වන්නේ සේවාව සියලු දත්ත මධ්යස්ථානවල පිහිටා ඇති විටය.
නමුත් මෙම සමතුලිතකය සමඟ සෑම දෙයක්ම එතරම් රෝස නොවේ: අපට අතිරේක අතරමැදි සංරචකයක් ඇත. සමතුලිතකය අස්ථායී විය හැකි අතර, මෙම ගැටළුව අතිරික්ත සේවාදායකයන් මගින් විසඳනු ලැබේ. A සහ B සේවා අතර අමතර ප්‍රමාදයක් ද ඇත. නමුත් ප්‍රායෝගිකව එය 1 ms ට වඩා අඩු වන අතර බොහෝ සේවාවන් සඳහා මෙය තීරණාත්මක නොවේ.
අනපේක්ෂිත ලෙස කටයුතු කිරීම: සෙවුම් සේවාව තුලනය සහ ඔරොත්තු දීමේ හැකියාව
බිඳවැටීමක් ඇති බව සිතන්න: ඔබ squeaker සමඟ බළලෙකු සොයා ගත යුතුය, නමුත් සේවාදායකය බිඳ වැටේ. නැතහොත් සේවාදායකයන් 100 ක්. පිටතට යන්නේ කෙසේද? අපි ඇත්තටම බළලෙකු නොමැතිව පරිශීලකයා අත්හැරීමට යන්නේද?
තත්වය භයානකයි, නමුත් අපි එයට සූදානම්. මම පිළිවෙලට කියන්නම්.
සෙවුම් යටිතල පහසුකම් දත්ත මධ්‍යස්ථාන කිහිපයක පිහිටා ඇත:
සැලසුම් කිරීමේදී, අපි එක් දත්ත මධ්යස්ථානයක් වසා දැමීමේ හැකියාව ඇතුළත් කරමු. ජීවිතය විස්මයන්ගෙන් පිරී ඇත - නිදසුනක් ලෙස, කැණීම් යන්ත්‍රයකට භූගත කේබලයක් කපා ගත හැකිය (ඔව්, එය සිදු විය). ඉතිරි දත්ත මධ්යස්ථානවල ධාරිතාව උපරිම බරට ඔරොත්තු දීමට ප්රමාණවත් විය යුතුය.
අපි තනි දත්ත මධ්යස්ථානයක් සලකා බලමු. සෑම දත්ත මධ්‍යස්ථානයක්ම එකම සමතුලිත මෙහෙයුම් ක්‍රමය ඇත:
එක් සමතුලිතයක් අවම වශයෙන් භෞතික සේවාදායකයන් තුනක් වේ. මෙම අතිරික්තය විශ්වසනීයත්වය සඳහා සාදා ඇත. ශේෂයන් HAProx මත ධාවනය වේ.
අපි HAProx තෝරා ගත්තේ එහි ඉහළ කාර්ය සාධනය, අඩු සම්පත් අවශ්‍යතා සහ පුළුල් ක්‍රියාකාරීත්වය හේතුවෙනි. අපගේ සෙවුම් මෘදුකාංගය සෑම සේවාදායකයක් තුළම ක්‍රියාත්මක වේ.
එක් සේවාදායකයක් අසමත් වීමේ සම්භාවිතාව අඩුය. නමුත් ඔබට බොහෝ සේවාදායකයන් තිබේ නම්, අඩුම තරමින් එකක්වත් පහත වැටීමේ සම්භාවිතාව වැඩි වේ.
යථාර්ථයේ දී සිදුවන්නේ මෙයයි: සේවාදායක බිඳවැටීම. එබැවින්, සියලුම සේවාදායකයන්ගේ තත්ත්වය නිරන්තරයෙන් අධීක්ෂණය කිරීම අවශ්ය වේ. සේවාදායකය ප්රතිචාර දැක්වීම නැවැත්වුවහොත්, එය ස්වයංක්රීයව ගමනාගමනයෙන් විසන්ධි වේ. මෙම කාර්යය සඳහා, HAProxy සතුව සවි කර ඇති සෞඛ්‍ය පරීක්‍ෂණයක් ඇත. එය HTTP ඉල්ලීමක් "/ping" සමඟ තත්පරයකට වරක් සියලුම සේවාදායකයන් වෙත යයි.
HAProxy හි තවත් විශේෂාංගයක්: නියෝජිත-පරීක්ෂාව මඟින් ඔබට සියලුම සේවාදායකයන් ඒකාකාරව පැටවීමට ඉඩ සලසයි. මෙය සිදු කිරීම සඳහා, HAProxy සියලුම සේවාදායකයන් වෙත සම්බන්ධ වන අතර, ඒවායේ බර 1 සිට 100 දක්වා වත්මන් භාරය මත පදනම්ව ආපසු ලබා දෙයි. බර ගණනය කරනු ලබන්නේ සැකසීම සඳහා පෝලිමේ ඇති ඉල්ලීම් ගණන සහ ප්‍රොසෙසරය මත පැටවීම මතය.
දැන් බළලා සොයා ගැනීම ගැන. සෙවුම් ප්රතිඵල වැනි ඉල්ලීම්වල: /search?text=angry+cat. සෙවීම වේගවත් වීමට නම්, සම්පූර්ණ cat index එක RAM එකට ගැළපිය යුතුය. SSD වලින් කියවීම පවා ප්රමාණවත් තරම් වේගවත් නොවේ.
වරෙක, පිරිනැමීමේ දත්ත ගබඩාව කුඩා වූ අතර, එක් සේවාදායකයක RAM ප්රමාණවත් විය. පිරිනැමීමේ පදනම වර්ධනය වූ විට, සෑම දෙයක්ම තවදුරටත් මෙම RAM එකට නොගැලපෙන අතර, දත්ත කොටස් දෙකකට බෙදා ඇත: shard 1 සහ shard 2.
නමුත් මෙය සැමවිටම සිදු වේ: ඕනෑම විසඳුමක්, හොඳ එකක් වුවද, වෙනත් ගැටළු ඇති කරයි.
සමතුලිතය තවමත් ඕනෑම සේවාදායකයකට ගියේය. ඒත් රික්වෙස්ට් එක ආපු මැෂින් එකේ තිබ්බෙ ඉන්ඩෙක්ස් එකෙන් බාගයක් විතරයි. ඉතිරිය වෙනත් සේවාදායකයන් මත විය. එමනිසා, සේවාදායකයට අසල්වැසි යන්ත්‍රයක් වෙත යාමට සිදු විය. සේවාදායකයන් දෙකෙන්ම දත්ත ලැබීමෙන් පසු, ප්රතිඵල ඒකාබද්ධ කර නැවත ශ්රේණිගත කරන ලදී.
සමතුලිතය ඉල්ලීම් ඒකාකාරව බෙදා හරින බැවින්, සියලුම සේවාදායකයන් දත්ත යැවීම පමණක් නොව නැවත ශ්රේණිගත කිරීම්වල නිරත විය.
අසල්වැසි සේවාදායකයක් නොමැති නම් ගැටළුව ඇති විය. විසඳුම වූයේ "අසල්වැසි" සේවාදායකයක් ලෙස විවිධ ප්‍රමුඛතා සහිත සේවාදායකයන් කිහිපයක් සඳහන් කිරීමයි. පළමුව, ඉල්ලීම වත්මන් රාක්කයේ සේවාදායකයන් වෙත යවන ලදී. ප්‍රතිචාරයක් නොමැති නම්, ඉල්ලීම මෙම දත්ත මධ්‍යස්ථානයේ සියලුම සේවාදායකයන් වෙත යවන ලදී. අවසාන වශයෙන්, ඉල්ලීම වෙනත් දත්ත මධ්‍යස්ථාන වෙත ගියේය.
යෝජනා ගණන වැඩි වන විට දත්ත කොටස් හතරකට බෙදා ඇත. නමුත් මෙය සීමාව නොවීය.
දැනට, කැබලි අටක වින්‍යාසයක් භාවිතා වේ. ඊට අමතරව, ඊටත් වඩා වැඩි මතකයක් ඉතිරි කර ගැනීම සඳහා, දර්ශකය සෙවුම් කොටසකට (සෙවීම සඳහා භාවිතා කරන) සහ ස්නිපට් කොටසකට (එය සෙවීමට සම්බන්ධ නොවන) බෙදා ඇත.
එක් සේවාදායකයක තොරතුරු අඩංගු වන්නේ එක් කැබැල්ලක් සඳහා පමණි. එබැවින්, සම්පූර්ණ දර්ශකය සෙවීම සඳහා, ඔබ විවිධ කොටස් අඩංගු සේවාදායකයන් අටක් මත සෙවිය යුතුය.
සේවාදායකයන් පොකුරු වලට කාණ්ඩගත කර ඇත. සෑම පොකුරක්ම සෙවුම් යන්ත්‍ර අටක් සහ එක් ස්නිපට් සේවාදායකයක් අඩංගු වේ.
ස්නිපට් සේවාදායකය ස්ථිතික දත්ත සමඟ යතුරු අගය දත්ත ගබඩාවක් ධාවනය කරයි. ලේඛන නිකුත් කිරීම සඳහා ඒවා අවශ්ය වේ, නිදසුනක් ලෙස, squeaker සමඟ බළලෙකුගේ විස්තරයක්. සෙවුම් සේවාදායකයන්ගේ මතකය පූරණය නොකිරීමට දත්ත විශේෂයෙන් වෙනම සේවාදායකයකට මාරු කරනු ලැබේ.
ලේඛන හැඳුනුම්පත් එක් දර්ශකයක් තුළ පමණක් අද්විතීය වන බැවින්, කොටස්වල ලේඛන නොමැති තත්වයක් ඇතිවිය හැකිය. හොඳයි, නැතහොත් එක් හැඳුනුම්පතක් සඳහා විවිධ අන්තර්ගතයන් ඇත. එබැවින්, සෙවුම ක්‍රියාත්මක වීමට සහ ප්රතිඵල ආපසු ලබා දීමට, සමස්ත පොකුර පුරාවටම අනුකූලතාවයක් අවශ්ය විය. අපි අනුකූලතාව නිරීක්ෂණය කරන්නේ කෙසේදැයි මම ඔබට පහතින් කියමි.
සෙවුමම පහත පරිදි ව්‍යුහගත කර ඇත: සෙවුම් ඉල්ලීමක් සර්වර් අටෙන් ඕනෑම එකකට පැමිණිය හැක. අපි හිතමු මෙයා සර්වර් 1ට ආවා කියලා.මේ සර්වර් එක හැම තර්කයක්ම ප්‍රොසෙස් කරලා මොනවද හොයන්නේ කොහොමද කියලා තේරෙනවා. ලැබෙන ඉල්ලීම මත පදනම්ව, සේවාදායකයාට අවශ්ය තොරතුරු සඳහා බාහිර සේවාවන් සඳහා අමතර ඉල්ලීම් කළ හැකිය. එක් ඉල්ලීමක් බාහිර සේවා සඳහා ඉල්ලීම් දහයක් දක්වා අනුගමනය කළ හැක.
අවශ්ය තොරතුරු රැස් කිරීමෙන් පසු, පිරිනැමීමේ දත්ත ගබඩාවේ සෙවීමක් ආරම්භ වේ. මෙය සිදු කිරීම සඳහා, පොකුරේ ඇති සර්වර් අටටම උප විමසුම් සිදු කරනු ලැබේ.
ප්රතිචාර ලැබුණු පසු, ප්රතිඵල ඒකාබද්ධ වේ. අවසානයේදී, ප්රතිඵල උත්පාදනය කිරීමට ස්නිපට් සේවාදායකයට තවත් උප විමසුම් කිහිපයක් අවශ්ය විය හැකිය.
පොකුර තුළ සෙවුම් විමසුම් පෙනෙන්නේ: /shard1?text=angry+cat. ඊට අමතරව, පොකුරේ ඇති සියලුම සේවාදායකයන් අතර පෝරමයේ උප විමසුම් තත්පරයකට වරක් සිදු කෙරේ: /තත්ත්වය.
ඉල්ලීම /තත්ත්වය සේවාදායකය නොමැති තත්වයක් හඳුනා ගනී.
එය සෙවුම් යන්ත්‍ර අනුවාදය සහ දර්ශක අනුවාදය සියලුම සේවාදායකයන්හි සමාන බව පාලනය කරයි, එසේ නොමැතිනම් පොකුර තුළ නොගැලපෙන දත්ත පවතිනු ඇත.
එක් ස්නිපට් සේවාදායකයක් සෙවුම් යන්ත්‍ර අටකින් ඉල්ලීම් සකසන බව තිබියදීත්, එහි ප්‍රොසෙසරය ඉතා සැහැල්ලුවෙන් පටවා ඇත. ඒ නිසා අපි දැන් ස්නිපට් දත්ත වෙනම සේවාවකට මාරු කරනවා.
දත්ත මාරු කිරීම සඳහා, අපි ලේඛන සඳහා විශ්වීය යතුරු හඳුන්වා දුන්නා. එක් යතුරක් භාවිතයෙන් වෙනත් ලේඛනයක අන්තර්ගතය ආපසු ලබා දෙන තත්වයක් දැන් කළ නොහැක.
නමුත් වෙනත් ගෘහ නිර්මාණ ශිල්පයකට මාරුවීම තවමත් සම්පූර්ණ වී නොමැත. දැන් අපට අවශ්ය වන්නේ කැපවූ ස්නිපට් සේවාදායකයෙන් මිදීමටයි. ඉන්පසුව පොකුරු ව්‍යුහයෙන් සම්පූර්ණයෙන්ම ඉවත් වන්න. මෙය අපට පහසුවෙන් පරිමාණය කිරීමට ඉඩ සලසයි. අතිරේක ප්රසාද දීමනාවක් සැලකිය යුතු යකඩ ඉතුරුම් වේ.
දැන් සතුටුදායක අවසානයක් සහිත බියජනක කථා වලට. සේවාදායකය නොමැති අවස්ථා කිහිපයක් සලකා බලමු.
භයානක දෙයක් සිදු විය: එක් සේවාදායකයක් නොමැත
අපි කියමු එක් සේවාදායකයක් නොමැත. එවිට පොකුරේ ඉතිරිව ඇති සේවාදායකයන්ට දිගටම ප්රතිචාර දැක්විය හැක, නමුත් සෙවුම් ප්රතිඵල අසම්පූර්ණ වනු ඇත.
තත්ත්ව පරීක්ෂාව හරහා /තත්ත්වය එකක් නොමැති බව අසල්වැසි සේවාදායකයන් තේරුම් ගනී. එබැවින්, සම්පූර්ණත්වය පවත්වා ගැනීම සඳහා, ඉල්ලීමකට අනුව පොකුරේ ඇති සියලුම සේවාදායකයන් /පිං ඔවුන් ද ලබා ගත නොහැකි බව සමතුලිතයට ප්රතිචාර දැක්වීමට පටන් ගනී. පොකුරේ සියලුම සේවාදායකයන් මිය ගිය බව පෙනේ (එය සත්‍ය නොවේ). අපගේ පොකුරු යෝජනා ක්‍රමයේ ප්‍රධාන අවාසිය මෙයයි - අපට එයින් ඉවත් වීමට අවශ්ය වන්නේ එබැවිනි.
දෝෂයක් සමඟ අසාර්ථක වන ඉල්ලීම් වෙනත් සේවාදායකයන් මත සමතුලිත කරන්නා විසින් යවනු ලැබේ.
සමතුලිතය මියගිය සේවාදායකයන් වෙත පරිශීලක ගමනාගමනය යැවීම නතර කරයි, නමුත් ඒවායේ තත්ත්වය දිගටම පරීක්ෂා කරයි.
සේවාදායකය ලබා ගත හැකි වූ විට, එය ප්රතිචාර දැක්වීමට පටන් ගනී /පිං. මිය ගිය සේවාදායකයන්ගෙන් පිං වලට සාමාන්‍ය ප්රතිචාර පැමිණීමට පටන් ගත් වහාම, සමතුලිත කරන්නන් පරිශීලක තදබදය එහි යැවීමට පටන් ගනී. පොකුරු මෙහෙයුම යථා තත්ත්වයට පත් කර ඇත, හුරේ.
ඊටත් වඩා නරකයි: බොහෝ සේවාදායකයන් නොමැත
දත්ත මධ්‍යස්ථානයේ සේවාදායකයන්ගෙන් සැලකිය යුතු කොටසක් කපා හැරේ. කුමක් කළ යුතුද, කොහේ දුවන්නද? සමතුලිතයා නැවත ගලවා ගැනීමට පැමිණේ. සෑම සමතුලිතයෙක්ම වර්තමාන සජීවී සේවාදායකයන් සංඛ්‍යාව මතකයේ නිරන්තරයෙන් ගබඩා කරයි. එය වත්මන් දත්ත මධ්‍යස්ථානයට සැකසිය හැකි උපරිම ගමනාගමන ප්‍රමාණය නිරන්තරයෙන් ගණනය කරයි.
දත්ත මධ්‍යස්ථානයක බොහෝ සේවාදායකයන් ක්රියා විරහිත වූ විට, මෙම දත්ත මධ්‍යස්ථානයට සියලුම මාර්ග තදබදය සැකසීමට නොහැකි බව සමතුලිතකරුට වැටහේ.
එවිට අතිරික්ත තදබදය වෙනත් දත්ත මධ්‍යස්ථාන වෙත අහඹු ලෙස බෙදා හැරීමට පටන් ගනී. හැම දෙයක්ම වැඩ කරනවා, හැමෝම සතුටින්.
අපි එය කරන්නේ කෙසේද: නිකුතු ප්‍රකාශනය කිරීම
දැන් අපි සේවාවට කළ වෙනස්කම් ප්‍රකාශ කරන ආකාරය ගැන කතා කරමු. මෙන්න අපි ක්‍රියාවලි සරල කිරීමේ මාවත ගෙන ඇත: නව නිකුතුවක් නිකුත් කිරීම සම්පූර්ණයෙන්ම පාහේ ස්වයංක්රීය වේ.
ව්‍යාපෘතියේ යම් යම් වෙනස්කම් එකතු වූ විට, නව නිකුතුවක් ස්වයංක්රීයව නිර්මාණය වී එහි ගොඩනැගීම ආරම්භ වේ.
ඉන්පසුව සේවාව පරීක්ෂාවට යොමු කරනු ලැබේ, එහිදී ක්‍රියාකාරීත්වයේ ස්ථායිතාව පරීක්ෂා කරනු ලැබේ.
ඒ සමගම, ස්වයංක්රීය කාර්ය සාධන පරීක්ෂාව දියත් කරනු ලැබේ. මෙය සිදු කරනු ලබන්නේ විශේෂ සේවාවක් මගිනි. මම දැන් ඒ ගැන කතා නොකරමි - එහි විස්තරය වෙනම ලිපියකට සුදුසු ය.
පරීක්‍ෂණයේදී ප්‍රකාශනය සාර්ථක නම්, ප්‍රෙස්ටබල් හි ප්‍රකාශනය ස්වයංක්රීයව ආරම්භ වේ. Prestable යනු සාමාන්‍ය පරිශීලක ගමනාගමනය යොමු කරන විශේෂ පොකුරකි. එය දෝෂයක් නැවත ලබා දෙන්නේ නම්, සමතුලිතකය නිෂ්පාදනය සඳහා නැවත ඉල්ලීමක් කරයි.
Prestable හි, ප්රතිචාර කාලය මනිනු ලබන අතර නිෂ්පාදනයේ පෙර නිකුතුව සමඟ සංසන්දනය කෙරේ. සෑම දෙයක්ම හොඳින් තිබේ නම්, පුද්ගලයෙකු සම්බන්ධ වේ: බර පරීක්ෂා කිරීමේ ප්‍රස්ථාර සහ ප්‍රති results ල පරීක්ෂා කර නිෂ්පාදනයට පෙරළීමට පටන් ගනී.
සියලු හොඳම දේ පරිශීලකයාට ලැබේ: A/B පරීක්ෂාව
සේවාවක වෙනස්කම් සැබෑ ප්‍රතිලාභ ගෙන දෙයිද යන්න සැමවිටම පැහැදිලි නැත. වෙනස්කම් වල ප්‍රයෝජනය මැනීමට, මිනිසුන් A/B පරීක්ෂාව ඉදිරිපත් කළහ. Yandex.Market සෙවීමේදී එය ක්රියා කරන ආකාරය ගැන මම ඔබට ටිකක් කියන්නම්.
ඒ සියල්ල ආරම්භ වන්නේ නව ක්‍රියාකාරිත්වය සක්‍රීය කරන නව CGI පරාමිතියක් එක් කිරීමෙනි. අපගේ පරාමිතිය මෙසේ වීමට ඉඩ දෙන්න: market_new_functionality=1. ධජය තිබේ නම් කේතයේ අපි මෙම ක්‍රියාකාරිත්වය සක්‍රීය කරමු:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}නව ක්‍රියාකාරීත්වය නිෂ්පාදනයට යොමු කෙරේ.
A/B පරීක්ෂාව ස්වයංක්රීය කිරීමට, සවිස්තරාත්මක තොරතුරු සපයන විශේෂිත සේවාවක් ඇත . සේවාව තුළ අත්හදා බැලීමක් නිර්මාණය කර ඇත. ගමනාගමන කොටස සකසා ඇත, උදාහරණයක් ලෙස, 15%. ප්‍රතිශත සකසා ඇත්තේ විමසුම් සඳහා නොව පරිශීලකයන් සඳහාය. අත්හදා බැලීමේ කාලසීමාව ද පෙන්වා ඇත, උදාහරණයක් ලෙස, සතියක්.
අත්හදා බැලීම් කිහිපයක් එකවර සිදු කළ හැකිය. සැකසුම් තුළ ඔබට වෙනත් අත්හදා බැලීම් සමඟ ඡේදනය කළ හැකිද යන්න සඳහන් කළ හැකිය.
ප්රතිඵලයක් වශයෙන්, සේවාව ස්වයංක්රීයව තර්කයක් එකතු කරයි market_new_functionality=1 පරිශීලකයින්ගෙන් 15% දක්වා. එය තෝරාගත් මිනුම් ද ස්වයංක්රීයව ගණනය කරයි. අත්හදා බැලීම අවසන් වූ පසු, විශ්ලේෂකයින් ප්රතිඵල දෙස බලා නිගමනවලට එළඹේ. සොයාගැනීම් මත පදනම්ව, නිෂ්පාදනයට හෝ ශෝධනයට පෙරළීමට තීරණයක් ගනු ලැබේ.
වෙළඳපොලේ දක්ෂ හස්තය: නිෂ්පාදනයේදී පරීක්ෂා කිරීම
නිෂ්පාදනයේ නව ක්‍රියාකාරීත්වයක ක්‍රියාකාරිත්වය පරීක්ෂා කිරීමට ඔබට අවශ්ය බව බොහෝ විට සිදු වේ, නමුත් අධික බරක් යටතේ “සටන්” තත්වයන් තුළ එය හැසිරෙන්නේ කෙසේදැයි ඔබට විශ්වාස නැත.
විසඳුමක් ඇත: CGI පරාමිතිවල ඇති කොඩි A/B පරීක්ෂණ සඳහා පමණක් නොව, නව ක්‍රියාකාරීත්වය පරීක්ෂා කිරීමටද භාවිතා කළ හැක.
අපි ඔබට සේවාව අවදානම්වලට නිරාවරණය නොකර දහස් ගණන් සේවාදායකයන් මත ක්ෂණිකව වින්‍යාසය වෙනස් කිරීමට ඔබට ඉඩ සලසන මෙවලමක් සාදන ලදී. ඒකට කියන්නේ Stop Tap කියලා. මුල් අදහස වූයේ පිරිසැලසුමක් නොමැතිව යම් ක්‍රියාකාරීත්වයක් ඉක්මනින් අක්‍රිය කිරීමට හැකි වීමයි. එවිට මෙවලම පුළුල් වී වඩාත් සංකීර්ණ විය.
සේවා ප්‍රවාහ රූප සටහන පහත දැක්වේ.
කොඩි අගයන් API හරහා සකසා ඇත. කළමනාකරණ සේවාව මෙම අගයන් දත්ත ගබඩාවේ ගබඩා කරයි. සියලුම සේවාදායකයන් සෑම තත්පර දහයකට වරක් දත්ත ගබඩාවට ගොස්, ධජ අගයන් පොම්ප කර එක් එක් ඉල්ලීම සඳහා මෙම අගයන් යොදන්න.
නැවතුම් ටැප් තුළ ඔබට අගයන් වර්ග දෙකක් සැකසිය හැක:
1) කොන්දේසි සහිත ප්රකාශයන්. එක් අගයක් සත්‍ය වූ විට අයදුම් කරන්න. උදාහරණ වශයෙන්:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}DC3 ස්ථානයේ ඉල්ලීම සකසන විට "1" අගය යෙදේ. beru.ru වෙබ් අඩවිය සඳහා දෙවන පොකුරේ ඉල්ලීම සකස් කරන විට අගය "4" වේ.
2) කොන්දේසි විරහිත අගයන්. කොන්දේසි කිසිවක් සපුරා නොමැති නම් පෙරනිමියෙන් අයදුම් කරන්න. උදාහරණ වශයෙන්:
වටිනාකම, වටිනාකම!
අගයක් විශ්මය ජනක ලක්ෂ්‍යයකින් අවසන් වන්නේ නම්, එයට ඉහළ ප්‍රමුඛතාවයක් දෙනු ලැබේ.
CGI පරාමිති විග්‍රහකය URL විග්‍රහ කරයි. ඉන්පසු Stop Tap වෙතින් අගයන් යොදයි.
පහත ප්‍රමුඛතා සහිත අගයන් යොදනු ලැබේ:
- Stop Tap (විස්මයාර්ථ ලකුණ) වෙතින් වැඩි ප්‍රමුඛතාවයක් සහිතව.
- ඉල්ලීමේ වටිනාකම.
- Stop tap වෙතින් පෙරනිමි අගය.
- කේතයේ පෙරනිමි අගය.
කොන්දේසි සහිත අගයන්ගෙන් දක්වා ඇති බොහෝ කොඩි තිබේ - ඒවා අප දන්නා සියලුම අවස්ථා සඳහා ප්රමාණවත් වේ:
- දත්ත මධ්යස්ථානය.
- පරිසරය: නිෂ්පාදනය, පරීක්ෂා කිරීම, සෙවනැල්ල.
- ස්ථානය: වෙළෙඳපොළ, බෙරු.
- පොකුරු අංකය.
මෙම මෙවලම සමඟ, ඔබට යම් සේවාදායක කණ්ඩායමක් මත නව ක්‍රියාකාරිත්වය සක්‍රීය කළ හැකිය (උදාහරණයක් ලෙස, එක් දත්ත මධ්‍යස්ථානයක පමණක්) සහ සම්පූර්ණ සේවාවට විශේෂ අවදානමකින් තොරව මෙම ක්‍රියාකාරීත්වයේ ක්‍රියාකාරිත්වය පරීක්ෂා කරන්න. ඔබ කොතැනක හෝ බරපතල වැරැද්දක් කළත්, සියල්ල වැටෙන්නට පටන් ගෙන මුළු දත්ත මධ්‍යස්ථානයම බැස ගියත්, balancers ඉල්ලීම් වෙනත් දත්ත මධ්‍යස්ථාන වෙත හරවා යවනු ඇත. අවසාන පරිශීලකයන් කිසිවක් නොදකිනු ඇත.
ඔබ ගැටලුවක් දුටුවහොත්, ඔබට වහාම ධජය එහි පෙර අගයට ආපසු ලබා දිය හැකි අතර වෙනස්කම් ආපසු හරවනු ලැබේ.
මෙම සේවාවට එහි අවාසි ද ඇත: සංවර්ධකයින් එයට බෙහෙවින් ආදරය කරන අතර බොහෝ විට සියලු වෙනස්කම් නැවතුම් ටැප් වෙත තල්ලු කිරීමට උත්සාහ කරයි. අපි උත්සාහ කරන්නේ අවභාවිතයට එරෙහිව සටන් කිරීමටයි.
ඔබ දැනටමත් නිෂ්පාදනයට පෙරළීමට සූදානම්ව ස්ථාවර කේතයක් ඇති විට Stop Tap ප්රවේශය හොඳින් ක්රියා කරයි. ඒ සමගම, ඔබ තවමත් සැකයන් ඇති අතර, ඔබට "සටන්" තත්වයන් තුළ කේතය පරීක්ෂා කිරීමට අවශ්ය වේ.
කෙසේ වෙතත්, Stop Tap සංවර්ධනය අතරතුර පරීක්ෂා කිරීම සඳහා සුදුසු නොවේ. සංවර්ධකයින් සඳහා "සෙවණ පොකුර" නමින් වෙනම පොකුරක් ඇත.
රහස් පරීක්ෂණ: සෙවනැලි පොකුර
එක් පොකුරකින් ලැබෙන ඉල්ලීම් සෙවනැලි පොකුරට අනුපිටපත් කෙරේ. නමුත් සමතුලිතය මෙම පොකුරෙන් ලැබෙන ප්රතිචාර සම්පූර්ණයෙන්ම නොසලකා හරියි. එහි ක්රියාකාරිත්වයේ රූප සටහන පහත දැක්වේ.
සැබෑ "සටන්" තත්වයන් තුළ ඇති පරීක්ෂණ පොකුරක් අපට ලැබේ. සාමාන්‍ය පරිශීලක ගමනාගමනය එතනට යයි. පොකුරු දෙකෙහිම දෘඪාංග සමාන වේ, එබැවින් කාර්ය සාධනය සහ දෝෂ සැසඳිය හැක.
සමතුලිතය ප්රතිචාර සම්පූර්ණයෙන්ම නොසලකා හරින බැවින්, අවසාන පරිශීලකයින්ට සෙවනැලි පොකුරෙන් ප්රතිචාර නොපෙනේ. එමනිසා, වැරැද්දක් කිරීමට බියක් නැත.
සොයා ගැනීම්
ඉතින්, අපි වෙළඳපල සෙවීම ගොඩනඟා ගත්තේ කෙසේද?
සෑම දෙයක්ම සුමටව සිදු කිරීමට, අපි ක්‍රියාකාරීත්වය වෙනම සේවාවලට වෙන් කරමු. මේ ආකාරයෙන් අපට අවශ්ය සංරචක පමණක් පරිමාණය කර සංරචක සරල කළ හැකිය. වෙනත් කණ්ඩායමකට වෙනම සංරචකයක් පැවරීම සහ එය මත වැඩ කිරීම සඳහා වගකීම් බෙදා ගැනීම පහසුය. මෙම ප්රවේශය සමඟ යකඩ සැලකිය යුතු ඉතිරියක් පැහැදිලි ප්ලස් වේ.
සෙවනැලි පොකුර ද අපට උපකාරී වේ: අපට සේවා සංවර්ධනය කළ හැකිය, ක්‍රියාවලියේදී ඒවා පරීක්ෂා කර පරිශීලකයාට බාධා නොකරන්න.
හොඳයි, නිෂ්පාදනයේ දී පරීක්ෂා කිරීම, ඇත්ත වශයෙන්ම. සේවාදායක දහස් ගණනක වින්‍යාසය වෙනස් කිරීමට අවශ්‍යද? පහසුයි, Stop Tap එක භාවිතා කරන්න. මේ ආකාරයෙන් ඔබට වහාම සූදානම් කළ සංකීර්ණ විසඳුමක් පෙරළා ගැටළු ඇති වුවහොත් ස්ථාවර අනුවාදයකට ආපසු යා හැක.
දිනෙන් දින වර්ධනය වන දීමනා පදනමක් සමඟින් අපි වෙළඳපොළ වේගවත් සහ ස්ථාවර කරන ආකාරය පෙන්වීමට මට හැකි වූ බව මම බලාපොරොත්තු වෙමි. අපි සේවාදායක ගැටළු විසඳන්නේ කෙසේද, විශාල ඉල්ලීම් සංඛ්‍යාවක් සමඟ කටයුතු කරන්නේ කෙසේද, සේවාවේ නම්‍යශීලීභාවය වැඩි දියුණු කරන්නේ කෙසේද සහ වැඩ ක්‍රියාවලීන්ට බාධා නොකර මෙය කරන්නේ කෙසේද.
මූලාශ්රය: www.habr.com