جاوا مائڪرو سروسز لاءِ هڪ گائيڊ. حصو 1: مائڪرو سروسز بنياديات ۽ فن تعمير

هن سبق ۾، توهان سکندا ته جاوا مائڪرو سروسز ڇا آهن، انهن کي ڪيئن ٺاهيو ۽ ٺاهيو. اهو جاوا مائڪرو سروسز لائبريرين ۽ مائڪرو سروسز استعمال ڪرڻ جي فزيبلٽي بابت سوالن جو به احاطو ڪري ٿو. جاوا مائڪرو سروسز جو ترجمو ۽ موافقت : هڪ عملي گائيڊ .

جاوا مائڪرو سروسز: بنيادي

microservices کي سمجهڻ لاءِ، توهان کي پهريان بيان ڪرڻ گهرجي ته اهي ڇا نه آهن. ڇا اهو نه آهي "مونولٿ" - جاوا مونولٿ: اهو ڇا آهي ۽ ان جا فائدا يا نقصان ڇا آهن؟

جاوا مونولٿ ڇا آهي؟

تصور ڪريو ته توھان ڪم ڪري رھيا آھيو ھڪڙي بئنڪ لاءِ يا ھڪڙي فنيچ شروع ڪرڻ لاءِ. توهان صارفين کي هڪ موبائل ايپ مهيا ڪندا آهيو جيڪا اهي استعمال ڪري سگهن ٿا هڪ نئون بئنڪ اڪائونٽ کولڻ لاءِ. جاوا ڪوڊ ۾ اهو نتيجو ٿيندو هڪ ڪنٽرولر طبقي جي موجودگي. آساني سان، اهو هن وانگر ڏسڻ ۾ اچي ٿو:

@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 فائل کي پنھنجي سرور تي ھلائي سگھو ٿا... ۽ بس توھان کي توھان جي جاوا ايپليڪيشن کي ڊيپلائي ڪرڻ جي ضرورت آھي. تصوير، مٿي کاٻي پاسي مستطيل: هڪ مونو (ليٿڪ) بينڪ جي ڊيپلائيمينٽ java -jar bank.jar (cp .war/.ear in appserver). ساڄي مستطيل: کليل برائوزر.

جاوا monoliths سان مسئلو ڇا آهي؟

جاوا monoliths سان موروثي طور تي ڪجھ به غلط ناهي. بهرحال، تجربو ڏيکاريو آهي ته جيڪڏهن توهان جي منصوبي ۾:

• هتي ڪيترائي پروگرامر / ٽيمون / صلاحڪار ڪم ڪري رهيا آهن ...
• ... بلڪل مبہم ضرورتن سان گراهڪن جي دٻاءُ هيٺ ساڳي monolith تي ...
• ٻن سالن اندر...

ان صورت ۾ توهان جي ننڍڙي bank.jar فائل اڪيلو ڪوڊ جي هڪ وڏي گيگا بائيٽ ۾ تبديل ٿي ويندي آهي، جيڪو ويجهڙائي ڪرڻ لاء خوفناڪ آهي، اڪيلو وڃڻ ڏيو.

جاوا مونولٿ جي سائيز کي ڪيئن گھٽائڻ؟

هڪ قدرتي سوال پيدا ٿئي ٿو: مونولٿ کي ننڍڙو ڪيئن ڪجي؟ هن وقت توهان جو bank.jar هڪ JVM تي هلندڙ آهي، هڪ سرور تي هڪ عمل. نه وڌيڪ، نه گهٽ. ۽ هن وقت هڪ منطقي سوچ ذهن ۾ اچي سگهي ٿي: ”پر خطري جي تصديق جي خدمت منهنجي ڪمپني ۾ ٻين شعبن طرفان استعمال ڪري سگهجي ٿي! اهو سڌو سنئون منهنجي monolithic بينڪنگ ايپليڪيشن سان لاڳاپيل ناهي! ٿي سگهي ٿو ته ان کي monolith مان ڪٽيو وڃي ۽ هڪ الڳ پيداوار طور مقرر ڪيو وڃي؟ اهو آهي، ٽيڪنيڪل طور ڳالهائڻ، ان کي هڪ الڳ جاوا پروسيس جي طور تي هلائي رهيو آهي.

