મોનોલિથથી માઇક્રોસર્વિસિસમાં સંક્રમણ: ઇતિહાસ અને પ્રેક્ટિસ

આ લેખમાં, હું જે પ્રોજેક્ટ પર કામ કરી રહ્યો છું તે કેવી રીતે મોટા મોનોલિથમાંથી માઇક્રોસર્વિસિસના સમૂહમાં રૂપાંતરિત થયું તે વિશે વાત કરીશ.

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

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

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

અનુક્રમણિકા

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

આર્કિટેક્ચર અને હાલના ઉકેલની સમસ્યાઓ

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

અગાઉના ઉકેલના ગેરફાયદા

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

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

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

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

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

માઇક્રોસર્વિસિસ પાસેથી અપેક્ષાઓ

જ્યારે તૈયાર થાય ત્યારે ઘટકોનો મુદ્દો. દ્રાવણને વિઘટન કરીને અને વિવિધ પ્રક્રિયાઓને અલગ કરીને ઘટકોની ડિલિવરી જ્યારે તૈયાર હોય.

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

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

જમાવટ સુગમતા. અમે સેવાઓને જે રીતે તેની જરૂર છે તે રીતે જોડવા માંગીએ છીએ, અને કોડ તેને દબાણ કરે છે તે રીતે નહીં.

નવી ટેકનોલોજીનો ઉપયોગ. આ કોઈપણ પ્રોગ્રામર માટે રસપ્રદ છે.

સંક્રમણ સમસ્યાઓ

અલબત્ત, જો મોનોલિથને માઇક્રોસર્વિસિસમાં તોડવાનું સરળ હોત, તો પરિષદોમાં તેના વિશે વાત કરવાની અને લેખો લખવાની જરૂર ન હોત. આ પ્રક્રિયામાં ઘણી મુશ્કેલીઓ છે; હું મુખ્ય મુદ્દાઓનું વર્ણન કરીશ જેણે અમને અવરોધ્યા.

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

કામની શરૂઆતના સમયે, રિપોઝીટરીમાં 500 થી વધુ પ્રોજેક્ટ્સ અને કોડની 700 હજારથી વધુ લાઇન હતી. આ ઘણો મોટો નિર્ણય છે અને બીજી સમસ્યા. તેને ખાલી લેવું અને તેને માઇક્રોસર્વિસિસમાં વિભાજીત કરવું શક્ય ન હતું.

ત્રીજી સમસ્યા - જરૂરી ઈન્ફ્રાસ્ટ્રક્ચરનો અભાવ. વાસ્તવમાં, અમે સર્વર્સ પર સોર્સ કોડની મેન્યુઅલી નકલ કરી રહ્યા હતા.

મોનોલિથથી માઇક્રોસર્વિસિસમાં કેવી રીતે ખસેડવું

માઇક્રોસર્વિસિસની જોગવાઈ

સૌપ્રથમ, અમે તરત જ અમારા માટે નક્કી કર્યું કે માઇક્રોસર્વિસિસનું વિભાજન એ પુનરાવર્તિત પ્રક્રિયા છે. અમારે હંમેશા સમાંતરમાં વ્યાપારી સમસ્યાઓ વિકસાવવાની જરૂર હતી. અમે આને તકનીકી રીતે કેવી રીતે અમલમાં મૂકીશું તે પહેલેથી જ અમારી સમસ્યા છે. તેથી, અમે પુનરાવર્તિત પ્રક્રિયા માટે તૈયાર છીએ. જો તમારી પાસે મોટી એપ્લિકેશન હોય અને તે શરૂઆતમાં ફરીથી લખવા માટે તૈયાર ન હોય તો તે અન્ય કોઈપણ રીતે કામ કરશે નહીં.

માઇક્રોસર્વિસિસને અલગ કરવા માટે આપણે કઈ પદ્ધતિઓનો ઉપયોગ કરીએ છીએ?

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

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

હોસ્ટ સાથે એસેમ્બલી એ પ્રોગ્રામ ક્લાસમાં કોડની માત્ર એક લાઇન છે. અમે સહાયક વર્ગમાં ટોપશેલ્ફ સાથે કામ છુપાવ્યું.

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

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

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

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

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

વાસ્તવિક UI તર્ક ફક્ત છેલ્લી બે લીટીઓમાં જ છે. અમે તેને સર્વર પર સ્થાનાંતરિત કર્યું છે જેથી કરીને તેનો પુનઃઉપયોગ કરી શકાય, ત્યાંથી UI ઘટાડીને યોગ્ય આર્કિટેક્ચર પ્રાપ્ત કરી શકાય.

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

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

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

આ બાઉન્ડેડ સંદર્ભોને એકબીજાથી અલગ કરવા અને માઇક્રોસર્વિસિસને મોનોલિથિક સોલ્યુશનથી અલગ કરવાની પ્રક્રિયા શરૂ કરવા માટે, અમે એપ્લિકેશનમાં બાહ્ય API બનાવવા જેવા અભિગમનો ઉપયોગ કર્યો. જો આપણે જાણતા હોઈએ કે અમુક મોડ્યુલ માઇક્રોસર્વિસ બનવું જોઈએ, જે પ્રક્રિયામાં કોઈક રીતે સંશોધિત કરવામાં આવે છે, તો અમે તરત જ બાહ્ય કૉલ્સ દ્વારા અન્ય મર્યાદિત સંદર્ભ સાથે સંબંધિત લોજિક પર કૉલ્સ કર્યા. ઉદાહરણ તરીકે, REST અથવા WCF દ્વારા.

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

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

