ડોડો IS આર્કિટેક્ચરનો ઇતિહાસ: ધ બેક ઓફિસ પાથ

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

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

સ્વીકૃતિઓ: તમારો પ્રતિસાદ અમારી સાથે શેર કરવા બદલ આભાર. તેમના માટે આભાર, અમે આખરે સિસ્ટમનું વર્ણન કર્યું, તકનીકી રડારનું સંકલન કર્યું અને ટૂંક સમયમાં અમારી પ્રક્રિયાઓનું વિશાળ વર્ણન રજૂ કરીશું. તમારા વિના, અમે બીજા 5 વર્ષ ત્યાં બેઠા હોત.

લેખોની શ્રેણી "ડોડો IS શું છે?" વિશે કહે છે:

1. ડોડો IS (2011-2015) માં પ્રારંભિક મોનોલિથ. (પ્રગતિમાં...)
2. બેક ઓફિસ પાથ: અલગ પાયા અને બસ. (તમે અહિંયા છો)
3. ક્લાયંટ સાઇડ પાથ: બેઝ ઉપર રવેશ (2016-2017). (પ્રગતિમાં...)
4. વાસ્તવિક માઇક્રોસર્વિસિસનો ઇતિહાસ. (2018-2019). (પ્રગતિમાં...)
5. મોનોલિથની સોઇંગ અને આર્કિટેક્ચરનું સ્થિરીકરણ સમાપ્ત. (પ્રગતિમાં...)

જો તમને કંઈક બીજું જાણવામાં રસ હોય તો - ટિપ્પણીઓમાં લખો.

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

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

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

2011 માં, ડોડો IS આર્કિટેક્ચર આના જેવું દેખાતું હતું:

2020 સુધીમાં, તે થોડું વધુ જટિલ બની ગયું છે અને આના જેવું બની ગયું છે:

આ ઉત્ક્રાંતિ કેવી રીતે થઈ? સિસ્ટમના વિવિધ ભાગો શા માટે જરૂરી છે? કયા આર્કિટેક્ચરલ નિર્ણયો લેવામાં આવ્યા હતા અને શા માટે? ચાલો આ લેખોની શ્રેણીમાં શોધીએ.

2016 ની પ્રથમ સમસ્યાઓ: સેવાઓએ મોનોલિથ કેમ છોડવું જોઈએ

શ્રેણીના પ્રથમ લેખો તે સેવાઓ વિશે હશે જે મોનોલિથથી અલગ કરવામાં પ્રથમ હતા. તમને સંદર્ભમાં મૂકવા માટે, હું તમને કહીશ કે 2016 ની શરૂઆતમાં અમને સિસ્ટમમાં કઈ સમસ્યાઓ હતી, કે અમારે સેવાઓના વિભાજનનો સામનો કરવો પડ્યો હતો.

એક જ MySql ડેટાબેઝ, જેમાં ડોડો ISમાં તે સમયે અસ્તિત્વમાં રહેલી તમામ એપ્લિકેશનો તેમના રેકોર્ડ લખે છે. પરિણામો હતા:

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

સમસ્યા એ મોનોલિથની હાજરી હતી. પરિણામો હતા:

• સિંગલ અને દુર્લભ રિલીઝ.
• મોટી સંખ્યામાં લોકોના સંયુક્ત વિકાસમાં મુશ્કેલી.
• નવી ટેકનોલોજી, નવા ફ્રેમવર્ક અને પુસ્તકાલયો રજૂ કરવામાં અસમર્થતા.

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

બેક ઓફિસ પાથ: અલગ પાયા અને બસ

પ્રકરણ નેવિગેશન

1. મોનોલિથ સ્કીમ 2016
2. મોનોલિથને અનલોડ કરવાનું શરૂ કરી રહ્યા છીએ: પ્રમાણીકરણ અને ટ્રેકરનું વિભાજન
   
3. Auth શું કરે છે?
4. ભાર ક્યાંથી આવે છે?
5. પ્રમાણીકરણ અનલોડ કરી રહ્યું છે
6. ટ્રેકર શું કરે છે?
7. ભાર ક્યાંથી આવે છે?
8. અનલોડિંગ ટ્રેકર

મોનોલિથ સ્કીમ 2016

અહીં ડોડો IS 2016 મોનોલિથના મુખ્ય બ્લોક્સ છે, અને નીચે તેમના મુખ્ય કાર્યોની ટ્રાન્સક્રિપ્ટ છે.

કેશિયર ડિલિવરી. કુરિયર્સ માટે એકાઉન્ટિંગ, કુરિયર્સને ઓર્ડર આપવા.
સંપર્ક કેન્દ્ર. ઑપરેટર દ્વારા ઓર્ડરની સ્વીકૃતિ.
સાઇટ. અમારી વેબસાઇટ્સ (dodopizza.ru, dodopizza.co.uk, dodopizza.by, વગેરે).
ઑથ. બેક ઓફિસ માટે અધિકૃતતા અને પ્રમાણીકરણ સેવા.
ટ્રેકર. રસોડામાં ઓર્ડર ટ્રેકર. ઓર્ડર તૈયાર કરતી વખતે તૈયારીની સ્થિતિને ચિહ્નિત કરવા માટેની સેવા.
રેસ્ટોરન્ટનું કેશ ડેસ્ક. રેસ્ટોરન્ટમાં ઓર્ડર લેવા, કેશિયર ઇન્ટરફેસ.
નિકાસ કરો. એકાઉન્ટિંગ માટે 1C માં અહેવાલો અપલોડ કરી રહ્યા છીએ.
સૂચનાઓ અને ઇન્વૉઇસેસ. રસોડામાં વૉઇસ કમાન્ડ (ઉદાહરણ તરીકે, “નવું પિઝા આવ્યું”) + કુરિયર માટે ઇન્વૉઇસ પ્રિન્ટિંગ.
શિફ્ટ મેનેજર. શિફ્ટ મેનેજરના કામ માટે ઇન્ટરફેસ: ઓર્ડરની સૂચિ, પ્રદર્શન ગ્રાફ, કર્મચારીઓને શિફ્ટમાં સ્થાનાંતરિત કરવું.
ઓફિસ મેનેજર. ફ્રેન્ચાઇઝી અને મેનેજરના કામ માટે ઇન્ટરફેસ: કર્મચારીઓનું સ્વાગત, પિઝેરિયાના કામ પરના અહેવાલો.
રેસ્ટોરન્ટ સ્કોરબોર્ડ. પિઝેરિયામાં ટીવી પર મેનૂ ડિસ્પ્લે.
એડમિન. ચોક્કસ પિઝેરિયામાં સેટિંગ્સ: મેનૂ, કિંમતો, એકાઉન્ટિંગ, પ્રોમો કોડ્સ, પ્રમોશન, વેબસાઇટ બેનરો, વગેરે.
કર્મચારીનું વ્યક્તિગત ખાતું. કર્મચારીઓના કામનું સમયપત્રક, કર્મચારીઓ વિશેની માહિતી.
કિચન મોટિવેશન બોર્ડ. એક અલગ સ્ક્રીન જે રસોડામાં અટકી જાય છે અને પિઝા બનાવનારાઓની ઝડપ દર્શાવે છે.
કોમ્યુનિકેશન. એસએમએસ અને ઈમેલ મોકલી રહ્યું છે.
ફાઇલસ્ટોરેજ. સ્ટેટિક ફાઇલો મેળવવા અને જારી કરવા માટે પોતાની સેવા.

સમસ્યાઓ હલ કરવાના પ્રથમ પ્રયાસોએ અમને મદદ કરી, પરંતુ તે માત્ર એક અસ્થાયી રાહત હતી. તેઓ સિસ્ટમ સોલ્યુશન્સ બન્યા ન હતા, તેથી તે સ્પષ્ટ હતું કે પાયા સાથે કંઈક કરવું પડશે. ઉદાહરણ તરીકે, સામાન્ય ડેટાબેઝને કેટલાક વધુ વિશિષ્ટમાં વિભાજીત કરવા.

મોનોલિથને અનલોડ કરવાનું શરૂ કરી રહ્યા છીએ: પ્રમાણીકરણ અને ટ્રેકરનું વિભાજન

મુખ્ય સેવાઓ કે જે પછી ડેટાબેઝમાંથી અન્ય કરતા વધુ રેકોર્ડ અને વાંચે છે:

1. ઓથ. બેક ઓફિસ માટે અધિકૃતતા અને પ્રમાણીકરણ સેવા.
2. ટ્રેકર. રસોડામાં ઓર્ડર ટ્રેકર. ઓર્ડર તૈયાર કરતી વખતે તૈયારીની સ્થિતિને ચિહ્નિત કરવા માટેની સેવા.

