કાફકા પર અસુમેળ API સાથે રિફંડ ટૂલ સેવા વિકસાવવાનો અનુભવ

સુવ્યવસ્થિત પ્રક્રિયા અને ડઝનેક ઇન્ટરકનેક્ટેડ સેવાઓ સાથે, લામોડા જેવી મોટી કંપનીને તેના અભિગમને નોંધપાત્ર રીતે બદલવા માટે શું દબાણ કરી શકે છે? પ્રેરણા સંપૂર્ણપણે અલગ હોઈ શકે છે: કાયદાકીયથી તમામ પ્રોગ્રામરોમાં સહજ પ્રયોગ કરવાની ઇચ્છા સુધી.

પરંતુ આનો અર્થ એ નથી કે તમે વધારાના લાભો પર વિશ્વાસ કરી શકતા નથી. સેર્ગેઈ ઝૈકા તમને કહેશે કે જો તમે કાફકા (થોડાક). મોટા શોટ અને રસપ્રદ શોધો વિશે ચોક્કસપણે વાત કરવામાં આવશે - પ્રયોગ તેમના વિના કરી શકતો નથી.

અસ્વીકરણ: આ લેખ સર્ગેઈ દ્વારા નવેમ્બર 2018માં હાઈલોડ++ પર યોજાયેલી મીટિંગની સામગ્રી પર આધારિત છે. કાફકા સાથે કામ કરવાના લામોડાના જીવંત અનુભવે શ્રોતાઓને શેડ્યૂલ પરના અન્ય અહેવાલો કરતાં ઓછા આકર્ષ્યા. અમને લાગે છે કે આ એ હકીકતનું ઉત્તમ ઉદાહરણ છે કે તમે હંમેશા સમાન વિચાર ધરાવતા લોકોને શોધી શકો છો અને જોઈએ, અને HighLoad++ ના આયોજકો આ માટે અનુકૂળ વાતાવરણ બનાવવાનો પ્રયાસ ચાલુ રાખશે.

પ્રક્રિયા વિશે

લામોડા એ એક મોટું ઈ-કોમર્સ પ્લેટફોર્મ છે જેનું પોતાનું કોન્ટેક્ટ સેન્ટર, ડિલિવરી સર્વિસ (અને ઘણા આનુષંગિકો), ફોટો સ્ટુડિયો, એક વિશાળ વેરહાઉસ છે અને આ બધું તેના પોતાના સોફ્ટવેર પર ચાલે છે. ત્યાં ડઝનેક ચુકવણી પદ્ધતિઓ, b2b ભાગીદારો છે જેઓ આમાંની કેટલીક અથવા બધી સેવાઓનો ઉપયોગ કરી શકે છે અને તેમના ઉત્પાદનો પર અપ-ટૂ-ડેટ માહિતી જાણવા માંગે છે. વધુમાં, Lamoda રશિયન ફેડરેશન ઉપરાંત ત્રણ દેશોમાં કામ કરે છે અને ત્યાં બધું થોડું અલગ છે. કુલ મળીને, નવા ઓર્ડરને ગોઠવવાની કદાચ સો કરતાં વધુ રીતો છે, જે તેની પોતાની રીતે પ્રક્રિયા કરવી આવશ્યક છે. આ બધું ડઝનેક સેવાઓની મદદથી કાર્ય કરે છે જે કેટલીકવાર બિન-સ્પષ્ટ રીતે વાતચીત કરે છે. ત્યાં એક કેન્દ્રીય સિસ્ટમ પણ છે જેની મુખ્ય જવાબદારી ઓર્ડરની સ્થિતિ છે. અમે તેને BOB કહીએ છીએ, હું તેની સાથે કામ કરું છું.

ઇવેન્ટ્સ-આધારિત API સાથે રિફંડ ટૂલ

ઘટનાઓ-સંચાલિત શબ્દ તદ્દન હેકનીડ છે; થોડું આગળ આપણે આનો અર્થ શું છે તે વધુ વિગતવાર વ્યાખ્યાયિત કરીશું. હું તે સંદર્ભથી શરૂઆત કરીશ જેમાં અમે કાફકામાં ઘટનાઓ-સંચાલિત API અભિગમને અજમાવવાનું નક્કી કર્યું છે.

કોઈપણ સ્ટોરમાં, ગ્રાહકો જેના માટે ચૂકવણી કરે છે તે ઓર્ડર ઉપરાંત, એવા સમયે હોય છે જ્યારે સ્ટોરને પૈસા પરત કરવાની જરૂર પડે છે કારણ કે ઉત્પાદન ગ્રાહકને અનુકૂળ ન હતું. આ પ્રમાણમાં ટૂંકી પ્રક્રિયા છે: જો જરૂરી હોય તો અમે માહિતી સ્પષ્ટ કરીએ છીએ અને પૈસા ટ્રાન્સફર કરીએ છીએ.

પરંતુ કાયદામાં ફેરફારને કારણે વળતર વધુ જટિલ બન્યું, અને અમારે તેના માટે એક અલગ માઇક્રોસર્વિસ લાગુ કરવી પડી.

અમારી પ્રેરણા:

1. કાયદો FZ-54 - ટૂંકમાં, કાયદો દરેક નાણાકીય વ્યવહાર વિશે ટેક્સ ઑફિસને જાણ કરવાની જરૂર છે, પછી તે રિટર્ન હોય કે રસીદ, થોડી મિનિટોના એકદમ ટૂંકા SLAમાં. અમે, એક ઈ-કોમર્સ કંપની તરીકે, ઘણી બધી કામગીરીઓ કરીએ છીએ. તકનીકી રીતે, આનો અર્થ છે નવી જવાબદારી (અને તેથી નવી સેવા) અને તમામ સામેલ સિસ્ટમોમાં સુધારા.
2. BOB વિભાજિત BOB ને મોટી સંખ્યામાં બિન-મુખ્ય જવાબદારીઓમાંથી મુક્ત કરવા અને તેની એકંદર જટિલતા ઘટાડવાનો કંપનીનો આંતરિક પ્રોજેક્ટ છે.

આ રેખાકૃતિ મુખ્ય લામોડા સિસ્ટમો દર્શાવે છે. હવે તેમાંના મોટા ભાગના વધુ છે ઘટતા મોનોલિથની આસપાસ 5-10 માઇક્રોસર્વિસિસનું નક્ષત્ર. તેઓ ધીમે ધીમે વધી રહ્યા છે, પરંતુ અમે તેમને નાના બનાવવાનો પ્રયાસ કરી રહ્યા છીએ, કારણ કે મધ્યમાં પસંદ કરેલા ટુકડાને જમાવવું એ ડરામણી છે - અમે તેને પડવાની મંજૂરી આપી શકતા નથી. અમને તમામ એક્સચેન્જો (તીર) આરક્ષિત કરવાની ફરજ પાડવામાં આવે છે અને તે હકીકત ધ્યાનમાં લેવી જોઈએ કે તેમાંથી કોઈપણ અનુપલબ્ધ હોઈ શકે છે.

BOB પાસે ઘણા બધા એક્સચેન્જો પણ છેઃ પેમેન્ટ સિસ્ટમ્સ, ડિલિવરી સિસ્ટમ્સ, નોટિફિકેશન સિસ્ટમ્સ વગેરે.

તકનીકી રીતે BOB છે:

• કોડની ~150k રેખાઓ + પરીક્ષણોની ~100k રેખાઓ;
• php7.2 + Zend 1 અને Symfony ઘટકો 3;
• >100 API અને ~50 આઉટબાઉન્ડ એકીકરણ;
• 4 દેશો તેમના પોતાના વ્યવસાયના તર્ક સાથે.

