له مونولیت څخه مایکرو خدماتو ته لیږد: تاریخ او تمرین

پدې مقاله کې به زه د دې په اړه وغږیږم چې څنګه پروژه چې زه یې کار کوم د لوی واحد څخه د مایکرو خدماتو سیټ ته بدل شو.

د دې پروژې تاریخ ډیر وخت دمخه د 2000 په پیل کې پیل شو. لومړۍ نسخه په Visual Basic 6 کې لیکل شوې. د وخت په تیریدو سره دا څرګنده شوه چې د دې ژبې پراختیا به په راتلونکي کې ملاتړ کول ستونزمن وي ځکه چې IDE او ژبه پخپله کمزورې وده کوي. د 2000 لسیزې په پای کې، پریکړه وشوه چې ډیر ژمن C# ته لاړ شي. نوې نسخه د زاړه له بیاکتنې سره موازي لیکل شوې، په تدریجي ډول په .NET کې ډیر او ډیر کوډ لیکل شوي. په C# کې بیکینډ په پیل کې د خدماتو جوړښت باندې تمرکز درلود، مګر د پراختیا په جریان کې، د منطق سره عام کتابتونونه کارول شوي، او خدمتونه په یوه پروسه کې پیل شوي. پایله یو غوښتنلیک و چې موږ یې د "خدمت مونولیت" وایو.

د دې ترکیب یو څو ګټو څخه د خدماتو وړتیا وه چې د بهرني API له لارې یو بل ته زنګ ووهي. یو ډیر درست خدمت ته د لیږد لپاره واضح شرایط شتون درلود، او په راتلونکي کې، د مایکرو سرویس جوړښت.

موږ د 2015 په شاوخوا کې د تخریب په اړه خپل کار پیل کړ. موږ لاهم یو مثالي حالت ته نه یو رسیدلي - لاهم د یوې لویې پروژې برخې شتون لري چې په سختۍ سره د مونولیت په نوم یادیږي ، مګر دوی د مایکرو خدماتو په څیر نه ښکاري. په هرصورت، پرمختګ د پام وړ دی.
زه به په مقاله کې د هغې په اړه خبرې وکړم.

منځپانګې

• جوړښت او د موجوده حل ستونزې
• د مایکرو خدماتو څخه تمه
• د لیږد ستونزې
• له مونولیت څخه مایکرو خدماتو ته د حرکت کولو څرنګوالی
  • لومړی لاره
  • دوهم لاره
  • دریمه لاره
  • څلورمه لاره
• د ډیټابیس سره کار کول
  • د موجوده میزونو ویشل
  • د پروسس څانګه
• د سرچینې کوډ سره کار کول
• د زیربناوو ستونزې
  • په چاپیریال کې لاسي نصب کول
  • جلا جلا کول
  • د اړوندو خدماتو ازموینه او ډیبګ کول

جوړښت او د موجوده حل ستونزې

په پیل کې، جوړښت داسې ښکاري: UI یو جلا غوښتنلیک دی، واحد برخه په Visual Basic 6 کې لیکل شوې، د .NET غوښتنلیک د اړوندو خدماتو یوه مجموعه ده چې د کافي لوی ډیټابیس سره کار کوي.

د پخوانیو حلونو نیمګړتیاوې

د ناکامۍ واحد ټکی
موږ د ناکامۍ یو واحد ټکی درلود: د .NET غوښتنلیک په یوه پروسه کې تیر شو. که کوم ماډل ناکام شو، ټول غوښتنلیک ناکام شو او باید بیا پیل شي. څرنګه چې موږ د مختلف کاروونکو لپاره ډیری پروسې اتومات کوو، د دوی په یوه کې د ناکامۍ له امله، هرڅوک نشي کولی د یو څه وخت لپاره کار وکړي. او د سافټویر غلطی په صورت کې، حتی بیک اپ مرسته نه ده کړې.

د پرمختګونو کتار
دا نیمګړتیا پرځای تنظیمي ده. زموږ غوښتنلیک ډیری پیرودونکي لري، او دوی ټول غواړي چې ژر تر ژره یې ښه کړي. پخوا، دا ناشونې وه چې دا په موازي توګه ترسره کړي، او ټول پیرودونکي په لیکه کې ودریدل. دا پروسه د سوداګرۍ لپاره منفي وه ځکه چې دوی باید ثابت کړي چې د دوی دنده ارزښتناکه وه. او پراختیایی ټیم د دې کتار په تنظیم کولو کې وخت تیر کړ. دې ډیر وخت او هڅې واخیستې، او محصول په نهایت کې نشي کولی څومره ژر چې دوی یې خوښ کړي بدلون ومومي.

د منابعو څخه غوره کارول
کله چې په یوه پروسه کې د خدماتو کوربه کول، موږ تل د سرور څخه سرور ته ترتیب په بشپړه توګه کاپي کوو. موږ غوښتل چې خورا ډیر بار شوي خدمات په جلا توګه ځای په ځای کړو ترڅو سرچینې ضایع نکړو او زموږ د ګمارنې سکیم باندې ډیر انعطاف وړ کنټرول ترلاسه کړو.