Auth શું કરે છે?

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

ઉદાહરણ તરીકે, અમે હોલમાં લટકાવેલા ટીવી પર ફિનિશ્ડ ઓર્ડરની સ્થિતિઓ સાથે ડિસ્પ્લે ખોલવા માંગીએ છીએ. પછી અમે auth.dodopizza.ru ખોલીએ છીએ, "ઉપકરણ તરીકે લૉગિન" પસંદ કરો, એક કોડ દેખાય છે જે શિફ્ટ મેનેજરના કમ્પ્યુટર પરના વિશિષ્ટ પૃષ્ઠમાં દાખલ કરી શકાય છે, જે ઉપકરણ (ઉપકરણ) નો પ્રકાર સૂચવે છે. ટીવી પોતે તેના પિઝેરિયાના ઇચ્છિત ઇન્ટરફેસ પર સ્વિચ કરશે અને ગ્રાહકોના નામ પ્રદર્શિત કરવાનું શરૂ કરશે જેમના ઓર્ડર ત્યાં તૈયાર છે.

ભાર ક્યાંથી આવે છે?

બેક ઓફિસનો દરેક લોગ ઇન થયેલ વપરાશકર્તા ડેટાબેઝ પર જાય છે, દરેક વિનંતી માટે વપરાશકર્તા ટેબલ પર જાય છે, વપરાશકર્તાને sql ક્વેરી દ્વારા બહાર કાઢે છે અને તપાસે છે કે તેની પાસે આ પૃષ્ઠની આવશ્યક ઍક્સેસ અને અધિકારો છે કે કેમ.

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

પ્રમાણીકરણ અનલોડ કરી રહ્યું છે

Auth પાસે એક અલગ ડોમેન છે, એટલે કે, વપરાશકર્તાઓ, લોગિન અથવા ઉપકરણો વિશેનો ડેટા સેવામાં પ્રવેશે છે (અત્યાર સુધી) અને ત્યાં જ રહે છે. જો કોઈને તેમની જરૂર હોય, તો તે ડેટા માટે આ સેવા પર જશે.

ડબલ્યુએએસ. કાર્યની મૂળ યોજના નીચે મુજબ હતી:

તે કેવી રીતે કાર્ય કરે છે તે હું થોડું સમજાવવા માંગુ છું:

1. બહારથી વિનંતી બેકએન્ડ પર આવે છે (ત્યાં Asp.Net MVC છે), તેની સાથે સેશન કૂકી લાવે છે, જેનો ઉપયોગ Redis(1) પાસેથી સત્ર ડેટા મેળવવા માટે થાય છે. તે કાં તો ઍક્સેસ વિશેની માહિતી ધરાવે છે, અને પછી નિયંત્રકની ઍક્સેસ ખુલ્લી છે (3,4), અથવા નહીં.
2. જો ત્યાં કોઈ ઍક્સેસ નથી, તો તમારે અધિકૃતતા પ્રક્રિયામાંથી પસાર થવાની જરૂર છે. અહીં, સરળતા માટે, તે સમાન લક્ષણમાં પાથના ભાગ તરીકે દર્શાવવામાં આવ્યું છે, જો કે તે લોગિન પૃષ્ઠ પરનું સંક્રમણ છે. હકારાત્મક પરિસ્થિતિના કિસ્સામાં, અમે યોગ્ય રીતે પૂર્ણ થયેલ સત્ર મેળવીશું અને બેકઓફિસ કંટ્રોલર પર જઈશું.
3. જો ત્યાં ડેટા છે, તો તમારે તેને વપરાશકર્તા આધારમાં સુસંગતતા માટે તપાસવાની જરૂર છે. શું તેની ભૂમિકા બદલાઈ ગઈ છે, શું તેને હવે પેજ પર મંજૂરી ન આપવી જોઈએ? આ કિસ્સામાં, સત્ર (1) પ્રાપ્ત કર્યા પછી, તમારે સીધા ડેટાબેઝ પર જવાની જરૂર છે અને પ્રમાણીકરણ તર્ક સ્તર (2) નો ઉપયોગ કરીને વપરાશકર્તાની ઍક્સેસ તપાસો. આગળ, ક્યાં તો લૉગિન પેજ પર, અથવા કંટ્રોલર પર જાઓ. આવી સરળ સિસ્ટમ, પરંતુ તદ્દન પ્રમાણભૂત નથી.
4. જો બધી પ્રક્રિયાઓ પસાર થઈ જાય, તો પછી અમે નિયંત્રકો અને પદ્ધતિઓમાં તર્કમાં આગળ વધીએ છીએ.

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