BOB ને જમાવવું ખર્ચાળ અને પીડાદાયક છે, કોડ અને સમસ્યાઓનો જથ્થો તે ઉકેલે છે તે એવી છે કે કોઈ પણ આ બધું તેમના માથામાં મૂકી શકતું નથી. સામાન્ય રીતે, તેને સરળ બનાવવાના ઘણા કારણો છે.

પરત કરવાની પ્રક્રિયા

શરૂઆતમાં, પ્રક્રિયામાં બે સિસ્ટમ સામેલ છે: BOB અને ચુકવણી. હવે બે વધુ દેખાય છે:

• ફિસ્કલાઇઝેશન સર્વિસ, જે ફિસ્કલાઇઝેશન અને બાહ્ય સેવાઓ સાથે સંચારની સમસ્યાઓનું ધ્યાન રાખશે.
• રિફંડ ટૂલ, જેમાં ફક્ત નવા એક્સચેન્જોનો સમાવેશ થાય છે જેથી BOB ના વધે.

હવે પ્રક્રિયા આના જેવી લાગે છે:

1. BOB ને રિફંડ માટે વિનંતી પ્રાપ્ત થાય છે.
2. BOB આ રિફંડ ટૂલ વિશે વાત કરે છે.
3. રિફંડ ટૂલ ચુકવણીને કહે છે: "પૈસા પરત કરો."
4. ચુકવણી પૈસા પરત કરે છે.
5. રિફંડ ટૂલ અને BOB સ્ટેટસને એકબીજા સાથે સિંક્રનાઇઝ કરે છે, કારણ કે અત્યારે બંનેને તેની જરૂર છે. અમે હજુ સુધી રિફંડ ટૂલ પર સંપૂર્ણ રીતે સ્વિચ કરવા માટે તૈયાર નથી, કારણ કે BOB પાસે UI છે, એકાઉન્ટિંગ માટે રિપોર્ટ્સ છે અને સામાન્ય રીતે ઘણો ડેટા છે જે એટલી સરળતાથી ટ્રાન્સફર કરી શકાતો નથી. તમારે બે ખુરશીઓ પર બેસવું પડશે.
6. નાણાકીયીકરણ માટેની વિનંતી દૂર જાય છે.

પરિણામે, અમે કાફકા પર એક પ્રકારની ઇવેન્ટ બસ બનાવી - ઇવેન્ટ-બસ, જેના પર બધું શરૂ થયું. હુરે, હવે આપણી પાસે નિષ્ફળતાનો એક જ મુદ્દો છે (કટાક્ષ).

ગુણદોષ ખૂબ સ્પષ્ટ છે. અમે બસ બનાવી છે, જેનો અર્થ છે કે હવે બધી સેવાઓ તેના પર નિર્ભર છે. આ ડિઝાઇનને સરળ બનાવે છે, પરંતુ સિસ્ટમમાં નિષ્ફળતાના એક બિંદુને રજૂ કરે છે. કાફકા ક્રેશ થશે, પ્રક્રિયા બંધ થઈ જશે.

ઇવેન્ટ-આધારિત API શું છે

આ પ્રશ્નનો સારો જવાબ માર્ટિન ફાઉલર (GOTO 2017)ના અહેવાલમાં છે. "ઘટના-સંચાલિત આર્કિટેક્ચરના ઘણા અર્થ".

સંક્ષિપ્તમાં અમે શું કર્યું:

1. દ્વારા તમામ અસુમેળ વિનિમયને લપેટી લો ઇવેન્ટ્સ સ્ટોરેજ. દરેક રુચિ ધરાવતા ઉપભોક્તાને નેટવર્ક પર સ્ટેટસમાં ફેરફાર વિશે જાણ કરવાને બદલે, અમે કેન્દ્રિય સ્ટોરેજમાં સ્ટેટસમાં ફેરફાર વિશે એક ઇવેન્ટ લખીએ છીએ અને વિષયમાં રસ ધરાવતા ગ્રાહકો ત્યાંથી જે દેખાય છે તે બધું વાંચે છે.
2. આ કિસ્સામાં ઘટના એક સૂચના છે (સૂચનાઓ) કે કંઈક ક્યાંક બદલાયું છે. ઉદાહરણ તરીકે, ઓર્ડરની સ્થિતિ બદલાઈ ગઈ છે. એક ગ્રાહક કે જેને સ્ટેટસ ચેન્જ સાથેના કેટલાક ડેટામાં રસ હોય અને જે નોટિફિકેશનમાં સામેલ ન હોય તે તેની સ્થિતિ જાતે જાણી શકે છે.
3. મહત્તમ વિકલ્પ સંપૂર્ણ સુવિધાયુક્ત ઇવેન્ટ સોર્સિંગ છે, રાજ્ય ટ્રાન્સફર, જે ઇવેન્ટમાં પ્રક્રિયા કરવા માટે જરૂરી બધી માહિતી શામેલ છે: તે ક્યાંથી આવી અને તે કઈ સ્થિતિ પર ગઈ, ડેટા કેવી રીતે બદલાયો, વગેરે. એકમાત્ર પ્રશ્ન સંભવિતતા અને માહિતીનો જથ્થો છે જે તમે સંગ્રહિત કરી શકો છો.

રિફંડ ટૂલના લોન્ચના ભાગ રૂપે, અમે ત્રીજા વિકલ્પનો ઉપયોગ કર્યો. આ સરળ ઘટના પ્રક્રિયા છે કારણ કે વિગતવાર માહિતી કાઢવાની કોઈ જરૂર ન હતી, ઉપરાંત તે દૃશ્યને દૂર કરે છે જ્યાં દરેક નવી ઇવેન્ટ ગ્રાહકો તરફથી સ્પષ્ટતા પ્રાપ્ત વિનંતીઓનો વિસ્ફોટ પેદા કરે છે.

રિફંડ ટૂલ સેવા લોડ થયેલ નથી, તેથી કાફકા પાસે આવશ્યકતા કરતાં પેનનો સ્વાદ વધુ છે. મને નથી લાગતું કે જો રિફંડ સર્વિસ હાઈ-લોડ પ્રોજેક્ટ બની જાય, તો બિઝનેસ ખુશ થશે.

Async એક્સચેન્જ AS IS

અસુમેળ વિનિમય માટે, PHP વિભાગ સામાન્ય રીતે RabbitMQ નો ઉપયોગ કરે છે. અમે વિનંતી માટે ડેટા એકત્રિત કર્યો, તેને એક કતારમાં મૂક્યો, અને તે જ સેવાના ઉપભોક્તાએ તેને વાંચ્યો અને મોકલ્યો (અથવા તેને મોકલ્યો નથી). એપીઆઈ માટે જ, લામોડા સક્રિયપણે સ્વેગરનો ઉપયોગ કરે છે. અમે API ડિઝાઇન કરીએ છીએ, સ્વેગરમાં તેનું વર્ણન કરીએ છીએ અને ક્લાયંટ અને સર્વર કોડ જનરેટ કરીએ છીએ. અમે સહેજ ઉન્નત JSON RPC 2.0 નો પણ ઉપયોગ કરીએ છીએ.

કેટલીક જગ્યાએ ESB બસોનો ઉપયોગ થાય છે, કેટલીક એક્ટિવએમક્યુ પર રહે છે, પરંતુ, સામાન્ય રીતે, RabbitMQ - પ્રમાણભૂત.

Async એક્સચેન્જ TO BE