د عصري ټیکنالوژیو پلي کول ستونزمن دي
یوه ستونزه چې ټولو پراختیا کونکو ته پیژندل کیږي: په پروژه کې د عصري ټیکنالوژیو معرفي کولو لیوالتیا شتون لري ، مګر هیڅ فرصت شتون نلري. د لوی واحد حل سره، د اوسني کتابتون هر ډول تازه کول، د نوي ته د لیږد یادونه نه کول، په یوه غیر معمولي کار بدلیږي. دا ډیر وخت نیسي چې د ټیم مشر ته ثابت کړي چې دا به د ضایع شوي اعصابو څخه ډیر بونس راوړي.

د بدلونونو په خپرولو کې ستونزې
دا ترټولو جدي ستونزه وه - موږ په هرو دوو میاشتو کې خوشې کول.
هر خوشې کول د پراختیا کونکو ازموینې او هڅو سره سره د بانک لپاره په ریښتیني ناورین بدل شو. سوداګرۍ پوهیده چې د اونۍ په پیل کې د هغې ځینې فعالیت به کار ونکړي. او پراختیا کونکي پوهیدل چې یوه اونۍ جدي پیښې دوی ته انتظار باسي.
هرڅوک د وضعیت د بدلولو هیله درلوده.

د مایکرو خدماتو څخه تمه

د اجزاو مسله کله چې چمتو وي. د اجزاوو تحویل کول کله چې چمتو وي د محلول تخریب او مختلف پروسې جلا کولو سره.

د کوچنیو محصولاتو ټیمونه. دا مهمه ده ځکه چې یو لوی ټیم چې په زاړه مونولیت کې کار کوي اداره کول ستونزمن وو. دا ډول ټیم ​​مجبور و چې د یوې سختې پروسې له مخې کار وکړي، مګر دوی ډیر خلاقیت او خپلواکي غواړي. یوازې کوچني ټیمونه دا توان لري.

په جلا پروسو کې د خدماتو جلا کول. په عین حال کې، ما غوښتل دا په کانټینرونو کې جلا کړم، مګر د .NET چوکاټ کې لیکل شوي لوی شمیر خدمتونه یوازې په وینډوز کې پرمخ ځي. د .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");

       }
    }
}

د مایکرو خدماتو تخصیص کولو دویمه لاره دا ده: د نویو ستونزو د حل لپاره یې جوړ کړئ. که په ورته وخت کې مونولیت وده ونه کړي، دا لا دمخه خورا ښه دی، پدې معنی چې موږ سم لوري ته روان یو. د نویو ستونزو د حل لپاره، موږ هڅه وکړه چې جلا خدمات رامنځته کړو. که چیرې داسې فرصت شتون ولري، نو بیا موږ نور "کینونیکل" خدمتونه رامینځته کړي چې په بشپړ ډول د دوی خپل ډیټا ماډل اداره کوي، یو جلا ډیټابیس.

موږ، د ډیری په څیر، د تصدیق او واک ورکولو خدماتو سره پیل کړی. دوی د دې لپاره مناسب دي. دوی خپلواک دي، د یوې قاعدې په توګه، دوی د جلا معلوماتو ماډل لري. دوی پخپله د monolith سره اړیکه نه لري، یوازې دا د ځینو ستونزو حل کولو لپاره دوی ته ځي. د دې خدماتو په کارولو سره ، تاسو کولی شئ نوي جوړښت ته لیږد پیل کړئ ، د دوی زیربنا ډیبګ کړئ ، د شبکې کتابتونونو پورې اړوند ځینې لارې هڅه وکړئ ، او داسې نور. موږ په خپل سازمان کې هیڅ ټیم نلرو چې نشي کولی د تصدیق خدمت رامینځته کړي.

د مایکرو خدماتو تخصیص لپاره دریمه لارههغه یو چې موږ یې کاروو زموږ لپاره یو څه ځانګړی دی. دا د UI پرت څخه د سوداګرۍ منطق لرې کول دي. زموږ اصلي UI غوښتنلیک ډیسټاپ دی؛ دا د شالید په څیر په C# کې لیکل شوی. پراختیا کونکو په دوره توګه غلطي کړې او د منطق برخې یې UI ته لیږدولي چې باید په شالید کې شتون ولري او بیا کارول شوي وي.

که تاسو د UI برخې کوډ څخه ریښتینې مثال وګورئ، تاسو کولی شئ وګورئ چې د دې حل ډیری برخه د اصلي سوداګرۍ منطق لري چې په نورو پروسو کې ګټور دي، نه یوازې د UI فارم جوړولو لپاره.

اصلي UI منطق یوازې په وروستیو څو کرښو کې شتون لري. موږ دا سرور ته لیږدولی ترڅو دا بیا وکارول شي، په دې توګه د UI کمول او سم جوړښت ترلاسه کول.

