ከሞኖሊት ወደ ማይክሮ ሰርቪስ ሽግግር: ታሪክ እና ልምምድ

በዚህ ጽሑፍ ውስጥ የምሰራው ፕሮጀክት ከትልቅ ሞኖሊት ወደ ማይክሮ ሰርቪስ ስብስብ እንዴት እንደተለወጠ እናገራለሁ.

ፕሮጀክቱ ታሪኩን የጀመረው ከረጅም ጊዜ በፊት ማለትም በ 2000 መጀመሪያ ላይ ነው. የመጀመሪያዎቹ ስሪቶች የተፃፉት በቪዥዋል ቤዚክ 6 ነው. በጊዜ ሂደት, በዚህ ቋንቋ እድገትን ወደፊት ለመደገፍ አስቸጋሪ እንደሚሆን ግልጽ ሆነ, ከ IDE ጀምሮ. እና ቋንቋው ራሱ በደንብ ያልዳበረ ነው። በ 2000 ዎቹ መገባደጃ ላይ ወደ የበለጠ ተስፋ ሰጪ C # ለመቀየር ተወስኗል. አዲሱ እትም ከአሮጌው ክለሳ ጋር በትይዩ ተጽፎ ነበር፣ ቀስ በቀስ ተጨማሪ ኮድ በ NET ተጽፏል። በ C # ውስጥ ያለው የጀርባ አሠራር መጀመሪያ ላይ በአገልግሎት አርክቴክቸር ላይ ያተኮረ ነበር፣ ነገር ግን በዕድገት ወቅት፣ ሎጂክ ያላቸው የጋራ ቤተ-መጻሕፍት ጥቅም ላይ ውለው ነበር፣ እና አገልግሎቶች በአንድ ሂደት ተጀመሩ። ውጤቱም “አገልግሎት ሞኖሊት” ብለን የጠራነው መተግበሪያ ነበር።

የዚህ ጥምረት ጥቂቶቹ ጥቅሞች አንዱ አገልግሎቶች በውጫዊ ኤፒአይ በኩል እርስ በርስ መደወል መቻላቸው ነው። ወደ ትክክለኛ አገልግሎት ለመሸጋገር ግልጽ ቅድመ ሁኔታዎች ነበሩ፣ እና ወደፊት ደግሞ የማይክሮ አገልግሎት አርክቴክቸር።

በ2015 አካባቢ የመበስበስ ስራችንን ጀመርን። እስካሁን ጥሩ ደረጃ ላይ አልደረስንም - አሁንም የአንድ ትልቅ ፕሮጀክት ክፍሎች አሉ monoliths ተብለው ሊጠሩ የማይችሉት ፣ ግን እነሱም ማይክሮ አገልግሎት አይመስሉም። ቢሆንም፣ መሻሻል ጉልህ ነው።
በጽሁፉ ውስጥ ስለ እሱ እናገራለሁ.

ይዘቶች

• የነባሩ መፍትሔ አርክቴክቸር እና ችግሮች
• ከማይክሮ አገልግሎቶች የሚጠበቁ ነገሮች
• የሽግግር ችግሮች
• ከሞኖሊት ወደ ማይክሮ ሰርቪስ እንዴት እንደሚንቀሳቀስ
  • የመጀመሪያው መንገድ
  • ሁለተኛው መንገድ
  • ሦስተኛው መንገድ
  • አራተኛው መንገድ
• ከመረጃ ቋቱ ጋር በመስራት ላይ
  • ያሉትን ጠረጴዛዎች መከፋፈል
  • የማቀነባበሪያ ክፍል
• ከምንጭ ኮድ ጋር በመስራት ላይ
• የመሠረተ ልማት ችግሮች
  • በአካባቢ ውስጥ በእጅ መጫን
  • የተለየ ምዝግብ ማስታወሻ
  • ተዛማጅ አገልግሎቶችን መሞከር እና ማረም

የነባሩ መፍትሔ አርክቴክቸር እና ችግሮች

መጀመሪያ ላይ አርክቴክቸር ይህን ይመስላል፡ ዩአይ የተለየ አፕሊኬሽን ነው፣ አሃዳዊው ክፍል የተፃፈው በ Visual Basic 6 ነው፣ .NET መተግበሪያ ከትልቅ የውሂብ ጎታ ጋር የሚሰሩ ተዛማጅ አገልግሎቶች ስብስብ ነው።

የቀደመው መፍትሔ ጉዳቶች

ነጠላ የውድቀት ነጥብ
አንድ ነጠላ የውድቀት ነጥብ ነበረብን፡ የ .NET አፕሊኬሽን የሚሰራው በአንድ ሂደት ነው። ማንኛውም ሞጁል ካልተሳካ፣ አፕሊኬሽኑ በሙሉ አልተሳካም እና እንደገና መጀመር ነበረበት። ለተለያዩ ተጠቃሚዎች ብዙ ቁጥር ያላቸውን ሂደቶች በራስ-ሰር ስለምንሰራ ከመካከላቸው በአንዱ ውድቀት ምክንያት ሁሉም ሰው ለተወሰነ ጊዜ መሥራት አልቻለም። እና የሶፍትዌር ስህተት ከሆነ, ምትኬ እንኳን አልረዳም.

የማሻሻያ ወረፋ
ይህ ጉድለት ድርጅታዊ ነው። የእኛ መተግበሪያ ብዙ ደንበኞች አሉት፣ እና ሁሉም በተቻለ ፍጥነት ማሻሻል ይፈልጋሉ። ከዚህ በፊት, ይህንን በትይዩ ማድረግ የማይቻል ነበር, እና ሁሉም ደንበኞች በመስመር ላይ ቆመው ነበር. ይህ ሂደት ለንግዶች አሉታዊ ነበር ምክንያቱም ተግባራቸው ጠቃሚ መሆኑን ማረጋገጥ ነበረባቸው። እናም የልማቱ ቡድን ይህንን ወረፋ በማዘጋጀት ጊዜ አሳልፏል። ይህ ብዙ ጊዜ እና ጥረት ወስዷል፣ እና ምርቱ በመጨረሻ የሚወዱትን ያህል በፍጥነት መለወጥ አልቻለም።

ዝቅተኛ ጥራት ያለው የሀብቶች አጠቃቀም
በአንድ ሂደት ውስጥ አገልግሎቶችን ስናስተናግድ፣ ሁልጊዜ አወቃቀሩን ከአገልጋይ ወደ አገልጋይ እንቀዳለን። ሀብቶችን እንዳናባክን እና በተሰማራበት እቅዳችን ላይ የበለጠ ተለዋዋጭ ቁጥጥር እንዳንገኝ በጣም የተጫኑ አገልግሎቶችን ለየብቻ ማስቀመጥ እንፈልጋለን።