જો ડેટાના ભાગને સતત સાચવવા માટે જરૂરી હોય ત્યારે પરિસ્થિતિ ઊભી થાય, તો અમે સંભવતઃ એક પ્રક્રિયામાં તેની પ્રક્રિયા કરવા માટે સેવાના એકીકરણ માટે જઈશું.

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

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

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

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

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

ડેટાબેઝ સાથે કામ કરવું

ડેટાબેઝને સ્રોત કોડ કરતાં વધુ ખરાબ રીતે વિભાજિત કરી શકાય છે, કારણ કે તેમાં માત્ર વર્તમાન સ્કીમા જ નથી, પણ સંચિત ઐતિહાસિક ડેટા પણ છે.

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

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

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

અમે ડેટાબેઝ પાર્ટીશનની બે વૈશ્વિક પદ્ધતિઓનો ઉપયોગ કર્યો: હાલના કોષ્ટકોનું પાર્ટીશન અને પ્રોસેસિંગ સાથે પાર્ટીશન.

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

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

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

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

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

પછીથી અમે આ કનેક્શનને દૂર કરીશું, એટલે કે, વિભાજિત કોષ્ટકોમાંથી મોનોલિથિક એપ્લિકેશનમાંથી વાંચન ડેટા પણ API માં સ્થાનાંતરિત કરવામાં આવશે.

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

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

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

આ યોજના કામ કરવા માટે, અમને સંક્રમણ સમયગાળાની જરૂર પડશે.

પછી બે સંભવિત અભિગમો છે.

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

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

બંને અભિગમો કામ કરે છે, પરિસ્થિતિના આધારે પસંદ કરો.

બધું કામ કરે છે તેની ખાતરી કર્યા પછી, જૂના ડેટાબેઝ સ્ટ્રક્ચર્સ સાથે કામ કરતા મોનોલિથનો ભાગ અક્ષમ થઈ શકે છે.

છેલ્લું પગલું જૂના ડેટા સ્ટ્રક્ચર્સને દૂર કરવાનું છે.

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

સ્ત્રોત કોડ સાથે કામ

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

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

અમે ભાગ્યશાળી હતા કે ઇન્ફ્રાસ્ટ્રક્ચર લાઇબ્રેરીઓનો અલગથી ઉપયોગ કરી શકાય.

કેટલીકવાર એવી પરિસ્થિતિ ઊભી થાય છે જ્યારે કેટલીક સામાન્ય વસ્તુઓ ખરેખર આ સ્તરની ન હતી, પરંતુ ઇન્ફ્રાસ્ટ્રક્ચર લાઇબ્રેરીઓ હતી. આ નામ બદલીને ઉકેલવામાં આવ્યું હતું.

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

અમે કોડ વિભાજન પ્રક્રિયા માટે ઘણા નિયમો ઘડ્યા છે.

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

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

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

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

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

આમ, સોર્સ કોડ પર કામ કરીને, આર્કિટેક્ચરમાં થોડો ફેરફાર કરીને અને રિપોઝીટરીઝને અલગ કરીને, અમે અમારી સેવાઓને વધુ સ્વતંત્ર બનાવીએ છીએ.

ઈન્ફ્રાસ્ટ્રક્ચર સમસ્યાઓ

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

વાતાવરણમાં મેન્યુઅલ ઇન્સ્ટોલેશન

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

અમે સોર્સ કોડ સ્ટોરેજ માટે એટલાસિયન, બિટબકેટ અને બિલ્ડિંગ માટે વાંસનો ઉપયોગ કરીએ છીએ. અમને કેકમાં બિલ્ડ સ્ક્રિપ્ટ લખવાનું ગમે છે કારણ કે તે C# જેવું જ છે. તૈયાર પેકેજો આર્ટિફેક્ટરીમાં આવે છે, અને Ansible ઑટોમૅટિક રીતે ટેસ્ટ સર્વર્સ પર પહોંચે છે, જેના પછી તેનું તરત જ પરીક્ષણ કરી શકાય છે.

અલગ લોગીંગ

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

Filebeat નો ઉપયોગ કરીને, અમને સર્વર્સમાંથી અમારા લોગ એકત્રિત કરવાની તક મળે છે, પછી તેને રૂપાંતરિત કરવાની, UI માં ક્વેરી બનાવવા માટે કિબાનાનો ઉપયોગ કરવાની અને સેવાઓ વચ્ચે કૉલ કેવી રીતે થયો તે જોવાની તક મળે છે. ટ્રેસ ID આમાં ઘણી મદદ કરે છે.

સંબંધિત સેવાઓનું પરીક્ષણ અને ડિબગીંગ

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

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

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

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

આપણે શું હાંસલ કર્યું છે?

પ્રથમ, અમે "પ્રકાશન" ની વિભાવનાથી છુટકારો મેળવ્યો. જ્યારે આ કોલોસસને ઉત્પાદન વાતાવરણમાં તૈનાત કરવામાં આવ્યું હતું ત્યારે બે મહિનાની ભયંકર પ્રકાશનો ગઈ હતી, અસ્થાયી રૂપે વ્યવસાય પ્રક્રિયાઓને અવરોધે છે. હવે અમે સરેરાશ દર 1,5 દિવસે સેવાઓ જમાવીએ છીએ, તેમને જૂથબદ્ધ કરીએ છીએ કારણ કે તેઓ મંજૂરી પછી કાર્યરત થાય છે.

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

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

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

સારાંશ

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

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

  PS વધુ ભાવનાત્મક વાર્તા (અને જાણે તમારા માટે વ્યક્તિગત રીતે) - અનુસાર કડી.
  અહીં રિપોર્ટનું સંપૂર્ણ સંસ્કરણ છે.

સોર્સ: www.habr.com