ઇવેન્ટ-બસ દ્વારા એક્સચેન્જ ડિઝાઇન કરતી વખતે, સામ્યતા શોધી શકાય છે. અમે એ જ રીતે ઇવેન્ટ સ્ટ્રક્ચર વર્ણન દ્વારા ભવિષ્યના ડેટા એક્સચેન્જનું વર્ણન કરીએ છીએ. yaml ફોર્મેટ, અમારે જાતે કોડ જનરેશન કરવાનું હતું, જનરેટર સ્પષ્ટીકરણ અનુસાર ડીટીઓ બનાવે છે અને ક્લાયંટ અને સર્વરને તેમની સાથે કામ કરવાનું શીખવે છે. પેઢી બે ભાષાઓમાં જાય છે - ગોલાંગ અને php. આ પુસ્તકાલયોને સુસંગત રાખવામાં મદદ કરે છે. જનરેટર ગોલાંગમાં લખાયેલું છે, તેથી તેનું નામ ગોગી પડ્યું.

કાફકા પર ઇવેન્ટ-સોર્સિંગ એ એક સામાન્ય બાબત છે. કાફકા કન્ફ્લુઅન્ટના મુખ્ય એન્ટરપ્રાઇઝ સંસ્કરણમાંથી એક ઉકેલ છે, ત્યાં છે નાકડી, અમારા ડોમેન ભાઈઓ Zalando તરફથી ઉકેલ. અમારા વેનીલા કાફકાથી શરૂઆત કરવાની પ્રેરણા - આનો અર્થ થાય છે કે જ્યાં સુધી આપણે નક્કી ન કરીએ ત્યાં સુધી આપણે તેનો સર્વત્ર ઉપયોગ કરીશું કે નહીં ત્યાં સુધી સોલ્યુશનને મુક્ત છોડી દઈએ, અને દાવપેચ અને સુધારાઓ માટે આપણી જાતને જગ્યા છોડીએ છીએ: અમને અમારા માટે સમર્થન જોઈએ છે JSON RPC 2.0, બે ભાષાઓ માટે જનરેટર અને ચાલો જોઈએ બીજું શું.

તે વ્યંગાત્મક છે કે આવા સુખી કિસ્સામાં પણ, જ્યારે લગભગ સમાન વ્યવસાય, ઝાલેન્ડો, જે લગભગ સમાન ઉકેલ બનાવે છે, અમે તેનો અસરકારક રીતે ઉપયોગ કરી શકતા નથી.

પ્રક્ષેપણ સમયે આર્કિટેક્ચરલ પેટર્ન નીચે મુજબ છે: અમે કાફકામાંથી સીધું વાંચીએ છીએ, પરંતુ ફક્ત ઇવેન્ટ્સ-બસ દ્વારા જ લખીએ છીએ. કાફકામાં વાંચવા માટે ઘણું બધું તૈયાર છે: બ્રોકર્સ, બેલેન્સર્સ, અને તે આડી સ્કેલિંગ માટે વધુ કે ઓછા તૈયાર છે, હું આ રાખવા માંગતો હતો. અમે એક ગેટવે ઉર્ફે ઇવેન્ટ્સ-બસ દ્વારા રેકોર્ડિંગ પૂર્ણ કરવા માગીએ છીએ, અને તેનું કારણ અહીં છે.

ઘટનાઓ-બસ

અથવા ઇવેન્ટ બસ. આ ફક્ત સ્ટેટલેસ http ગેટવે છે, જે ઘણી મહત્વપૂર્ણ ભૂમિકાઓ લે છે:

• માન્યતા ઉત્પાદન - અમે તપાસીએ છીએ કે ઇવેન્ટ્સ અમારા વિશિષ્ટતાઓને પૂર્ણ કરે છે.
• ઇવેન્ટ માસ્ટર સિસ્ટમ, એટલે કે, આ કંપનીની મુખ્ય અને એકમાત્ર સિસ્ટમ છે જે તે પ્રશ્નનો જવાબ આપે છે કે કઈ ઘટનાઓ સાથે કઈ રચનાઓ માન્ય ગણવામાં આવે છે. માન્યતામાં સામગ્રીને સખત રીતે સ્પષ્ટ કરવા માટે ફક્ત ડેટા પ્રકારો અને એનમનો સમાવેશ થાય છે.
• હેશ કાર્ય શાર્ડિંગ માટે - કાફકા સંદેશનું માળખું કી-વેલ્યુ છે અને કીના હેશનો ઉપયોગ કરીને તેને ક્યાં મૂકવો તેની ગણતરી કરવામાં આવે છે.

શા માટે

અમે સુવ્યવસ્થિત પ્રક્રિયા સાથે મોટી કંપનીમાં કામ કરીએ છીએ. શા માટે કંઈપણ બદલો? આ એક પ્રયોગ છે, અને અમે ઘણા લાભો મેળવવાની અપેક્ષા રાખીએ છીએ.

1:n+1 એક્સચેન્જો (એકથી ઘણા)

કાફકા નવા ગ્રાહકોને API સાથે જોડવાનું ખૂબ જ સરળ બનાવે છે.

ચાલો કહીએ કે તમારી પાસે એક ડિરેક્ટરી છે જે તમારે એકસાથે ઘણી સિસ્ટમોમાં (અને કેટલીક નવી સિસ્ટમોમાં) અપ ટુ ડેટ રાખવાની જરૂર છે. અગાઉ, અમે એક બંડલની શોધ કરી હતી જે સેટ-એપીઆઈ લાગુ કરે છે, અને મુખ્ય સિસ્ટમને ગ્રાહક સરનામાંની જાણ કરવામાં આવી હતી. હવે માસ્ટર સિસ્ટમ વિષય પર અપડેટ્સ મોકલે છે, અને રસ ધરાવતા દરેક તેને વાંચે છે. એક નવી સિસ્ટમ આવી છે - અમે તેને વિષય માટે સાઇન અપ કર્યું છે. હા, પણ બંડલ, પરંતુ સરળ.

રિફંડ-ટૂલના કિસ્સામાં, જે BOB નો એક ભાગ છે, તેને કાફકા દ્વારા સમન્વયિત રાખવું અમારા માટે અનુકૂળ છે. ચુકવણી કહે છે કે પૈસા પરત કરવામાં આવ્યા હતા: BOB, RTને આ વિશે જાણવા મળ્યું, તેમની સ્થિતિ બદલાઈ, ફિસ્કલાઇઝેશન સર્વિસને આ વિશે જાણવા મળ્યું અને ચેક જારી કર્યો.

અમે એક યુનિફાઇડ નોટિફિકેશન સર્વિસ બનાવવાની યોજના ધરાવીએ છીએ જે ક્લાયન્ટને તેના ઓર્ડર/રીટર્ન સંબંધિત સમાચાર વિશે જાણ કરશે. હવે આ જવાબદારી સિસ્ટમો વચ્ચે ફેલાયેલી છે. કાફકા પાસેથી સંબંધિત માહિતી મેળવવા અને તેનો પ્રતિસાદ આપવા (અને અન્ય સિસ્ટમમાં આ સૂચનાઓને અક્ષમ કરવા) માટે સૂચના સેવાને શીખવવા માટે અમારા માટે તે પૂરતું હશે. કોઈ નવા સીધા વિનિમયની જરૂર રહેશે નહીં.

ડેટા આધારિત

સિસ્ટમો વચ્ચેની માહિતી પારદર્શક બને છે - પછી ભલે તમારી પાસે "લોહી એન્ટરપ્રાઇઝ" હોય અને તમારો બેકલોગ કેટલો ભરાવદાર હોય તે મહત્વનું નથી. લામોડા પાસે ડેટા એનાલિટિક્સ વિભાગ છે જે સિસ્ટમ્સમાંથી ડેટા એકત્રિત કરે છે અને તેને વ્યવસાય અને બુદ્ધિશાળી સિસ્ટમો બંને માટે ફરીથી વાપરી શકાય તેવા સ્વરૂપમાં મૂકે છે. કાફકા તમને ઝડપથી તેમને ઘણો ડેટા આપવા અને તે માહિતીના પ્રવાહને અદ્યતન રાખવા દે છે.