ዘመናዊ ቴክኖሎጂዎችን ለመተግበር አስቸጋሪ ነው
ለሁሉም ገንቢዎች የታወቀ ችግር: ዘመናዊ ቴክኖሎጂዎችን ወደ ፕሮጀክቱ የማስተዋወቅ ፍላጎት አለ, ግን ምንም ዕድል የለም. በትልቅ አሃዳዊ መፍትሄ፣ ማንኛውም የአሁኑ ቤተ-መጽሐፍት ማሻሻያ፣ ወደ አዲስ መሸጋገሩን ሳይጠቅስ፣ ወደ ተራ ያልሆነ ተግባር ይቀየራል። ይህ ከሚባክኑ ነርቮች የበለጠ ጉርሻ እንደሚያመጣ ለቡድኑ መሪ ለማረጋገጥ ብዙ ጊዜ ይወስዳል።

ለውጦችን ለማውጣት አስቸጋሪነት
ይህ በጣም አሳሳቢው ችግር ነበር - በየሁለት ወሩ ልቀቶችን እንለቅቅ ነበር።
ምንም እንኳን የገንቢዎቹ ሙከራ እና ጥረቶች ቢኖሩም እያንዳንዱ ልቀት ለባንኩ እውነተኛ አደጋ ሆነ። ንግዱ በሳምንቱ መጀመሪያ ላይ አንዳንድ ተግባሮቹ እንደማይሰሩ ተረድቷል። እና ገንቢዎቹ የአንድ ሳምንት ከባድ ክስተቶች እንደሚጠብቋቸው ተረድተዋል።
ሁሉም ሰው ሁኔታውን ለመለወጥ ፍላጎት ነበረው.

ከማይክሮ አገልግሎቶች የሚጠበቁ ነገሮች

ዝግጁ ሲሆኑ የንጥረ ነገሮች ጉዳይ. መፍትሄውን በመበስበስ እና የተለያዩ ሂደቶችን በመለየት ዝግጁ በሚሆንበት ጊዜ ክፍሎችን ማቅረቡ.

አነስተኛ የምርት ቡድኖች. ይህ አስፈላጊ ነው ምክንያቱም በአሮጌው ሞኖሊት ላይ የሚሰራ ትልቅ ቡድን ለማስተዳደር አስቸጋሪ ነበር. እንዲህ ዓይነቱ ቡድን ጥብቅ በሆነ አሠራር መሠረት እንዲሠራ ተገድዷል, ነገር ግን የበለጠ ፈጠራ እና ነፃነትን ይፈልጋሉ. ይህንን መግዛት የሚችሉት ትናንሽ ቡድኖች ብቻ ነበሩ።

በተለየ ሂደቶች ውስጥ አገልግሎቶችን ማግለል. በሐሳብ ደረጃ፣ በኮንቴይነሮች ውስጥ መለየት እፈልጋለሁ፣ ነገር ግን በ.NET Framework ውስጥ የተጻፉ ብዙ አገልግሎቶች ከሚከተሉት በታች ብቻ ይሰራሉ Windowsበ.NET Core ላይ የተመሰረቱ አገልግሎቶች አሁን እየታዩ ነው፣ ነገር ግን አሁንም ጥቂቶቹ ናቸው።

የመዘርጋት ተለዋዋጭነት. አገልግሎቶችን በምንፈልገው መንገድ ማዋሃድ እንፈልጋለን፣ እና ኮዱ በሚያስገድድበት መንገድ አይደለም።

አዳዲስ ቴክኖሎጂዎችን መጠቀም. ይህ ለማንኛውም ፕሮግራመር የሚስብ ነው።

የሽግግር ችግሮች

በእርግጥ ሞኖሊትን ወደ ማይክሮ ሰርቪስ መስበር ቀላል ቢሆን ኖሮ በኮንፈረንስ ላይ ስለ እሱ ማውራት እና መጣጥፎችን መጻፍ አያስፈልግም ነበር። በዚህ ሂደት ውስጥ ብዙ ወጥመዶች አሉ፤ ዋና ዋናዎቹን እንቅፋት የሆኑትን እገልጻለሁ።

የመጀመሪያው ችግር ለአብዛኞቹ ሞኖሊቶች የተለመደ፡ የንግድ ሎጂክ ወጥነት። ሞኖሊት ስንጽፍ አላስፈላጊ ኮድ ላለመጻፍ ክፍሎቻችንን እንደገና መጠቀም እንፈልጋለን። እና ወደ ማይክሮ ሰርቪስ በሚንቀሳቀሱበት ጊዜ ይህ ችግር ይሆናል-ሁሉም ኮዶች በጥብቅ የተጣመሩ ናቸው, እና አገልግሎቶቹን ለመለየት አስቸጋሪ ነው.

ሥራው በተጀመረበት ጊዜ ማከማቻው ከ 500 በላይ ፕሮጀክቶች እና ከ 700 ሺህ በላይ የኮድ መስመሮች ነበሩት. ይህ በጣም ትልቅ ውሳኔ ነው እና ሁለተኛ ችግር. በቀላሉ ወስዶ ወደ ማይክሮ ሰርቪስ መከፋፈል አልተቻለም።

ሦስተኛው ችግር - አስፈላጊ የመሠረተ ልማት እጥረት. እንደውም የምንጭ ኮዱን ወደ አገልጋዮቹ በእጅ እየገለበጥን ነበር።

ከሞኖሊት ወደ ማይክሮ ሰርቪስ እንዴት እንደሚንቀሳቀስ

ጥቃቅን አገልግሎቶችን መስጠት

በመጀመሪያ ፣ ማይክሮ ሰርቪስ መለያየት ተደጋጋሚ ሂደት መሆኑን ወዲያውኑ ለራሳችን ወስነናል። ሁልጊዜም የንግድ ችግሮችን በትይዩ እንድናዳብር ይጠበቅብናል። ይህንን በቴክኒክ እንዴት እንደምንተገብረው ቀድሞውንም ችግራችን ነው። ስለዚህ, ለተደጋጋሚ ሂደት አዘጋጅተናል. ትልቅ መተግበሪያ ካለዎት እና እንደገና ለመፃፍ መጀመሪያ ላይ ካልሆነ በሌላ መንገድ አይሰራም።

ማይክሮ አገልግሎቶችን ለመለየት ምን ዘዴዎችን እንጠቀማለን?

የመጀመሪያው መንገድ - ነባር ሞጁሎችን እንደ አገልግሎት ያንቀሳቅሱ። በዚህ ረገድ, እድለኞች ነበርን: የ WCF ፕሮቶኮልን በመጠቀም የሚሰሩ ቀደም ሲል የተመዘገቡ አገልግሎቶች ነበሩ. ወደ ተለያዩ ጉባኤዎች ተለያይተዋል። በየግንባታው ላይ ትንሽ ማስጀመሪያ ጨምረናቸው ለየብቻ አስቀመጥናቸው። መተግበሪያውን እንደ አገልግሎት እና እንደ ኮንሶል ለማሄድ የሚያስችለውን አስደናቂውን Topshelf ላይብረሪ በመጠቀም ነው የተጻፈው። በመፍትሔው ውስጥ ምንም ተጨማሪ ፕሮጀክቶች ስለሌለ ይህ ለማረም ምቹ ነው.

