جاوا مائیکرو سروسز کے لیے ایک گائیڈ۔ حصہ 1: مائیکرو سروسز کی بنیادی باتیں اور فن تعمیر

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

جاوا مائیکرو سروسز: بنیادی باتیں

مائیکرو سروسز کو سمجھنے کے لیے، آپ کو پہلے اس بات کی وضاحت کرنی چاہیے کہ وہ کیا نہیں ہیں۔ کیا یہ ایک "monolith" نہیں ہے - Java monolith: یہ کیا ہے اور اس کے فوائد یا نقصانات کیا ہیں؟

جاوا یک سنگی کیا ہے؟

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

@Controller
class BankController {

    @PostMapping("/users/register")
    public void register(RegistrationForm form) {
        validate(form);
        riskCheck(form);
        openBankAccount(form);
        // etc..
    }
}

آپ کو کنٹرولر کی ضرورت ہے:

1. رجسٹریشن فارم کی تصدیق کی۔
2. صارف کے ایڈریس کے خطرات کو چیک کیا تاکہ فیصلہ کیا جا سکے کہ آیا اسے بینک اکاؤنٹ فراہم کرنا ہے۔
3. بینک اکاؤنٹ کھولا۔

کلاس کو BankControllerآپ کے باقی ذرائع کے ساتھ تعیناتی کے لیے ایک bank.jar یا bank.war فائل میں پیک کیا جائے گا - یہ ایک اچھا پرانا یک سنگی ہے جس میں آپ کے بینک کو چلانے کے لیے درکار تمام کوڈ موجود ہیں۔ ایک موٹے اندازے کے مطابق، .jar (یا .war) فائل کا ابتدائی سائز 1 سے 100 MB تک ہوگا۔ اب آپ اپنے سرور پر .jar فائل کو آسانی سے چلا سکتے ہیں... اور آپ کو اپنی جاوا ایپلیکیشن کو تعینات کرنے کے لیے بس اتنا ہی کرنا ہے۔ تصویر، اوپر بائیں مستطیل: mono(lithic) بینک java-jar bank.jar (cp .war/.ear in appserver) کی تعیناتی۔ دائیں مستطیل: اوپن براؤزر۔

جاوا monoliths کے ساتھ کیا مسئلہ ہے؟

جاوا یک سنگی کے ساتھ فطری طور پر کچھ بھی غلط نہیں ہے۔ تاہم، تجربے سے پتہ چلتا ہے کہ اگر آپ کے پروجیکٹ میں:

• بہت سے پروگرامر/ٹیم/کنسلٹنٹس کام کر رہے ہیں...
• ...بہت مبہم تقاضوں کے ساتھ صارفین کے دباؤ میں اسی یک سنگی پر...
• ایک دو سال کے اندر...

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

جاوا یک سنگی کے سائز کو کیسے کم کیا جائے؟

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

جاوا مائیکرو سروس کیا ہے؟

عملی طور پر، اس جملے کا مطلب ہے کہ اب بینک کنٹرولر سے میتھڈ کال riskCheck()نہیں کی جائے گی: یہ طریقہ یا بین جزو اپنی تمام معاون کلاسوں کے ساتھ اس کے اپنے Maven یا Gradle پروجیکٹ میں منتقل ہو جائے گا۔ اسے بھی تعینات کیا جائے گا اور بینکنگ یک سنگی سے آزادانہ طور پر ورژن کنٹرول میں رکھا جائے گا۔ تاہم، نکالنے کا یہ پورا عمل آپ کے نئے RiskCheck ماڈیول کو ایک مائیکرو سروس میں تبدیل نہیں کرتا ہے، کیونکہ مائیکرو سروس کی تعریف تشریح کے لیے کھلی ہے۔ یہ ٹیموں اور کمپنیوں کے اندر اکثر بات چیت کی طرف جاتا ہے.

• کیا ایک پروجیکٹ میں 5-7 کلاسز مائیکرو ہیں یا کیا؟
• 100 یا 1000 کلاسز... پھر بھی مائیکرو؟
• کیا مائیکرو سروس کا تعلق عام طور پر کلاسز کی تعداد سے ہے یا نہیں؟

آئیے نظریاتی استدلال کو پیچھے چھوڑتے ہیں، اور اس کے بجائے عملی خیالات پر قائم رہتے ہیں اور یہ کرتے ہیں:

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

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

جاوا مائیکرو سروسز کے درمیان مواصلت کیسے قائم کی جائے؟

عام طور پر اور عام طور پر، دو اختیارات ہیں - مطابقت پذیر اور غیر مطابقت پذیر مواصلات.

ہم وقت ساز مواصلات: (HTTP)/REST

عام طور پر، مائیکرو سروسز کے درمیان مطابقت پذیر مواصلت HTTP اور REST جیسی سروسز کے ذریعے ہوتی ہے جو XML یا JSON کو واپس کرتی ہیں۔ بلاشبہ، اور بھی آپشنز ہو سکتے ہیں - کم از کم گوگل پروٹوکول بفرز لیں ۔ اگر آپ کو فوری جواب درکار ہے تو بہتر ہے کہ REST کمیونیکیشن کا استعمال کریں۔ ہماری مثال میں، بالکل وہی ہے جو کرنے کی ضرورت ہے، کیونکہ اکاؤنٹ کھولنے سے پہلے خطرے کی تصدیق کی ضرورت ہوتی ہے۔ اگر کوئی رسک چیکنگ نہیں ہے تو کوئی اکاؤنٹ نہیں ہے۔ ہم ذیل میں ٹولز پر تبادلہ خیال کریں گے، سیکشن میں " کون سی لائبریریاں سنکرونس جاوا ریسٹ کالز کے لیے بہترین ہیں "۔

پیغام رسانی - غیر مطابقت پذیر مواصلات

غیر مطابقت پذیر مائیکرو سروس کمیونیکیشن عام طور پر JMS کے نفاذ کے ساتھ پیغامات کے تبادلے اور/یا AMQP جیسے پروٹوکول کا استعمال کرتے ہوئے مکمل کیا جاتا ہے ۔ ہم نے یہاں "عام طور پر" ایک وجہ سے لکھا: آئیے کہتے ہیں کہ ای میل/SMTP انضمام کی تعداد کو کم نہیں سمجھا جا سکتا۔ جب آپ کو فوری جواب کی ضرورت نہ ہو تو اسے استعمال کریں۔ مثال کے طور پر، صارف "ابھی خریدیں" کے بٹن پر کلک کرتا ہے، اور آپ، بدلے میں، ایک رسید بنانا چاہتے ہیں۔ یہ عمل یقینی طور پر صارف کی خریداری کی درخواست کے جواب کے چکر میں نہیں ہونا چاہیے۔ ذیل میں ہم بیان کریں گے کہ کون سے ٹولز غیر مطابقت پذیر Java پیغام رسانی کے لیے بہترین ہیں ۔

مثال: جاوا میں REST API کال

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

@Controller
class BankController {

    @Autowired
    private HttpClient httpClient;

    @PostMapping("/users/register")
    public void register(RegistrationForm form) {
        validate(form);
        httpClient.send(riskRequest, responseHandler());
        setupAccount(form);
        // etc..
    }
}

کوڈ کی بنیاد پر، یہ واضح ہو جاتا ہے کہ اب ہمیں دو جاوا (مائکرو) سروسز، بینک اور رسک چیک کو تعینات کرنے کی ضرورت ہے۔ نتیجے کے طور پر، ہمارے پاس دو JVM عمل چل رہے ہوں گے۔ جاوا مائیکرو سروسز پراجیکٹ تیار کرنے کے لیے آپ کو بس اتنا ہی درکار ہے: صرف ایک یک سنگی کے بجائے چھوٹے ٹکڑوں (.jar یا .war فائلوں) کو بنائیں اور ان کو تعینات کریں۔ سوال کا جواب ابھی تک واضح نہیں ہے: ہمیں مائیکرو سروسز میں یک سنگی کو کیسے کاٹنا چاہئے؟ یہ ٹکڑے کتنے چھوٹے ہونے چاہئیں، صحیح سائز کا تعین کیسے کریں؟ آؤ دیکھیں.

جاوا مائیکرو سروسز آرکیٹیکچر

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

یک سنگی سے مائیکرو سروسز تک

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

آئیڈیا: یک سنگی کو مائیکرو سروسز میں توڑ دیں۔

میراثی منصوبوں پر مائیکرو سروس اپروچ کا اطلاق کیا جا سکتا ہے۔ اور اسی لیے:

1. اکثر، ایسے منصوبوں کو برقرار رکھنا/تبدیل کرنا/بڑھانا مشکل ہوتا ہے۔
2. ہر کوئی، ڈویلپرز سے لے کر انتظامیہ تک، آسانیاں چاہتا ہے۔
3. آپ کے پاس (نسبتاً) واضح ڈومین کی حدود ہیں، یعنی آپ بالکل جانتے ہیں کہ آپ کے سافٹ ویئر کو کیا کرنا چاہیے۔

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

• لہذا، صارف کے ڈیٹا (جیسے نام، پتے، فون نمبرز) کی پروسیسنگ کو ایک الگ مائیکرو سروس "اکاؤنٹ مینجمنٹ" میں الگ کرنا مناسب ہوگا۔
• یا مذکورہ بالا "Risk Checker Module" جو صارف کے خطرے کی سطح کو چیک کرتا ہے اور اسے کمپنی کے بہت سے دوسرے پروجیکٹس یا یہاں تک کہ محکمے استعمال کر سکتے ہیں۔
• یا ایک انوائسنگ ماڈیول جو پی ڈی ایف فارمیٹ میں یا میل کے ذریعے انوائس بھیجتا ہے۔

