یک سنگی سے مائیکرو سروسز میں منتقلی: تاریخ اور مشق

اس آرٹیکل میں، میں اس بات کے بارے میں بات کروں گا کہ میں جس پروجیکٹ پر کام کر رہا ہوں وہ ایک بڑے یک سنگی سے مائیکرو سروسز کے سیٹ میں کیسے تبدیل ہوا۔

اس منصوبے نے اپنی تاریخ کافی عرصہ پہلے، 2000 کے آغاز میں شروع کی تھی۔ پہلے ورژن Visual Basic 6 میں لکھے گئے تھے۔ وقت گزرنے کے ساتھ ساتھ، یہ واضح ہو گیا کہ مستقبل میں اس زبان کی ترقی کو سہارا دینا مشکل ہو گا، کیونکہ IDE اور زبان بذات خود خراب ترقی یافتہ ہے۔ 2000 کی دہائی کے آخر میں، زیادہ امید افزا C# پر سوئچ کرنے کا فیصلہ کیا گیا۔ نیا ورژن پرانے کی نظر ثانی کے متوازی طور پر لکھا گیا تھا، آہستہ آہستہ زیادہ سے زیادہ کوڈ .NET میں لکھا گیا تھا۔ C# میں بیک اینڈ ابتدائی طور پر سروس فن تعمیر پر مرکوز تھا، لیکن ترقی کے دوران، منطق کے ساتھ مشترکہ لائبریریوں کا استعمال کیا گیا، اور خدمات کو ایک ہی عمل میں شروع کیا گیا۔ نتیجہ ایک ایپلیکیشن تھا جسے ہم نے "سروس monolith" کہا۔

اس امتزاج کے چند فوائد میں سے ایک بیرونی API کے ذریعے ایک دوسرے کو کال کرنے کی خدمات کی صلاحیت تھی۔ زیادہ درست سروس، اور مستقبل میں، مائیکرو سروس فن تعمیر کے لیے واضح شرائط تھیں۔

ہم نے 2015 کے آس پاس سڑنے پر اپنا کام شروع کیا۔ ہم ابھی تک ایک مثالی حالت تک نہیں پہنچے ہیں - اب بھی ایک بڑے پروجیکٹ کے کچھ حصے ہیں جنہیں شاید ہی یک سنگی کہا جا سکے، لیکن وہ مائیکرو سروسز کی طرح نظر نہیں آتے۔ اس کے باوجود، پیش رفت اہم ہے.
میں مضمون میں اس کے بارے میں بات کروں گا۔

مواد

• فن تعمیر اور موجودہ حل کے مسائل
• مائیکرو سروسز سے توقعات
• منتقلی کے مسائل
• یک سنگی سے مائیکرو سروسز میں جانے کا طریقہ
  • پہلا راستہ
  • دوسرا راستہ
  • تیسرا راستہ
  • چوتھا راستہ
• ڈیٹا بیس کے ساتھ کام کرنا
  • موجودہ میزیں تقسیم کرنا
  • محکمہ پروسیسنگ
• سورس کوڈ کے ساتھ کام کرنا
• انفراسٹرکچر کے مسائل
  • ماحول میں دستی تنصیب
  • الگ لاگنگ
  • متعلقہ خدمات کی جانچ اور ڈیبگنگ

فن تعمیر اور موجودہ حل کے مسائل

ابتدائی طور پر، فن تعمیر اس طرح نظر آتا تھا: UI ایک الگ ایپلی کیشن ہے، یک سنگی حصہ Visual Basic 6 میں لکھا گیا ہے، .NET ایپلیکیشن متعلقہ خدمات کا ایک سیٹ ہے جو کافی بڑے ڈیٹا بیس کے ساتھ کام کرتی ہے۔

پچھلے حل کے نقصانات

ناکامی کا واحد نقطہ
ہمارے پاس ناکامی کا ایک ہی نقطہ تھا: .NET ایپلیکیشن ایک ہی عمل میں چلی۔ اگر کوئی ماڈیول ناکام ہو گیا تو پوری ایپلیکیشن ناکام ہو گئی اور اسے دوبارہ شروع کرنا پڑا۔ چونکہ ہم مختلف صارفین کے لیے ایک بڑی تعداد کو خودکار بناتے ہیں، ان میں سے کسی ایک میں ناکامی کی وجہ سے، ہر کوئی کچھ وقت کے لیے کام نہیں کر سکتا۔ اور سافٹ ویئر کی خرابی کی صورت میں، بیک اپ سے بھی کوئی فائدہ نہیں ہوا۔

بہتری کی قطار
یہ خرابی بجائے تنظیمی ہے. ہماری ایپلیکیشن کے بہت سے صارفین ہیں، اور وہ سب جلد از جلد اسے بہتر بنانا چاہتے ہیں۔ پہلے، متوازی طور پر ایسا کرنا ناممکن تھا، اور تمام صارفین لائن میں کھڑے تھے۔ یہ عمل کاروباری اداروں کے لیے منفی تھا کیونکہ انہیں ثابت کرنا تھا کہ ان کا کام قیمتی تھا۔ اور ترقیاتی ٹیم نے اس قطار کو منظم کرنے میں وقت صرف کیا۔ اس میں کافی وقت اور محنت لگ گئی، اور پروڈکٹ بالآخر اتنی جلدی تبدیل نہیں ہو سکی جتنی کہ وہ پسند کرتے۔

