جاوا مائڪرو سروسز لاءِ هڪ گائيڊ. حصو 3: عام سوال

جاوا مائڪرو سروسز جو ترجمو ۽ موافقت : هڪ عملي گائيڊ . ھدايت جا پوئين حصا:

• microservices بنياديات ۽ سندن فن تعمير ؛
• microservices کي لڳائڻ ۽ جانچڻ .

اچو ته جاوا ۾ مائڪرو سروسز جي موروثي مسئلن کي ڏسو، خلاصي شين سان شروع ٿئي ٿو ۽ ڪنڪريٽ لائبريرين سان ختم ٿئي ٿو.

جاوا مائڪرو سروس کي لچڪدار ڪيئن بڻايو وڃي؟

ياد رکو ته جڏهن توهان مائڪرو سروسز ٺاهي رهيا آهيو، توهان لازمي طور تي واپار ڪري رهيا آهيو JVM طريقو ڪالن لاءِ هم وقت ساز HTTP ڪالن يا غير هم وقتي پيغام ڏيڻ. جڏهن ته هڪ طريقو ڪال گهڻو ڪري مڪمل ڪرڻ جي ضمانت ڏني وئي آهي (غير متوقع JVM بند ٿيڻ کان سواء)، هڪ نيٽ ورڪ ڪال ڊفالٽ طرفان ناقابل اعتبار آهي. اهو ڪم ڪري سگهي ٿو، پر اهو مختلف سببن جي ڪري ڪم نٿو ڪري سگهي: نيٽ ورڪ اوورلوڊ ٿيل آهي، هڪ نئون فائر وال قاعدو لاڳو ڪيو ويو آهي، وغيره. ڏسڻ لاءِ ته اهو ڪيئن فرق ٿو آڻي، اچو ته هڪ نظر وٺون بلنگ سروس مثال.

HTTP/REST لچڪدار نمونن

اچو ته چوندا آهن ته گراهڪ توهان جي ڪمپني جي ويب سائيٽ تي اي ڪتاب خريد ڪري سگهن ٿا. ائين ڪرڻ لاءِ، توهان صرف هڪ بلنگ مائڪرو سروس لاڳو ڪيو آهي جيڪو توهان جي آن لائن اسٽور کي اصل PDF انوائسز ٺاهڻ لاءِ ڪال ڪري سگهي ٿو. هن وقت لاءِ، اسين هن ڪال کي هم وقت سازي سان ڪنداسين، 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 ڪال جا ٽي ممڪن نتيجا آهن.

• ٺيڪ: ڪال ٿي وئي، اڪائونٽ ڪاميابيءَ سان ٺهي ويو.
• دير: ڪال گذري وئي، پر ان کي مڪمل ٿيڻ ۾ تمام گهڻو وقت لڳو.
• ERROR. ڪال ناڪام ٿي، توهان شايد هڪ غير مطابقت واري درخواست موڪلي هجي، يا شايد سسٽم ڪم نه ڪري رهيو آهي.

ڪنهن به پروگرام کي اميد آهي ته غلطي جي حالتن کي هٿي وٺن، نه صرف ڪامياب. ساڳيو ئي microservices تي لاڳو ٿئي ٿو. جيتوڻيڪ توهان کي اضافي ڪوشش ڪرڻ جي ضرورت آهي انهي کي يقيني بڻائڻ لاءِ ته API جا سڀئي ترتيب ڏنل نسخا مطابقت رکن ٿا هڪ دفعو توهان انفرادي مائڪرو سروسز جي ترتيب ۽ رليز سان شروع ڪيو. ڏسڻ لاءِ هڪ دلچسپ ڪيس دير جو معاملو آهي. مثال طور، جواب ڏيڻ واري جي microservice هارڊ ڊرائيو مڪمل آهي، ۽ 50 ms وٺڻ بدران، جواب ڏيڻ ۾ 10 سيڪنڊ لڳن ٿا. اهو اڃا به وڌيڪ دلچسپ ٿي ويندو آهي جڏهن توهان هڪ خاص لوڊ تجربو ڪيو آهي ته جيئن توهان جي بلنگ سروس جي غير جوابدهيت توهان جي سسٽم ذريعي ڇڪڻ شروع ٿئي ٿي. هڪ مثالي مثال جي طور تي، تصور ڪريو هڪ باورچی خانه آهستي آهستي سڀني ريسٽورنٽ جي ويٽرن جو ”بلاڪ“ شروع ڪندي. هي سيڪشن واضح طور تي مائيڪرو سروس لچڪ جي موضوع جو هڪ مڪمل جائزو مهيا نٿو ڪري سگهي، پر اهو ڊولپرز لاءِ هڪ ياد ڏياريندڙ جي طور تي ڪم ڪري ٿو ته اهو اصل ۾ ڪجهه آهي جنهن کي توهان جي پهرين رليز کان اڳ حل ڪرڻ ۽ نظرانداز نه ڪرڻ جي ضرورت آهي (جيڪو، تجربو کان، گهڻو ڪري ٿئي ٿو. نه). هڪ مشهور لائبريري جيڪا توهان جي مدد ڪري ٿي دير جي باري ۾ سوچڻ ۽ غلطي رواداري Netflix جي Hystrix. ان جي دستاويز کي استعمال ڪريو موضوع ۾ وڌيڪ گہرا ڪرڻ لاء.