አገልግሎቶቹ የተገናኙት በቢዝነስ አመክንዮ መሰረት ነው፣ ምክንያቱም የጋራ ስብሰባዎችን ስለሚጠቀሙ እና ከጋራ ዳታቤዝ ጋር ይሰሩ ነበር። በንጹህ መልክቸው ማይክሮ ሰርቪስ ተብለው ሊጠሩ አይችሉም። ሆኖም፣ እነዚህን አገልግሎቶች በተናጥል በተለያዩ ሂደቶች ልንሰጥ እንችላለን። ይህም ብቻ እርስ በርስ ያላቸውን ተጽዕኖ ለመቀነስ አስችሏል, ትይዩ ልማት እና አንድ ነጠላ ነጥብ ውድቀት ጋር ያለውን ችግር በመቀነስ.

ከአስተናጋጁ ጋር መሰብሰብ በፕሮግራሙ ክፍል ውስጥ አንድ የኮድ መስመር ብቻ ነው። ከ Topshelf ጋር በረዳት ክፍል ውስጥ ሥራን ደበቅን።

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

       }
    }
}

ማይክሮ አገልግሎቶችን ለመመደብ ሁለተኛው መንገድ- አዳዲስ ችግሮችን ለመፍታት ይፍጠሩ. በተመሳሳይ ጊዜ ሞኖሊቱ ካላደገ, ይህ ቀድሞውኑ በጣም ጥሩ ነው, ይህም ማለት በትክክለኛው አቅጣጫ እንጓዛለን ማለት ነው. አዳዲስ ችግሮችን ለመፍታት የተለየ አገልግሎት ለመፍጠር ሞክረናል። እንደዚህ አይነት እድል ካለ, ከዚያም የራሳቸውን የውሂብ ሞዴል, የተለየ የውሂብ ጎታ ሙሉ በሙሉ የሚያስተዳድሩ ተጨማሪ "ቀኖናዊ" አገልግሎቶችን ፈጠርን.

እኛ፣ ልክ እንደ ብዙዎቹ፣ በማረጋገጫ እና በፈቀዳ አገልግሎቶች ጀምረናል። ለዚህ ተስማሚ ናቸው. እነሱ ገለልተኛ ናቸው, እንደ አንድ ደንብ, የተለየ የውሂብ ሞዴል አላቸው. እነሱ ራሳቸው ከ monolith ጋር አይገናኙም, አንዳንድ ችግሮችን ለመፍታት ወደ እነርሱ ብቻ ይመለሳሉ. እነዚህን አገልግሎቶች በመጠቀም ወደ አዲስ አርክቴክቸር ሽግግር መጀመር፣ መሠረተ ልማቱን በእነሱ ላይ ማረም፣ ከአውታረ መረብ ቤተ መጻሕፍት ጋር የተያያዙ አንዳንድ አቀራረቦችን መሞከር፣ ወዘተ. በድርጅታችን ውስጥ የማረጋገጫ አገልግሎት መፍጠር የማይችሉ ቡድኖች የሉንም።

ማይክሮ አገልግሎቶችን ለመመደብ ሦስተኛው መንገድየምንጠቀመው ለእኛ ትንሽ የተወሰነ ነው። ይህ የቢዝነስ አመክንዮ ከUI ንብርብር መወገድ ነው። የእኛ ዋና የዩአይ መተግበሪያ ዴስክቶፕ ነው፣ እሱ፣ ልክ እንደ ጀርባው፣ በ C # ተጽፏል። ገንቢዎቹ ከጊዜ ወደ ጊዜ ስህተቶችን ሰርተው የሎጂክ ክፍሎችን በጀርባው ውስጥ መኖር የነበረባቸውን እና እንደገና ጥቅም ላይ መዋል ያለባቸውን ወደ UI አስተላልፈዋል።

ከዩአይዩ ክፍል ኮድ ውስጥ አንድ እውነተኛ ምሳሌ ከተመለከቱ ፣ አብዛኛው የዚህ መፍትሄ የ UI ቅጽን ለመገንባት ብቻ ሳይሆን በሌሎች ሂደቶች ውስጥ ጠቃሚ የሆነ እውነተኛ የንግድ ሎጂክ እንደያዘ ማየት ይችላሉ።

ትክክለኛው የዩአይ ሎጂክ በመጨረሻዎቹ ሁለት መስመሮች ውስጥ ብቻ ነው። እንደገና ጥቅም ላይ እንዲውል ወደ አገልጋዩ አስተላልፈነዋል፣ በዚህም UI በመቀነስ ትክክለኛውን አርክቴክቸር ማሳካት እንችላለን።

ማይክሮ አገልገሎቶችን ለመለየት አራተኛው እና በጣም አስፈላጊው መንገድሞኖሊትን ለመቀነስ የሚያስችለው፣ ያሉትን አገልግሎቶች ከማቀነባበር ጋር ማስወገድ ነው። አሁን ያሉትን ሞጁሎች እንደ ሁኔታው ​​ስናወጣ ውጤቱ ሁልጊዜ ገንቢዎች አይወዱም, እና ተግባራዊነቱ ከተፈጠረ ጀምሮ የንግድ ሂደቱ ጊዜ ያለፈበት ሊሆን ይችላል. በማደስ፣ የንግድ ሥራ መስፈርቶች በየጊዜው ስለሚለዋወጡ አዲስ የሥራ ሂደት መደገፍ እንችላለን። የምንጭ ኮዱን ማሻሻል፣ የታወቁ ጉድለቶችን ማስወገድ እና የተሻለ የውሂብ ሞዴል መፍጠር እንችላለን። ብዙ ጥቅሞችን ያስገኛሉ።

አገልግሎቶችን ከማቀነባበር መለየት በማይነጣጠል ሁኔታ ከተገደበ አውድ ጽንሰ-ሀሳብ ጋር የተቆራኘ ነው። ይህ ከDomain Driven Design የመጣ ጽንሰ ሃሳብ ነው። ሁሉም የአንድ ቋንቋ ውሎች በልዩ ሁኔታ የተገለጹበት የጎራ ሞዴል ክፍል ማለት ነው። እንደ ምሳሌ የኢንሹራንስ እና የፍጆታ ሁኔታዎችን እንይ። አንድ ነጠላ መተግበሪያ አለን, እና በኢንሹራንስ ውስጥ ካለው መለያ ጋር መስራት አለብን. ገንቢው በሌላ ጉባኤ ውስጥ ያለውን የመለያ ክፍል እንዲያገኝ፣ ከኢንሹራንስ ክፍል እንዲያጣቅሰው እንጠብቃለን እና የስራ ኮድ ይኖረናል። የ DRY መርህ ይከበራል, አሁን ያለውን ኮድ በመጠቀም ስራው በፍጥነት ይከናወናል.

በውጤቱም, የመለያዎች እና የኢንሹራንስ ሁኔታዎች ተያያዥነት አላቸው. አዳዲስ መስፈርቶች ሲወጡ, ይህ ትስስር በልማት ውስጥ ጣልቃ ይገባል, ቀድሞውንም የተወሳሰበ የንግድ ሎጂክ ውስብስብነት ይጨምራል. ይህንን ችግር ለመፍታት በኮዱ ውስጥ ባሉ አውዶች መካከል ያሉትን ድንበሮች ማግኘት እና ጥሰቶቻቸውን ማስወገድ ያስፈልግዎታል. ለምሳሌ በኢንሹራንስ አውድ ውስጥ ባለ 20 አሃዝ የማዕከላዊ ባንክ መለያ ቁጥር እና መለያው የተከፈተበት ቀን በቂ ሊሆን ይችላል።