د مایکرو خدماتو جلا کولو څلورمه او خورا مهمه لاره، کوم چې د مونولیت کمولو امکان رامینځته کوي ، د پروسس کولو سره د موجوده خدماتو لرې کول دي. کله چې موږ موجوده موډلونه لکه څنګه چې وي نو پایله یې تل د پراختیا کونکو په خوښه نه وي، او د سوداګرۍ پروسه ممکن د فعالیت له رامینځته کیدو راهیسې زوړ شوی وي. د بیاکتنې سره، موږ کولی شو د نوي سوداګرۍ پروسې ملاتړ وکړو ځکه چې د سوداګرۍ اړتیاوې په دوامداره توګه بدلیږي. موږ کولی شو د سرچینې کوډ ښه کړو، پیژندل شوي نیمګړتیاوې لرې کړو، او د ډیټا غوره ماډل جوړ کړو. ډیری ګټې شتون لري.

د پروسس کولو څخه د خدماتو جلا کول د محدود شرایطو مفکورې سره په غیر مستقیم ډول تړاو لري. دا د ډومین چلولو ډیزاین څخه مفهوم دی. دا د ډومین ماډل یوه برخه ده چې پکې د یوې ژبې ټول شرایط په ځانګړي ډول تعریف شوي. راځئ چې د مثال په توګه د بیمې او بیلونو شرایطو ته وګورو. موږ یو واحد غوښتنلیک لرو، او موږ اړتیا لرو چې د بیمې حساب سره کار وکړو. موږ تمه لرو چې پراختیا کونکي په بل مجلس کې د موجوده حساب ټولګي ومومي ، د بیمې ټولګي څخه یې حواله کړي ، او موږ به کاري کوډ ولرو. د DRY اصول به درناوی وشي، کار به د موجوده کوډ په کارولو سره ګړندی ترسره شي.

د پایلې په توګه، دا معلومه شوه چې د حسابونو او بیمې شرایط سره تړلي دي. لکه څنګه چې نوې اړتیاوې راڅرګندېږي، دا جوړه به د پرمختګ سره مداخله وکړي، د پخوانۍ پیچلې سوداګرۍ منطق پیچلتیا زیاتوي. د دې ستونزې د حل لپاره، تاسو اړتیا لرئ چې په کوډ کې د شرایطو تر مینځ سرحدونه ومومئ او د دوی سرغړونې لیرې کړئ. د مثال په توګه، د بیمې په شرایطو کې، دا خورا ممکنه ده چې د مرکزي بانک د 20 عددي حساب شمیره او د حساب پرانیستلو نیټه به کافي وي.

د دې لپاره چې دا تړل شوي شرایط له یو بل څخه جلا کړئ او د مایکرو خدماتو جلا کولو پروسه له یو واحد حل څخه پیل کړئ، موږ یوه طریقه وکاروله لکه په غوښتنلیک کې د بهرني APIs رامینځته کول. که موږ پوهیږو چې ځینې ماډل باید د مایکرو سرویس شي، د پروسې په اوږدو کې یو څه تعدیل شوي، نو موږ سمدلاسه هغه منطق ته زنګ وواهه چې د بهرني تلیفونونو له لارې په بل محدود شرایطو پورې اړه لري. د مثال په توګه، د REST یا WCF له لارې.

موږ په کلکه پریکړه وکړه چې موږ به د کوډ څخه مخنیوی ونکړو چې توزیع شوي لیږد ته اړتیا ولري. زموږ په قضیه کې، دا معلومه شوه چې دا قواعد تعقیب کول خورا اسانه دي. موږ لاهم د داسې شرایطو سره مخ شوي ندي چیرې چې سخت توزیع شوي لیږد ته واقعیا اړتیا ده - د ماډلونو ترمینځ وروستی ثبات خورا کافي دی.

راځئ چې یو ځانګړی مثال وګورو. موږ د آرکیسټرټر مفهوم لرو - یو پایپ لاین چې د "غوښتنلیک" وجود پروسس کوي. هغه په ​​بدل کې یو مراجع، یو حساب او یو بانک کارت جوړوي. که چیرې پیرودونکي او حساب په بریالیتوب سره رامینځته شي ، مګر د کارت رامینځته کول ناکام شي ، غوښتنلیک د "بریالي" حالت ته نه ځي او د "کارډ نه جوړ شوی" حالت کې پاتې کیږي. په راتلونکي کې، د شالید فعالیت به دا غوره کړي او پای ته ورسوي. سیسټم د څه مودې لپاره د ګډوډۍ په حالت کې و، مګر موږ په عمومي توګه له دې څخه راضي یو.

که چیرې یو حالت رامینځته شي کله چې دا اړینه وي چې په دوامداره توګه د ډیټا یوه برخه خوندي کړئ ، نو موږ به ډیری احتمال د خدماتو یوځای کولو لپاره لاړ شو ترڅو دا په یوه پروسه کې پروسس کړو.

راځئ چې د مایکرو سرویس تخصیص یوه بیلګه وګورو. تاسو څنګه کولی شئ دا په نسبتا خوندي ډول تولید ته راوړو؟ په دې مثال کې، موږ د سیسټم یوه جلا برخه لرو - د معاشاتو خدماتو ماډل، د کوډ یوه برخه چې موږ غواړو د مایکرو خدمت جوړ کړو.

