විධිමත් ක්‍රියාවලියක් සහ අන්තර් සම්බන්ධිත සේවාවන් දුසිම් ගනනක් සහිත Lamoda වැනි විශාල සමාගමකට එහි ප්‍රවේශය සැලකිය යුතු ලෙස වෙනස් කිරීමට බල කළ හැක්කේ කුමක් ද? අභිප්රේරණය සම්පූර්ණයෙන්ම වෙනස් විය හැකිය: ව්‍යවස්ථාදායකයේ සිට සියලුම ක්‍රමලේඛකයින්ට ආවේණික වූ අත්හදා බැලීමේ ආශාව දක්වා.
නමුත් මෙය ඔබට අතිරේක ප්රතිලාභ මත ගණන් ගත නොහැකි බව ඉන් අදහස් නොවේ. ඔබ කෆ්කා හි සිදුවීම් මත පදනම් වූ API ක්රියාත්මක කළහොත් ඔබට ජයග්‍රහණය කළ හැකි දේ සර්ජි සයිකා ඔබට කියනු ඇත () විශාල වෙඩි තැබීම් සහ රසවත් සොයාගැනීම් ගැන අනිවාර්යයෙන්ම කතා කරනු ඇත - අත්හදා බැලීම ඔවුන් නොමැතිව කළ නොහැක.
වියාචනය: මෙම ලිපිය පදනම් වී ඇත්තේ 2018 නොවැම්බර් මාසයේදී HighLoad++ හි සර්ජි විසින් පවත්වන ලද රැස්වීමක ද්‍රව්‍ය මත ය. කෆ්කා සමඟ වැඩ කිරීමේ ලමෝඩාගේ සජීවී අත්දැකීම කාලසටහනේ අනෙකුත් වාර්තාවලට වඩා අඩුවෙන් සවන්දෙන්නන් ආකර්ෂණය කර ගත්තේය. ඔබට සැමවිටම සමාන අදහස් ඇති අය සොයා ගත හැකි සහ කළ යුතු බවට මෙය කදිම උදාහරණයක් යැයි අපි සිතමු, තවද HighLoad++ හි සංවිධායකයින් මේ සඳහා හිතකර වාතාවරණයක් නිර්මාණය කිරීමට දිගටම උත්සාහ කරනු ඇත.
ක්රියාවලිය ගැන
Lamoda යනු තමන්ගේම සම්බන්ධතා මධ්‍යස්ථානයක්, බෙදාහැරීමේ සේවාවක් (සහ බොහෝ අනුබද්ධිත ආයතන), ඡායාරූප චිත්‍රාගාරයක්, විශාල ගබඩාවක් ඇති විශාල ඊ-වාණිජ්‍ය වේදිකාවක් වන අතර මේ සියල්ල තමන්ගේම මෘදුකාංගයක් මත ක්රියාත්මක වේ. ගෙවීම් ක්‍රම දුසිම් ගණනක් ඇත, මෙම සේවාවන් සමහරක් හෝ සියල්ලම භාවිතා කළ හැකි සහ ඔවුන්ගේ නිෂ්පාදන පිළිබඳ යාවත්කාලීන තොරතුරු දැන ගැනීමට කැමති b2b හවුල්කරුවන්. මීට අමතරව, Lamoda රුසියානු සමූහාණ්ඩුව හැර රටවල් තුනක ක්රියාත්මක වන අතර එහි සෑම දෙයක්ම ටිකක් වෙනස් වේ. සමස්තයක් වශයෙන්, නව ඇණවුමක් වින්‍යාස කිරීමට ක්‍රම සියයකට වඩා තිබේ, එය තමන්ගේම ආකාරයෙන් සැකසිය යුතුය. මේ සියල්ල සමහර විට නොපැහැදිලි ආකාරවලින් සන්නිවේදනය කරන දුසිම් ගනනක සේවාවන්ගේ උපකාරයෙන් ක්රියා කරයි. ප්රධාන වගකීම ඇණවුම් තත්ත්වයන් වන මධ්‍යම පද්ධතියක් ද ඇත. අපි ඇයව හඳුන්වන්නේ BOB, මම ඇය සමඟ වැඩ කරනවා.
සිදුවීම් මත පදනම් වූ API සමඟ මුදල් ආපසු ගෙවීමේ මෙවලම
සිද්ධීන්-ධාවනය යන වචනය තරමක් හක්කකි; තව ටිකක් ඉදිරියට අපි මෙයින් අදහස් කරන්නේ කුමක්ද යන්න වඩාත් විස්තරාත්මකව අර්ථ දක්වන්නෙමු. මම Kafka හි සිදුවීම් මත පදනම් වූ API ප්‍රවේශය උත්සාහ කිරීමට තීරණය කළ සන්දර්භය සමඟ ආරම්භ කරමි.
ඕනෑම වෙළඳසැලක, පාරිභෝගිකයින් ගෙවන ඇණවුම් වලට අමතරව, භාණ්ඩය පාරිභෝගිකයාට නොගැලපෙන නිසා ගබඩාවට මුදල් ආපසු ලබා දිය යුතු අවස්ථා තිබේ. මෙය සාපේක්ෂව කෙටි ක්රියාවලියකි: අවශ්ය නම්, අපි තොරතුරු පැහැදිලි කර මුදල් මාරු කරන්නෙමු.
නමුත් නීති සම්පාදනයේ වෙනස්කම් හේතුවෙන් ආපසු පැමිණීම වඩාත් සංකීර්ණ වූ අතර, ඒ සඳහා වෙනම ක්ෂුද්ර සේවාවක් ක්රියාත්මක කිරීමට අපට සිදු විය.
අපගේ අභිප්රේරණය:
- නීතිය FZ-54 - කෙටියෙන් කිවහොත්, සෑම මුදල් ගනුදෙනුවක් ගැනම, එය ප්‍රතිලාභයක් හෝ කුවිතාන්සියක් වේවා, මිනිත්තු කිහිපයක් වැනි තරමක් කෙටි SLA කාලයක් තුළ බදු කාර්යාලයට වාර්තා කිරීම නීතියට අවශ්ය වේ. අපි, ඊ-වාණිජ්‍ය සමාගමක් ලෙස, බොහෝ මෙහෙයුම් සිදු කරන්නෙමු. තාක්ෂණික වශයෙන්, මෙයින් අදහස් කරන්නේ නව වගකීම (සහ ඒ නිසා නව සේවාවක්) සහ සියලුම සම්බන්ධිත පද්ධතිවල වැඩිදියුණු කිරීම් ය.
- BOB බෙදීම යනු BOB මූලික නොවන වගකීම් විශාල සංඛ්‍යාවකින් නිදහස් කිරීමට සහ එහි සමස්ත සංකීර්ණත්වය අඩු කිරීමට සමාගමේ අභ්‍යන්තර ව්‍යාපෘතියකි.
මෙම රූප සටහන ප්රධාන Lamoda පද්ධති පෙන්වයි. දැන් බොහෝ ඒවා වැඩි ය හැකිලෙන මොනොලිතයක් වටා ක්ෂුද්ර සේවා 5-10 ක තාරකා මණ්ඩලයක්. ඒවා සෙමින් වර්ධනය වෙමින් පවතී, නමුත් අපි ඒවා කුඩා කිරීමට උත්සාහ කරමු, මන්ද තෝරාගත් කොටස මැදට යෙදවීම භයානක ය - අපට එය වැටීමට ඉඩ දිය නොහැක. සියලුම හුවමාරු (ඊතල) වෙන් කර ගැනීමට අපට බල කෙරෙන අතර ඒවායින් කිසිවක් ලබා ගත නොහැකි විය හැකි බව සැලකිල්ලට ගනිමු.
BOB සතුව බොහෝ හුවමාරු ඇත: ගෙවීම් පද්ධති, බෙදා හැරීමේ පද්ධති, දැනුම්දීම් පද්ධති, ආදිය.
තාක්ෂණික වශයෙන් BOB යනු:
- ~ 150k කේත රේඛා + ~ 100k පරීක්ෂණ පේළි;
- php7.2 + Zend 1 සහ Symfony සංරචක 3;
- >100 API සහ ~50 පිටතට යන ඒකාබද්ධ කිරීම්;
- තමන්ගේම ව්‍යාපාරික තර්කයක් සහිත රටවල් 4ක්.
BOB යෙදවීම මිල අධික සහ වේදනාකාරී වේ, කේත ප්‍රමාණය සහ එය විසඳන ගැටළු කිසිවකුට ඒ සියල්ල ඔළුවට දැමිය නොහැක. පොදුවේ, එය සරල කිරීමට බොහෝ හේතු තිබේ.
ආපසු පැමිණීමේ ක්රියාවලිය
මුලදී, ක්‍රියාවලියට පද්ධති දෙකක් සම්බන්ධ වේ: BOB සහ ගෙවීම්. දැන් තවත් දෙකක් දිස්වේ:
- මූල්‍යකරණ සේවාව, මූල්‍යකරණය සහ බාහිර සේවාවන් සමඟ සන්නිවේදනය පිළිබඳ ගැටළු ගැන සැලකිලිමත් වනු ඇත.
- BOB පුම්බා නොදැමීම සඳහා හුදෙක් නව හුවමාරු අඩංගු මුදල් ආපසු ගෙවීමේ මෙවලම.
දැන් ක්රියාවලිය මේ වගේ ය:
- BOB වෙත ආපසු ගෙවීමක් සඳහා ඉල්ලීමක් ලැබේ.
- BOB මෙම මුදල් ආපසු ගෙවීමේ මෙවලම ගැන කතා කරයි.
- ආපසු ගෙවීමේ මෙවලම ගෙවීමට කියයි: "මුදල් ආපසු දෙන්න."
- ගෙවීම මුදල් ආපසු ලබා දෙයි.
- Refund Tool සහ BOB එකිනෙක තත්ව සමමුහුර්ත කරයි, මන්ද දැනට ඔවුන් දෙදෙනාටම එය අවශ්ය වේ. BOB හි UI, ගිණුම්කරණය සඳහා වාර්තා සහ සාමාන්යයෙන් එතරම් පහසුවෙන් මාරු කළ නොහැකි දත්ත රාශියක් ඇති බැවින්, ආපසු ගෙවීමේ මෙවලම වෙත සම්පූර්ණයෙන්ම මාරු වීමට අපි තවමත් සූදානම් නැත. ඔබ පුටු දෙකක වාඩි විය යුතුය.
- මූල්‍යකරණය සඳහා වූ ඉල්ලීම පහව යයි.
එහි ප්‍රතිඵලයක් වශයෙන්, අපි Kafka - Event-bus හි සිදුවීම් බස් රථයක් සෑදුවෙමු, එය සියල්ල ආරම්භ විය. හුරේ, දැන් අපට ඇත්තේ අසාර්ථක වීමේ එක් කරුණක් (උපහාසය).
වාසි සහ අවාසි ඉතා පැහැදිලිය. අපි බස් රථයක් සෑදුවා, එයින් අදහස් කරන්නේ දැන් සියලුම සේවාවන් එය මත රඳා පවතින බවයි. මෙය සැලසුම සරල කරයි, නමුත් පද්ධතියට අසාර්ථක වීමේ එක් ලක්ෂයක් හඳුන්වා දෙයි. කෆ්කා කඩා වැටෙනු ඇත, ක්රියාවලිය නතර වනු ඇත.
සිදුවීම් මත පදනම් වූ API යනු කුමක්ද?
මෙම ප්‍රශ්නයට හොඳ පිළිතුරක් මාටින් ෆෝලර්ගේ වාර්තාවේ ඇත (GOTO 2017) .
අපි කළ දේ කෙටියෙන්:
- හරහා සියලුම අසමමුහුර්ත හුවමාරුව අවසන් කරන්න සිදුවීම් ගබඩා කිරීම. ජාලය හරහා සිදුවන තත්ත්‍ව වෙනස් වීමක් ගැන උනන්දුවක් දක්වන සෑම පාරිභෝගිකයෙකුටම දැනුම් දෙනවා වෙනුවට, මධ්‍යගත ගබඩාවකට තත්ත්‍වයේ වෙනසක් ගැන අපි සිදුවීමක් ලියන අතර, මාතෘකාව ගැන උනන්දුවක් දක්වන පාරිභෝගිකයන් එතැන් සිට දිස්වන සියල්ල කියවයි.
- මෙම නඩුවේ සිදුවීම දැනුම්දීමකි (දැනුම්දීම්) කොහේ හරි යමක් වෙනස් වී ඇති බව. උදාහරණයක් ලෙස, ඇණවුම් තත්ත්වය වෙනස් වී ඇත. දැනුම්දීමේ ඇතුළත් නොවන තත්ත්‍වයේ වෙනසක් සමඟ ඇති සමහර දත්ත ගැන උනන්දුවක් දක්වන පාරිභෝගිකයෙකුට එහි තත්ත්වය තමාටම දැනගත හැකිය.
- උපරිම විකල්පය වන්නේ අංගසම්පූර්ණ සිදුවීම් මූලාශ්රය, රාජ්ය මාරු කිරීම, සැකසීමට අවශ්ය සියලුම තොරතුරු අඩංගු වන්නේ කුමන අවස්ථාවකද: එය පැමිණියේ කොහෙන්ද සහ කුමන තත්ත්වයට ගියේද, හරියටම දත්ත වෙනස් වූයේ කෙසේද, යනාදිය එකම ප්‍රශ්නය ශක්‍යතාව සහ ඔබට ගබඩා කිරීමට දැරිය හැකි තොරතුරු ප්‍රමාණයයි.
ආපසු ගෙවීමේ මෙවලම දියත් කිරීමේ කොටසක් ලෙස, අපි තුන්වන විකල්පය භාවිතා කළෙමු. සවිස්තරාත්මක තොරතුරු උකහා ගැනීමේ අවශ්‍යතාවයක් නොමැති බැවින් මෙම සරල සිද්ධි සැකසීම, තවද එය සෑම නව සිදුවීමක්ම පාරිභෝගිකයින්ගෙන් ඉල්ලීම් ලබා ගැනීමේ පැහැදිලි කිරීමේ පිපිරීමක් උත්පාදනය කරන අවස්ථාව ඉවත් කළේය.
මුදල් ආපසු ගැනීමේ මෙවලම් සේවාව පටවා නැත, ඉතින් කෆ්කාගේ අවශ්‍යතාවයට වඩා පෑනෙහි රසය වැඩියි. මුදල් ආපසු ගෙවීමේ සේවාව අධික බර සහිත ව්යාපෘතියක් බවට පත් වුවහොත් ව්‍යාපාරය සතුටු වනු ඇතැයි මම නොසිතමි.
Async හුවමාරුව ලෙස
අසමමුහුර්ත හුවමාරු සඳහා, PHP දෙපාර්තමේන්තුව සාමාන්යයෙන් RabbitMQ භාවිතා කරයි. අපි ඉල්ලීම සඳහා දත්ත එකතු කර, එය පෝලිමේ තබා, එම සේවාවේම පාරිභෝගිකයා එය කියවා එය යැව්වා (නැතහොත් එය නොයවා ඇත). API සඳහාම, Lamoda ක්රියාකාරීව Swagger භාවිතා කරයි. අපි API එකක් නිර්මාණය කර, එය Swagger හි විස්තර කර, සේවාලාභියා සහ සේවාදායක කේතය උත්පාදනය කරන්නෙමු. අපි තරමක් වැඩි දියුණු කළ JSON RPC 2.0 ද භාවිතා කරමු.
සමහර ස්ථානවල ESB බස් රථ භාවිතා වේ, සමහරක් ක්රියාකාරීMQ මත ජීවත් වේ, නමුත්, සාමාන්යයෙන්, RabbitMQ - සම්මත.
Async exchange TO BE
Events-bus හරහා හුවමාරුව සැලසුම් කිරීමේදී, සාදෘශ්‍යයක් සොයා ගත හැක. අපි සිදුවීම් ව්‍යුහ විස්තර හරහා අනාගත දත්ත හුවමාරුව ඒ හා සමානව විස්තර කරමු. yaml ආකෘතියෙන්, කේත උත්පාදනය අප විසින්ම කළ යුතුව තිබුණි, ජෙනරේටරය පිරිවිතරයන්ට අනුව DTOs නිර්මාණය කරන අතර සේවාදායකයින්ට සහ සේවාදායකයන්ට ඔවුන් සමඟ වැඩ කිරීමට උගන්වයි. පරම්පරාව භාෂා දෙකකට යයි - golang සහ php. මෙය පුස්තකාල ස්ථාවරව තබා ගැනීමට උපකාරී වේ. ජෙනරේටරය ගොලාං භාෂාවෙන් ලියා ඇත, ඒ නිසා එයට ගොගි යන නම ලැබුණි.
කෆ්කා හි සිදුවීම් මූලාශ්‍ර කිරීම සාමාන්‍ය දෙයකි. Kafka Confluent හි ප්රධාන ව්‍යවසාය අනුවාදයෙන් විසඳුමක් තිබේ , අපගේ වසම් සහෝදරයන් වන Zalando වෙතින් විසඳුමක්. අපගේ වැනිලා කෆ්කා සමඟ ආරම්භ කිරීමට පෙළඹවීම - මෙයින් අදහස් කරන්නේ අපි එය සෑම තැනකම භාවිතා කරන්නේද යන්න තීරණය කරන තෙක් විසඳුම නොමිලේ තැබීම සහ උපාමාරු සහ වැඩිදියුණු කිරීම් සඳහා අපටම ඉඩ ලබා දීමයි: අපට අපගේ සහාය අවශ්යයි JSON RPC 2.0, භාෂා දෙකක් සඳහා ජනක යන්ත්‍ර සහ අපි බලමු වෙන මොනවද කියලා.
එවැනි සතුටුදායක අවස්ථාවකදී ද දළ වශයෙන් සමාන විසඳුමක් කළ Zalando නම් ව්‍යාපාරයක් තිබියදී අපට එය ඵලදායී ලෙස භාවිතා කිරීමට නොහැකි වීම හාස්‍යයට කරුණකි.
දියත් කිරීමේදී වාස්තුවිද්‍යාත්මක රටාව පහත පරිදි වේ: අපි කෆ්කා වෙතින් කෙලින්ම කියවන නමුත් ලියන්නේ සිදුවීම්-බස් හරහා පමණි. Kafka හි කියවීමට බොහෝ දේ සූදානම් වේ: තැරැව්කරුවන්, සමතුලිත කරන්නන්, සහ එය තිරස් පරිමාණය සඳහා අඩු හෝ වැඩි වශයෙන් සූදානම්, මට මෙය තබා ගැනීමට අවශ්ය විය. අපට එක් Gateway හෙවත් Events-bus එකක් හරහා පටිගත කිරීම සම්පූර්ණ කිරීමට අවශ්ය වූ අතර, ඒ මන්ද යන්නයි.
සිදුවීම්-බස්
නැත්නම් උත්සව බස් එකක්. මෙය හුදෙක් රාජ්ය රහිත http ද්වාරයකි, එය වැදගත් භූමිකාවන් කිහිපයක් ඉටු කරයි:
- නිෂ්පාදනය වලංගුකරණය - සිදුවීම් අපගේ පිරිවිතරයන්ට අනුකූලදැයි අපි පරීක්ෂා කරමු.
- සිදුවීම් මාස්ටර් පද්ධතිය, එනම්, ව්‍යුහයන් වලංගු යැයි සලකනු ලබන්නේ කුමන සිදුවීම් සමඟද යන ප්‍රශ්නයට පිළිතුරු සපයන සමාගමෙහි ප්රධාන සහ එකම පද්ධතිය මෙයයි. වලංගුකරණයට අන්තර්ගතය දැඩිව සඳහන් කිරීමට දත්ත වර්ග සහ enums ඇතුළත් වේ.
- හැෂ් ශ්‍රිතය බෙදා හැරීම සඳහා - කෆ්කා පණිවිඩ ව්‍යුහය ප්රධාන අගයක් වන අතර යතුරේ හැෂ් භාවිතයෙන් එය තැබිය යුතු ස්ථානය ගණනය කෙරේ.
මන්ද
අපි විධිමත් ක්‍රියාවලියක් සහිත විශාල සමාගමක වැඩ කරන්නෙමු. කිසිවක් වෙනස් කරන්නේ ඇයි? මෙය අත්හදා බැලීමකි, සහ අපි ප්රතිලාභ කිහිපයක් ලබා ගැනීමට බලාපොරොත්තු වෙමු.
1:n+1 හුවමාරු (එකක් සිට බොහෝ)
Kafka නව පාරිභෝගිකයින් API වෙත සම්බන්ධ කිරීම ඉතා පහසු කරයි.
ඔබට එකවර පද්ධති කිහිපයක (සහ සමහර නව ඒවා තුළ) යාවත්කාලීනව තබා ගැනීමට අවශ්ය නාමාවලියක් ඇතැයි සිතමු. මීට පෙර, අපි set-API ක්රියාත්මක කරන ලද මිටියක් නිර්මාණය කළ අතර, ප්රධාන පද්ධතියට පාරිභෝගික ලිපින පිළිබඳව දැනුම් දෙන ලදී. දැන් ප්රධාන පද්ධතිය මාතෘකාවට යාවත්කාලීන කිරීම් යවන අතර උනන්දුවක් දක්වන සෑම කෙනෙකුම එය කියවයි. නව පද්ධතියක් දර්ශනය වී ඇත - අපි එය මාතෘකාව සඳහා අත්සන් කළෙමු. ඔව්, බණ්ඩලය ද, නමුත් සරලයි.
BOB හි කොටසක් වන ආපසු ගෙවීමේ මෙවලම සම්බන්ධයෙන්, ඒවා Kafka හරහා සමමුහුර්ත කර තබා ගැනීම අපට පහසු වේ. මුදල් ආපසු ලබා දුන් බව ගෙවීම් පවසයි: BOB, RT මේ ගැන සොයා ගත්තා, ඔවුන්ගේ තත්ත්වය වෙනස් කළා, මූල්‍යකරණ සේවාව මේ ගැන සොයාගෙන චෙක්පතක් නිකුත් කළා.
සේවාලාභියාට ඔහුගේ ඇණවුම/ආපසු සම්බන්ධ පුවත් දැනුම් දෙන ඒකාබද්ධ දැනුම්දීම් සේවාවක් නිර්මාණය කිරීමට අප සැලසුම් කර ඇත. දැන් මෙම වගකීම පද්ධති අතර පැතිර ඇත. Kafka වෙතින් අදාළ තොරතුරු අල්ලා ගැනීමට සහ ඒවාට ප්‍රතිචාර දැක්වීමට (සහ වෙනත් පද්ධතිවල මෙම දැනුම්දීම් අක්‍රිය කිරීමට) දැනුම්දීම් සේවාවට ඉගැන්වීම අපට ප්රමාණවත් වනු ඇත. නව සෘජු හුවමාරු අවශ්ය නොවේ.
දත්ත මත පදනම් වූ
පද්ධති අතර තොරතුරු පාරදෘශ්‍ය වේ - ඔබට කුමන “ලේ වැකි ව්‍යවසායයක්” තිබුණත් සහ ඔබේ පසුබෑම කෙතරම් තරබාරු වුවත්. Lamoda සතුව දත්ත විශ්ලේෂණ දෙපාර්තමේන්තුවක් ඇති අතර එය පද්ධති වලින් දත්ත රැස් කර එය ව්‍යාපාර සඳහා සහ බුද්ධිමත් පද්ධති සඳහා නැවත භාවිත කළ හැකි ආකාරයක් බවට පත් කරයි. Kafka ඔබට ඉක්මනින් ඔවුන්ට බොහෝ දත්ත ලබා දීමට සහ එම තොරතුරු ප්රවාහය යාවත්කාලීනව තබා ගැනීමට ඔබට ඉඩ සලසයි.
අනුකරණ ලොගය
RabbitMQ හි මෙන් කියවීමෙන් පසු පණිවිඩ අතුරුදහන් නොවේ. සිදුවීමක් සැකසීම සඳහා ප්රමාණවත් තොරතුරු අඩංගු වන විට, වස්තුවේ මෑත වෙනස්වීම් පිළිබඳ ඉතිහාසයක් අපට ඇත, සහ, අවශ්ය නම්, මෙම වෙනස්කම් යෙදීමේ හැකියාව.
පිටපත් කිරීමේ ලොගයේ ගබඩා කාලය මෙම මාතෘකාවට ලිවීමේ තීව්‍රතාවය මත රඳා පවතී; ගබඩා කාලය සහ දත්ත පරිමාව මත නම්‍යශීලී ලෙස සීමාවන් සැකසීමට Kafka ඔබට ඉඩ සලසයි. තීව්‍ර මාතෘකා සඳහා, කෙටි කාලීන අකර්මන්‍යතාවයකදී පවා තොරතුරු අතුරුදහන් වීමට පෙර සියලුම පාරිභෝගිකයින්ට තොරතුරු කියවීමට කාලය තිබීම වැදගත්ය. සඳහා දත්ත ගබඩා කිරීමට සාමාන්යයෙන් හැකි ය දින ඒකක, සහාය සඳහා සෑහෙන තරම් ප්රමාණවත් වේ.
ඊළඟට, කෆ්කා ගැන නොදන්නා අය සඳහා ලියකියවිලි ටිකක් නැවත කියවීම (පින්තූරය ද ලේඛනගත කිරීමෙනි)
AMQP හි පෝලිම් ඇත: අපි පාරිභෝගිකයා සඳහා පෝලිමකට පණිවිඩ ලියන්නෙමු. සාමාන්යයෙන්, එක් පෝලිමක් එකම ව්‍යාපාරික තර්කයක් සහිත එක් පද්ධතියකින් සකසනු ලැබේ. ඔබට පද්ධති කිහිපයකට දැනුම් දීමට අවශ්ය නම්, ඔබට පෝලිම් කිහිපයකට ලිවීමට හෝ ඒවා ක්ලෝන කරන fanout යාන්ත්‍රණය සමඟ හුවමාරුව වින්‍යාස කිරීමට යෙදුමට ඉගැන්විය හැකිය.
කෆ්කා සතුවද එවැනිම වියුක්තයක් ඇත මාතෘකාව, ඔබ පණිවිඩ ලියන, නමුත් ඒවා කියවීමෙන් පසු අතුරුදහන් නොවේ. පෙරනිමියෙන්, ඔබ Kafka වෙත සම්බන්ධ වූ විට, ඔබට සියලු පණිවිඩ ලැබෙන අතර ඔබ නතර කළ ස්ථානය සුරැකීමේ විකල්පය ඇත. එනම්, ඔබ අනුක්‍රමිකව කියවන අතර, ඔබට පණිවිඩය කියවූ ලෙස සලකුණු නොකළ හැක, නමුත් ඔබට දිගටම කියවිය හැකි හැඳුනුම්පත සුරකින්න. ඔබ පදිංචි වූ හැඳුනුම්පත ඕෆ්සෙට් ලෙස හැඳින්වේ, සහ යාන්ත්‍රණය කැප ඕෆ්සෙට් වේ.
ඒ අනුව විවිධ තර්ක ක්රියාත්මක කළ හැකිය. උදාහරණයක් ලෙස, අපි විවිධ රටවල් සඳහා අවස්ථා 4 කින් BOB ඇත - Lamoda රුසියාව, කසකස්තානය, යුක්රේනය, බෙලරුස් වේ. ඒවා වෙන වෙනම යොදවා ඇති බැවින්, ඔවුන්ට තරමක් වෙනස් වින්‍යාස සහ ඔවුන්ගේම ව්‍යාපාර තර්ක ඇත. අපි පණිවිඩයේ සඳහන් කරන්නේ එය කුමන රටකටද යන්නයි. සෑම රටකම සෑම BOB පාරිභෝගිකයෙක්ම විවිධ groupId එකකින් කියවයි, එම පණිවිඩය ඔවුන්ට අදාළ නොවන්නේ නම්, ඔවුන් එය මඟහරියි, i.e. වහාම ඕෆ්සෙට් +1 සිදු කරයි. අපගේ ගෙවීම් සේවාව මගින් එකම මාතෘකාව කියවා ඇත්නම්, එය වෙනම කණ්ඩායමක් සමඟ එසේ කරයි, එබැවින් ඕෆ්සෙට් ඡේදනය නොවේ.
සිදුවීම් අවශ්යතා:
- දත්ත සම්පූර්ණත්වය. මෙම සිදුවීම සැකසීමට හැකි වන පරිදි ප්රමාණවත් දත්ත තිබීමට මම කැමතියි.
- අඛණ්ඩතාව. අපි Events-bus වෙත මෙම සිදුවීම ස්ථීර බව සත්‍යාපනය පවරමු සහ එයට එය සැකසිය හැක.
- පිළිවෙල වැදගත්. ආපසු පැමිණීමේදී, ඉතිහාසය සමඟ වැඩ කිරීමට අපට බල කෙරෙයි. දැනුම්දීම් සමඟ, ඇණවුම වැදගත් නොවේ, ඒවා සමජාතීය දැනුම්දීම් නම්, කුමන ඇණවුම පළමුව පැමිණියත් විද්‍යුත් තැපෑල එකම වේ. මුදල් ආපසු ගෙවීමේදී, පැහැදිලි ක්‍රියාවලියක් ඇත; අපි අනුපිළිවෙල වෙනස් කළහොත්, ව්‍යතිරේක පැන නගිනු ඇත, මුදල් ආපසු ගෙවීම නිර්මාණය කිරීම හෝ සැකසීම සිදු නොවේ - අපි වෙනස් තත්වයක අවසන් වනු ඇත.
- අනුකූලතාව. අපට ගබඩාවක් ඇත, දැන් අපි API වෙනුවට සිදුවීම් සාදන්නෙමු. අපගේ සේවාවන් වෙත නව සිදුවීම් සහ පවතින ඒවාට සිදුවන වෙනස්කම් පිළිබඳ තොරතුරු ඉක්මනින් සහ ලාභදායී ලෙස සම්ප්‍රේෂණය කිරීමට අපට ක්‍රමයක් අවශ්ය වේ. මෙය සාක්ෂාත් කරගනු ලබන්නේ වෙනම git ගබඩාවක සහ කේත උත්පාදක යන්ත්‍රවල පොදු පිරිවිතරයක් මගිනි. එබැවින්, විවිධ සේවාවන්හි සේවාදායකයින් සහ සේවාදායකයන් සම්බන්ධීකරණය කර ඇත.
ලමෝඩා හි කෆ්කා
අපට Kafka ස්ථාපනයන් තුනක් තිබේ:
- සටහන්;
- R&D;
- සිදුවීම්-බස්.
අද අපි කතා කරන්නේ අවසාන කරුණ ගැන පමණයි. Events-bus හි, අපට ඉතා විශාල ස්ථාපනයන් නොමැත - තැරැව්කරුවන් 3 ක් (සේවාදායකයන්) සහ මාතෘකා 27 ක් පමණි. රීතියක් ලෙස, එක් මාතෘකාවක් එක් ක්රියාවලියකි. නමුත් මෙය සියුම් කරුණක් වන අතර, අපි දැන් එය ස්පර්ශ කරන්නෙමු.
ඉහත ඇත්තේ rps ප්‍රස්ථාරයයි. ආපසු ගෙවීමේ ක්රියාවලිය ටර්කියුයිස් රේඛාවකින් සලකුණු කර ඇත (ඔව්, X අක්ෂයේ ඇති එක), සහ රෝස රේඛාව අන්තර්ගත යාවත්කාලීන ක්රියාවලිය වේ.
Lamoda නාමාවලියෙහි නිෂ්පාදන මිලියන ගණනක් අඩංගු වන අතර දත්ත සෑම විටම යාවත්කාලීන වේ. සමහර එකතු කිරීම් විලාසිතාවෙන් බැහැර වන අතර, ඒවා වෙනුවට නව ඒවා නිකුත් කරනු ලබන අතර, නව මාදිලි නිරන්තරයෙන් නාමාවලියෙහි දක්නට ලැබේ. අපි හෙට අපගේ ගනුදෙනුකරුවන්ට රසවත් වන්නේ කුමක්දැයි පුරෝකථනය කිරීමට උත්සාහ කරමු, එබැවින් අපි නිරන්තරයෙන් නව දේවල් මිල දී ගෙන ඒවා ඡායාරූප ගත කර සංදර්ශක නඩුව යාවත්කාලීන කරන්නෙමු.
රෝස උච්ච යනු නිෂ්පාදන යාවත්කාලීන කිරීම්, එනම් නිෂ්පාදනවල වෙනස්කම් වේ. යාලුවනේ පින්තූර ගත්තා, පින්තූර ගත්තා, පසුව නැවතත්! - සිදුවීම් ඇසුරුමක් පටවා ඇත.
Lamoda Events භාවිතා කරන අවස්ථා
පහත සඳහන් මෙහෙයුම් සඳහා අපි ඉදිකරන ලද ගෘහ නිර්මාණ ශිල්පය භාවිතා කරමු:
- ආපසු තත්ත්වය නිරීක්ෂණය කිරීම: සියලුම සම්බන්ධිත පද්ධති වලින් ක්‍රියාවට ඇමතුම් සහ තත්ත්‍ව ලුහුබැඳීම. ගෙවීම්, තත්ව, මූල්‍යකරණය, දැනුම්දීම්. මෙහිදී අපි ප්‍රවේශය පරීක්ෂා කර, මෙවලම් සාදා, සියලු දෝෂ එකතු කර, ලේඛන ලියා එය භාවිතා කරන ආකාරය අපගේ සගයන්ට පැවසුවෙමු.
- නිෂ්පාදන කාඩ්පත් යාවත්කාලීන කිරීම: වින්යාසය, පාර-දත්ත, ලක්ෂණ. එක් පද්ධතියක් කියවන (දර්ශණය වන) සහ කිහිපයක් ලියන්න.
- ඊමේල්, තල්ලු සහ කෙටි පණිවුඩ: ඇණවුම එකතු කර ඇත, ඇණවුම පැමිණ ඇත, ආපසු පැමිණීම පිළිගෙන ඇත, ඒවායින් බොහොමයක් තිබේ.
- තොග, ගබඩාව අලුත් කිරීම - අයිතමවල ප්‍රමාණාත්මක යාවත්කාලීන කිරීම, අංක පමණි: ගබඩාවට පැමිණීම, ආපසු පැමිණීම. භාණ්ඩ වෙන් කිරීම හා සම්බන්ධ සියලුම පද්ධති වඩාත්ම වත්මන් දත්ත සමඟ ක්රියාත්මක වීම අවශ්ය වේ. දැනට, කොටස් යාවත්කාලීන පද්ධතිය තරමක් සංකීර්ණ ය; Kafka එය සරල කරනු ඇත.
- දත්ත විශ්ලේෂණය (R&D දෙපාර්තමේන්තුව), ML මෙවලම්, විශ්ලේෂණ, සංඛ්‍යාලේඛන. අපට අවශ්ය වන්නේ තොරතුරු විනිවිද භාවයෙන් තිබීමයි - කෆ්කා මේ සඳහා හොඳින් ගැලපේ.
පසුගිය මාස හය තුළ සිදු වූ විශාල ගැටිති සහ රසවත් සොයාගැනීම් පිළිබඳ වඩාත් රසවත් කොටස දැන්.
නිර්මාණ ගැටළු
අපට අලුත් දෙයක් කිරීමට අවශ්ය යැයි කියමු - උදාහරණයක් ලෙස, සම්පූර්ණ බෙදා හැරීමේ ක්රියාවලිය Kafka වෙත මාරු කරන්න. දැන් ක්‍රියාවලියේ කොටසක් BOB හි ඇණවුම් සැකසීමේදී ක්රියාත්මක වේ. බෙදා හැරීමේ සේවාවට ඇණවුමක් මාරු කිරීම, අතරමැදි ගබඩාවකට ගමන් කිරීම සහ යනාදිය පිටුපස තත්ව ආකෘතියක් ඇත. සම්පූර්ණ ඒකලිතයක්, දෙකක් පවා ඇත, ඊට අමතරව බෙදා හැරීම සඳහා කැප වූ API පොකුරක් ඇත. ඔවුන් බෙදා හැරීම ගැන බොහෝ දේ දන්නවා.
මේවා සමාන ප්‍රදේශ බව පෙනේ, නමුත් BOB හි ඇණවුම් සැකසීම සහ නැව්ගත කිරීමේ පද්ධතිය වෙනස් තත්ව ඇත. උදාහරණයක් ලෙස, සමහර කුරියර් සේවා අතරමැදි තත්ත්වයන් යවන්නේ නැත, නමුත් අවසාන ඒවා පමණි: "බෙදා හරින ලද" හෝ "නැතිවූ". අනෙක් අය, ඊට පටහැනිව, භාණ්ඩ චලනය ගැන ඉතා විස්තරාත්මකව වාර්තා කරයි. සෑම කෙනෙකුටම තමන්ගේම වලංගු කිරීමේ නීති ඇත: සමහරුන්ට, විද්‍යුත් තැපෑල වලංගු වේ, එනම් එය සැකසෙනු ඇත; අනෙක් අයට එය වලංගු නැත, නමුත් සම්බන්ධතා සඳහා දුරකථන අංකයක් ඇති බැවින් ඇණවුම තවමත් සකසනු ඇත, සහ එවැනි ඇණවුමක් කිසිසේත්ම සකසන්නේ නැති බව යමෙකු කියනු ඇත.
දත්ත ප්රවාහය
කෆ්කා සම්බන්ධයෙන් ගත් කල, දත්ත ප්රවාහය සංවිධානය කිරීමේ ප්‍රශ්නය පැන නගී. මෙම කාර්යයට කරුණු කිහිපයක් මත පදනම් වූ උපාය මාර්ගයක් තෝරා ගැනීම ඇතුළත් වේ; අපි ඒවා සියල්ල හරහා යමු.
එක් මාතෘකාවක් තුළ හෝ වෙනත් මාතෘකාවක් තුළ?
අපට සිදුවීම් පිරිවිතරයක් ඇත. BOB හි අපි එවැනි සහ එවැනි ඇණවුමක් ලබා දිය යුතු බව ලියා දක්වන්නෙමු: ඇණවුම් අංකය, එහි සංයුතිය, සමහර SKU සහ තීරු කේත යනාදිය. භාණ්ඩ ගබඩාවට පැමිණි විට, බෙදා හැරීමට තත්ත්වයන්, වේලා මුද්‍රා සහ අවශ්ය සියල්ල ලබා ගැනීමට හැකි වේ. නමුත් පසුව අපට BOB හි මෙම දත්ත පිළිබඳ යාවත්කාලීන ලබා ගැනීමට අවශ්යයි. අපට බෙදාහැරීමෙන් දත්ත ලැබීමේ ප්‍රතිලෝම ක්‍රියාවලියක් ඇත. මෙයද එම සිදුවීමද? නැත්නම් මෙය තමන්ගේම මාතෘකාවට සුදුසු වෙනම හුවමාරුවක්ද?
බොහෝ දුරට ඉඩ ඇත්තේ, ඔවුන් බොහෝ දුරට සමාන වනු ඇති අතර, එක් මාතෘකාවක් කිරීමට පෙළඹවීම පදනම් විරහිත නොවේ, මන්ද වෙනම මාතෘකාවක් යනු වෙනම පාරිභෝගිකයින්, වෙනම වින්යාසයන්, මේ සියල්ලේ වෙනම පරම්පරාවකි. නමුත් සත්‍යයක් නොවේ.
නව ක්ෂේත්‍රයක් හෝ නව සිදුවීමක්?
නමුත් ඔබ එකම සිදුවීම් භාවිතා කරන්නේ නම්, තවත් ගැටළුවක් පැන නගී. උදාහරණයක් ලෙස, BOB හට උත්පාදනය කළ හැකි ආකාරයේ DTO ජනනය කිරීමට සියලුම බෙදාහැරීමේ පද්ධතිවලට නොහැක. අපි ඔවුන්ට හැඳුනුම්පත යවමු, නමුත් ඔවුන්ට එය අවශ්ය නොවන නිසා ඔවුන් එය සුරැකෙන්නේ නැත, සහ සිදුවීම්-බස් ක්රියාවලිය ආරම්භ කිරීමේ දෘෂ්ටි කෝණයෙන්, මෙම ක්ෂේත්රය අවශ්ය වේ.
අපි Event-bus සඳහා මෙම ක්ෂේත්රය අවශ්ය බවට රීතියක් හඳුන්වා දෙන්නේ නම්, එවිට අපට BOB හෝ ආරම්භක සිදුවීම් හසුරුවෙහි අමතර වලංගුකරණ නීති සැකසීමට බල කෙරේ. වලංගුකරණය සේවාව පුරා පැතිරීමට පටන් ගනී - මෙය ඉතා පහසු නොවේ.
තවත් ගැටළුවක් වන්නේ වර්ධක සංවර්ධනය සඳහා පෙළඹීමයි. සිදුවීමට යමක් එකතු කළ යුතු බව අපට කියනු ලැබේ, සමහර විට අපි ඒ ගැන සිතන්නේ නම්, එය වෙනම සිදුවීමක් විය යුතුය. නමුත් අපගේ යෝජනා ක්රමය තුළ, වෙනම සිදුවීමක් වෙනම මාතෘකාවක් වේ. වෙනම මාතෘකාවක් යනු මා ඉහත විස්තර කළ සමස්ත ක්‍රියාවලියයි. සංවර්ධකයා JSON යෝජනා ක්‍රමයට සරලව වෙනත් ක්ෂේත්‍රයක් එක් කර එය ප්‍රතිජනනය කිරීමට පෙළඹේ.
ආපසු ගෙවීම් සම්බන්ධයෙන්, අපි වසර භාගයක් තුළ සිදුවීම් සිදුවීමට පැමිණියෙමු. අපට ආපසු ගෙවීමේ යාවත්කාලීනය නමින් එක් මෙටා-සිදුවීමක් තිබුණි, මෙම යාවත්කාලීනය ඇත්ත වශයෙන්ම කුමක්දැයි විස්තර කරන ආකාරයේ ක්ෂේත්‍රයක් එහි තිබුණි. මේ නිසා, මෙම වර්ගය සමඟ මෙම සිදුවීම වලංගු කරන්නේ කෙසේදැයි අපට පැවසූ වලංගුකරුවන් සමඟ “පුදුමාකාර” ස්විචයන් අප සතුව තිබුණි.
සිදුවීම් අනුවාදය
Kafka හි පණිවිඩ වලංගු කිරීමට ඔබට භාවිතා කළ හැක , නමුත් එය වහාම එය මත තැබීමට සහ Confluent භාවිතා කිරීමට අවශ්ය විය. අපගේ නඩුවේදී, අපි අනුවාදයන් සමඟ ප්රවේශම් විය යුතුය. ආදර්ශය "වමේ" ඇති නිසා අනුරූ ලොගයෙන් පණිවිඩ නැවත කියවීමට සැමවිටම නොහැකි වනු ඇත. මූලික වශයෙන්, එය ආකෘතිය පසුපසට අනුකූල වන පරිදි අනුවාද ගොඩනැගීමට හැරේ: උදාහරණයක් ලෙස, ක්ෂේත්‍රයක් තාවකාලිකව විකල්ප කරන්න. වෙනස්කම් ඉතා ශක්තිමත් නම්, අපි නව මාතෘකාවකින් ලිවීමට පටන් ගනිමු, පැරණි එක කියවීම අවසන් වූ විට සේවාදායකයින් මාරු කරන්න.
කොටස්වල සහතික කියවීමේ අනුපිළිවෙල
කෆ්කා තුළ ඇති මාතෘකා කොටස් වලට බෙදා ඇත. අප ආයතන සහ හුවමාරු සැලසුම් කරන අතරතුර මෙය ඉතා වැදගත් නොවේ, නමුත් එය පරිභෝජනය කරන්නේ කෙසේද සහ පරිමාණය කරන්නේ කෙසේද යන්න තීරණය කිරීමේදී වැදගත් වේ.
සුපුරුදු නඩුවේදී, ඔබ කෆ්කා හි එක් මාතෘකාවක් ලියන්න. පෙරනිමියෙන්, එක් කොටසක් භාවිතා කරනු ලබන අතර, මෙම මාතෘකාවේ ඇති සියලුම පණිවිඩ එයට යයි. තවද පාරිභෝගිකයා මෙම පණිවිඩ අනුපිළිවෙලින් කියවයි. දැන් අපි කියමු වෙනස් පාරිභෝගිකයින් දෙදෙනෙකු විසින් පණිවිඩ කියවන පරිදි පද්ධතිය පුළුල් කළ යුතුය. උදාහරණයක් ලෙස, ඔබ කෙටි පණිවුඩ යවන්නේ නම්, ඔබට අමතර කොටසක් සෑදීමට කෆ්කාට පැවසිය හැකිය, එවිට කෆ්කා පණිවිඩ කොටස් දෙකකට බෙදීමට පටන් ගනී - අඩක් මෙහි, අඩක් මෙහි.
කෆ්කා ඔවුන්ව බෙදන්නේ කෙසේද? සෑම පණිවිඩයකටම ශරීරයක් (අපි JSON ගබඩා කරන) සහ යතුරක් ඇත. ඔබට මෙම යතුරට හැෂ් ශ්‍රිතයක් ඇමිණිය හැකිය, එමඟින් පණිවිඩය යන්නේ කුමන කොටසටද යන්න තීරණය කරනු ඇත.
අපගේ මුදල් ආපසු ගෙවීමේදී, මෙය වැදගත් වේ, අපි කොටස් දෙකක් ගතහොත්, සමාන්තර පාරිභෝගිකයෙකු පළමු සිදුවීමට පෙර දෙවන සිදුවීම සැකසීමට ඉඩ ඇති අතර කරදර ඇති වේ. හෑෂ් ශ්‍රිතය මඟින් එකම යතුර සහිත පණිවිඩ එකම කොටසකින් අවසන් වන බව සහතික කරයි.
සිදුවීම් එදිරිව විධාන
මෙය අප මුහුණ දුන් තවත් ගැටලුවකි. සිදුවීම යනු නිශ්චිත සිදුවීමකි: අපි කියන්නේ යම්කිසි තැනක යම් දෙයක් සිදු වූ බව (යමක්_සිදුවීය), උදාහරණයක් ලෙස, අයිතමයක් අවලංගු කර හෝ ආපසු ගෙවීමක් සිදු විය. යමෙක් මෙම සිදුවීම් වලට සවන් දෙන්නේ නම්, "අයිතමය අවලංගු කරන ලද" අනුව, මුදල් ආපසු ගෙවීමේ ආයතනය සාදනු ලබන අතර, "ආපසු මුදල් ආපසු ලබා දීම සිදු විය" යන්න සැකසුම් තුළ කොතැනක හෝ ලියා ඇත.
නමුත් සාමාන්යයෙන්, ඔබ සිදුවීම් සැලසුම් කරන විට, ඔබට ඒවා නිෂ්ඵල ලෙස ලිවීමට අවශ්ය නැත - යමෙකු ඒවා කියවන බව ඔබ විශ්වාස කරයි. යමක්_සිදු වූ දෙයක් (අයිතම_අවලංගු කළ, ආපසු_පසු ගෙවූ) නොව, කළ යුතු_යමක් ලිවීමට ඉහළ පෙළඹවීමක් ඇත. උදාහරණයක් ලෙස, අයිතමය ආපසු ලබා දීමට සූදානම්.
එක් අතකින්, එය සිදුවීම භාවිතා කරන ආකාරය යෝජනා කරයි. අනෙක් අතට, එය සාමාන්‍ය සිදුවීම් නාමයක් මෙන් බොහෝ සෙයින් අඩු ය. ඊට අමතරව, එය do_something විධානයට මෙතැන් සිට දුර නොවේ. නමුත් මෙම සිදුවීම යමෙකු කියවන බවට ඔබට සහතිකයක් නැත; ඔබ එය කියවා ඇත්නම්, ඔබ එය සාර්ථකව කියවා ඇත; ඔබ එය සාර්ථකව කියවා ඇත්නම්, ඔබ යමක් කළා, යමක් සාර්ථක වූ බව. සිදුවීමක් යමක් කරන්න_යමක් බවට පත් වූ මොහොතේ, ප්‍රතිපෝෂණය අවශ්ය වේ, එය ගැටලුවකි.
RabbitMQ හි අසමමුහුර්ත හුවමාරුවේදී, ඔබ පණිවිඩය කියවන විට, http වෙත යන්න, ඔබට ප්‍රතිචාරයක් ඇත - අවම වශයෙන් පණිවිඩය ලැබුණු බව. ඔබ කෆ්කාට ලියන විට, ඔබ කෆ්කාට ලියූ පණිවිඩයක් ඇත, නමුත් එය සැකසූ ආකාරය ගැන ඔබ කිසිවක් නොදනී.
එමනිසා, අපගේ නඩුවේදී, අපට ප්‍රතිචාර දැක්වීමේ සිදුවීමක් හඳුන්වා දී නිරීක්ෂණ සැකසීමට සිදු විය, එවිට බොහෝ සිදුවීම් එව්වා නම්, එවැනි වේලාවකට පසු ප්‍රතිචාර සිදුවීම් සමාන ප්‍රමාණයක් පැමිණිය යුතුය. මෙය සිදු නොවන්නේ නම්, යමක් වැරදී ඇති බව පෙනේ. උදාහරණයක් ලෙස, අපි "item_ready_to_refund" සිදුවීම එව්වේ නම්, අපි මුදල් ආපසු ගෙවීමක් සාදනු ඇතැයි අපේක්ෂා කරමු, සේවාදායකයා වෙත මුදල් ආපසු ලබා දෙනු ඇත, සහ "money_refunded" සිදුවීම අප වෙත එවනු ලැබේ. නමුත් මෙය නිශ්චිත නැත, එබැවින් නිරීක්ෂණය කිරීම අවශ්ය වේ.
නිකායන්
තරමක් පැහැදිලි ගැටළුවක් තිබේ: ඔබ මාතෘකාවකින් අනුක්‍රමිකව කියවා ඔබට යම් නරක පණිවිඩයක් ඇත්නම්, පාරිභෝගිකයා වැටෙනු ඇත, ඔබ තවදුරටත් ඉදිරියට නොයනු ඇත. ඔබට අවශ්යයි සියලුම පාරිභෝගිකයින් නවත්වන්න, දිගටම කියවීම සඳහා ඕෆ්සෙට් කරන්න.
අපි ඒ ගැන දැන සිටියෙමු, අපි එය ගණන් කළෙමු, නමුත් එය සිදු විය. මෙය සිදු වූයේ සිදුවීම්-බස් යන දෘෂ්ටි කෝණයෙන් සිදුවීම වලංගු වූ බැවිනි, යෙදුම් වලංගුකරුගේ දෘෂ්ටි කෝණයෙන් සිදුවීම වලංගු විය, නමුත් PostgreSQL හි දෘෂ්ටි කෝණයෙන් එය වලංගු නොවීය, මන්ද අපගේ එක් පද්ධතියක් තුළ UNSIGNED INT සමඟ MySQL, සහ අලුතින් ලියන ලද පද්ධතියේ PostgreSQL තිබුණේ INT සමඟ පමණි. ඔහුගේ ප්‍රමාණය ටිකක් කුඩා වන අතර හැඳුනුම්පත නොගැලපේ. සිම්ෆොනි ව්යතිරේකයකින් මිය ගියේය. ඇත්ත වශයෙන්ම, අපි ව්‍යතිරේකය අල්ලා ගත්තේ අප එය මත විශ්වාසය තබා මෙම ඕෆ්සෙට් කිරීමට යන බැවිනි, නමුත් ඊට පෙර අපට පණිවිඩය අසාර්ථක ලෙස සැකසූ බැවින් ගැටළු කවුන්ටරය වැඩි කිරීමට අවශ්ය විය. මෙම ව්යාපෘතියේ කවුන්ටර ද දත්ත සමුදායේ ඇති අතර, Symfony දැනටමත් දත්ත සමුදාය සමඟ සන්නිවේදනය වසා දමා ඇති අතර, දෙවන ව්‍යතිරේකය මගින් හිලව් කිරීමට අවස්ථාවක් නොමැතිව සමස්ත ක්‍රියාවලියම මරා දැමීය.
සේවාව ටික වේලාවක් පැවතුනි - වාසනාවකට මෙන්, කෆ්කා සමඟ මෙය එතරම් නරක නැත, මන්ද පණිවිඩ පවතින බැවිනි. වැඩ යථා තත්ත්වයට පත් වූ විට, ඔබට ඒවා කියවා අවසන් කළ හැකිය. එය සුවපහසුයි.
මෙවලම් හරහා අත්තනෝමතික ඕෆ්සෙට් එකක් සැකසීමේ හැකියාව කෆ්කාට ඇත. නමුත් මෙය සිදු කිරීම සඳහා, ඔබ සියලු පාරිභෝගිකයින් නැවැත්විය යුතුය - අපගේ නඩුවේදී, පාරිභෝගිකයින්, නැවත ස්ථානගත කිරීම් නොමැති වෙනම නිකුතුවක් සකස් කරන්න. එවිට කෆ්කා හි ඔබට මෙවලම් හරහා ඕෆ්සෙට් මාරු කළ හැකි අතර, පණිවිඩය හරහා යනු ඇත.
තවත් සූක්ෂ්මතාවයක් - අනුරූ ලඝු-සටහන vs rdkafka.so - අපගේ ව්යාපෘතියේ විශේෂතා වලට සම්බන්ධ වේ. අපි PHP භාවිතා කරන අතර, PHP හි, රීතියක් ලෙස, සියලුම පුස්තකාල rdkafka.so ගබඩාව හරහා Kafka සමඟ සන්නිවේදනය කරයි, පසුව යම් ආකාරයක දවටනයක් ඇත. සමහර විට මේවා අපගේ පුද්ගලික දුෂ්කරතා විය හැකිය, නමුත් අප දැනටමත් කියවා ඇති දේවලින් කොටසක් නැවත කියවීම එතරම් පහසු නොවන බව පෙනී ගියේය. පොදුවේ, මෘදුකාංග ගැටළු ඇති විය.
කොටස් සමඟ වැඩ කිරීමේ විශේෂතා වෙත ආපසු යාම, එය ලේඛනගත කිරීමෙහි නිවැරදිව ලියා ඇත පාරිභෝගිකයන් >= මාතෘකා කොටස්. නමුත් මම මේ ගැන දැනගත්තේ මා කැමති වූවාට වඩා බොහෝ පසුවය. ඔබට පරිමාණය කිරීමට සහ පාරිභෝගිකයින් දෙදෙනෙකු සිටීමට අවශ්ය නම්, ඔබට අවම වශයෙන් කොටස් දෙකක්වත් අවශ්ය වේ. එනම්, ඔබට පණිවිඩ 20 ක් එකතු වී ඇති එක් කොටසක් තිබේ නම් සහ ඔබ නැවුම් එකක් සාදා ඇත්නම්, පණිවිඩ ගණන ඉක්මනින් සමාන නොවේ. එබැවින්, සමාන්තර පාරිභෝගිකයින් දෙදෙනෙකු සිටීම සඳහා, ඔබ කොටස් සමඟ කටයුතු කළ යුතුය.
අධීක්ෂණය
එය අප නිරීක්ෂණය කරන ආකාරය අනුව පවතින ප්‍රවේශයේ ඇති ගැටළු මොනවාද යන්න වඩාත් පැහැදිලි වනු ඇතැයි මම සිතමි.
උදාහරණයක් ලෙස, අපි දත්ත සමුදායේ නිෂ්පාදන කීයක් මෑතකදී ඒවායේ තත්ත්වය වෙනස් කර ඇත්දැයි ගණනය කරමු, ඒ අනුව, මෙම වෙනස්කම් මත පදනම්ව සිදුවීම් සිදු විය යුතු අතර, අපි මෙම අංකය අපගේ නිරීක්ෂණ පද්ධතියට යවමු. එවිට කෆ්කා වෙතින් අපට දෙවන අංකය ලැබේ, ඇත්ත වශයෙන්ම සිදුවීම් කීයක් වාර්තා වී තිබේද යන්න. නිසැකවම, මෙම සංඛ්යා දෙක අතර වෙනස සෑම විටම ශුන්ය විය යුතුය.
ඊට අමතරව, නිෂ්පාදකයා කරන්නේ කෙසේද, සිදුවීම්-බස් වෙත පණිවිඩ ලැබී තිබේද සහ පාරිභෝගිකයා කරන්නේ කෙසේද යන්න ඔබ නිරීක්ෂණය කළ යුතුය. උදාහරණයක් ලෙස, පහත ප්‍රස්ථාරවල, මුදල් ආපසු ගෙවීමේ මෙවලම හොඳින් ක්රියාත්මක වේ, නමුත් BOB හට පැහැදිලිවම යම් ගැටළු තිබේ (නිල් කඳු මුදුන්).
මම දැනටමත් පාරිභෝගික කණ්ඩායම් පසුබෑම ගැන සඳහන් කළෙමි. දළ වශයෙන් කිවහොත්, මෙය නොකියවූ පණිවිඩ ගණනයි. පොදුවේ ගත් කල, අපගේ පාරිභෝගිකයින් ඉක්මනින් වැඩ කරයි, එබැවින් ප්‍රමාදය සාමාන්යයෙන් 0 වේ, නමුත් සමහර විට කෙටි කාලීන උච්චස්ථානයක් තිබිය හැකිය. කෆ්කාට මෙය කොටුවෙන් පිටත කළ හැක, නමුත් ඔබට නිශ්චිත කාල පරතරයක් සැකසිය යුතුය.
ව්යාපෘතියක් තිබේ එය ඔබට කෆ්කා පිළිබඳ වැඩිදුර තොරතුරු ලබා දෙනු ඇත. මෙම කණ්ඩායම ක්රියා කරන ආකාරය පිළිබඳ තත්ත්වය ලබා දීමට එය පාරිභෝගික කණ්ඩායම් API භාවිතා කරයි. OK සහ Failed වලට අමතරව, අනතුරු ඇඟවීමක් ඇති අතර, ඔබේ පාරිභෝගිකයින්ට නිෂ්පාදන වේගය සමඟ සාර්ථකව කටයුතු කළ නොහැකි බව ඔබට සොයා ගත හැකිය - ලියා ඇති දේ සෝදුපත් කියවීමට ඔවුන්ට කාලය නැත. පද්ධතිය තරමක් බුද්ධිමත් හා භාවිතා කිරීමට පහසුය.
API ප්‍රතිචාරය පෙනෙන්නේ මෙයයි. මෙන්න සමූහ bob-live-fifa, partition refund.update.v1, තත්ත්වය OK, lag 0 - අවසාන අවසාන ඕෆ්සෙට් එක සහ එවැනි.
අධීක්ෂණය SLA හි යාවත්කාලීන කරන ලදි (හිරවී ඇත) මම දැනටමත් සඳහන් කළා. උදාහරණයක් ලෙස, නිෂ්පාදිතය ආපසු පැමිණීමට සූදානම් බව තත්ත්වයට වෙනස් වී ඇත. අපි ක්‍රෝන් ස්ථාපනය කරමු, එයින් කියැවෙන්නේ මිනිත්තු 5 කින් මෙම වස්තුව ආපසු ගෙවීමට ගොස් නොමැති නම් (අපි ඉතා ඉක්මනින් ගෙවීම් පද්ධති හරහා මුදල් ආපසු ලබා දෙමු), එවිට යමක් නියත වශයෙන්ම වැරදී ඇති අතර මෙය අනිවාර්යයෙන්ම සහාය සඳහා වන අවස්ථාවකි. එමනිසා, අපි සරලවම එවැනි දේ කියවන ක්‍රෝන් ගනිමු, ඒවා 0 ට වඩා වැඩි නම්, එය අනතුරු ඇඟවීමක් යවයි.
සාරාංශගත කිරීම සඳහා, සිදුවීම් භාවිතා කිරීම පහසු වේ:
- පද්ධති කිහිපයක් සඳහා තොරතුරු අවශ්ය වේ;
- සැකසීමේ ප්රතිඵලය වැදගත් නොවේ;
- සිදුවීම් කිහිපයක් හෝ කුඩා සිදුවීම් තිබේ.
ලිපියෙහි ඉතා නිශ්චිත මාතෘකාවක් ඇති බව පෙනේ - කෆ්කා හි අසමමුහුර්ත API, නමුත් ඒ සම්බන්ධයෙන් මම එකවර බොහෝ දේ නිර්දේශ කිරීමට කැමතියි.
පළමුව, ඊළඟට අපි නොවැම්බර් දක්වා බලා සිටිය යුතුය; අප්රේල් මාසයේදී ශාන්ත පීටර්ස්බර්ග් අනුවාදයක් ඇත, ජුනි මාසයේදී අපි නොවොසිබිර්ස්ක්හි අධික බර ගැන කතා කරමු.
දෙවනුව, වාර්තාවේ කතුවරයා වන සර්ජි සයිකා දැනුම කළමනාකරණය පිළිබඳ අපගේ නව සමුළුවේ වැඩසටහන් කමිටුවේ සාමාජිකයෙකි. . සම්මන්ත්‍රණය එක් දිනක් වන අතර එය අප්රේල් 26 වන දින සිදුවනු ඇත, නමුත් එහි වැඩසටහන ඉතා තීව්‍ර වේ.
තවද එය මැයි මාසයේදී වනු ඇත и (DevOpsConf ඇතුළුව) - ඔබට එහි ඔබේ මාතෘකාව යෝජනා කිරීමට, ඔබේ අත්දැකීම් ගැන කතා කිරීමට සහ ඔබේ පිරවූ කේතු ගැන පැමිණිලි කිරීමටද හැකිය.
මූලාශ්රය: www.habr.com