BANAVU. તેથી તેઓએ કર્યું:

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

પ્રમાણીકરણ સેવા અને તેની સાથે, ઉપકરણ સેવાનો ઉપયોગ બેક ઑફિસ માટે થાય છે, એટલે કે, ઉત્પાદનમાં ઉપયોગમાં લેવાતી સેવાઓ અને ઇન્ટરફેસ માટે. ક્લાયંટ સેવાઓ (જેમ કે વેબસાઇટ અથવા મોબાઇલ એપ્લિકેશન) માટે પ્રમાણીકરણ પ્રમાણીકરણનો ઉપયોગ કર્યા વિના અલગથી થાય છે. અલગ થવામાં લગભગ એક વર્ષનો સમય લાગ્યો, અને હવે અમે ફરીથી આ વિષય સાથે કામ કરી રહ્યા છીએ, સિસ્ટમને નવી પ્રમાણીકરણ સેવાઓ (માનક પ્રોટોકોલ સાથે) પર સ્થાનાંતરિત કરી રહ્યા છીએ.

અલગ થવામાં આટલો સમય કેમ લાગ્યો?
રસ્તામાં ઘણી સમસ્યાઓ હતી જેણે અમને ધીમું કર્યું:

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

પિઝેરિયામાં ઉપકરણ નોંધણી યોજના:

પ્રમાણીકરણ અને ઉપકરણો સેવાના નિષ્કર્ષણ પછી સામાન્ય આર્કિટેક્ચર:

નોંધણી. 2020 માટે, અમે Auth ના નવા સંસ્કરણ પર કામ કરી રહ્યા છીએ, જે OAuth 2.0 અધિકૃતતા ધોરણ પર આધારિત છે. આ ધોરણ તદ્દન જટિલ છે, પરંતુ તે પાસ-થ્રુ પ્રમાણીકરણ સેવા વિકસાવવા માટે ઉપયોગી છે. લેખમાં "અધિકૃતતાની સૂક્ષ્મતા: OAuth 2.0 તકનીકની ઝાંખી» અમે એલેક્સી ચેર્નાયેવે ધોરણ વિશે શક્ય તેટલું સરળ અને સ્પષ્ટ રીતે કહેવાનો પ્રયાસ કર્યો જેથી તમે તેનો અભ્યાસ કરવામાં સમય બચાવી શકો.

ટ્રેકર શું કરે છે?

હવે લોડ કરેલી સેવાઓના બીજા વિશે. ટ્રેકર દ્વિ ભૂમિકા ભજવે છે:

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

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

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

ટ્રેકર "રસ્કટકા" ના સ્ટેશન પર ટેબ્લેટની સ્ક્રીન આ રીતે દેખાય છે

ભાર ક્યાંથી આવે છે?

દરેક પિઝેરિયામાં ટ્રેકર સાથે લગભગ પાંચ ટેબ્લેટ હોય છે. 2016 માં, અમારી પાસે 100 થી વધુ પિઝેરિયા હતા (અને હવે 600 થી વધુ). દરેક ટેબ્લેટ દર 10 સેકન્ડમાં એકવાર બેકએન્ડને વિનંતી કરે છે અને ઓર્ડર ટેબલમાંથી ડેટા સ્ક્રેપ કરે છે (ક્લાયન્ટ અને સરનામા સાથેનું જોડાણ), ઓર્ડર કમ્પોઝિશન (ઉત્પાદન સાથે જોડાણ અને જથ્થાના સંકેત), પ્રેરણા એકાઉન્ટિંગ ટેબલ (આ દબાવવાનો સમય તેમાં ટ્રેક કરવામાં આવે છે). જ્યારે પિઝા મેકર ટ્રેકર પરના ઉત્પાદન પર ક્લિક કરે છે, ત્યારે આ તમામ કોષ્ટકોની એન્ટ્રી અપડેટ થાય છે. ઓર્ડર ટેબલ સામાન્ય છે, તેમાં ઓર્ડર સ્વીકારતી વખતે ઇન્સર્ટ્સ, સિસ્ટમના અન્ય ભાગોમાંથી અપડેટ્સ અને અસંખ્ય રીડિંગ્સ પણ શામેલ છે, ઉદાહરણ તરીકે, ટીવી પર જે પિઝેરિયામાં અટકી જાય છે અને ગ્રાહકોને સમાપ્ત ઓર્ડર બતાવે છે.

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

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

