جاوا مائیکرو سروسز کے لیے ایک گائیڈ۔ حصہ 3: عمومی سوالات

جاوا مائیکرو سروسز کا ترجمہ اور موافقت : ایک عملی گائیڈ ۔ گائیڈ کے پچھلے حصے:

• مائیکرو سروسز کی بنیادی باتیں اور ان کا فن تعمیر
• مائیکرو سروسز کی تعیناتی اور جانچ

آئیے جاوا میں مائیکرو سروسز کے موروثی مسائل پر نظر ڈالتے ہیں، خلاصہ چیزوں سے شروع ہو کر اور کنکریٹ لائبریریوں پر ختم ہوتے ہیں۔

جاوا مائیکرو سروس کو لچکدار کیسے بنایا جائے؟

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

HTTP/REST لچک کے پیٹرنز

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

@Service
class BillingService {

    @Autowired
    private HttpClient client;

     public void bill(User user, Plan plan) {
        Invoice invoice = createInvoice(user, plan);
        httpClient.send(invoiceRequest(user.getEmail(), invoice), responseHandler());
        // ...
    }
}

خلاصہ کرنے کے لیے، یہاں اس HTTP کال کے تین ممکنہ نتائج ہیں۔

• ٹھیک ہے: کال گزر گئی، اکاؤنٹ کامیابی کے ساتھ بنایا گیا۔
• تاخیر: کال گزر گئی، لیکن اسے مکمل ہونے میں کافی وقت لگا۔
• غلطی۔ کال ناکام ہو گئی، ہو سکتا ہے آپ نے ایک غیر موازن درخواست بھیجی ہو، یا ہو سکتا ہے سسٹم کام نہ کر رہا ہو۔

کسی بھی پروگرام سے غلطی کی صورت حال سے نمٹنے کی توقع کی جاتی ہے، نہ صرف کامیاب۔ مائیکرو سروسز پر بھی یہی لاگو ہوتا ہے۔ یہاں تک کہ اگر آپ کو یہ یقینی بنانے کے لیے اضافی کوشش کرنے کی ضرورت ہے کہ ایک بار جب آپ انفرادی مائیکرو سروسز کی تعیناتیوں اور ریلیز کے ساتھ شروع کرتے ہیں تو API کے تمام متعین کردہ ورژن مطابقت رکھتے ہیں۔ دیکھنے کے لئے ایک دلچسپ معاملہ تاخیر کا معاملہ ہے۔ مثال کے طور پر، جواب دہندہ کی مائیکرو سروس ہارڈ ڈرائیو بھری ہوئی ہے، اور 50 ایم ایس لینے کے بجائے، جواب دینے میں 10 سیکنڈ لگتے ہیں۔ جب آپ کسی خاص بوجھ کا تجربہ کرتے ہیں تو یہ اور بھی دلچسپ ہو جاتا ہے کہ آپ کی بلنگ سروس کی غیر جوابدہی آپ کے سسٹم کے ذریعے پھیلنا شروع ہو جاتی ہے۔ ایک مثالی مثال کے طور پر، تصور کریں کہ ایک باورچی خانہ آہستہ آہستہ تمام ریستوراں کے ویٹروں کا "بلاک" شروع کر رہا ہے۔ یہ سیکشن ظاہر ہے کہ مائیکرو سرویس لچک کے موضوع کا مکمل جائزہ فراہم نہیں کر سکتا، لیکن یہ ڈویلپرز کے لیے ایک یاد دہانی کے طور پر کام کرتا ہے کہ یہ دراصل ایک ایسی چیز ہے جس پر توجہ دینے کی ضرورت ہے اور آپ کی پہلی ریلیز سے پہلے اسے نظر انداز نہیں کیا جانا چاہیے (جو، تجربے سے، اکثر ہوتا ہے۔ نہیں) پیروی کرتا ہے)۔ ایک مشہور لائبریری جو آپ کو تاخیر اور غلطی کو برداشت کرنے کے بارے میں سوچنے میں مدد کرتی ہے وہ ہے Netflix کی Hystrix۔ موضوع کی گہرائی میں جانے کے لیے اس کی دستاویزات کا استعمال کریں۔