እነዚህን የታሰሩ አውዶች እርስ በርስ ለመለየት እና ጥቃቅን አገልግሎቶችን ከአንድ ነጠላ መፍትሄ የመለየት ሂደቱን ለመጀመር በመተግበሪያው ውስጥ ውጫዊ ኤፒአይዎችን መፍጠር የመሰለ ዘዴን ተጠቅመንበታል። አንዳንድ ሞጁል ማይክሮ ሰርቪስ መሆን እንዳለበት ካወቅን ፣ በሂደቱ ውስጥ በሆነ መንገድ ተስተካክሏል ፣ ከዚያ ወዲያውኑ ወደ ሌላ ውስን አውድ ወደሆነው አመክንዮ በውጫዊ ጥሪዎች ጥሪ አደረግን። ለምሳሌ፣ በREST ወይም WCF በኩል።

የተከፋፈለ ግብይቶችን የሚጠይቅ ኮድ እንዳናስወግድ ወስነናል። በእኛ ሁኔታ, ይህንን ህግ መከተል በጣም ቀላል ሆኖ ተገኝቷል. ጥብቅ የተከፋፈሉ ግብይቶች በእውነት የሚፈለጉባቸው ሁኔታዎች ገና አጋጥመውናል - በሞጁሎች መካከል ያለው የመጨረሻው ወጥነት በጣም በቂ ነው።

አንድ የተወሰነ ምሳሌ እንመልከት። የኦርኬስትራ ፅንሰ-ሀሳብ አለን - "የመተግበሪያውን" አካል የሚያስኬድ የቧንቧ መስመር. በተራ ደንበኛ፣ አካውንት እና የባንክ ካርድ ይፈጥራል። ደንበኛው እና መለያው በተሳካ ሁኔታ ከተፈጠሩ, ግን የካርድ ፈጠራው ካልተሳካ, አፕሊኬሽኑ ወደ "ስኬታማ" ሁኔታ አይንቀሳቀስም እና "ካርድ አልተፈጠረም" በሚለው ሁኔታ ውስጥ ይቆያል. ወደፊት፣ የበስተጀርባ እንቅስቃሴ ያነሳውና ይጨርሰዋል። ስርዓቱ ለተወሰነ ጊዜ ወጥነት በሌለው ሁኔታ ውስጥ ነው, ነገር ግን በአጠቃላይ በዚህ ረክተናል.

የመረጃውን የተወሰነ ክፍል በተከታታይ ማስቀመጥ በሚያስፈልግበት ጊዜ አንድ ሁኔታ ከተፈጠረ፣ አገልግሎቱን በአንድ ሂደት ለማስኬድ ወደ ማጠናከሪያነት እንሄዳለን።

ማይክሮ አገልግሎትን የመመደብ ምሳሌን እንመልከት። በአንጻራዊ ሁኔታ ደህንነቱ በተጠበቀ ሁኔታ ወደ ምርት እንዴት ማምጣት ይቻላል? በዚህ ምሳሌ ውስጥ የተለየ የስርዓቱ ክፍል አለን - የደመወዝ አገልግሎት ሞጁል ፣ ማይክሮ አገልግሎት ለመስራት የምንፈልገው ከኮድ ክፍሎች አንዱ ነው።

በመጀመሪያ ደረጃ, ኮዱን እንደገና በመጻፍ ማይክሮ አገልግሎት እንፈጥራለን. ያልተደሰትንባቸውን አንዳንድ ገጽታዎች እያሻሻልን ነው። ከደንበኛው አዲስ የንግድ መስፈርቶችን እንተገብራለን. በዩአይ እና በኋለኛው መካከል ባለው ግንኙነት ላይ የኤፒአይ ጌትዌይን እንጨምራለን፣ ይህም የጥሪ ማስተላለፍን ያቀርባል።

በመቀጠል, ይህንን ውቅረት ወደ ሥራ እንለቃለን, ነገር ግን በአብራሪ ሁኔታ ውስጥ. አብዛኛዎቹ ተጠቃሚዎቻችን አሁንም ከድሮ የንግድ ሂደቶች ጋር ይሰራሉ። ለአዲስ ተጠቃሚዎች ከአሁን በኋላ ይህን ሂደት ያልያዘ አዲስ የሞኖሊቲክ መተግበሪያ ስሪት እያዘጋጀን ነው። በመሰረቱ፣ እንደ አብራሪ ሆኖ የሚሰራ የሞኖሊት እና የማይክሮ ሰርቪስ ጥምረት አለን።

በተሳካለት አብራሪ፣ አዲሱ ውቅር በእርግጥ ሊሰራ የሚችል መሆኑን እንረዳለን፣ አሮጌውን ሞኖሊትን ከቀመር ላይ እናስወግድ እና አዲሱን ውቅር በአሮጌው መፍትሄ ምትክ መተው እንችላለን።

በአጠቃላይ፣ የአንድን ሞኖሊት ምንጭ ኮድ ለመከፋፈል ሁሉንም ነባር ዘዴዎችን እንጠቀማለን። ሁሉም የመተግበሪያውን ክፍሎች መጠን እንድንቀንስ እና ወደ አዲስ ቤተ-መጻሕፍት እንድንተረጉም ያስችሉናል, ይህም የተሻለ ምንጭ ኮድ ነው.

ከመረጃ ቋቱ ጋር በመስራት ላይ

የመረጃ ቋቱ አሁን ያለውን እቅድ ብቻ ሳይሆን የተከማቸ ታሪካዊ መረጃዎችን ስለሚይዝ ከምንጩ ኮድ በባሰ ሊከፋፈል ይችላል።

የእኛ የውሂብ ጎታ፣ ልክ እንደሌሎች ብዙ፣ ሌላ አስፈላጊ ጉድለት ነበረው - ትልቅ መጠኑ። ይህ ዳታቤዝ የተነደፈው በአንድ የሞኖሊት ውስብስብ የንግድ አመክንዮ እና በተለያዩ የተገደቡ አውዶች ሰንጠረዦች መካከል የተከማቹ ግንኙነቶች ነው።

በእኛ ሁኔታ, ሁሉንም ችግሮች (ትልቅ የውሂብ ጎታ, ብዙ ግንኙነቶች, አንዳንድ ጊዜ በጠረጴዛዎች መካከል ግልጽ ያልሆኑ ድንበሮች), በብዙ ትላልቅ ፕሮጀክቶች ውስጥ የሚከሰት ችግር ተከሰተ: የጋራ የውሂብ ጎታ አብነት አጠቃቀም. መረጃ ከሰንጠረዦች በእይታ፣ በማባዛት ተወስዷል እና ይህ ማባዛት ወደሚያስፈልገው ሌሎች ስርዓቶች ተልኳል። በውጤቱም, ሰንጠረዦቹን በንቃት ጥቅም ላይ ስለዋሉ ወደ የተለየ ንድፍ ማንቀሳቀስ አልቻልንም.