جاوا مائڪرو سروس ڇا آهي؟

عملي طور تي، هن جملي جو مطلب آهي ته هاڻي طريقو ڪال riskCheck()بينڪ ڪنٽرولر کان نه ڪيو ويندو: هي طريقو يا بين جزو ان جي سڀني معاون طبقن سان گڏ ان جي پنهنجي Maven يا Gradle پروجيڪٽ ڏانهن منتقل ڪيو ويندو. اهو پڻ مقرر ڪيو ويندو ۽ ورزن ڪنٽرول هيٺ رکيو ويندو آزاد طور تي بئنڪنگ مونولٿ کان. بهرحال، هي مڪمل ڪڍڻ وارو عمل توهان جي نئين RiskCheck ماڊل کي هڪ مائڪرو سروس في سي ۾ تبديل نٿو ڪري، ڇاڪاڻ ته مائڪرو سروس جي تعريف تشريح لاءِ کليل آهي. هي ٽيمن ۽ ڪمپنين ۾ بار بار بحث مباحثو ڪري ٿو.

• ڇا هڪ پروجيڪٽ ۾ 5-7 ڪلاس مائڪرو يا ڇا آهن؟
• 100 يا 1000 ڪلاس... اڃا به مائڪرو؟
• ڇا مائڪرو سروس عام طور تي طبقن جي تعداد سان لاڳاپيل آهي يا نه؟

اچو ته نظرياتي استدلال کي پوئتي ڇڏي ڏيو، ۽ ان جي بدران عملي خيالات ڏانهن لٺ ۽ هي ڪريو:

1. اچو ته سڀني الڳ الڳ مقرر ڪيل خدمتن کي سڏيون microservices، قطع نظر انهن جي سائيز يا ڊومين جي حدن جي.
2. اچو ته ان باري ۾ سوچيو ته انٽر سروس ڪميونيڪيشن جو بندوبست ڪيئن ڪجي. اسان جي مائڪرو سروسز کي هڪ ٻئي سان رابطي لاءِ طريقن جي ضرورت آهي.

تنهن ڪري، اختصار ڪرڻ لاءِ: اڳي توهان وٽ هڪ JVM عمل هو، بينڪ کي هلائڻ لاءِ هڪ مضبوط واحد. ھاڻي توھان وٽ ھڪڙو بينڪنگ مونولٿ JVM عمل آھي ۽ ھڪڙو الڳ RiskCheck microservice جيڪو ھلندو آھي پنھنجي JVM عمل ۾. ۽ ھاڻي، خطرن جي جانچ ڪرڻ لاءِ، توھان جي monolith کي ھن microservice کي سڏڻ گھرجي. اهو ڪيئن ڪجي؟

جاوا مائڪرو سروسز جي وچ ۾ رابطي کي ڪيئن قائم ڪجي؟

عام طور تي ۽ عام طور تي، اتي ٻه اختيار آهن - هم وقت سازي ۽ هم وقت سازي مواصلات.

هم وقت سازي ڪميونيڪيشن: (HTTP)/REST

عام طور تي، مائڪرو سروسز جي وچ ۾ هم وقت سازي رابطي HTTP ۽ REST-جهڙي خدمتن جي ذريعي ٿئي ٿي جيڪا واپسي XML يا JSON. يقينا، ٻيا اختيار ٿي سگھن ٿا - گھٽ ۾ گھٽ گوگل پروٽوڪول بفرز وٺو . جيڪڏهن توهان کي فوري جواب جي ضرورت آهي، اهو بهتر آهي ته REST مواصلات استعمال ڪريو. اسان جي مثال ۾، اهو ئي آهي جيڪو ڪرڻ جي ضرورت آهي، ڇو ته اڪائونٽ کولڻ کان پهريان خطري جي تصديق جي ضرورت آهي. جيڪڏهن ڪو خطري جي چڪاس نه آهي، اتي ڪو اڪائونٽ ناهي. اسان هيٺ ڏنل ٽولز تي بحث ڪنداسين، سيڪشن ۾ " ڪهڙيون لائبريريون هم وقت ساز جاوا REST ڪالز لاءِ بهترين آهن ".