پيغام ڏيڻ جي لچڪدار نموني

اچو ته هڪ ويجهي نظر رکون غير مطابقت واري ڪميونيڪيشن تي. اسان جو BillingService پروگرام ھاڻي ڪجھ ھن طرح نظر اچي سگھي ٿو، فرض ڪري رھيا آھيون Spring ۽ RabbitMQ ميسيج لاءِ. اڪائونٽ ٺاهڻ لاءِ، اسان ھاڻي پنھنجي RabbitMQ ميسيج بروکر ڏانھن ھڪ نياپو موڪليو، جتي ڪيترائي ملازم نوان پيغامن جي انتظار ۾ آھن. اهي ڪارڪن PDF انوائس ٺاهي ۽ انهن کي مناسب استعمال ڪندڙن ڏانهن موڪليندا آهن.

@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);
        // ...
    }
}

امڪاني غلطيون هاڻي ٿوري مختلف نظر اچن ٿيون، جيئن توهان کي فوري ٺيڪ يا ERROR جواب نه ملندا جيئن توهان هڪ هم وقت ساز HTTP ڪنيڪشن سان ڪيو. ان جي بدران، اسان وٽ شايد ٽي امڪاني منظرنامو ٿي سگھي ٿو جيڪي غلط ٿي سگھن ٿيون، جيڪي ھيٺين سوالن کي اٿاري سگھن ٿا:

1. ڇا منهنجو پيغام پهچايو ويو ۽ ملازم طرفان استعمال ڪيو ويو؟ يا اهو گم ٿي ويو آهي؟ (استعمال ڪندڙ هڪ انوائس وصول نه ڪندو آهي).
2. ڇا منهنجو پيغام صرف هڪ ڀيرو پهچايو ويو؟ يا هڪ ڀيرو کان وڌيڪ پهچايو ۽ صرف هڪ ڀيرو پروسيس ڪيو ويو؟ (استعمال ڪندڙ ڪيترن ئي انوائس وصول ڪندا).
3. ڪنفيگريشن: ”ڇا مون مٽاسٽا لاءِ صحيح روٽنگ ڪي/نالا استعمال ڪيا“ کان وٺي ”ڇا منهنجو ميسيج بروکر صحيح ترتيب ۽ سنڀاليو ويو آهي يا ان جون قطارون پوريون آهن؟ (استعمال ڪندڙ هڪ انوائس وصول نه ڪندو آهي).

تفصيلي وضاحت هر فرد جي غير مطابقت واري مائڪروسروس لچڪدار نموني هن گائيڊ جي دائري کان ٻاهر آهي. تنهن هوندي، صحيح هدايت ۾ نشانيون آهن. ان کان علاوه، اهي پيغام رسائيندڙ ٽيڪنالاجي تي منحصر هوندا. مثال:

• جيڪڏھن توھان استعمال ڪري رھيا آھيو JMS لاڳو ڪرڻ جھڙوڪ ActiveMQ، توھان واپار ڪري سگھو ٿا رفتار جي ضمانت لاءِ ٻن مرحلن (XA) ڪمٽس.
• جيڪڏھن توھان RabbitMQ استعمال ڪري رھيا آھيو، پھريائين ھي ھدايت پڙھو، ۽ پوءِ عام طور تي تصديق، غلطي جي رواداري، ۽ پيغام جي اعتبار جي باري ۾ احتياط سان سوچيو.
• ٿي سگهي ٿو ته ڪو ماڻهو فعال يا RabbitMQ سرورز کي ترتيب ڏيڻ ۾ ماهر هجي، خاص طور تي ڪلسترنگ ۽ ڊاڪر سان گڏ (ڪو به؟ ؛))

جاوا مائڪرو سروسز لاءِ ڪهڙو فريم ورڪ بهترين حل هوندو؟

هڪ طرف، توهان هڪ تمام مشهور آپشن انسٽال ڪري سگهو ٿا جهڙوڪ اسپرنگ بوٽ . اهو .jar فائلون ٺاهڻ ۾ تمام آسان بڻائي ٿو، هڪ ٺهيل ويب سرور جهڙوڪ Tomcat يا Jetty سان گڏ اچي ٿو، ۽ جلدي ۽ ڪٿي به هلائي سگهجي ٿو. مائڪرو سروس ايپليڪيشنن جي تعمير لاءِ مثالي. تازو، ڪجهه خاص مائڪرو سروس فريم ورڪ، ڪبرنيٽس يا GraalVM ، ظاهر ٿيا، جزوي طور تي رد عمل واري پروگرامنگ کان متاثر. هتي ڪجھ وڌيڪ دلچسپ اميدوار آهن: Quarkus , Micronaut , Vert.x , Helidon . آخر ۾، توهان کي پنهنجي لاءِ چونڊڻو پوندو، پر اسان توهان کي ڪجهه تجويزون ڏئي سگهون ٿا جيڪي مڪمل طور تي معياري نه هجن: اسپرنگ بوٽ جي استثنا سان، سڀئي مائڪرو سروسز فريم ورڪ عام طور تي ناقابل يقين حد تائين تيزيءَ سان مارڪيٽ ڪيا ويندا آهن، لڳ ڀڳ فوري طور تي شروع ٿيڻ سان. , گھٽ ميموري استعمال، لامحدود تائين اسڪيلبلٽي. مارڪيٽنگ مواد عام طور تي متاثر ڪندڙ گرافڪس ڏيکاري ٿو جيڪي پليٽ فارم کي ڏيکاري ٿو بيهيمٿ اسپرنگ بوٽ جي اڳيان يا هڪ ٻئي ڏانهن. اهو، نظريي ۾، ڊولپرز جي اعصاب کي بچائي ٿو ميراثي منصوبن جي حمايت ڪري ٿو، جيڪي ڪڏهن ڪڏهن لوڊ ڪرڻ ۾ ڪيترائي منٽ وٺندا آهن. يا ڪلائوڊ ۾ ڪم ڪندڙ ڊولپر جيڪي گھڻا مائڪرو ڪنٽينر شروع/بند ڪرڻ چاھين ٿا جيئن انھن کي في الحال 50 ms جي اندر ضرورت آھي. بهرحال، مسئلو اهو آهي ته اهي (مصنوعي) ننگي ڌاتو شروع ٿيندڙ وقت ۽ ٻيهر ڪم ڪرڻ جا وقت مشڪل سان منصوبي جي مجموعي ڪاميابي ۾ حصو وٺندا آهن. گهٽ ۾ گهٽ اهي هڪ مضبوط فريم ورڪ انفراسٽرڪچر، مضبوط دستاويزن، ڪميونٽي ۽ مضبوط ڊولپر جي صلاحيتن کان گهڻو گهٽ اثر انداز ڪن ٿا. تنهن ڪري اهو بهتر آهي ته ان کي هن طريقي سان ڏسو: جيڪڏهن ايترو پري:

• توھان پنھنجي ORMs کي تيزيءَ سان ھلڻ ڏيو، سادو ڪم فلوز لاءِ سوين سوال پيدا ڪري.
• توھان کي پنھنجي اعتدال واري پيچيده مونولٿ کي هلائڻ لاءِ لامحدود گيگا بائيٽ جي ضرورت آھي.
• توھان وٽ تمام گھڻو ڪوڊ آھي ۽ پيچيدگي تمام گھڻي آھي (اسان ھاڻي ھائيبرنيٽ وانگر امڪاني طور تي سست شروعات ڪندڙن بابت نه ڳالھائي رھيا آھيون) ته توھان جي ايپليڪيشن کي لوڊ ٿيڻ ۾ ڪيترائي منٽ لڳن ٿا.

جيڪڏهن اهو معاملو آهي، ته پوء اضافي mycoservice مسئلن کي شامل ڪرڻ (نيٽ ورڪ جي لچڪ، ميسيجنگ، DevOps، انفراسٽرڪچر) توهان جي منصوبي تي هڪ خالي هيلو، دنيا کي لوڊ ڪرڻ جي ڀيٽ ۾ تمام گهڻو اثر ٿيندو. ۽ ترقي جي دوران گرم ٻيهر بحالي لاء، توهان شايد حل سان ختم ڪري سگهون ٿا JRebel يا DCEVM . اچو ته هڪ لمحو وٺي سائمن براون جو حوالو ڏيون : ” جيڪڏهن ماڻهو (تيز ۽ ڪارآمد) monoliths ٺاهي نٿا سگهن، ته انهن کي بنا ڪنهن ساخت جي (تيز ۽ ڪارائتو) مائڪرو سروسز ٺاهڻ ۾ ڏکيائي ٿيندي . تنھنڪري پنھنجي فريم ورڪ کي سمجھاڻي سان چونڊيو.

ڪهڙيون لائبريريون هم وقت ساز جاوا REST ڪالن لاءِ بهترين آهن؟

گھٽ-سطح ٽيڪنيڪل پاسي، توھان ممڪن طور ھيٺ ڏنل HTTP ڪلائنٽ لائبريرين مان ھڪڙي سان ختم ڪنداسين: جاوا جي اصلي HttpClient (جاوا 11 کان وٺي)، Apache جي HttpClient ، يا OkHttp . نوٽ ڪريو ته مان چوان ٿو "شايد" هتي ڇو ته ٻيا آپشن آهن، جن ۾ سٺن پراڻن JAX-RS ڪلائنٽ کان وٺي جديد WebSocket ڪلائنٽ تائين . ڪنهن به صورت ۾، رجحان هڪ HTTP ڪلائنٽ پيدا ڪرڻ جي طرف آهي، پنهنجي پاڻ کي HTTP ڪالن سان ڀرجي وڃڻ کان پري وڃڻ. هن کي ڪرڻ لاءِ، توهان کي ڏسڻ جي ضرورت آهي OpenFeign پروجيڪٽ ۽ ان جي دستاويز کي وڌيڪ پڙهڻ لاءِ شروعاتي نقطي طور.

Asynchronous Java ميسيجنگ لاءِ بهترين بروکر ڪهڙا آهن؟

گهڻو ڪري، توهان وٽ ايندا مشهور ActiveMQ (Classic or Artemis) , RabbitMQ يا Kafka .