પ્રતિકૃતિ લોગ

RabbitMQની જેમ સંદેશાઓ વાંચ્યા પછી અદૃશ્ય થતા નથી. જ્યારે ઇવેન્ટમાં પ્રક્રિયા કરવા માટે પૂરતી માહિતી હોય છે, ત્યારે અમારી પાસે ઑબ્જેક્ટમાં તાજેતરના ફેરફારોનો ઇતિહાસ હોય છે, અને, જો ઇચ્છિત હોય, તો આ ફેરફારો લાગુ કરવાની ક્ષમતા હોય છે.

પ્રતિકૃતિ લોગનો સંગ્રહ સમયગાળો આ વિષય પર લખવાની તીવ્રતા પર આધાર રાખે છે; કાફકા તમને સંગ્રહ સમય અને ડેટા વોલ્યુમ પર લવચીક રીતે મર્યાદા સેટ કરવાની મંજૂરી આપે છે. સઘન વિષયો માટે, તે મહત્વપૂર્ણ છે કે તમામ ગ્રાહકો પાસે માહિતી અદૃશ્ય થઈ જાય તે પહેલાં તેને વાંચવાનો સમય હોય, ટૂંકા ગાળાની અયોગ્યતાના કિસ્સામાં પણ. માટે ડેટા સ્ટોર કરવો સામાન્ય રીતે શક્ય છે દિવસોના એકમો, જે આધાર માટે પૂરતું છે.

આગળ, કાફકાથી પરિચિત ન હોય તેવા લોકો માટે, દસ્તાવેજીકરણની થોડી પુનઃસંગ્રહ (ચિત્ર પણ દસ્તાવેજીકરણમાંથી છે)

AMQP માં કતાર છે: અમે ઉપભોક્તા માટે કતારમાં સંદેશા લખીએ છીએ. સામાન્ય રીતે, એક જ વ્યવસાય તર્ક સાથે એક સિસ્ટમ દ્વારા એક કતાર પર પ્રક્રિયા કરવામાં આવે છે. જો તમારે ઘણી સિસ્ટમોને સૂચિત કરવાની જરૂર હોય, તો તમે એપ્લિકેશનને ઘણી કતારોમાં લખવાનું શીખવી શકો છો અથવા ફેનઆઉટ મિકેનિઝમ સાથે એક્સચેન્જને ગોઠવી શકો છો, જે તેમને પોતે જ ક્લોન કરે છે.

કાફકાનું પણ એવું જ અમૂર્તપણું છે વિષય, જેમાં તમે સંદેશાઓ લખો છો, પરંતુ તે વાંચ્યા પછી અદૃશ્ય થઈ જતા નથી. ડિફૉલ્ટ રૂપે, જ્યારે તમે કાફકા સાથે કનેક્ટ કરો છો, ત્યારે તમને બધા સંદેશા પ્રાપ્ત થાય છે અને તમે જ્યાં છોડી દીધું હતું ત્યાં સાચવવાનો વિકલ્પ હોય છે. એટલે કે, તમે ક્રમિક રીતે વાંચો છો, તમે સંદેશને વાંચેલા તરીકે ચિહ્નિત કરી શકતા નથી, પરંતુ તે ID સાચવો કે જેનાથી તમે વાંચવાનું ચાલુ રાખી શકો. તમે જે આઈડી પર સ્થાયી થયા છો તેને ઑફસેટ કહેવામાં આવે છે, અને મિકેનિઝમ કમીટ ઑફસેટ છે.

તદનુસાર, વિવિધ તર્ક અમલમાં મૂકી શકાય છે. ઉદાહરણ તરીકે, અમારી પાસે વિવિધ દેશો માટે 4 ઉદાહરણોમાં BOB છે - લામોડા રશિયા, કઝાકિસ્તાન, યુક્રેન, બેલારુસમાં છે. તેઓ અલગથી તૈનાત હોવાથી, તેમની પાસે થોડી અલગ રૂપરેખાઓ અને તેમના પોતાના વ્યવસાય તર્ક છે. અમે સંદેશમાં સૂચવીએ છીએ કે તે કયા દેશનો ઉલ્લેખ કરે છે. દરેક દેશમાં દરેક BOB ઉપભોક્તા અલગ ગ્રુપ આઈડી સાથે વાંચે છે, અને જો સંદેશ તેમને લાગુ પડતો નથી, તો તેઓ તેને છોડી દે છે, એટલે કે. તરત જ ઑફસેટ +1 કરે છે. જો આ જ વિષય અમારી ચુકવણી સેવા દ્વારા વાંચવામાં આવે છે, તો તે એક અલગ જૂથ સાથે આવું કરે છે, અને તેથી ઑફસેટ્સ એકબીજાને છેદતી નથી.

ઇવેન્ટ આવશ્યકતાઓ:

• ડેટા સંપૂર્ણતા. હું ઈચ્છું છું કે ઇવેન્ટમાં પૂરતો ડેટા હોય જેથી કરીને તેની પ્રક્રિયા થઈ શકે.

• અખંડિતતા. અમે ઇવેન્ટ્સ-બસને ચકાસણી સોંપીએ છીએ કે ઇવેન્ટ સુસંગત છે અને તે તેની પ્રક્રિયા કરી શકે છે.
• ઓર્ડર મહત્વપૂર્ણ છે. પાછા ફરવાના કિસ્સામાં, અમને ઇતિહાસ સાથે કામ કરવાની ફરજ પડી છે. સૂચનાઓ સાથે, ઓર્ડર મહત્વપૂર્ણ નથી, જો તે સજાતીય સૂચનાઓ હોય, તો જે ઓર્ડર પ્રથમ આવ્યો તે ધ્યાનમાં લીધા વિના ઇમેઇલ સમાન હશે. રિફંડના કિસ્સામાં, એક સ્પષ્ટ પ્રક્રિયા છે; જો અમે ઓર્ડર બદલીશું, તો અપવાદો ઉદ્ભવશે, રિફંડ બનાવવામાં આવશે નહીં અથવા પ્રક્રિયા કરવામાં આવશે નહીં - અમે એક અલગ સ્થિતિમાં સમાપ્ત થઈશું.
• સુસંગતતા. અમારી પાસે એક સ્ટોર છે, અને હવે અમે API ને બદલે ઇવેન્ટ્સ બનાવીએ છીએ. અમને અમારી સેવાઓમાં નવી ઇવેન્ટ્સ અને વર્તમાનમાં ફેરફારો વિશેની માહિતી ઝડપથી અને સસ્તી રીતે ટ્રાન્સમિટ કરવાની એક રીતની જરૂર છે. આ એક અલગ ગિટ રીપોઝીટરી અને કોડ જનરેટરમાં સામાન્ય સ્પષ્ટીકરણ દ્વારા પ્રાપ્ત થાય છે. તેથી, વિવિધ સેવાઓમાં ક્લાયન્ટ્સ અને સર્વર્સનું સંકલન કરવામાં આવે છે.

લામોડામાં કાફકા

અમારી પાસે ત્રણ કાફકા સ્થાપનો છે:

1. લોગ્સ;
2. આર એન્ડ ડી;
3. ઘટનાઓ-બસ.

આજે આપણે ફક્ત છેલ્લા મુદ્દા વિશે વાત કરી રહ્યા છીએ. ઇવેન્ટ-બસ પર, અમારી પાસે બહુ મોટા ઇન્સ્ટોલેશન નથી - 3 બ્રોકર્સ (સર્વર) અને માત્ર 27 વિષયો. એક નિયમ તરીકે, એક વિષય એક પ્રક્રિયા છે. પરંતુ આ એક સૂક્ષ્મ બિંદુ છે, અને અમે તેને હવે સ્પર્શ કરીશું.

ઉપર આરપીએસ ગ્રાફ છે. રિફંડ પ્રક્રિયાને પીરોજ લાઇન (હા, X અક્ષ પરની એક) સાથે ચિહ્નિત કરવામાં આવે છે, અને ગુલાબી રેખા સામગ્રી અપડેટ પ્રક્રિયા છે.

Lamoda કૅટેલોગમાં લાખો ઉત્પાદનોનો સમાવેશ થાય છે, અને ડેટા હંમેશા અપડેટ કરવામાં આવે છે. કેટલાક સંગ્રહો ફેશનની બહાર જાય છે, તેમને બદલવા માટે નવા રજૂ કરવામાં આવે છે, અને સૂચિમાં નવા મોડલ્સ સતત દેખાય છે. અમે આવતીકાલે અમારા ગ્રાહકો માટે શું રસપ્રદ રહેશે તેની આગાહી કરવાનો પ્રયાસ કરીએ છીએ, તેથી અમે સતત નવી વસ્તુઓ ખરીદીએ છીએ, તેનો ફોટોગ્રાફ લઈએ છીએ અને ડિસ્પ્લે કેસ અપડેટ કરીએ છીએ.

ગુલાબી શિખરો એ ઉત્પાદન અપડેટ્સ છે, એટલે કે, ઉત્પાદનોમાં ફેરફાર. તે જોઈ શકાય છે કે શખ્સે ચિત્રો લીધા, ચિત્રો લીધા અને પછી ફરી! - ઘટનાઓનું પેક લોડ કર્યું.

Lamoda ઘટનાઓ કેસો ઉપયોગ

અમે નીચેની કામગીરી માટે બાંધેલા આર્કિટેક્ચરનો ઉપયોગ કરીએ છીએ:

• રીટર્ન સ્ટેટસ ટ્રેકિંગ: તમામ સામેલ સિસ્ટમોમાંથી કૉલ-ટુ-એક્શન અને સ્ટેટસ ટ્રેકિંગ. ચુકવણી, સ્થિતિઓ, નાણાકીયકરણ, સૂચનાઓ. અહીં અમે અભિગમનું પરીક્ષણ કર્યું, ટૂલ્સ બનાવ્યા, બધી ભૂલો એકઠી કરી, દસ્તાવેજો લખ્યા અને અમારા સાથીઓને તેનો ઉપયોગ કેવી રીતે કરવો તે જણાવ્યું.
• પ્રોડક્ટ કાર્ડ અપડેટ કરી રહ્યાં છીએ: રૂપરેખાંકન, મેટા-ડેટા, લાક્ષણિકતાઓ. એક સિસ્ટમ વાંચે છે (જે દર્શાવે છે), અને ઘણી લખે છે.
• ઈમેલ, પુશ અને એસએમએસ: ઓર્ડર એકત્રિત કરવામાં આવ્યો છે, ઓર્ડર આવી ગયો છે, રિટર્ન સ્વીકારવામાં આવ્યું છે, વગેરે, તેમાંના ઘણા બધા છે.
• સ્ટોક, વેરહાઉસ નવીકરણ - વસ્તુઓનું માત્રાત્મક અપડેટ, માત્ર સંખ્યાઓ: વેરહાઉસ પર આગમન, પરત. તે જરૂરી છે કે રિઝર્વિંગ માલ સાથે સંકળાયેલી તમામ સિસ્ટમો સૌથી વર્તમાન ડેટા સાથે કામ કરે. હાલમાં, સ્ટોક અપડેટ સિસ્ટમ ખૂબ જટિલ છે; કાફકા તેને સરળ બનાવશે.
• માહિતી વિશ્લેષણ (R&D વિભાગ), ML ટૂલ્સ, એનાલિટિક્સ, સ્ટેટિસ્ટિક્સ. અમે ઇચ્છીએ છીએ કે માહિતી પારદર્શક હોય - કાફકા આ માટે યોગ્ય છે.

હવે છેલ્લા છ મહિનામાં થયેલી મોટી મુશ્કેલીઓ અને રસપ્રદ શોધો વિશે વધુ રસપ્રદ ભાગ.

ડિઝાઇન સમસ્યાઓ

ચાલો કહીએ કે અમે એક નવી વસ્તુ કરવા માંગીએ છીએ - ઉદાહરણ તરીકે, સમગ્ર ડિલિવરી પ્રક્રિયા કાફકાને સ્થાનાંતરિત કરો. હવે પ્રક્રિયાનો એક ભાગ BOB માં ઓર્ડર પ્રોસેસિંગમાં લાગુ કરવામાં આવ્યો છે. ઓર્ડરને ડિલિવરી સેવામાં સ્થાનાંતરિત કરવા, મધ્યવર્તી વેરહાઉસમાં હિલચાલ વગેરે પાછળ એક સ્ટેટસ મોડલ છે. ત્યાં એક સંપૂર્ણ મોનોલિથ છે, બે પણ, ઉપરાંત ડિલિવરી માટે સમર્પિત API નો સમૂહ. તેઓ ડિલિવરી વિશે વધુ જાણે છે.

આ સમાન વિસ્તારો લાગે છે, પરંતુ BOB અને શિપિંગ સિસ્ટમમાં ઓર્ડર પ્રોસેસિંગની સ્થિતિ અલગ છે. ઉદાહરણ તરીકે, કેટલીક કુરિયર સેવાઓ મધ્યવર્તી સ્થિતિઓ મોકલતી નથી, પરંતુ ફક્ત અંતિમ સ્થિતિઓ મોકલે છે: "વિતરિત" અથવા "ખોવાયેલ". અન્ય, તેનાથી વિપરીત, માલની હિલચાલ વિશે ખૂબ વિગતવાર અહેવાલ આપે છે. દરેકના પોતાના માન્યતા નિયમો છે: કેટલાક માટે, ઇમેઇલ માન્ય છે, જેનો અર્થ છે કે તે પ્રક્રિયા કરવામાં આવશે; અન્ય લોકો માટે તે માન્ય નથી, પરંતુ ઓર્ડર પર હજુ પણ પ્રક્રિયા કરવામાં આવશે કારણ કે સંપર્ક માટે ફોન નંબર છે, અને કોઈ કહેશે કે આવા ઓર્ડર પર બિલકુલ પ્રક્રિયા કરવામાં આવશે નહીં.

ડેટા સ્ટ્રીમ

કાફકાના કિસ્સામાં, ડેટા ફ્લોને ગોઠવવાનો પ્રશ્ન ઊભો થાય છે. આ કાર્યમાં કેટલાક મુદ્દાઓ પર આધારિત વ્યૂહરચના પસંદ કરવાનો સમાવેશ થાય છે; ચાલો તે બધામાંથી પસાર થઈએ.

એક વિષયમાં કે અલગ વિષયમાં?

અમારી પાસે ઇવેન્ટ સ્પષ્ટીકરણ છે. BOB માં અમે લખીએ છીએ કે આવા અને આવા ઓર્ડરને વિતરિત કરવાની જરૂર છે, અને સૂચવે છે: ઓર્ડર નંબર, તેની રચના, કેટલાક SKU અને બાર કોડ વગેરે. જ્યારે માલ વેરહાઉસ પર પહોંચે છે, ત્યારે ડિલિવરી સ્ટેટસ, ટાઇમસ્ટેમ્પ અને જરૂરી હોય તે બધું પ્રાપ્ત કરી શકશે. પરંતુ પછી અમે BOB માં આ ડેટા પર અપડેટ્સ પ્રાપ્ત કરવા માંગીએ છીએ. અમારી પાસે ડિલિવરીમાંથી ડેટા મેળવવાની વિપરીત પ્રક્રિયા છે. શું આ જ ઘટના છે? અથવા આ એક અલગ વિનિમય છે જે તેના પોતાના વિષયને પાત્ર છે?