پيغام رسائيندڙ - هم وقت سازي ڪميونيڪيشن

Asynchronous microservice ڪميونيڪيشن عام طور تي JMS لاڳو ڪرڻ ۽/يا پروٽوڪول استعمال ڪندي پيغامن جي تبادلي سان مڪمل ڪيو ويندو آهي جهڙوڪ AMQP . اسان "عام طور تي" هتي هڪ سبب لاءِ لکيو آهي: اچو ته چئون ته اي ميل/SMTP انضمام جو تعداد گهٽ نه ٿو ڪري سگهجي. ان کي استعمال ڪريو جڏهن توهان کي فوري جواب جي ضرورت نه آهي. مثال طور، صارف "هاڻي خريد ڪريو" بٽڻ تي ڪلڪ ڪري ٿو، ۽ توهان، موڙ ۾، هڪ انوائس ٺاهڻ چاهيو ٿا. اهو عمل يقيني طور تي صارف جي خريداري جي درخواست-جواب چڪر جي اندر نه ٿيڻ گهرجي. هيٺ اسين بيان ڪنداسين ته ڪهڙن اوزارن لاءِ بهترين آهن Asynchronous Java ميسيجنگ .

مثال: REST API ڪال جاوا ۾

اچو ته فرض ڪريون ته اسان هم وقت ساز مائڪرو سروس ڪميونيڪيشن چونڊيو. انهي حالت ۾، اسان جو جاوا ڪوڊ (جيڪو اسان مٿي پيش ڪيو آهي) گهٽ سطح تي ڪجهه هن طرح نظر ايندو. (هتي گهٽ سطح کان اسان جو مطلب اهو آهي ته microservice ڪميونيڪيشن لاءِ، ڪلائنٽ لائبريريون عام طور تي ٺاهي وينديون آهن جيڪي توهان کي اصل 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..
    }
}

ڪوڊ جي بنياد تي، اهو واضح ٿئي ٿو ته اسان کي هاڻي ٻه جاوا (مائڪرو) خدمتن کي ترتيب ڏيڻ جي ضرورت آهي، بئنڪ ۽ RiskCheck. نتيجي طور، اسان وٽ ٻه JVM عمل هلندڙ هوندا. جاوا مائيڪرو سروسز پروجيڪٽ ٺاهڻ لاءِ توهان کي صرف اهو ئي ڪرڻو آهي: صرف هڪ واحد جي بدران ننڍا ٽڪرا (.jar يا .war فائلون) ٺاهيو ۽ لڳايو. سوال جو جواب واضح ناهي ته: اسان کي ڪيئن ڪٽ ڪرڻ گهرجي monolith microservices ۾؟ اهي ٽڪرا ڪيترا ننڍا هجن، صحيح سائيز کي ڪيئن طئي ڪجي؟ اچو ته چيڪ ڪريو.

جاوا مائڪرو سروسز آرڪيٽيڪچر

عملي طور تي، ڪمپنيون مختلف طريقن سان microservice منصوبن کي ترقي ڪن ٿيون. نقطه نظر ان تي منحصر آهي ته ڇا توهان ڪوشش ڪري رهيا آهيو هڪ موجوده مونولٿ کي مائڪرو سروسز پروجيڪٽ ۾ تبديل ڪرڻ يا منصوبي کي شروع کان شروع ڪرڻ.

monolith کان microservices تائين

سڀ کان وڌيڪ منطقي خيالن مان هڪ آهي مائڪرو سروسز کي هڪ موجوده مونولٿ مان ڪڍڻ. نوٽ ڪريو ته هتي اڳياڙي ”مائڪرو“ جو اصل مطلب اهو ناهي ته ڪڍيل خدمتون واقعي ننڍيون هونديون؛ اهو ضروري ناهي ته اهو معاملو هجي. اچو ته نظرياتي پس منظر تي نظر رکون.

خيال: monolith کي microservices ۾ ٽوڙيو

هڪ microservice طريقيڪار ورثي منصوبن تي لاڳو ڪري سگهجي ٿو. ۽ اهو ئي سبب آهي ته:

1. گهڻو ڪري، اهڙن منصوبن کي برقرار رکڻ / تبديل ڪرڻ / وڌائڻ ڏکيو آهي.
2. هرڪو، ڊولپرز کان انتظاميه تائين، سادگي چاهي ٿو.
3. توهان وٽ (نسبتا) واضح ڊومين جون حدون آهن، مطلب ته توهان ڄاڻو ٿا ته توهان جو سافٽ ويئر ڇا ڪرڻ گهرجي.

اسان جي مثال ڏانهن موٽڻ، ان جو مطلب اهو آهي ته توهان پنهنجي جاوا بينڪنگ monolith کي ڏسي سگهو ٿا ۽ ان کي ٽوڙڻ جي ڪوشش ڪري ڊومين جي حدن ۾.

• تنهن ڪري، اهو مناسب هوندو ته صارف جي ڊيٽا جي پروسيسنگ کي الڳ ڪرڻ (جهڙوڪ نالا، ايڊريس، فون نمبر) هڪ الڳ مائڪرو سروس "اڪائونٽ مئنيجمينٽ" ۾.
• يا مٿي بيان ڪيل "خطري چيڪ ڪندڙ ماڊل" جيڪو صارف جي خطري جي سطح کي چيڪ ڪري ٿو ۽ ڪيترن ئي ٻين منصوبن يا ڪمپني جي شعبن طرفان پڻ استعمال ڪري سگهجي ٿو.
• يا هڪ انوائسنگ ماڊل جيڪو پي ڊي ايف فارميٽ ۾ يا ميل ذريعي انوائس موڪلي ٿو.

هڪ خيال تي عمل ڪرڻ: ڪنهن ٻئي کي ڪرڻ ڏيو

مٿي بيان ڪيل طريقي سان پيپر ۽ يو ايم ايل-جهڙي ڊاگرام تي تمام سٺو لڳندو آهي. تنهن هوندي به، سڀڪنھن شيء کي ايترو سادو نه آهي. ان جي عملي تي عمل ڪرڻ لاءِ سنجيده ٽيڪنيڪل تياري جي ضرورت آهي: اسان جي سمجھ جي وچ ۾ خال آهي ته هڪ مونولٿ مان ڪڍڻ ڪهڙو سٺو هوندو ۽ ڪڍڻ وارو عمل خود تمام وڏو آهي. اڪثر انٽرپرائز پروجيڪٽ هڪ اسٽيج تي پهچن ٿا جتي ڊولپرز ڊپ کان ڊڄن ٿا، چون ٿا، هائبرنيٽ جي 7 سالن جي پراڻي ورزن کي نئين ۾ اپڊيٽ ڪرڻ. لائبريريون ان سان گڏ اپڊيٽ ٿي وينديون آهن، پر ڪجهه ٽوڙڻ جو حقيقي خطرو آهي. تنهن ڪري اهي ساڳيون ڊولپرز هاڻي قديم ورثي واري ڪوڊ ذريعي غير واضح ڊيٽابيس ٽرانزيڪشن جي حدن سان گڏ ۽ چڱي طرح بيان ڪيل مائڪرو سروسز کي ڪڍڻو پوندو؟ گهڻو ڪري نه، اهو مسئلو تمام پيچيده آهي ۽ "حل" نه ٿو ڪري سگھجي وائيٽ بورڊ تي يا فن تعمير جي گڏجاڻين ۾. Twitter ڊولپر @simonbrown جو حوالو ڏيڻ لاءِ: مان اهو بار بار چوندس... جيڪڏهن ماڻهو صحيح طريقي سان مونولٿس نه ٺاهي سگهندا، مائڪرو سروسز مدد نه ڪنديون. سائمن براون

مائڪرو سروس آرڪيٽيڪچر جي بنياد تي شروع کان پروجيڪٽ

نون جاوا پروجيڪٽس جي صورت ۾، پوئين حصي مان ٽي نمبر ٿيل پوائنٽون ٿورو مختلف نظر اچن ٿا:

1. توهان صاف سليٽ سان شروع ڪريو، تنهنڪري برقرار رکڻ لاء ڪو به "سامان" ناهي.
2. ڊولپر مستقبل ۾ شين کي سادو رکڻ چاهيندا.
3. مسئلو: توهان وٽ ڊومين جي حدن جي تمام گهڻي مبهم تصوير آهي: توهان کي خبر ناهي ته توهان جو سافٽ ويئر اصل ۾ ڇا ڪرڻ گهرجي (اشارو: چست؛))

هي ڪمپني جاوا مائڪرو سروسز سان نئين منصوبن جي ڪوشش ڪري رهيو آهي.

ٽيڪنيڪل microservice فن تعمير

پهريون نقطو ڊولپرز لاءِ سڀ کان وڌيڪ واضح لڳي ٿو، پر اهڙا پڻ آهن جيڪي سختيءَ سان ان جي حوصلا افزائي ڪن ٿا. هادي هريري IntelliJ ۾ "Extract Microservice" جي ريفيڪٽرنگ جي سفارش ڪري ٿو. ۽ جيتوڻيڪ هيٺ ڏنل مثال تمام آسان آهي، حقيقي منصوبن ۾ عمل درآمد، بدقسمتي سان، ان کان گهڻو پري نه وڃو. microservices کان اڳ

@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 ڪال ۾ جاوا ميٿڊ ڪال کي لپي رهيا آهيو، ائين ڪرڻ لاءِ ڪو واضح سبب ناهي. هڪ سبب، تنهن هوندي به، هي آهي: تجربو جي کوٽ ۽ جاوا مائڪرو سروسز جي طريقي کي مجبور ڪرڻ جي ڪوشش. سفارش: ائين نه ڪريو.

ڪم فلو تي مبني microservice فن تعمير

ايندڙ عام طريقو جاوا مائڪرو سروسز کي ورڪ فلو تي ٻڌل ماڊلز ۾ ورهائڻ آهي. حقيقي زندگي جو مثال: جرمني ۾، جڏهن توهان هڪ (عوامي) ڊاڪٽر وٽ وڃو، هن کي توهان جي دوري کي پنهنجي طبي CRM سسٽم ۾ رڪارڊ ڪرڻ گهرجي. انشورنس کان ادائيگي حاصل ڪرڻ لاء، هو توهان جي علاج بابت ڊيٽا موڪليندو (۽ ٻين مريضن جو علاج) وچولي کي XML ذريعي. بروکر هن XML فائل کي ڏسندو ۽ (آسان ٿيل):

1. چيڪ ڪنداسين ته صحيح XML فائل ملي ٿي.
2. اهو عمل جي تعميل جي جانچ ڪندو: چون ٿا، هڪ سال جي ٻار، جنهن کي هڪ ڏينهن ۾ ٽن ڏندن جي صفائي جي طريقيڪار حاصل ڪئي وئي هڪ زنانيات جي ماهر کان ڪجهه مشڪوڪ نظر اچي ٿو.
3. ڪجهه ٻين بيوروڪريسي ڊيٽا سان گڏ XML گڏ ڪندو.
4. ادائگي شروع ڪرڻ لاءِ ايڪس ايم ايل فائل انشورنس ڪمپني ڏانهن موڪلي ويندي.
5. ۽ اهو نتيجو ڊاڪٽر ڏانهن موڪليندو، هن کي پيغام فراهم ڪندي ”ڪاميابي“ يا ”مهرباني ڪري هن رڪارڊنگ کي جلد کان جلد ٻيهر موڪليو جيئن اهو احساس ٿئي.

نوٽ. هن مثال ۾، microservices جي وچ ۾ رابطي جو ڪو ڪردار نه آهي، پر هڪ پيغام بروکر (مثال طور RabbitMQ)، جيئن ته ڊاڪٽر کي فوري طور تي فوري موٽ نه ملي ٿي، هڪ پيغام بروکر جي ذريعي چڱي طرح ڪري سگهجي ٿو. ٻيهر، هي ڪاغذ تي تمام سٺو لڳندو آهي، پر قدرتي سوال پيدا ٿين ٿا:

• ڇا ھڪڙو XML فائل کي پروسيس ڪرڻ لاء ڇھ ايپليڪيشنن کي ترتيب ڏيڻ ضروري آھي؟
• ڇا اهي microservices واقعي هڪ ٻئي کان آزاد آهن؟ ڇا اهي هڪ ٻئي کان الڳ الڳ ٿي سگهن ٿا؟ مختلف نسخن ۽ API اسڪيمن سان؟
• جيڪڏهن تصديق ٿيل مائڪرو سروس ڪم نه ڪندي ته معلومات جي قابليت واري مائڪرو سروس ڇا ڪندو؟ ڇا سسٽم اڃا تائين ڪم ڪري رهيو آهي؟
• ڇا اهي مائڪرو سروسز ساڳيا ڊيٽابيس شيئر ڪن ٿا (انهن کي يقيني طور تي ڊي بي ٽيبل ۾ ڪجهه عام ڊيٽا جي ضرورت آهي)، يا انهن مان هر هڪ کي پنهنجو آهي؟
• … ۽ گهڻو ڪجهه.

دلچسپ ڳالهه اها آهي ته، مٿي ڏنل ڊراگرام وڌيڪ سادو نظر اچي ٿو ڇاڪاڻ ته هر خدمت هاڻي پنهنجي مخصوص، چڱي طرح بيان ڪيل مقصد آهي. اهو ڪجهه ڏسڻ لاء استعمال ڪيو ويو هن خوفناڪ monolith وانگر: جڏهن ته توهان انهن ڊاڪٽرن جي سادگي بابت بحث ڪري سگهو ٿا، توهان کي يقيني طور تي هاڻي انهن اضافي عملياتي چئلينج کي حل ڪرڻ جي ضرورت آهي.

• توهان کي صرف هڪ ايپليڪيشن کي ترتيب ڏيڻ جي ضرورت ناهي، پر گهٽ ۾ گهٽ ڇهه.
• توهان کي شايد ڪيترن ئي ڊيٽابيس کي ترتيب ڏيڻ جي ضرورت پوندي، انهي تي منحصر آهي ته توهان مائڪرو سروسز آرڪيٽيڪچر ۾ وڃڻ چاهيو ٿا.
• توهان کي پڪ ڪرڻ جي ضرورت آهي ته هر سسٽم آن لائن آهي ۽ صحيح ڪم ڪري رهيو آهي.
• توهان کي پڪ ڪرڻ جي ضرورت آهي ته مائڪرو سروسز جي وچ ۾ توهان جون ڪالون واقعي لچڪدار آهن (ڏسو ته جاوا مائڪرو سروسز کي لچڪدار ڪيئن ٺاهيو؟).
• ۽ ٻيو سڀ ڪجهه جيڪو هن سيٽ اپ جو مطلب آهي - مقامي ڊولپمينٽ سيٽنگن کان وٺي انٽيگريشن ٽيسٽ تائين.

تنهن ڪري سفارش ڪئي ويندي:

• جيڪڏهن توهان Netflix نه آهيو (امڪان آهن، توهان Netflix نه آهيو) ...
• جيستائين توهان وٽ زبردست ڪم جون صلاحيتون نه آهن جتي توهان ترقي واري ماحول کي کوليندا آهيو ۽ اهو هڪ افراتفري بندر جو سبب بڻجندو آهي جيڪو توهان جي پيداوار ڊيٽابيس کي اڇلائي ڇڏيندو آهي جيڪو آساني سان 5 سيڪنڊن ۾ بحال ڪيو ويندو آهي.
• يا توهان @monzo وانگر محسوس ڪندا آهيو ۽ 1500 مائڪرو سروسز کي آزماڻ لاءِ تيار آهيو صرف ان ڪري جو توهان ڪري سگهو ٿا.