پیغام رسانی لچک کے پیٹرن

آئیے غیر مطابقت پذیر مواصلات پر گہری نظر ڈالیں۔ ہمارا BillingService پروگرام اب کچھ اس طرح نظر آ سکتا ہے، یہ فرض کرتے ہوئے کہ ہم پیغام رسانی کے لیے Spring اور RabbitMQ استعمال کر رہے ہیں۔ ایک اکاؤنٹ بنانے کے لیے، اب ہم اپنے RabbitMQ میسج بروکر کو ایک پیغام بھیجتے ہیں، جہاں کئی کارکن نئے پیغامات کا انتظار کر رہے ہیں۔ یہ کارکن پی ڈی ایف انوائس بناتے ہیں اور مناسب صارفین کو بھیجتے ہیں۔

@Service
class BillingService {

    @Autowired
    private RabbitTemplate rabbitTemplate;

     public void bill(User user, Plan plan) {
        Invoice invoice = createInvoice(user, plan);
        // преобразует счет, например, в json и использует его How тело messages
        rabbitTemplate.convertAndSend(exchange, routingkey, invoice);
        // ...
    }
}

ممکنہ خرابیاں اب تھوڑی مختلف نظر آتی ہیں، کیونکہ اب آپ کو فوری طور پر OK یا ERROR کے جوابات موصول نہیں ہوتے جیسے کہ آپ نے مطابقت پذیر HTTP کنکشن کے ساتھ کیا تھا۔ اس کے بجائے، ہمارے پاس تین ممکنہ منظرنامے ہو سکتے ہیں جو غلط ہو سکتے ہیں، جو درج ذیل سوالات کو جنم دے سکتے ہیں:

1. کیا میرا پیغام ملازم نے پہنچایا اور استعمال کیا؟ یا یہ کھو گیا ہے؟ (صارف کو انوائس موصول نہیں ہوتی)۔
2. کیا میرا پیغام صرف ایک بار پہنچایا گیا تھا؟ یا ایک سے زیادہ بار پہنچایا اور صرف ایک بار کارروائی کی؟ (صارف کو متعدد رسیدیں موصول ہوں گی)۔
3. کنفیگریشن: "کیا میں نے تبادلے کے لیے صحیح روٹنگ کیز/نام استعمال کیے" سے لے کر "کیا میرے میسج بروکر نے درست طریقے سے ترتیب اور دیکھ بھال کی ہے یا اس کی قطاریں بھری ہوئی ہیں؟" (صارف کو انوائس موصول نہیں ہوتی)۔

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

• اگر آپ ایکٹو ایم کیو جیسے JMS نفاذ کا استعمال کر رہے ہیں، تو آپ دو فیز (XA) کمٹ کی گارنٹی کے لیے اسپیڈ ٹریڈ کر سکتے ہیں۔
• اگر آپ RabbitMQ استعمال کر رہے ہیں، تو پہلے اس گائیڈ کو پڑھیں، اور پھر تصدیقات، غلطی کو برداشت کرنے، اور عام طور پر پیغام کی بھروسے کے بارے میں غور سے سوچیں۔
• شاید کوئی ایکٹو یا ربیٹ ایم کیو سرورز کو ترتیب دینے میں ماہر ہو، خاص طور پر کلسٹرنگ اور ڈوکر کے ساتھ مل کر (کوئی؟ ؛))

جاوا مائیکرو سروسز کے لیے کون سا فریم ورک بہترین حل ہوگا؟