મોટે ભાગે, તેઓ ખૂબ સમાન હશે, અને એક વિષય બનાવવાની લાલચ પાયાવિહોણી નથી, કારણ કે એક અલગ વિષયનો અર્થ છે અલગ ઉપભોક્તા, અલગ રૂપરેખાંકનો, આ બધાની એક અલગ પેઢી. પરંતુ હકીકત નથી.

નવું ક્ષેત્ર કે નવી ઘટના?

પરંતુ જો તમે સમાન ઘટનાઓનો ઉપયોગ કરો છો, તો બીજી સમસ્યા ઊભી થાય છે. ઉદાહરણ તરીકે, બધી ડિલિવરી સિસ્ટમ્સ BOB જે પ્રકારનું DTO જનરેટ કરી શકે છે તે જનરેટ કરી શકતી નથી. અમે તેમને આઈડી મોકલીએ છીએ, પરંતુ તેઓ તેને સાચવતા નથી કારણ કે તેમને તેની જરૂર નથી, અને ઇવેન્ટ-બસ પ્રક્રિયા શરૂ કરવાના દૃષ્ટિકોણથી, આ ક્ષેત્ર જરૂરી છે.

જો અમે ઇવેન્ટ-બસ માટે નિયમ રજૂ કરીએ છીએ કે આ ક્ષેત્ર જરૂરી છે, તો અમને BOB અથવા સ્ટાર્ટ ઇવેન્ટ હેન્ડલરમાં વધારાના માન્યતા નિયમો સેટ કરવાની ફરજ પડી છે. માન્યતા સમગ્ર સેવામાં ફેલાવાનું શરૂ થાય છે - આ ખૂબ અનુકૂળ નથી.

બીજી સમસ્યા એ વૃદ્ધિશીલ વિકાસની લાલચ છે. અમને કહેવામાં આવ્યું છે કે ઇવેન્ટમાં કંઈક ઉમેરવાની જરૂર છે, અને કદાચ, જો આપણે તેના વિશે વિચારીએ, તો તે એક અલગ ઇવેન્ટ હોવી જોઈએ. પરંતુ અમારી યોજનામાં, એક અલગ ઇવેન્ટ એ એક અલગ વિષય છે. એક અલગ વિષય એ સમગ્ર પ્રક્રિયા છે જે મેં ઉપર વર્ણવી છે. વિકાસકર્તાને ફક્ત JSON સ્કીમમાં બીજું ફીલ્ડ ઉમેરવા અને તેને ફરીથી બનાવવા માટે લલચાવવામાં આવે છે.

રિફંડના કિસ્સામાં, અમે અડધા વર્ષમાં ઇવેન્ટની ઘટના પર પહોંચ્યા. અમારી પાસે રિફંડ અપડેટ નામની એક મેટા-ઇવેન્ટ હતી, જેમાં આ અપડેટ ખરેખર શું છે તેનું વર્ણન કરતું એક પ્રકારનું ફીલ્ડ હતું. આને કારણે, અમારી પાસે માન્યકર્તાઓ સાથે "અદ્ભુત" સ્વીચો હતા જેમણે અમને કહ્યું કે આ ઇવેન્ટને આ પ્રકાર સાથે કેવી રીતે માન્ય કરવી.

ઇવેન્ટ વર્ઝનિંગ

કાફકામાં સંદેશાઓને માન્ય કરવા માટે તમે ઉપયોગ કરી શકો છો યુરો, પરંતુ તરત જ તેના પર મૂકવું અને કન્ફ્લુઅન્ટનો ઉપયોગ કરવો જરૂરી હતું. અમારા કિસ્સામાં, આપણે વર્ઝનિંગ સાથે સાવચેત રહેવું જોઈએ. પ્રતિકૃતિ લોગમાંથી સંદેશાઓને ફરીથી વાંચવાનું હંમેશા શક્ય બનશે નહીં કારણ કે મોડેલમાં "ડાબે" છે. મૂળભૂત રીતે, તે સંસ્કરણો બનાવવા માટે બહાર આવ્યું છે જેથી મોડેલ પાછળની તરફ સુસંગત હોય: ઉદાહરણ તરીકે, ક્ષેત્રને અસ્થાયી રૂપે વૈકલ્પિક બનાવો. જો તફાવતો ખૂબ જ મજબૂત હોય, તો અમે નવા વિષયમાં લખવાનું શરૂ કરીએ છીએ, અને ક્લાયન્ટ જ્યારે જૂનું વાંચવાનું સમાપ્ત કરીએ છીએ ત્યારે તેમને સ્થાનાંતરિત કરીએ છીએ.

પાર્ટીશનોના વાંચન ક્રમની ખાતરી

કાફકાની અંદરના વિષયોને પાર્ટીશનોમાં વહેંચવામાં આવ્યા છે. જ્યારે આપણે એન્ટિટી અને એક્સચેન્જો ડિઝાઇન કરી રહ્યા હોઈએ ત્યારે આ ખૂબ મહત્વનું નથી, પરંતુ તેનો વપરાશ અને સ્કેલ કેવી રીતે કરવો તે નક્કી કરતી વખતે તે મહત્વપૂર્ણ છે.

સામાન્ય કિસ્સામાં, તમે કાફકામાં એક વિષય લખો છો. મૂળભૂત રીતે, એક પાર્ટીશનનો ઉપયોગ થાય છે, અને આ વિષયના બધા સંદેશાઓ તેના પર જાય છે. અને પરિણામે ગ્રાહક આ સંદેશાઓ ક્રમિક રીતે વાંચે છે. ચાલો કહીએ કે હવે આપણે સિસ્ટમને વિસ્તૃત કરવાની જરૂર છે જેથી સંદેશાઓ બે અલગ-અલગ ગ્રાહકો દ્વારા વાંચવામાં આવે. જો, ઉદાહરણ તરીકે, તમે એસએમએસ મોકલી રહ્યાં છો, તો પછી તમે કાફકાને વધારાનું પાર્ટીશન બનાવવા માટે કહી શકો છો, અને કાફકા સંદેશાઓને બે ભાગોમાં વિભાજિત કરવાનું શરૂ કરશે - અડધા અહીં, અડધા અહીં.

કાફકા તેમને કેવી રીતે વિભાજિત કરે છે? દરેક સંદેશમાં એક મુખ્ય ભાગ (જેમાં આપણે JSON સંગ્રહિત કરીએ છીએ) અને એક કી હોય છે. તમે આ કી સાથે હેશ ફંક્શન જોડી શકો છો, જે નક્કી કરશે કે સંદેશ કયા પાર્ટીશનમાં જશે.

રિફંડ સાથેના અમારા કિસ્સામાં, આ મહત્વપૂર્ણ છે, જો આપણે બે પાર્ટીશનો લઈએ, તો એવી તક છે કે સમાંતર ઉપભોક્તા પ્રથમ પહેલાં બીજી ઘટના પર પ્રક્રિયા કરશે અને મુશ્કેલી ઊભી થશે. હેશ ફંક્શન એ સુનિશ્ચિત કરે છે કે સમાન કી સાથેના સંદેશાઓ સમાન પાર્ટીશનમાં સમાપ્ત થાય છે.

ઇવેન્ટ્સ વિ આદેશો

આ બીજી સમસ્યા છે જેનો અમે સામનો કર્યો. ઇવેન્ટ એ ચોક્કસ ઘટના છે: અમે કહીએ છીએ કે કંઈક ક્યાંક થયું છે (something_happened), ઉદાહરણ તરીકે, કોઈ આઇટમ રદ કરવામાં આવી હતી અથવા રિફંડ આવી હતી. જો કોઈ વ્યક્તિ આ ઇવેન્ટ્સ સાંભળે છે, તો પછી "આઇટમ રદ કરવામાં આવી" મુજબ, રિફંડ એન્ટિટી બનાવવામાં આવશે અને સેટઅપ્સમાં ક્યાંક "રિફંડ આવ્યું" લખવામાં આવશે.

