په مسکو کې د سپتمبر 19 لومړۍ موضوعي ناسته HUG (Highload++ User Group) چې مایکرو سرویسونو ته وقف شوې وه. دلته یو پریزنټیشن شتون درلود چې "د مایکرو خدماتو عملیات: د اندازې مسلې، حتی که تاسو کوبرنیټس ولرئ،" په کوم کې چې موږ د مایکرو سرویس معمارۍ سره په عملیاتي پروژو کې د فلانټ پراخه تجربه شریکه کړه. له هرڅه دمخه ، دا به د ټولو پراختیا کونکو لپاره ګټور وي څوک چې د دوی په اوسني یا راتلونکي پروژه کې د دې طریقې کارولو په اړه فکر کوي.
معرفي کول (50 دقیقې، د مقالې په پرتله خورا ډیر معلوماتي)، او همدارنګه د متن په بڼه کې د هغې اصلي استخراج.
نوټ: ویډیو او پریزنټیشن هم د دې پوسټ په پای کې شتون لري.
پېژندنه
معمولا یوه ښه کیسه پیل، اصلي پلاټ او حل لري. دا راپور ډیر د یو وړاندیز په څیر دی، او په دې کې یو غمجن دی. دا هم مهمه ده چې یادونه وکړو چې دا د مایکرو خدماتو په اړه د بهرنیانو لید وړاندې کوي. استحصال.
زه به د دې ګراف سره پیل وکړم، د کوم لیکوال (په 2015 کې) مارتین فولر:
دا ښیي چې څنګه، د یو واحد غوښتنلیک په صورت کې چې یو ټاکلي ارزښت ته رسیږي، د تولید کمښت پیل کیږي. کوچني خدمتونه په دې کې توپیر لري چې د دوی لومړني تولیدات ټیټ دي، مګر څنګه چې پیچلتیا زیاتیږي، د موثریت کمښت د دوی لپاره د پام وړ نه دی.
زه به د Kubernetes کارولو قضیې لپاره پدې ګراف کې اضافه کړم:
ولې د مایکرو خدماتو سره غوښتنلیک غوره دی؟ ځکه چې دا ډول جوړښت د معمارۍ لپاره جدي اړتیاوې وړاندې کوي، کوم چې په پایله کې د کبرنیټس وړتیاوې په بشپړه توګه پوښل شوي. له بلې خوا، د دې فعالیت ځینې به د مونولیت لپاره ګټور وي، په ځانګړې توګه ځکه چې نن ورځ عادي مونولیت په حقیقت کې یو مونولیت نه دی (تفصیل به وروسته په راپور کې وي).
لکه څنګه چې تاسو لیدلی شئ، وروستی ګراف (کله چې دواړه واحد او مایکرو خدمت غوښتنلیکونه د Kubernetes سره زیربنا کې وي) د اصلي څخه ډیر توپیر نلري. بیا به موږ د هغه غوښتنلیکونو په اړه وغږیږو چې د Kubernetes په کارولو سره پرمخ وړل کیږي.
ګټور او زیانمن مایکرو خدمتونه
او دلته اصلي نظر دی:
څه دي نورمال د مایکرو سرویس جوړښت؟ دا باید تاسو ته ریښتینې ګټې راوړي، ستاسو د کار موثریت زیات کړي. که موږ بیرته ګراف ته لاړ شو، دا دلته دی:
که تاسو هغې ته زنګ ووهئ ګټور، بیا به د ګراف په بل اړخ کې وي زیان رسونکی کوچني خدمتونه (په کار کې مداخله):
"اصلي مفکورې" ته راستنیدل: ایا زه په خپله تجربه باور لرم؟ د دې کال له پیل راهیسې ما لیدلی دی ۸۵ پروژې. ټول یې کوچني خدمتونه نه وو (شاوخوا له دریمې څخه تر نیمایي پورې ورته جوړښت درلود) ، مګر دا لاهم لوی شمیر دی. موږ (فلانټ شرکت) د بهرنی سرچینو په توګه اداره کوو چې په وړو شرکتونو (د 5 پراختیا کونکو سره) او په لویو (~ 500 پراختیا کونکو) کې رامینځته شوي پراخه غوښتنلیکونه وګورو. یوه اضافه ګټه دا ده چې موږ ګورو چې دا غوښتنلیکونه د کلونو په اوږدو کې ژوندي او وده کوي.
ولې کوچني خدمتونه؟
د مایکرو خدماتو د ګټو په اړه پوښتنې ته دلته شتون لري د دمخه ذکر شوي مارټین فولر څخه:
- د ماډلریت روښانه سرحدونه؛
- خپلواک استخدام؛
- د ټیکنالوژیو غوره کولو آزادي.
ما د سافټویر معمارانو او پراختیا کونکو سره ډیرې خبرې کړې او وپوښتل چې ولې دوی مایکرو خدماتو ته اړتیا لري. او ما د دوی د هیلو لیست جوړ کړ. دلته هغه څه دي چې پیښ شوي:
که موږ ځینې ټکي په "احساساتو" کې تشریح کړو، نو:
- د ماډلونو روښانه سرحدونه: دلته موږ یو ویرونکی مونولیت لرو، او اوس به هر څه په ښه توګه د Git په ذخیره کې تنظیم شي، په کوم کې چې هر څه "په الماریو کې" دي، ګرم او نرم نه مخلوط شوي؛
- د ګمارنې خپلواکي: موږ به وکولی شو په خپلواکه توګه خدمات وړاندې کړو ترڅو پرمختګ ګړندی شي (نوي ځانګړتیاوې په موازي ډول خپروي)؛
- د پراختیا خپلواکي: موږ کولی شو دا مایکرو خدمت یو ټیم / پراختیا کونکي ته ورکړو، او هغه بل ته، مننه چې موږ کولی شو چټک پرمختګ وکړو؛
- боډیر اعتبار: که چیرې جزوي تخریب رامینځته شي (له 20 څخه یو مایکرو خدمت راټیټیږي) ، نو یوازې یوه تڼۍ به کار ودروي ، او سیسټم به په بشپړ ډول خپل فعالیت ته دوام ورکړي.
عادي (ضررناک) د مایکرو سرویس جوړښت
د دې تشریح کولو لپاره چې ولې واقعیت هغه څه ندي چې موږ یې تمه کوو، زه به یې وړاندې کړم ډله ایز د ډیری مختلف پروژو تجربې پراساس د مایکرو سرویس معمارۍ عکس.
یو مثال به یو خلاص آنلاین پلورنځی وي چې د ایمیزون یا لږترلږه اوزون سره سیالي کوي. د دې مایکرو سرویس جوړښت داسې ښکاري:
د دلایلو د ترکیب لپاره، دا مایکرو خدمتونه په مختلفو پلیټ فارمونو کې لیکل شوي دي:
څرنګه چې هر مایکرو خدمت باید خپلواکي ولري، ډیری یې خپل ډیټابیس او کیچ ته اړتیا لري. وروستی جوړښت په لاندې ډول دی:
پایلې یې څه دي؟
فولر هم دا لري - د مایکرو خدماتو کارولو لپاره د "تادیې" په اړه:
او موږ به وګورو چې ایا زموږ هیلې پوره شوې.
د ماډلونو سرحدونه پاک کړئ ...
خو څومره مایکرو خدمتونه موږ واقعیا اصلاح کولو ته اړتیا لرو؟د بدلون راوستلو لپاره؟ ایا موږ کولی شو دا هم معلومه کړو چې څنګه هر څه د توزیع شوي ټرسر پرته کار کوي (په هرصورت ، کومه غوښتنه د نیمایي مایکرو خدماتو لخوا پروسس کیږي)؟
یوه بیلګه ده ""، او دلته دا د کثافاتو توزیع شوې ټوټه وه. د دې تصدیق کولو لپاره، دلته یو اټکل شوی مثال دی چې غوښتنې څنګه پرمخ ځي:
د استخدام خپلواکي...
په تخنیکي توګه، دا ترلاسه شوي: موږ کولی شو هر مایکرو خدمت په جلا توګه وړاندې کړو. مګر په عمل کې تاسو اړتیا لرئ په پام کې ونیسئ چې دا تل په لاره اچول کیږي ډیری کوچني خدمتونه، او موږ باید په پام کې ونیسو د دوی د راوتلو ترتیب. په ښه توګه، موږ عموما اړتیا لرو په جلا سرکټ کې ازموینه وکړو چې ایا موږ په سم ترتیب کې خوشې کول ترسره کوو.
د ټیکنالوژۍ غوره کولو آزادي ...
هغه ده. یوازې په یاد ولرئ چې ازادي اکثرا د بې قانونۍ سره پوله لري. دا دلته خورا مهم دي چې یوازې د دوی سره "لوبې" کولو لپاره ټیکنالوژي غوره نه کړئ.
د پرمختګ خپلواکي...
څنګه د ټول غوښتنلیک لپاره د ازموینې لوپ جوړ کړئ (د ډیری برخو سره)؟ مګر تاسو لاهم اړتیا لرئ چې دا تازه وساتئ. دا ټول د دې حقیقت لامل کیږي د ازموینې سرکیټونو ریښتیني شمیر، کوم چې موږ کولی شو په اصولو کې ولري ، لږ تر لږه معلومیږي.
دا ټول په ځایی توګه د ځای پرځای کولو په اړه څنګه؟... دا معلومه شوه چې ډیری وختونه پراختیا کونکي خپل کار په خپلواکه توګه ترسره کوي، مګر "په تصادفي"، ځکه چې هغه مجبور دی چې انتظار وکړي تر هغه چې سرکټ د ازموینې لپاره وړیا وي.
جلا اندازه کول ...
هو، مګر دا د DBMS کارول شوي ساحه کې محدود دی. په ورکړل شوي معمارۍ مثال کې ، کاسیندرا به ستونزې ونه لري ، مګر MySQL او PostgreSQL به.
Боډیر اعتبار ...
نه یوازې په حقیقت کې د یو مایکرو خدمت ناکامي اکثرا د ټول سیسټم سم فعالیت ماتوي ، بلکه یوه نوې ستونزه هم شتون لري: د هر مایکرو سرویس غلطی زغمل خورا ستونزمن کار دی. ځکه چې مایکرو خدمتونه مختلف ټیکنالوژي کاروي (memcache، Redis، او نور)، د هر یو لپاره تاسو اړتیا لرئ د هرڅه په اړه فکر وکړئ او پلي یې کړئ، کوم چې، البته، ممکن دی، مګر لوی سرچینو ته اړتیا لري.
د بار اندازه کولو وړتیا ...
دا واقعیا ښه ده.
د مایکرو خدماتو "روښانتیا" ...
موږ نه یوازې لوی لرو د شبکې سر (د DNS لپاره غوښتنې ضرب کیږي، او نور)، مګر د ډیری فرعي پوښتنو له امله چې موږ یې پیل کړی د معلوماتو نقل کول (د ذخیره کولو کیچونه)، کوم چې د پام وړ ذخیره کولو المل شو.
او دلته زموږ د هیلو پوره کولو پایله ده:
مګر دا ټول نه دي!
ځکه:
- ډیری احتمال موږ به د پیغام بس ته اړتیا ولرو.
- څنګه په سم وخت کې یو ثابت بیک اپ جوړ کړئ؟ یوازینی رښتیا اختیار دا دی چې د دې لپاره ترافیک بند کړئ. مګر دا څنګه په تولید کې ترسره کړئ؟
- که موږ د څو سیمو د ملاتړ په اړه وغږیږو، نو په هر یو کې د پایښت تنظیم کول خورا سخت کار دی.
- د مرکزي بدلونونو رامینځته کولو ستونزه رامینځته کیږي. د مثال په توګه، که موږ د پی ایچ پی نسخه تازه کولو ته اړتیا لرو، موږ به د هر ذخیره کولو لپاره ژمن یو (او لسګونه یې شتون لري).
- په عملیاتي پیچلتیا کې وده، لاسي، بې حده ده.
له دې ټولو سره څه وکړي؟
د یو واحد غوښتنلیک سره پیل کړئ. د فولر تجربه دا چې نږدې ټول بریالي مایکرو سرویس غوښتنلیکونه د یو واحد په توګه پیل شوي چې خورا لوی شو او بیا مات شو. په ورته وخت کې، نږدې ټول سیسټمونه د پیل څخه د مایکرو خدماتو په توګه جوړ شوي ژر یا وروسته جدي ستونزې تجربه کوي.
یو بل ارزښتناک فکر دا دی چې د یوې پروژې لپاره چې د مایکرو سرویس معمارۍ سره بریالۍ وي، تاسو باید ډیر ښه پوه شئ او د موضوع ساحه، او څنګه د مایکرو خدماتو رامینځته کول. او د موضوع ساحه زده کولو غوره لاره د مونولیت جوړول دي.
مګر که موږ دمخه پدې حالت کې یو؟
د هرې ستونزې د حل لپاره لومړی ګام دا دی چې ورسره موافقه وکړو او په دې پوه شو چې دا یوه ستونزه ده، موږ نور نه غواړو چې ځورول شي.
که چیرې ، د ډیر لوی شوي مونولیت په حالت کې (کله چې موږ د دې لپاره د اضافي سرچینو پیرود فرصت له لاسه ورکړو) ، موږ یې پرې کړو ، نو پدې حالت کې برعکس کیسه راپورته کیږي: کله چې ډیر مایکرو خدمات نور مرسته نه کوي ، مګر خنډ کوي - اضافي پرې کړئ او لوی کړئ!
د مثال په توګه، د ډله ایز عکس لپاره چې پورته بحث شوی ...
د خورا پوښتنې وړ مایکرو خدماتو څخه ځان خلاص کړئ:
ټول مایکرو خدمتونه یوځای کړئ چې د فرنټ اینډ نسل لپاره مسؤل دي:
... په یوه مایکرو سرویس کې، په یوه کې لیکل شوي (مډرن او نورمال، لکه څنګه چې تاسو پخپله فکر کوئ) ژبه/ چوکاټ:
دا به یو ORM (یو DBMS) ولري او لومړی یو څو غوښتنلیکونه:
... مګر په عمومي توګه تاسو کولی شئ هلته ډیر څه انتقال کړئ، لاندې پایلې ترلاسه کړئ:
سربیره پردې ، په کوبرنیټس کې موږ دا ټول په جلا جلا مثالونو کې چلوو ، پدې معنی چې موږ لاهم کولی شو بار اندازه کړو او په جلا توګه اندازه کړو.
لنډیز
لوی انځور ته وګورئ. ډیری وختونه ، دا ټولې ستونزې د مایکرو خدماتو سره رامینځته کیږي ځکه چې یو چا خپله دنده په غاړه اخیستې ، مګر غوښتل یې "د مایکرو خدماتو سره لوبې وکړي".
د "مایکرو خدماتو" کلمه کې د "مایکرو" برخه بې ځایه ده.. دوی یوازې "مائیکرو" دي ځکه چې دوی د لوی مونولیت څخه کوچني دي. مګر د دوی په اړه د یو څه کوچني په توګه فکر مه کوئ.
او د وروستي فکر لپاره ، راځئ چې اصلي چارټ ته راستون شو:
یو یادښت پرې لیکل شوی (پورته ښۍ) دا حقیقت ته رسوي د ټیم مهارتونه چې ستاسو پروژه رامینځته کوي تل لومړني وي - دوی به ستاسو په انتخاب کې د مایکرو سرویسونو او مونولیت ترمنځ کلیدي رول ولوبوي. که ټیم کافي مهارتونه ونلري ، مګر دا د مایکرو خدماتو رامینځته کول پیل کوي ، کیسه به خامخا وژونکي وي.
ویډیوګانې او سلایډونه
د وینا څخه ویډیو (~ 50 دقیقې؛ له بده مرغه، دا د لیدونکو ډیری احساسات نه بیانوي، کوم چې په لویه کچه د راپور مزاج ټاکي، مګر دا څنګه دی):
د راپور وړاندې کول:
PS
زموږ په بلاګ کې نور راپورونه:
- «» (دیمیتري سټولیاروف؛ د می 28، 2018 په RootConf کې);
- «» (دیمیتري سټولیاروف؛ د نومبر 7، 2017 په HighLoad++);
- «» (دیمیتري سټولیاروف؛ د جون 6، 2017 په RootConf کې);
- «» (دیمیتري سټولیاروف؛ د نومبر 8، 2016 په HighLoad++);
- «» (دیمیتري سټولیاروف؛ د می 31، 2016 په RootConf کې).
تاسو ممکن په لاندې خپرونو کې هم علاقه ولرئ:
- «»
- «»
- «".
سرچینه: www.habr.com