క్రమబద్ధీకరించబడిన ప్రక్రియ మరియు డజన్ల కొద్దీ ఇంటర్‌కనెక్టడ్ సేవలతో లామోడా వంటి పెద్ద కంపెనీ దాని విధానాన్ని గణనీయంగా మార్చడానికి ఏది బలవంతం చేస్తుంది? ప్రేరణ పూర్తిగా భిన్నంగా ఉంటుంది: శాసనకర్త నుండి అన్ని ప్రోగ్రామర్లలో అంతర్లీనంగా ప్రయోగాలు చేయాలనే కోరిక వరకు.
కానీ మీరు అదనపు ప్రయోజనాలను లెక్కించలేరని దీని అర్థం కాదు. మీరు కాఫ్కాలో ఈవెంట్‌ల ఆధారిత APIని అమలు చేస్తే మీరు ఖచ్చితంగా ఏమి గెలవగలరో సెర్గీ జైకా మీకు తెలియజేస్తుంది () పెద్ద షాట్లు మరియు ఆసక్తికరమైన ఆవిష్కరణల గురించి కూడా ఖచ్చితంగా చర్చ ఉంటుంది - అవి లేకుండా ప్రయోగం చేయలేము.
నిరాకరణ: ఈ కథనం నవంబర్ 2018లో HighLoad++లో సెర్గీ నిర్వహించిన మీట్‌అప్‌లోని విషయాలపై ఆధారపడింది. కాఫ్కాతో కలిసి పనిచేసిన లమోడా యొక్క ప్రత్యక్ష అనుభవం షెడ్యూల్‌లోని ఇతర నివేదికల కంటే తక్కువ కాకుండా శ్రోతలను ఆకర్షించింది. మీరు ఇలాంటి ఆలోచనలు గల వ్యక్తులను కనుగొనవచ్చు మరియు ఎల్లప్పుడూ ఉండాలనే దానికి ఇది ఒక అద్భుతమైన ఉదాహరణ అని మేము భావిస్తున్నాము మరియు HighLoad++ నిర్వాహకులు దీనికి అనుకూలమైన వాతావరణాన్ని సృష్టించడానికి ప్రయత్నిస్తూనే ఉంటారు.
ప్రక్రియ గురించి
Lamoda అనేది ఒక పెద్ద ఇ-కామర్స్ ప్లాట్‌ఫారమ్, దాని స్వంత సంప్రదింపు కేంద్రం, డెలివరీ సేవ (మరియు అనేక అనుబంధ సంస్థలు), ఫోటో స్టూడియో, భారీ గిడ్డంగి మరియు ఇవన్నీ దాని స్వంత సాఫ్ట్‌వేర్‌పై నడుస్తాయి. డజన్ల కొద్దీ చెల్లింపు పద్ధతులు ఉన్నాయి, b2b భాగస్వాములు ఈ సేవలలో కొన్ని లేదా అన్నింటినీ ఉపయోగించుకోవచ్చు మరియు వారి ఉత్పత్తులపై తాజా సమాచారాన్ని తెలుసుకోవాలనుకుంటున్నారు. అదనంగా, Lamoda రష్యన్ ఫెడరేషన్ కాకుండా మూడు దేశాలలో పనిచేస్తుంది మరియు అక్కడ ప్రతిదీ కొద్దిగా భిన్నంగా ఉంటుంది. మొత్తంగా, కొత్త ఆర్డర్‌ను కాన్ఫిగర్ చేయడానికి బహుశా వంద కంటే ఎక్కువ మార్గాలు ఉన్నాయి, ఇది దాని స్వంత మార్గంలో ప్రాసెస్ చేయబడాలి. ఇవన్నీ కొన్నిసార్లు అస్పష్టమైన మార్గాల్లో కమ్యూనికేట్ చేసే డజన్ల కొద్దీ సేవల సహాయంతో పని చేస్తాయి. ఆర్డర్ స్థితిగతులపై ప్రధాన బాధ్యత వహించే కేంద్ర వ్యవస్థ కూడా ఉంది. మేము ఆమెను BOB అని పిలుస్తాము, నేను ఆమెతో పని చేస్తున్నాను.
ఈవెంట్‌ల ఆధారిత APIతో వాపసు సాధనం
ఈవెంట్స్-డ్రైవెన్ అనే పదం చాలా హ్యాక్‌నీడ్; కొంచెం ముందుకు దీని అర్థం ఏమిటో మేము మరింత వివరంగా నిర్వచించాము. నేను కాఫ్కాలో ఈవెంట్‌ల ఆధారిత API విధానాన్ని ప్రయత్నించాలని నిర్ణయించుకున్న సందర్భంతో ప్రారంభిస్తాను.
ఏదైనా స్టోర్‌లో, కస్టమర్‌లు చెల్లించే ఆర్డర్‌లతో పాటు, కస్టమర్‌కు ఉత్పత్తి సరిపోనందున స్టోర్ డబ్బును తిరిగి ఇవ్వాల్సిన సందర్భాలు ఉన్నాయి. ఇది చాలా చిన్న ప్రక్రియ: అవసరమైతే మేము సమాచారాన్ని స్పష్టం చేస్తాము మరియు డబ్బును బదిలీ చేస్తాము.
కానీ చట్టంలో మార్పుల కారణంగా తిరిగి రావడం మరింత క్లిష్టంగా మారింది మరియు మేము దాని కోసం ప్రత్యేక మైక్రోసర్వీస్‌ను అమలు చేయాల్సి వచ్చింది.
మా ప్రేరణ:
- చట్టం FZ-54 - సంక్షిప్తంగా, చట్టం ప్రకారం ప్రతి ద్రవ్య లావాదేవీ గురించి పన్ను కార్యాలయానికి నివేదించడం అవసరం, అది రిటర్న్ లేదా రసీదు కావచ్చు, కొన్ని నిమిషాల వ్యవధిలో చాలా తక్కువ SLA లోపల. మేము, ఇ-కామర్స్ కంపెనీగా, చాలా కార్యకలాపాలను నిర్వహిస్తాము. సాంకేతికంగా, దీని అర్థం కొత్త బాధ్యత (అందువలన కొత్త సేవ) మరియు ప్రమేయం ఉన్న అన్ని సిస్టమ్‌లలో మెరుగుదలలు.
- BOB విభజన పెద్ద సంఖ్యలో నాన్-కోర్ బాధ్యతల నుండి BOBని విముక్తి చేయడానికి మరియు దాని మొత్తం సంక్లిష్టతను తగ్గించడానికి కంపెనీ యొక్క అంతర్గత ప్రాజెక్ట్.
ఈ రేఖాచిత్రం ప్రధాన లామోడా వ్యవస్థలను చూపుతుంది. ఇప్పుడు వాటిలో చాలా ఎక్కువ తగ్గిపోతున్న ఏకశిలా చుట్టూ 5-10 మైక్రోసర్వీస్‌ల సమూహం. అవి నెమ్మదిగా పెరుగుతున్నాయి, కానీ మేము వాటిని చిన్నవిగా చేయడానికి ప్రయత్నిస్తున్నాము, ఎందుకంటే మధ్యలో ఎంచుకున్న భాగాన్ని మోహరించడం భయానకంగా ఉంది - మేము దానిని పడకుండా అనుమతించలేము. మేము అన్ని ఎక్స్ఛేంజీలను (బాణాలు) రిజర్వ్ చేయవలసి వస్తుంది మరియు వాటిలో ఏవైనా అందుబాటులో ఉండకపోవచ్చు అనే వాస్తవాన్ని పరిగణనలోకి తీసుకుంటాము.
BOBలో చాలా ఎక్స్ఛేంజీలు ఉన్నాయి: చెల్లింపు వ్యవస్థలు, డెలివరీ సిస్టమ్‌లు, నోటిఫికేషన్ సిస్టమ్‌లు మొదలైనవి.
సాంకేతికంగా BOB:
- ~150k లైన్ల కోడ్ + ~100k లైన్ల పరీక్షలు;
- php7.2 + Zend 1 & Symfony భాగాలు 3;
- >100 APIలు & ~50 అవుట్‌బౌండ్ ఇంటిగ్రేషన్‌లు;
- వారి స్వంత వ్యాపార లాజిక్‌తో 4 దేశాలు.
BOBని అమలు చేయడం ఖరీదైనది మరియు బాధాకరమైనది, ఇది పరిష్కరిస్తున్న కోడ్ మరియు సమస్యలను ఎవరూ వారి తలపై ఉంచలేరు. సాధారణంగా, దీన్ని సరళీకృతం చేయడానికి చాలా కారణాలు ఉన్నాయి.
రిటర్న్ ప్రాసెస్
ప్రారంభంలో, రెండు వ్యవస్థలు ప్రక్రియలో పాల్గొంటాయి: BOB మరియు చెల్లింపు. ఇప్పుడు మరో రెండు కనిపిస్తున్నాయి:
- ఫిస్కలైజేషన్ సర్వీస్, ఇది ఫిస్కలైజేషన్ మరియు బాహ్య సేవలతో కమ్యూనికేషన్‌కు సంబంధించిన సమస్యలను చూసుకుంటుంది.
- రీఫండ్ టూల్, ఇది BOBని పెంచకుండా కొత్త ఎక్స్ఛేంజీలను కలిగి ఉంటుంది.
ఇప్పుడు ప్రక్రియ ఇలా కనిపిస్తుంది:
- BOB వాపసు కోసం అభ్యర్థనను అందుకుంటుంది.
- BOB ఈ రీఫండ్ టూల్ గురించి మాట్లాడుతుంది.
- వాపసు సాధనం చెల్లింపుకు చెబుతుంది: "డబ్బు తిరిగి ఇవ్వండి."
- చెల్లింపు డబ్బును తిరిగి ఇస్తుంది.
- రీఫండ్ టూల్ మరియు BOB ఒకదానితో ఒకటి స్టేటస్‌లను సింక్రొనైజ్ చేస్తాయి, ఎందుకంటే ప్రస్తుతానికి అవి రెండూ అవసరం. BOBకి UI, అకౌంటింగ్ నివేదికలు మరియు సాధారణంగా చాలా సులభంగా బదిలీ చేయలేని డేటా ఉన్నందున, రీఫండ్ టూల్‌కు పూర్తిగా మారడానికి మేము ఇంకా సిద్ధంగా లేము. మీరు రెండు కుర్చీలపై కూర్చోవాలి.
- ఫిస్కలైజేషన్ కోసం అభ్యర్థన తొలగిపోతుంది.
ఫలితంగా, మేము కాఫ్కాలో ఒక రకమైన ఈవెంట్ బస్సును తయారు చేసాము - ఈవెంట్-బస్సు, దానిలో ప్రతిదీ ప్రారంభించబడింది. హుర్రే, ఇప్పుడు మనకు ఒక వైఫల్యం (వ్యంగ్యం) ఉంది.
లాభాలు మరియు నష్టాలు చాలా స్పష్టంగా ఉన్నాయి. మేము బస్సును తయారు చేసాము, అంటే ఇప్పుడు అన్ని సేవలు దానిపై ఆధారపడి ఉంటాయి. ఇది డిజైన్‌ను సులభతరం చేస్తుంది, కానీ సిస్టమ్‌లో వైఫల్యం యొక్క ఒకే పాయింట్‌ను పరిచయం చేస్తుంది. కాఫ్కా క్రాష్ అవుతుంది, ప్రక్రియ ఆగిపోతుంది.
ఈవెంట్‌ల ఆధారిత API అంటే ఏమిటి
ఈ ప్రశ్నకు మంచి సమాధానం మార్టిన్ ఫౌలర్ (GOTO 2017) నివేదికలో ఉంది .
క్లుప్తంగా మేము ఏమి చేసాము:
- ద్వారా అన్ని అసమకాలిక మార్పిడిని మూసివేయండి ఈవెంట్స్ నిల్వ. నెట్‌వర్క్‌లో స్థితి మార్పు గురించి ఆసక్తి ఉన్న ప్రతి వినియోగదారునికి తెలియజేయడానికి బదులుగా, మేము కేంద్రీకృత నిల్వకు స్థితి మార్పు గురించి ఈవెంట్‌ను వ్రాస్తాము మరియు అంశంపై ఆసక్తి ఉన్న వినియోగదారులు అక్కడ కనిపించే ప్రతిదాన్ని చదువుతారు.
- ఈ సందర్భంలో ఈవెంట్ నోటిఫికేషన్ (ప్రకటనలను) ఎక్కడో ఏదో మార్పు వచ్చిందని. ఉదాహరణకు, ఆర్డర్ స్థితి మార్చబడింది. నోటిఫికేషన్‌లో చేర్చని స్థితి మార్పుతో పాటు కొంత డేటాపై ఆసక్తి ఉన్న వినియోగదారు దాని స్థితిని స్వయంగా తెలుసుకోవచ్చు.
- గరిష్ట ఎంపిక పూర్తి స్థాయి ఈవెంట్ సోర్సింగ్, రాష్ట్ర బదిలీ, ఏ ఈవెంట్‌లో ప్రాసెసింగ్‌కు అవసరమైన మొత్తం సమాచారం ఉంటుంది: ఇది ఎక్కడ నుండి వచ్చింది మరియు ఏ స్థితికి వెళ్లింది, డేటా సరిగ్గా ఎలా మార్చబడింది, మొదలైనవి. మీరు నిల్వ చేయగల సాధ్యత మరియు సమాచారం మొత్తం మాత్రమే ప్రశ్న.
రీఫండ్ టూల్ ప్రారంభించడంలో భాగంగా, మేము మూడవ ఎంపికను ఉపయోగించాము. వివరణాత్మక సమాచారాన్ని సంగ్రహించాల్సిన అవసరం లేనందున ఈ సరళీకృత ఈవెంట్ ప్రాసెసింగ్, అలాగే ప్రతి కొత్త ఈవెంట్ వినియోగదారుల నుండి అభ్యర్థనలను పొందడంపై స్పష్టతనిచ్చే దృష్టాంతాన్ని తొలగించింది.
వాపసు సాధనం సేవ లోడ్ చేయబడలేదు, కాబట్టి కాఫ్కాలో అవసరం కంటే పెన్ను రుచి ఎక్కువ. వాపసు సేవ అధిక-లోడ్ ప్రాజెక్ట్‌గా మారితే, వ్యాపారం సంతోషంగా ఉంటుందని నేను అనుకోను.
అసమకాలిక మార్పిడి అలాగే
అసమకాలిక మార్పిడి కోసం, PHP విభాగం సాధారణంగా RabbitMQని ఉపయోగిస్తుంది. మేము అభ్యర్థన కోసం డేటాను సేకరించాము, దానిని క్యూలో ఉంచాము మరియు అదే సేవ యొక్క వినియోగదారు దానిని చదివి పంపారు (లేదా పంపలేదు). API కోసం, Lamoda చురుకుగా స్వాగర్‌ని ఉపయోగిస్తుంది. మేము APIని డిజైన్ చేస్తాము, దానిని స్వాగర్‌లో వివరిస్తాము మరియు క్లయింట్ మరియు సర్వర్ కోడ్‌ని రూపొందిస్తాము. మేము కొంచెం మెరుగుపరచబడిన JSON RPC 2.0ని కూడా ఉపయోగిస్తాము.
కొన్ని ప్రదేశాలలో ESB బస్సులు ఉపయోగించబడతాయి, కొన్ని ActiveMQలో నివసిస్తాయి, కానీ, సాధారణంగా, RabbitMQ - ప్రమాణం.
Async మార్పిడి TO BE
ఈవెంట్స్-బస్సు ద్వారా మార్పిడిని రూపకల్పన చేసేటప్పుడు, ఒక సారూప్యతను గుర్తించవచ్చు. మేము ఈవెంట్ నిర్మాణ వివరణల ద్వారా భవిష్యత్ డేటా మార్పిడిని అదేవిధంగా వివరిస్తాము. yaml ఫార్మాట్, కోడ్ జనరేషన్ మనమే చేయాల్సి ఉంటుంది, జెనరేటర్ స్పెసిఫికేషన్ ప్రకారం DTOలను సృష్టిస్తుంది మరియు క్లయింట్లు మరియు సర్వర్‌లకు వారితో పని చేయడానికి నేర్పుతుంది. జనరేషన్ రెండు భాషల్లోకి వెళ్తుంది - గోలాంగ్ మరియు php. ఇది లైబ్రరీలను స్థిరంగా ఉంచడంలో సహాయపడుతుంది. జనరేటర్ గోలాంగ్‌లో వ్రాయబడింది, అందుకే దీనికి గోగి అనే పేరు వచ్చింది.
కాఫ్కాలో ఈవెంట్-సోర్సింగ్ అనేది ఒక సాధారణ విషయం. కాఫ్కా సంగమం యొక్క ప్రధాన సంస్థ వెర్షన్ నుండి ఒక పరిష్కారం ఉంది , మా డొమైన్ సోదరులు Zalando నుండి ఒక పరిష్కారం. మా వనిల్లా కాఫ్కాతో ప్రారంభించడానికి ప్రేరణ - దీనర్థం, మేము దానిని ప్రతిచోటా ఉపయోగించాలా వద్దా అని చివరకు నిర్ణయించే వరకు పరిష్కారాన్ని ఉచితంగా వదిలివేయడం మరియు యుక్తి మరియు మెరుగుదలల కోసం మనల్ని మనం వదిలివేస్తాము: మాకు మద్దతు కావాలి JSON RPC 2.0, రెండు భాషలకు జనరేటర్లు మరియు ఇంకా ఏమి చూద్దాం.
ఇంత సంతోషకరమైన సందర్భంలో కూడా, ఇంచుమించు ఇదే విధమైన పరిష్కారాన్ని తయారుచేసిన జలాండో అనే వ్యాపారం ఉన్నపుడు, మనం దానిని సమర్థవంతంగా ఉపయోగించుకోలేకపోవడం విడ్డూరం.
ప్రయోగ సమయంలో నిర్మాణ నమూనా క్రింది విధంగా ఉంది: మేము కాఫ్కా నుండి నేరుగా చదువుతాము, కానీ ఈవెంట్స్-బస్సు ద్వారా మాత్రమే వ్రాస్తాము. కాఫ్కాలో చదవడానికి చాలా సిద్ధంగా ఉంది: బ్రోకర్లు, బ్యాలెన్సర్‌లు మరియు ఇది క్షితిజ సమాంతర స్కేలింగ్‌కు ఎక్కువ లేదా తక్కువ సిద్ధంగా ఉంది, నేను దీన్ని ఉంచాలనుకుంటున్నాను. మేము ఒక గేట్‌వే అకా ఈవెంట్స్-బస్ ద్వారా రికార్డింగ్‌ను పూర్తి చేయాలనుకుంటున్నాము మరియు ఎందుకు అని ఇక్కడ ఉంది.
ఈవెంట్స్-బస్సు
లేదా ఈవెంట్ బస్సు. ఇది కేవలం స్థితిలేని http గేట్‌వే, ఇది అనేక ముఖ్యమైన పాత్రలను పోషిస్తుంది:
- ధ్రువీకరణను ఉత్పత్తి చేస్తోంది — ఈవెంట్‌లు మా స్పెసిఫికేషన్‌లకు అనుగుణంగా ఉన్నాయని మేము తనిఖీ చేస్తాము.
- ఈవెంట్ మాస్టర్ సిస్టమ్, అంటే, ఇది ఏ సంఘటనలతో ఏ నిర్మాణాలు చెల్లుబాటు అవుతాయి అనే ప్రశ్నకు సమాధానం ఇచ్చే సంస్థలోని ప్రధాన మరియు ఏకైక వ్యవస్థ. ధృవీకరణ అనేది కంటెంట్‌ను ఖచ్చితంగా పేర్కొనడానికి డేటా రకాలు మరియు enumలను కలిగి ఉంటుంది.
- హాష్ ఫంక్షన్ షార్డింగ్ కోసం - కాఫ్కా సందేశ నిర్మాణం కీ-విలువ మరియు హ్యాష్ ఆఫ్ కీని ఉపయోగించి దానిని ఎక్కడ ఉంచాలో లెక్కించబడుతుంది.
ఎందుకు
మేము క్రమబద్ధమైన ప్రక్రియతో పెద్ద కంపెనీలో పని చేస్తాము. దేనినైనా ఎందుకు మార్చాలి? ఇదొక ప్రయోగం, మరియు మేము అనేక ప్రయోజనాలను పొందాలని ఆశిస్తున్నాము.
1:n+1 మార్పిడి (ఒకటి నుండి చాలా వరకు)
కాఫ్కా కొత్త వినియోగదారులను APIకి కనెక్ట్ చేయడం చాలా సులభం చేస్తుంది.
మీరు ఒకేసారి అనేక సిస్టమ్‌లలో (మరియు కొన్ని కొత్త వాటిలో) తాజాగా ఉంచాల్సిన డైరెక్టరీని కలిగి ఉన్నారని అనుకుందాం. మునుపు, మేము సెట్-APIని అమలు చేసే బండిల్‌ను కనుగొన్నాము మరియు వినియోగదారు చిరునామాల గురించి మాస్టర్ సిస్టమ్‌కు తెలియజేయబడింది. ఇప్పుడు మాస్టర్ సిస్టమ్ అంశానికి నవీకరణలను పంపుతుంది మరియు ఆసక్తి ఉన్న ప్రతి ఒక్కరూ దానిని చదువుతారు. ఒక కొత్త సిస్టమ్ కనిపించింది - మేము దానిని టాపిక్ కోసం సైన్ అప్ చేసాము. అవును, బండిల్ కూడా, కానీ సరళమైనది.
BOB యొక్క భాగం అయిన రీఫండ్-టూల్ విషయంలో, వాటిని కాఫ్కా ద్వారా సమకాలీకరించడం మాకు సౌకర్యంగా ఉంటుంది. చెల్లింపు డబ్బు తిరిగి వచ్చిందని చెప్పారు: BOB, RT దీని గురించి తెలుసుకుంది, వారి స్థితిగతులను మార్చింది, ఫిస్కలైజేషన్ సర్వీస్ దీని గురించి తెలుసుకుని చెక్ జారీ చేసింది.
క్లయింట్‌కు అతని ఆర్డర్/రిటర్న్‌లకు సంబంధించిన వార్తల గురించి తెలియజేసే ఏకీకృత నోటిఫికేషన్‌ల సేవను రూపొందించడానికి మేము ప్లాన్ చేస్తున్నాము. ఇప్పుడు ఈ బాధ్యత వ్యవస్థల మధ్య విస్తరించింది. కాఫ్కా నుండి సంబంధిత సమాచారాన్ని క్యాచ్ చేయడానికి మరియు దానికి ప్రతిస్పందించడానికి (మరియు ఇతర సిస్టమ్‌లలో ఈ నోటిఫికేషన్‌లను నిలిపివేయడానికి) నోటిఫికేషన్‌ల సేవకు మాకు నేర్పిస్తే సరిపోతుంది. కొత్త డైరెక్ట్ ఎక్స్ఛేంజీలు అవసరం లేదు.
డేటా ఆధారిత
సిస్టమ్‌ల మధ్య సమాచారం పారదర్శకంగా మారుతుంది - మీ వద్ద ఎలాంటి “బ్లడీ ఎంటర్‌ప్రైజ్” ఉన్నా మరియు మీ బ్యాక్‌లాగ్ ఎంత బొద్దుగా ఉన్నా. Lamoda డేటా అనలిటిక్స్ డిపార్ట్‌మెంట్‌ను కలిగి ఉంది, ఇది సిస్టమ్‌ల నుండి డేటాను సేకరించి, వ్యాపారం కోసం మరియు తెలివైన సిస్టమ్‌ల కోసం పునర్వినియోగ రూపంలో ఉంచుతుంది. వారికి చాలా డేటాను త్వరగా అందించడానికి మరియు ఆ సమాచారాన్ని తాజాగా ఉంచడానికి కాఫ్కా మిమ్మల్ని అనుమతిస్తుంది.
ప్రతిరూపణ లాగ్
RabbitMQలో వలె మెసేజ్‌లు చదివిన తర్వాత అదృశ్యం కావు. ఈవెంట్ ప్రాసెసింగ్ కోసం తగినంత సమాచారాన్ని కలిగి ఉన్నప్పుడు, మేము ఆబ్జెక్ట్‌కు ఇటీవలి మార్పుల చరిత్రను కలిగి ఉన్నాము మరియు కావాలనుకుంటే, ఈ మార్పులను వర్తింపజేయగల సామర్థ్యాన్ని కలిగి ఉంటాము.
ప్రతిరూపణ లాగ్ యొక్క నిల్వ వ్యవధి ఈ అంశానికి వ్రాసే తీవ్రతపై ఆధారపడి ఉంటుంది; కాఫ్కా మీరు నిల్వ సమయం మరియు డేటా వాల్యూమ్‌పై పరిమితులను సరళంగా సెట్ చేయడానికి అనుమతిస్తుంది. ఇంటెన్సివ్ టాపిక్‌ల కోసం, స్వల్పకాలిక అసమర్థత విషయంలో కూడా సమాచారాన్ని అదృశ్యమయ్యే ముందు చదవడానికి వినియోగదారులందరికీ సమయం ఉండటం ముఖ్యం. దీని కోసం డేటాను నిల్వ చేయడం సాధారణంగా సాధ్యమవుతుంది రోజుల యూనిట్లు, మద్దతు కోసం ఇది చాలా సరిపోతుంది.
తరువాత, కాఫ్కాతో పరిచయం లేని వారి కోసం డాక్యుమెంటేషన్ యొక్క చిన్న రీటెల్లింగ్ (చిత్రం కూడా డాక్యుమెంటేషన్ నుండి)
AMQPకి క్యూలు ఉన్నాయి: మేము వినియోగదారు కోసం క్యూలో సందేశాలను వ్రాస్తాము. సాధారణంగా, ఒక క్యూ ఒకే వ్యాపార లాజిక్‌తో ఒక సిస్టమ్ ద్వారా ప్రాసెస్ చేయబడుతుంది. మీరు అనేక సిస్టమ్‌లకు తెలియజేయాల్సిన అవసరం ఉన్నట్లయితే, మీరు అప్లికేషన్‌ను అనేక క్యూలకు వ్రాయడం లేదా వాటిని క్లోన్ చేసే ఫానౌట్ మెకానిజంతో మార్పిడిని కాన్ఫిగర్ చేయడం నేర్పించవచ్చు.
కాఫ్కాకు ఇదే విధమైన సంగ్రహణ ఉంది విషయం, దీనిలో మీరు సందేశాలను వ్రాస్తారు, కానీ చదివిన తర్వాత అవి కనిపించవు. డిఫాల్ట్‌గా, మీరు కాఫ్కాకు కనెక్ట్ చేసినప్పుడు, మీరు అన్ని సందేశాలను స్వీకరిస్తారు మరియు మీరు ఎక్కడ ఆపారో అక్కడ సేవ్ చేసుకునే అవకాశం ఉంటుంది. అంటే, మీరు క్రమానుగతంగా చదువుతారు, మీరు సందేశాన్ని చదివినట్లుగా గుర్తించలేరు, కానీ మీరు చదవడం కొనసాగించగల idని సేవ్ చేయండి. మీరు సెటిల్ చేసిన Idని ఆఫ్‌సెట్ అంటారు మరియు మెకానిజం కమిట్ ఆఫ్‌సెట్ అవుతుంది.
దీని ప్రకారం, వివిధ తర్కం అమలు చేయవచ్చు. ఉదాహరణకు, మేము వివిధ దేశాల కోసం 4 సందర్భాలలో BOBని కలిగి ఉన్నాము - Lamoda రష్యా, కజాఖ్స్తాన్, ఉక్రెయిన్, బెలారస్లో ఉంది. అవి విడివిడిగా అమలు చేయబడినందున, వాటికి కొద్దిగా భిన్నమైన కాన్ఫిగరేషన్‌లు మరియు వారి స్వంత వ్యాపార లాజిక్ ఉన్నాయి. ఇది ఏ దేశాన్ని సూచిస్తుందో మేము సందేశంలో సూచిస్తాము. ప్రతి దేశంలోని ప్రతి BOB వినియోగదారు వేర్వేరు గ్రూప్‌ఐడితో చదువుతారు మరియు సందేశం వారికి వర్తించకపోతే, వారు దానిని దాటవేస్తారు, అనగా. వెంటనే ఆఫ్‌సెట్ +1ని నిర్దేశిస్తుంది. అదే టాపిక్ మా చెల్లింపు సేవ ద్వారా చదివితే, అది ఒక ప్రత్యేక సమూహంతో చదివితే, ఆఫ్‌సెట్‌లు కలుస్తాయి.
ఈవెంట్ అవసరాలు:
- డేటా సంపూర్ణత. ఈవెంట్‌లో తగినంత డేటా ఉండాలని నేను కోరుకుంటున్నాను, తద్వారా అది ప్రాసెస్ చేయబడుతుంది.
- సమగ్రత. ఈవెంట్ స్థిరంగా ఉందని మరియు దానిని ప్రాసెస్ చేయగలదని ధృవీకరణను మేము ఈవెంట్స్-బస్‌కి అప్పగిస్తాము.
- క్రమం ముఖ్యం. తిరిగి వచ్చిన సందర్భంలో, మేము చరిత్రతో పని చేయవలసి వస్తుంది. నోటిఫికేషన్‌లతో, ఆర్డర్ ముఖ్యం కాదు, అవి సజాతీయ నోటిఫికేషన్‌లు అయితే, ఏ ఆర్డర్ మొదట వచ్చినా ఇమెయిల్ అదే విధంగా ఉంటుంది. వాపసు విషయంలో, స్పష్టమైన ప్రక్రియ ఉంది; మేము ఆర్డర్‌ను మార్చినట్లయితే, మినహాయింపులు తలెత్తుతాయి, వాపసు సృష్టించబడదు లేదా ప్రాసెస్ చేయబడదు - మేము వేరే స్థితిలో ఉంటాము.
- స్థిరత్వం. మాకు స్టోర్ ఉంది మరియు ఇప్పుడు మేము APIకి బదులుగా ఈవెంట్‌లను సృష్టిస్తాము. మా సేవలకు కొత్త ఈవెంట్‌లు మరియు ఇప్పటికే ఉన్న వాటికి మార్పుల గురించి సమాచారాన్ని త్వరగా మరియు చౌకగా ప్రసారం చేయడానికి మాకు ఒక మార్గం అవసరం. ఇది ఒక ప్రత్యేక git రిపోజిటరీ మరియు కోడ్ జనరేటర్లలో ఒక సాధారణ వివరణ ద్వారా సాధించబడుతుంది. అందువల్ల, వివిధ సేవలలో క్లయింట్లు మరియు సర్వర్లు సమన్వయంతో ఉంటాయి.
లమోడాలో కాఫ్కా
మాకు మూడు కాఫ్కా ఇన్‌స్టాలేషన్‌లు ఉన్నాయి:
- లాగ్‌లు;
- R&D;
- ఈవెంట్స్-బస్సు.
ఈ రోజు మనం చివరి పాయింట్ గురించి మాత్రమే మాట్లాడుతున్నాము. ఈవెంట్స్-బస్సులో, మాకు చాలా పెద్ద ఇన్‌స్టాలేషన్‌లు లేవు - 3 బ్రోకర్లు (సర్వర్లు) మరియు 27 టాపిక్‌లు మాత్రమే. నియమం ప్రకారం, ఒక అంశం ఒక ప్రక్రియ. కానీ ఇది ఒక సూక్ష్మమైన అంశం, మరియు మేము ఇప్పుడు దానిని తాకుతాము.
పైన rps గ్రాఫ్ ఉంది. వాపసు ప్రక్రియ మణి రేఖతో గుర్తించబడింది (అవును, X అక్షంలో ఉన్నది), మరియు పింక్ లైన్ అనేది కంటెంట్ అప్‌డేట్ ప్రక్రియ.
Lamoda కేటలాగ్ మిలియన్ల కొద్దీ ఉత్పత్తులను కలిగి ఉంది మరియు డేటా అన్ని సమయాలలో నవీకరించబడుతుంది. కొన్ని సేకరణలు ఫ్యాషన్ నుండి బయటపడతాయి, వాటి స్థానంలో కొత్తవి విడుదల చేయబడతాయి మరియు కొత్త నమూనాలు నిరంతరం కేటలాగ్‌లో కనిపిస్తాయి. రేపు మా కస్టమర్‌లకు ఏది ఆసక్తికరంగా ఉంటుందో అంచనా వేయడానికి మేము ప్రయత్నిస్తాము, కాబట్టి మేము నిరంతరం కొత్త వస్తువులను కొనుగోలు చేస్తాము, వాటిని ఫోటోగ్రాఫ్ చేయండి మరియు డిస్ప్లే కేస్‌ను అప్‌డేట్ చేస్తాము.
పింక్ శిఖరాలు ఉత్పత్తి నవీకరణలు, అంటే ఉత్పత్తులలో మార్పులు. అబ్బాయిలు చిత్రాలు తీయడం, చిత్రాలు తీయడం, ఆపై మళ్లీ చూడగలరు! - ఈవెంట్‌ల ప్యాక్ లోడ్ చేయబడింది.
Lamoda ఈవెంట్స్ కేసులను ఉపయోగిస్తాయి
కింది కార్యకలాపాల కోసం మేము నిర్మించిన నిర్మాణాన్ని ఉపయోగిస్తాము:
- తిరిగి స్థితి ట్రాకింగ్: ప్రమేయం ఉన్న అన్ని సిస్టమ్‌ల నుండి కాల్-టు-యాక్షన్ మరియు స్టేటస్ ట్రాకింగ్. చెల్లింపు, హోదాలు, ఫిస్కలైజేషన్, నోటిఫికేషన్‌లు. ఇక్కడ మేము విధానాన్ని పరీక్షించాము, సాధనాలను తయారు చేసాము, అన్ని బగ్‌లను సేకరించాము, డాక్యుమెంటేషన్ వ్రాసాము మరియు దానిని ఎలా ఉపయోగించాలో మా సహోద్యోగులకు చెప్పాము.
- ఉత్పత్తి కార్డ్‌లను నవీకరిస్తోంది: కాన్ఫిగరేషన్, మెటా-డేటా, లక్షణాలు. ఒక సిస్టమ్ రీడ్ చేస్తుంది (ఇది డిస్ప్లే చేస్తుంది), మరియు అనేక వ్రాస్తుంది.
- ఇమెయిల్, పుష్ మరియు SMS: ఆర్డర్ సేకరించబడింది, ఆర్డర్ వచ్చింది, రిటర్న్ అంగీకరించబడింది, మొదలైనవి, వాటిలో చాలా ఉన్నాయి.
- స్టాక్, గిడ్డంగి పునరుద్ధరణ - వస్తువుల పరిమాణాత్మక నవీకరణ, కేవలం సంఖ్యలు: గిడ్డంగికి చేరుకోవడం, తిరిగి రావడం. వస్తువులను రిజర్వ్ చేయడంతో అనుబంధించబడిన అన్ని సిస్టమ్‌లు అత్యంత ప్రస్తుత డేటాతో పనిచేయడం అవసరం. ప్రస్తుతం, స్టాక్ అప్‌డేట్ సిస్టమ్ చాలా క్లిష్టంగా ఉంది; కాఫ్కా దానిని సులభతరం చేస్తుంది.
- డేటా విశ్లేషణ (R&D విభాగం), ML సాధనాలు, విశ్లేషణలు, గణాంకాలు. సమాచారం పారదర్శకంగా ఉండాలని మేము కోరుకుంటున్నాము - కాఫ్కా దీనికి బాగా సరిపోతుంది.
గత ఆరు నెలలుగా సంభవించిన పెద్ద గడ్డలు మరియు ఆసక్తికరమైన ఆవిష్కరణల గురించి ఇప్పుడు మరింత ఆసక్తికరమైన భాగం.
డిజైన్ సమస్యలు
మనం ఒక కొత్త పని చేయాలనుకుంటున్నాము అనుకుందాం - ఉదాహరణకు, మొత్తం డెలివరీ ప్రక్రియను కాఫ్కాకు బదిలీ చేయండి. ఇప్పుడు ప్రక్రియలో కొంత భాగం BOBలో ఆర్డర్ ప్రాసెసింగ్‌లో అమలు చేయబడింది. డెలివరీ సేవకు ఆర్డర్‌ను బదిలీ చేయడం, ఇంటర్మీడియట్ గిడ్డంగికి తరలించడం మరియు మొదలైన వాటి వెనుక స్థితి నమూనా ఉంది. మొత్తం ఏకశిలా ఉంది, రెండు కూడా ఉన్నాయి, ఇంకా డెలివరీకి అంకితమైన APIల సమూహం. డెలివరీ గురించి వారికి చాలా ఎక్కువ తెలుసు.
ఇవి సారూప్య ప్రాంతాలుగా కనిపిస్తున్నాయి, అయితే BOBలోని ఆర్డర్ ప్రాసెసింగ్ మరియు షిప్పింగ్ సిస్టమ్ వేర్వేరు హోదాలను కలిగి ఉన్నాయి. ఉదాహరణకు, కొన్ని కొరియర్ సేవలు ఇంటర్మీడియట్ స్థితిగతులను పంపవు, కానీ చివరివి మాత్రమే: “బట్వాడా” లేదా “కోల్పోయినవి”. ఇతరులు, దీనికి విరుద్ధంగా, వస్తువుల కదలిక గురించి చాలా వివరంగా నివేదిస్తారు. ప్రతి ఒక్కరికి వారి స్వంత ధ్రువీకరణ నియమాలు ఉన్నాయి: కొంతమందికి, ఇమెయిల్ చెల్లుబాటు అవుతుంది, అంటే ఇది ప్రాసెస్ చేయబడుతుంది; ఇతరులకు ఇది చెల్లదు, కానీ సంప్రదింపు కోసం ఫోన్ నంబర్ ఉన్నందున ఆర్డర్ ఇప్పటికీ ప్రాసెస్ చేయబడుతుంది మరియు అలాంటి ఆర్డర్ అస్సలు ప్రాసెస్ చేయబడదని ఎవరైనా చెబుతారు.
డేటా స్ట్రీమ్
కాఫ్కా విషయంలో, డేటా ప్రవాహాన్ని నిర్వహించడం అనే ప్రశ్న తలెత్తుతుంది. ఈ పనిలో అనేక పాయింట్ల ఆధారంగా వ్యూహాన్ని ఎంచుకోవడం ఉంటుంది; వాటన్నింటిని పరిశీలిద్దాం.
ఒక టాపిక్‌లోనా లేక వేరేవాటిలోనా?
మాకు ఈవెంట్ స్పెసిఫికేషన్ ఉంది. BOBలో మేము అటువంటి మరియు అటువంటి ఆర్డర్ డెలివరీ చేయబడాలని వ్రాస్తాము మరియు సూచిస్తాము: ఆర్డర్ నంబర్, దాని కూర్పు, కొన్ని SKUలు మరియు బార్ కోడ్‌లు మొదలైనవి. వస్తువులు గిడ్డంగికి వచ్చినప్పుడు, డెలివరీ స్థితి, సమయ స్టాంపులు మరియు అవసరమైన ప్రతిదాన్ని స్వీకరించగలదు. కానీ మేము BOBలో ఈ డేటాపై నవీకరణలను స్వీకరించాలనుకుంటున్నాము. మేము డెలివరీ నుండి డేటాను స్వీకరించడానికి రివర్స్ ప్రక్రియను కలిగి ఉన్నాము. ఇదే ఘటనా? లేదా ఇది దాని స్వంత అంశానికి అర్హమైన ప్రత్యేక మార్పిడినా?
చాలా మటుకు, అవి చాలా సారూప్యంగా ఉంటాయి మరియు ఒక అంశాన్ని రూపొందించాలనే టెంప్టేషన్ నిరాధారమైనది కాదు, ఎందుకంటే ప్రత్యేక అంశం అంటే ప్రత్యేక వినియోగదారులు, ప్రత్యేక కాన్ఫిగరేషన్‌లు, వీటన్నింటి యొక్క ప్రత్యేక తరం. కానీ వాస్తవం కాదు.
కొత్త ఫీల్డ్ లేదా కొత్త ఈవెంట్?
కానీ మీరు అదే ఈవెంట్‌లను ఉపయోగిస్తే, మరొక సమస్య తలెత్తుతుంది. ఉదాహరణకు, అన్ని డెలివరీ సిస్టమ్‌లు BOB ఉత్పత్తి చేయగల DTO రకాన్ని రూపొందించలేవు. మేము వారికి ఐడిని పంపుతాము, కానీ వారు దానిని సేవ్ చేయరు ఎందుకంటే వారికి ఇది అవసరం లేదు మరియు ఈవెంట్-బస్ ప్రక్రియను ప్రారంభించే కోణం నుండి, ఈ ఫీల్డ్ అవసరం.
ఈవెంట్-బస్సు కోసం ఈ ఫీల్డ్ అవసరమని మేము నియమాన్ని ప్రవేశపెడితే, మేము BOB లేదా ప్రారంభ ఈవెంట్ హ్యాండ్లర్‌లో అదనపు ధ్రువీకరణ నియమాలను సెట్ చేయవలసి వస్తుంది. ధృవీకరణ సేవ అంతటా వ్యాప్తి చెందడం ప్రారంభమవుతుంది - ఇది చాలా సౌకర్యవంతంగా లేదు.
మరొక సమస్య పెరుగుతున్న అభివృద్ధికి టెంప్టేషన్. ఈవెంట్‌కి ఏదైనా జోడించాల్సిన అవసరం ఉందని, బహుశా, దాని గురించి మనం ఆలోచిస్తే, అది ప్రత్యేక ఈవెంట్ అయి ఉండవచ్చని మాకు చెప్పబడింది. కానీ మా పథకంలో, ఒక ప్రత్యేక సంఘటన ప్రత్యేక అంశం. ఒక ప్రత్యేక అంశం నేను పైన వివరించిన మొత్తం ప్రక్రియ. డెవలపర్ కేవలం JSON స్కీమాకు మరొక ఫీల్డ్‌ని జోడించి, దాన్ని పునరుత్పత్తి చేసేందుకు శోదించబడ్డాడు.
రీఫండ్‌ల విషయంలో, మేము అర్ధ సంవత్సరంలో ఈవెంట్‌ల ఈవెంట్‌కి చేరుకున్నాము. మేము రీఫండ్ అప్‌డేట్ అనే మెటా-ఈవెంట్‌ని కలిగి ఉన్నాము, ఈ అప్‌డేట్ వాస్తవానికి ఏమిటో వివరించే టైప్ ఫీల్డ్‌ని కలిగి ఉంది. దీని కారణంగా, ఈ రకంతో ఈ ఈవెంట్‌ని ఎలా ధృవీకరించాలో మాకు తెలిపిన వాలిడేటర్‌లతో మేము "అద్భుతమైన" స్విచ్‌లను కలిగి ఉన్నాము.
ఈవెంట్ సంస్కరణ
కాఫ్కాలో సందేశాలను ధృవీకరించడానికి మీరు ఉపయోగించవచ్చు , కానీ వెంటనే దానిపై వేయడానికి మరియు సంగమాన్ని ఉపయోగించడం అవసరం. మా విషయంలో, మేము సంస్కరణతో జాగ్రత్తగా ఉండాలి. మోడల్ "ఎడమ" ఉన్నందున ప్రతిరూపణ లాగ్ నుండి సందేశాలను మళ్లీ చదవడం ఎల్లప్పుడూ సాధ్యం కాదు. ప్రాథమికంగా, మోడల్ వెనుకకు అనుకూలంగా ఉండేలా సంస్కరణలను రూపొందించడానికి ఇది మారుతుంది: ఉదాహరణకు, ఫీల్డ్‌ను తాత్కాలికంగా ఐచ్ఛికంగా చేయండి. తేడాలు చాలా బలంగా ఉంటే, మేము కొత్త టాపిక్‌లో రాయడం ప్రారంభిస్తాము మరియు క్లయింట్లు పాతదాన్ని చదవడం పూర్తి చేసినప్పుడు వారిని బదిలీ చేస్తాము.
విభజనల రీడింగ్ ఆర్డర్ హామీ
కాఫ్కాలోని అంశాలు విభజనలుగా విభజించబడ్డాయి. మేము ఎంటిటీలు మరియు ఎక్స్ఛేంజీలను రూపొందిస్తున్నప్పుడు ఇది చాలా ముఖ్యమైనది కాదు, కానీ దానిని ఎలా వినియోగించాలో మరియు స్కేల్ చేయాలో నిర్ణయించేటప్పుడు ఇది చాలా ముఖ్యం.
సాధారణ సందర్భంలో, మీరు కాఫ్కాలో ఒక అంశాన్ని వ్రాస్తారు. డిఫాల్ట్‌గా, ఒక విభజన ఉపయోగించబడుతుంది మరియు ఈ అంశంలోని అన్ని సందేశాలు దానికి వెళ్తాయి. మరియు వినియోగదారు ఈ సందేశాలను వరుసగా చదువుతారు. ఇప్పుడు మనం సిస్టమ్‌ను విస్తరించాల్సిన అవసరం ఉందని చెప్పండి, తద్వారా సందేశాలు ఇద్దరు వేర్వేరు వినియోగదారులచే చదవబడతాయి. ఉదాహరణకు, మీరు SMS పంపుతున్నట్లయితే, మీరు అదనపు విభజనను చేయమని కాఫ్కాకు చెప్పవచ్చు మరియు కాఫ్కా సందేశాలను రెండు భాగాలుగా విభజించడం ప్రారంభిస్తుంది - సగం ఇక్కడ, సగం ఇక్కడ.
కాఫ్కా వాటిని ఎలా విభజిస్తుంది? ప్రతి సందేశానికి ఒక శరీరం (దీనిలో మేము JSONని నిల్వ చేస్తాము) మరియు ఒక కీని కలిగి ఉంటుంది. మీరు ఈ కీకి హాష్ ఫంక్షన్‌ను జోడించవచ్చు, ఇది సందేశం ఏ విభజనలోకి వెళుతుందో నిర్ణయిస్తుంది.
మా వాపసు విషయంలో, ఇది ముఖ్యం, మేము రెండు విభజనలను తీసుకుంటే, సమాంతర వినియోగదారుడు మొదటి ఈవెంట్‌కు ముందు రెండవ ఈవెంట్‌ను ప్రాసెస్ చేసే అవకాశం ఉంది మరియు ఇబ్బంది ఉంటుంది. హాష్ ఫంక్షన్ ఒకే కీతో సందేశాలు ఒకే విభజనలో ముగుస్తుందని నిర్ధారిస్తుంది.
ఈవెంట్‌లు vs ఆదేశాలు
ఇది మేము ఎదుర్కొన్న మరొక సమస్య. ఈవెంట్ అనేది ఒక నిర్దిష్టమైన సంఘటన: మేము ఎక్కడో ఏదో జరిగినట్లు (ఏదో_జరిగింది) చెప్పాము, ఉదాహరణకు, ఒక అంశం రద్దు చేయబడింది లేదా వాపసు జరిగింది. ఎవరైనా ఈ ఈవెంట్‌లను వింటుంటే, “అంశం రద్దు చేయబడింది” ప్రకారం, రీఫండ్ ఎంటిటీ సృష్టించబడుతుంది మరియు సెటప్‌లలో ఎక్కడో ఒకచోట “రీఫండ్ జరిగింది” అని వ్రాయబడుతుంది.
కానీ సాధారణంగా, మీరు ఈవెంట్‌లను రూపొందించినప్పుడు, మీరు వాటిని వ్యర్థంగా వ్రాయకూడదు - ఎవరైనా వాటిని చదువుతారనే దానిపై మీరు ఆధారపడతారు. ఏదైనా_జరిగింది (ఐటెమ్_రద్దు చేయబడింది, రీఫండ్_రీఫండ్ చేయబడింది) కాదు, ఏదైనా_చేయాలి_చేయాలి అని వ్రాయడానికి అధిక టెంప్టేషన్ ఉంది. ఉదాహరణకు, వస్తువు తిరిగి ఇవ్వడానికి సిద్ధంగా ఉంది.
ఒక వైపు, ఈవెంట్ ఎలా ఉపయోగించబడుతుందో సూచిస్తుంది. మరోవైపు, ఇది సాధారణ ఈవెంట్ పేరు వలె చాలా తక్కువగా ఉంటుంది. అంతేకాకుండా, ఇది ఇక్కడ నుండి do_something ఆదేశానికి చాలా దూరంలో లేదు. కానీ ఈ ఈవెంట్‌ను ఎవరైనా చదివారని మీకు ఎలాంటి హామీ లేదు; మరియు మీరు దానిని చదివితే, మీరు దానిని విజయవంతంగా చదివారు; మరియు మీరు దానిని విజయవంతంగా చదివితే, మీరు ఏదో చేసారు మరియు ఏదో విజయవంతమైంది. ఈవెంట్ ఏదైనా_సమథింగ్ అయినప్పుడు, ఫీడ్‌బ్యాక్ అవసరం అవుతుంది మరియు అది సమస్య.
RabbitMQలో అసమకాలిక మార్పిడిలో, మీరు సందేశాన్ని చదివినప్పుడు, httpకి వెళ్లండి, మీకు ప్రతిస్పందన ఉంటుంది - కనీసం సందేశం స్వీకరించబడిందని. మీరు కాఫ్కాకు వ్రాసినప్పుడు, మీరు కాఫ్కాకు వ్రాసిన సందేశం ఉంది, కానీ అది ఎలా ప్రాసెస్ చేయబడిందో మీకు ఏమీ తెలియదు.
కాబట్టి, మా విషయంలో, మేము ప్రతిస్పందన ఈవెంట్‌ను పరిచయం చేసి, పర్యవేక్షణను సెటప్ చేయాలి, తద్వారా చాలా ఈవెంట్‌లు పంపబడితే, అలాంటి సమయం తర్వాత అదే సంఖ్యలో ప్రతిస్పందన ఈవెంట్‌లు వచ్చేలా. ఇది జరగకపోతే, ఏదో తప్పు జరిగినట్లు అనిపిస్తుంది. ఉదాహరణకు, మేము “item_ready_to_refund” ఈవెంట్‌ను పంపినట్లయితే, వాపసు సృష్టించబడుతుందని, క్లయింట్‌కు డబ్బు తిరిగి ఇవ్వబడుతుంది మరియు “Money_refunded” ఈవెంట్ మాకు పంపబడుతుంది. కానీ ఇది ఖచ్చితంగా కాదు, కాబట్టి పర్యవేక్షణ అవసరం.
స్వల్ప
చాలా స్పష్టమైన సమస్య ఉంది: మీరు ఒక అంశం నుండి వరుసగా చదివి, మీకు కొంత చెడ్డ సందేశం ఉంటే, వినియోగదారు పడిపోతారు మరియు మీరు మరింత ముందుకు వెళ్లరు. నీకు అవసరం వినియోగదారులందరినీ ఆపండి, చదవడం కొనసాగించడానికి ఆఫ్‌సెట్‌ను మరింత కమిట్ చేయండి.
మాకు దాని గురించి తెలుసు, మేము దానిని లెక్కించాము, ఇంకా అది జరిగింది. ఈవెంట్‌లు-బస్సు దృష్ట్యా ఈవెంట్ చెల్లుబాటు అయ్యేది, అప్లికేషన్ వాలిడేటర్ దృక్కోణం నుండి ఈవెంట్ చెల్లుబాటు అయ్యేది, కానీ PostgreSQL కోణం నుండి ఇది చెల్లదు, ఎందుకంటే మా ఒక సిస్టమ్‌లో అన్‌సైన్డ్ INTతో MySQL, మరియు కొత్తగా వ్రాసిన సిస్టమ్‌లో కేవలం INTతో PostgreSQL ఉంది. అతని పరిమాణం కొద్దిగా తక్కువగా ఉంది మరియు Id సరిపోలేదు. సింఫోనీ ఒక మినహాయింపుతో మరణించాడు. మేము మినహాయింపును తీసుకున్నాము, ఎందుకంటే మేము దానిపై ఆధారపడ్డాము మరియు ఈ ఆఫ్‌సెట్‌కు కట్టుబడి ఉన్నాము, కానీ సందేశం విఫలమైనందున మేము సమస్య కౌంటర్‌ను పెంచాలనుకుంటున్నాము. ఈ ప్రాజెక్ట్‌లోని కౌంటర్‌లు కూడా డేటాబేస్‌లో ఉన్నాయి మరియు Symfony ఇప్పటికే డేటాబేస్‌తో కమ్యూనికేషన్‌ను మూసివేసింది మరియు రెండవ మినహాయింపు ఆఫ్‌సెట్ చేయడానికి అవకాశం లేకుండా మొత్తం ప్రక్రియను చంపేసింది.
సేవ కొంత సమయం వరకు ఉంది - అదృష్టవశాత్తూ, కాఫ్కాతో ఇది అంత చెడ్డది కాదు, ఎందుకంటే సందేశాలు అలాగే ఉన్నాయి. పని పునరుద్ధరించబడినప్పుడు, మీరు వాటిని చదవడం పూర్తి చేయవచ్చు. ఇది సౌకర్యంగా ఉంది.
కాఫ్కా టూలింగ్ ద్వారా ఏకపక్ష ఆఫ్‌సెట్‌ను సెట్ చేయగల సామర్థ్యాన్ని కలిగి ఉంది. కానీ దీన్ని చేయడానికి, మీరు వినియోగదారులందరినీ ఆపివేయాలి - మా విషయంలో, వినియోగదారులు ఉండని ప్రత్యేక విడుదలను సిద్ధం చేయండి, పునఃప్రయోగాలు. కాఫ్కాలో మీరు టూలింగ్ ద్వారా ఆఫ్‌సెట్‌ను మార్చవచ్చు మరియు సందేశం ద్వారా వెళుతుంది.
మరొక స్వల్పభేదాన్ని - రెప్లికేషన్ లాగ్ vs rdkafka.so - మా ప్రాజెక్ట్ యొక్క ప్రత్యేకతలకు సంబంధించినది. మేము PHPని ఉపయోగిస్తాము మరియు PHPలో, ఒక నియమం వలె, అన్ని లైబ్రరీలు rdkafka.so రిపోజిటరీ ద్వారా కాఫ్కాతో కమ్యూనికేట్ చేస్తాయి, ఆపై ఒక రకమైన రేపర్ ఉంది. బహుశా ఇవి మన వ్యక్తిగత ఇబ్బందులు కావచ్చు, కానీ మనం ఇప్పటికే చదివిన దానిలో కొంత భాగాన్ని తిరిగి చదవడం అంత సులభం కాదని తేలింది. సాధారణంగా, సాఫ్ట్‌వేర్ సమస్యలు ఉన్నాయి.
విభజనలతో పని చేసే ప్రత్యేకతలకు తిరిగి రావడం, ఇది డాక్యుమెంటేషన్‌లో సరిగ్గా వ్రాయబడింది వినియోగదారులు >= టాపిక్ విభజనలు. కానీ నేను దీని గురించి నేను ఇష్టపడే దానికంటే చాలా ఆలస్యంగా తెలుసుకున్నాను. మీరు స్కేల్ మరియు ఇద్దరు వినియోగదారులను కలిగి ఉండాలనుకుంటే, మీకు కనీసం రెండు విభజనలు అవసరం. అంటే, మీరు 20 వేల సందేశాలు సేకరించిన ఒక విభజనను కలిగి ఉంటే మరియు మీరు తాజాగా చేసినట్లయితే, సందేశాల సంఖ్య త్వరలో సమం చేయబడదు. అందువల్ల, ఇద్దరు సమాంతర వినియోగదారులను కలిగి ఉండటానికి, మీరు విభజనలతో వ్యవహరించాలి.
పర్యవేక్షణ
ప్రస్తుతం ఉన్న విధానంలో ఎలాంటి సమస్యలు ఉన్నాయో మనం పర్యవేక్షించే విధానం మరింత స్పష్టంగా ఉంటుందని నేను భావిస్తున్నాను.
ఉదాహరణకు, డేటాబేస్‌లోని ఎన్ని ఉత్పత్తులు ఇటీవల వాటి స్థితిని మార్చుకున్నాయో మేము లెక్కిస్తాము మరియు తదనుగుణంగా, ఈ మార్పుల ఆధారంగా ఈవెంట్‌లు జరిగి ఉండాలి మరియు మేము ఈ నంబర్‌ను మా పర్యవేక్షణ సిస్టమ్‌కు పంపుతాము. కాఫ్కా నుండి మనకు రెండవ సంఖ్య వస్తుంది, వాస్తవానికి ఎన్ని సంఘటనలు నమోదు చేయబడ్డాయి. సహజంగానే, ఈ రెండు సంఖ్యల మధ్య వ్యత్యాసం ఎల్లప్పుడూ సున్నాగా ఉండాలి.
అదనంగా, మీరు నిర్మాత ఎలా పనిచేస్తున్నారు, ఈవెంట్‌లు-బస్సు సందేశాలను స్వీకరించారా మరియు వినియోగదారు ఎలా చేస్తున్నారో మీరు పర్యవేక్షించాలి. ఉదాహరణకు, దిగువ చార్ట్‌లలో, వాపసు సాధనం బాగా పని చేస్తోంది, కానీ BOBకి స్పష్టంగా కొన్ని సమస్యలు ఉన్నాయి (నీలం శిఖరాలు).
నేను ఇప్పటికే వినియోగదారు-సమూహ లాగ్‌ని పేర్కొన్నాను. స్థూలంగా చెప్పాలంటే, ఇది చదవని సందేశాల సంఖ్య. సాధారణంగా, మా వినియోగదారులు త్వరగా పని చేస్తారు, కాబట్టి లాగ్ సాధారణంగా 0, కానీ కొన్నిసార్లు స్వల్పకాలిక శిఖరం ఉండవచ్చు. కాఫ్కా దీన్ని బాక్స్ వెలుపల చేయగలదు, కానీ మీరు నిర్దిష్ట విరామాన్ని సెట్ చేయాలి.
ఒక ప్రాజెక్ట్ ఉంది ఇది మీకు కాఫ్కా గురించి మరింత సమాచారాన్ని అందిస్తుంది. ఈ సమూహం ఎలా పని చేస్తుందో స్థితిని అందించడానికి ఇది వినియోగదారు-సమూహ APIని ఉపయోగిస్తుంది. సరే మరియు విఫలమైన వాటికి అదనంగా, ఒక హెచ్చరిక ఉంది మరియు మీ వినియోగదారులు ఉత్పత్తి వేగాన్ని భరించలేరని మీరు కనుగొనవచ్చు - వ్రాసిన వాటిని సరిదిద్దడానికి వారికి సమయం లేదు. సిస్టమ్ చాలా స్మార్ట్ మరియు ఉపయోగించడానికి సులభమైనది.
API ప్రతిస్పందన ఇలా కనిపిస్తుంది. ఇక్కడ సమూహం bob-live-fifa, విభజన refund.update.v1, స్థితి సరే, లాగ్ 0 - చివరి చివరి ఆఫ్‌సెట్ అలాంటిది.
పర్యవేక్షణ SLA వద్ద_నవీకరించబడింది (చిక్కపోయింది) నేను ఇప్పటికే ప్రస్తావించాను. ఉదాహరణకు, ఉత్పత్తి తిరిగి రావడానికి సిద్ధంగా ఉన్న స్థితికి మార్చబడింది. మేము క్రాన్‌ను ఇన్‌స్టాల్ చేస్తాము, ఇది 5 నిమిషాల్లో ఈ వస్తువు వాపసుకు వెళ్లకపోతే (మేము చెల్లింపు వ్యవస్థల ద్వారా డబ్బును చాలా త్వరగా తిరిగి ఇస్తాము), అప్పుడు ఖచ్చితంగా ఏదో తప్పు జరిగింది మరియు ఇది ఖచ్చితంగా మద్దతు కోసం ఒక సందర్భం. అందువల్ల, మేము కేవలం క్రాన్‌ని తీసుకుంటాము, ఇది అలాంటి విషయాలను చదువుతుంది మరియు అవి 0 కంటే ఎక్కువ ఉంటే, అది హెచ్చరికను పంపుతుంది.
సంగ్రహంగా చెప్పాలంటే, ఈవెంట్‌లను ఉపయోగించడం సౌకర్యవంతంగా ఉంటుంది:
- అనేక వ్యవస్థల ద్వారా సమాచారం అవసరం;
- ప్రాసెసింగ్ ఫలితం ముఖ్యం కాదు;
- కొన్ని సంఘటనలు లేదా చిన్న సంఘటనలు ఉన్నాయి.
వ్యాసం చాలా నిర్దిష్టమైన అంశాన్ని కలిగి ఉన్నట్లు అనిపిస్తుంది - కాఫ్కాపై అసమకాలిక API, కానీ దానికి సంబంధించి నేను ఒకేసారి చాలా విషయాలను సిఫార్సు చేయాలనుకుంటున్నాను.
మొదటి, తదుపరి మేము నవంబర్ వరకు వేచి ఉండాలి; ఏప్రిల్‌లో సెయింట్ పీటర్స్‌బర్గ్ వెర్షన్ ఉంటుంది మరియు జూన్‌లో మేము నోవోసిబిర్స్క్‌లో అధిక లోడ్ల గురించి మాట్లాడుతాము.
రెండవది, నివేదిక రచయిత, సెర్గీ జైకా, నాలెడ్జ్ మేనేజ్‌మెంట్‌పై మా కొత్త కాన్ఫరెన్స్ ప్రోగ్రామ్ కమిటీలో సభ్యుడు . కాన్ఫరెన్స్ ఒక రోజు, ఏప్రిల్ 26 న జరుగుతుంది, కానీ దాని కార్యక్రమం చాలా తీవ్రంగా ఉంది.
మరియు అది మేలో ఉంటుంది и (DevOpsConfతో సహా) - మీరు అక్కడ మీ అంశాన్ని ప్రతిపాదించవచ్చు, మీ అనుభవం గురించి మాట్లాడవచ్చు మరియు మీ స్టఫ్డ్ కోన్‌ల గురించి ఫిర్యాదు చేయవచ్చు.
మూలం: www.habr.com