ડબલ્યુએએસ. મૂળ આર્કિટેક્ચર હતું:

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

અનલોડિંગ ટ્રેકર

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

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

ઓર્ડરની સ્થિતિ બદલવા માટેની યોજના આના જેવી લાગે છે:

વિવિધ સિસ્ટમો વચ્ચે સ્થિતિ બદલાય છે. અને અહીં ટ્રેકર એ અંતિમ સિસ્ટમ નથી જેમાં ડેટા બંધ છે. અમે આવા કિસ્સામાં પાર્ટીશન કરવા માટેના ઘણા સંભવિત અભિગમો જોયા છે:

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

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

તે સમય સુધીમાં, અમારી પાસે પહેલાથી જ સ્ટેકમાં RabbitMQ હતું, તેથી તેનો સંદેશ બ્રોકર તરીકે ઉપયોગ કરવાનો અંતિમ નિર્ણય. ડાયાગ્રામ રેસ્ટોરન્ટ કેશિયર તરફથી ટ્રેકર દ્વારા ઓર્ડરનું સંક્રમણ દર્શાવે છે, જ્યાં તે તેની સ્થિતિ અને મેનેજરના ઓર્ડર ઇન્ટરફેસ પર તેનું પ્રદર્શન બદલે છે. BANAVU:

ઓર્ડર પાથ પગલું દ્વારા પગલું
ઓર્ડર પાથ ઓર્ડર સ્ત્રોત સેવાઓમાંથી એકથી શરૂ થાય છે. અહીં રેસ્ટોરન્ટના કેશિયર છે:

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

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

અન્ય તમામ સેવાઓ તેમના પોતાના માટે ઉપયોગ કરવા માટે ટ્રેકરમાંથી ઑર્ડર ઇવેન્ટ્સ માટે સબ્સ્ક્રાઇબ પણ કરી શકે છે.

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

ઓથ અને ટ્રેકરમાં ફેરફારો પછી અંતિમ આર્કિટેક્ચર

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

આવી સામગ્રીના ફાયદાઓ (અથવા તેના અભાવ) પર પ્રતિબિંબિત કરતા, હું નિષ્કર્ષ પર પહોંચ્યો કે ઘટનાઓની સંપૂર્ણ વિગતો, વિગતવાર પૂર્વદર્શન અને મારા ભૂતકાળના નિર્ણયોના વિશ્લેષણ વિના સતત વિકાસ અશક્ય છે.

હું આશા રાખું છું કે અમારા પાથ વિશે શીખવું તમારા માટે ઉપયોગી અને રસપ્રદ હતું. હવે હું આગળના લેખમાં ડોડો IS સિસ્ટમના કયા ભાગનું વર્ણન કરું તે પસંદગીનો સામનો કરી રહ્યો છું: ટિપ્પણીઓમાં લખો અથવા મત આપો.

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

આગળના લેખમાં તમે ડોડો ISના કયા ભાગ વિશે જાણવા માગો છો?

• 24,1%ડોડો IS (2011-2015)14 માં પ્રારંભિક મોનોલિથ

• 24,1%પ્રથમ સમસ્યાઓ અને તેના ઉકેલો (2015-2016)14

• 20,7%ક્લાયંટ ભાગનો માર્ગ: આધારની ઉપરનો રવેશ (2016-2017)12

• 36,2%વાસ્તવિક માઇક્રોસર્વિસિસનો ઇતિહાસ (2018-2019)21

• 44,8%મોનોલિથનું સંપૂર્ણ સોઇંગ અને આર્કિટેક્ચરનું સ્થિરીકરણ26

• 29,3%સિસ્ટમના વિકાસ માટેની વધુ યોજનાઓ વિશે17

• 19,0%હું ડોડો IS11 વિશે કંઈપણ જાણવા માંગતો નથી

58 વપરાશકર્તાઓએ મતદાન કર્યું. 6 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com