በኮዱ ውስጥ ወደ ውሱን አውዶች ያለው ተመሳሳይ ክፍፍል በመለያየት ውስጥ ይረዳናል። ብዙውን ጊዜ መረጃን በመረጃ ቋት ደረጃ እንዴት እንደምንከፋፍል ጥሩ ሀሳብ ይሰጠናል። የትኛዎቹ ሰንጠረዦች ለአንድ የታጠረ አውድ እና የትኛው ለሌላው እንደሆኑ እንረዳለን።

ሁለት ዓለም አቀፋዊ የውሂብ ጎታ ክፍፍል ዘዴዎችን ተጠቀምን-ነባር ሠንጠረዦችን መከፋፈል እና ከሂደቱ ጋር መከፋፈል.

አሁን ያሉትን ጠረጴዛዎች መከፋፈል የመረጃው መዋቅር ጥሩ ከሆነ, የንግድ ሥራ መስፈርቶችን የሚያሟላ ከሆነ እና ሁሉም ሰው በእሱ ደስተኛ ከሆነ ለመጠቀም ጥሩ ዘዴ ነው. በዚህ ሁኔታ, ያሉትን ሰንጠረዦች ወደ ተለየ ንድፍ መለየት እንችላለን.

የንግድ ሞዴሉ በከፍተኛ ሁኔታ ሲቀየር እና ሰንጠረዦቹ ከአሁን በኋላ እኛን ማርካት ሲያቅታቸው ሂደት ያለው ክፍል ያስፈልጋል።

ያሉትን ጠረጴዛዎች መከፋፈል። የምንለያይበትን መወሰን አለብን። ያለዚህ እውቀት ምንም ነገር አይሰራም, እና እዚህ በኮዱ ውስጥ የታሰሩ አውዶችን መለየት ይረዳናል. እንደ አንድ ደንብ, በምንጭ ኮድ ውስጥ የአውዶችን ድንበሮች መረዳት ከቻሉ, የትኞቹ ሰንጠረዦች ለክፍሉ ዝርዝር ውስጥ መካተት እንዳለባቸው ግልጽ ይሆናል.

ሁለት ነጠላ ሞጁሎች ከአንድ የውሂብ ጎታ ጋር የሚገናኙበት መፍትሄ እንዳለን እናስብ። አንድ ሞጁል ብቻ ከተለዩ የጠረጴዛዎች ክፍል ጋር መስተጋብር እንደሚፈጥር እና ሌላኛው በኤፒአይ በኩል ከእሱ ጋር መስተጋብር መጀመሩን ማረጋገጥ አለብን። ለመጀመር ፣ ቀረጻ ብቻ በኤፒአይ በኩል መከናወኑ በቂ ነው። ስለ ጥቃቅን አገልግሎቶች ነፃነት ለመናገር ይህ አስፈላጊ ሁኔታ ነው. ትልቅ ችግር እስካልተፈጠረ ድረስ የንባብ ግንኙነቶች ሊቆዩ ይችላሉ.

የሚቀጥለው እርምጃ ከተለዩ ጠረጴዛዎች ጋር የሚሰራውን የኮድ ክፍል ከሂደቱ ጋር ወይም ያለማቀነባበር ወደ ተለየ ማይክሮ ሰርቪስ እንለያለን እና በተለየ ሂደት, መያዣ ውስጥ እንሰራለን. ይህ ከሞኖሊት ዳታቤዝ እና ከሱ ጋር በቀጥታ የማይገናኙ ሠንጠረዦች ጋር ግንኙነት ያለው የተለየ አገልግሎት ይሆናል። ሞኖሊቱ አሁንም ለንባብ ከማይነጣጠለው ክፍል ጋር ይገናኛል።

በኋላ ላይ ይህን ግንኙነት እናስወግደዋለን፣ ማለትም፣ ከአንድ ነጠላ አፕሊኬሽን የተገኘ መረጃ ከተለያዩ ሰንጠረዦች ማንበብ ወደ ኤፒአይም ይተላለፋል።

በመቀጠል, ከአጠቃላይ የውሂብ ጎታ አዲሱ ማይክሮ አገልግሎት ብቻ የሚሰራባቸውን ሰንጠረዦች እንመርጣለን. ሰንጠረዦቹን ወደተለየ ሼማ ወይም ወደተለየ አካላዊ ዳታቤዝ ማዛወር እንችላለን። አሁንም በማይክሮ ሰርቪስ እና በሞኖሊት ዳታቤዝ መካከል የንባብ ግንኙነት አለ ፣ ግን ምንም የሚያስጨንቅ ነገር የለም ፣ በዚህ ውቅር ውስጥ ለረጅም ጊዜ ሊኖር ይችላል።

የመጨረሻው እርምጃ ሁሉንም ግንኙነቶች ሙሉ በሙሉ ማስወገድ ነው. በዚህ አጋጣሚ ከዋናው ዳታቤዝ መረጃን ማዛወር ሊያስፈልገን ይችላል። አንዳንድ ጊዜ በበርካታ የውሂብ ጎታዎች ውስጥ ከውጫዊ ስርዓቶች የተባዙ አንዳንድ መረጃዎችን ወይም ማውጫዎችን እንደገና መጠቀም እንፈልጋለን። ይህ በየጊዜው ይደርስብናል።

የማቀነባበሪያ ክፍል. ይህ ዘዴ ከመጀመሪያው ጋር በጣም ተመሳሳይ ነው, በተቃራኒው ቅደም ተከተል ብቻ. ወዲያውኑ አዲስ ዳታቤዝ እና ከሞኖሊት ጋር በኤፒአይ የሚገናኝ አዲስ ማይክሮ አገልግሎት እንመድባለን። ግን በተመሳሳይ ጊዜ, ለወደፊቱ ልንሰርዛቸው የምንፈልጋቸው የውሂብ ጎታ ሰንጠረዦች አሉ. ከአሁን በኋላ አያስፈልገንም, በአዲሱ ሞዴል ተክተነዋል.

ይህ እቅድ እንዲሰራ፣ የሽግግር ጊዜ ሊያስፈልገን ይችላል።

ከዚያ ሁለት ሊሆኑ የሚችሉ መንገዶች አሉ.

የመጀመሪያው: ሁሉንም መረጃዎች በአዲሱ እና በአሮጌ የውሂብ ጎታዎች ውስጥ እናባዛለን. በዚህ አጋጣሚ የውሂብ ድግግሞሽ አለብን እና የማመሳሰል ችግሮች ሊፈጠሩ ይችላሉ። ግን ሁለት የተለያዩ ደንበኞችን መውሰድ እንችላለን. አንዱ ከአዲሱ ስሪት ጋር, ሌላኛው ከአሮጌው ጋር ይሰራል.