• ActiveMQ ۽ RabbitMQ روايتي، مڪمل ميسيج بروڪرز آھن. اهي هڪ "سمارٽ بروکر" ۽ "بيوقوف استعمال ڪندڙ" جي رابطي ۾ شامل آهن.
• تاريخي طور تي، ActiveMQ وٽ آسان ان لائننگ جو فائدو آهي (ٽيسٽنگ لاءِ)، جنهن کي RabbitMQ/Docker/TestContainer سيٽنگن سان گھٽائي سگهجي ٿو.
• ڪافڪا کي روايتي ”سمارٽ“ بروکر نٿو چئي سگهجي. ان جي بدران، اهو هڪ نسبتا "گونگا" پيغام اسٽور (لاگ فائل) آهي جنهن کي عمل ڪرڻ لاء سمارٽ صارفين جي ضرورت آهي.

بهتر سمجهڻ لاءِ جڏهن استعمال ڪجي RabbitMQ (يا عام طور تي ٻيا روايتي پيغام بروڪرز) يا ڪافڪا، هڪ نظر وٺو هن Pivotal پوسٽ کي شروعاتي نقطي طور. عام طور تي، جڏهن هڪ پيغام رسائيندڙ بروکر چونڊيو، مصنوعي ڪارڪردگي سببن کي نظر انداز ڪرڻ جي ڪوشش ڪريو. هڪ وقت هو جڏهن ٽيمون ۽ آن لائين برادريون مسلسل بحث ڪنديون هيون ته RabbitMQ ڪيترو تيز هو ۽ ActiveMQ ڪيترو سست هو. هاڻي ساڳيا دليل RabbitMQ جي حوالي سان ڪيا ويا آهن، انهن جو چوڻ آهي ته اهو سست رفتار سان ڪم ڪري ٿو 20-30 هزار پيغام في سيڪنڊ سان. ڪافڪا 100 هزار پيغام في سيڪنڊ رڪارڊ ڪري ٿو. سچ ڳالهائڻ، اهڙيون مقابلو نرم سان گرم جي مقابلي وانگر آهن. اضافي طور تي، ٻنهي صورتن ۾ throughput قدر شايد گهٽ کان وچين حد تائين، چون ٿا، علي بابا گروپ. تنهن هوندي، توهان ممڪن ناهي ته هن پيماني جي منصوبن سان منهن ڪيو هجي (ملين پيغام في منٽ) حقيقت ۾. اهي ضرور موجود آهن ۽ اهي مسئلا هوندا. ٻين 99٪ جي برعڪس ”باقاعده“ جاوا ڪاروباري منصوبن. تنهن ڪري فيشن ۽ hype تي ڌيان نه ڏيو. عقلمندي سان چونڊيو.

مائڪرو سروسز کي جانچڻ لاءِ مان ڪهڙيون لائبريريون استعمال ڪري سگهان ٿو؟

اهو توهان جي اسٽيڪ تي منحصر آهي. جيڪڏهن توهان وٽ اسپرنگ ايڪو سسٽم لڳايو ويو آهي، اهو فريم ورڪ جي مخصوص اوزارن کي استعمال ڪرڻ عقلمند هوندو . جيڪڏهن JavaEE Arquillian وانگر ڪجهه آهي . اهو هڪ نظر وٺڻ جي قابل ٿي سگهي ٿو Docker ۽ واقعي سٺي ٽيسٽ ڪنٽينرز لائبريري ، جيڪا خاص طور تي مقامي ترقي يا انٽيگريشن ٽيسٽ لاءِ آساني سان ۽ جلدي هڪ Oracle ڊيٽابيس قائم ڪرڻ ۾ مدد ڪري ٿي. ٺٺولي جاچ لاءِ پوري HTTP سرورز، چيڪ ڪريو Wiremock . Asynchronous Messaging کي جانچڻ لاءِ، ActiveMQ يا RabbitMQ لاڳو ڪرڻ جي ڪوشش ڪريو ۽ پوءِ Awaitility DSL استعمال ڪندي ٽيسٽون لکو . اضافي طور تي، توهان جا سڀئي معمولي اوزار استعمال ڪيا ويا آهن - Junit ، TestNG for AssertJ ۽ Mockito . مهرباني ڪري نوٽ ڪريو ته هي هڪ مڪمل فهرست نه آهي. جيڪڏهن توهان هتي پنهنجو پسنديده اوزار نه ڳوليندا آهيو، مهرباني ڪري ان کي تبصري سيڪشن ۾ پوسٽ ڪريو.

سڀني جاوا مائڪرو سروسز لاءِ لاگنگ کي ڪيئن فعال ڪجي؟

microservices جي صورت ۾ لاگ ان هڪ دلچسپ ۽ بلڪه پيچيده موضوع آهي. هڪ لاگ فائل رکڻ جي بدران جنهن کي توهان گهٽ يا گريپ ڪمانڊ سان ٺاهي سگهو ٿا، توهان وٽ هاڻي اين لاگ فائلون آهن، ۽ توهان چاهيو ٿا ته اهي تمام پکڙيل نه هجن. لاگنگ ايڪو سسٽم جون خاصيتون هن مضمون ۾ چڱي طرح بيان ڪيون ويون آهن (انگريزي ۾). ان کي پڙهڻ جي پڪ ڪريو، ۽ سيڪشن ڏانهن ڌيان ڏيو مرڪزي لاگنگ هڪ microservices نقطه نظر کان . عملي طور تي، توهان مختلف طريقن سان ملندا: سسٽم منتظم ڪجهه لکت لکندو آهي جيڪي مختلف سرورن مان لاگ فائلن کي گڏ ڪري ۽ گڏ ڪن ٿا هڪ واحد لاگ فائل ۾ ۽ انهن کي ڊائون لوڊ ڪرڻ لاءِ FTP سرورز تي رکي ٿو. رننگ ٻلي/گريپ/يونيگ/ترتيب جو مجموعو متوازي SSH سيشن ۾. اھو اھو آھي جيڪو Amazon AWS ڪندو آھي، ۽ توھان پنھنجي مينيجر کي ٻڌائي سگھو ٿا. ھڪڙو اوزار استعمال ڪريو جهڙوڪ گريلوگ يا اي ايل ڪي اسٽيڪ (لچڪدار ڳولا، لاگسٽاش، ڪبانا)

منهنجا مائڪرو سروسز هڪ ٻئي کي ڪيئن ڳوليندا آهن؟

هينئر تائين، اسان فرض ڪيو آهي ته اسان جون مائڪرو سروسز هڪ ٻئي جي باري ۾ ڄاڻون ٿا ۽ لاڳاپيل IPS کي ڄاڻون ٿا. اچو ته جامد ترتيب جي باري ۾ ڳالهايون. تنهن ڪري، اسان جي بئنڪنگ monolith [ip = 192.168.200.1] ڄاڻي ٿو ته ان کي خطري جي سرور سان ڳالهائڻ جي ضرورت آهي [ip = 192.168.200.2]، جيڪو ملڪيت جي فائل ۾ هارڊ ڪوڊ ٿيل آهي. تنهن هوندي، توهان شين کي وڌيڪ متحرڪ بڻائي سگهو ٿا:

• ڪلائوڊ بيسڊ ڪنفيگريشن سرور استعمال ڪريو جتان سڀ مائيڪرو سروسز ان جي ٺاھ جوڙ کي ڪڍن بجاءِ ايپليڪيشن.پراپرٽيز فائلن کي ڊيپلائي ڪرڻ بجاءِ پنھنجي مائڪرو سروسز تي.
• جيئن ته توهان جي خدمت جا مثال متحرڪ طور تي پنهنجو مقام تبديل ڪري سگهن ٿا، اهو انهن خدمتن کي ڏسڻ جي قابل آهي جيڪي ڄاڻن ٿا ته توهان جون خدمتون ڪٿي رهن ٿيون، انهن جا IP ڇا آهن، ۽ انهن کي ڪيئن روٽ ڪجي.
• هاڻي ته سڀ ڪجهه متحرڪ آهي، نوان مسئلا پيدا ٿين ٿا، جهڙوڪ ليڊر جي خودڪار چونڊ: اهو ماسٽر ڪير آهي جيڪو ڪجهه ڪمن تي ڪم ڪري ٿو ته جيئن انهن کي ٻه ڀيرا پروسيس نه ڪيو وڃي، مثال طور؟ ڪنهن ليڊر جي جاءِ ڪير وٺندو جڏهن هو ناڪام ٿيندو؟ ڪهڙي بنياد تي بدلي وٺندي؟

عام اصطلاحن ۾، هي اهو آهي جنهن کي microservice orchestration چئبو آهي ۽ اهو هڪ ٻيو بي بنياد موضوع آهي. لائبريريون جهڙوڪ Eureka يا Zookeeper انهن مسئلن کي ”حل“ ڪرڻ جي ڪوشش ڪندي ڏيکاريو ته ڪهڙيون خدمتون موجود آهن. ٻئي طرف، اهي اضافي پيچيدگي متعارف ڪرايو. هر ڪنهن کان پڇو جنهن ڪڏهن زو ڪيپر نصب ڪيو آهي.

جاوا مائڪرو سروسز استعمال ڪندي اختيار ۽ تصديق کي ڪيئن منظم ڪجي؟

هي موضوع به هڪ الڳ ڪهاڻيءَ جي لائق آهي. ٻيهر، اختيارن جي حد هارڊ ڪوڊ ٿيل بنيادي HTTPS جي تصديق کان وٺي ڪسٽم سيڪيورٽي فريم ورڪ سان Oauth2 تنصيب کي هلائڻ تائين ان جي پنهنجي اختيار واري سرور سان.

مان ڪيئن پڪ ڪري سگهان ٿو ته منهنجا سڀئي ماحول ساڳيا نظر اچن ٿا؟

مائيڪرو سروس کان سواءِ ڊيپلائيمينٽس لاءِ جيڪو سچ آهي اهو هڪ سان ڊيپلائيمينٽس لاءِ به صحيح آهي. ڪوشش ڪريو Docker/Test Containers ۽ Scripting/Ansible جو مجموعو.

ڪوبه سوال ناهي: مختصر طور تي YAML بابت