→ ائين نه ڪريو. ۽ هاڻي اهو گهٽ هائپربولڪ آهي. ڊومين جي حدن ۾ مائڪرو سروسز کي ماڊل ڪرڻ جي ڪوشش ڪافي معقول لڳي ٿي. پر هن جو مطلب اهو ناهي ته توهان کي هڪ ڪم فلو وٺڻ جي ضرورت آهي ۽ ان کي ننڍن انفرادي حصن ۾ ورهائڻ جي ضرورت آهي (ايڪس ايم ايل وصول ڪريو، XML کي درست ڪريو، XML اڳتي وڌايو). ان ڪري، جڏهن به توهان جاوا مائيڪرو سروسز سان ڪو نئون پروجيڪٽ شروع ڪيو ۽ ڊومين جون حدون اڃا به بلڪل مبہم آهن، ڪوشش ڪريو ته توهان جي مائڪرو سروسز جي سائيز کي گهٽ سطح تي رکو. توھان ھميشه بعد ۾ وڌيڪ ماڊل شامل ڪري سگھو ٿا. ۽ پڪ ڪريو ته توهان ٽيم/ڪمپني/ ڊويزن ۾ ترقي يافته DevOps آهن توهان جي نئين انفراسٽرڪچر کي سپورٽ ڪرڻ لاءِ.

پولي گلوٽ يا ٽيم تي مبني مائڪرو سروس آرڪيٽيڪچر

اتي هڪ ٽيون، لڳ ڀڳ آزادي پسند، مائڪرو سروسز کي ترقي ڪرڻ جو طريقو آهي: ٽيمن يا ماڻهن کي اجازت ڏئي ٿو ته ڪنهن به ٻولي يا مائڪرو سروسز استعمال ڪندي صارف ڪهاڻيون لاڳو ڪن (مارڪيٽر هن طريقي کي "پولي گلوٽ پروگرامنگ" سڏين ٿا). اهڙيءَ طرح، مٿي بيان ڪيل XML جي تصديق واري خدمت جاوا ۾ لکي سگهجي ٿي، جڏهن ته هڪ ئي وقت ۾ تصديق واري microservice کي Haskell ۾ لکي سگهجي ٿو (ان کي رياضياتي طور تي آواز ڏيڻ لاءِ). انشورنس فارورڊنگ مائڪرو سروس لاءِ، توھان استعمال ڪري سگھوٿا Erlang (ڇاڪاڻ ته اھو واقعي اسڪيل ڪرڻ جي ضرورت آھي ؛)). ڊولپر جي نقطي نظر کان ڇا ٿي سگھي ٿو مزيدار ٿي سگھي ٿو (ھڪ ڌار ماحول ۾ پنھنجي مڪمل ٻولي سان مڪمل سسٽم کي ترقي ڪرڻ)، حقيقت ۾، اھو ڪڏھن به نه آھي جيڪو تنظيم گھري ٿو: homogenization ۽ standardization. ان جو مطلب ٻولين، لائبريرين ۽ اوزارن جو نسبتاً معياري سيٽ آهي ته جيئن ٻيا ڊولپرز مستقبل ۾ توهان جي هاسڪيل مائڪرو سروس کي سپورٽ ڪرڻ جاري رکي سگهن جڏهن توهان سبز چراگاهن ڏانهن وڃو. تاريخ ڏيکاري ٿي ته معيار عام طور تي تمام گهڻي ڳري ٿي ويندي آهي. مثال طور، وڏي فارچون 500 ڪمپنين ۾ ڊولپرز کي ڪڏهن ڪڏهن به اسپرنگ استعمال ڪرڻ جي اجازت نه هوندي هئي ڇاڪاڻ ته اها ڪمپني جي ٽيڪنالاجي روڊ ميپ جو حصو نه هئي. بهرحال، پوليگلوٽ جي نقطي نظر ۾ هڪ مڪمل منتقلي تقريبن ساڳي شيء آهي، ساڳئي سڪي جو ٻيو پاسو. سفارش: جيڪڏهن توهان پولي گلوٽ پروگرامنگ استعمال ڪرڻ وارا آهيو، ڪوشش ڪريو ساڳئي پروگرامنگ ٻوليءَ جي ماحوليات ۾ گهٽ قسم جي. تنهن ڪري، اهو بهتر آهي ته ڪوٽلن ۽ جاوا گڏجي استعمال ڪريو (ٻئي ٻوليون JVM تي ٻڌل آهن ۽ هڪ ٻئي سان 100٪ مطابقت آهن)، بجاء جاوا ۽، چئو، هاسڪيل. ايندڙ حصي ۾ ، توهان جاوا مائڪرو سروسز کي ترتيب ڏيڻ ۽ جانچ ڪرڻ بابت سکندا.