ሁለተኛው: በአንዳንድ የንግድ መስፈርቶች መሰረት ውሂቡን እንከፋፍላለን. ለምሳሌ, በአሮጌው የውሂብ ጎታ ውስጥ የተከማቹ 5 ምርቶች በስርዓቱ ውስጥ ነበሩን. ስድስተኛውን በአዲሱ የንግድ ሥራ ውስጥ በአዲስ የውሂብ ጎታ ውስጥ እናስቀምጣለን. ግን ይህን ውሂብ የሚያመሳስል እና ደንበኛው ከየት እና ምን ማግኘት እንዳለበት የሚያሳይ የኤፒአይ ጌትዌይ ያስፈልገናል።

ሁለቱም አካሄዶች ይሠራሉ, እንደ ሁኔታው ​​ይምረጡ.

ሁሉም ነገር እየሰራ መሆኑን ካረጋገጥን በኋላ ከድሮ የውሂብ ጎታ አወቃቀሮች ጋር የሚሰራው የሞኖሊቱ ክፍል ሊሰናከል ይችላል።

የመጨረሻው እርምጃ የድሮውን የውሂብ አወቃቀሮችን ማስወገድ ነው.

ለማጠቃለል ያህል, በመረጃ ቋቱ ላይ ችግሮች አሉብን ማለት እንችላለን: ከምንጩ ኮድ ጋር ሲነጻጸር ከእሱ ጋር አብሮ መስራት አስቸጋሪ ነው, ለማጋራት የበለጠ ከባድ ነው, ግን ሊሠራ ይችላል እና መደረግ አለበት. ይህንን በአስተማማኝ ሁኔታ እንድናደርግ የሚያስችሉን አንዳንድ መንገዶች አግኝተናል፣ ነገር ግን ከምንጭ ኮድ ይልቅ በመረጃ ስህተት መስራት አሁንም ቀላል ነው።

ከምንጭ ኮድ ጋር በመስራት ላይ

የሞኖሊቲክ ፕሮጄክትን መተንተን ስንጀምር የምንጭ ኮድ ዲያግራም ይህን ይመስላል።

በግምት በሦስት ንብርብሮች ሊከፈል ይችላል. ይህ የተጀመሩ ሞጁሎች፣ ተሰኪዎች፣ አገልግሎቶች እና የግለሰብ እንቅስቃሴዎች ንብርብር ነው። በእውነቱ፣ እነዚህ በአንድ ነጠላ መፍትሄ ውስጥ የመግቢያ ነጥቦች ነበሩ። ሁሉም ከጋራ ንብርብር ጋር በጥብቅ ተዘግተዋል. አገልግሎቶቹ የሚጋሩት የንግድ አመክንዮ እና ብዙ ትስስር ነበረው። እያንዳንዱ አገልግሎት እና ፕለጊን እንደ መጠናቸው እና እንደ ገንቢዎቹ ሕሊና ላይ በመመስረት እስከ 10 ወይም ከዚያ በላይ የተለመዱ ስብሰባዎችን ተጠቅመዋል።

ለየብቻ ጥቅም ላይ የሚውሉ የመሠረተ ልማት ቤተ መጻሕፍት በማግኘታችን እድለኛ ነበርን።

አንዳንድ ጊዜ አንዳንድ የተለመዱ ነገሮች የዚህ ንብርብር አካል ሳይሆኑ የመሠረተ ልማት ቤተ-መጻሕፍት ሲሆኑ አንድ ሁኔታ ተከሰተ። ይህ በመሰየም ተፈታ።

ትልቁ ስጋት የታሰሩ አውዶች ነበር። በአንድ የጋራ ስብሰባ ውስጥ 3-4 አውዶች ተደባልቀው እና እርስ በእርስ በተመሳሳይ የንግድ ተግባራት ውስጥ መጠቀማቸው ተከሰተ። ይህ የት እንደሚከፋፈል እና በምን አይነት ድንበሮች እና በቀጣይ ይህንን ክፍል ወደ ምንጭ ኮድ ስብሰባዎች በማዘጋጀት ምን ማድረግ እንዳለበት መረዳት አስፈላጊ ነበር።

ለኮድ ክፍፍል ሂደት ብዙ ደንቦችን አዘጋጅተናል።

የመጀመሪያውከአሁን በኋላ በአገልግሎቶች፣ እንቅስቃሴዎች እና ተሰኪዎች መካከል የንግድ አመክንዮ ማጋራት አልፈለግንም። በማይክሮ አገልግሎቶች ውስጥ የንግድ ሎጂክን ገለልተኛ ማድረግ እንፈልጋለን። ማይክሮ ሰርቪስ በበኩሉ ሙሉ በሙሉ ራሱን ችሎ የሚኖር አገልግሎት ተብሎ ይታሰባል። ይህ አቀራረብ በተወሰነ ደረጃ ብክነት እንዳለው አምናለሁ, እና ለመድረስ አስቸጋሪ ነው, ምክንያቱም ለምሳሌ, በ C # ውስጥ ያሉ አገልግሎቶች በማንኛውም ሁኔታ በመደበኛ ቤተ-መጽሐፍት ይገናኛሉ. ስርዓታችን በC# ተጽፏል፤ ሌሎች ቴክኖሎጂዎችን እስካሁን አልተጠቀምንም። ስለዚህ, የጋራ ቴክኒካዊ ስብሰባዎችን ለመጠቀም አቅም እንዳለን ወስነናል. ዋናው ነገር የቢዝነስ አመክንዮ ምንም ቁርጥራጭ የሌላቸው መሆኑ ነው. እየተጠቀሙበት ባለው ORM ላይ የምቾት መጠቅለያ ካሎት ከአገልግሎት ወደ አገልግሎት መቅዳት በጣም ውድ ነው።

ቡድናችን በጎራ የሚመራ ንድፍ አድናቂ ነው፣ ስለዚህ የሽንኩርት አርክቴክቸር ለእኛ በጣም ተስማሚ ነበር። የአገልግሎታችን መሰረት የመረጃ ተደራሽነት ንብርብር ሳይሆን የቢዝነስ ሎጂክን ብቻ የያዘ እና ከመሠረተ ልማት ጋር ምንም ግንኙነት የሌለው ስብሰባ ነው። በተመሳሳይ ጊዜ, ከማዕቀፎች ጋር የተያያዙ ችግሮችን ለመፍታት የጎራ ስብሰባን በግል ማሻሻል እንችላለን.

በዚህ ደረጃ የመጀመሪያውን ከባድ ችግር አጋጥሞናል. አገልግሎቱ አንድን የጎራ ስብሰባ ማጣቀስ ነበረበት፣ አመክንዮውን ነጻ ማድረግ እንፈልጋለን፣ እና የ DRY መርህ እዚህ ላይ በጣም እንቅፋት አድርጎብናል። ማባዛትን ለማስቀረት ገንቢዎቹ ከአጎራባች ስብሰባዎች ክፍሎችን እንደገና መጠቀም ይፈልጋሉ እና በዚህ ምክንያት ጎራዎቹ እንደገና አንድ ላይ መያያዝ ጀመሩ። ውጤቶቹን ተንትነን ምናልባት ችግሩ የምንጭ ኮድ ማከማቻ መሳሪያ አካባቢ ላይም እንዳለ ወስነናል። ሁሉንም የምንጭ ኮድ የያዘ ትልቅ ማከማቻ ነበረን። ለጠቅላላው ፕሮጀክት መፍትሄው በአካባቢው ማሽን ላይ ለመሰብሰብ በጣም አስቸጋሪ ነበር. ስለዚህ ለፕሮጀክቱ ክፍሎች የተለዩ ትናንሽ መፍትሄዎች ተፈጥረዋል፣ እና ማንም የጋራ ወይም የጎራ ስብሰባን ለእነሱ ማከል እና እንደገና ጥቅም ላይ ማዋልን ማንም አልከለከለም። ይህንን እንድናደርግ ያልፈቀደልን ብቸኛው መሳሪያ የኮድ ግምገማ ነው። ግን አንዳንድ ጊዜ ደግሞ አልተሳካም.