પરંતુ સામાન્ય રીતે, જ્યારે તમે ઇવેન્ટ્સ ડિઝાઇન કરો છો, ત્યારે તમે તેને નિરર્થક રીતે લખવા માંગતા નથી - તમે એ હકીકત પર વિશ્વાસ કરો છો કે કોઈ તેને વાંચશે. કંઇક_થયું (આઇટમ_રદ કરેલ, રિફંડ_રિફંડ) નહી પરંતુ કંઇક_થવું_કરવું_કરવું લખવાની લાલચ છે. ઉદાહરણ તરીકે, આઇટમ પરત કરવા માટે તૈયાર છે.

એક તરફ, તે સૂચવે છે કે ઇવેન્ટનો ઉપયોગ કેવી રીતે કરવામાં આવશે. બીજી બાજુ, તે સામાન્ય ઘટના નામ જેવું ઘણું ઓછું લાગે છે. આ ઉપરાંત, તે અહીંથી do_something આદેશથી દૂર નથી. પરંતુ તમારી પાસે કોઈ ગેરેંટી નથી કે કોઈ આ ઘટના વાંચે છે; અને જો તમે તેને વાંચો છો, તો પછી તમે તેને સફળતાપૂર્વક વાંચો છો; અને જો તમે તેને સફળતાપૂર્વક વાંચો, તો તમે કંઈક કર્યું, અને તે કંઈક સફળ થયું. જે ક્ષણે કોઈ ઇવેન્ટ do_something બને છે, પ્રતિસાદ જરૂરી બને છે, અને તે એક સમસ્યા છે.

RabbitMQ માં અસુમેળ વિનિમયમાં, જ્યારે તમે સંદેશ વાંચો છો, http પર જાઓ છો, ત્યારે તમારી પાસે પ્રતિસાદ છે - ઓછામાં ઓછું તે સંદેશ પ્રાપ્ત થયો હતો. જ્યારે તમે કાફકાને લખો છો, ત્યારે એક સંદેશ હોય છે જે તમે કાફકાને લખ્યો હતો, પરંતુ તે કેવી રીતે પ્રક્રિયા કરવામાં આવી હતી તે વિશે તમે કંઈપણ જાણતા નથી.

તેથી, અમારા કિસ્સામાં, અમારે પ્રતિભાવ ઇવેન્ટ રજૂ કરવી પડી અને મોનિટરિંગ સેટ કરવું પડ્યું જેથી જો આટલી બધી ઇવેન્ટ્સ મોકલવામાં આવે, તો આવા અને આવા સમય પછી એટલી જ સંખ્યામાં પ્રતિસાદ ઇવેન્ટ્સ આવે. જો આમ ન થાય તો કંઈક ખોટું થયું હોય એવું લાગે છે. ઉદાહરણ તરીકે, જો અમે "આઇટમ_રેડી_ટુ_રીફંડ" ઇવેન્ટ મોકલી છે, તો અમે અપેક્ષા રાખીએ છીએ કે રિફંડ બનાવવામાં આવશે, પૈસા ક્લાયન્ટને પરત કરવામાં આવશે અને "મની_રિફંડ" ઇવેન્ટ અમને મોકલવામાં આવશે. પરંતુ આ ચોક્કસ નથી, તેથી દેખરેખની જરૂર છે.

નુક્શાન

ત્યાં એકદમ સ્પષ્ટ સમસ્યા છે: જો તમે કોઈ વિષયમાંથી ક્રમિક રીતે વાંચો છો, અને તમારી પાસે કોઈ ખરાબ સંદેશ છે, તો ગ્રાહક પડી જશે, અને તમે આગળ વધશો નહીં. તમને જરૂર છે બધા ગ્રાહકોને રોકો, વાંચન ચાલુ રાખવા માટે વધુ ઓફસેટ કરો.

અમે તેના વિશે જાણતા હતા, અમે તેના પર ગણતરી કરી હતી, અને તેમ છતાં તે થયું. અને આવું એટલા માટે થયું કારણ કે ઇવેન્ટ ઈવેન્ટ્સ-બસના દૃષ્ટિકોણથી માન્ય હતી, એપ્લીકેશન વેલિડેટરના દૃષ્ટિકોણથી ઇવેન્ટ માન્ય હતી, પરંતુ પોસ્ટગ્રેએસક્યુએલના દૃષ્ટિકોણથી તે માન્ય ન હતી, કારણ કે અમારી સિસ્ટમમાં MySQL UnSigned INT સાથે સિસ્ટમમાં પોસ્ટગ્રેએસક્યુએલ ફક્ત INT સાથે હતું. તેનું કદ થોડું નાનું છે, અને આઈડી ફિટ નથી. સિમ્ફની એક અપવાદ સાથે મૃત્યુ પામી. અમે, અલબત્ત, અપવાદને પકડ્યો કારણ કે અમે તેના પર આધાર રાખ્યો હતો, અને આ ઑફસેટ કરવા જઈ રહ્યા હતા, પરંતુ તે પહેલાં અમે સમસ્યા કાઉન્ટરને વધારવા માંગીએ છીએ, કારણ કે સંદેશની અસફળ પ્રક્રિયા કરવામાં આવી હતી. આ પ્રોજેક્ટના કાઉન્ટર્સ પણ ડેટાબેઝમાં છે, અને સિમ્ફોનીએ ડેટાબેઝ સાથેનો સંચાર પહેલેથી જ બંધ કરી દીધો છે, અને બીજા અપવાદે ઑફસેટ કરવાની કોઈ તક વિના સમગ્ર પ્રક્રિયાને મારી નાખી છે.

સેવા થોડા સમય માટે પડી રહી છે - સદભાગ્યે, કાફકા સાથે આ એટલું ખરાબ નથી, કારણ કે સંદેશાઓ રહે છે. જ્યારે કાર્ય પુનઃસ્થાપિત થાય છે, ત્યારે તમે તેમને વાંચવાનું સમાપ્ત કરી શકો છો. તે આરામદાયક છે.

કાફકા પાસે ટૂલિંગ દ્વારા મનસ્વી ઓફસેટ સેટ કરવાની ક્ષમતા છે. પરંતુ આ કરવા માટે, તમારે બધા ગ્રાહકોને રોકવાની જરૂર છે - અમારા કિસ્સામાં, એક અલગ પ્રકાશન તૈયાર કરો જેમાં કોઈ ઉપભોક્તા, પુનઃસ્થાપન નહીં હોય. પછી કાફકામાં તમે ટૂલિંગ દ્વારા ઑફસેટને શિફ્ટ કરી શકો છો, અને સંદેશ પસાર થશે.

અન્ય ઉપદ્રવ - પ્રતિકૃતિ લોગ વિ rdkafka.so - અમારા પ્રોજેક્ટની વિશિષ્ટતાઓ સાથે સંબંધિત છે. અમે PHP નો ઉપયોગ કરીએ છીએ, અને PHP માં, એક નિયમ તરીકે, બધી લાઇબ્રેરીઓ rdkafka.so રીપોઝીટરી દ્વારા કાફકા સાથે વાતચીત કરે છે, અને પછી ત્યાં એક પ્રકારનું રેપર છે. કદાચ આ અમારી અંગત મુશ્કેલીઓ છે, પરંતુ તે બહાર આવ્યું છે કે આપણે જે વાંચ્યું છે તેના ભાગને ફરીથી વાંચવું એટલું સરળ નથી. સામાન્ય રીતે, સોફ્ટવેર સમસ્યાઓ હતી.