وسائل کا سب سے زیادہ استعمال
ایک ہی عمل میں خدمات کی میزبانی کرتے وقت، ہم نے ہمیشہ سرور سے سرور تک کنفیگریشن کو مکمل طور پر کاپی کیا۔ ہم سب سے زیادہ بھاری بھرکم خدمات کو الگ سے رکھنا چاہتے تھے تاکہ وسائل ضائع نہ ہوں اور اپنی تعیناتی اسکیم پر زیادہ لچکدار کنٹرول حاصل کریں۔

جدید ٹیکنالوجی کو لاگو کرنا مشکل ہے۔
تمام ڈویلپرز سے واقف ایک مسئلہ: اس منصوبے میں جدید ٹیکنالوجی متعارف کرانے کی خواہش ہے، لیکن کوئی موقع نہیں ہے۔ ایک بڑے یک سنگی حل کے ساتھ، موجودہ لائبریری کی کوئی بھی تازہ کاری، جس میں کسی نئی میں منتقلی کا ذکر نہیں، ایک غیر معمولی کام میں بدل جاتا ہے۔ ٹیم لیڈر کو یہ ثابت کرنے میں کافی وقت لگتا ہے کہ یہ ضائع شدہ اعصاب سے زیادہ بونس لائے گا۔

تبدیلیاں جاری کرنے میں دشواری
یہ سب سے سنگین مسئلہ تھا - ہم ہر دو ماہ بعد ریلیز جاری کر رہے تھے۔
ڈویلپرز کی جانچ اور کوششوں کے باوجود ہر ریلیز بینک کے لیے ایک حقیقی تباہی میں بدل گئی۔ کاروبار سمجھ گیا کہ ہفتے کے آغاز میں اس کی کچھ فعالیت کام نہیں کرے گی۔ اور ڈویلپر سمجھ گئے کہ سنگین واقعات کا ایک ہفتہ ان کا انتظار کر رہا ہے۔
ہر کوئی حالات بدلنے کی خواہش رکھتا تھا۔

مائیکرو سروسز سے توقعات

تیار ہونے پر اجزاء کا مسئلہ۔ حل کو گل کر اور مختلف عمل کو الگ کر کے تیار ہونے پر اجزاء کی ترسیل۔

چھوٹی مصنوعات کی ٹیمیں۔ یہ اس لیے اہم ہے کیونکہ پرانے یک سنگی پر کام کرنے والی ایک بڑی ٹیم کا انتظام کرنا مشکل تھا۔ ایسی ٹیم کو سخت عمل کے مطابق کام کرنے پر مجبور کیا گیا تھا، لیکن وہ زیادہ تخلیقی صلاحیت اور آزادی چاہتے تھے۔ صرف چھوٹی ٹیمیں اس کی متحمل ہوسکتی ہیں۔

الگ الگ عمل میں خدمات کی تنہائی۔ مثالی طور پر، میں اسے کنٹینرز میں الگ کرنا چاہوں گا، لیکن .NET فریم ورک میں لکھی گئی خدمات کی ایک بڑی تعداد صرف اس کے تحت چلتی ہے۔ Windows.NET کور پر مبنی خدمات اب ظاہر ہو رہی ہیں، لیکن ان میں سے اب بھی چند ہیں۔

تعیناتی کی لچک۔ ہم خدمات کو اس طرح جوڑنا چاہیں گے جس طرح ہمیں اس کی ضرورت ہے، نہ کہ جس طرح کوڈ اسے مجبور کرتا ہے۔

نئی ٹیکنالوجیز کا استعمال۔ یہ کسی بھی پروگرامر کے لیے دلچسپ ہے۔

منتقلی کے مسائل

بلاشبہ، اگر مائیکرو سروسز میں یک سنگی کو توڑنا آسان ہوتا، تو کانفرنسوں میں اس کے بارے میں بات کرنے اور مضامین لکھنے کی ضرورت نہیں تھی۔ اس عمل میں بہت سے نقصانات ہیں؛ میں ان اہم چیزوں کو بیان کروں گا جو ہماری راہ میں رکاوٹ ہیں۔

پہلا مسئلہ زیادہ تر monoliths کے لیے عام: کاروباری منطق کی ہم آہنگی۔ جب ہم یک سنگی لکھتے ہیں تو ہم اپنی کلاسوں کو دوبارہ استعمال کرنا چاہتے ہیں تاکہ غیر ضروری کوڈ نہ لکھیں۔ اور جب مائیکرو سروسز میں جاتے ہیں تو یہ ایک مسئلہ بن جاتا ہے: تمام کوڈ کافی مضبوطی سے جوڑے جاتے ہیں، اور سروسز کو الگ کرنا مشکل ہوتا ہے۔

کام کے آغاز کے وقت، ذخیرے میں 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 ہندسوں کا مرکزی بینک اکاؤنٹ نمبر اور اکاؤنٹ کھولنے کی تاریخ کافی ہو۔

ان پابند سیاق و سباق کو ایک دوسرے سے الگ کرنے اور مائیکرو سروسز کو یک سنگی حل سے الگ کرنے کا عمل شروع کرنے کے لیے، ہم نے ایپلیکیشن کے اندر بیرونی APIs بنانے جیسا طریقہ استعمال کیا۔ اگر ہم جانتے تھے کہ کچھ ماڈیول کو مائیکرو سروس بننا چاہیے، کسی نہ کسی طرح عمل کے اندر ترمیم کی جائے، تو ہم نے فوری طور پر اس منطق پر کال کی جو بیرونی کالوں کے ذریعے کسی اور محدود سیاق و سباق سے تعلق رکھتی ہے۔ مثال کے طور پر، REST یا WCF کے ذریعے۔