تر ټولو لومړی، موږ د کوډ په بیا لیکلو سره مایکرو خدمت جوړوو. موږ ځینې اړخونه ښه کوو چې موږ یې خوښ نه وو. موږ د پیرودونکي څخه د سوداګرۍ نوي اړتیاوې پلي کوو. موږ د UI او شالید تر مینځ اړیکې ته د API ګیټ وے اضافه کوو ، کوم چې به د تلیفون فارورډنګ چمتو کړي.

بیا، موږ دا ترتیب په عملیاتو کې خوشې کوو، مګر په پیلوټ حالت کې. زموږ ډیری کاروونکي لاهم د پخوانیو سوداګریزو پروسو سره کار کوي. د نویو کاروونکو لپاره، موږ د واحد غوښتنلیک نوې نسخه رامینځته کوو چې نور دا پروسه نلري. په لازمي ډول ، موږ د یو مونولیت او مایکرو سرویس ترکیب لرو چې د پیلوټ په توګه کار کوي.

د بریالي پیلوټ سره، موږ پوهیږو چې نوی ترتیب په حقیقت کې د کار وړ دی، موږ کولی شو د معادلې څخه زوړ مونولیت لیرې کړو او د زاړه حل په ځای نوی ترتیب پریږدو.

په مجموع کې، موږ د یو واحد منبع کوډ ویشلو لپاره نږدې ټول موجود میتودونه کاروو. دا ټول موږ ته اجازه راکوي چې د غوښتنلیک د برخو اندازه کمه کړو او نوي کتابتونونو ته یې وژباړو، د غوره سرچینې کوډ رامینځته کول.

د ډیټابیس سره کار کول

ډیټابیس د سرچینې کوډ څخه بدتر ویشل کیدی شي، ځکه چې دا نه یوازې اوسنی سکیما لري، بلکې تاریخي معلومات هم لري.

زموږ ډیټابیس، د ډیری نورو په څیر، یو بل مهم نیمګړتیا درلوده - د هغې لوی اندازه. دا ډیټابیس د مونولیت د پیچلي سوداګرۍ منطق سره سم ډیزاین شوی، او د مختلفو محدودو شرایطو جدولونو ترمنځ راټول شوي اړیکې.

زموږ په قضیه کې ، د ټولو ستونزو سر ته رسولو لپاره (لوی ډیټابیس ، ډیری اړیکې ، ځینې وختونه د میزونو ترمینځ ناڅرګند سرحدونه) ، یوه ستونزه رامینځته شوې چې په ډیری لویو پروژو کې پیښیږي: د ګډ ډیټابیس ټیمپلیټ کارول. ډاټا د میزونو څخه د لید له لارې اخیستل شوي، د نقل له لارې، او نورو سیسټمونو ته لیږدول شوي چیرې چې دا نقل ته اړتیا وه. د پایلې په توګه، موږ نشو کولی میزونه په جلا سکیما کې حرکت وکړو ځکه چې دوی په فعاله توګه کارول شوي.

په کوډ کې په محدودو شرایطو کې ورته ویش زموږ سره په جلا کولو کې مرسته کوي. دا معمولا موږ ته یو ښه ښه نظر راکوي چې څنګه موږ د ډیټابیس په کچه ډاټا ماتوو. موږ پوهیږو چې کوم میزونه د یو محدود شرایطو سره تړاو لري او کوم بل سره.

موږ د ډیټابیس ویشلو دوه نړیوال میتودونه کارولي: د موجوده جدولونو ویشل او د پروسس کولو سره ویشل.

د موجوده جدولونو ویشل د کارولو لپاره یو ښه میتود دی که چیرې د ډیټا جوړښت ښه وي ، د سوداګرۍ اړتیاوې پوره کوي ، او هرڅوک ترې خوښ وي. په دې حالت کې، موږ کولی شو موجوده میزونه په جلا سکیما کې جلا کړو.

د پروسس کولو څانګې ته اړتیا ده کله چې د سوداګرۍ ماډل خورا بدل شوی وي ، او میزونه نور موږ ته مطمین نه کوي.

د موجوده میزونو ویشل. موږ باید دا معلومه کړو چې موږ به څه جلا کړو. د دې پوهې پرته، هیڅ شی به کار ونکړي، او دلته په کوډ کې د محدود شرایطو جلا کول به زموږ سره مرسته وکړي. د یوې قاعدې په توګه، که تاسو د سرچینې کوډ کې د شرایطو په حدودو پوه شئ، دا روښانه کیږي چې کوم میزونه باید د ډیپارټمنټ لپاره په لیست کې شامل شي.

راځئ چې تصور وکړو چې موږ یو حل لرو چې په کې دوه مونولیت ماډلونه د یو ډیټابیس سره تعامل کوي. موږ اړتیا لرو ډاډ ترلاسه کړو چې یوازې یو ماډل د جلا شوي جدولونو برخې سره تعامل کوي ، او بل یې د API له لارې ورسره تعامل پیل کوي. د پیل کولو لپاره، دا بسیا ده چې یوازې د API له لارې ثبتول ترسره کیږي. دا زموږ لپاره یو اړین شرط دی چې د مایکرو خدماتو خپلواکۍ په اړه وغږیږو. د لوستلو اړیکې تر هغه پورې پاتې کیدی شي تر هغه چې کومه لویه ستونزه شتون ونلري.