ایک خیال کا نفاذ: کسی اور کو کرنے دیں۔

اوپر بیان کردہ نقطہ نظر کاغذ اور UML جیسے خاکوں پر بہت اچھا لگتا ہے۔ تاہم، سب کچھ اتنا آسان نہیں ہے. اس کے عملی نفاذ کے لیے سنجیدگی سے تکنیکی تیاری کی ضرورت ہوتی ہے: ہماری سمجھ کے درمیان کہ ایک سنگی پتھر سے کیا نکالنا اچھا ہو گا اور نکالنے کے عمل کے درمیان فاصلہ بہت زیادہ ہے۔ زیادہ تر انٹرپرائز پروجیکٹ اس مرحلے پر پہنچ جاتے ہیں جہاں ڈویلپرز ہائبرنیٹ کے 7 سالہ پرانے ورژن کو نئے ورژن میں اپ گریڈ کرنے سے ڈرتے ہیں۔ اس کے ساتھ لائبریریوں کو اپ ڈیٹ کیا جائے گا، لیکن کسی چیز کے ٹوٹنے کا حقیقی خطرہ ہے۔ تو اب وہی ڈویلپرز کو قدیم میراثی کوڈ کو غیر واضح ڈیٹا بیس لین دین کی حدود کے ساتھ کھودنا ہوگا اور اچھی طرح سے متعین مائکرو سروسز کو نکالنا ہوگا؟ اکثر نہیں، یہ مسئلہ بہت پیچیدہ ہے اور اسے وائٹ بورڈ یا فن تعمیر کی میٹنگز میں "حل" نہیں کیا جا سکتا۔ ٹویٹر ڈویلپر @ simonbrown کا حوالہ دینے کے لیے: میں یہ بار بار کہوں گا... اگر لوگ یک سنگی درست طریقے سے نہیں بنا سکتے تو مائیکرو سروسز مدد نہیں کریں گی۔ سائمن براؤن

مائیکرو سروس فن تعمیر کی بنیاد پر شروع سے پروجیکٹ

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

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

اس کی وجہ سے کمپنیاں جاوا مائیکرو سروسز کے ساتھ نئے پروجیکٹس کی کوشش کر رہی ہیں۔

تکنیکی مائیکرو سروس فن تعمیر

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

@Service
class UserService {

    public void register(User user) {
        String email = user.getEmail();
        String username =  email.substring(0, email.indexOf("@"));
        // ...
    }
}

سبسٹرنگ جاوا مائیکرو سروس کے ساتھ

@Service
class UserService {

    @Autowired
    private HttpClient client;

    public void register(User user) {
        String email = user.getEmail();
        //теперь вызываем substring microservice via http
        String username =  httpClient.send(substringRequest(email), responseHandler());
        // ...
    }
}

لہذا آپ بنیادی طور پر جاوا میتھڈ کال کو HTTP کال میں لپیٹ رہے ہیں، ایسا کرنے کی کوئی واضح وجہ نہیں ہے۔ تاہم، ایک وجہ یہ ہے: تجربے کی کمی اور جاوا مائیکرو سروسز اپروچ کو مجبور کرنے کی کوشش کرنا۔ مشورہ: ایسا نہ کریں۔

ورک فلو پر مبنی مائیکرو سروس فن تعمیر

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

1. چیک کریں گے کہ آیا صحیح XML فائل موصول ہوئی ہے۔
2. یہ طریقہ کار کی معقولیت کی جانچ کرے گا: کہتے ہیں کہ، ایک سال کا بچہ جس نے ماہر امراض چشم سے ایک دن میں تین دانتوں کی صفائی کا طریقہ کار حاصل کیا وہ کچھ مشکوک نظر آتا ہے۔
3. XML کو کچھ دوسرے بیوروکریٹک ڈیٹا کے ساتھ جوڑ دے گا۔
4. ادائیگی شروع کرنے کے لیے XML فائل انشورنس کمپنی کو بھیجے گا۔
5. اور یہ نتیجہ ڈاکٹر کو بھیجے گا، اسے پیغام "کامیابی" یا "براہ کرم اس ریکارڈنگ کو جیسے ہی سمجھ میں آئے اسے دوبارہ بھیج دیں۔"

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