ከዚያም የተለየ ማከማቻዎች ወዳለው ሞዴል መሄድ ጀመርን. የንግድ አመክንዮ ከአሁን በኋላ ከአገልግሎት ወደ አገልግሎት አይፈስም፣ ጎራዎች በእውነት ራሳቸውን የቻሉ ሆነዋል። የታሰሩ አውዶች የበለጠ በግልፅ ይደገፋሉ። የመሠረተ ልማት ቤተ መጻሕፍትን እንዴት እንደገና እንጠቀማለን? በተለየ ማከማቻ ውስጥ ለይተናቸው፣ ከዚያም ወደ ኑጌት ፓኬጆች አስገባናቸው፣ ወደ አርቲፋክተሪም አስገባን። በማንኛውም ለውጥ ፣ ስብሰባ እና ህትመት በራስ-ሰር ይከሰታል።

አገልግሎታችን የውስጥ መሠረተ ልማት ፓኬጆችን ከውጫዊው ጋር በተመሳሳይ መልኩ ማጣቀስ ጀመረ። ከኑጌት የውጭ ቤተ-መጻሕፍትን እናወርዳለን። እነዚህን ጥቅሎች ባደረግንበት ከአርቲፊክቲክ ጋር ለመስራት ሁለት የጥቅል አስተዳዳሪዎችን ተጠቀምን። በትናንሽ ማከማቻዎች ውስጥም ኑጌትን ተጠቀምን። ብዙ አገልግሎቶች ባሉባቸው ማከማቻዎች ውስጥ፣ በሞጁሎች መካከል የበለጠ የስሪት ወጥነት የሚያቀርበውን ፓኬትን ተጠቀምን።

ስለዚህ በምንጭ ኮድ ላይ በመስራት፣ አርክቴክቸርን በትንሹ በመቀየር እና ማከማቻዎችን በመለየት አገልግሎቶቻችንን የበለጠ ገለልተኛ እናደርጋለን።

የመሠረተ ልማት ችግሮች

ወደ ማይክሮ ሰርቪስ ለመሸጋገር አብዛኛው አሉታዊ ጎኖች ከመሰረተ ልማት ጋር የተያያዙ ናቸው። አውቶማቲክ ማሰማራት ያስፈልግዎታል፣ መሠረተ ልማቱን ለማካሄድ አዲስ ቤተ መጻሕፍት ያስፈልግዎታል።

በአካባቢ ውስጥ በእጅ መጫን

መጀመሪያ ላይ ለአካባቢዎች መፍትሄውን በእጅ ጫንን. ይህንን ሂደት በራስ-ሰር ለማድረግ, የሲአይ / ሲዲ የቧንቧ መስመር ፈጠርን. ቀጣይነት ያለው የማስረከቢያ ሂደትን መርጠናል ምክንያቱም ቀጣይነት ያለው ማሰማራት ከንግድ ሂደቶች አንፃር ለእኛ ገና ተቀባይነት ስለሌለው ነው። ስለዚህ, ለስራ መላክ የሚከናወነው አዝራርን በመጠቀም ነው, እና ለሙከራ - በራስ-ሰር.

አትላሲያንን፣ ቢትቡኬትን የምንጭ ኮድ ማከማቻ እና ቀርከሃ ለመገንባት እንጠቀማለን። እኛ በኬክ ውስጥ የግንባታ ስክሪፕቶችን መጻፍ እንፈልጋለን ምክንያቱም እሱ ከ C # ጋር ተመሳሳይ ነው። ዝግጁ የሆኑ ፓኬጆች ወደ አርቲፋክተሪ ይመጣሉ ፣ እና Ansible በራስ-ሰር ወደ የሙከራ አገልጋዮች ይደርሳል ፣ ከዚያ በኋላ ወዲያውኑ ሊሞከሩ ይችላሉ።

የተለየ ምዝግብ ማስታወሻ

በአንድ ወቅት፣ የሞኖሊዝ አንዱ ሃሳብ የጋራ ምዝግብ ማስታወሻ ማቅረብ ነበር። እንዲሁም በዲስኮች ላይ ባሉ ነጠላ ምዝግብ ማስታወሻዎች ምን ማድረግ እንዳለብን መረዳት አለብን። የእኛ ምዝግብ ማስታወሻዎች ለጽሑፍ ፋይሎች ተጽፈዋል። መደበኛ የ ELK ቁልል ለመጠቀም ወስነናል። በቀጥታ በአቅራቢዎች በኩል ወደ ELK አልጻፍንም፣ ነገር ግን የጽሑፍ መዝገቦችን እንደምናጠናቅቅ እና የመከታተያ መታወቂያውን እንደ መለያ እንጽፋለን፣ የአገልግሎት ስሙን በመጨመር እነዚህ ምዝግብ ማስታወሻዎች በኋላ ሊተነተኑ ይችላሉ።

በFilebeat አማካኝነት ምዝግብ ማስታወሻዎቻችንን ከሚከተሉት ውስጥ መሰብሰብ እንችላለን አገልጋዮችከዚያም ይቀይሯቸው፣ በUI ውስጥ ጥያቄዎችን ለመገንባት ኪባናን ይጠቀሙ እና ጥሪው በአገልግሎቶች መካከል እንዴት እንደተዘዋወረ ይመልከቱ። የመከታተያ መታወቂያዎች ለዚህ በጣም ጠቃሚ ናቸው።

ተዛማጅ አገልግሎቶችን መሞከር እና ማረም

መጀመሪያ ላይ፣ እየተገነቡ ያሉትን አገልግሎቶች እንዴት ማረም እንደምንችል ሙሉ በሙሉ አልገባንም። በሞኖሊት ሁሉም ነገር ቀላል ነበር፤ በአገር ውስጥ ማሽን ላይ እንሮጥነው ነበር። መጀመሪያ ላይ በማይክሮ ሰርቪስ ተመሳሳይ ነገር ለማድረግ ሞክረዋል ፣ ግን አንዳንድ ጊዜ አንድ ማይክሮ አገልግሎትን ሙሉ በሙሉ ለመጀመር ሌሎች ብዙዎችን ማስጀመር ያስፈልግዎታል ፣ እና ይህ የማይመች ነው። እኛ ማረም የምንፈልገውን አገልግሎት ወይም አገልግሎቶችን ብቻ በአገር ውስጥ ማሽን ላይ ወደምንወጣበት ሞዴል መሄድ እንዳለብን ተገነዘብን። የተቀሩት አገልግሎቶች ውቅሩን ከፕሮድ ጋር ከሚዛመዱ አገልጋዮች ጥቅም ላይ ይውላሉ። ከማረም በኋላ, በሙከራ ጊዜ, ለእያንዳንዱ ተግባር, የተቀየሩት አገልግሎቶች ለሙከራ አገልጋይ ብቻ ይሰጣሉ. ስለዚህ, መፍትሄው ወደፊት በማምረት ላይ በሚታይበት መልክ ይሞከራል.