بل ګام دا دی چې موږ کولی شو د کوډ هغه برخه جلا کړو چې د جلا جدولونو سره کار کوي، پرته له پروسس کولو سره، په جلا مایکرو سرویس کې او دا په جلا پروسې، یو کانټینر کې پرمخ وړي. دا به یو جلا خدمت وي چې د مونولیت ډیټابیس او هغه میزونو سره اړیکه لري چې مستقیم ورسره تړاو نلري. مونولیت لاهم د جلا کیدو وړ برخې سره د لوستلو لپاره تعامل کوي.

وروسته به موږ دا اړیکه لیرې کړو، دا دی، د جلا شوي جدولونو څخه د واحد غوښتنلیک څخه ډاټا لوستل به API ته لیږدول کیږي.

بیا، موږ به د عمومي ډیټابیس څخه هغه میزونه وټاکو چې یوازې نوي مایکروسافټ کار کوي. موږ کولی شو میزونه جلا سکیما یا حتی جلا فزیکي ډیټابیس ته انتقال کړو. د مایکرو سرویس او مونولیت ډیټابیس ترمینځ لاهم د لوستلو اړیکه شتون لري ، مګر د اندیښنې لپاره هیڅ شی شتون نلري ، پدې ترتیب کې دا د اوږدې مودې لپاره ژوند کولی شي.

وروستی ګام دا دی چې په بشپړه توګه ټولې اړیکې لرې کړئ. په دې حالت کې، موږ ممکن د اصلي ډیټابیس څخه ډاټا مهاجرت ته اړتیا ولرو. ځینې ​​​​وختونه موږ غواړو چې ځینې ډیټا یا لارښودونه په څو ډیټابیسونو کې د بهرني سیسټمونو څخه نقل شوي بیا وکاروو. دا زموږ سره وخت په وخت پیښیږي.

د پروسس څانګه. دا طریقه د لومړي سره ورته ده، یوازې په برعکس ترتیب کې. موږ سمدلاسه یو نوی ډیټابیس او یو نوی مایکرو سرویس تخصیص کوو چې د API له لارې د مونولیت سره اړیکه لري. مګر په ورته وخت کې ، د ډیټابیس میزونو سیټ پاتې دی چې موږ غواړو په راتلونکي کې حذف کړو. موږ نور ورته اړتیا نلرو؛ موږ دا په نوي ماډل کې ځای په ځای کړل.

د دې سکیم د کار کولو لپاره، موږ به احتمال د لیږد دورې ته اړتیا ولرو.

بیا دوه ممکنه طریقې شتون لري.

لومړی: موږ ټول معلومات په نوي او زاړه ډیټابیس کې نقل کوو. په دې حالت کې، موږ د ډیټا بې ځایه کیدو او همغږي کولو ستونزې لرو. مګر موږ کولی شو دوه مختلف پیرودونکي واخلو. یو به د نوي نسخې سره کار وکړي، بل به د زاړه سره.

دوهم: موږ معلومات د ځینو سوداګریزو معیارونو سره سم ویشو. د مثال په توګه، موږ په سیسټم کې 5 محصولات درلودل چې په زاړه ډیټابیس کې زیرمه شوي وو. موږ شپږم په نوي ډیټابیس کې د نوي سوداګرۍ دندې دننه ځای په ځای کوو. مګر موږ به د API ګیټ وے ته اړتیا ولرو چې دا معلومات به همغږي کړي او پیرودونکي ته وښیې چې چیرې او څه شی ترلاسه کوي.

دواړه طریقې کار کوي، د وضعیت په پام کې نیولو سره غوره کړئ.

وروسته له دې چې موږ ډاډه شو چې هرڅه کار کوي، د مونولیت برخه چې د زاړه ډیټابیس جوړښتونو سره کار کوي غیر فعال کیدی شي.

وروستی ګام د پخوانیو معلوماتو جوړښتونو لرې کول دي.

د لنډیز لپاره، موږ کولی شو ووایو چې موږ د ډیټابیس سره ستونزې لرو: د سرچینې کوډ په پرتله د دې سره کار کول ستونزمن دي، دا شریکول خورا ستونزمن دي، مګر دا کیدی شي او باید ترسره شي. موږ ځینې لارې موندلي چې موږ ته اجازه راکوي چې دا په خوندي ډول ترسره کړو، مګر د سرچینې کوډ په پرتله د معلوماتو سره د غلطیو کول لاهم اسانه دي.

د سرچینې کوډ سره کار کول

دا هغه څه دي چې د سرچینې کوډ ډیاګرام ورته ښکاري کله چې موږ د واحد پروژې تحلیل پیل کړ.

دا تقریبا په دریو طبقو ویشل کیدی شي. دا د پیل شوي ماډلونو، پلگ انونو، خدماتو او انفرادي فعالیتونو یو پرت دی. په حقیقت کې، دا په یو واحد حل کې د ننوتلو نقطې وې. دا ټول په کلکه د یو عام پرت سره مهر شوي وو. دا د سوداګرۍ منطق درلود چې خدمتونه شریک شوي او ډیری اړیکې لري. هر خدمت او پلگ ان تر 10 یا ډیرو عام مجلسونو پورې کارول کیږي ، د دوی اندازې او د پراختیا کونکو ضمیر پورې اړه لري.