ہم نے مضبوطی سے فیصلہ کیا ہے کہ ہم ایسے کوڈ سے گریز نہیں کریں گے جس میں تقسیم شدہ لین دین کی ضرورت ہوگی۔ ہمارے معاملے میں، اس اصول پر عمل کرنا کافی آسان نکلا۔ ہم نے ابھی تک ایسے حالات کا سامنا نہیں کیا ہے جہاں سخت تقسیم شدہ لین دین کی واقعی ضرورت ہے - ماڈیولز کے درمیان حتمی مستقل مزاجی کافی ہے۔

آئیے ایک مخصوص مثال کو دیکھتے ہیں۔ ہمارے پاس آرکیسٹریٹر کا تصور ہے - ایک پائپ لائن جو "درخواست" کی ہستی پر کارروائی کرتی ہے۔ وہ بدلے میں ایک کلائنٹ، ایک اکاؤنٹ اور ایک بینک کارڈ بناتا ہے۔ اگر کلائنٹ اور اکاؤنٹ کامیابی کے ساتھ بن جاتے ہیں، لیکن کارڈ بنانے میں ناکام ہو جاتا ہے، تو ایپلیکیشن "کامیاب" سٹیٹس پر نہیں جاتی اور "کارڈ نہیں بنایا" سٹیٹس میں رہتی ہے۔ مستقبل میں، پس منظر کی سرگرمی اسے اٹھا کر ختم کر دے گی۔ نظام کچھ عرصے سے متضاد حالت میں ہے، لیکن ہم عموماً اس سے مطمئن ہیں۔

اگر کوئی ایسی صورت حال پیدا ہوتی ہے جب ڈیٹا کے کچھ حصے کو مستقل طور پر محفوظ کرنا ضروری ہوتا ہے، تو ہم زیادہ تر ممکنہ طور پر ایک ہی عمل میں اس پر کارروائی کرنے کے لیے سروس کو مضبوط کرنے کے لیے جائیں گے۔

آئیے ایک مائیکرو سروس مختص کرنے کی ایک مثال دیکھیں۔ آپ اسے نسبتا محفوظ طریقے سے پیداوار میں کیسے لا سکتے ہیں؟ اس مثال میں، ہمارے پاس سسٹم کا ایک الگ حصہ ہے - ایک پے رول سروس ماڈیول، کوڈ سیکشن میں سے ایک جس کے ہم مائیکرو سروس بنانا چاہیں گے۔

سب سے پہلے، ہم کوڈ کو دوبارہ لکھ کر ایک مائیکرو سروس بناتے ہیں۔ ہم کچھ ایسے پہلوؤں کو بہتر کر رہے ہیں جن سے ہم خوش نہیں تھے۔ ہم گاہک سے نئی کاروباری ضروریات کو نافذ کرتے ہیں۔ ہم UI اور بیک اینڈ کے درمیان کنکشن میں ایک API گیٹ وے شامل کرتے ہیں، جو کال فارورڈنگ فراہم کرے گا۔

اگلا، ہم اس ترتیب کو آپریشن میں جاری کرتے ہیں، لیکن پائلٹ حالت میں۔ ہمارے زیادہ تر صارفین اب بھی پرانے کاروباری عمل کے ساتھ کام کرتے ہیں۔ نئے صارفین کے لیے، ہم یک سنگی ایپلیکیشن کا ایک نیا ورژن تیار کر رہے ہیں جس میں اب یہ عمل شامل نہیں ہے۔ بنیادی طور پر، ہمارے پاس پائلٹ کے طور پر کام کرنے والی یک سنگی اور ایک مائیکرو سروس کا مجموعہ ہے۔

ایک کامیاب پائلٹ کے ساتھ، ہم سمجھتے ہیں کہ نئی ترتیب واقعی قابل عمل ہے، ہم مساوات سے پرانے یک سنگی کو ہٹا سکتے ہیں اور پرانے حل کی جگہ نئی ترتیب چھوڑ سکتے ہیں۔

مجموعی طور پر، ہم ایک یک سنگی کے ماخذ کوڈ کو تقسیم کرنے کے لیے تقریباً تمام موجودہ طریقے استعمال کرتے ہیں۔ یہ سب ہمیں ایپلیکیشن کے حصوں کا سائز کم کرنے اور بہتر سورس کوڈ بناتے ہوئے نئی لائبریریوں میں ترجمہ کرنے کی اجازت دیتے ہیں۔

ڈیٹا بیس کے ساتھ کام کرنا

ڈیٹا بیس کو سورس کوڈ سے بدتر تقسیم کیا جا سکتا ہے، کیونکہ اس میں نہ صرف موجودہ سکیما، بلکہ جمع شدہ تاریخی ڈیٹا بھی شامل ہے۔

ہمارے ڈیٹا بیس میں، بہت سے دوسرے لوگوں کی طرح، ایک اور اہم خرابی تھی - اس کا بڑا سائز۔ اس ڈیٹا بیس کو یک سنگی کی پیچیدہ کاروباری منطق کے مطابق ڈیزائن کیا گیا تھا، اور مختلف پابند سیاق و سباق کی میزوں کے درمیان جمع ہونے والے تعلقات۔

ہمارے معاملے میں، تمام پریشانیوں کو دور کرنے کے لیے (بڑے ڈیٹا بیس، بہت سے کنکشنز، بعض اوقات میزوں کے درمیان غیر واضح حدود)، ایک مسئلہ پیدا ہوا جو بہت سے بڑے پروجیکٹس میں ہوتا ہے: مشترکہ ڈیٹا بیس ٹیمپلیٹ کا استعمال۔ ڈیٹا کو ٹیبلز سے منظر کے ذریعے، نقل کے ذریعے لیا گیا، اور دوسرے سسٹمز میں بھیج دیا گیا جہاں اس نقل کی ضرورت تھی۔ نتیجے کے طور پر، ہم ٹیبلز کو الگ اسکیما میں منتقل نہیں کر سکے کیونکہ وہ فعال طور پر استعمال کیے گئے تھے۔