ایک طرف، آپ ایک بہت مقبول آپشن انسٹال کر سکتے ہیں جیسے Spring Boot ۔ یہ .jar فائلوں کو بنانا بہت آسان بناتا ہے، ایک بلٹ ان ویب سرور جیسے Tomcat یا Jetty کے ساتھ آتا ہے، اور اسے جلدی اور کہیں بھی چلایا جا سکتا ہے۔ مائیکرو سروس ایپلی کیشنز بنانے کے لیے مثالی۔ حال ہی میں، کچھ مخصوص مائیکرو سروس فریم ورک، Kubernetes یا GraalVM ، نمودار ہوئے، جزوی طور پر رد عمل والے پروگرامنگ سے متاثر ہوئے۔ یہاں کچھ اور دلچسپ دعویدار ہیں: Quarkus , Micronaut , Vert.x , Helidon . آخر میں، آپ کو اپنے لیے انتخاب کرنا پڑے گا، لیکن ہم آپ کو چند سفارشات دے سکتے ہیں جو مکمل طور پر معیاری نہیں ہو سکتیں: سپرنگ بوٹ کو چھوڑ کر، تمام مائیکرو سروسز کے فریم ورک کو عام طور پر ناقابل یقین حد تک تیزی سے مارکیٹ کیا جاتا ہے، تقریباً فوری آغاز کے ساتھ۔ ، میموری کا کم استعمال، لامحدودیت تک اسکیل ایبلٹی۔ مارکیٹنگ کے مواد میں عام طور پر متاثر کن گرافکس نمایاں ہوتے ہیں جو پلیٹ فارم کو بیہیمتھ اسپرنگ بوٹ کے ساتھ یا ایک دوسرے کے سامنے دکھاتے ہیں۔ یہ، تھیوری میں، پراجیکٹس کی حمایت کرنے والے ڈویلپرز کے اعصاب کو بچاتا ہے، جنہیں لوڈ ہونے میں بعض اوقات کئی منٹ لگتے ہیں۔ یا کلاؤڈ میں کام کرنے والے ڈویلپرز جو زیادہ سے زیادہ مائیکرو کنٹینرز کو 50 ms کے اندر شروع/ بند کرنا چاہتے ہیں۔ تاہم، مسئلہ یہ ہے کہ یہ (مصنوعی) ننگی دھات کے آغاز کے اوقات اور دوبارہ تعیناتی کے اوقات اس منصوبے کی مجموعی کامیابی میں مشکل سے حصہ ڈالتے ہیں۔ کم از کم وہ ایک مضبوط فریم ورک انفراسٹرکچر، مضبوط دستاویزات، کمیونٹی اور مضبوط ڈویلپر کی مہارت سے بہت کم اثر انداز ہوتے ہیں۔ تو اس کو اس طرح دیکھنا بہتر ہے: اگر اب تک:

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

اگر یہ معاملہ ہے، تو اضافی mycoservice مسائل (نیٹ ورک کی لچک، پیغام رسانی، DevOps، انفراسٹرکچر) کو شامل کرنے سے آپ کے پروجیکٹ پر خالی ہیلو، دنیا کو لوڈ کرنے سے کہیں زیادہ اثر پڑے گا۔ اور ترقی کے دوران گرم دوبارہ تعیناتیوں کے لیے، آپ JRebel یا DCEVM جیسے حل کے ساتھ ختم ہو سکتے ہیں ۔ آئیے سائمن براؤن کا ایک بار پھر حوالہ دیتے ہیں : " اگر لوگ (تیز اور موثر) یک سنگی تعمیر نہیں کر سکتے ہیں، تو ڈھانچے سے قطع نظر، انہیں (تیز اور موثر) مائیکرو سروسز بنانے میں مشکل پیش آئے گی ۔" لہذا اپنے فریم ورک کو سمجھداری سے منتخب کریں۔

ہم وقت ساز جاوا REST کالز کے لیے کون سی لائبریری بہترین ہیں؟

نچلے درجے کی تکنیکی طرف، آپ ممکنہ طور پر درج ذیل HTTP کلائنٹ لائبریریوں میں سے کسی ایک کے ساتھ ختم ہوں گے: Java کی مقامی HttpClient (جاوا 11 کے بعد سے)، Apache کا HttpClient ، یا OkHttp ۔ نوٹ کریں کہ میں یہاں "شاید" کہتا ہوں کیونکہ اچھے پرانے JAX-RS کلائنٹس سے لے کر جدید WebSocket کلائنٹس تک اور بھی آپشنز موجود ہیں ۔ کسی بھی صورت میں، رجحان ایک HTTP کلائنٹ پیدا کرنے کی طرف ہے، خود HTTP کالز کے ساتھ گھومنے پھرنے سے ہٹ کر۔ ایسا کرنے کے لیے، آپ کو OpenFeign پروجیکٹ اور مزید پڑھنے کے لیے ابتدائی نقطہ کے طور پر اس کی دستاویزات پر ایک نظر ڈالنے کی ضرورت ہے۔