موږ خوشحاله یو چې زیربنا کتابتونونه درلودل چې په جلا توګه کارول کیدی شي.

ځینې ​​​​وختونه داسې حالت رامینځته کیږي کله چې ځینې عام شیان په حقیقت کې د دې طبقې پورې تړاو نه درلود، مګر د زیربنا کتابتونونه وو. دا د نوم په بدلولو سره حل شو.

ترټولو لویه اندیښنه د محدودو شرایطو وه. دا پیښ شوي چې 3-4 شرایط په یوه ګډ مجلس کې مخلوط شوي او یو بل یې په ورته سوداګریزو دندو کې کارولی. دا اړینه وه چې پوه شو چې دا چیرته ویشل کیدی شي او په کوم سرحدونو کې، او د سرچینې کوډ مجلسونو کې د دې ویش نقشه کولو سره څه باید وشي.

موږ د کوډ ویشلو پروسې لپاره ډیری مقررات جوړ کړي دي.

لومړی: موږ نور نه غواړو د خدماتو، فعالیتونو او پلگ انونو ترمنځ د سوداګرۍ منطق شریک کړو. موږ غوښتل د سوداګرۍ منطق په مایکرو خدماتو کې خپلواک کړو. له بلې خوا کوچني خدمتونه په مثالي توګه د خدماتو په توګه فکر کیږي چې په بشپړ ډول خپلواک شتون لري. زه باور لرم چې دا طریقه یو څه ضایع ده، او ترلاسه کول یې ستونزمن دي، ځکه چې د مثال په توګه، په C# کې خدمات به په هر حالت کې د معیاري کتابتون لخوا وصل شي. زموږ سیسټم په C# کې لیکل شوی؛ موږ تراوسه نور ټیکنالوژي نه دي کارولي. له همدې امله، موږ پریکړه وکړه چې موږ کولی شو د ګډ تخنیکي غونډو څخه کار واخلو. اصلي شی دا دی چې دوی د سوداګرۍ منطق هیڅ ټوټه نلري. که تاسو د ORM په اړه د اسانتیا ریپر لرئ چې تاسو یې کاروئ، نو بیا یې له خدمت څخه خدمت ته کاپي کول خورا ګران دي.

زموږ ټیم د ډومین لخوا پرمخ وړل شوي ډیزاین مینه وال دی، نو د پیاز جوړښت زموږ لپاره خورا مناسب و. زموږ د خدماتو اساس د معلوماتو لاسرسي پرت نه دی ، مګر د ډومین منطق سره مجلس دی چې یوازې د سوداګرۍ منطق لري او د زیربنا سره هیڅ اړیکه نلري. په ورته وخت کې، موږ کولی شو په خپلواکه توګه د ډومین مجلس تعدیل کړو ترڅو د چوکاټونو پورې اړوند ستونزې حل کړي.

پدې مرحله کې موږ د خپلې لومړۍ جدي ستونزې سره مخ شو. خدمت باید یوې ډومین مجلس ته راجع کړي، موږ غوښتل چې منطق خپلواک کړو، او د DRY اصول موږ دلته خورا خنډ کړی. پراختیا کونکو غوښتل چې د ګاونډیو مجلسونو ټولګیو څخه بیا کار واخلي ترڅو د نقل مخه ونیسي، او د پایلې په توګه، ډومینونه بیا یوځای سره تړل شوي. موږ پایلې تحلیل کړې او پریکړه یې وکړه چې شاید ستونزه د سرچینې کوډ ذخیره کولو وسیلې په ساحه کې هم وي. موږ یو لوی ذخیره درلوده چې ټول سرچینې کوډ لري. د ټولې پروژې لپاره حل خورا ستونزمن و چې په محلي ماشین کې راټول شي. له همدې امله، د پروژې د برخو لپاره جلا کوچني حلونه رامینځته شوي، او هیڅوک دوی ته د یو څه عام یا ډومین اسمبلۍ اضافه کولو او بیا کارولو څخه منع نه کوي. یوازینی وسیله چې موږ ته یې اجازه نه راکوله د کوډ بیاکتنه وه. مګر کله ناکله دا هم ناکامه شوه.

بیا موږ د جلا ذخیره کولو سره ماډل ته حرکت پیل کړ. د سوداګرۍ منطق نور له خدمت څخه خدمت ته نه ځي، ډومینونه په ریښتیا خپلواک شوي. تړل شوي شرایط په روښانه ډول ملاتړ کیږي. موږ څنګه د زیربناوو کتابتونونه بیا وکاروو؟ موږ دوی په جلا ذخیره کې جلا کړل، بیا یې د نوګټ کڅوړو کې واچول، کوم چې موږ په هنري فابریکه کې واچوو. د هر ډول بدلون سره، مجلس او خپرونه په اوتومات ډول پیښیږي.