کوڈ میں محدود سیاق و سباق میں اسی تقسیم سے ہمیں علیحدگی میں مدد ملتی ہے۔ یہ عام طور پر ہمیں ایک بہت اچھا خیال دیتا ہے کہ ہم ڈیٹا بیس کی سطح پر ڈیٹا کو کیسے توڑتے ہیں۔ ہم سمجھتے ہیں کہ کون سی میزیں ایک پابند سیاق و سباق سے تعلق رکھتی ہیں اور کون سی دوسری سے۔

ہم نے ڈیٹا بیس کی تقسیم کے دو عالمی طریقے استعمال کیے: موجودہ جدولوں کی تقسیم اور پروسیسنگ کے ساتھ تقسیم۔

موجودہ جدولوں کو الگ کرنا استعمال کرنے کا ایک اچھا طریقہ ہے اگر ڈیٹا کا ڈھانچہ اچھا ہے، کاروباری ضروریات کو پورا کرتا ہے، اور ہر کوئی اس سے خوش ہے۔ اس صورت میں، ہم موجودہ جدولوں کو الگ اسکیما میں الگ کر سکتے ہیں۔

پروسیسنگ کے ساتھ ایک محکمہ کی ضرورت ہوتی ہے جب کاروباری ماڈل بہت زیادہ بدل گیا ہے، اور میزیں اب ہمیں بالکل مطمئن نہیں کرتی ہیں.

موجودہ میزیں تقسیم کرنا۔ ہمیں یہ طے کرنے کی ضرورت ہے کہ ہم کیا الگ کریں گے۔ اس علم کے بغیر، کچھ بھی کام نہیں کرے گا، اور یہاں کوڈ میں پابند سیاق و سباق کی علیحدگی ہماری مدد کرے گی۔ ایک اصول کے طور پر، اگر آپ سورس کوڈ میں سیاق و سباق کی حدود کو سمجھ سکتے ہیں، تو یہ واضح ہو جاتا ہے کہ ڈیپارٹمنٹ کی فہرست میں کون سی ٹیبلز شامل کی جانی چاہئیں۔

آئیے تصور کریں کہ ہمارے پاس ایک حل ہے جس میں دو مونولتھ ماڈیول ایک ڈیٹا بیس کے ساتھ تعامل کرتے ہیں۔ ہمیں اس بات کو یقینی بنانے کی ضرورت ہے کہ صرف ایک ماڈیول علیحدہ جدولوں کے حصے کے ساتھ تعامل کرتا ہے، اور دوسرا API کے ذریعے اس کے ساتھ تعامل شروع کرتا ہے۔ شروع کرنے کے لیے، یہ کافی ہے کہ API کے ذریعے صرف ریکارڈنگ کی جاتی ہے۔ مائیکرو سروسز کی آزادی کے بارے میں بات کرنے کے لیے یہ ایک ضروری شرط ہے۔ پڑھنے کے رابطے تب تک رہ سکتے ہیں جب تک کوئی بڑا مسئلہ نہ ہو۔

اگلا مرحلہ یہ ہے کہ ہم کوڈ کے اس حصے کو الگ کر سکتے ہیں جو علیحدہ میزوں کے ساتھ کام کرتا ہے، پروسیسنگ کے ساتھ یا بغیر، ایک علیحدہ مائیکرو سروس میں اور اسے ایک الگ پروسیس، ایک کنٹینر میں چلا سکتے ہیں۔ یہ ایک الگ سروس ہوگی جس کا یک سنگی ڈیٹا بیس اور ان ٹیبلز سے تعلق ہوگا جو اس سے براہ راست تعلق نہیں رکھتے ہیں۔ monolith اب بھی detachable حصے کے ساتھ پڑھنے کے لیے بات چیت کرتا ہے۔

بعد میں ہم اس کنکشن کو ہٹا دیں گے، یعنی علیحدہ جدولوں سے یک سنگی ایپلی کیشن کا ڈیٹا پڑھنا بھی API میں منتقل ہو جائے گا۔

اس کے بعد، ہم عام ڈیٹا بیس سے وہ ٹیبل منتخب کریں گے جن کے ساتھ صرف نئی مائیکرو سروس کام کرتی ہے۔ ہم ٹیبلز کو ایک علیحدہ اسکیما یا یہاں تک کہ ایک الگ فزیکل ڈیٹا بیس میں منتقل کر سکتے ہیں۔ مائیکرو سروس اور مونولتھ ڈیٹا بیس کے درمیان پڑھنے کا تعلق اب بھی موجود ہے، لیکن فکر کرنے کی کوئی بات نہیں ہے، اس ترتیب میں یہ کافی دیر تک زندہ رہ سکتا ہے۔

آخری مرحلہ تمام کنکشنز کو مکمل طور پر ہٹانا ہے۔ اس صورت میں، ہمیں مرکزی ڈیٹا بیس سے ڈیٹا منتقل کرنے کی ضرورت پڑ سکتی ہے۔ بعض اوقات ہم کئی ڈیٹا بیس میں بیرونی سسٹمز سے نقل کردہ کچھ ڈیٹا یا ڈائریکٹریز کو دوبارہ استعمال کرنا چاہتے ہیں۔ یہ ہمارے ساتھ وقتاً فوقتاً ہوتا رہتا ہے۔

