خانه / microservices / استاندارد سازی و آزادی عمل؛دوگانگی مهم و حیاتی در مایکروسرویس ها

استاندارد سازی و آزادی عمل؛دوگانگی مهم و حیاتی در مایکروسرویس ها

استاندارد سازی و آزادی عمل؛دوگانگی مهم و حیاتی در مایکروسرویس ها

وقتی که صحبت از مایکروسرویس یا سرویس های کوچک مقیاس و مایکروسرویس سازی به میان می آید؛ سیستمی با یک دوجین سرویس کوچک(مطابق اصل Programing Polyglot) با حداقل میزان کد و وابستگی؛ که با هم تعامل دارند به ذهن خطور می کند. سرویس هایی که کاملا مستقل از یکدیگر هستند؛ و حتی دارای دیتاهای مختص بخود هستند؛ و داده های هر سرویس از دید سرویس های دیگر پنهان بوده؛ و قابل دسترسی مستقیم نمی باشد(Data base polyglot).

مایکروسرویس ها در این اکوسیستم که البته از دید کاربر نهایی به عنوان یک سیستم یکپارچه به نظر می آید(اصل شفافیت در سیستم های توزیع شده)؛ جهت تکمیل سناریوهای کاربر نیازمند روشی جهت ارتباط با یکدیگر می باشند؛ معمولترین روش جهت ارتباط میان سرویس ها؛ بدین صورت می باشد که هر سرویس یک API ارائه می دهد؛ که سایر سرویس ها از طریق آن امکان برقراری ارتباط با سرویس مورد نظر را داشته باشند. در واقع می توان از یک دید غیر فنی گفت مایکروسرویس برابر است با یک مشت سرویس و یک دوجین API.

Sam Newman مزیت های زیر را برای مایکروسرویس ها بر می شمارد:

  • انعکاس راحت Entity های سطح دامین و عملیات مرتبط با آنها درون هر سرویس
  • هم تراز آسانتر با ساختار سازمان
  • بصورت مستقل و بدون وابستگی با سایر سرویس ها می توانند دیپلوی شود؛ که این امر منجر به کمک به چرخه های Continues Delivery می شود؛ زیرا اجازه می دهد که در صورت نیاز به هر سرویس تنها همان سرویس بتواند بصورت جداگانه دیپلوی شود
  • تطابق با تکنولوژی های جدیدتر در صورت نیاز آسان تر انجام می شود
  • مقیاس پذیر نمودن سرویس های کوچکتر بسیار راحت تر از مقیاس نمودن یک سیستم بزرگ می باشد

 

دو رویکرد مختلف بهنگام توسعه سیستم وجود دارد:

  • استاندارد سازی: انتخاب یک استاندارد یکسان و مشابه برای توسعه سیستم بر اساس یکسری از چالش های اولویت دار از جمله امنیت یا یکپارچگی داده و … .
  • آزاد گذاشتن همه تیم ها: بهنگام توسعه سیستم ها به توسعه دهنده ها آزادی عمل داده شود که از هر پشته ی تکنولوژی و هر زبان برنامه نویسی که دوست داشتند استفاده کنند.

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

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

بهنگام توسعه سرویس ها سعی کنید بر روی استاندارد سازی Integration این سرویس ها به دقت و با وسواس بیشتری وقت بگذارید. در این نقطه حتما از مکانیزم های RPC اجتناب کنید؛ این مکانیزم ها محدودیت هایی جدید برای integration style ها مختلف که برای یکپارچه سازی مایکروسرویس ها مورد نیاز می باشد. بهترین گزینه برای انتخاب integration style میان مایکروسرویس های رویکردهای مبتنی بر resource ها می باشد.

در معماری های سرویس گرا از جمله مایکروسرویس؛ تراکنش هایی که بین چندین سرویس پخش شده اند؛ یکی از چالش های مهم این سیستم ها می باشد؛ جایی که دیگر ACID نمی تواند به ما کمک کند و ما باید سراغ BASE برویم(قانون اسید و بازها در دیتابیس) تا حد امکان باید از این تراکنش ها اجتناب کرد.

با توجه به اینکه در این سیستم ها پیام ها(شامل commandها یا Queryها یا Eventها) میتوانند بین چندین مایکروسرویس و چندین سیستم مختلف در گردش و یا سرگردان باشند؛ حتما جهت track کردن وضعیت این پیام ها در این سیستم های توزیع شده؛ از Correlation ID استفاده کنند. این مورد همچنین جهت تشخیص Duplicateها؛ پیام های نامعتبر و … نیز بسیار مناسب و ضروری می باشد.

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

بهنگام طراحی API ها برای هر کدام از سرویس ها که می تواند Consumer های مختلفی از مایکروسرویس های گرفته تا Device های مختلف(مثل موبایل ها) و استفاده کننده های بیرون سازمان؛ حتما به Consumer-Driven Contract ها برای این سرویس ها پایبند باشید. در این الگو فرآیند توسعه API از مشتری و بر اساس نیاز او شروع می شود.

به تغییرات اجازه ندهید که زیاد شوند؛ هرچه سریعتر تغییرات را ریلیز کنید؛ در حالت ایده آل به ازای هر تغییر یک ریلیز.

فقط یک روش جهت دیپلوی کردن سرویس های توی تمام محیط های مختلف استفاده کنید.

جهت اجتناب از failureهای پشت سر هم؛ از timeout ها؛ circuit breaker ها و bulk-ahead ها استفاده کنید. مایکروسرویس ها به شدت نسبت به اشکالات کوچک حساس می باشد؛ و باید حتما رویکردهایی جهت مواجه با این مشکلات داشت.

خلاصه:

بطور خلاصه باید گفت که هر چند در مایکروسرویس ما با سرویس های خود مختار و غیر وابسته به هم سروکار داریم که ساختار داخلی هر سرویس از دید سایر سرویس ها پنهان می باشد؛ و اینکه مایکروسرویس تاکید زیادی بر عدم وابستگی بر تکنولوژی خاص یا زبان برنامه نویس خاصی دارد؛ در عمل اما این به معنای آزادی کامل نیست. قطعا ما نیاز به اعمال استانداردهایی مناسب برای جنبه های مختلف این معماری داریم؛ و باید مایکروسرویس های مختلف از این استانداردهای پیروی کنند. نکته ی مهم در اینجا این می باشد؛ این استاندارد سازی به هیچ وجه به معنای محدود کردن ساختار داخلی سرویس های نمی باشد. مهمترین جنبه ی استاندارد سازی مربوط می شود به انتخاب Integration Style های مناسب جهت یکپارچه سازی این سرویس ها.

 

 

 

درباره ی masoud@admin

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

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

ملزومات مایکروسرویس آقای مارتین فاولر مقاله ای تحت عنوان MicroservicePrerequisites دارند که در اون به بررسی یک …

Microservices: Lessons from the Frontline

خانم ژامک دهقانی از مشاورین ارشد thoughtworks  و با نگاه و تمرکز بر روی معماری سیستم …

پاسخ دهید

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

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

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

پیوستن بستن