زموږ خدماتو د داخلي زیربناوو کڅوړو ته په ورته ډول د بهرنیو په څیر حواله کول پیل کړل. موږ د نګیټ څخه بهرني کتابتونونه ډاونلوډ کوو. د هنري فابریکې سره کار کولو لپاره ، چیرې چې موږ دا کڅوړې ځای په ځای کړې ، موږ دوه کڅوړې مدیران کاروو. په کوچنیو زیرمو کې موږ نوګیټ هم کارولی. د ډیری خدماتو سره په ذخیره کې، موږ پاکټ کارولی، کوم چې د ماډلونو تر مینځ ډیر نسخه ثبات چمتو کوي.

په دې توګه، د سرچینې کوډ په کار کولو سره، د جوړښت لږ څه بدلولو او د ذخیره کولو جلا کولو سره، موږ خپل خدمتونه ډیر خپلواک کوو.

د زیربناوو ستونزې

مایکرو خدماتو ته د تګ ډیری نیمګړتیاوې د زیربنا پورې اړوند دي. تاسو به اتوماتیک ګمارنې ته اړتیا ولرئ، تاسو به د زیربنا چلولو لپاره نوي کتابتونونو ته اړتیا ولرئ.

په چاپیریال کې لاسي نصب کول

په پیل کې، موږ په لاسي ډول د چاپیریال لپاره حل نصب کړ. د دې پروسې اتومات کولو لپاره، موږ د CI/CD پایپ لاین جوړ کړ. موږ د تحویلي دوامداره پروسه غوره کړه ځکه چې دوامداره ګمارل لاهم زموږ لپاره د سوداګرۍ پروسو له نظره د منلو وړ ندي. له همدې امله ، د عملیاتو لپاره لیږل د تڼۍ په کارولو سره ترسره کیږي ، او د ازموینې لپاره - په اوتومات ډول.

موږ د سرچینې کوډ ذخیره کولو لپاره اټلیسیان ، بټ بکټ او د ودانۍ لپاره بانس کاروو. موږ په کیک کې د جوړونې سکریپټ لیکل خوښوو ځکه چې دا د C# په څیر دی. چمتو شوي کڅوړې هنري فابریکې ته راځي، او ځواب ورکوونکي په اتوماتيک ډول د ازموینې سرورونو ته رسیږي، چې وروسته یې سمدلاسه ازموینه کیدی شي.

جلا جلا کول

په یو وخت کې، د monolith د نظرونو څخه یو دا و چې د ګډو ننوتلو چمتو کول. موږ دا هم پوهیدلو ته اړتیا درلوده چې د انفرادي لاګونو سره څه وکړو چې په ډیسکونو کې دي. زموږ لاګونه د متن فایلونو ته لیکل شوي. موږ پریکړه وکړه چې د معیاري ELK سټیک وکاروو. موږ د چمتو کونکو له لارې مستقیم ELK ته نه و لیکلی، مګر پریکړه یې وکړه چې موږ به د متن لاګونه تعدیل کړو او د ټریس ID به د پیژندونکي په توګه ولیکئ، د خدماتو نوم اضافه کړئ، ترڅو دا لاګونه وروسته تجزیه شي.

د فایل بیټ په کارولو سره، موږ فرصت ترلاسه کوو چې خپل لاګونه له سرورونو څخه راټول کړو، بیا یې بدل کړو، په UI کې د پوښتنو جوړولو لپاره کبانا وکاروو او وګورو چې تلیفون څنګه د خدماتو ترمنځ تیریږي. ټریس ID پدې کې ډیره مرسته کوي.

د اړوندو خدماتو ازموینه او ډیبګ کول

په پیل کې، موږ په بشپړه توګه نه پوهیږو چې څنګه پرمختللی خدمتونه ډیبګ کړو. د مونولیت سره هرڅه ساده وو؛ موږ دا په محلي ماشین کې چلولی. په لومړي سر کې دوی هڅه وکړه چې د مایکرو خدماتو سره ورته کار وکړي، مګر ځینې وختونه د یو مایکرو سرویس په بشپړه توګه پیل کولو لپاره تاسو اړتیا لرئ څو نور پیل کړئ، او دا ناشونی دی. موږ پوهیږو چې موږ اړتیا لرو داسې ماډل ته لاړ شو چیرې چې موږ په محلي ماشین کې یوازې هغه خدمت یا خدمات پریږدو چې موږ یې ډیبګ کول غواړو. پاتې خدمتونه د سرورونو څخه کارول کیږي چې د پروډ سره ترتیب سره سمون لري. د ډیبګ کولو وروسته ، د ازموینې پرمهال ، د هرې دندې لپاره ، یوازې بدل شوي خدمات د ازموینې سرور ته صادریږي. پدې توګه ، حل په هغه شکل کې ازمول شوی چې په راتلونکي کې به په تولید کې څرګند شي.

داسې سرورونه شتون لري چې یوازې د خدماتو تولید نسخې پرمخ وړي. دا سرورونه د پیښو په صورت کې اړین دي، د ګمارلو دمخه او د داخلي روزنې لپاره د تحویلي چک کولو لپاره.

