خانه / DevOps / ملزومات مایکروسرویس

ملزومات مایکروسرویس

ملزومات مایکروسرویس

آقای مارتین فاولر مقاله ای تحت عنوان MicroservicePrerequisites دارند که در اون به بررسی یک سری پیش نیاز ها برای رفتن و تصمیم جهت حرکت به سمت معماری مایکروسرویس ها پرداختند؛ که در زیر می توانید برگردان این مقاله را به فارسی مشاهده بفرمائید.

به موازات اینکه با مردم و افراد درباره ی استفاده از سبک معماری مایکروسرویس, صحبت می کنم؛خوش بینی زیادی را شنیدم. توسعه دهنده ها از کار کردن با واحدهای کوچکتر لذت می برند و همچنین انتظار دارند که سطح ماژولاریتی بیشتر و بالاتری نسبت به مونولیت ها داشته باشند. همانند هر تصمیم معماری اما اینجا هم با مسامحه کاری سروکار خواهیم داشت. بویژه بهمراه مایکروسرویس ها برای کسی که مجبور به هندل کردن یک اکوسیستم از سرویس های کوچکتر در تقابل با یک تک مونولیت خوش-تعریف می باشند, پیامدهای جدی برای اداره کردن وجود دارد. نتیجتا اینکه در صورتی که دارای یک حداقلی از صلاحیت ها در این زمینه نیستید؛ نباید استفاده کردن از روش مایکروسرویس را مطرح نمائید.

تامین سریع: باید قادر باشید که عرض چند ساعت یک سرور جدید را بالا بیاورید. طبیعتا این متناسب با  CloudComputing می باشد, اما موردی هست که می تواند بدون داشتن یک سرویس کامل Cloud نیز به انجام برسد. برای اینکه بتونید اقداماتی شبیه تامین سریع رو انجام بدید؛ به تعداد زیادی automation نیاز خواهید داشت- این مورد ممکن است که ابتدا به ساکن نیاز نباشد که بطور کامل automated باشد؛ اما بمنظور انجام جدی مایکروسرویس ها نیاز هست که این کار را انجام دهیم.

مانیتور کردن پایه: با مقدار زیادی تعامل و گفتگو میان سرویس های با اتصال ضعیف در محیط پروداکشن؛ این سرویس ها ممکن است به اشتباه به روش هایی که تشخیص آنها در محیط هایی آزمون مشکل است؛ متوقف شوند. در نتیجه وجود داشتن یک روش مانیتور کردن جهت تشخیص دادن هر چه سریعتر مشکلات جدی یک مورد ضروری می باشد. بیس لاین در اینجا تشخیص دادن مشکلات تکنیکال(حساب کردن خطاها, در دسترس بودن سرویس و موارد مشابه) می باشد؛ اما همچنین مانیتور نمودن مشلات بیزینسی(از جمله تشخیص از قلم افتادن برخی سفارشات) نیز ارزشمند می باشند. در صورتی که یک مشکل ناگهانی رخ بدهد باید مطئن باشید که خواهید توانست که آن را سریعا rollback کنید بهمین دلیل…

توسعه سریع برنامه: با داشتن تعدا زیادی سرویس که باید مدیریت شوند, نیاز خواهید داشت که هرچه سریعتر آنها را دیپلوی کنید؛ هم در محیط های آزمون و هم محیط پروداکشن. معمولا این مورد نیازمند یک  DeploymentPipelineمی باشد که در کمتر از یک ساعت اجرا شود. برخی مداخلات دستی بخصوص در مراحل اولیه صحیح هست؛ اما خیلی زود به دنبال یک automation کامل خواهید بود.

چنین توانایی هایی دلالت بر یک تغییر جهت سازمانی دارد-همکاری نزدیک میان توسعه دهنده ها و عملیاتی ها؛  DevOpsCulture. این همکاری جهت اطمینان از اینکه این توسعه و تامین می تواند به سرعت انجام شود؛ مورد نیاز می باشد, و همچنین جهت اطمینان از اینکه شما قادر خواهید بود هنگامی که مانیتورینگ شما یک مسئله و مشکل را نشان می دهد سریعا عکس العمل نشان دهید. علی الخصوص هر مدیریت حوادث جهت درگیر کردن تیم توسعه و عملیاتی ها نیاز است؛ هم برای رفع نمودن مشکلات فوری و هم ریشه یابی کردن جهت اطمینان از اینکه مشکلات اساسی حل خواهند شد.

با این نوع از راه ندازی در محل؛ شما برای اولین سیستم که از مایکروسرویس ها استفاده می کند اماده می باشید. این سیستم را دیپلوی کنید؛ و از اون در پروداکشن استفاده کنید؛ و منتظر باشید که درباره ی سلامت نگه داشتن آن خیلی زیاد یاد بگیرید؛ و مطمنن باشید که همکاری DevOps بخوبی عمل می کند. برای انجام دادن این موارد به خودتون زمان بدید, از آن یاد بگیرید؛ و قبل از اینکه تعداد سرویس های خود به به یکباره زیاد کنید؛ توانایی خود را بالا ببرید.

در صورتی که در حال حاظر همچین توانمندی هایی را ندارید, مطمئن شوید که آنها را توسعه می دهید بنابراین آنها زمانی که شما یک سیستم مایکروسرویس را به پروداکشن قرار می دهید اماده هستند. مسلما اینها توانایی هایی هستند که برای سیستم های مونولیت نیز شما قطعا نیاز خواهید داشت. هرچند آنها عموما میان سازمانهای نرم افزاری نیستند؛ جاهایی کمی هستند که آنها نباید اولویت بالایی داشته باشند.

رفتن به بیش از یک مشت سرویس نیازمندیهای بیشتری را دارد. شما نیاز دارید که تراکنش های بیزینسی که میان چندین سرویس هستند را ردیابی کنید و همچنین با پذیرش کامل ContinuousDelivery توسعه و تامین خود را اتوماتیک کنید.این مورد همچنین یک جابجایی برای product centered teams که نیازمند شروع شدن می باشند نیز هست. شما نیاز دارید که محیط توسعه خود را سازماندهی کنید؛ در نتیجه توسعه دهنده های ممکن است خیلی راحت میان جندین repository, library و language های مختلف جابجا شوند. برخی از مخاطبین من احساس کردند که در اینجا می توان یک مفید که به سازمانهایی که به سمت پیاده سازی های بیشتر از مایکروسرویس ها هستند, کمک می کند-باید گفتگوی بیشتری درباره ی آن در چند سال بعدی ببینیم.

سپاسگزاری

این لیست در بحثی با همکارانم در ThoughtWorks شکل گرفته است, بخصوص آنهایی که در اوج مایکروسرویس در چند سال اخیر هستند. از همین رو لیست را با بحث و گفتگو با Evan Bottcher, Thiyagu Palanisamy, Sam Newman, and James Lewisساختار داده و به اتمام رسوندم.

طبق معمول کامنت ها ارزشمندی از لیست میلینگ داخلی من از Chris Ford, Kief Morris, PremanandChandrasekaran, RebeccaParsons, Sarah Taraporewallaو Ian Cartwright وجود داشت.

درباره ی masoud@admin

همچنین ببینید

درس هایی که مایکروسرویس باید از موفقیت ها و شکست های SOA بگیرد.

درس هایی که مایکروسرویس باید از موفقیت ها و شکست های SOA بگیرد. یکی از …

Say No to No Monolith

Say No to “No Monolith” Packages Principals با بیشتر شدن تمایل و گرایش به مایکروسرویس …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن