ما غوښتل د اوږدې مودې لپاره د مایکروسافټ معمارۍ په اړه مقاله ولیکم، مګر دوه شیانو ما مخه ونیوله - هرڅومره چې ما موضوع ته ورننوتل، نور ما ته داسې بریښي چې زه څه پوهیږم هغه څرګند دی، او زه څه نه کوم. نه پوهیدل باید مطالعه او مطالعه شي. له بلې خوا، زه فکر کوم چې د پراخو لیدونکو ترمنځ د بحث کولو لپاره لا دمخه یو څه شتون لري. نو بدیل نظرونه ښه راغلاست دي.
د کانوی قانون او د سوداګرۍ، سازمان او معلوماتو سیسټم ترمنځ اړیکه
یوځل بیا زه اجازه ورکوم چې خپل ځان ته حواله کړم:
"هر هغه سازمان چې یو سیسټم ډیزاین کوي (په پراخه معنی کې) به داسې ډیزاین ترلاسه کړي چې جوړښت یې په دې سازمان کې د ټیمونو جوړښت نقل کوي."
میلوین کانوی، ۱۹۶۷
زما په اند، دا قانون ډیر احتمال لري چې د سوداګرۍ تنظیم کولو امکانات پورې اړه ولري، نه د مستقیم معلوماتو سیسټم سره. اجازه راکړئ په یوه مثال سره تشریح کړم. راځئ چې ووایو چې موږ د دومره اوږدوالي د ژوند دورې سره د کافي مستحکم سوداګرۍ فرصت لرو چې دا د تصدۍ تنظیم کولو لپاره معنی لري (دا ټایپو نده ، مګر زه واقعیا دا اصطلاح خوښوم چې ما غلا کړې) په طبیعي توګه ، د دې سوداګرۍ ملاتړی سیسټم. په سازماني او پروسیجر ډول به د دې سوداګرۍ سره مطابقت ولري.
د معلوماتي سیسټمونو سوداګرۍ تمایل
اجازه راکړئ په یوه مثال سره تشریح کړم. راځئ چې ووایو د پیزا پلورلو سوداګرۍ تنظیم کولو لپاره د سوداګرۍ فرصت شتون لري. د V1 نسخه کې (راځئ چې دا د معلوماتو دمخه ووایو)، شرکت پیززیریا، د نغدو راجستر، او د تحویلي خدمت و. دا نسخه د ټیټ چاپیریال بدلون په شرایطو کې اوږدمهاله وه. بیا نسخه 2 د دې ځای په ځای کولو لپاره راغله - ډیر پرمختللی او د یو واحد معمارۍ سره د سوداګرۍ لپاره د معلوماتو سیسټم کارولو توان لري. او دلته، زما په اند، د واحدونو په اړه په ساده ډول یو لوی ظلم دی - د ادعا شوي واحد معمارۍ د ډومین سوداګرۍ ماډل سره مطابقت نلري. هو، که دا وي، سیسټم به په هیڅ ډول د کار کولو توان ونلري - د ورته کانوی قانون او عام احساس سره په تضاد کې. نه، د سوداګرۍ د پراختیا په دې مرحله کې واحد معمارۍ د سوداګرۍ ماډل سره په بشپړه توګه مطابقت لري - زه، البته، هغه مرحله ده کله چې سیسټم لا دمخه رامینځته شوی او په فعالیت کې اچول شوی وي. دا یو خورا په زړه پوری حقیقت دی چې د معمارۍ چلند ته په پام سره ، دواړه د خدماتو پر بنسټ معمارۍ نسخه 3 او د مایکرو سرویسس آرکیټیکچر نسخه N به په مساوي توګه کار وکړي. کیچ څه شی دی؟
هر څه تیریږي، هرڅه بدلیږي، یا مایکرو خدمتونه د پیچلتیا سره د مبارزې وسیله ده؟
مخکې لدې چې موږ دوام ورکړو ، راځئ چې د مایکرو سرویس جوړښت په اړه ځینې غلط فهمۍ وګورو.
د مایکرو سرویس طریقې کارولو پلویان اکثرا استدلال کوي چې په مایکرو سرویسونو کې د واحد ماتول د انفرادي خدماتو د کوډ بیس کمولو سره د پراختیا طریقه ساده کوي. زما په اند، دا څرګندونې په بشپړه توګه بې بنسټه دي. په جدي توګه، د یو واحد او همجنس کوډ دننه ښکاره تعامل پیچلی ښکاري؟ که دا واقعا واقع وي، ټولې پروژې به په پیل کې د مایکرو خدماتو په توګه جوړې شي، پداسې حال کې چې تمرین ښیي چې له یو واحد څخه مایکرو خدماتو ته مهاجرت خورا عام دی. پیچلتیا له لاسه نه ورکوي؛ دا په ساده ډول له انفرادي ماډلونو څخه انٹرفیسونو ته حرکت کوي (دا د ډیټا بسونه ، RPC ، APIs ، او نور پروتوکولونه وي) او د تنظیم کولو سیسټمونه. او دا ستونزمنه ده!
د متفاوت سټیک کارولو ګټه هم د پوښتنې وړ ده. زه به استدلال ونه کړم چې دا هم ممکنه ده، مګر په حقیقت کې دا په ندرت سره پیښیږي (مخکې لیدل - دا باید پیښ شي - مګر د ګټې په پرتله د پایلې په توګه).
د محصول د ژوند دوره او د خدمت ژوند دوره
پورته انځور ته یو بل نظر وګورئ. دا کومه تصادفي نه ده چې ما د سوداګرۍ د جلا نسخې د ژوند دوره کمه کړې - په عصري شرایطو کې، دا د نسخو ترمنځ د سوداګرۍ لیږد ګړندی دی چې د بریالیتوب لپاره پریکړه کونکی دی. د محصول بریالیتوب په دې کې د سوداګرۍ فرضیې ازموینې سرعت لخوا ټاکل کیږي. او دلته، زما په نظر، د مایکرو سرویس معمارۍ کلیدي ګټه ده. مګر راځئ چې په ترتیب سره لاړ شو.
راځئ چې د معلوماتي سیسټمونو د تکامل راتلونکي مرحلې ته لاړ شو - د SOA خدمت پر بنسټ جوړښت ته. نو، په یو ټاکلي وخت کې موږ په خپل محصول کې روښانه کړه اوږدمهاله خدمتونه - د اوږدې مودې لپاره په دې معنی چې کله د محصول د نسخو ترمنځ حرکت کول، د دې امکان شتون لري چې د خدماتو د ژوند دوره به د محصول د راتلونکي نسخې د ژوند دورې څخه اوږده وي. دا به منطقي وي چې دوی په هیڅ ډول بدل نه کړو - موږ هغه څه چې مهم دي راتلونکي نسخې ته د لیږد سرعت دی. مګر افسوس، موږ مجبور یو چې په خدماتو کې دوامداره بدلونونه وکړو - او دلته هرڅه زموږ لپاره کار کوي، د DevOps کړنې، کانټینر کول، او داسې نور - هرڅه چې ذهن ته راځي. مګر دا لاهم کوچني خدمتونه ندي!
کوچني خدمتونه د پیچلتیا سره د مبارزې لپاره د یوې وسیلې په توګه ... د تنظیم کولو مدیریت
او دلته موږ کولی شو په پای کې د مایکرو خدماتو تعریف شوي رول ته لاړ شو - دا هغه طریقه ده چې د محصول تنظیم کولو مدیریت ساده کوي. په ډیر تفصیل سره، د هر مایکروسافټ فعالیت د ډومین ماډل سره سم د محصول دننه د سوداګرۍ فعالیت په سمه توګه تشریح کوي - او دا هغه شیان دي چې په لنډ مهاله نسخه کې نه ژوند کوي، مګر د اوږد مهاله سوداګرۍ فرصت کې. او د محصول بلې نسخې ته لیږد واقعیا په پام کې نه نیول کیږي - تاسو یو مایکرو خدمت بدل کړئ / اضافه کړئ ، او شاید یوازې د دوی متقابل عمل سکیم ، او ناڅاپه تاسو په راتلونکي کې خپل ځان ومومئ ، د ژړا سیالانو شاته پریږدئ چې د نسخو ترمینځ کودتا ته دوام ورکوي. د هغوی monoliths. اوس تصور وکړئ چې د مخکیني تعریف شوي انٹرفیسونو او سوداګرۍ وړتیاو سره د مایکرو خدماتو خورا لوی مقدار شتون لري. او تاسو راشئ او د چمتو شوي مایکرو خدماتو څخه د خپل محصول جوړښت رامینځته کړئ - د مثال په توګه د ډیاګرام په رسم کولو سره. مبارکۍ - تاسو یو پلیټ فارم لرئ - او اوس تاسو کولی شئ د ځان لپاره سوداګرۍ راجلب کړئ. خوبونه خوبونه.
موندنو
- د سیسټم جوړښت باید د هغې د اجزاوو د ژوند دوره وټاکل شي. که یوه برخه د محصول نسخه کې ژوند کوي، د مایکرو سرویس طریقې په کارولو سره د سیسټم پیچلتیا زیاتولو کې هیڅ معنی نشته.
- د مایکرو سرویس جوړښت باید د ډومین ماډل پراساس وي - ځکه چې د سوداګرۍ فرصت ترټولو اوږد ژوند ډومین دی
- د تحویلي کړنې (DevOps کړنې) او آرکیسټریشن د مایکرو سرویس معمارۍ لپاره یو له خورا مهم دی - د دې دلیل لپاره چې د اجزاو بدلولو نرخ کې زیاتوالی د تحویلي سرعت او کیفیت باندې غوښتنې ډیروي.
سرچینه: www.habr.com