اچو ته هڪ لمحي لاءِ لائبريرين ۽ لاڳاپيل مسئلن کان پري ٿي وڃون ۽ يامل تي تڪڙو نظر وجهون. هي فائيل فارميٽ استعمال ڪيو ويندو آهي حقيقت ۾ فارميٽ جي طور تي "لکڻ جي ترتيب کي ڪوڊ جي طور تي." اهو پڻ استعمال ڪيو ويندو آهي سادو اوزار جهڙوڪ جوابي ۽ گينٽ جهڙوڪ ڪبرنيٽس. YAML انڊينٽيشن جي درد کي محسوس ڪرڻ لاءِ، هڪ سادي جوابي فائل لکڻ جي ڪوشش ڪريو ۽ ڏسو ته توهان کي فائل کي ڪيترو ايڊٽ ڪرڻو آهي ان کان اڳ جو اهو ڪم ڪري جيئن توقع ڪئي وڃي. ۽ هي فارميٽ سڀني وڏن IDEs پاران سپورٽ ٿيڻ جي باوجود! ان کان پوء، هن گائيڊ پڙهڻ کي ختم ڪرڻ لاء واپس اچو.

Yaml:
  - is:
    - so
    - great

ورهايل ٽرانزيڪشن بابت ڇا؟ ڪارڪردگي جاچ؟ ٻيا موضوع؟

ٿي سگهي ٿو ڪنهن ڏينهن، دستياب جي مستقبل جي ايڊيشن ۾. في الحال، اهو سڀ ڪجهه آهي. اسان سان گڏ رهو!

Microservices سان تصوراتي مسئلا

جاوا ۾ مائڪرو سروسز جي مخصوص مسئلن کان علاوه، ٻيا مسئلا آهن، اچو ته چئو، جيڪي ڪنهن به مائڪرو سروسز پروجيڪٽ ۾ ظاهر ٿيندا آهن. انهن جو تعلق اڪثر ڪري تنظيم، ٽيم ۽ انتظام سان.

اڳيون ۽ پسمانده بي ترتيب

ڪيترن ئي مائڪرو سروسز پروجيڪٽس ۾ فرنٽ اينڊ بيڪ اينڊ بي ميل هڪ تمام عام مسئلو آهي. هن جو ڇا مطلب آهي؟ صرف اهو آهي ته سٺي پراڻي monoliths ۾، ويب انٽرفيس ڊولپرز وٽ ڊيٽا حاصل ڪرڻ لاء هڪ خاص ذريعو هو. microservice منصوبن ۾، سامهون-آخر ڊولپرز وٽ اوچتو ڊيٽا حاصل ڪرڻ جا ذريعا آهن. تصور ڪريو ته توھان جاوا ۾ ڪجھ قسم جي IoT (انٽرنيٽ آف تھنگز) مائڪرو سروسز پروجيڪٽ ٺاھي رھيا آھيو. اچو ته چئو ته توهان سڄي يورپ ۾ جيوڊيٽڪ مشينن ۽ صنعتي فرنس جو انتظام ڪريو. ۽ اهي اوون توهان کي انهن جي درجه حرارت ۽ پسند سان باقاعده اپڊيٽ موڪليندا آهن. جلدي يا بعد ۾ توهان شايد منتظم UI ۾ اوون ڳولڻ چاهيندا، شايد "فرنس سرچ" مائڪرو سروسز استعمال ڪندي. ان تي منحصر آهي ته توهان جا پس منظر وارا هم منصب ڊومين تي هلندڙ ڊيزائن يا مائڪرو سروسز قانونن کي ڪيئن سختي سان لاڳو ڪن ٿا، هڪ ”اوون ڳولهيو“ مائڪرو سروس صرف اوون ID واپس ڪري سگهي ٿي ۽ ٻيو ڊيٽا نه جيئن قسم، ماڊل، يا مقام. هن کي ڪرڻ لاءِ، فرنٽ اينڊ ڊولپرز کي ضرورت پوندي ته هڪ يا اين اضافي ڪالون (انحصار پيجنگ تي عمل درآمد تي) ”حاصل فرنس ڊيٽا“ مائيڪرو سروس ۾ انهن IDن سان جيڪي انهن کي پهرين مائڪرو سروس مان مليون آهن. ۽ جيتوڻيڪ اهو صرف هڪ سادي مثال آهي، جيتوڻيڪ هڪ حقيقي (!) منصوبي مان ورتو ويو آهي، جيتوڻيڪ اهو هيٺين مسئلي کي ظاهر ڪري ٿو: سپر مارڪيٽ انتهائي مقبول ٿي چڪا آهن. اهو ان ڪري جو انهن سان گڏ توهان کي ڀاڄيون، ليمونيڊ، منجمد پيزا ۽ ٽوائلٽ پيپر خريد ڪرڻ لاءِ 10 مختلف هنڌن تي وڃڻ جي ضرورت ناهي. ان جي بدران، توهان هڪ جاء تي وڃو، اهو آسان ۽ تيز آهي. ساڳيو ئي فرنٽ اينڊ ۽ مائڪرو سروس ڊولپرز لاءِ آهي.

انتظامي اميدون

انتظاميا غلط تاثر هيٺ آهي ته انهن کي هاڻي ضرورت آهي لامحدود تعداد ۾ ڊولپرز کي هڪ (اوور آرچنگ) پروجيڪٽ لاءِ، ڇو ته ڊولپر هاڻي مڪمل طور تي هڪ ٻئي کان آزاديءَ سان ڪم ڪري سگهن ٿا، هر هڪ پنهنجي پنهنجي مائڪرو سروس تي. صرف ٿورڙي انضمام واري ڪم جي ضرورت آهي تمام آخر ۾ (لنچ کان ٿورو اڳ). حقيقت ۾، هي طريقو انتهائي مشڪل آهي. هيٺين پيراگراف ۾ اسان وضاحت ڪرڻ جي ڪوشش ڪنداسين ڇو.