የምርት ስሪቶችን ብቻ የሚያሄዱ አገልጋዮች አሉ። እነዚህ ሰርቨሮች በአደጋዎች ጊዜ ያስፈልጋሉ, ከመሰማራቱ በፊት መላክን ለመፈተሽ እና ለውስጣዊ ስልጠና.

ታዋቂውን የSpecflow ላይብረሪ በመጠቀም አውቶሜትድ የሙከራ ሂደት አክለናል። ሙከራዎች ከአንሲብል ከተሰማሩ በኋላ NUnitን በመጠቀም በራስ-ሰር ይሰራሉ። የሥራው ሽፋን ሙሉ በሙሉ በራስ-ሰር ከሆነ, ከዚያ በእጅ መሞከር አያስፈልግም. ምንም እንኳን አንዳንድ ጊዜ ተጨማሪ በእጅ መሞከር አሁንም ያስፈልጋል. ለአንድ የተወሰነ ጉዳይ የትኛዎቹ ሙከራዎች እንደሚሄዱ ለማወቅ በጂራ ውስጥ መለያዎችን እንጠቀማለን።

በተጨማሪም ፣ የጭነት መፈተሽ አስፈላጊነት ጨምሯል ፣ ከዚህ ቀደም የተካሄደው አልፎ አልፎ ብቻ ነበር። ፈተናዎችን ለማሄድ JMeterን፣ እነሱን ለማከማቸት InfluxDB እና Grafana የሂደት ግራፎችን ለመስራት እንጠቀማለን።

ምን አሳካን?

በመጀመሪያ, "መለቀቅ" የሚለውን ጽንሰ-ሐሳብ አስወግደናል. ይህ ኮሎሰስ በምርት አካባቢ ውስጥ ሲሰማራ፣ ለጊዜው የንግድ ሂደቶችን ሲያስተጓጉል የሁለት ወር አስፈሪ ልቀቶች ጠፍተዋል። አሁን በየ1,5 ቀኑ በአማካይ አገልግሎቶችን እናሰማራቸዋለን፣ ከተፈቀደ በኋላ ወደ ስራ ስለሚገቡ በቡድን እንመድባቸዋለን።

በስርዓታችን ውስጥ ገዳይ ውድቀቶች የሉም። ማይክሮ ሰርቪስን ከስህተት ጋር ከለቀቅን ከዚያ ጋር የተያያዘው ተግባር ይሰበራል እና ሁሉም ሌሎች ተግባራት አይጎዱም። ይህ የተጠቃሚውን ልምድ በእጅጉ ያሻሽላል።

የማሰማራት ዘይቤን መቆጣጠር እንችላለን። አስፈላጊ ከሆነ ከተቀረው መፍትሄ በተናጠል የአገልግሎቶች ቡድኖችን መምረጥ ይችላሉ.

በተጨማሪም, እኛ በከፍተኛ ማሻሻያ ወረፋ ጋር ያለውን ችግር ቀንሷል. አሁን ከአንዳንድ አገልግሎቶች ጋር በግል የሚሰሩ የተለዩ የምርት ቡድኖች አሉን። የ Scrum ሂደት አስቀድሞ እዚህ ጥሩ ነው። አንድ የተወሰነ ቡድን ለእሱ ተግባራትን የሚመድብ የተለየ የምርት ባለቤት ሊኖረው ይችላል።

ማጠቃለያ

• ማይክሮ ሰርቪስ ውስብስብ ስርዓቶችን ለመበስበስ በጣም ተስማሚ ነው. በሂደቱ ውስጥ, በስርዓታችን ውስጥ ምን እንዳለ, ምን አይነት ውስን አውዶች እንዳሉ, ድንበራቸው የት እንዳለ መረዳት እንጀምራለን. ይህ በሞጁሎች መካከል ማሻሻያዎችን በትክክል ለማሰራጨት እና የኮድ ግራ መጋባትን ለመከላከል ያስችላል።
• ማይክሮ ሰርቪስ ድርጅታዊ ጥቅሞችን ይሰጣል። ብዙውን ጊዜ የሚነገሩት እንደ አርክቴክቸር ብቻ ነው, ነገር ግን ማንኛውም አርክቴክቸር የቢዝነስ ፍላጎቶችን ለመፍታት እንጂ በራሱ አይደለም. ስለዚህ, Scrum አሁን በጣም ተወዳጅ ስለሆነ ጥቃቅን አገልግሎቶች በትናንሽ ቡድኖች ውስጥ ችግሮችን ለመፍታት በጣም ተስማሚ ናቸው ማለት እንችላለን.
• መለያየት ተደጋጋሚ ሂደት ነው። አፕሊኬሽኑን ወስደህ በቀላሉ ወደ ማይክሮ ሰርቪስ መከፋፈል አትችልም። የተገኘው ምርት ተግባራዊ ሊሆን አይችልም. ማይክሮ ሰርቪስ በሚሰጥበት ጊዜ ያለውን ውርስ እንደገና መጻፍ ጠቃሚ ነው, ማለትም ወደምንወደው ኮድ መቀየር እና በተግባራዊነት እና በፍጥነት የንግድ ፍላጎቶችን በተሻለ ሁኔታ ያሟላል.

  ትንሽ ማስጠንቀቂያ; ወደ ማይክሮ ሰርቪስ የመሸጋገር ወጪዎች በጣም ጠቃሚ ናቸው. የመሰረተ ልማት ችግርን ብቻ ለመፍታት ረጅም ጊዜ ፈጅቷል። ስለዚህ ትንሽ አፕሊኬሽን ልዩ ልኬትን የማይፈልግ ከሆነ፣ ለቡድንዎ ትኩረት እና ጊዜ የሚወዳደሩ ደንበኞች ከሌሉዎት፣ ማይክሮ ሰርቪስ ዛሬ እርስዎ የሚፈልጉት ላይሆኑ ይችላሉ። በጣም ውድ ነው። ሂደቱን በማይክሮ ሰርቪስ ከጀመሩ ታዲያ ወጪዎቹ በመጀመሪያ ከሞኖሊቲ ልማት ጋር ተመሳሳይ ፕሮጀክት ከጀመሩ የበለጠ ከፍ ያለ ይሆናል።

  PS የበለጠ ስሜታዊ ታሪክ (እና ለእርስዎ በግል) - መሠረት ማያያዣ.
  የሪፖርቱ ሙሉ ስሪት እነሆ።

ምንጭ: hab.com