محکمہ پروسیسنگ۔ یہ طریقہ پہلے سے بہت ملتا جلتا ہے، صرف الٹا ترتیب میں۔ ہم فوری طور پر ایک نیا ڈیٹا بیس اور ایک نئی مائیکرو سروس مختص کرتے ہیں جو ایک API کے ذریعے یک سنگی کے ساتھ تعامل کرتا ہے۔ لیکن ایک ہی وقت میں، ڈیٹا بیس ٹیبلز کا ایک سیٹ باقی ہے جسے ہم مستقبل میں حذف کرنا چاہتے ہیں۔ ہمیں اب اس کی ضرورت نہیں ہے؛ ہم نے اسے نئے ماڈل میں بدل دیا ہے۔

اس اسکیم کے کام کرنے کے لیے، ہمیں ممکنہ طور پر منتقلی کی مدت درکار ہوگی۔

پھر دو ممکنہ طریقے ہیں۔

پہلا: ہم تمام ڈیٹا کو نئے اور پرانے ڈیٹا بیس میں نقل کرتے ہیں۔ اس صورت میں، ہمارے پاس ڈیٹا بے کار ہے اور ہم وقت سازی کے مسائل پیدا ہو سکتے ہیں۔ لیکن ہم دو مختلف کلائنٹ لے سکتے ہیں۔ ایک نئے ورژن کے ساتھ کام کرے گا، دوسرا پرانے ورژن کے ساتھ۔

دوسرا: ہم ڈیٹا کو کچھ کاروباری معیارات کے مطابق تقسیم کرتے ہیں۔ مثال کے طور پر، ہمارے پاس سسٹم میں 5 پروڈکٹس تھے جو پرانے ڈیٹا بیس میں محفوظ تھے۔ ہم چھٹے کو نئے کاروباری کام کے اندر ایک نئے ڈیٹا بیس میں رکھتے ہیں۔ لیکن ہمیں ایک API گیٹ وے کی ضرورت ہوگی جو اس ڈیٹا کو سنکرونائز کرے گا اور کلائنٹ کو دکھائے گا کہ کہاں اور کیا حاصل کرنا ہے۔

دونوں نقطہ نظر کام کرتے ہیں، صورت حال پر منحصر ہے منتخب کریں.

جب ہم اس بات کا یقین کر لیں کہ سب کچھ کام کرتا ہے، یک سنگی کا وہ حصہ جو پرانے ڈیٹا بیس ڈھانچے کے ساتھ کام کرتا ہے کو غیر فعال کیا جا سکتا ہے۔

آخری مرحلہ پرانے ڈیٹا ڈھانچے کو ہٹانا ہے۔

خلاصہ کرنے کے لیے، ہم کہہ سکتے ہیں کہ ہمیں ڈیٹا بیس کے ساتھ مسائل ہیں: سورس کوڈ کے مقابلے میں اس کے ساتھ کام کرنا مشکل ہے، اس کا اشتراک کرنا زیادہ مشکل ہے، لیکن یہ کیا جا سکتا ہے اور ہونا چاہیے۔ ہمیں کچھ ایسے طریقے مل گئے ہیں جو ہمیں یہ کام کافی محفوظ طریقے سے کرنے کی اجازت دیتے ہیں، لیکن ماخذ کوڈ کے مقابلے میں ڈیٹا کے ساتھ غلطیاں کرنا اب بھی آسان ہے۔

سورس کوڈ کے ساتھ کام کرنا

جب ہم نے یک سنگی منصوبے کا تجزیہ کرنا شروع کیا تو سورس کوڈ کا خاکہ ایسا ہی نظر آتا تھا۔

اسے تقریباً تین تہوں میں تقسیم کیا جا سکتا ہے۔ یہ لانچ کردہ ماڈیولز، پلگ انز، خدمات اور انفرادی سرگرمیوں کی ایک پرت ہے۔ درحقیقت، یہ یک سنگی حل کے اندر داخلے کے مقامات تھے۔ ان سب کو کامن پرت کے ساتھ مضبوطی سے سیل کیا گیا تھا۔ اس میں کاروباری منطق تھی کہ خدمات کا اشتراک کیا گیا تھا اور بہت سارے رابطے تھے۔ ہر سروس اور پلگ ان 10 یا اس سے زیادہ عام اسمبلیوں تک استعمال کرتی ہے، ان کے سائز اور ڈویلپرز کے ضمیر پر منحصر ہے۔

ہم خوش قسمت تھے کہ انفراسٹرکچر لائبریریاں تھیں جو الگ سے استعمال کی جا سکتی تھیں۔

بعض اوقات ایسی صورت حال پیدا ہوتی ہے جب کچھ عام اشیاء درحقیقت اس تہہ سے تعلق نہیں رکھتی تھیں بلکہ بنیادی ڈھانچے کی لائبریریاں تھیں۔ یہ نام بدل کر حل ہو گیا۔

سب سے بڑی تشویش پابند سیاق و سباق تھی۔ ایسا ہوا کہ ایک مشترکہ اسمبلی میں 3-4 سیاق و سباق کو ملایا گیا اور ایک دوسرے کو ایک ہی کاروباری افعال میں استعمال کیا۔ یہ سمجھنا ضروری تھا کہ اسے کہاں تقسیم کیا جا سکتا ہے اور کن حدود کے ساتھ، اور اس تقسیم کو ماخذ کوڈ اسمبلیوں میں نقشہ بنانے کے ساتھ آگے کیا کرنا ہے۔

ہم نے کوڈ کی تقسیم کے عمل کے لیے کئی اصول وضع کیے ہیں۔