"ننڍا ٽڪرا" برابر نه آهن "بهتر ٽڪر"

اهو فرض ڪرڻ هڪ وڏي غلطي هوندي ته ڪوڊ 20 حصن ۾ ورهايل لازمي طور تي هڪ پوري ٽڪڙي کان اعليٰ معيار جو هوندو. جيتوڻيڪ اسان معيار کي خالص ٽيڪنيڪل نقطه نظر کان وٺي سگهون ٿا، اسان جون انفرادي خدمتون اڃا به هلائي رهيون آهن 400 Hibernate سوالن کي ڊيٽابيس مان صارف کي چونڊڻ لاءِ، اڻ سڌريل ڪوڊ جي پرتن کي پار ڪندي. هڪ دفعو ٻيهر، اسان سائمن براون جي اقتباس ڏانهن موٽون ٿا: جيڪڏهن توهان صحيح طريقي سان 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 کي فيشنبل Erlang ۾ لکون. ۽ اچو ته ڳاڙهي ڪارا وڻ ڪٿي استعمال ڪرڻ جي ڪوشش ڪريون، ڇاڪاڻ ته اسٽيو يگ لکيو آهي ته گوگل تي لاڳو ڪرڻ لاءِ توهان کي انهن کي اندر کان ٻاهر ڄاڻڻو پوندو. هڪ انضمام، سار سنڀال، ۽ مجموعي ڊيزائن جي نقطه نظر کان، اهو هڪ واحد واحد اندر اسپگيٽي ڪوڊ جي پرت لکڻ جي طور تي خراب آهي. هڪ مصنوعي ۽ عام مثال؟ هي سچ آهي. بهرحال، اهو حقيقت ۾ ٿي سگهي ٿو.

ٿورا ٽڪرا - گهٽ سمجھڻ

پوءِ سوال قدرتي طور تي اچي ٿو ته سسٽم کي مڪمل طور تي سمجهڻ، ان جي عملن ۽ ڪم جي وهڪري جي، پر ساڳئي وقت توهان، هڪ ڊولپر جي حيثيت ۾، صرف توهان جي الڳ ٿيل مائڪرو سروس تي ڪم ڪرڻ جا ذميوار آهيو [95: login-101: updateUserProfile]. اهو پوئين پيراگراف سان هموار ٿئي ٿو، پر توهان جي تنظيم، اعتماد جي سطح ۽ رابطي جي بنياد تي، اهو تمام گهڻو مونجهارو، ڇڪتاڻ، ۽ الزام جو سبب بڻجي سگهي ٿو جيڪڏهن مائڪرو سروس چين ۾ هڪ حادثاتي خرابي آهي. ۽ ڪو به اهڙو ناهي جيڪو جيڪو ٿيو ان جي مڪمل ذميواري قبول ڪري. ۽ اها ڪا به بي ايماني جي ڳالهه ناهي. حقيقت ۾، مختلف حصن کي ڳنڍڻ ۽ منصوبي جي مجموعي تصوير ۾ انهن جي جڳهه کي سمجهڻ تمام ڏکيو آهي.

ڪميونيڪيشن ۽ سروس

ڪمپني جي سائيز جي لحاظ سان رابطي ۽ خدمت جي سطح تمام گھڻو مختلف ٿي سگھي ٿو. بهرحال، عام تعلق واضح آهي: وڌيڪ، وڌيڪ مشڪل.

• ڪير هلائي ٿو microservice #47؟
• ڇا اهي صرف هڪ microservice جو هڪ نئون، غير مطابقت وارو نسخو لڳايو؟ هي دستاويز ڪٿي هو؟
• نئين خصوصيت جي درخواست ڪرڻ لاءِ مون کي ڪنهن سان ڳالهائڻ جي ضرورت آهي؟
• ڪير اِرلنگ ۾ مائڪرو سروس جي حمايت ڪندو، صرف هڪ کان پوء جيڪو هن ٻولي ڄاڻي ٿو ڪمپني ڇڏي؟
• اسان جون سڀئي مائيڪرو سروس ٽيمون ڪم ڪن ٿيون نه رڳو مختلف پروگرامنگ ٻولين ۾، پر مختلف ٽائم زونن ۾ به! اسان اهو سڀ ڪجهه صحيح طريقي سان ڪيئن منظم ڪريون ٿا؟

بنيادي نقطو اهو آهي ته، جيئن DevOps سان، هڪ وڏي، شايد بين الاقوامي ڪمپني ۾ مائڪرو سروسز لاء مڪمل طريقي سان، اضافي رابطي جي مسئلن جي هڪ گروپ سان گڏ اچي ٿو. ۽ ڪمپني کي سنجيدگي سان هن لاء تيار ڪرڻ گهرجي.

نتيجا