غیر مطابقت پذیر جاوا پیغام رسانی کے لیے بہترین بروکرز کون سے ہیں؟

غالباً، آپ کو مقبول ایکٹو ایم کیو (کلاسک یا آرٹیمس) ، RabbitMQ یا Kafka ملیں گے ۔

• ActiveMQ اور RabbitMQ روایتی، مکمل میسج بروکرز ہیں۔ ان میں "سمارٹ بروکر" اور "بیوقوف صارفین" کا تعامل شامل ہے۔
• تاریخی طور پر، ActiveMQ کو آسان ان لائننگ (ٹیسٹنگ کے لیے) کا فائدہ حاصل ہوا ہے، جسے RabbitMQ/Docker/TestContainer کی ترتیبات سے کم کیا جا سکتا ہے۔
• کافکا کو روایتی "سمارٹ" بروکر نہیں کہا جا سکتا۔ اس کے بجائے، یہ نسبتاً "گونگا" میسج اسٹور (لاگ فائل) ہے جس پر عمل کرنے کے لیے ہوشیار صارفین کی ضرورت ہوتی ہے۔

RabbitMQ (یا عام طور پر دوسرے روایتی میسج بروکرز) یا کافکا کو کب استعمال کرنا ہے اس کو بہتر طور پر سمجھنے کے لیے، نقطہ آغاز کے طور پر اس اہم پوسٹ پر ایک نظر ڈالیں۔ عام طور پر، میسجنگ بروکر کا انتخاب کرتے وقت، مصنوعی کارکردگی کی وجوہات کو نظر انداز کرنے کی کوشش کریں۔ ایک وقت تھا جب ٹیمیں اور آن لائن کمیونٹیز اس بارے میں مسلسل بحث کرتی تھیں کہ RabbitMQ کتنا تیز تھا اور ActiveMQ کتنا سست تھا۔ اب یہی دلیلیں RabbitMQ کے حوالے سے دی جاتی ہیں، وہ کہتے ہیں کہ یہ 20-30 ہزار پیغامات فی سیکنڈ کے ساتھ آہستہ کام کرتا ہے۔ کافکا 100 ہزار پیغامات فی سیکنڈ ریکارڈ کرتا ہے۔ سچ کہوں تو، اس طرح کا موازنہ نرم سے گرم کا موازنہ کرنے کے مترادف ہے۔ مزید برآں، دونوں صورتوں میں تھرو پٹ ویلیوز علی بابا گروپ کی کم سے درمیانی حد میں ہو سکتی ہیں۔ تاہم، آپ کو حقیقت میں اس پیمانے کے منصوبوں (لاکھوں پیغامات فی منٹ) کا سامنا کرنے کا امکان نہیں ہے۔ وہ یقینی طور پر موجود ہیں اور انہیں پریشانی ہوگی۔ دوسرے 99% "باقاعدہ" جاوا کاروباری منصوبوں کے برعکس۔ اس لیے فیشن اور ہائپ پر توجہ نہ دیں۔ سمجھداری سے انتخاب کرو.

مائیکرو سروسز کو جانچنے کے لیے میں کن لائبریریوں کا استعمال کر سکتا ہوں؟