پہلے: ہم اب خدمات، سرگرمیوں اور پلگ ان کے درمیان کاروباری منطق کا اشتراک نہیں کرنا چاہتے تھے۔ ہم مائیکرو سروسز کے اندر کاروباری منطق کو آزاد بنانا چاہتے تھے۔ دوسری طرف، مائیکرو سروسز کو مثالی طور پر ایسی خدمات کے طور پر سمجھا جاتا ہے جو مکمل طور پر آزادانہ طور پر موجود ہوں۔ مجھے یقین ہے کہ یہ نقطہ نظر کچھ فضول ہے، اور اسے حاصل کرنا مشکل ہے، کیونکہ، مثال کے طور پر، C# میں خدمات کسی بھی صورت میں ایک معیاری لائبریری سے منسلک ہوں گی۔ ہمارا سسٹم C# میں لکھا ہوا ہے؛ ہم نے ابھی تک دوسری ٹیکنالوجیز استعمال نہیں کی ہیں۔ لہذا، ہم نے فیصلہ کیا کہ ہم مشترکہ تکنیکی اسمبلیوں کو استعمال کرنے کے متحمل ہوسکتے ہیں۔ اہم بات یہ ہے کہ ان میں کاروباری منطق کا کوئی حصہ نہیں ہے۔ اگر آپ کے پاس ORM پر سہولت کا ریپر ہے جسے آپ استعمال کر رہے ہیں، تو اسے سروس سے سروس میں کاپی کرنا بہت مہنگا ہے۔

ہماری ٹیم ڈومین سے چلنے والے ڈیزائن کی پرستار ہے، اس لیے پیاز کا فن تعمیر ہمارے لیے بہت موزوں تھا۔ ہماری خدمات کی بنیاد ڈیٹا تک رسائی کی پرت نہیں ہے، بلکہ ڈومین منطق کے ساتھ ایک اسمبلی ہے، جس میں صرف کاروباری منطق ہوتی ہے اور اس کا بنیادی ڈھانچے سے کوئی تعلق نہیں ہے۔ ایک ہی وقت میں، ہم فریم ورک سے متعلق مسائل کو حل کرنے کے لیے ڈومین اسمبلی کو آزادانہ طور پر تبدیل کر سکتے ہیں۔

اس مرحلے پر ہمیں اپنی پہلی سنگین پریشانی کا سامنا کرنا پڑا۔ سروس کو ایک ڈومین اسمبلی کا حوالہ دینا تھا، ہم منطق کو خود مختار بنانا چاہتے تھے، اور DRY اصول نے ہمیں یہاں بہت زیادہ روکا تھا۔ ڈویلپرز ڈپلیکیشن سے بچنے کے لیے پڑوسی اسمبلیوں کی کلاسوں کو دوبارہ استعمال کرنا چاہتے تھے، اور اس کے نتیجے میں، ڈومینز دوبارہ ایک ساتھ منسلک ہونا شروع ہوئے۔ ہم نے نتائج کا تجزیہ کیا اور فیصلہ کیا کہ شاید مسئلہ سورس کوڈ اسٹوریج ڈیوائس کے علاقے میں بھی ہے۔ ہمارے پاس ایک بڑا ذخیرہ تھا جس میں تمام سورس کوڈ موجود تھے۔ پورے منصوبے کا حل مقامی مشین پر جمع کرنا بہت مشکل تھا۔ لہذا، پروجیکٹ کے حصوں کے لیے الگ الگ چھوٹے حل بنائے گئے تھے، اور کسی نے ان میں کچھ عام یا ڈومین اسمبلی شامل کرنے اور انہیں دوبارہ استعمال کرنے سے منع نہیں کیا۔ واحد ٹول جس نے ہمیں ایسا کرنے کی اجازت نہیں دی وہ تھا کوڈ کا جائزہ۔ لیکن کبھی کبھی یہ ناکام بھی ہوتا ہے۔

پھر ہم نے الگ الگ ذخیروں والے ماڈل کی طرف جانا شروع کیا۔ کاروباری منطق اب سروس سے سروس تک نہیں جاتی ہے، ڈومینز صحیح معنوں میں خود مختار ہو چکے ہیں۔ پابند سیاق و سباق کو زیادہ واضح طور پر سپورٹ کیا جاتا ہے۔ ہم انفراسٹرکچر لائبریریوں کا دوبارہ استعمال کیسے کریں؟ ہم نے انہیں ایک علیحدہ ریپوزٹری میں الگ کیا، پھر انہیں Nuget پیکجوں میں ڈال دیا، جسے ہم آرٹی فیکٹری میں ڈالتے ہیں۔ کسی بھی تبدیلی کے ساتھ، اسمبلی اور اشاعت خود بخود ہوتی ہے۔

ہماری خدمات نے اندرونی انفراسٹرکچر پیکجوں کا اسی طرح حوالہ دینا شروع کیا جس طرح بیرونی۔ ہم نوگیٹ سے بیرونی لائبریریاں ڈاؤن لوڈ کرتے ہیں۔ آرٹفیکٹری کے ساتھ کام کرنے کے لیے، جہاں ہم نے ان پیکجوں کو رکھا، ہم نے دو پیکیج مینیجرز کا استعمال کیا۔ چھوٹے ذخیروں میں ہم نے نوگیٹ بھی استعمال کیا۔ متعدد خدمات کے ساتھ ذخیرہ خانوں میں، ہم نے Paket کا استعمال کیا، جو ماڈیولز کے درمیان زیادہ ورژن کی مستقل مزاجی فراہم کرتا ہے۔

اس طرح، سورس کوڈ پر کام کرکے، فن تعمیر کو قدرے تبدیل کرکے اور ذخیرہ خانوں کو الگ کرکے، ہم اپنی خدمات کو مزید خود مختار بناتے ہیں۔

