نوټ. ژباړه: د خدماتو میش یوه پدیده ده چې لاهم په روسیه کې مستحکم ژباړه نلري (د 2 کلونو څخه ډیر دمخه موږ د "خدماتو لپاره میش" اختیار وړاندیز کړی و ، او یو څه وروسته ځینې همکارانو په فعاله توګه د "خدمت چاڼ" ترکیب ته وده ورکړه). د دې ټیکنالوژۍ په اړه دوامداره خبرې د داسې وضعیت لامل شوي چې بازار موندنه او تخنیکي برخې خورا نږدې سره تړلي دي. د اصلي اصطالح د لیکوالانو څخه دا په زړه پوري مواد د انجینرانو او نورو لپاره روښانه کول دي.
له کامیک څخه
پېژندنه
که تاسو د سافټویر انجینر یاست چې د بیک انډ سیسټمونو ځای کې چیرې کار کوئ ، نو د "خدمت میش" اصطلاح شاید دمخه په تیرو څو کلونو کې ستاسو په ذهن کې په کلکه ځای په ځای شوې وي. د یو عجیب تصادف څخه مننه ، دا جمله صنعت ورځ تر بلې په خپل لاس کې اخلي ، او د دې سره تړلي هایپ او پروموشنل وړاندیزونه د واورې بال په څیر وده کوي چې ښکته الوت کوي او د سستیدو نښې نه ښیې.
د خدمت میش د بادل اصلي ایکوسیستم په تیاره ، متعصبو اوبو کې زیږیدلی. له بده مرغه، د دې معنی دا ده چې د هغې په شاوخوا کې ډیری شخړې د "کم کالوري خبرې" څخه د تخنیکي اصطلاح کارولو لپاره - په بشپړه توګه بې ځایه دي. مګر که تاسو ټول شور پرې کړئ ، نو تاسو به ومومئ چې د خدماتو میش خورا ریښتینی ، تعریف شوی او مهم فعالیت لري.
پدې پوسټ کې ، زه به هڅه وکړم یوازې دا وکړم: د خدماتو میش ته صادق ، ژور ، انجینر متمرکز لارښود چمتو کړئ. زه یوازې دې پوښتنې ته ځواب نه ورکوم: "دا څه شی دی؟", - خو هم "ولې؟"او همدارنګه "ولی اوس؟". په نهایت کې ، زه به هڅه وکړم چې تشریح کړم چې ولې (زما په نظر) دې ځانګړي ټیکنالوژۍ دومره لیونۍ حرکت رامینځته کړی ، کوم چې پخپله یوه په زړه پوري کیسه ده.
زه څوک یم؟
سلام و ټولو ته! زما نوم دی . زه یو له جوړونکو څخه یم - د لومړي خدمت میش پروژه او هغه پروژه چې د اصطلاح ظهور لپاره ملامت وي د خدمت میش لکه (بښنه غواړم هلکانو!). (د ژباړې یادونه.: له بلې خوا، د دې اصطلاح د ظهور په پیل کې، 2,5 کاله دمخه، موږ لا دمخه د ورته لیکوال لومړني مواد ژباړلي وو چې عنوان یې ".".) زه هم سر ورکوم یو پیل دی چې د غوره خدماتو میش شیان رامینځته کوي لکه لینکرډ او .
تاسو شاید اټکل وکړئ چې زه پدې مسله خورا متعصب او موضوعي نظر لرم. په هرصورت، زه به هڅه وکړم چې لږ تر لږه تعصب وساتم (د یوې برخې استثنا سره: "ولې د خدمت میش په اړه دومره خبرې دي؟", - په کوم کې چې زه به بیا هم خپل مخکیني نظرونه شریک کړم). زه به خپله هڅه هم وکړم چې دا لارښود د امکان تر حده هدف جوړ کړم. د ځانګړو مثالونو لپاره، زه به په ابتدايي توګه د لینکرډ تجربې باندې تکیه وکړم، پداسې حال کې چې توپیرونه (که کوم وي) په ګوته کړم چې زه د نورو خدماتو میش ډولونو پلي کولو کې پوهیږم.
ښه، وخت دی چې د ښیګڼو ته لاړ شئ.
د خدمت میش څه شی دی؟
د ټولو هایپ سره سره، د خدماتو میش جوړښت خورا ساده دی. دا یوازې د کاروونکو ځای پراکسيونو یوه ډله ده چې د خدماتو "شاوخوا" موقعیت لري (موږ به د دې په اړه لږ څه وغږیږو چې "راتلونکی" وروسته دی) ، او د کنټرول پروسې سیټ. پراکسي په ګډه ویل کیږي د معلوماتو الوتکه، او د کنټرول پروسې بلل کیږي د کنټرول الوتکه. د معلوماتو الوتکه د خدماتو تر مینځ تلیفونونه منع کوي او د دوی سره "ټول ډول ډول شیان" کوي؛ د کنټرول الوتکه، په دې اساس، د پراکسي چلند همغږي کوي او ستاسو لپاره لاسرسی چمتو کوي، د بیلګې په توګه. آپریټر، API ته، شبکې ته اجازه ورکوي چې سمبال شي او په ټولیزه توګه اندازه شي.
دا څه ډول پراکسي ده؟ دا یو پرت 7 پوه TCP پراکسي ده (د مثال په توګه د OSI ماډل 7 پرت "په پام کې نیول") لکه HAProxy او NGINX. تاسو کولی شئ د خپلې خوښې پراکسي غوره کړئ؛ لینکرډ د زنګ پراکسي کاروي، په ساده ډول نومول شوی . موږ دا په ځانګړي ډول د خدمت میش لپاره یوځای کوو. نور میشونه نور پراکسي غوره کوي (مصنف یو عام انتخاب دی). په هرصورت، د پراکسي غوره کول یوازې د پلي کولو مسله ده.
دا پراکسي سرورونه څه کوي؟ په ښکاره ډول، دوی خدماتو ته او له هغه څخه پراکسي زنګونه کوي (په کلکه ووایو، دوی د پراکسي او ریورس پراکسي په توګه عمل کوي، د راتلونکو او وتلو دواړو تلیفونونو اداره کوي). او دوی د فیچر سیټ پلي کوي چې په تلیفونونو تمرکز کوي د خدمتونه د خدماتو تر مینځ ترافیک باندې دا تمرکز هغه څه دي چې د خدماتو میش پراکسي سره توپیر کوي ، ووایه ، د API ګیټ ویز یا انګریس پراکسي (وروستي تمرکز د بهرنۍ نړۍ څخه کلستر ته راځي تلیفونونو باندې). (نوټ. ژباړه: د Kubernetes لپاره د موجوده انګریس کنټرولرونو پرتله کولو لپاره، چې ډیری یې مخکې ذکر شوي استازي کاروي، وګورئ .)
نو، موږ د معلوماتو الوتکه ترتیب کړې. د کنټرول الوتکه ساده ده: دا د اجزاو ټولګه ده چې ټول میکانیکونه چمتو کوي چې د ډیټا الوتکه په همغږي ډول کار کولو ته اړتیا لري ، پشمول د خدماتو کشف ، د TLS سندونو صادرول ، میټریک راټولول او داسې نور. چلند په بدل کې، د کنټرول الوتکه یو API چمتو کوي چې تاسو ته اجازه درکوي د ډیټا الوتکې چلند بدل او څارنه وکړئ.
لاندې په لینکرډ کې د کنټرول الوتکې او ډیټا الوتکې ډیاګرام دی. لکه څنګه چې تاسو لیدلی شئ، د کنټرول الوتکې ډیری مختلف برخې شاملې دي، په شمول د پرومیټیوس مثال چې د پراکسي سرورونو څخه میټریکونه راټولوي، او همدارنګه نورې برخې لکه destination (د خدماتو کشف) identity (د سند واک، CA) او public-api (د ویب او CLI لپاره پای ټکي). په مقابل کې، د ډاټا الوتکه د غوښتنلیک مثال ته نږدې یو ساده لینکرډ پراکسي دی. دا یوازې یو منطقي انځور دی؛ په ریښتینې نړۍ کې ځای په ځای کولو کې، تاسو ممکن د هر کنټرول الوتکې برخې درې نقلونه او د ډیټا په الوتکه کې سلګونه یا زرګونه پراکسي ولرئ.
(په دې ډیاګرام کې نیلي مستطیلونه د Kubernetes پوډونو سرحدونه سمبول کوي. تاسو لیدلی شئ چې د لینکرډ پراکسي سره کانټینرونه د غوښتنلیک کانټینرونو په ورته پوډ کې دي. دا سکیم په نوم پیژندل کیږي. د سایډ کار کانټینر.)
د خدماتو میش جوړښت ډیری مهمې اغیزې لري. لومړی، له هغه ځایه چې د پراکسي دنده د خدماتو تر مینځ د زنګ وهلو مخه نیسي، د خدماتو میش یوازې هغه وخت معنی لري که ستاسو غوښتنلیک د خدماتو د یوې ټاکلې سیټ لپاره رامینځته شوی وي. میش کولای شي د monoliths سره وکاروئ، مګر دا په ښکاره ډول د یو واحد پراکسي لپاره بې ځایه دی، او د دې فعالیت احتمال نلري چې په تقاضا کې وي.
بله مهمه پایله دا ده چې د خدماتو میش ته اړتیا ده لوی د پراکسي شمیر. په حقیقت کې، لینکرډ د هر خدمت هرې بیلګې ته یو لینکرډ پراکسي ضمیمه کوي (نور تطبیقونه په هر نوډ/میزبان/مجازی ماشین کې پراکسي اضافه کوي. دا په هرصورت ډیر دی). په ځان کې د پراکسي دا ډول فعال کارول یو شمیر اضافي پیچلتیاوې لري:
- د معلوماتو په الوتکه کې پراکسي باید وي چټک، ځکه چې د هر زنګ لپاره پراکسي ته څو زنګونه شتون لري: یو د پیرودونکي اړخ کې ، یو د سرور اړخ کې.
- هم باید پراکسي وي کوچنی и لږ وزن. هر یو به د حافظې او CPU سرچینې مصرف کړي ، او دا مصرف به د غوښتنلیک سره سم وده وکړي.
- تاسو به یو میکانیزم ته اړتیا ولرئ ترڅو د پراکسي لوی شمیر ځای په ځای او تازه کړي. دا په لاسي ډول کول یو اختیار ندی.
په عموم کې، د خدماتو میش داسې ښکاري (لږترلږه د مرغۍ د سترګو څخه): تاسو د کاروونکي ځای پراکسي یوه ډله ځای په ځای کړئ چې د داخلي، بین خدمت ټرافیک سره "یو څه" کوي، او د څارنې او اداره کولو لپاره د کنټرول الوتکه کاروي.
اوس د دې وخت دی چې پوښتنه وکړئ "ولې؟"
د خدمت میش د څه لپاره دی؟
هغه څوک چې لومړی د خدمت میش مفکورې سره مخ شوي د یو څه ویره احساس کولو لپاره بخښل کیدی شي. د خدمت میش ډیزاین پدې معنی دی چې دا به نه یوازې په غوښتنلیک کې ځنډ ډیر کړي ، بلکه به هم مصرف سرچینې او اضافه به کړي په زیربنا کې د نوي میکانیزمونو یوه ډله. لومړی تاسو د خدماتو میش ترتیب کړئ، او بیا ناڅاپه تاسو خپل ځان د سلګونو (که زرګونه نه) پراکسي خدمت کولو ته اړتیا لرئ. پوښتنه دا ده چې څوک به په خپله خوښه دا کار وکړي؟
د دې پوښتنې ځواب دوه برخې لري. لومړی، د راکړې ورکړې لګښتونه چې د دې پراکسيونو له مینځه وړلو پورې تړاو لري د پام وړ کمول کیدی شي د ځینو بدلونونو څخه مننه چې په ایکوسیستم کې پیښیږي (په دې اړه نور وروسته).
دوهم، د دې په څیر وسیله په حقیقت کې سیسټم ته د اضافي منطق معرفي کولو لپاره یوه ښه لار ده. نه یوازې دا چې د خدماتو میش کولی شي ډیری نوي فعالیت اضافه کړي ، بلکه دا هم د اکوسیستم سره د مداخلې پرته ترسره کیدی شي. په حقیقت کې، د ټول خدمت میش ماډل د دې اساس پر بنسټ والړ دی: په څو خدماتو سیسټم کې، مهمه نده چې څه شی وکړه انفرادي خدمات، ترافیک د دوی ترمنځ د فعالیت اضافه کولو لپاره غوره نقطه ده.
د مثال په توګه، په لینکرډ کې (لکه په ډیری میشونو کې) فعالیت په ابتدايي توګه د HTTP کالونو باندې تمرکز کوي، په شمول د HTTP/2 او gRPC*. فعالیت خورا بډایه دی - دا په دریو ټولګیو ویشل کیدی شي:
- پورې اړوند ځانګړتیاوې اعتبار. تکراري غوښتنې، مهال ویش، د کانري طریقه (د ټرافیک ویشل / بیا راستنیدل)، او نور.
- پورې اړوند ځانګړتیاوې څارنه. د هر خدمت یا انفرادي لارښوونو لپاره د بریالیتوب نرخونو، ځنډونو او د غوښتنې حجمونو راټولول؛ د خدمتونو د توپولوژیکي نقشو جوړول، او داسې نور.
- پورې اړوند ځانګړتیاوې امنیت. دوه اړخیز TLS، د لاسرسي کنټرول، او نور.
* د لینکرډ له نظره، gRPC په عملي توګه د HTTP/2 څخه توپیر نلري: دا یوازې په تادیه کې پروټوبف کاروي. د پراختیا کونکي له نظره، دوه شیان، البته، مختلف دي.
ډیری دا میکانیزمونه د غوښتنې په کچه کار کوي (له همدې امله "L7 پراکسي"). د مثال په توګه، که د Foo خدمت د بار خدمت ته HTTP زنګ ووهي، د Foo اړخ ته Linkerd-proxy کولی شي د لید شوي ځنډ پراساس د فو څخه بار مثالونو ته د هوښیار بار توازن او روټ زنګونه ترسره کړي؛ دا د اړتیا په صورت کې غوښتنه تکرار کولی شي (او که دا بې کفایته وي)؛ دا کولی شي د ځواب کوډ او وخت پای ته ورسیږي، او داسې نور. په ورته ډول، د بار لوري ته لینکرډ پراکسي کولی شي غوښتنه رد کړي که چیرې اجازه نه وي یا د غوښتنې حد څخه تیریږي؛ کیدای شي د هغې په برخه کې ځنډ ثبت کړي، او داسې نور.
پراکسي کولی شي د ارتباط په کچه هم "یو څه وکړي". د مثال په توګه، د Foo اړخ کې Linkerd-proxy کولی شي د TLS پیوستون پیل کړي، او د بار اړخ کې Linkerd-proxy کولی شي دا ختم کړي، او دواړه خواوې کولی شي د یو بل TLS سندونه تصدیق کړي*. دا نه یوازې د خدماتو تر مینځ کوډ کول چمتو کوي ، بلکه د خدماتو پیژندلو لپاره د کریپټوګرافیک خوندي لاره هم چمتو کوي: فو او بار کولی شي "ثابت کړي" چې دوی هغه څوک دي چې دوی یې وايي.
* "د ملګري متقابل" معنی دا ده چې د پیرودونکي سند هم تایید شوی (متقابل TLS). په "کلاسیک" TLS کې، د بیلګې په توګه د براوزر او سرور ترمنځ، یوازې د یو اړخ (سرور) سند معمولا تایید کیږي.
که دوی د غوښتنې یا پیوستون په کچه کار کوي، دا مهمه ده چې ټینګار وشي چې د خدماتو میش ټولې دندې عملیاتي کرکټر لینکرډ نشي کولی د تادیې سیمانټیک بدل کړي - د مثال په توګه ، د JSON برخې ته ساحې اضافه کول یا پروټوبف کې بدلونونه. موږ به وروسته د دې مهم خصوصیت په اړه وغږیږو کله چې موږ د ESB او Middleware په اړه وغږیږو.
دا د ځانګړتیاوو مجموعه ده چې د خدمت میش وړاندیز کوي. پوښتنه راپورته کیږي: ولې یې په مستقیم ډول په غوښتنلیک کې نه پلي کوئ؟ او ولې په ټوله کې د پراکسي سره خپه کیږي؟
ولې د خدمت میش یو ښه نظر دی
پداسې حال کې چې د خدماتو میش وړتیاوې په زړه پوري دي، د دې اصلي ارزښت په حقیقت کې د هغې په ځانګړتیاو کې ندي. په پای کې موږ کولای شی دوی په مستقیم ډول په غوښتنلیک کې پلي کړئ (موږ به وروسته وګورو چې دا د خدماتو میش اصل و). هڅه وکړئ او په یوه جمله کې یې خلاص کړئ، د خدمت میش ارزښت دا دی: دا د عصري سرور سافټویر چلولو لپاره مهمې ځانګړتیاوې وړاندې کوي چې په ټول سټیک کې په منظم ډول او د غوښتنلیک کوډ څخه خپلواک وي.
راځئ چې دا وړاندیز تحلیل کړو.
«د عصري سرور سافټویر چلولو لپاره مهمې ځانګړتیاوې" که تاسو د لیږدونکي سرور غوښتنلیک رامینځته کوئ چې د عامه انټرنیټ سره وصل وي ، د بهرنۍ نړۍ غوښتنې ومني او په لنډ وخت کې ورته ځواب ووایی - د مثال په توګه ، ویب غوښتنلیک ، د API سرور ، او ډیری نور عصري غوښتنلیکونه. - او که تاسو دا د خدماتو د یوې سیټ په توګه پلي کوئ چې په همغږي توګه یو له بل سره متقابل عمل کوي ، او که تاسو په دوامداره توګه دا سافټویر اپ گریڈ کوئ ، نوي ب featuresې اضافه کوئ ، او که تاسو د ترمیم پروسې په جریان کې د دې سیسټم په کاري ترتیب کې ساتلو ته اړ یاست - پدې کې قضیه، مبارکۍ، تاسو د عصري سرور سافټویر رامینځته کوئ. او پورته لست شوي دا ټولې عالي ځانګړتیاوې واقعیا ستاسو لپاره مهمې دي. غوښتنلیک باید د باور وړ، خوندي وي، او تاسو باید د دې وړتیا ولرئ چې وګورئ چې دا څه کوي. دا دقیقا هغه پوښتنې دي چې د خدماتو میش حل کولو کې مرسته کوي.
(ښه، پخوانۍ پراګراف لاهم زما باور لري چې دا طریقه د سرور سافټویر رامینځته کولو عصري لاره ده. نور غوره کوي چې مونولیتس رامینځته کړي ، "عملي مایکرو خدماتو" او نور هغه شیان چې پورته تعریف شوي تعریف لاندې نه راځي. دا خلک شاید خپل ولري. نظر زما څخه توپیر لري. په بدل کې، زه فکر کوم چې دوی "غلط" دي - که څه هم په هر حالت کې د خدماتو میش د دوی لپاره ډیر ګټور نه دی).
«د ټول سټیک لپاره یونیفورم" د خدمت میش لخوا چمتو شوي فعالیت یوازې د ماموریت مهم ندي. دوی په غوښتنلیک کې په ټولو خدماتو کې پلي کیږي، پرته له دې چې دوی په کومه ژبه لیکل شوي، کوم چوکاټ چې دوی کاروي، چا یې لیکلي، څنګه یې ځای پرځای شوي، او د دوی د پراختیا او کارولو کوم بل فرعي ټکي.
«د غوښتنلیک کوډ څخه خپلواک" په نهایت کې ، د خدماتو میش نه یوازې په ټول سټیک کې دوامداره فعالیت چمتو کوي ، دا په داسې طریقه ترسره کوي چې غوښتنلیک ایډیټ کولو ته اړتیا نلري. د خدمت میش فعالیت اساسی اساس ، پشمول د تشکیلاتو ، تازه کولو ، عملیاتو ، ساتنې او داسې نورو لپاره دندې ، په بشپړ ډول د پلیټ فارم په کچه ژوند کوي او د غوښتنلیک څخه خپلواک دی. غوښتنلیک کولی شي د خدماتو میش اغیزه کولو پرته بدل شي. په بدل کې، د خدماتو میش کولی شي د غوښتنلیک څخه د ګډون پرته بدل شي.
په لنډه توګه، د خدماتو میش نه یوازې حیاتي فعالیت وړاندې کوي، بلکې دا په نړیوال، یونیفورم، او غوښتنلیک-خپلواک ډول هم کوي. او په دې توګه، که څه هم د خدماتو میش فعالیت د خدماتو کوډ کې پلي کیدی شي (د مثال په توګه، د کتابتون په توګه چې په هر خدمت کې شامل وي)، دا طریقه به یووالی او خپلواکي چمتو نکړي چې د خدمت میش په قضیه کې خورا ارزښتناکه وي.
او ټول هغه څه چې تاسو یې کولو ته اړتیا لرئ د پراکسي یوه ډله اضافه کړئ! زه ژمنه کوم چې موږ به ډیر ژر د دې پراکسي اضافه کولو پورې اړوند عملیاتي لګښتونه وګورو. مګر لومړی راځئ چې ودروو او د خپلواکۍ دې مفکورې ته له بیلابیلو لیدونو څخه وګورو. خلک.
د خدمت میش څوک مرسته کوي؟
څومره چې دا ناشونی وي، د دې لپاره چې ټیکنالوژي د ایکوسیستم مهمه برخه شي، دا باید د خلکو لخوا ومنل شي. نو څوک د خدمت میش سره علاقه لري؟ څوک یې له استعمال څخه ګټه اخلي؟
که تاسو د عصري سرور سافټویر رامینځته کوئ، تاسو کولی شئ د یوې ډلې په توګه ستاسو د ټیم په اړه فکر وکړئ د خدمت خاوندانڅوک چې په ګډه د سوداګرۍ منطق وده او پلي کوي، او د پلیټ فارم مالکین، د داخلي پلیټ فارم رامینځته کول په کوم کې چې دا خدمات فعالیت کوي. په کوچنیو سازمانونو کې، دا ممکن ورته خلک وي، مګر لکه څنګه چې شرکت وده کوي، دا رولونه نور هم څرګندیږي او حتی په فرعي رولونو ویشل کیږي ... (دلته د ډیوپس د بدلیدونکي طبیعت په اړه ډیر څه ویل کیږي، د مایکرو خدماتو تنظیمي اغیزې، او داسې نور) n. مګر د اوس لپاره راځئ چې دا توضیحات په پام کې ونیسو).
له دې نظره، د خدماتو میش روښانه ګټه اخیستونکي د پلیټ فارم مالکین دي. په هرصورت، په نهایت کې د پلیټ فارم ټیم هدف دا دی چې یو داخلي پلیټ فارم رامینځته کړي په کوم کې چې د خدماتو مالکین کولی شي د سوداګرۍ منطق پلي کړي او دا په داسې طریقه ترسره کړي چې ډاډ ترلاسه کړي چې دوی د دې عملیاتو له پیچلي توضیحاتو څخه د امکان تر حده خپلواک دي. نه یوازې د خدماتو میش د دې موخې ترلاسه کولو لپاره مهم وړتیاوې وړاندې کوي، دا په داسې طریقه ترسره کوي چې په پایله کې د خدماتو مالکینو باندې تکیه نه کوي.
د خدماتو مالکین هم ګټه پورته کوي، که څه هم په غیر مستقیم ډول. د خدماتو مالک هدف دا دی چې د سوداګرۍ پروسې منطق پلي کولو کې د امکان تر حده ګټور وي ، او څومره چې هغه د عملیاتي مسلو په اړه لږ اندیښنه ولري ، ښه. د دې پرځای چې پلي کولو سره معامله وکړئ ، ووایئ ، د پالیسیو یا TLS بیا هڅه وکړئ ، دوی کولی شي یوازې د سوداګرۍ اهدافو باندې تمرکز وکړي او امید لري چې پلیټ فارم پاتې نورو ته پاملرنه وکړي. دا د دوی لپاره لویه ګټه ده.
د پلیټ فارمونو او خدماتو مالکینو تر مینځ د دې ډول ویش تنظیمي ارزښت ډیر نه اټکل کیدی شي. زه فکر کوم چې هغه مرسته کوي بنسټیز د خدمت میش ارزښت کې ونډه.
موږ دا درس زده کړ کله چې د لینکرډ لومړني فین موږ ته وویل چې ولې دوی د خدماتو میش غوره کړی: ځکه چې دا دوی ته اجازه ورکړه چې "د خبرو کولو هټۍ لږترلږه وساتي." دلته ځینې توضیحات دي: د یو لوی شرکت څخه هلکانو خپل پلیټ فارم کوبرنیټس ته لیږدول. څرنګه چې غوښتنلیک حساس معلومات اداره کړي، دوی غوښتل چې په کلسترونو کې ټول مخابرات کوډ کړي. په هرصورت، وضعیت د سلګونو خدماتو او سلګونو پرمختیایي ټیمونو شتون له امله پیچلی و. د هرچا سره تماس نیولو او هغوی ته قانع کول چې په خپلو پالنونو کې د TLS مالتړ شامل کړي دوی هیڅ خوښ نه کړي. د لینکرډ نصبولو وروسته، دوی لیږدول مسؤلیت له پراختیا کونکو څخه (له هغه نظره چې دا غیر ضروري ستونزه وه) پلیټفارمرانو ته ، د کوم لپاره چې دا د لوړې کچې لومړیتوب و. په بل عبارت، لینکرډ د دوی لپاره دومره تخنیکي ستونزه حل کړه چې د سازماني په توګه.
په لنډه توګه، د خدماتو میش یو ډیر حل دی، نه تخنیکي، مګر ټولنیز - تخنیکي ستونزې. (له تاسو مننه د دې اصطلاح معرفي کولو لپاره.)
ایا د خدمت میش به زما ټولې ستونزې حل کړي؟
هو. زما مطلب دی، نه!
که تاسو د پورته ذکر شوي ځانګړتیاوو درې ټولګیو ته وګورئ - اعتبار، امنیت، او مشاهده - دا روښانه کیږي چې د خدماتو میش د دې ستونزو څخه هیڅ یو بشپړ حل ندی. پداسې حال کې چې لینکرډ کولی شي غوښتنې بیا خپروي (که دا پوهیږي چې دوی بې کفایته دي)، دا نشي کولی د دې په اړه پریکړې وکړي چې کارونکي ته څه بیرته راستانه شي که چیرې خدمت د تل لپاره ناکام شوی وي - دا پریکړې باید د غوښتنلیک لخوا ترسره شي. Linkerd کولی شي د بریالي غوښتنو احصایې وساتي، مګر دا د دې توان نلري چې خدمت وګوري او خپل داخلي میترونه چمتو کړي - غوښتنلیک باید داسې وسایل ولري. او که څه هم لینکرډ د mTLS تنظیم کولو توان لري، بشپړ امنیتي حلونه ډیر څه ته اړتیا لري.
د خدماتو میش لخوا وړاندیز شوي پدې برخو کې د ځانګړتیاو یوه فرعي برخه پورې اړه لري د پلیټ فارم ځانګړتیاوې. له دې څخه زما مطلب دا دی چې:
- د سوداګرۍ منطق خپلواک. هغه لاره چې د فو او بار تر مینځ د کال هسټوګرامونه جوړیږي په بشپړ ډول خپلواکه ده ولې فو بار ته زنګ وواهه.
- په سمه توګه پلي کول ستونزمن دي. په لینکرډ کې، بیاکتنې د هر ډول فینسي شیانو سره پیرامیټر شوي دي لکه د بیاکتنې بودیجې (د بودیجې بیا هڅه وکړئ)، ځکه چې د داسې شیانو پلي کولو لپاره یو ناپېژانده ، په سر کې چلند به یقینا د "غوښتنو د واورې توپان" رامینځته کیدو لامل شي. (د طوفان بیا هڅه وکړئ) او نورې ستونزې چې د ویشل شوي سیسټم ځانګړتیاوې لري.
- خورا اغیزمنه ده کله چې په یو شان تطبیق شي. د TLS میکانیزم یوازې معنی لري که چیرې دا په هر ځای کې پلي شي.
څرنګه چې دا دندې د پراکسي په کچه پلي کیږي (او د غوښتنلیک په کچه نه)، د خدماتو میش دوی ته چمتو کوي پلیټ فارمنه غوښتنلیکونه. په دې توګه، دا مهمه نده چې خدمتونه په کومه ژبه کې لیکل شوي، کوم چوکاټ دوی کاروي، چا یې لیکلي او ولې. پراکسي د دې ټولو توضیحاتو څخه بهر فعالیت کوي ، او د دې فعالیت بنسټیز اساس ، پشمول د ترتیب کولو ، تازه کولو ، عملیاتو ، ساتنې او داسې نورو کارونو په شمول ، یوازې د پلیټ فارم په کچه کې دی.
د خدمت میش وړتیاو مثالونه
د لنډیز لپاره، د خدماتو میش د اعتبار، مشاهدې، یا امنیت لپاره بشپړ حل ندی. د دې ساحو ساحه د خدماتو مالکینو، Ops/SRE ټیمونو او نورو شرکتونو شرکتونو ګډون ته اړتیا لري. د خدماتو میش یوازې د دې هرې ساحې لپاره د پلیټ فارم کچې "سلائس" چمتو کوي.
ولې اوس مهال د خدماتو میش مشهور شوی؟
تر دې دمه تاسو شاید حیران یاست: ښه ، که د خدماتو میش دومره ښه وي ، نو ولې موږ لس کاله دمخه په سټیک کې د ملیونونو پراکسي ګمارل پیل نه کړل؟
د دې پوښتنې لپاره یو متفاوت ځواب شتون لري: لس کاله دمخه هرڅوک مونولیتس جوړ کړ، او هیڅوک د خدمت میش ته اړتیا نه درلوده. دا ریښتیا ده، مګر زما په اند دا ځواب ټکی له لاسه ورکوي. حتی لس کاله دمخه، د لوی پیمانه سیسټمونو جوړولو لپاره د ژمنې لارې په توګه د مایکرو خدماتو مفهوم په پراخه کچه بحث شوی او په شرکتونو لکه ټویټر، فیسبوک، ګوګل او Netflix کې پلي شوی. عمومي نظر - لږترلږه د صنعت په برخو کې چې زه ورسره اړیکه لرم - دا وه چې مایکرو خدمتونه د لوی سیسټمونو جوړولو لپاره "سمه لاره" وه، حتی که دا خورا سخت وي.
البته، که څه هم لس کاله دمخه داسې شرکتونه وو چې مایکرو خدمتونه یې چلول، دوی په هر ځای کې چې دوی کولی شي د خدماتو میش جوړ کړي پراکسي نه و. په هرصورت، که تاسو نږدې وګورئ، دوی ورته ورته کار کړی: ډیری دې شرکتونو د شبکې اړیکو لپاره د ځانګړي داخلي کتابتون کارولو ته اړتیا درلوده (کله ناکله د موټ پیرودونکي کتابتون په نوم یادیږي، د غوړ پیرودونکي کتابتون).
Netflix Hysterix درلود، ګوګل Stubby درلود، ټویټر د Finagle کتابتون درلود. Finagle، د بیلګې په توګه، په ټویټر کې د هر نوي خدمت لپاره لازمي و. دا د اتصالاتو پیرودونکي او سرور دواړه اړخونه اداره کوي ، د تکرار غوښتنو لپاره اجازه ورکړل شوې ، د غوښتنې لارې ملاتړ شوي ، د بار توازن او اندازه کول. دا په ټول ټویټر سټیک کې د اعتبار او مشاهدې یو دوامداره پرت چمتو کړی ، پرته لدې چې خدمت څه کوي. البته، دا یوازې د JVM ژبو لپاره کار کاوه او د برنامه کولو ماډل پراساس و چې باید د ټول غوښتنلیک لپاره وکارول شي. په هرصورت، د دې فعالیت تقریبا د خدمت میش سره ورته و. (په حقیقت کې، د لینکرډ لومړۍ نسخه په ساده ډول د پراکسي بڼه کې فنګل پوښل شوې وه.)
په دې توګه، لس کاله وړاندې نه یوازې مایکرو خدمتونه، بلکې ځانګړي پروټو-خدمت-مش کتابتونونه هم وو چې ورته ستونزې یې حل کړې وې چې نن ورځ خدمت میش حل کوي. په هرصورت، د خدماتو میش پخپله هغه وخت شتون نه درلود. مخکې لدې چې هغې راڅرګند شي باید یو بل بدلون وي.
او دا هغه ځای دی چې ژور ځواب په بل بدلون کې پټ دی چې په تیرو 10 کلونو کې پیښ شوی: د مایکرو خدماتو ځای پرځای کولو لګښت په ډراماتیک ډول راټیټ شوی. پورته ذکر شوي شرکتونه چې لس کاله دمخه یې مایکرو خدمات کارولي - ټویټر، Netflix، فیسبوک، ګوګل - د لوی پیمانه او لویو سرچینو شرکتونه وو. دوی نه یوازې اړتیا درلوده ، بلکه د لوی مایکرو خدماتو پراساس غوښتنلیکونو جوړولو ، ځای په ځای کولو او چلولو وړتیا هم درلوده. هغه انرژي او هڅې چې د ټویټر انجینرانو له یو واحد څخه مایکرو سرویسس طریقې ته حرکت ته اړولی حیرانتیا ده. (د عادلانه کیدو لپاره، دا حقیقت دی چې دا بریالی شو.) دا ډول زیربناوې بیا د کوچنیو شرکتونو لپاره ناشونې وې.
ګړندی اوس مهال ته. نن ورځ داسې پیلونه شتون لري چیرې چې پراختیا کونکو ته د مایکرو خدماتو تناسب 5: 1 دی (یا حتی )، او نور څه دي، دوی په بریالیتوب سره مقابله کوي! که د 5-شخص پیل کول په اسانۍ سره 50 مایکرو خدمتونه پرمخ وړي، نو یو څه په ښکاره ډول د دوی د پلي کولو لګښت کم کړی.
په مونزو کې 1500 کوچني خدمتونه؛ هره کرښه د شبکې ټاکل شوي قاعده ده چې ترافیک ته اجازه ورکوي
د عملیاتي مایکرو خدماتو په لګښت کې ډراماتیک کمښت د یوې پروسې پایله ده: د کانټینرونو مخ په زیاتیدونکي شهرت и آرکیسټرات. دا دقیقا د دې پوښتنې ژور ځواب دی چې د خدماتو میش رامینځته کیدو کې څه مرسته کړې. ورته ټیکنالوژي دواړه د خدماتو میشونه او مایکرو خدمات په زړه پوري کړي: کبرنیټس او ډاکر.
ولې؟ ښه ، ډاکر یوه لویه ستونزه حل کوي - د بسته بندۍ ستونزه. د غوښتنلیک بسته کولو سره او د هغې (غیر شبکې) د چلولو وخت انحصار په کانټینر کې ، ډاکر غوښتنلیک د تبادلې وړ واحد ته اړوي چې کوربه کیدی شي او هرچیرې چلولی شي. په ورته وخت کې، دا عملیات خورا ساده کوي څو ژبی سټیک: ځکه چې کانټینر د پلي کولو او عملیاتي موخو لپاره د اجرا کولو اټومي واحد دی ، دا مهمه نده چې دننه څه دي ، دا د JVM ، نوډ ، ګو ، پایتون یا روبي غوښتنلیک وي. تاسو یوازې دا پیل کړئ او بس.
Kubernetes هرڅه بلې کچې ته لیږي. اوس چې دلته د چلولو لپاره ډیری شیان شتون لري او د دوی چلولو لپاره ټن ماشینونه شتون لري، داسې وسیلې ته اړتیا ده چې کولی شي دوی له یو بل سره اړیکه ونیسي. په پراخه معنی، تاسو Kubernetes ته ډیری کانټینرونه او ډیری ماشینونه ورکوئ، او دا دوی د یو بل په وړاندې نقشه کوي (البته، دا یو متحرک او تل بدلیدونکی بهیر دی: نوي کانټینرونه د سیسټم شاوخوا حرکت کوي، ماشینونه پیل او ودریږي. په هرصورت، Kubernetes دا ټول په پام کې نیسي).
یوځل چې کبرنیټس تنظیم شي ، د یو خدمت پلي کولو او چلولو وخت لګښت د لسو خدماتو پلي کولو او چلولو لګښت څخه لږ توپیر لري (په حقیقت کې دا د 100 خدماتو لپاره نږدې ورته دی). دې کانټینرونو ته د بسته بندۍ میکانیزم په توګه اضافه کړئ چې څو ژبني پلي کول هڅوي، او تاسو د مایکرو خدماتو په بڼه په مختلفو ژبو لیکل شوي د نوي غوښتنلیکونو کوربه لرئ - په حقیقت کې هغه ډول چاپیریال چې د خدماتو میش لپاره خورا مناسب دی.
نو، موږ د دې پوښتنې ځواب ته راځو چې ولې د خدماتو میش مفکوره اوس مشهوره شوې ده: هغه همغږي چې کوبرنیټس د خدماتو لپاره چمتو کوي مستقیم د عملیاتي ننګونو لپاره پلي کیږي چې د خدماتو میش سره مخ دي. تاسو پراکسي په کانټینرونو کې بسته کړئ، کوبرنیټس ته دنده ورکړئ چې هرچیرې یې ودروي، او وایلا! د پایلې په توګه، تاسو د خدماتو میش ترلاسه کوئ، پداسې حال کې چې د دې ګمارلو ټول میخانیکونه د Kubernetes لخوا اداره کیږي. (لږترلږه د مرغیو د سترګو لید څخه. البته، د دې پروسې لپاره ډیری لنډیزونه شتون لري.)
د دې لنډیز لپاره: د دې لامل چې د خدماتو میشونه اوس مشهور شوي ، نه لس کاله دمخه ، دا دی چې کوبرنیټس او ډاکر نه یوازې د پام وړ وده کړې. اړتیا په دې کې، د څو ژبو مایکرو خدماتو سیټونو په توګه د غوښتنلیکونو پلي کول ساده کول، مګر د پام وړ کم شوي لګښتونه د دې عملیاتو لپاره، د سایډ کار پراکسي بیړیو ځای پرځای کولو او ملاتړ لپاره میکانیزمونه چمتو کوي.
ولې د خدمت میش په اړه دومره خبرې کیږي؟
مخنیوی: په دې برخه کې له هر ډول انګېرنو، ګومانونو، دروغو او داخلي معلوماتو څخه کار اخلم.
د "خدمت میش" لټون وکړئ او تاسو به د یو ټن ریسایکل شوي ټیټ کالوري مینځپانګې سره مخ شئ ، عجیب پروژې ، او د تحریف یو کلیډوسکوپ چې د ایکو چیمبر وړ دی. هره نوې ټیکنالوژي دا کار کوي، مګر د خدماتو میش په صورت کې ستونزه په ځانګړې توګه شدیده ده. ولې؟
ښه، د هغې یوه برخه زما ګناه ده. زه د لینکرډ ته وده ورکولو لپاره سخت کار کوم او د خدماتو میش هر چانس چې زه د دې په څیر د بې شمیره بلاګ پوسټونو او مقالو له لارې ترلاسه کوم. مګر زه دومره ځواکمن نه یم. د دې پوښتنې ځواب لپاره، موږ باید د عمومي وضعیت په اړه لږ څه خبرې وکړو. او د یوې پروژې له ذکر کولو پرته د دې په اړه خبرې کول ناممکن دي: د خلاصې سرچینې خدمت میش دی چې د ګوګل ، IBM او Lyft لخوا په ګډه رامینځته شوی.
(درې شرکتونه خورا مختلف رولونه لري: د لیفټ ښکیلتیا یوازې په نوم کې ښکاري؛ دوی د استازي لیکوالان دي، مګر د اسټیو په پراختیا کې کار نه کوي یا برخه نه اخلي. IBM د اسټیو پراختیا کې ښکیل دی او کاروي. ګوګل په فعاله توګه د اسټیو په پراختیا کې ښکیل دی. پرمختیا، مګر په حقیقت کې دا تر هغه ځایه نه کاروي چې زه یې ویلای شم.)
د اسټیو پروژه د دوه شیانو لپاره د پام وړ ده. لومړی، د بازار موندنې خورا لوی هڅې شتون لري چې ګوګل، په ځانګړې توګه، د هغې په وده کې اچوي. زه به اټکل وکړم چې ډیری خلک نن ورځ د خدماتو میش مفهوم څخه خبر دي لومړی یې د اسټیو له لارې د دې په اړه زده کړل. دویمه خبره دا ده چې Istio څومره بې وزله ترلاسه شوی. په دې مسله کې، زه په ښکاره ډول لیوالتیا لرم، مګر هڅه کوم چې د امکان تر حده هدف پاتې شم، زه لاهم مرسته نشم کولی , ډیر ځانګړی ندی (که څه هم ځانګړی ندی: سیسټم په ذهن کې راځي، ...) د خلاصې سرچینې پروژې لپاره.
(په عمل کې، اسټیو داسې بریښي چې نه یوازې د پیچلتیا او UX سره ستونزې لري، بلکه د فعالیت سره هم. د بیلګې په توګه، په جریان کې. د دریمې ډلې مطالعې کې، څیړونکو داسې شرایط وموندل چې په هغه کې د اسټیو د پای ځنډ د لینکرډ په پرتله 100 ځله لوړ و، په بیله بیا د منابعو له مینځه وړل شوي حالتونه چیرې چې لینکرډ په بریالیتوب سره کار کولو ته دوام ورکړ پداسې حال کې چې اسټیو په بشپړ ډول کار بند کړ.)
زما د تیوریو پریښودل چې ولې دا پیښ شوي، زه باور لرم چې د خدماتو میش په شاوخوا کې د پام وړ لیوالتیا د ګوګل د ګډون لخوا تشریح شوې. د بیلګې په توګه، د لاندې دریو فکتورونو ترکیب:
- د اسټیو د ګوګل لاسوهنه ترویج؛
- د پروژې په اړه ورته ناخوښي، انتقادي چلند؛
- د کبرنیټس په شهرت کې وروستي میټریک زیاتوالی، چې یادونه یې لاهم تازه دي.
دا فکتورونه یوځای سره یوځای کوي چې یو حیرانونکی، اکسیجن څخه پاک چاپیریال رامینځته کړي چې په کې د منطقي قضاوت ظرفیت کمزوری شوی، او یوازې عجیب ډولونه پاتې دي. .
د لینکرډ له نظره، دا هغه څه دي چې زه به یې د مخلوط نعمت په توګه تشریح کړم. زما مطلب دی ، دا خورا ښه دی چې د خدماتو میش په داسې طریقه اصلي جریان ته ننوتلی چې دا په 2016 کې نه و کله چې لینکرډ لومړی پیل وکړ او دا واقعیا سخته وه چې خلک دې پروژې ته پاملرنه وکړي. اوس داسې کومه ستونزه نشته! مګر بد خبر دا دی چې د خدماتو میش منظره نن ورځ دومره مغشوش ده چې دا تقریبا ناممکنه ده چې پوه شي چې کومې پروژې واقعیا د خدماتو میش کټګورۍ کې دي (یوازې پریږدئ پوه شئ چې کوم یو د ځانګړي کارونې قضیې لپاره غوره دی). دا یقینا د هرچا لپاره معامله کونکی دی (او یقینا ځینې قضیې شتون لري چیرې چې اسټیو یا بله پروژه د لینکرډ په پرتله غوره ده ، ځکه چې وروستی لاهم نړیوال حل ندی).
د لینکرډ په اړخ کې، زموږ ستراتیژي دا وه چې شور له پامه غورځول، د ټولنې د حقیقي ستونزو حل کولو تمرکز ته دوام ورکړو، او په لازمي ډول د هایپ مړینې ته انتظار وباسو. په نهایت کې ، هیپ به کم شي او موږ کولی شو په آرامۍ سره کار ته دوام ورکړو.
په ورته وخت کې، موږ ټول باید لږ صبر وکړو.
ایا د خدمت میش به زما لپاره ګټور وي ، یو عاجز سافټویر انجینر؟
لاندې پوښتنلیک به تاسو سره د دې پوښتنې په ځواب کې مرسته وکړي:
ایا تاسو یوازې د سوداګرۍ منطق پلي کولو کې ښکیل یاست؟ په دې حالت کې، د خدمت میش به ستاسو لپاره ګټور نه وي. دا ، البته ، تاسو ممکن پدې کې علاقه ولرئ ، مګر په مثالي توګه د خدماتو میش باید مستقیم ستاسو په چاپیریال کې هیڅ شی اغیزه ونکړي. د هغه څه په اړه کار کولو ته دوام ورکړئ چې تاسو یې د ترسره کولو لپاره تادیه کوئ.
ایا تاسو په یوه شرکت کې د پلیټ فارم ملاتړ کوئ چې کوبرنیټس کاروي؟ هو، پدې حالت کې تاسو د خدماتو میش ته اړتیا لرئ (مګر که تاسو K8s یوازې د مونولیت یا بیچ پروسس کولو لپاره کاروئ - مګر بیا زه غواړم پوښتنه وکړم چې تاسو ولې K8s ته اړتیا لرئ). تاسو به احتمالا د مختلف خلکو لخوا لیکل شوي ډیری مایکرو خدماتو سره پای ته ورسیږئ. دوی ټول له یو بل سره متقابل عمل کوي او د چلولو وخت پورې تړلو پورې تړلي دي، او تاسو اړتیا لرئ د دې ټولو سره معامله کولو لپاره لاره ومومئ. د Kubernetes کارول تاسو ته اجازه درکوي د خدمت میش "د ځان لپاره" غوره کړئ. د دې کولو لپاره ، خپل ځان د دوی وړتیاو او ځانګړتیاو سره آشنا کړئ او دې پوښتنې ته ځواب ووایاست چې ایا کومې موجودې پروژې ستاسو لپاره مناسب دي (زه وړاندیز کوم چې ستاسو څیړنه د لینکرډ سره پیل کړئ).
ایا تاسو په یوه شرکت کې د پلیټ فارم شرکت یاست چې کوبرنیټس نه کاروي مګر مایکرو خدمات کاروي؟ په دې حالت کې، د خدمت میش به ستاسو لپاره ګټور وي، مګر د هغې کارول به غیر معمولي وي. البته تاسو کولی شئ نقل کول د یو شمیر پراکسيونو په ځای کولو سره د خدماتو میش کار کوي، مګر د کوبرنیټس یوه مهمه ګټه د ځای پرځای کولو ماډل دی: په لاسي ډول د دې پراکسي ساتل به ډیر وخت، هڅې او لګښت ته اړتیا ولري.
ایا تاسو په یوه شرکت کې د پلیټ فارم لپاره مسؤل یاست چې د مونولیتس سره کار کوي؟ په دې حالت کې، تاسو شاید د خدماتو میش ته اړتیا نلرئ. که تاسو د monoliths (یا حتی د monoliths ټولګه) سره کار کوئ چې ښه تعریف شوي او په ندرت سره د متقابل عمل نمونې بدلوي، نو د خدماتو میش به تاسو ته د وړاندیز کولو لپاره لږ څه ولري. نو تاسو کولی شئ دا په ساده ډول له پامه غورځولی شئ او امید لرئ چې دا به د بد خوب په څیر ورک شي ...
پایلې
شاید، د خدماتو میش لاهم باید "په نړۍ کې ترټولو غوره ټیکنالوژي" ونه بلل شي - دا شکمن اعزاز شاید د Bitcoin یا AI پورې اړه ولري. هغه شاید په غوره پنځو کې وي. مګر که تاسو د شور پرتونو پرې کړئ ، نو دا روښانه کیږي چې د خدماتو میش هغو کسانو ته ریښتیني ګټې راوړي څوک چې په کوبرنیټس کې غوښتنلیکونه رامینځته کوي.
زه غواړم چې تاسو لینکرډ هڅه وکړئ - دا د کبرنیټس کلستر کې نصب کړئ (یا حتی په لیپ ټاپ کې مینیکیوب) ، او تاسو کولی شئ د ځان لپاره وګورئ چې زه د څه په اړه خبرې کوم.
FAQs
- که زه د خدماتو میش له پامه غورځوم، ایا دا به ورک شي؟
- زه باید تاسو مایوسه کړم: د خدمت میش د اوږدې مودې لپاره زموږ سره دی.
- مګر زه نه غواړم د خدمت میش وکاروم!
- ښه، دا اړینه نه ده! یوازې زما پورته پوښتنلیک ولولئ ترڅو پوه شئ چې ایا تاسو باید لږترلږه د دې اساساتو سره ځان آشنا کړئ.
- ایا دا د نوي ساس سره ښه زوړ ESB/منځنی سامان ندی؟
- د خدماتو میش د عملیاتي منطق سره معامله کوي، نه سیمانټیک. د شرکت خدمت بس (). د دې جلا کولو ساتل د خدماتو میش سره مرسته کوي د ورته برخلیک څخه مخنیوی وکړي.
- د خدماتو میش څنګه د API ګیټ ویز څخه توپیر لري؟
- پدې موضوع کې یو ملیون مقالې شتون لري. یوازې دا ګوګل کړئ.
- سفیر د خدمت میش دی؟
- نه، سفیر د خدماتو میش نه دی، دا یو پراکسي سرور دی. دا د خدماتو میش تنظیم کولو لپاره کارول کیدی شي (او نور ډیر څه - دا د عمومي هدف پراکسي دی). مګر پخپله دا د خدمت میش ندی.
- د شبکې خدمت میش د خدماتو میش دی؟
- نه. د نوم سره سره، دا د خدماتو میش نه دی (تاسو څنګه د بازار موندنې معجزې خوښوئ؟).
- ایا د خدماتو میش به زما د پیغام کتار میشته عکس العمل غیر فعال سیسټم سره مرسته وکړي؟
- نه، د خدمت میش به تاسو سره مرسته ونکړي.
- کوم خدمت میش باید وکاروم؟
- ، هیڅ مغز نلري.
- مقاله خرابه ده! / لیکوال ښه راغلاست!
- مهرباني وکړئ د دې لینک له خپلو ټولو ملګرو سره شریک کړئ ترڅو دوی یې وګوري!
اعترافونه
لکه څنګه چې تاسو ممکن د سرلیک څخه اټکل کړی وي، دا مقاله د جې کریپس په زړه پورې مقالې څخه الهام اخیستې وه "" ما لس کاله دمخه له جې سره ولیدل کله چې ما د هغه سره په لینک شوي کې مرکه وکړه او هغه له هغه وخت راهیسې زما لپاره الهام دی.
پداسې حال کې چې زه غواړم ځان ته د "لینکرډ پراختیا کونکی" ووایم، حقیقت دا دی چې زه په پروژه کې د README.md فایل ډیر ساتونکی یم. Linkerd نن ورځ کار کوي , , خلک، او دا پروژه به د ونډې اخیستونکو او کاروونکو په زړه پورې ټولنې له ګډون پرته نه وي پیښ شوي.
او په نهایت کې ، د لینکرډ جوړونکي څخه ځانګړې مننه ، (primus inter pares)هغه چا چې کلونه وړاندې له ما سره یو ځای د خدمت جال سره په دې ټولو ګډوډۍ کې ډوب شو.
PS د ژباړونکي څخه
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «»
- «»
- «".
سرچینه: www.habr.com