પાર્ટીશનો સાથે કામ કરવાની વિશિષ્ટતાઓ પર પાછા ફરવું, તે દસ્તાવેજીકરણમાં જ લખાયેલું છે ઉપભોક્તા >= વિષય પાર્ટીશનો. પરંતુ મને ગમ્યું હોત તેના કરતાં મને આ વિશે ઘણું પાછળથી જાણવા મળ્યું. જો તમે સ્કેલ કરવા માંગો છો અને બે ઉપભોક્તા ધરાવો છો, તો તમારે ઓછામાં ઓછા બે પાર્ટીશનોની જરૂર છે. એટલે કે, જો તમારી પાસે એક પાર્ટીશન હોય જેમાં 20 હજાર સંદેશાઓ એકઠા થયા હોય, અને તમે એક નવું બનાવ્યું હોય, તો ટૂંક સમયમાં સંદેશાઓની સંખ્યા બરાબર થશે નહીં. તેથી, બે સમાંતર ગ્રાહકો રાખવા માટે, તમારે પાર્ટીશનો સાથે વ્યવહાર કરવાની જરૂર છે.

મોનીટરીંગ

મને લાગે છે કે આપણે જે રીતે તેનું નિરીક્ષણ કરીએ છીએ તે વધુ સ્પષ્ટ થશે કે હાલના અભિગમમાં કઈ સમસ્યાઓ છે.

ઉદાહરણ તરીકે, અમે ગણતરી કરીએ છીએ કે ડેટાબેઝમાં કેટલા ઉત્પાદનોએ તાજેતરમાં તેમની સ્થિતિ બદલી છે, અને તે મુજબ, આ ફેરફારોના આધારે ઇવેન્ટ્સ આવી હોવી જોઈએ, અને અમે આ નંબર અમારી મોનિટરિંગ સિસ્ટમને મોકલીએ છીએ. પછી કાફકામાંથી આપણને બીજો નંબર મળે છે, ખરેખર કેટલી ઘટનાઓ નોંધવામાં આવી હતી. દેખીતી રીતે, આ બે સંખ્યાઓ વચ્ચેનો તફાવત હંમેશા શૂન્ય હોવો જોઈએ.

વધુમાં, તમારે મોનિટર કરવાની જરૂર છે કે નિર્માતા કેવી રીતે કરી રહ્યા છે, શું ઇવેન્ટ-બસને સંદેશા પ્રાપ્ત થયા છે અને ગ્રાહક કેવી રીતે કરી રહ્યા છે. ઉદાહરણ તરીકે, નીચેના ચાર્ટમાં, રિફંડ ટૂલ સારું કામ કરી રહ્યું છે, પરંતુ BOB સ્પષ્ટપણે કેટલીક સમસ્યાઓ ધરાવે છે (વાદળી શિખરો).

મેં પહેલેથી જ ગ્રાહક-જૂથ લેગનો ઉલ્લેખ કર્યો છે. સામાન્ય રીતે કહીએ તો, આ ન વાંચેલા સંદેશાઓની સંખ્યા છે. સામાન્ય રીતે, અમારા ગ્રાહકો ઝડપથી કામ કરે છે, તેથી લેગ સામાન્ય રીતે 0 હોય છે, પરંતુ કેટલીકવાર ટૂંકા ગાળાની ટોચ હોઈ શકે છે. કાફકા આ બૉક્સની બહાર કરી શકે છે, પરંતુ તમારે ચોક્કસ અંતરાલ સેટ કરવાની જરૂર છે.

એક પ્રોજેક્ટ છે બરોવજે તમને કાફકા વિશે વધુ માહિતી આપશે. આ જૂથ કેવી રીતે કાર્ય કરી રહ્યું છે તેની સ્થિતિ આપવા માટે તે ફક્ત ગ્રાહક-જૂથ API નો ઉપયોગ કરે છે. ઠીક અને નિષ્ફળ ઉપરાંત, ત્યાં એક ચેતવણી છે, અને તમે શોધી શકો છો કે તમારા ઉપભોક્તા ઉત્પાદનની ગતિનો સામનો કરી શકતા નથી - તેમની પાસે જે લખ્યું છે તે પ્રૂફરીડ કરવાનો સમય નથી. સિસ્ટમ એકદમ સ્માર્ટ અને ઉપયોગમાં સરળ છે.

આ API પ્રતિસાદ જેવો દેખાય છે. આ છે ગ્રૂપ બોબ-લાઇવ-ફીફા, પાર્ટીશન રિફંડ.અપડેટ.વી1, સ્ટેટસ ઓકે, લેગ 0 - છેલ્લું અંતિમ ઑફસેટ આવા અને આવા.

મોનીટરીંગ અપડેટ_એટ SLA (અટવાયું) મેં પહેલેથી જ ઉલ્લેખ કર્યો છે. ઉદાહરણ તરીકે, ઉત્પાદનની સ્થિતિ બદલાઈ ગઈ છે કે તે વળતર માટે તૈયાર છે. અમે ક્રોન ઇન્સ્ટોલ કરીએ છીએ, જે કહે છે કે જો 5 મિનિટમાં આ ઑબ્જેક્ટ રિફંડ માટે ગયો નથી (અમે ખૂબ જ ઝડપથી ચુકવણી સિસ્ટમ દ્વારા પૈસા પરત કરીએ છીએ), તો ચોક્કસપણે કંઈક ખોટું થયું છે, અને આ ચોક્કસપણે સમર્થન માટેનો કેસ છે. તેથી, અમે ફક્ત ક્રોન લઈએ છીએ, જે આવી વસ્તુઓ વાંચે છે, અને જો તે 0 કરતા વધારે હોય, તો તે ચેતવણી મોકલે છે.

સારાંશ માટે, જ્યારે ઇવેન્ટ્સનો ઉપયોગ કરવો અનુકૂળ છે:

• માહિતી ઘણી સિસ્ટમો દ્વારા જરૂરી છે;
• પ્રક્રિયાનું પરિણામ મહત્વનું નથી;
• ત્યાં થોડી ઘટનાઓ અથવા નાની ઘટનાઓ છે.

એવું લાગે છે કે લેખમાં એક ખૂબ જ વિશિષ્ટ વિષય છે - કાફકા પર અસુમેળ API, પરંતુ તેના સંબંધમાં હું એક સાથે ઘણી બધી વસ્તુઓની ભલામણ કરવા માંગુ છું.
પ્રથમ, આગામી હાઇલોડ++ આપણે નવેમ્બર સુધી રાહ જોવાની જરૂર છે; એપ્રિલમાં સેન્ટ પીટર્સબર્ગ સંસ્કરણ હશે, અને જૂનમાં આપણે નોવોસિબિર્સ્કમાં વધુ ભાર વિશે વાત કરીશું.
બીજું, અહેવાલના લેખક, સેરગેઈ ઝૈકા, જ્ઞાન વ્યવસ્થાપન પર અમારી નવી પરિષદની પ્રોગ્રામ કમિટીના સભ્ય છે. KnowledgeConf. આ કોન્ફરન્સ એક દિવસીય છે, 26 એપ્રિલે થશે, પરંતુ તેનો કાર્યક્રમ ખૂબ જ તીવ્ર છે.
અને તે મેમાં હશે PHP રશિયા и RIT++ (DevOpsConf સમાવિષ્ટ સાથે) - તમે ત્યાં તમારા વિષયનો પ્રસ્તાવ પણ મૂકી શકો છો, તમારા અનુભવ વિશે વાત કરી શકો છો અને તમારા સ્ટફ્ડ શંકુ વિશે ફરિયાદ કરી શકો છો.

સોર્સ: www.habr.com