یہ آپ کے اسٹیک پر منحصر ہے۔ اگر آپ کے پاس اسپرنگ ایکو سسٹم تعینات ہے، تو فریم ورک کے مخصوص ٹولز کو استعمال کرنا دانشمندی ہوگی ۔ اگر JavaEE Arquillian کی طرح کچھ ہے ۔ یہ Docker اور واقعی اچھی Testcontainers لائبریری پر ایک نظر ڈالنے کے قابل ہو سکتا ہے ، جو خاص طور پر مقامی ترقی یا انضمام کے ٹیسٹ کے لیے اوریکل ڈیٹا بیس کو آسانی سے اور تیزی سے ترتیب دینے میں مدد کرتا ہے۔ پورے HTTP سرورز کی فرضی جانچ کے لیے، Wiremock کو چیک کریں ۔ غیر مطابقت پذیر پیغام رسانی کی جانچ کرنے کے لیے، ActiveMQ یا RabbitMQ کو لاگو کرنے کی کوشش کریں اور پھر Awaitility DSL کا استعمال کرتے ہوئے ٹیسٹ لکھیں ۔ اس کے علاوہ، آپ کے تمام معمول کے اوزار استعمال کیے جاتے ہیں - Junit ، TestNG for AssertJ اور Mockito ۔ براہ کرم نوٹ کریں کہ یہ مکمل فہرست نہیں ہے۔ اگر آپ کو اپنا پسندیدہ ٹول یہاں نہیں ملتا ہے، تو براہ کرم اسے تبصرے کے سیکشن میں پوسٹ کریں۔

تمام جاوا مائیکرو سروسز کے لیے لاگنگ کو کیسے فعال کیا جائے؟

مائیکرو سروسز کے معاملے میں لاگ ان کرنا ایک دلچسپ اور پیچیدہ موضوع ہے۔ ایک لاگ فائل رکھنے کے بجائے جسے آپ کم یا گریپ کمانڈز کے ساتھ جوڑ توڑ کر سکتے ہیں، اب آپ کے پاس n لاگ فائلیں ہیں، اور آپ چاہتے ہیں کہ وہ زیادہ بکھری نہ جائیں۔ لاگنگ ایکو سسٹم کی خصوصیات اس مضمون (انگریزی میں) میں اچھی طرح بیان کی گئی ہیں۔ اسے ضرور پڑھیں، اور مائیکرو سروسز کے نقطہ نظر سے سنٹرلائزڈ لاگنگ سیکشن پر توجہ دیں ۔ عملی طور پر، آپ کو مختلف انداز نظر آئیں گے: سسٹم ایڈمنسٹریٹر کچھ اسکرپٹ لکھتا ہے جو مختلف سرورز سے لاگ فائلوں کو اکٹھا اور یکجا کرکے ایک لاگ فائل میں FTP سرورز پر ڈالتا ہے۔ متوازی SSH سیشنز میں cat/grep/unig/sort امتزاج چلانا۔ یہ بالکل وہی ہے جو Amazon AWS کرتا ہے، اور آپ اپنے مینیجر کو بتا سکتے ہیں۔ Graylog یا ELK Stack جیسے ٹول کا استعمال کریں (Elasticsearch، Logstash، Kibana)

میری مائیکرو سروسز ایک دوسرے کو کیسے تلاش کرتی ہیں؟

اب تک، ہم نے فرض کیا ہے کہ ہماری مائیکرو سروسز ایک دوسرے کے بارے میں جانتی ہیں اور متعلقہ IPS کو جانتی ہیں۔ آئیے جامد ترتیب کے بارے میں بات کرتے ہیں۔ لہذا، ہمارا بینکنگ monolith [ip = 192.168.200.1] جانتا ہے کہ اسے رسک سرور [ip = 192.168.200.2] سے بات کرنے کی ضرورت ہے، جو پراپرٹی فائل میں ہارڈ کوڈ ہے۔ تاہم، آپ چیزوں کو زیادہ متحرک بنا سکتے ہیں:

• ایک کلاؤڈ بیسڈ کنفیگریشن سرور استعمال کریں جس سے تمام مائیکرو سروسز اپنی مائیکرو سروسز پر application.properties فائلوں کو تعینات کرنے کے بجائے اپنی کنفیگریشن کھینچتی ہیں۔
• چونکہ آپ کی سروس کی مثالیں متحرک طور پر اپنا مقام تبدیل کر سکتی ہیں، اس لیے ان سروسز کو دیکھنا قابل قدر ہے جو جانتی ہیں کہ آپ کی سروسز کہاں رہتی ہیں، ان کے IPs کیا ہیں، اور انہیں کیسے روٹ کرنا ہے۔
• اب جب کہ سب کچھ متحرک ہے، نئے مسائل پیدا ہوتے ہیں، جیسے کہ لیڈر کا خودکار انتخاب: وہ ماسٹر کون ہے جو کچھ کاموں پر کام کرتا ہے، مثال کے طور پر ان پر دو بار کارروائی نہ کرے؟ جب کوئی لیڈر ناکام ہوتا ہے تو اس کی جگہ کون لیتا ہے؟ تبدیلی کس بنیاد پر ہوتی ہے؟

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

جاوا مائیکرو سروسز کا استعمال کرتے ہوئے اجازت اور توثیق کو کیسے منظم کیا جائے؟

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

میں یہ کیسے یقینی بنا سکتا ہوں کہ میرے تمام ماحول ایک جیسے نظر آتے ہیں؟

مائیکرو سروس کے بغیر تعیناتیوں کے لیے جو سچ ہے وہی ایک کے ساتھ تعیناتیوں کے لیے بھی درست ہے۔ Docker/Testcontainers اور Scripting/Ansible کا مجموعہ آزمائیں۔

کوئی سوال نہیں: مختصر طور پر YAML کے بارے میں

آئیے ایک لمحے کے لیے لائبریریوں اور متعلقہ مسائل سے ہٹ کر یمل پر ایک سرسری نظر ڈالیں۔ اس فائل فارمیٹ کو ڈی فیکٹو فارمیٹ کے طور پر "کوڈ کے طور پر کنفیگریشن لکھنا" کے لیے استعمال کیا جاتا ہے۔ یہ آسان ٹولز جیسے Ansible اور کبرنیٹس جیسے جنات کے ذریعہ بھی استعمال ہوتا ہے۔ YAML انڈینٹیشن کے درد کا تجربہ کرنے کے لیے، ایک سادہ Ansible فائل لکھنے کی کوشش کریں اور دیکھیں کہ اس سے پہلے کہ یہ توقع کے مطابق کام کرے آپ کو فائل میں کتنی ترمیم کرنی ہوگی۔ اور یہ تمام بڑے IDEs کے ذریعہ فارمیٹ کی حمایت کے باوجود! اس کے بعد، اس گائیڈ کو پڑھنا ختم کرنے کے لیے واپس آئیں۔

Yaml:
  - is:
    - so
    - great

تقسیم شدہ لین دین کے بارے میں کیا خیال ہے؟ کارکردگی کی جانچ؟ دیگر موضوعات؟

شاید کسی دن، دستی کے مستقبل کے ایڈیشن میں۔ ابھی کے لئے، یہ سب ہے. ہمارے ساتھ رہو!

مائیکرو سروسز کے ساتھ تصوراتی مسائل

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

فرنٹ اینڈ اور بیک اینڈ میں مماثلت نہیں ہے۔

