19 سپتامبر در مسکو اولین جلسه موضوعی HUG (گروه کاربری Highload++) که به میکروسرویس ها اختصاص داشت. ارائه‌ای با عنوان «میکروسرویس‌های عملیاتی: اندازه مهم است، حتی اگر Kubernetes دارید» برگزار شد، که در آن ما تجربه گسترده فلانت در اجرای پروژه‌های با معماری میکروسرویس را به اشتراک گذاشتیم. اول از همه، برای همه توسعه دهندگانی که به استفاده از این رویکرد در پروژه فعلی یا آینده خود فکر می کنند مفید خواهد بود.
معرفی کردن (50 دقیقه، بسیار آموزنده تر از مقاله)، و همچنین عصاره اصلی آن به صورت متنی.
نکته: ویدئو و ارائه نیز در انتهای این پست موجود است.
معرفی
معمولاً یک داستان خوب یک شروع، یک طرح اصلی و یک راه حل دارد. این گزارش بیشتر شبیه یک پیش درآمد و در عین حال تراژیک است. همچنین مهم است که توجه داشته باشید که دید خارجی از میکروسرویس ها را فراهم می کند. بهره برداری.
من با این نمودار شروع می کنم، نویسنده آن (در سال 2015) مارتین فاولر:
این نشان می دهد که چگونه، در مورد یک برنامه یکپارچه که به یک ارزش خاص می رسد، بهره وری شروع به کاهش می کند. میکروسرویس ها از این جهت متفاوت هستند که بهره وری اولیه با آنها کمتر است، اما با افزایش پیچیدگی، کاهش کارایی برای آنها چندان محسوس نیست.
من برای مورد استفاده از Kubernetes به این نمودار اضافه می کنم:
چرا اپلیکیشن با میکروسرویس بهتر است؟ زیرا چنین معماری الزامات جدی را برای معماری مطرح می کند که به نوبه خود کاملاً توسط قابلیت های Kubernetes پوشش داده می شود. از سوی دیگر، برخی از این عملکرد برای یک مونولیت مفید خواهد بود، به ویژه به این دلیل که یکپارچه معمولی امروز دقیقاً یکپارچه نیست (جزئیات بعداً در گزارش ارائه خواهد شد).
همانطور که می بینید، نمودار نهایی (زمانی که هر دو برنامه یکپارچه و میکروسرویس در زیرساخت با Kubernetes هستند) تفاوت زیادی با نمودار اصلی ندارد. در ادامه در مورد برنامه های کاربردی با استفاده از Kubernetes صحبت خواهیم کرد.
میکروسرویس های مفید و مضر
و ایده اصلی اینجاست:
چه طبیعی معماری میکروسرویس؟ این باید مزایای واقعی را برای شما به ارمغان بیاورد و بازده کاری شما را افزایش دهد. اگر به نمودار برگردیم، اینجاست:
اگه بهش زنگ بزنی مفید، سپس در سمت دیگر نمودار وجود خواهد داشت زیان آور میکروسرویس ها (در کار اختلال ایجاد می کند):
بازگشت به "ایده اصلی": آیا اصلاً باید به تجربه خود اعتماد کنم؟ از ابتدای امسال من نگاه کردم 85 پروژه. همه آنها میکروسرویس نبودند (تقریباً یک سوم تا نیمی از آنها چنین معماری داشتند)، اما این هنوز تعداد زیادی است. ما (شرکت فلانت) به عنوان برون سپاری موفق به مشاهده انواع برنامه های کاربردی توسعه یافته هم در شرکت های کوچک (با 5 توسعه دهنده) و هم در شرکت های بزرگ (حدود 500 توسعه دهنده) هستیم. یک مزیت اضافه این است که ما شاهد زنده بودن و تکامل این برنامه ها در طول سال ها هستیم.
چرا میکروسرویس؟
به این سوال در مورد مزایای میکروسرویس وجود دارد از مارتین فاولر که قبلاً ذکر شد:
- مرزهای مدولار بودن مشخص
- استقرار مستقل؛
- آزادی انتخاب فناوری ها
من با معماران و توسعه دهندگان نرم افزار زیاد صحبت کرده ام و پرسیده ام که چرا به میکروسرویس نیاز دارند. و من لیستی از انتظارات آنها تهیه کردم. این چیزی است که اتفاق افتاد:
اگر برخی از نکات را "در احساسات" توصیف کنیم، آنگاه:
- مرزهای واضح ماژول ها: در اینجا ما یک مونولیت وحشتناک داریم و اکنون همه چیز به خوبی در مخازن Git مرتب می شود که در آن همه چیز "در قفسه ها" است ، گرم و نرم با هم مخلوط نمی شوند.
- استقلال استقرار: ما قادر خواهیم بود خدمات را به طور مستقل ارائه دهیم تا توسعه سریعتر انجام شود (مشاهده ویژگی های جدید به صورت موازی).
- استقلال توسعه: ما می‌توانیم این میکروسرویس را به یک تیم/توسعه‌دهنده و آن را به دیگری بدهیم که به لطف آن می‌توانیم سریعتر توسعه دهیم.
- боقابلیت اطمینان بیشتر: اگر تخریب جزئی اتفاق بیفتد (یک میکروسرویس از 20 سقوط)، آنگاه فقط یک دکمه از کار می افتد و سیستم به طور کلی به کار خود ادامه می دهد.
معماری میکروسرویس معمولی (مضر).
برای توضیح اینکه چرا واقعیت آن چیزی نیست که ما انتظار داریم، ارائه خواهم کرد جمعی تصویری از معماری میکروسرویس بر اساس تجربیات بسیاری از پروژه های مختلف.
یک مثال می تواند یک فروشگاه آنلاین انتزاعی باشد که قرار است با آمازون یا حداقل OZON رقابت کند. معماری میکروسرویس آن به شکل زیر است:
به دلایلی ترکیبی، این میکروسرویس ها بر روی پلتفرم های مختلف نوشته شده اند:
از آنجایی که هر میکروسرویس باید دارای استقلال باشد، بسیاری از آنها به پایگاه داده و حافظه پنهان خود نیاز دارند. معماری نهایی به شرح زیر است:
عواقب آن چیست؟
فاولر هم این را دارد - در مورد "پرداخت" برای استفاده از خدمات میکرو:
و خواهیم دید که آیا انتظارات ما برآورده شده است یا خیر.
مرزهای ماژول ها را پاک کنید...
اما واقعاً چند میکروسرویس باید تعمیر کنیم؟برای ارائه تغییر؟ آیا حتی می توانیم بفهمیم که چگونه همه چیز بدون ردیاب توزیع شده کار می کند (بالاخره، هر درخواستی توسط نیمی از میکروسرویس ها پردازش می شود)؟
یک الگو وجود دارد "و در اینجا معلوم شد که یک توده خاک توزیع شده است. برای تأیید این موضوع، در اینجا یک تصویر تقریبی از نحوه انجام درخواست ها آورده شده است:
استقلال استقرار ...
از نظر فنی، به دست آمده است: ما می توانیم هر میکروسرویس را به طور جداگانه ارائه کنیم. اما در عمل باید در نظر داشته باشید که همیشه منتشر می شود بسیاری از میکروسرویس ها، و باید در نظر بگیریم ترتیب عرضه آنها. در یک راه خوب، ما معمولاً باید در یک مدار جداگانه آزمایش کنیم که آیا ما نسخه را به ترتیب صحیح اجرا می کنیم یا خیر.
آزادی انتخاب تکنولوژی...
او است. فقط به یاد داشته باشید که آزادی اغلب به بی قانونی محدود می شود. در اینجا بسیار مهم است که فناوری ها را فقط برای "بازی کردن" با آنها انتخاب نکنید.
استقلال توسعه ...
چگونه یک حلقه تست برای کل برنامه (با این همه مؤلفه) ایجاد کنیم؟ اما همچنان باید آن را به روز نگه دارید. همه اینها به این واقعیت منجر می شود که تعداد واقعی مدارهای تست، که در اصل می توانیم آن را داشته باشیم، به حداقل می رسد.
در مورد استقرار همه اینها به صورت محلی چطور؟... معلوم می شود که اغلب توسعه دهنده کار خود را به طور مستقل انجام می دهد، اما "به صورت تصادفی"، زیرا او مجبور است منتظر بماند تا مدار برای آزمایش آزاد شود.
مقیاس بندی جداگانه ...
بله، اما در حوزه DBMS استفاده شده محدود است. در مثال معماری داده شده، Cassandra مشکلی نخواهد داشت، اما MySQL و PostgreSQL مشکلی خواهند داشت.
Боقابلیت اطمینان بیشتر...
نه تنها شکست یک میکروسرویس در واقعیت اغلب عملکرد صحیح کل سیستم را مختل می کند، بلکه یک مشکل جدید نیز وجود دارد: ساختن هر میکروسرویس مقاوم در برابر خطا بسیار دشوار است. از آنجایی که میکروسرویس ها از فناوری های مختلفی استفاده می کنند (memcache، Redis و غیره)، برای هر کدام باید در مورد همه چیز فکر کنید و آن را پیاده سازی کنید، که البته ممکن است، اما به منابع عظیمی نیاز دارد.
قابلیت اندازه گیری بار ...
این واقعا خوبه.
"سبک بودن" میکروسرویس ها...
ما نه تنها بزرگ داریم سربار شبکه (درخواست‌ها برای DNS در حال افزایش است و غیره)، اما همچنین به دلیل سوالات فرعی زیادی که شروع کردیم داده های تکراری (کش های ذخیره سازی)، که منجر به حجم قابل توجهی از ذخیره سازی شد.
و در اینجا نتیجه برآورده شدن انتظارات ما است:
اما این همه ماجرا نیست!
زیرا:
- به احتمال زیاد ما به یک اتوبوس پیام نیاز خواهیم داشت.
- چگونه در زمان مناسب یک نسخه پشتیبان تهیه کنیم؟ تنها واقعی گزینه خاموش کردن ترافیک برای این است. اما چگونه می توان این کار را در تولید انجام داد؟
- اگر ما در مورد حمایت از چندین منطقه صحبت می کنیم، سازماندهی پایداری در هر یک از آنها یک کار بسیار پر زحمت است.
- مشکل ایجاد تغییرات متمرکز به وجود می آید. به عنوان مثال، اگر ما نیاز به به روز رسانی نسخه PHP داشته باشیم، باید به هر مخزن متعهد شویم (و ده ها مورد از آنها وجود دارد).
- رشد در پیچیدگی عملیاتی، غیرمنتظره، تصاعدی است.
با این همه چه باید کرد؟
با یک برنامه یکپارچه شروع کنید. تجربه فاولر تقریباً تمام برنامه‌های میکروسرویس موفق به‌عنوان یک مونولیت شروع شدند که خیلی بزرگ شد و سپس شکست. در عین حال، تقریباً تمام سیستم هایی که از همان ابتدا به عنوان میکروسرویس ساخته شده اند دیر یا زود با مشکلات جدی مواجه شدند.
یک فکر ارزشمند دیگر این است که برای موفقیت یک پروژه با معماری میکروسرویس باید خیلی خوب بدانید و حوزه موضوعی و نحوه ساخت میکروسرویس ها. و بهترین راه برای یادگیری یک حوزه موضوعی ساختن یکپارچه است.
اما اگر در حال حاضر در این وضعیت باشیم چه؟
اولین قدم برای حل هر مشکلی این است که با آن موافق باشید و درک کنید که یک مشکل است و ما دیگر نمی خواهیم رنج بکشیم.
اگر در مورد یک مونولیت بیش از حد رشد کرده (زمانی که فرصت خرید منابع اضافی برای آن تمام شده است)، آن را قطع کنیم، در این مورد داستان مخالف مشخص می شود: زمانی که ریز خدمات بیش از حد دیگر کمکی نمی کند، بلکه مانع می شود - اضافی را قطع کرده و بزرگ کنید!
به عنوان مثال، برای تصویر جمعی مورد بحث در بالا ...
از شر مشکوک ترین میکروسرویس ها خلاص شوید:
همه میکروسرویس های مسئول تولید فرانت اند را ترکیب کنید:
... در یک میکروسرویس، نوشته شده به یک زبان/چارچوب (مدرن و معمولی، همانطور که خودتان فکر می کنید):
این یک ORM (یک DBMS) و ابتدا چند برنامه خواهد داشت:
... اما به طور کلی می توانید خیلی بیشتر را به آنجا منتقل کنید و نتیجه زیر را بگیرید:
علاوه بر این، در Kubernetes همه اینها را در نمونه‌های جداگانه اجرا می‌کنیم، به این معنی که هنوز می‌توانیم بار را اندازه‌گیری کنیم و آنها را جداگانه مقیاس کنیم.
به طور خلاصه
به تصویر بزرگتر نگاه کن. اغلب، همه این مشکلات در مورد میکروسرویس ها به این دلیل به وجود می آیند که شخصی وظیفه خود را انجام می دهد، اما می خواهد "با میکروسرویس ها بازی کند".
در کلمه "microservices" قسمت "micro" اضافی است.. آنها "میکرو" هستند فقط به این دلیل که کوچکتر از یک تک سنگ بزرگ هستند. اما آنها را چیز کوچکی در نظر نگیرید.
و برای فکر نهایی، اجازه دهید به نمودار اصلی برگردیم:
یادداشتی روی آن نوشته شده است (بالا سمت راست) به این واقعیت خلاصه می شود که مهارت های تیمی که پروژه شما را می سازد همیشه اولیه است - آنها نقش کلیدی در انتخاب شما بین میکروسرویس ها و یکپارچه خواهند داشت. اگر تیم مهارت کافی نداشته باشد، اما شروع به ساخت میکروسرویس کند، داستان قطعاً کشنده خواهد بود.
فیلم ها و اسلایدها
ویدئویی از سخنرانی (50 دقیقه؛ متأسفانه احساسات بی شمار بازدیدکنندگان را که تا حد زیادی حال و هوای گزارش را تعیین می کند، منتقل نمی کند، اما اینطور است):
ارائه گزارش:
PS
گزارش های دیگر در وبلاگ ما:
- «» (دیمیتری استولیاروف؛ 28 مه 2018 در RootConf);
- «» (دیمیتری استولیاروف؛ 7 نوامبر 2017 در HighLoad++);
- «» (دیمیتری استولیاروف؛ 6 ژوئن 2017 در RootConf);
- «» (دیمیتری استولیاروف؛ 8 نوامبر 2016 در HighLoad++);
- «» (دیمیتری استولیاروف؛ 31 مه 2016 در RootConf).
همچنین ممکن است به انتشارات زیر علاقه مند باشید:
- «"؛
- «"؛
- «'.
منبع: www.habr.com