• کیا ایک XML فائل پر کارروائی کرنے کے لیے چھ ایپلیکیشنز کو تعینات کرنا ضروری ہے؟
• کیا یہ مائیکرو سروسز واقعی ایک دوسرے سے آزاد ہیں؟ کیا انہیں ایک دوسرے سے آزادانہ طور پر تعینات کیا جا سکتا ہے؟ مختلف ورژن اور API اسکیموں کے ساتھ؟
• اگر تصدیقی مائیکرو سروس کام نہیں کرتی ہے تو کریڈیبلٹی مائیکرو سروس کیا کرتی ہے؟ کیا نظام اب بھی کام کر رہا ہے؟
• کیا یہ مائیکرو سروسز ایک ہی ڈیٹا بیس کا اشتراک کرتی ہیں (انہیں یقینی طور پر ڈی بی ٹیبلز میں کچھ عام ڈیٹا کی ضرورت ہے)، یا ان میں سے ہر ایک کا اپنا ہے؟
• … اور بہت کچھ.

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

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

تو سفارش یہ ہوگی:

• اگر آپ Netflix نہیں ہیں (امکانات ہیں، آپ Netflix نہیں ہیں)...
• جب تک کہ آپ کے پاس انتہائی مضبوط کام کی مہارتیں نہیں ہیں جہاں آپ ترقیاتی ماحول کو کھولتے ہیں اور یہ ایک افراتفری کا بندر کہتا ہے جو آپ کے پروڈکشن ڈیٹا بیس کو پھینک دیتا ہے جو آسانی سے 5 سیکنڈ میں بحال ہوجاتا ہے۔
• یا آپ @monzo کی طرح محسوس کرتے ہیں اور 1500 مائیکرو سروسز کو آزمانے کے لیے تیار ہیں کیونکہ آپ کر سکتے ہیں۔

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

پولی گلوٹ یا ٹیم پر مبنی مائیکرو سروس فن تعمیر

مائیکرو سروسز تیار کرنے کے لیے ایک تیسرا، تقریباً آزادی پسندانہ نقطہ نظر ہے: ٹیموں یا یہاں تک کہ افراد کو کسی بھی زبان یا مائیکرو سروسز کا استعمال کرتے ہوئے صارف کی کہانیوں کو نافذ کرنے کی اجازت دیتا ہے (مارکیٹرز اس نقطہ نظر کو "پولی گلوٹ پروگرامنگ" کہتے ہیں)۔ اس طرح، اوپر بیان کردہ XML کی توثیق کی خدمت جاوا میں لکھی جا سکتی ہے، جبکہ ایک ہی وقت میں توثیق مائیکرو سروس کو ہاسکل میں لکھا جا سکتا ہے (اسے ریاضی کے لحاظ سے درست بنانے کے لیے)۔ انشورنس فارورڈنگ مائیکرو سروس کے لیے، آپ ایرلنگ استعمال کر سکتے ہیں (کیونکہ اسے واقعی پیمانے کی ضرورت ہے ؛))۔ ایک ڈویلپر کے نقطہ نظر سے جو چیز مضحکہ خیز لگ سکتی ہے (ایک الگ تھلگ ماحول میں اپنی کامل زبان کے ساتھ کامل نظام تیار کرنا) درحقیقت وہ کبھی نہیں ہوتا جو تنظیم چاہتی ہے: ہم آہنگی اور معیاری کاری۔ اس کا مطلب ہے زبانوں، لائبریریوں اور ٹولز کا نسبتاً معیاری سیٹ تاکہ دوسرے ڈویلپرز مستقبل میں آپ کی ہاسکل مائیکرو سروس کو سپورٹ کرنا جاری رکھ سکیں جب آپ سبز چراگاہوں پر جائیں گے۔ تاریخ سے پتہ چلتا ہے کہ معیاری کاری عام طور پر بہت گہرائی سے جڑ جاتی ہے۔ مثال کے طور پر، بڑی Fortune 500 کمپنیوں کے ڈویلپرز کو کبھی کبھی Spring استعمال کرنے کی بھی اجازت نہیں تھی کیونکہ یہ "کمپنی کے ٹیکنالوجی روڈ میپ کا حصہ نہیں تھا۔" تاہم، پولی گلوٹ اپروچ میں مکمل منتقلی تقریباً ایک ہی چیز ہے، ایک ہی سکے کا دوسرا رخ۔ تجویز: اگر آپ پولی گلوٹ پروگرامنگ استعمال کرنے جا رہے ہیں، تو اسی پروگرامنگ لینگویج ایکو سسٹم میں کم ورائٹی آزمائیں۔ لہذا، بہتر ہے کہ جاوا اور کہیے، ہاسکل کے بجائے کوٹلن اور جاوا کو ایک ساتھ استعمال کریں (دونوں زبانیں JVM پر مبنی ہیں اور ایک دوسرے کے ساتھ 100٪ ہم آہنگ ہیں)۔ اگلے حصے میں ، آپ جاوا مائیکرو سروسز کی تعیناتی اور جانچ کے بارے میں جانیں گے۔