بہت سے مائیکرو سروس پروجیکٹس میں فرنٹ اینڈ اور بیک اینڈ کی مماثلت ایک بہت عام مسئلہ ہے۔ اس کا کیا مطلب ہے؟ صرف یہ کہ اچھے پرانے monoliths میں، ویب انٹرفیس ڈویلپرز کے پاس ڈیٹا حاصل کرنے کا ایک مخصوص ذریعہ تھا۔ مائیکرو سروس پروجیکٹس میں، فرنٹ اینڈ ڈویلپرز کے پاس اچانک ڈیٹا حاصل کرنے کے لیے ذرائع ہوتے ہیں۔ تصور کریں کہ آپ جاوا میں کسی قسم کا IoT (انٹرنیٹ آف تھنگز) مائیکرو سروسز پروجیکٹ بنا رہے ہیں۔ ہم کہتے ہیں کہ آپ پورے یورپ میں جیوڈیٹک مشینوں اور صنعتی بھٹیوں کا انتظام کرتے ہیں۔ اور یہ اوون آپ کو اپنے درجہ حرارت اور اس طرح کے ساتھ باقاعدہ اپ ڈیٹ بھیجتے ہیں۔ جلد یا بدیر آپ ایڈمن UI میں اوون تلاش کرنا چاہیں گے، شاید "فرنس سرچ" مائیکرو سروسز کا استعمال کرتے ہوئے۔ اس بات پر منحصر ہے کہ آپ کے بیک اینڈ ہم منصب ڈومین سے چلنے والے ڈیزائن یا مائیکرو سروس قوانین کو کس حد تک سختی سے لاگو کرتے ہیں، ایک "فائنڈ اوون" مائیکرو سروس صرف اوون آئی ڈیز واپس کر سکتی ہے نہ کہ دیگر ڈیٹا جیسے کہ قسم، ماڈل یا مقام۔ ایسا کرنے کے لیے، فرنٹ اینڈ ڈویلپرز کو پہلی مائیکرو سروس سے موصول ہونے والی آئی ڈیز کے ساتھ "فرنس ڈیٹا حاصل کریں" مائیکرو سروس میں ایک یا این اضافی کالز کرنے کی ضرورت ہوگی۔ اور اگرچہ یہ صرف ایک سادہ سی مثال ہے، اگرچہ ایک حقیقی (!) پروجیکٹ سے لیا گیا ہے، یہاں تک کہ یہ مندرجہ ذیل مسئلہ کو ظاہر کرتا ہے: سپر مارکیٹیں انتہائی مقبول ہو چکی ہیں۔ اس کی وجہ یہ ہے کہ ان کے ساتھ آپ کو سبزیاں، لیمونیڈ، فروزن پیزا اور ٹوائلٹ پیپر خریدنے کے لیے 10 مختلف جگہوں پر جانے کی ضرورت نہیں ہے۔ اس کے بجائے، آپ ایک جگہ جاتے ہیں۔ یہ آسان اور تیز تر ہے۔ فرنٹ اینڈ اور مائیکرو سروس ڈویلپرز کے لیے بھی یہی ہے۔

انتظامیہ کی توقعات

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

"چھوٹے ٹکڑے" "بہتر ٹکڑے" کے برابر نہیں ہوتے

یہ سمجھنا بہت بڑی غلطی ہوگی کہ 20 حصوں میں تقسیم شدہ کوڈ لازمی طور پر ایک پورے ٹکڑے سے اعلیٰ معیار کا ہوگا۔ یہاں تک کہ اگر ہم معیار کو خالصتاً تکنیکی نقطہ نظر سے لیتے ہیں، تب بھی ہماری انفرادی خدمات ڈیٹا بیس سے صارف کو منتخب کرنے کے لیے 400 ہائبرنیٹ سوالات چلا رہی ہوں گی، غیر تعاون یافتہ کوڈ کی تہوں کو عبور کرتے ہوئے ایک بار پھر، ہم سائمن براؤن کے اقتباس پر واپس آتے ہیں: اگر آپ monoliths کو صحیح طریقے سے بنانے میں ناکام رہتے ہیں، تو مناسب مائیکرو سروسز بنانا مشکل ہو جائے گا۔ مائیکرو سروس پراجیکٹس میں غلطی کی رواداری کے بارے میں بات کرنے میں اکثر دیر ہو جاتی ہے۔ اتنا زیادہ کہ بعض اوقات یہ دیکھنا خوفناک ہوتا ہے کہ حقیقی پروجیکٹس میں مائیکرو سروسز کیسے کام کرتی ہیں۔ اس کی وجہ یہ ہے کہ جاوا کے ڈویلپرز غلطی برداشت کرنے، نیٹ ورکنگ اور دیگر متعلقہ موضوعات کا مناسب سطح پر مطالعہ کرنے کے لیے ہمیشہ تیار نہیں ہوتے ہیں۔ "ٹکڑے" خود چھوٹے ہیں، لیکن "تکنیکی حصے" بڑے ہیں۔ تصور کریں کہ آپ کی مائیکرو سروسز ٹیم کو ڈیٹا بیس سسٹم میں لاگ ان کرنے کے لیے تکنیکی مائیکرو سروس لکھنے کے لیے کہا گیا ہے، کچھ اس طرح:

@Controller
class LoginController {
    // ...
    @PostMapping("/login")
    public boolean login(String username, String password) {
        User user = userDao.findByUserName(username);
        if (user == null) {
            // обработка варианта с несуществующим пользователем
            return false;
        }
        if (!user.getPassword().equals(hashed(password))) {
            // обработка неверного пароля
            return false;
        }
        // 'Ю-ху, залогинorсь!';
        // установите cookies, делайте, что угодно
        return true;
    }
}

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

کم ٹکڑے - کم سمجھ

پھر یہ سوال قدرتی طور پر سسٹم کو مجموعی طور پر سمجھنے، اس کے عمل اور کام کے بہاؤ کے بارے میں سامنے آتا ہے، لیکن اس کے ساتھ ساتھ آپ، ایک ڈویلپر کے طور پر، صرف اپنی الگ تھلگ مائیکرو سروس [95: لاگ ان-101: updateUserProfile] پر کام کرنے کے ذمہ دار ہیں۔ یہ پچھلے پیراگراف سے ہم آہنگ ہے، لیکن آپ کی تنظیم، اعتماد کی سطح اور کمیونیکیشن کی بنیاد پر، اگر مائیکرو سروس چین میں حادثاتی طور پر خرابی ہو جاتی ہے تو یہ بہت زیادہ الجھنوں، کندھے اچکانے اور الزام تراشی کا باعث بن سکتا ہے۔ اور جو کچھ ہوا اس کی پوری ذمہ داری لینے والا کوئی نہیں۔ اور یہ بالکل بھی بے ایمانی کی بات نہیں ہے۔ درحقیقت مختلف حصوں کو جوڑنا اور پروجیکٹ کی مجموعی تصویر میں ان کی جگہ کو سمجھنا بہت مشکل ہے۔

مواصلات اور خدمات

کمپنی کے سائز کے لحاظ سے مواصلات اور خدمات کی سطح بہت مختلف ہوتی ہے۔ تاہم، عمومی تعلق واضح ہے: جتنا زیادہ، اتنا ہی زیادہ مسئلہ۔

• مائیکرو سروس #47 کون چلاتا ہے؟
• کیا انہوں نے صرف ایک مائیکرو سروس کا ایک نیا، غیر مطابقت پذیر ورژن تعینات کیا ہے؟ یہ دستاویزی کہاں تھی؟
• ایک نئی خصوصیت کی درخواست کرنے کے لیے مجھے کس سے بات کرنے کی ضرورت ہے؟
• ایرلنگ میں اس مائیکرو سروس کو کون سپورٹ کرے گا، اس زبان کے جاننے والے کے بعد کمپنی چھوڑ دی؟
• ہماری تمام مائیکرو سروس ٹیمیں نہ صرف مختلف پروگرامنگ زبانوں میں بلکہ مختلف ٹائم زونز میں بھی کام کرتی ہیں! ہم اس سب کو صحیح طریقے سے کیسے مربوط کرتے ہیں؟

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

نتائج

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

مائیکرو سروسز یا یک سنگی؟

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

مائیکرو سروسز اضافی پیچیدگی پیدا کرتی ہیں۔

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

کیا یہ جاوا مائیکرو سروسز بنانے کے قابل ہے؟

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

منظر نامے

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

سوال

آپ کے ڈیٹا بیس سرور پر آپ کے جاوا مونولتھ (کنکشن پول) کو کتنے ڈیٹا بیس کنکشن کھولنے چاہئیں؟ ایسا کیوں ہے؟ آپ کے خیال میں کتنے کنکرنٹ فعال صارفین ہیں جو آپ کا مونولیتھ (تقریباً) پیمانہ بنا سکتا ہے؟

جواب دیں۔

ان سوالات کے اپنے جواب تبصرے کے سیکشن میں چھوڑیں۔ میں تمام جوابات کا منتظر ہوں۔ اب اپنا ذہن بنا لیں۔ اگر آپ آخر تک پڑھتے ہیں، تو ہم آپ کے بہت مشکور ہیں!