سلام! منهنجو نالو Vadim Madison آهي، آئون Avito سسٽم پليٽ فارم جي ترقي جي اڳواڻي ڪريان ٿو. اهو هڪ کان وڌيڪ ڀيرا چيو ويو آهي ته اسان ڪيئن ڪمپني ۾ هڪ monolithic فن تعمير کان هڪ microservices ڏانهن منتقل ڪري رهيا آهيون. اهو وقت آهي شيئر ڪرڻ جو ته ڪيئن اسان پنهنجي بنيادي ڍانچي کي تبديل ڪيو آهي ته جيئن مائڪرو سروسز مان وڌ کان وڌ فائدو حاصل ڪري ۽ پاڻ کي انهن ۾ گم ٿيڻ کان روڪيو. PaaS هتي اسان جي ڪيئن مدد ڪري ٿو، اسان ڪيئن ترتيب ڏيڻ کي آسان ڪيو ۽ هڪ ڪلڪ تي مائڪرو سروس جي تخليق کي گهٽايو - پڙهو. هر شيءِ ناهي جنهن بابت آئون هيٺ لکان ٿو مڪمل طور تي Avito ۾ لاڳو ٿيل آهي، ان مان ڪجهه اهو آهي ته اسان پنهنجي پليٽ فارم کي ڪيئن ترقي ڪندا آهيون.
(۽ هن مضمون جي آخر ۾، مان هڪ ٽن ڏينهن جي سيمينار ۾ شرڪت ڪرڻ جي موقعي جي باري ۾ ڳالهائيندس مائڪرو سروس آرڪيٽيڪچر ماهر ڪرس رچرڊسن).
اسان ڪيئن آيا microservices
Avito دنيا جي سڀ کان وڏي درجه بندي سائيٽن مان هڪ آهي؛ ان تي روزانو 15 ملين کان وڌيڪ نوان اشتهار شايع ٿيندا آهن. اسان جو پس منظر 20 هزار کان وڌيڪ درخواستون في سيڪنڊ قبول ڪري ٿو. اسان وٽ في الحال ڪيترائي سئو مائڪرو سروسز آهن.
اسان ڪيترن ئي سالن کان مائڪرو سروس آرڪيٽيڪچر ٺاهي رهيا آهيون. ڪيئن بلڪل - تفصيل ۾ اسان جي ساٿين اسان جي سيڪشن تي RIT++ 2017 تي. CodeFest 2017 تي (ڏسو. )، سرجي اورلوف ۽ ميخائل پروڪوپچڪ تفصيل سان ٻڌايو ته اسان کي مائڪرو سروسز ڏانهن منتقلي جي ضرورت ڇو آهي ۽ ڪبرنيٽس هتي ڪهڙو ڪردار ادا ڪيو. خير، هاڻي اسان سڀ ڪجهه ڪري رهيا آهيون اسڪيلنگ جي قيمتن کي گهٽائڻ لاءِ جيڪي اهڙي فن تعمير ۾ شامل آهن.
شروعات ۾، اسان هڪ ماحولياتي نظام نه ٺاهيو هو جيڪو اسان کي مائڪرو سروسز کي ترقي ۽ لانچ ڪرڻ ۾ مڪمل طور تي مدد ڪري. انهن صرف گڏ ڪيو سمجھدار اوپن سورس حل، انهن کي گهر ۾ شروع ڪيو ۽ ڊولپر کي دعوت ڏني ته انهن سان معاملو ڪرڻ لاء. نتيجي طور، هو درجنين هنڌن تي ويو (ڊيش بورڊ، اندروني خدمتون)، جنهن کان پوء هن پنهنجي خواهش ۾ مضبوط ٿي ويو ته پراڻي طريقي سان ڪوڊ ڪٽي، هڪ واحد ۾. هيٺ ڏنل تصويرن ۾ سائو رنگ ظاهر ڪري ٿو ته ڊولپر پنهنجي هٿن سان هڪ طريقو يا ٻيو ڇا ڪندو آهي، ۽ پيلو رنگ خودڪار طريقي سان اشارو ڪري ٿو.
ھاڻي PaaS CLI افاديت ۾، ھڪڙي نئين خدمت ھڪڙي حڪم سان ٺاھيو ويو آھي، ۽ ھڪڙو نئون ڊيٽابيس شامل ڪيو ويو آھي ٻن وڌيڪ ۽ اسٽيج تي لڳايو ويو آھي.
"مائڪرو سروس فريگمينٽيشن" جي دور کي ڪيئن ختم ڪجي
هڪ monolithic فن تعمير سان، پيداوار ۾ تبديلين جي تسلسل جي خاطر، ڊولپرز کي اهو سمجهڻ تي مجبور ڪيو ويو ته انهن جي پاڙيسرين سان ڇا ٿي رهيو آهي. جڏهن نئين فن تعمير تي ڪم ڪري رهيا آهن، خدمت جي حوالي سان هاڻي هڪ ٻئي تي منحصر نه آهن.
اضافي طور تي، هڪ microservice فن تعمير کي اثرائتو بڻائڻ لاء، ڪيترن ئي عملن کي قائم ڪرڻ جي ضرورت آهي، يعني:
• لاگنگ؛
• ٽريڪنگ جي درخواست (جيگر)؛
• غلطي جمع (سنٽري)؛
• ڪيبرنيٽس (ايونٽ اسٽريم پروسيسنگ) کان اسٽيٽس، پيغام، واقعا؛
• ريس جي حد / سرڪٽ برڪر (توهان استعمال ڪري سگهو ٿا Hystrix)؛
• سروس رابطي جو ڪنٽرول (اسان استعمال ڪندا آهيون Netramesh)؛
• نگراني (Grafana)؛
• اسيمبلي (TeamCity);
• رابطي ۽ نوٽيفڪيشن (سليڪ، اي ميل)؛
• ڪم ٽريڪنگ؛ (جيرا)
• دستاويز جي تياري.
انهي ڳالهه کي يقيني بڻائڻ لاءِ ته سسٽم پنهنجي سالميت کي نه وڃائيندو آهي ۽ اثرائتو رهي ٿو جيئن اهو ماپ ڪري ٿو، اسان Avito ۾ مائڪرو سروسز جي تنظيم تي ٻيهر غور ڪيو.
اسان مائڪرو سروسز کي ڪيئن منظم ڪريون ٿا
ڪيترن ئي Avito microservices جي وچ ۾ هڪ متحد "پارٽي پاليسي" کي لاڳو ڪرڻ ۾ هيٺين مدد:
- بنيادي ڍانچي کي تہه ۾ ورهائڻ؛
- پليٽ فارم هڪ خدمت جي طور تي (PaaS) تصور؛
- مائڪرو سروسز سان هر شيءِ جي نگراني.
انفراسٽرڪچر جي تجزيي جي تہن ۾ ٽي تہون شامل آھن. اچو ته مٿي کان هيٺ وڃو.
A. مٿي - خدمت mesh. پهرين ۾ اسان Istio جي ڪوشش ڪئي، پر اهو ظاهر ٿيو ته اهو تمام گهڻا وسيلا استعمال ڪري ٿو، جيڪو اسان جي حجم لاء تمام قيمتي آهي. تنهن ڪري، فن تعمير جي ٽيم ۾ سينئر انجنيئر اليگزينڊر لوڪانچينڪو پنهنجو حل تيار ڪيو. (اوپن ماخذ ۾ دستياب آهي)، جيڪو اسان هن وقت پيداوار ۾ استعمال ڪندا آهيون ۽ جيڪو Istio جي ڀيٽ ۾ ڪيترائي ڀيرا گهٽ وسيلا استعمال ڪري ٿو (پر اهو سڀ ڪجهه نٿو ڪري جيڪو Istio فخر ڪري سگهي ٿو).
B. وچولي - ڪبرنيٽس. اسان ان تي مائيڪرو سروسز ٺاهي ۽ هلائيندا آهيون.
C. هيٺيون - ننگي ڌاتو. اسان بادل يا شيون استعمال نٿا ڪريون جهڙوڪ OpenStack، پر مڪمل طور تي ننگي ڌاتو تي ڀروسو ڪندا آهيون.
سڀئي پرتون PaaS پاران گڏيل آهن. ۽ هي پليٽ فارم، موڙ ۾، ٽن حصن تي مشتمل آهي.
I. جنريٽر، CLI يوٽيلٽي ذريعي ڪنٽرول. اها هوءَ آهي جيڪا ڊولپر جي مدد ڪري ٿي مائڪرو سروس ٺاهڻ ۾ صحيح طريقي سان ۽ گهٽ ۾ گهٽ ڪوشش سان.
II. گڏيل جمع ڪندڙ هڪ عام ڊيش بورڊ ذريعي سڀني اوزارن جي ڪنٽرول سان.
III. ذخيرو. شيڊولرز سان ڳنڍيندو آهي جيڪي خودڪار طور تي اهم ڪارناما لاءِ ٽارگيٽ سيٽ ڪندا آهن. اهڙي سسٽم جي مهرباني، هڪ به ڪم نه وڃايو ويو آهي صرف ان ڪري جو ڪو ماڻهو جيرا ۾ هڪ ٽاسڪ قائم ڪرڻ وساري ويو. اسان ان لاءِ ائٽلس نالي هڪ اندروني اوزار استعمال ڪندا آهيون.
Avito ۾ microservices تي عمل درآمد پڻ ھڪڙي ھڪڙي منصوبي جي مطابق ڪيو ويو آھي، جيڪو ترقي ۽ ڇڏڻ جي هر مرحلي تي انھن تي ڪنٽرول کي آسان بڻائي ٿو.
هڪ معياري مائڪرو سروس ڊولپمينٽ پائيپ لائين ڪيئن ڪم ڪري ٿي؟
عام طور تي، microservice تخليق جو سلسلو هن طرح نظر اچي ٿو:
CLI-push → Continuous Integration → Bake → Deploy → Artificial tests → Canary tests → Squeeze Testing → Production → Maintenance.
اچو ته ان جي ذريعي وڃو بلڪل هن ترتيب ۾.
CLI-Push
• هڪ microservice ٺاهڻ.
اسان هڪ ڊگهي وقت تائين جدوجهد ڪئي هر ڊولپر کي سيکارڻ لاءِ ته مائڪرو سروسز ڪيئن ڪجي. ھن ۾ سنگم ۾ تفصيلي ھدايتون لکڻ شامل آھن. پر اسڪيمون تبديل ٿي ويون ۽ مڪمل ڪيون ويون. نتيجو اهو آهي ته سفر جي شروعات ۾ هڪ رڪاوٽ ظاهر ٿيو: اهو مائڪرو سروسز شروع ڪرڻ لاء گهڻو وقت ورتو، ۽ اڃا به انهن جي تخليق دوران اڪثر مسئلا پيدا ٿيندا آهن.
آخر ۾، اسان هڪ سادي CLI يوٽيلٽي ٺاهي آهي جيڪا بنيادي مرحلن کي خودڪار ڪري ٿي جڏهن هڪ مائڪرو سروس ٺاهي ٿي. حقيقت ۾، اها پهرين گٽ پش کي تبديل ڪري ٿي. هتي اهو ئي آهي جيڪو هوءَ ڪري ٿي.
- ھڪڙي ٽيمپليٽ جي مطابق ھڪڙي خدمت ٺاھي ٿو - قدم بہ قدم، "وزرڊ" موڊ ۾. اسان وٽ ٽيمپليٽ آهن مکيه پروگرامنگ ٻولين لاءِ Avito پس منظر ۾: PHP، Golang ۽ Python.
- هڪ وقت ۾ هڪ حڪم هڪ مخصوص مشين تي مقامي ترقي لاءِ ماحول فراهم ڪري ٿو - Minikube لانچ ڪيو ويو آهي، هيلم چارٽ خودڪار طور تي ٺاهيا ويندا آهن ۽ مقامي ڪبرنيٽس ۾ لانچ ڪيا ويندا آهن.
- گهربل ڊيٽابيس کي ڳنڍي ٿو. ڊولپر کي ڄاڻڻ جي ضرورت نه آهي IP، لاگ ان ۽ پاسورڊ تائين رسائي حاصل ڪرڻ لاءِ ڊيٽابيس تائين رسائي حاصل ڪرڻ لاءِ هن کي گهربل آهي - اهو مقامي طور تي هجي، اسٽيج تي، يا پيداوار ۾. ان کان علاوه، ڊيٽابيس کي فوري طور تي مقرر ڪيو ويو آهي غلطي برداشت ڪرڻ واري ترتيب ۽ توازن سان.
- اهو پاڻ کي لائيو اسيمبلي انجام ڏئي ٿو. اچو ته هڪ ڊولپر پنهنجي IDE ذريعي مائڪرو سروس ۾ ڪجهه درست ڪيو. افاديت فائل سسٽم ۾ تبديليون ڏسي ٿو ۽، انهن جي بنياد تي، ايپليڪيشن کي ٻيهر ٺاهي ٿو (گولنگ لاء) ۽ ٻيهر شروع ٿئي ٿو. PHP لاءِ، اسان صرف ڊاريڪٽري کي ڪعب جي اندر اڳتي وڌو ٿا ۽ اتي لائيو ري لوڊ “خودڪار” حاصل ڪيو وڃي ٿو.
- خودڪار ٽيسٽ ٺاهي ٿو. خال جي صورت ۾، پر استعمال لاء ڪافي مناسب.
• Microservice deployment.
مائيڪرو سروس کي ترتيب ڏيڻ اسان لاءِ ٿورو ڪم هوندو هو. هيٺيان گهربل هئا:
I. Dockerfile.
II. ترتيب.
III. هيلم چارٽ، جيڪو پاڻ منجهيل آهي ۽ ان ۾ شامل آهي:
- چارٽ پاڻ؛
- ٽيمپليٽ؛
- مخصوص قدر جيڪي مختلف ماحول کي مدنظر رکندي.
اسان ڪبرنيٽس جي پڌرنامي کي ٻيهر ڪم ڪرڻ مان درد ڪڍي ڇڏيو آهي ان ڪري اهي هاڻي پاڻمرادو ٺاهيا ويا آهن. پر سڀ کان وڌيڪ اهم، انهن حد تائين ترتيب ڏيڻ کي آسان بڻائي ڇڏيو. ھاڻي اسان وٽ ھڪڙو Dockerfile آھي، ۽ ڊولپر سڄي ترتيب ھڪڙي ھڪڙي مختصر app.toml فائل ۾ لکي ٿو.
ها، ۽ app.toml ۾ پاڻ وٽ هڪ منٽ لاءِ ڪجهه به ناهي. اسان وضاحت ڪريون ٿا ته ڪٿي ۽ ڪيترين ئي نقلن جي خدمت کي وڌائڻ لاء (ديو سرور تي، اسٽيجنگ تي، پيداوار ۾)، ۽ ان جي انحصار کي ظاهر ڪريو. ليڪ جي سائيز = "ننڍو" کي نوٽ ڪريو [انجڻ] بلاڪ ۾. اها حد آهي جيڪا مختص ڪئي ويندي خدمت لاءِ Kubernetes ذريعي.
پوء، ترتيب جي بنياد تي، سڀئي ضروري هيلم چارٽ خودڪار طور تي ٺاهيا ويا آهن ۽ ڊيٽابيس سان ڪنيڪشن ٺاهي رهيا آهن.
• بنيادي تصديق. اهڙا چيڪ پڻ خودڪار آهن.
ٽريڪ ڪرڻ جي ضرورت آهي:
- اتي هڪ Dockerfile آهي؛
- اتي آهي app.toml؛
- ڇا اتي موجود دستاويز موجود آهن؟
- ڇا انحصار ترتيب ۾ آهي؟
- ڇا الرٽ ضابطا مقرر ڪيا ويا آھن.
آخري نقطي تائين: خدمت جو مالڪ پاڻ اهو طئي ڪري ٿو ته ڪهڙي پيداوار جي ميٽرڪ مانيٽر ڪرڻ لاء.
• دستاويز جي تياري.
اڃا تائين هڪ مسئلو علائقو. اهو لڳي ٿو ته اهو سڀ کان وڌيڪ واضح آهي، پر ساڳئي وقت اهو پڻ هڪ رڪارڊ آهي "اڪثر وساري"، ۽ تنهن ڪري زنجير ۾ هڪ خطرناڪ لنڪ.
اهو ضروري آهي ته هر microservice لاء دستاويز موجود آهي. ان ۾ ھيٺيون بلاڪ شامل آھن.
I. خدمت جي مختصر وضاحت. لفظي طور تي ڪجھ جملا ان بابت ڇا ڪري ٿو ۽ ڇو ان جي ضرورت آھي.
II. آرڪيٽيڪچر ڊاگرام لنڪ. اهو ضروري آهي ته ان تي هڪ تڪڙي نظر سان اهو سمجهڻ آسان آهي، مثال طور، ڇا توهان استعمال ڪري رهيا آهيو ريڊيس کي ڪيش ڪرڻ لاءِ يا مکيه ڊيٽا اسٽور جي طور تي مسلسل موڊ ۾. Avito ۾ ھاڻي اھو سنگم جي ھڪڙي لنڪ آھي.
III. رن بڪ. خدمت شروع ڪرڻ ۽ ان کي سنڀالڻ جي پيچيدگين تي هڪ مختصر گائيڊ.
IV. FAQ، جتي اهو سٺو هوندو ته انهن مسئلن جو اندازو لڳائڻ جيڪي توهان جي ساٿين کي منهن ڏئي سگهن ٿا جڏهن خدمت سان ڪم ڪري رهيا آهن.
V. API لاءِ آخري پوائنٽس جو تفصيل. جيڪڏهن اوچتو توهان منزلن جي وضاحت نه ڪئي آهي، ساٿي جن جا مائڪرو سروسز توهان سان لاڳاپيل آهن تقريبن ضرور ان لاءِ ادا ڪندا. هاڻي اسان استعمال ڪندا آهيون Swagger ۽ اسان جو حل ان لاءِ مختصر سڏيو ويندو آهي.
VI. ليبلز. يا مارڪر جيڪي ڏيکارين ٿا ته ڪهڙي پراڊڪٽ، ڪارڪردگي، يا ڪمپني جي جوڙجڪ ڊويزن جي خدمت سان تعلق رکي ٿي. اهي توهان کي جلدي سمجهڻ ۾ مدد ڪن ٿا، مثال طور، ڇا توهان ڪارڪردگي کي گهٽائي رهيا آهيو جيڪا توهان جي ساٿين هڪ هفتي اڳ ساڳئي ڪاروباري يونٽ لاءِ تيار ڪئي هئي.
VII. خدمت جا مالڪ يا مالڪ. اڪثر ڪيسن ۾، اهو - يا اهي - خودڪار طريقي سان طئي ڪري سگهجي ٿو PaaS استعمال ڪندي، پر محفوظ پاسي تي، اسان کي ڊولپر جي ضرورت آهي ته انهن کي دستي طور تي بيان ڪيو وڃي.
آخرڪار، اهو هڪ سٺو عمل آهي دستاويزن جو جائزو وٺڻ، ساڳيو ڪوڊ جائزو.
مسلسل پابندي
- ذخيرو تيار ڪرڻ.
- TeamCity ۾ پائپ لائن ٺاهڻ.
- سيٽنگ جا حق.
- خدمت جي مالڪن جي ڳولا ڪريو. هتي هڪ هائبرڊ اسڪيم آهي - دستي مارڪنگ ۽ PaaS کان گهٽ ۾ گهٽ خودڪار. مڪمل طور تي خودڪار اسڪيم ناڪام ٿي ويندي آهي جڏهن خدمتون منتقل ڪيون وينديون آهن سپورٽ لاءِ ڪنهن ٻئي ڊولپمينٽ ٽيم ڏانهن يا، مثال طور، جيڪڏهن سروس ڊولپر ڇڏي ٿو.
- Atlas ۾ هڪ خدمت رجسٽر ڪرڻ (مٿي ڏسو). ان جي سڀني مالڪن ۽ انحصار سان.
- لڏپلاڻ جي چڪاس. اسان چيڪ ڪريون ٿا ته ڇا انهن مان ڪو به خطرناڪ آهي. مثال طور، انهن مان هڪ ۾ هڪ ڦيرڦار ٽيبل يا ٻيو ڪجهه پاپ اپ ٿئي ٿو جيڪو خدمت جي مختلف نسخن جي وچ ۾ ڊيٽا اسڪيما جي مطابقت کي ٽوڙي سگهي ٿو. پوءِ لڏپلاڻ نه ڪئي وئي آهي، پر سبسڪرپشن ۾ رکيل آهي - PaaS کي خدمت جي مالڪ کي سگنل ڏيڻ گهرجي جڏهن اهو استعمال ڪرڻ لاءِ محفوظ آهي.
وٺ
ايندڙ اسٽيج آهي پيڪنگنگ سروسز ڊبليشن کان اڳ.
- ايپليڪيشن جي تعمير. جي مطابق classics - هڪ Docker تصوير ۾.
- خود خدمت ۽ لاڳاپيل وسيلن لاءِ هيلم چارٽس جي پيدائش. ڊيٽابيس ۽ ڪيش لاءِ شامل آهن. اهي خودڪار طريقي سان ٺاهيا ويا آهن app.toml ترتيب جي مطابق جيڪا CLI-push اسٽيج تي ٺاهي وئي هئي.
- بندرگاهن کي کولڻ لاءِ منتظمين لاءِ ٽڪيٽون ٺاهڻ (جڏهن گهربل هجي).
- يونٽ ٽيسٽ هلائڻ ۽ ڪوڊ ڪوريج جي حساب سان. جيڪڏهن ڪوڊ ڪوريج مخصوص حد کان هيٺ آهي، ته پوء گهڻو ڪري خدمت وڌيڪ نه ٿيندي - تعیناتي لاء. جيڪڏهن اهو قابل قبول ٿيڻ جي ڪناري تي آهي، ته پوءِ خدمت کي تفويض ڪيو ويندو ”پريشان ڪندڙ“ ڪوفيشيٽ: پوءِ، جيڪڏهن وقت گذرڻ سان اشاري ۾ ڪا بهتري نه ايندي، ڊولپر کي نوٽيفڪيشن ملندو ته ٽيسٽن جي لحاظ کان ڪا به ترقي نه ٿي آهي ( ۽ ان بابت ڪجهه ڪرڻ جي ضرورت آهي).
- ميموري ۽ سي پي يو جي حدن لاء اڪائونٽنگ. اسان بنيادي طور تي گولانگ ۾ مائڪرو سروسز لکندا آهيون ۽ انهن کي ڪبرنيٽس ۾ هلائيندا آهيون. تنهن ڪري گولانگ ٻولي جي خاصيت سان لاڳاپيل هڪ ذيلي ذخيري: ڊفالٽ طور، جڏهن شروع ٿئي ٿي، مشين تي سڀئي ڪور استعمال ڪيا ويندا آهن، جيڪڏهن توهان واضح طور تي GOMAXPROCS متغير مقرر نه ڪيو، ۽ جڏهن ساڳئي مشين تي ڪيتريون ئي خدمتون شروع ڪيون وينديون آهن، اهي شروع ٿينديون آهن. وسيلن لاءِ مقابلو ڪرڻ، هڪ ٻئي سان مداخلت ڪرڻ. هيٺ ڏنل گراف ڏيکارين ٿا ته ڪيئن عمل جو وقت بدلجي ٿو جيڪڏهن توهان ايپليڪيشن کي بغير ڪنهن تڪرار ۽ ريسورس موڊ جي ڊوڙ ۾ هلائيندا آهيو. (گرافس جا ذريعا آهن ).
عمل جو وقت، گهٽ بهتر آهي. وڌ ۾ وڌ: 643ms، گھٽ ۾ گھٽ: 42ms. فوٽو ڪلڪ ڪري سگهجي ٿو.
سرجري لاء وقت، گهٽ بهتر آهي. وڌ ۾ وڌ: 14091 ns، گھٽ ۾ گھٽ: 151 ns. فوٽو ڪلڪ ڪري سگهجي ٿو.
اسيمبلي جي تياري واري مرحلي ۾، توهان هن متغير کي واضح طور تي سيٽ ڪري سگهو ٿا يا توهان لائبريري استعمال ڪري سگهو ٿا Uber جي ماڻهن کان.
مقرر ڪرڻ
• ڪنوينشن چيڪ ڪرڻ. توھان کان پھريائين توھان جي ارادي واري ماحول ۾ سروس اسيمبليون پهچائڻ شروع ڪريو، توھان کي ھيٺين کي جانچڻ جي ضرورت آھي:
- API جي آخري پوائنٽ.
- اسڪيما سان API جي آخري پوائنٽن جي جوابن جي تعميل.
- لاگ فارميٽ.
- خدمت لاءِ درخواستن لاءِ هيڊر سيٽ ڪرڻ (في الحال اهو ڪيو ويندو آهي netramesh)
- ايونٽ بس ڏانهن پيغام موڪلڻ وقت مالڪ ٽوڪن کي ترتيب ڏيڻ. اهو ضروري آهي ته بس ۾ خدمتن جي رابطي کي ٽريڪ ڪرڻ لاء. توهان ٻنهي idempotent ڊيٽا بس ڏانهن موڪلي سگهو ٿا، جيڪو خدمتن جي رابطي کي نه وڌائيندو آهي (جيڪو سٺو آهي)، ۽ ڪاروباري ڊيٽا جيڪو خدمتن جي رابطي کي مضبوط ڪري ٿو (جيڪو تمام خراب آهي!). ۽ ان نقطي تي جڏهن هي رابطو هڪ مسئلو بڻجي وڃي ٿو، اهو سمجهڻ ته ڪير لکي ٿو ۽ پڙهي ٿو بس صحيح طور تي الڳ الڳ خدمتن ۾ مدد ڪري ٿي.
Avito ۾ اڃا تائين تمام گهڻا ڪنوينشن نه آهن، پر انهن جو تلاء وڌايو آهي. وڌيڪ اهڙا معاهدا هڪ فارم ۾ موجود آهن ته ٽيم سمجهي ۽ سمجهي سگهي ٿي، مائڪرو سروسز جي وچ ۾ تسلسل برقرار رکڻ آسان آهي.
مصنوعي ٽيسٽ
• بند ٿيل لوپ جاچ. ان لاءِ اسان هاڻي اوپن سورس استعمال ڪري رهيا آهيون . پهريون، اهو خدمت تي حقيقي لوڊ رڪارڊ ڪري ٿو، پوء - صرف هڪ بند لوپ ۾ - اهو ان کي نقل ڪري ٿو.
• دٻاءَ جي جاچ. اسان ڪوشش ڪريون ٿا ته سڀني خدمتن کي بهتر ڪارڪردگي تي آڻينداسين. ۽ هر خدمت جا سڀئي ورجن لازمي طور تي لوڊ ٽيسٽ جي تابع هوندا - هن طريقي سان اسان سروس جي موجوده ڪارڪردگي ۽ ساڳئي خدمت جي پوئين ورزن سان فرق سمجهي سگهون ٿا. جيڪڏهن، خدمت جي تازه ڪاري کان پوء، ان جي ڪارڪردگي هڪ اڌ ڀيرا گهٽجي وئي، اهو ان جي مالڪن لاء هڪ واضح سگنل آهي: توهان کي ڪوڊ ۾ کڙو ڪرڻ ۽ صورتحال کي درست ڪرڻ جي ضرورت آهي.
اسان گڏ ڪيل ڊيٽا استعمال ڪريون ٿا، مثال طور، آٽو اسڪيلنگ کي صحيح طور تي لاڳو ڪرڻ لاءِ ۽، آخر ۾، عام طور تي سمجھو ته خدمت ڪيئن اسڪيلبل آهي.
لوڊ جاچ دوران، اسان چيڪ ڪريون ٿا ته ڇا وسيلن جو استعمال مقرر ڪيل حدن کي پورو ڪري ٿو. ۽ اسان بنيادي طور تي انتها تي ڌيان ڏيندا آهيون.
a) اسان مجموعي لوڊ کي ڏسون ٿا.
- تمام ننڍو - گهڻو ڪري ڪجھ به ڪم نه ڪندو آهي جيڪڏهن اوچتو لوڊ اوچتو ڪيترائي ڀيرا گهٽجي وڃي.
- تمام وڏو - اصلاح جي ضرورت آھي.
ب) اسان آر پي ايس جي مطابق ڪٽي آف کي ڏسو.
هتي اسان موجوده نسخي ۽ پوئين نسخ ۽ مجموعي مقدار جي وچ ۾ فرق کي ڏسو. مثال طور، جيڪڏهن هڪ خدمت 100 آر پي ايس پيدا ڪري ٿي، پوء اهو يا ته خراب لکيو ويو آهي، يا اهو ان جي خاصيت آهي، پر ڪنهن به صورت ۾، اهو هڪ سبب آهي ته خدمت کي تمام ويجهي ڏسڻ لاء.
جيڪڏهن، ان جي برعڪس، اتي تمام گھڻا RPS آھن، پوء شايد ڪجھھ قسم جو بگ آھي ۽ ڪجھ آخري پوائنٽون پيل لوڊ کي عمل ڪرڻ بند ڪري ڇڏيون آھن، ۽ ڪجھ ٻيو ھڪڙو صرف شروع ڪيو ويو آھي. return true;
ڪينري ٽيسٽ
مصنوعي ٽيسٽ پاس ڪرڻ کان پوءِ، اسان ننڍي تعداد ۾ استعمال ڪندڙن تي مائڪرو سروس ٽيسٽ ڪندا آهيون. اسان احتياط سان شروع ڪريون ٿا، خدمت جي گهربل سامعين جي هڪ ننڍڙي حصي سان - 0,1٪ کان گهٽ. هن اسٽيج تي، اهو تمام ضروري آهي ته صحيح ٽيڪنيڪل ۽ پراڊڪٽ ميٽرڪ مانيٽرنگ ۾ شامل ڪيا وڃن ته جيئن اهي جلد کان جلد سروس ۾ مسئلو ڏيکارين. ڪينري ٽيسٽ لاءِ گھٽ ۾ گھٽ وقت 5 منٽ آھي، مکيه ھڪڙو 2 ڪلاڪ آھي. پيچيده خدمتن لاءِ، اسان دستي طور وقت مقرر ڪريون ٿا.
اچو ته تجزيو ڪريون:
- ٻولي-مخصوص ميٽرڪس، خاص طور تي، php-fpm ڪارڪنن؛
- Sentry ۾ غلطيون؛
- جوابي حالتون؛
- جوابي وقت، صحيح ۽ سراسري؛
- دير سان؛
- استثنا، پروسيس ٿيل ۽ اڻڄاتل؛
- پيداوار جي ماپ.
ڇڪڻ جي جاچ
نچڻ جي جاچ کي پڻ سڏيو ويندو آهي "نچڻ" جاچ. ٽيڪنالاجي جو نالو Netflix ۾ متعارف ڪرايو ويو. ان جو خلاصو اهو آهي ته پهرين اسان هڪ مثال ڀريون ٿا حقيقي ٽرئفڪ سان ناڪامي جي نقطي تي ۽ اهڙي طرح ان جي حد مقرر ڪريو. ان کان پوء اسان هڪ ٻيو مثال شامل ڪيو ۽ هن جوڙو لوڊ ڪريو - ٻيهر وڌ ۾ وڌ؛ اسان انهن جي ڇت ۽ ڊيلٽا کي پهرين ”نچوڙي“ سان ڏسون ٿا. ۽ تنهنڪري اسان هڪ وقت ۾ هڪ مثال ڳنڍيندا آهيون ۽ تبديلين جي نموني کي ڳڻپ ڪندا آهيون.
ٽيسٽ ڊيٽا "نچوڙي" ذريعي پڻ هڪ عام ميٽرڪ ڊيٽابيس ۾ وهندي آهي، جتي اسان يا ته مصنوعي لوڊ نتيجن کي انهن سان گڏ ڪريون ٿا، يا انهن سان گڏ "مصنوعيات" کي به تبديل ڪريون ٿا.
پيداوار
• اسڪيلنگ. جڏهن اسان پيداوار لاءِ هڪ خدمت تيار ڪريون ٿا، اسان مانيٽر ڪريون ٿا ته اهو ڪيئن ٿو ماپي. اسان جي تجربي ۾، صرف سي پي يو اشارن جي نگراني غير موثر آهي. آر پي ايس بينچ مارڪنگ سان آٽو اسڪيلنگ ان جي خالص شڪل ۾ ڪم ڪري ٿي، پر صرف ڪجهه خدمتن لاءِ، جهڙوڪ آن لائن اسٽريمنگ. تنهن ڪري اسان پهريون ڀيرو ڏسو ايپليڪيشن-مخصوص پراڊڪٽ ميٽرڪ تي.
نتيجي طور، جڏهن اسڪيلنگ اسين تجزيو ڪريون ٿا:
- سي پي يو ۽ رام اشارا،
- قطار ۾ درخواستن جو تعداد،
- جوابي وقت،
- گڏ ڪيل تاريخي ڊيٽا جي بنياد تي اڳڪٿي.
جڏهن هڪ خدمت کي اسڪيل ڪرڻ، اهو پڻ ضروري آهي ته ان جي انحصار کي مانيٽر ڪيو وڃي ته جيئن اسان زنجير ۾ پهرين خدمت کي ماپ نه ڪريون، ۽ جيڪي ان تائين پهچن ٿا اهي لوڊ هيٺ ناڪام ٿين. خدمتن جي پوري پول لاءِ قابل قبول لوڊ قائم ڪرڻ لاءِ، اسان ڏسون ٿا تاريخي ڊيٽا ”ويجھي“ انحصار سروس جي (سي پي يو ۽ رام اشارن جي ميلاپ جي بنياد تي، ايپ جي مخصوص ميٽرڪس سان گڏ) ۽ انھن کي تاريخي ڊيٽا سان ڀيٽيو. شروعاتي سروس جي، ۽ ائين ئي سڄي ”انحصار واري زنجير“ ۾، مٿي کان هيٺ تائين.
خدمت
microservice کي آپريشن ۾ آڻڻ کان پوءِ، اسان ان سان ٽڪر لڳائي سگهون ٿا.
هتي عام حالتون آهن جن ۾ ٽاريون ٿينديون آهن.
- ممڪن طور تي خطرناڪ لڏپلاڻ جو پتو لڳايو ويو آهي.
- سيڪيورٽي اپڊيٽ جاري ڪئي وئي آهي.
- خدمت پاڻ هڪ ڊگهي وقت تائين اپڊيٽ نه ڪئي وئي آهي.
- خدمت تي لوڊ خاص طور تي گهٽجي ويو آهي يا ان جي ڪجهه پراڊڪٽ ميٽرڪ عام حد کان ٻاهر آهن.
- خدمت هاڻي نئين پليٽ فارم جي گهرجن کي پورو نٿو ڪري.
ڪجھ محرڪ آپريشن جي استحڪام لاءِ ذميوار آھن، ڪجھ - سسٽم جي سار سنڀال جي ڪم جي طور تي - مثال طور، ڪجھ سروس ڊگھي وقت تائين نه ڏني وئي آھي ۽ ان جي بنيادي تصوير سيڪيورٽي چيڪن کي پاس ڪرڻ بند ڪري ڇڏيو آھي.
ڊيش بورڊ
مختصر ۾، ڊيش بورڊ اسان جي سڄي PaaS جو ڪنٽرول پينل آهي.
- خدمت جي باري ۾ معلومات جو هڪ واحد نقطو، ان جي ٽيسٽ ڪوريج تي ڊيٽا سان، ان جي تصويرن جو تعداد، پيداوار جي نقلن جو تعداد، نسخو، وغيره.
- خدمتن ۽ ليبلن ذريعي ڊيٽا کي فلٽر ڪرڻ لاء هڪ اوزار (ڪاروباري يونٽن سان تعلق رکندڙ نشانن، پيداوار جي ڪارڪردگي، وغيره)
- ٽريڪنگ، لاگنگ، ۽ مانيٽرنگ لاء بنيادي ڍانچي جي اوزار سان انضمام لاء هڪ اوزار.
- خدمت دستاويزن جو هڪ واحد نقطو.
- خدمتن جي سڀني واقعن جي ھڪڙي نقطي نظر.
ڪل
PaaS کي متعارف ڪرائڻ کان اڳ، ھڪڙو نئون ڊولپر ڪيترن ئي ھفتا خرچ ڪري سگھي ٿو سڀني اوزارن کي سمجھڻ لاءِ ضروري آھي پيداوار ۾ مائڪرو سروس شروع ڪرڻ لاءِ: ڪبرنيٽس، ھيلم، اسان جي اندروني ٽيم سٽي خاصيتون، ڊيٽابيس ۽ ڪيچز سان ڪنيڪشن قائم ڪرڻ، غلطي برداشت ڪرڻ واري انداز ۾، وغيره. Quickstart پڙهڻ ۽ سروس پاڻ ٺاهڻ ۾ ڪجهه ڪلاڪ لڳن ٿا.
مون هن موضوع تي رپورٽ ڏني HighLoad++ 2018، توهان ان کي ڏسي سگهو ٿا и .
انهن لاءِ بونس ٽريڪ جيڪي آخر تائين پڙهندا آهن
اسان Avito تي ڊولپرز لاء اندروني ٽن ڏينهن جي تربيت منظم ڪري رهيا آهيون ، microservice فن تعمير ۾ هڪ ماهر. اسان هن پوسٽ جي پڙهندڙن مان هڪ کي ان ۾ حصو وٺڻ جو موقعو ڏيڻ چاهيندا. ٽريننگ پروگرام پوسٽ ڪيو ويو آهي.
تربيت ماسڪو ۾ 5 کان 7 آگسٽ تائين ٿيندي. اهي ڪم ڪندڙ ڏينهن آهن جيڪي مڪمل طور تي قبضو ڪيا ويندا. لنچ ۽ ٽريننگ اسان جي آفيس ۾ ٿيندي، ۽ چونڊيل حصو وٺندڙ پاڻ سفر ۽ رهائش لاءِ ادا ڪندو.
توهان شرڪت لاء درخواست ڪري سگهو ٿا . توهان کان - سوال جو جواب ڇو توهان کي تربيت ۾ شرڪت ڪرڻ جي ضرورت آهي ۽ معلومات ڪيئن توهان سان رابطو ڪرڻ تي. انگريزيءَ ۾ جواب ڏيو، ڇاڪاڻ ته ڪرس حصو وٺندڙ چونڊيندو جيڪو پاڻ ٽريننگ ۾ شرڪت ڪندو.
اسان ٽريننگ شرڪت ڪندڙ جي نالي جو اعلان ڪنداسين هن پوسٽ جي تازه ڪاري ۾ ۽ سوشل نيٽ ورڪن تي Avito ڊولپرز لاءِ (AvitoTech in , , ) جولاءِ 19 کان پوءِ نه.
جو ذريعو: www.habr.com