انفراسٹرکچر کے مسائل

مائیکرو سروسز میں منتقل ہونے کے زیادہ تر نشیب و فراز بنیادی ڈھانچے سے متعلق ہیں۔ آپ کو خودکار تعیناتی کی ضرورت ہوگی، آپ کو بنیادی ڈھانچے کو چلانے کے لیے نئی لائبریریوں کی ضرورت ہوگی۔

ماحول میں دستی تنصیب

ابتدائی طور پر، ہم نے ماحول کے لیے حل دستی طور پر انسٹال کیا۔ اس عمل کو خودکار کرنے کے لیے، ہم نے ایک CI/CD پائپ لائن بنائی۔ ہم نے مسلسل ترسیل کے عمل کا انتخاب کیا کیونکہ کاروباری عمل کے نقطہ نظر سے مسلسل تعیناتی ہمارے لیے قابل قبول نہیں ہے۔ لہذا، آپریشن کے لئے بھیجنا ایک بٹن کا استعمال کرتے ہوئے کیا جاتا ہے، اور جانچ کے لئے - خود کار طریقے سے.

ہم سورس کوڈ اسٹوریج کے لیے Atlassian، Bitbucket اور عمارت کے لیے بانس استعمال کرتے ہیں۔ ہم کیک میں بلڈ اسکرپٹ لکھنا پسند کرتے ہیں کیونکہ یہ C# جیسا ہی ہے۔ ریڈی میڈ پیکجز آرٹفیکٹری میں آتے ہیں، اور Ansible خود بخود ٹیسٹ سرورز تک پہنچ جاتا ہے، جس کے بعد ان کا فوری تجربہ کیا جا سکتا ہے۔

الگ لاگنگ

ایک وقت میں، یک سنگی کے خیالات میں سے ایک مشترکہ لاگنگ فراہم کرنا تھا۔ ہمیں یہ سمجھنے کی بھی ضرورت تھی کہ ڈسک پر موجود انفرادی لاگز کے ساتھ کیا کرنا ہے۔ ہمارے لاگز ٹیکسٹ فائلوں پر لکھے جاتے ہیں۔ ہم نے ایک معیاری ELK اسٹیک استعمال کرنے کا فیصلہ کیا۔ ہم نے فراہم کنندگان کے ذریعے براہ راست ELK کو نہیں لکھا، لیکن فیصلہ کیا کہ ہم ٹیکسٹ لاگز کو حتمی شکل دیں گے اور ان میں ٹریس ID کو ایک شناخت کنندہ کے طور پر لکھیں گے، سروس کا نام شامل کریں گے، تاکہ ان لاگز کو بعد میں پارس کیا جا سکے۔

Filebeat کے ساتھ ہم اپنے لاگز کو جمع کرنے کے قابل ہیں۔ سرورز، پھر انہیں تبدیل کریں، UI میں استفسارات بنانے کے لیے Kibana کا استعمال کریں، اور دیکھیں کہ کال کو سروسز کے درمیان کیسے روٹ کیا گیا تھا۔ ٹریس آئی ڈی اس کے لیے بہت مددگار ہیں۔

متعلقہ خدمات کی جانچ اور ڈیبگنگ

ابتدائی طور پر، ہم پوری طرح سے سمجھ نہیں پائے تھے کہ تیار کی جا رہی خدمات کو کیسے ڈیبگ کیا جائے۔ یک سنگی کے ساتھ سب کچھ آسان تھا؛ ہم نے اسے مقامی مشین پر چلایا۔ پہلے تو انہوں نے مائیکرو سروسز کے ساتھ ایسا ہی کرنے کی کوشش کی، لیکن بعض اوقات ایک مائیکرو سروس کو مکمل طور پر لانچ کرنے کے لیے آپ کو کئی دیگر لانچ کرنے کی ضرورت ہوتی ہے، اور یہ تکلیف دہ ہے۔ ہم نے محسوس کیا کہ ہمیں ایک ایسے ماڈل پر جانے کی ضرورت ہے جہاں ہم مقامی مشین پر صرف وہی سروس یا خدمات چھوڑتے ہیں جنہیں ہم ڈیبگ کرنا چاہتے ہیں۔ باقی سروسز ان سرورز سے استعمال کی جاتی ہیں جو پروڈ کے ساتھ کنفیگریشن سے میل کھاتی ہیں۔ ڈیبگ کرنے کے بعد، جانچ کے دوران، ہر کام کے لیے، صرف تبدیل شدہ خدمات ٹیسٹ سرور کو جاری کی جاتی ہیں۔ اس طرح، حل کو اس شکل میں آزمایا جاتا ہے جس میں یہ مستقبل میں پیداوار میں ظاہر ہوگا۔

ایسے سرورز ہیں جو صرف خدمات کے پروڈکشن ورژن چلاتے ہیں۔ ان سرورز کی ضرورت واقعات کی صورت میں، تعیناتی سے پہلے ڈیلیوری چیک کرنے اور اندرونی تربیت کے لیے ہوتی ہے۔

ہم نے مشہور اسپیک فلو لائبریری کا استعمال کرتے ہوئے ایک خودکار جانچ کا عمل شامل کیا ہے۔ Ansible سے تعیناتی کے فوراً بعد NUnit کا استعمال کرتے ہوئے ٹیسٹ خود بخود چلتے ہیں۔ اگر کام کی کوریج مکمل طور پر خودکار ہے، تو پھر دستی جانچ کی ضرورت نہیں ہے۔ اگرچہ بعض اوقات اضافی دستی جانچ کی ضرورت ہوتی ہے۔ ہم جیرا میں ٹیگ استعمال کرتے ہیں اس بات کا تعین کرنے کے لیے کہ کسی مخصوص مسئلے کے لیے کون سے ٹیسٹ چلائے جائیں۔