موږ د مشهور سپیک فلو کتابتون په کارولو سره د اتوماتیک ازموینې پروسه اضافه کړې. ازموینې د ځواب وړ څخه د ګمارلو سمدلاسه وروسته د NUnit په کارولو سره په اوتومات ډول پرمخ ځي. که د دندې پوښښ په بشپړ ډول اتومات وي، نو د لاسي ازموینې ته اړتیا نشته. که څه هم ځینې وختونه اضافي لاسي ازموینې لاهم اړین دي. موږ په جیرا کې ټګونه کاروو ترڅو معلومه کړو چې کومې ازموینې د یوې ځانګړې مسلې لپاره پرمخ وړل کیږي.

سربیره پردې ، د بار ازموینې اړتیا زیاته شوې؛ مخکې دا یوازې په نادره قضیو کې ترسره کیده. موږ د ازموینې چلولو لپاره JMeter کاروو، د ذخیره کولو لپاره InfluxDB، او Grafana د پروسې ګرافونو جوړولو لپاره.

څه مو لاسته راوړي دي؟

لومړی، موږ د "خلاصون" مفهوم څخه ځان خلاص کړ. هغه دوه میاشتې وحشتناک ریلیزونه تیر شول کله چې دا کالوس د تولید چاپیریال کې ځای په ځای شوی و ، په موقتي ډول د سوداګرۍ پروسې ګډوډې کړې. اوس موږ خدمتونه په اوسط ډول په هرو 1,5 ورځو کې ځای په ځای کوو، دوی ډله ایز کوو ځکه چې دوی د تصویب وروسته کار کوي.

زموږ په سیسټم کې هیڅ وژونکي ناکامي شتون نلري. که موږ د بګ سره مایکرو سرویس خوشې کړو، نو د دې سره تړلي فعالیت به مات شي، او نور ټول فعالیت به اغیزمن نشي. دا د کاروونکي تجربه خورا ښه کوي.

موږ کولی شو د ګمارنې نمونه کنټرول کړو. تاسو کولی شئ د خدماتو ګروپونه د پاتې حل څخه جلا انتخاب کړئ، که اړتیا وي.

سربیره پردې ، موږ د پرمختګونو لوی قطار سره ستونزه د پام وړ کمه کړې. موږ اوس د محصول جلا ټیمونه لرو چې د ځینو خدماتو سره په خپلواکه توګه کار کوي. د سکرم پروسه لا دمخه دلته ښه فټ ده. یو ځانګړی ټیم ممکن د محصول جلا مالک ولري څوک چې ورته دندې ګماري.

لنډیز

• کوچني خدمتونه د پیچلو سیسټمونو د تخریب لپاره مناسب دي. په پروسه کې، موږ په دې پوهیږو چې زموږ په سیسټم کې څه دي، کوم محدود شرایط شتون لري، چیرته چې د دوی سرحدونه شتون لري. دا تاسو ته اجازه درکوي په سمه توګه د ماډلونو تر مینځ پرمختګونه توزیع کړئ او د کوډ ګډوډۍ مخه ونیسئ.
• کوچني خدمتونه سازماني ګټې وړاندې کوي. دوی ډیری وختونه یوازې د معمارۍ په اړه خبرې کیږي، مګر هر ډول جوړښت د سوداګرۍ اړتیاوو حل کولو لپاره اړین دی، نه په خپله. له همدې امله، موږ کولی شو ووایو چې مایکرو خدمتونه په کوچنیو ټیمونو کې د ستونزو حل کولو لپاره مناسب دي، په دې شرط چې سکرم اوس خورا مشهور دی.
• جلا کول یو تکراري پروسه ده. تاسو نشئ کولی غوښتنلیک واخلئ او په ساده ډول یې په مایکرو خدماتو ویشئ. پایله لرونکی محصول د فعالیت امکان نلري. کله چې د مایکرو خدماتو وقف کول، دا ګټوره ده چې موجوده میراث بیا ولیکئ، دا په کوډ کې بدل کړئ چې موږ یې خوښوو او د فعالیت او سرعت له مخې د سوداګرۍ اړتیاوې په ښه توګه پوره کوي.

  یو کوچنی خبرداری: مایکرو خدماتو ته د تللو لګښتونه خورا مهم دي. یوازې د زیربنا ستونزې حل کولو لپاره ډیر وخت نیولی. نو که تاسو یو کوچنی غوښتنلیک ولرئ چې ځانګړي پیمانه ته اړتیا نلري، پرته لدې چې تاسو د خپل ټیم ​​​​توجه او وخت لپاره سیالي کولو لوی شمیر پیرودونکي ولرئ ، نو مایکرو خدمتونه ممکن هغه څه نه وي چې تاسو ورته اړتیا لرئ نن ورځ. دا خورا ګران دی. که تاسو پروسه د مایکرو خدماتو سره پیل کړئ ، نو لګښتونه به په پیل کې د هغه په ​​​​پرتله لوړ وي که تاسو ورته پروژه د مونولیت پراختیا سره پیل کړئ.

  PS یو ډیر احساساتي کیسه (او لکه څنګه چې ستاسو لپاره په شخصي توګه) - په وینا مخونه.
  دلته د راپور بشپړ نسخه ده.

سرچینه: www.habr.com