مدتها بود که می خواستم مقاله ای در مورد معماری میکروسرویس بنویسم، اما دو چیز مانع من شد - هر چه بیشتر وارد این موضوع می شدم، بیشتر به نظرم می رسید که آنچه می دانم واضح است و آنچه نمی دانم. دانستن نیاز به مطالعه و مطالعه دارد. از سوی دیگر، من فکر می کنم که در حال حاضر چیزی برای بحث در میان مخاطبان گسترده وجود دارد. بنابراین نظرات جایگزین استقبال می شود.
قانون کانوی و رابطه بین تجارت، سازمان و سیستم اطلاعاتی
یک بار دیگر به خودم اجازه می‌دهم نقل کنم:
هر سازمانی که سیستمی را طراحی کند (به معنای وسیع) طرحی دریافت خواهد کرد که ساختار آن ساختار تیم های آن سازمان را تکرار می کند.
- ملوین کانوی، 1967
به نظر من، این قانون بیشتر به امکان سنجی سازماندهی یک تجارت مربوط می شود تا مستقیماً به سیستم اطلاعاتی. بگذارید با یک مثال توضیح دهم. فرض کنید یک فرصت تجاری نسبتاً پایدار با یک چرخه عمر به اندازه ای داریم که سازماندهی یک شرکت منطقی است (این یک اشتباه تایپی نیست، اما من واقعاً این اصطلاحی را که من دزدیده ام دوست دارم) طبیعتاً سیستم پشتیبانی از این تجارت از نظر سازمانی و فرآیندی با این تجارت مطابقت خواهد داشت.
جهت گیری تجاری سیستم های اطلاعاتی
بگذارید با یک مثال توضیح دهم. فرض کنید یک فرصت تجاری برای سازماندهی کسب و کار فروش پیتزا وجود دارد. در نسخه V1 (اجازه دهید آن را اطلاعات اولیه بنامیم)، این شرکت یک پیتزا فروشی، یک صندوق فروش و یک سرویس تحویل بود. این نسخه در شرایط تغییرات محیطی کم عمر طولانی داشت. سپس نسخه 2 جایگزین آن شد - پیشرفته تر و قادر به استفاده از یک سیستم اطلاعاتی در هسته خود برای تجارت با معماری یکپارچه. و در اینجا، به نظر من، به سادگی یک بی عدالتی وحشتناک در رابطه با یکپارچه ها وجود دارد - ظاهراً معماری یکپارچه با مدل کسب و کار دامنه مطابقت ندارد. بله، اگر اینطور بود، سیستم اصلاً نمی توانست کار کند - در تضاد با همان قانون کانوی و عقل سلیم. خیر، معماری یکپارچه کاملاً با مدل کسب و کار در این مرحله از توسعه کسب و کار سازگار است - البته منظور من مرحله ای است که سیستم قبلاً ایجاد و راه اندازی شده است. این یک واقعیت کاملاً شگفت‌انگیز است که صرف‌نظر از رویکرد معماری، هم معماری سرویس‌گرا نسخه 3 و هم معماری میکروسرویس نسخه N به یک اندازه خوب کار خواهند کرد. گرفتاری چیست؟
همه چیز در جریان است، همه چیز تغییر می کند، یا میکروسرویس ها وسیله ای برای مبارزه با پیچیدگی هستند؟
قبل از ادامه، اجازه دهید به برخی از تصورات غلط در مورد معماری میکروسرویس نگاهی بیندازیم.
طرفداران استفاده از رویکرد میکروسرویس اغلب استدلال می‌کنند که شکستن یکپارچه به میکروسرویس‌ها، رویکرد توسعه را با کاهش پایه کد خدمات فردی ساده‌تر می‌کند. به نظر من این گفته کاملاً مزخرف است. به طور جدی، تعامل آشکار در یک کد یکپارچه و همگن پیچیده به نظر می رسد؟ اگر واقعاً چنین بود، همه پروژه‌ها در ابتدا به‌عنوان ریز سرویس‌ها ساخته می‌شدند، در حالی که عمل نشان می‌دهد که مهاجرت از یکپارچه به میکروسرویس بسیار رایج‌تر است. پیچیدگی ناپدید نمی‌شود، بلکه به سادگی از ماژول‌های مجزا به رابط‌ها (اعم از گذرگاه‌های داده، RPC، APIها و سایر پروتکل‌ها) و سیستم‌های هماهنگ حرکت می‌کند. و این سخت است!
مزیت استفاده از پشته ناهمگن نیز مشکوک است. من استدلال نمی کنم که این نیز امکان پذیر است، اما در واقعیت به ندرت اتفاق می افتد (نگاه به آینده - این باید اتفاق بیفتد - بلکه بیشتر به عنوان یک نتیجه است تا یک مزیت).
چرخه عمر محصول و چرخه عمر خدمات
یک نگاه دیگر به نمودار بالا بیندازید. تصادفی نیست که من به کاهش چرخه عمر یک نسخه جداگانه از یک تجارت اشاره کردم - در شرایط مدرن، این تسریع در انتقال یک تجارت بین نسخه ها است که برای موفقیت آن تعیین کننده است. موفقیت یک محصول با سرعت آزمایش فرضیه های تجاری در آن تعیین می شود. و در اینجا، به نظر من، مزیت کلیدی معماری میکروسرویس نهفته است. اما به ترتیب برویم.
بیایید به مرحله بعدی در تکامل سیستم های اطلاعاتی برویم - به معماری سرویس گرا SOA. بنابراین، در یک نقطه خاص ما در محصول خود برجسته کردیم خدمات طولانی مدت - عمر طولانی به این معنا که هنگام جابجایی بین نسخه های یک محصول، این احتمال وجود دارد که چرخه عمر سرویس بیشتر از چرخه عمر نسخه بعدی محصول باشد. منطقی است که اصلاً آنها را تغییر ندهیم - ما آنچه اهمیت دارد سرعت انتقال به نسخه بعدی است. اما افسوس، ما مجبور هستیم که تغییرات دائمی در خدمات ایجاد کنیم - و در اینجا همه چیز برای ما کار می کند، اقدامات DevOps، کانتینرسازی و غیره - هر چیزی که به ذهن می رسد. اما اینها هنوز میکروسرویس نیستند!
میکروسرویس ها به عنوان وسیله ای برای مبارزه با پیچیدگی... مدیریت پیکربندی
و در اینجا می توانیم در نهایت به نقش تعیین کننده ریزسرویس ها برویم - این رویکردی است که مدیریت پیکربندی محصول را ساده می کند. با جزئیات بیشتر، عملکرد هر میکروسرویس دقیقاً عملکرد تجاری داخل محصول را مطابق مدل دامنه توصیف می کند - و اینها چیزهایی هستند که نه در یک نسخه کوتاه مدت، بلکه در یک فرصت تجاری طولانی مدت زندگی می کنند. و انتقال به نسخه بعدی محصول به معنای واقعی کلمه بدون توجه اتفاق می افتد - شما یک میکروسرویس و شاید فقط طرح تعامل آنها را تغییر می دهید / اضافه می کنید، و ناگهان خود را در آینده می یابید و رقبای گریان را پشت سر می گذارید که به پرش بین نسخه ها ادامه می دهند. یکپارچه های آنها اکنون تصور کنید که حجم نسبتاً زیادی از میکروسرویس ها با رابط های از پیش تعریف شده و قابلیت های تجاری وجود دارد. و شما می آیید و ساختار محصول خود را از میکروسرویس های آماده می سازید - به عنوان مثال، به سادگی با کشیدن یک نمودار. تبریک می گویم - شما یک پلت فرم دارید - و اکنون می توانید تجارت را برای خود جذب کنید. رویاها رویاها.
یافته ها
- معماری سیستم باید با چرخه عمر اجزای آن تعیین شود. اگر یک جزء در یک نسخه محصول زندگی می کند، هیچ فایده ای برای افزایش پیچیدگی سیستم با استفاده از رویکرد میکروسرویس وجود ندارد.
- معماری میکروسرویس باید بر اساس مدل دامنه باشد - زیرا فرصت تجاری طولانی ترین دامنه است
- شیوه‌های تحویل (روش‌های DevOps) و هماهنگ‌سازی یکی از مهم‌ترین موارد برای معماری میکروسرویس هستند - به این دلیل که افزایش نرخ تغییر مؤلفه‌ها باعث افزایش تقاضا برای سرعت و کیفیت تحویل می‌شود.
منبع: www.habr.com