سلام، حبر! زه ستاسو پام ته وړاندې کوم د لیکوال د مقالې ژباړه .
په داسې وخت کې چې د معلوماتي ټکنالوجۍ نړۍ په تدریجي ډول د کوبرنیټس په څیر د مایکرو خدماتو او وسیلو په لور حرکت کوي، یوازې یوه ستونزه ورځ تر بلې د پام وړ کیږي. دا ستونزه - د microservice نسخې. بیا هم، د معلوماتي ټکنالوجۍ ټولنه پدې باور ده چې اوسنی وضعیت د پخوا په پرتله خورا ښه دی د ټیکنالوژیو پخوانی نسل. په هرصورت، د مایکرو خدماتو نسخه کول خورا پیچلې ستونزه ده. د دې یو ثبوت کیدی شي مقالې وي .
که تاسو لاهم د دې متن په لوستلو سره ستونزه نه پوهیږئ، اجازه راکړئ تشریح کړم. راځئ چې ووایو ستاسو محصول د 10 مایکرو خدماتو څخه جوړ دی. اوس راځئ فرض کړو چې 1 نوې نسخه د دې هر مایکرو خدماتو لپاره خپره شوې. یوازې 1 نسخه - زه امید لرم چې موږ ټول موافق یو چې دا یو خورا کوچنی او مهم حقیقت دی. اوس، په هرصورت، راځئ چې زموږ محصول ته یو بل نظر واخلو. د هرې برخې یوازې یوې نوې نسخې سره، موږ اوس 2^10 - یا 1024 اجازه لرو چې زموږ محصول څنګه جوړ شي.
که اوس هم کوم غلط فهم وي، اجازه راکړئ چې ریاضی مات کړم. نو موږ 10 مایکرو خدمتونه لرو، هر یو یو تازه ترلاسه کوي. دا دی، موږ د هر مایکرو خدمت لپاره 2 ممکنه نسخې ترلاسه کوو (یا زوړ یا نوی). اوس، د محصول هرې برخې لپاره، موږ کولی شو د دې دوو نسخو څخه کار واخلو. په ریاضي کې، دا یو شان دی لکه څنګه چې موږ د 10 عددونو بائنری شمیره درلوده. د مثال په توګه، راځئ چې ووایو چې 1 نوې نسخه ده، او 0 پخوانۍ نسخه ده - بیا یو احتمالي اجازه د 1001000000 په توګه پیژندل کیدی شي - چیرته چې لومړی او څلورم اجزا نوي شوي، او نور ټول ندي. د ریاضیاتو څخه موږ پوهیږو چې د 1 عددي بائنری شمیره کیدای شي 4^10 یا 2 ارزښت ولري. دا دی، موږ د هغه شمیر اندازه تایید کړې چې موږ ورسره معامله کوو.
راځئ چې خپل استدلال ته دوام ورکړو - څه به پیښ شي که چیرې موږ 100 مایکرو خدمتونه ولرو او هر یو یې 10 ممکنه نسخې ولري؟ ټول وضعیت خورا ناخوښه کیږي - موږ اوس 10^ 100 تخفیفونه لرو - کوم چې خورا لوی شمیر دی. په هرصورت، زه ترجیح ورکوم چې دا وضعیت په دې ډول لیبل کړم، ځکه چې اوس موږ نور د "کوبرنیټس" په څیر د کلمو تر شا پټ نه یو، بلکه د ستونزې سره مخ یو لکه څنګه چې دا دی.
زه ولې د دې ستونزې په اړه زړه نازړه یم؟ یو څه ځکه چې ، مخکې مو د NLP او AI نړۍ کې کار کړی و ، موږ شاوخوا 5-6 کاله دمخه د ګډې چاودنې په اړه ډیر بحث وکړ. یوازې د نسخو پرځای موږ انفرادي کلمې درلودې، او د محصولاتو پرځای موږ جملې او پراګرافونه درلودل. او که څه هم د NLP او AI ستونزې تر ډیره حده حل شوي ندي، دا باید ومنل شي چې په تیرو څو کلونو کې د پام وړ پرمختګ شوی. (زما په نظر، پرمختګ کیدی شيоدا به غوره وي که چیرې په صنعت کې خلک د ماشین زده کړې ته لږ پام وکړي او نورو تخنیکونو ته یو څه ډیر پام وکړي - مګر دا لا دمخه موضوع ده).
راځئ چې د DevOps او مایکرو خدماتو نړۍ ته راستون شو. موږ د یوې لویې ستونزې سره مخ یو، په کنستکامیرا کې د هاتین په څیر نقاب کول - ځکه چې هغه څه چې زه اکثرا اورم "یوازې کبرنیټس او هیلم واخلئ، هرڅه به سم شي!" مګر نه، هرڅه به سم نه وي که هرڅه همداسې پاتې شي. برسېره پردې، د دې ستونزې تحلیلي حل د هغې د پیچلتیا له امله د منلو وړ نه ښکاري. لکه څنګه چې په NLP کې، موږ باید لومړی د لټون ساحه محدودولو سره دې ستونزې ته ورسیږو - پدې حالت کې، د پخوانیو اجازو له منځه وړلو سره.
یو له هغه شیانو څخه چې ممکن مرسته وکړي هغه څه دي چې ما تیر کال لیکلي و . دا هم مهمه ده چې په یاد ولرئ چې یو ښه ډیزاین شوی CI/CD پروسه د توپیر کمولو کې ډیره مرسته کوي. په هرصورت، د CI/CD سره د چارو اوسنی حالت دومره ښه ندی چې د حساب ورکولو او تعقیب اجزاو لپاره اضافي وسیلو پرته د اجازې ستونزې حل کړي.
هغه څه چې موږ ورته اړتیا لرو د ادغام په مرحله کې د تجربې سیسټم دی ، چیرې چې موږ کولی شو د هرې برخې لپاره د خطر فکتور وټاکو ، او همدارنګه د مختلف اجزاو تازه کولو او د آپریټر مداخلې پرته ازموینې لپاره اتومات پروسه هم لرو - ترڅو وګورئ چې څه کار کوي او څه نه کوي.
د تجربو دا ډول سیسټم کیدای شي داسې ښکاري:
- پراختیا کونکي ازموینې لیکي (دا یو مهم مرحله ده - ځکه چې که نه نو موږ د ارزونې معیار نلرو - دا د ماشین زده کړې کې د ډیټا لیبل کولو په څیر دی).
- هره برخه (پروژه) خپل CI سیسټم ترلاسه کوي - دا پروسه اوس ښه وده شوې ، او د یوې برخې لپاره د CI سیسټم رامینځته کولو مسله په پراخه کچه حل شوې.
- د "سمارټ ادغام سیسټم" د مختلف CI سیسټمونو پایلې راټولوي او وروستي محصول ته اجزاوې پروژې راټولوي ، ازموینه پرمخ وړي او په پای کې د موجوده اجزاو او خطر فکتورونو پراساس د مطلوب محصول فعالیت ترلاسه کولو لپاره ترټولو لنډه لاره محاسبه کوي. که تازه کول ممکن نه وي، دا سیسټم پراختیا کونکو ته د موجوده برخو په اړه خبر ورکوي او کوم یو یې د خطا لامل کیږي. یوځل بیا، د ازموینې سیسټم دلته خورا مهم دی - ځکه چې د ادغام سیسټم ازموینې د ارزونې معیار په توګه کاروي.
- د CD سیسټم، چې بیا د سمارټ انټیګریشن سیسټم څخه ډاټا ترلاسه کوي او په مستقیم ډول اوسمهال ترسره کوي. دا مرحله دوره پای ته رسوي.
د لنډیز کولو لپاره، زما لپاره اوس یوه لویه ستونزه د داسې "سمارټ انسجام سیسټم" نشتوالی دی چې مختلف برخې به یو محصول سره ونښلوي او پدې توګه تاسو ته اجازه درکوي چې تعقیب کړئ چې څنګه محصول په ټولیز ډول یوځای کیږي. زه به په دې اړه د ټولنې له افکارو سره علاقه ولرم (سپویلر - زه اوس په یوه پروژه کار کوم ، کوم چې کولی شي دا ډول سمارټ ادغام سیسټم شي).
یو وروستی شی چې زه یې غواړم یادونه وکړم هغه دا دی چې زما لپاره یو مونولیت حتی د منځنۍ اندازې هرې پروژې لپاره د منلو وړ ندی. زما لپاره، د پلي کولو وخت ګړندۍ کولو هڅې او د پرمختګ کیفیت یو واحد ته بیرته راستنیدو سره د لوی شک لامل کیږي. لومړی، یو مونولیت د اجزاوو اداره کولو کې ورته ستونزه لري - د مختلفو کتابتونونو په منځ کې چې دا پکې شامل دي، په هرصورت، دا ټول د پام وړ ندي او په ابتدايي توګه د پراختیا کونکو لخوا مصرف شوي وخت کې څرګندیږي. د مونولیت ستونزې پایله په کوډ کې د بدلونونو رامینځته کولو مجازی ناممکنیت دی - او د پرمختګ خورا ورو سرعت.
کوچني خدمتونه وضعیت ښه کوي، مګر بیا د مایکرو سرویس جوړښت د ادغام په مرحله کې د ګډې چاودنې له ستونزې سره مخ کیږي. هو، په عموم کې، موږ ورته ستونزه د پراختیا مرحلې څخه د ادغام مرحلې ته لیږدولې ده. په هرصورت، زما په اند، د مایکرو خدماتو چلند لاهم د غوره پایلو لامل کیږي، او ټیمونه ګړندي پایلې ترلاسه کوي (شاید په عمده توګه د پراختیا واحد د اندازې کمولو له امله - یا د بست اندازه). په هرصورت، له مونولیت څخه مایکرو سرویسونو ته تلل لاهم پروسې ته کافي وده نه ده کړې - د مایکرو سرویس نسخو ترکیب چاودنه یوه لویه ستونزه ده ، او موږ د وضعیت ښه کولو لپاره خورا ډیر ظرفیت لرو ځکه چې موږ یې حل کوو.
سرچینه: www.habr.com