هن مضمون پڙهڻ کان پوء، توهان سوچيو ته ليکڪ microservices جو هڪ پرجوش مخالف آهي. اهو مڪمل طور تي درست نه آهي - مان بنيادي طور تي انهن نقطن کي اجاگر ڪرڻ جي ڪوشش ڪري رهيو آهيان جن تي ڪجهه ماڻهو ڌيان ڏيندا آهن نئين ٽيڪنالاجي جي چريو نسل ۾.

Microservices يا monolith؟

جاوا مائڪرو سروسز استعمال ڪرڻ ڪنهن به وقت، ڪٿي به هڪ انتهائي آهي. ٻيو ڪجهه ٿي وڃي ٿو جهڙوڪ سوين سٺا پراڻا Maven ماڊلز هڪ monolith ۾. توهان جو ڪم صحيح توازن ڳولڻ آهي. اهو خاص طور تي نئين منصوبن لاء صحيح آهي. ويهن ڪلائوڊ تيار مائڪرو سروسز سان شروع ڪرڻ جي بجاءِ ، توهان کي وڌيڪ قدامت پسند ، ”مونوليٿڪ“ انداز اختيار ڪرڻ ۽ گهٽ سٺا ماوين ماڊلز ٺاهڻ کان روڪڻ لاءِ ڪجهه به ناهي.

Microservices اضافي پيچيدگي پيدا ڪري ٿي

ذهن ۾ رکو ته توهان وٽ جيتريون وڌيڪ مائڪرو سروسز آهن ۽ گهٽ واقعي طاقتور DevOps توهان وٽ آهن (نه، هڪ ٻه جوابي اسڪرپٽ هلائڻ يا هيروڪو کي ترتيب ڏيڻ ڳڻپ نٿو ڪري!)، توهان کي وڌيڪ مسئلا بعد ۾ عمل ۾ ايندا. جيتوڻيڪ جاوا مائڪرو سروسز بابت عام سوالن لاءِ وقف ڪيل هن گائيڊ جي سيڪشن جي آخر تائين پڙهڻ ڪافي مشڪل ڪم آهي. انهن سڀني بنيادي ڍانچي جي مسئلن جي حل کي لاڳو ڪرڻ جي باري ۾ سخت سوچيو ۽ توهان اوچتو محسوس ڪندا ته اهو هاڻي ڪاروباري پروگرامنگ بابت نه آهي (جيڪو توهان کي ادا ڪيو وڃي ٿو) بلڪه وڌيڪ ٽيڪنالاجي تي وڌيڪ ٽيڪنالاجي کي درست ڪرڻ بابت. شيوا پرساد ريڊي ان کي پنهنجي بلاگ ۾ مڪمل طور تي خلاصو ڪيو : ”توهان کي خبر ناهي ته اهو ڪيترو خوفناڪ هوندو آهي جڏهن هڪ ٽيم 70 سيڪڙو وقت هن جديد انفراسٽرڪچر سان جدوجهد ڪندي گذاريندي آهي ۽ صرف 30 سيڪڙو وقت حقيقي ڪاروباري منطق کي انجام ڏيڻ لاءِ ڇڏي ويندو آهي. " شيوا پرساد ريڊي

ڇا اهو جاوا مائڪرو سروسز ٺاهڻ جي لائق آهي؟

هن سوال جو جواب ڏيڻ لاء، مان هن مضمون کي ختم ڪرڻ چاهيان ٿو هڪ تمام گستاخي، گوگل انٽرويو جهڙو ٽيزر سان. جيڪڏهن توهان ڄاڻو ٿا ته هن سوال جو جواب تجربي مان، جيتوڻيڪ اهو محسوس نٿو ٿئي ته اهو microservices سان ڪو به واسطو نه آهي، توهان شايد تيار ٿي وڃو microservices اپروچ لاءِ.

منظرنامو

تصور ڪريو ته توھان وٽ ھڪڙو جاوا monolith آھي اڪيلو ھلندڙ ننڍڙو Hetzner وقف سرور تي . ساڳيو ئي توهان جي ڊيٽابيس سرور تي لاڳو ٿئي ٿو، اهو پڻ هلندڙ آهي ساڳي هزنر مشين تي . ۽ اچو ته اهو پڻ فرض ڪريون ته توهان جو جاوا مونولٿ ڪم فلوز کي سنڀالي سگهي ٿو، چئو صارف جي رجسٽريشن، ۽ توهان هر ڪم فلو تي سوين ڊيٽابيس سوالن کي نه ٺاهي رهيا آهيو، پر هڪ وڌيڪ معقول نمبر (<10).

سوال

توهان جي ڊيٽابيس سرور تي توهان جا جاوا مونولٿ (ڪنيڪشن پول) ڪيترا ڊيٽابيس ڪنيڪشن کولڻ گهرجن؟ ائين ڇو آهي؟ ڪيترا سمورو فعال استعمال ڪندڙ توهان سوچيو ٿا ته توهان جو مونولٿ (تقريبن) ماپ ڪري سگهي ٿو؟

جواب

انهن سوالن جا پنهنجا جواب تبصري سيڪشن ۾ ڇڏي ڏيو. مان سڀني جوابن جو منتظر آهيان. هاڻي پنهنجو ذهن ٺاهيو. جيڪڏهن توهان آخر تائين پڙهي، اسان توهان جا شڪرگذار آهيون!