سلام، حبر. نن ورځ زه د خپرونو لړۍ ته دوام ورکوم چې ما په ځانګړي ډول د کورس د نوي جریان د پیل لپاره لیکلي. .
پېژندنه
د معمارۍ سټایل انتخاب یو له بنسټیزو تخنیکي پریکړو څخه دی کله چې د معلوماتو سیسټم رامینځته کول. د مقالو پدې لړۍ کې ، زه وړاندیز کوم چې د غوښتنلیکونو جوړولو لپاره ترټولو مشهور معماري سټایلونه تحلیل کړم او دې پوښتنې ته ځواب ورکړم چې کوم معماري سټایل خورا غوره دی. د پریزنټشن په بهیر کې، زه به هڅه وکړم چې یو منطقي سلسله راوباسئ چې د معماري سټایلونو پراختیا له مونولیتس څخه مایکرو سرویسونو ته تشریح کوي.
В موږ د مونولیت سره معامله وکړه او دې پایلې ته ورسیدو چې مونولیت یو شمیر ستونزې لري: اندازه، ارتباط، ځای پرځای کول، توزیع، اعتبار او دقت.
دا ځل زه وړاندیز کوم چې د ماډلونو/کتابتونونو د یوې سیټ په توګه د سیسټم تنظیم کولو امکاناتو په اړه وغږیږم.
د اجزاو پر بنسټ جوړښت
د اجزاو پر بنسټ جوړښت د اجزاو د یوې سیټ په توګه د سیسټم اجرا کول شامل دي چې په اوسني او راتلونکي دواړو پروژو کې کارول کیدی شي. کله چې یو سیسټم په اجزاوو ویشل کیږي، لاندې ټکي په پام کې نیول کیږي: د دوی بیا کارونې وړتیا، د دوی د ځای کولو وړتیا، د شرایطو خپلواکي، توسعیت، انډول کول او خپلواکي.
د اجزاوو په سمه توګه کارولو سره، د "د کثافاتو لوی بال" (لوی اندازه + لوړ جوړه) ستونزه حل کیږي، او اجزا پخپله دواړه د مجلس واحدونه (ماډولونه، کتابتونونه) او د ځای پرځای کولو واحدونه (خدمات) کیدی شي. د پلي کولو واحدونه تل د روان پروسې سره نقشه نه کیږي: د مثال په توګه ، ویب غوښتنلیک او ډیټابیس یوځای ځای په ځای شوي.
ډیری وختونه، مونولیتونه د ماډلونو سیټ په توګه رامینځته کیږي. دا طریقه د خپلواک پرمختګ لامل کیږي، مګر د خپلواک اندازه کولو او پلي کولو ستونزې، د غلطۍ زغم او د ټول ټیکنالوژۍ سټیک څخه خپلواکي پاتې ده. له همدې امله ماډل یو څه خپلواکه برخه ده.
د داسې مونولیت سره لویه ستونزه دا ده چې په ماډلونو کې ویش په بشپړ ډول منطقي دی او د پراختیا کونکو لخوا په اسانۍ سره سرغړونه کیدی شي. یو اصلي ماډل ممکن څرګند شي ، کوم چې په تدریجي ډول د کثافاتو په ډنډ بدلیږي ، د ماډلونو ترمینځ د انحصار ګراف ممکن وده وکړي ، او داسې نور. د دې ډول ستونزو څخه د مخنیوي لپاره، پراختیا باید یا د خورا بالغ ټیم لخوا ترسره شي، یا د "معمار" تر لارښوونې لاندې چې د بشپړ وخت کوډ بیاکتنې کې بوخت وي او د پراختیا کونکو لاسونه وهي چې منطقي جوړښت څخه سرغړونه کوي.
"مثالي" مونولیت د منطقي پلوه جلا شوي ماډلونو سیټ دی، چې هر یو یې خپل ډیټابیس ته ګوري.
د خدمت پر بنسټ جوړښت
که چیرې سیسټم باید د خدماتو د یوې سیټ په بڼه تنظیم شي، نو موږ د خدمت پر بنسټ د جوړښت په اړه خبرې کوو. د دې اصول د کارونکي متمرکز غوښتنلیک متقابل عمل ، د سوداګرۍ خدماتو بیا کارول ، د ټیکنالوژۍ سټیک خپلواکي ، او خپلواکي (خپلواکه تکامل ، توزیع کول ، او ځای پرځای کول) دي.
د خدمت پر بنسټ معمارۍ (SOA = د خدمت پر بنسټ جوړښت) د مونولیت ټولې پیژندل شوې ستونزې حل کوي: یوازې یو خدمت اغیزمن کیږي کله چې بدلون واقع کیږي، او یو ښه تعریف شوی API د اجزاوو ښه پوښښ ملاتړ کوي.
مګر هرڅه دومره اسانه ندي: SOA نوې ستونزې رامینځته کوي. ریموټ تلیفونونه د ځایی تلیفونونو په پرتله خورا ګران دي، او د اجزاوو ترمنځ د مسؤلیتونو بیا ویش د پام وړ ډیر ګران شوی.
په هرصورت، د خپلواک ګمارلو امکان د خدماتو خورا مهم ځانګړتیا ده. که خدمتونه باید یوځای ځای په ځای شي یا سربیره پردې، په یو ټاکلي ترتیب کې، بیا سیسټم نشي کولی د خدماتو پر بنسټ وګڼل شي. په دې حالت کې، دوی د توزیع شوي مونولیت په اړه خبرې کوي (نه یوازې د SOA له نظره، بلکې د مایکرو سرویس معمارۍ له نظره هم د ضد نمونې په توګه ګڼل کیږي).
د خدمت پر بنسټ معمارۍ د معمارۍ ټولنې او پلورونکو لخوا ښه ملاتړ کیږي. دا د ډیری کورسونو او تصدیقونو شتون په ګوته کوي ، ښه پرمختللي نمونې. وروستنۍ کې شامل دي، د بیلګې په توګه، د تصدۍ پیژندل شوي خدمت بس (ESB = د تصدۍ خدماتو بس). په ورته وخت کې، ESB د پلورونکو څخه یو سامان دی؛ دا اړینه نده چې په SOA کې وکارول شي.
د خدمت پر بنسټ د معمارۍ شهرت د 2008 په شاوخوا کې لوړ شو، وروسته له هغې چې دا په کمیدو پیل وکړ، کوم چې د مایکرو خدماتو (~ 2015) له راتګ وروسته د پام وړ ډیر ډراماتیک شو.
پایلې
وروسته له دې چې موږ د خدماتو او ماډلونو په بڼه د معلوماتو سیسټمونو تنظیم کولو امکاناتو په اړه بحث وکړ، زه وړاندیز کوم چې په پای کې د مایکرو سرویس معمارۍ اصولو ته لاړ شم او په راتلونکې برخه کې د مایکرو سرویس معمارۍ او خدماتو پر بنسټ جوړښت ترمنځ توپیر ته ځانګړې پاملرنه وکړم.
سرچینه: www.habr.com