مزید برآں، لوڈ ٹیسٹنگ کی ضرورت بڑھ گئی ہے؛ پہلے یہ صرف غیر معمولی معاملات میں کیا جاتا تھا۔ ہم ٹیسٹ چلانے کے لیے JMeter، ان کو ذخیرہ کرنے کے لیے InfluxDB، اور پراسیس گراف بنانے کے لیے Grafana کا استعمال کرتے ہیں۔

ہم نے کیا حاصل کیا ہے؟

سب سے پہلے، ہم نے "رہائی" کے تصور سے چھٹکارا حاصل کیا. دو ماہ کی خوفناک ریلیز ختم ہوگئیں جب اس کولاس کو پیداواری ماحول میں تعینات کیا گیا تھا، جس سے کاروباری عمل میں عارضی طور پر خلل پڑتا تھا۔ اب ہم خدمات کو اوسطاً ہر 1,5 دن میں تعینات کرتے ہیں، ان کو گروپ کرتے ہیں کیونکہ وہ منظوری کے بعد کام کرتی ہیں۔

ہمارے نظام میں کوئی مہلک ناکامی نہیں ہے۔ اگر ہم ایک بگ کے ساتھ مائیکرو سروس جاری کرتے ہیں، تو اس سے وابستہ فعالیت ٹوٹ جائے گی، اور دیگر تمام فعالیت متاثر نہیں ہوں گی۔ یہ صارف کے تجربے کو بہت بہتر بناتا ہے۔

ہم تعیناتی پیٹرن کو کنٹرول کر سکتے ہیں۔ اگر ضروری ہو تو آپ بقیہ حل سے الگ الگ خدمات کے گروپس کو منتخب کر سکتے ہیں۔

اس کے علاوہ، ہم نے بہتری کی ایک بڑی قطار کے ساتھ مسئلہ کو نمایاں طور پر کم کیا ہے۔ اب ہمارے پاس الگ الگ پروڈکٹ ٹیمیں ہیں جو کچھ خدمات کے ساتھ آزادانہ طور پر کام کرتی ہیں۔ سکرم کا عمل یہاں پہلے سے ہی مناسب ہے۔ ایک مخصوص ٹیم کے پاس ایک الگ پروڈکٹ کا مالک ہوسکتا ہے جو اسے کام تفویض کرتا ہے۔

خلاصہ

• مائیکرو سروسز پیچیدہ نظاموں کو گلنے کے لیے اچھی طرح سے موزوں ہیں۔ اس عمل میں، ہم یہ سمجھنے لگتے ہیں کہ ہمارے نظام میں کیا ہے، کون سے محدود سیاق و سباق ہیں، ان کی حدود کہاں ہیں۔ یہ آپ کو ماڈیولز میں بہتری کو صحیح طریقے سے تقسیم کرنے اور کوڈ کی الجھن کو روکنے کی اجازت دیتا ہے۔
• مائیکرو سروسز تنظیمی فوائد فراہم کرتی ہیں۔ ان کے بارے میں اکثر صرف فن تعمیر کے طور پر بات کی جاتی ہے، لیکن کسی بھی فن تعمیر کی ضرورت کاروباری ضروریات کو حل کرنے کے لیے ہوتی ہے، نہ کہ خود۔ لہذا، ہم کہہ سکتے ہیں کہ چھوٹی ٹیموں میں مسائل کو حل کرنے کے لیے مائیکرو سروسز اچھی طرح سے موزوں ہیں، اس لیے کہ Scrum اب بہت مقبول ہے۔
• علیحدگی ایک تکراری عمل ہے۔ آپ درخواست نہیں لے سکتے اور اسے صرف مائیکرو سروسز میں تقسیم کر سکتے ہیں۔ نتیجے میں مصنوعات کے فعال ہونے کا امکان نہیں ہے۔ مائیکرو سروسز کو وقف کرتے وقت، موجودہ میراث کو دوبارہ لکھنا فائدہ مند ہے، یعنی اسے کوڈ میں تبدیل کرنا جو ہمیں پسند ہے اور فعالیت اور رفتار کے لحاظ سے کاروباری ضروریات کو بہتر طریقے سے پورا کرتا ہے۔

  ایک چھوٹا سا انتباہ: مائیکرو سروسز میں جانے کے اخراجات کافی اہم ہیں۔ صرف انفراسٹرکچر کے مسئلے کو حل کرنے میں کافی وقت لگا۔ لہذا اگر آپ کے پاس ایک چھوٹی ایپلی کیشن ہے جس کے لیے مخصوص اسکیلنگ کی ضرورت نہیں ہے، جب تک کہ آپ کے پاس بڑی تعداد میں گاہک آپ کی ٹیم کی توجہ اور وقت کے لیے مقابلہ نہ کریں، تو مائیکرو سروسز شاید وہ نہ ہوں جس کی آپ کو آج ضرورت ہے۔ یہ کافی مہنگا ہے۔ اگر آپ مائیکرو سروسز کے ساتھ عمل شروع کرتے ہیں، تو ابتدائی طور پر اخراجات اس سے زیادہ ہوں گے جب آپ ایک ہی پروجیکٹ کو یک سنگی کی ترقی کے ساتھ شروع کرتے ہیں۔

  PS ایک زیادہ جذباتی کہانی (اور گویا آپ کے لیے ذاتی طور پر) - کے مطابق لنک.
  رپورٹ کا مکمل ورژن یہ ہے۔

ماخذ: www.habr.com