خرد متعارف موعظه می کند که با یکپارچه شروع می شود. این وسوسه به ویژه در هنگام شروع کار با یک تیم لاغر قوی است روی ضرب الاجل های تنگ اما آیا عقل متعارف همیشه درست است؟ دوست خوبم داربی فری اخیراً پس از به عهده گرفتن نقش جدید خود به عنوان سرپرست مهندسی پلتفرم Sr. یک پروژه سبز فیلد را آغاز کرد. گاموت. علیرغم اینکه کار را با یکپارچه در شرکت قبلی خود آغاز کرد شکم، او کشف کرد که (در شرایط مناسب) شروع با یکپارچه همیشه بهترین راه برای رفتن نیست.

در Belly، داربی و تیمش یکپارچگی خود را به یک معماری میکروسرویس نسبتاً بزرگ تقسیم کردند. آنها موفق شدند آن را به مکان خوبی برسانند، اما تنها پس از ماه‌ها آزمایش و مصیبت که به میکروسرویس‌ها مهاجرت کردند. با این تجربه تازه در ذهنش، او به پروژه جدید خود در Gamut کمی محتاط تر از خدمات میکرو نزدیک شد:

من به طور قطعی عضو تیم مونولیت بودم. (من فکر کردم) بیایید یک برنامه واحد بسازیم و اگر شروع به احساس درد کردیم بعداً چیزها را از هم جدا کنیم.” در حالی که این یک پروژه گرین فیلد بود، تیم داربی کوچک بود و او جدول زمانی تهاجمی داشت، بنابراین روی سطح، یکپارچه مانند انتخاب بدیهی به نظر می رسید. “(اما با این پروژه جدید)، من مشتاق بودم که اشتباهات گذشته را تکرار نکنم.”

و با آن، او با تصمیمی مواجه شد که همه ما با آن دست و پنجه نرم می کنیم، آیا باید با یکپارچه یا میکروسرویس شروع کنیم و چگونه تصمیم بگیریم؟

درک انتخاب ها

برای تصمیم گیری بین این دو، ابتدا باید منظورمان از «یکپارچه» و «ریز سرویس» را مشخص کنیم.

Zachary Crockett، CTO در ذره به من گفت که «معماری های سیستم دروغ می گویند روی یک طیف… هنگام بحث در مورد ریزسرویس ها، مردم تمایل دارند تمرکز کنند روی یک سر آن طیف: بسیاری از برنامه های کوچک که پیام های زیادی را به یکدیگر ارسال می کنند. در انتهای دیگر طیف، شما یک تک سنگ غول پیکر دارید که کارهای زیادی انجام می دهد. برای هر سیستم واقعی، بسیاری از معماری‌های سرویس‌گرا بین این دو حد وجود دارد.

تعریف یکپارچه

یک برنامه یکپارچه به عنوان یک واحد واحد و یکپارچه ساخته شده است. غالباً یک یکپارچه از سه بخش تشکیل شده است: یک پایگاه داده ، یک رابط کاربری طرف مشتری (متشکل از صفحات HTML و/یا جاوا اسکریپت در حال اجرا در یک مرورگر) و یک برنامه سمت سرور. برنامه سمت سرور درخواست های HTTP را انجام می دهد ، منطق خاص دامنه را اجرا می کند ، داده ها را از پایگاه داده بازیابی و به روز می کند و نماهای HTML را برای ارسال به مرورگر جمع می کند.

در یکپارچه، منطق برنامه سمت سرور، منطق سمت سرویس گیرنده جلویی، کارهای پس‌زمینه، و غیره، همه در یک پایگاه کد عظیم تعریف می‌شوند. نتیجه: اگر توسعه‌دهندگان می‌خواهند تغییرات یا به‌روزرسانی‌هایی ایجاد کنند، باید کل پشته را یک‌باره بسازند و مستقر کنند.

برخلاف آنچه ممکن است فکر کنید، یکپارچه یک معماری قدیمی نیست که ما باید آن را در گذشته رها کنیم. در شرایط خاص، یکپارچه ایده آل است. استیون چروینسکی، رئیس مهندسی در اسکایلر و کارمند سابق Google توضیح داد که از آنجا که تیم وی در Scaylr کوچک بود ، یک برنامه یکپارچه در مقایسه با تقسیم همه چیز به میکروسرویس قابل کنترل تر بود: “(در روزهای ابتدایی Scaylr) حتی اگر ما این تجربیات مثبت را در استفاده از میکروسرویس ها در اختیار داشتیم گوگل، ما مسیری (برای یکپارچه) رفتیم زیرا داشتن یک سرور یکپارچه به معنای کار کمتر برای ما به عنوان دو مهندس است.

هنگام در نظر گرفتن یک معماری یکپارچه، تیم شما باید موارد زیر را در نظر بگیرد:

مزایای یکپارچه

• نگرانی های بین بخشی کمتر: مهمترین مزیت معماری یکپارچه این است که بیشتر برنامه ها به طور معمول دارای تعداد زیادی نگرانی متقابل مانند ورود به سیستم ، محدود کردن نرخ و ویژگی های امنیتی چنین مسیرهای حسابرسی و محافظت از DOS هستند. وقتی همه چیز از طریق یک برنامه اجرا می شود، آسان است hook تا مولفه های آن نگرانی های مقطعی.
• سربار عملیاتی کمتر: داشتن یک برنامه (بزرگ) به این معنی است که فقط یک برنامه وجود دارد که باید ثبت، نظارت و آزمایش را برای آن تنظیم کنید. همچنین استقرار آن معمولاً پیچیدگی کمتری دارد.
• کارایی: همچنین می تواند مزایای عملکردی داشته باشد، زیرا دسترسی به حافظه مشترک سریعتر از بینprocess ارتباطات (IPC).

معایب یکپارچه

• محکم جفت شده: خدمات برنامه یکپارچه تمایل دارند که با تکامل برنامه ، محکم و درگیر شوند ، و جداسازی خدمات برای اهداف مانند مقیاس گذاری مستقل یا قابلیت حفظ کد دشوار است.
• درک سخت تر: معماری های یکپارچه نیز درک آن بسیار سخت تر است ، زیرا ممکن است وابستگی ها ، عوارض جانبی و جادویی وجود داشته باشد که هنگام نگاه به یک سرویس یا کنترل کننده خاص آشکار نیست.

تعریف میکروسرویس ها

هیچ چیز ذاتاً «میکرو» در مورد میکروسرویس ها فی نفسه وجود ندارد. در حالی که آنها معمولا کوچکتر از یکپارچه متوسط ​​هستند، لازم نیست کوچک باشند. برخی چنین هستند، اما اندازه نسبی است و هیچ استانداردی برای واحد اندازه گیری در بین سازمان ها وجود ندارد.

سبک معماری میکروسرویس رویکردی برای توسعه یک برنامه کاربردی به عنوان مجموعه ای از خدمات کوچک است که هر کدام به تنهایی اجرا می شوند. process و ارتباط با مکانیسم های سبک وزن، اغلب یک API منبع HTTP. این خدمات بر اساس قابلیت های تجاری ساخته شده اند و به طور مستقل توسط ماشین آلات استقرار کاملاً خودکار قابل استقرار هستند. حداقل مدیریت متمرکز این خدمات وجود دارد.

هنگام در نظر گرفتن میکروسرویس ها، تیم شما باید به خاطر داشته باشد:

طرفداران میکروسرویس

• سازماندهی بهتر: معماری های میکروسرویس به طور معمول سازماندهی بهتر هستند ، زیرا هر میکروسرویس شغل بسیار خاصی دارد و به کار سایر مؤلفه ها مربوط نمی شود.
• جدا شده: خدمات جداشده نیز برای ارائه اهداف برنامه های مختلف (به عنوان مثال ، خدمت به مشتری های وب و API عمومی) آسان تر و پیکربندی مجدد است. آنها همچنین امکان تحویل سریع و مستقل قطعات جداگانه را در یک سیستم بزرگتر و یکپارچه فراهم می کنند.
• کارایی: در شرایط مناسب، میکروسرویس ها نیز بسته به عملکرد، می توانند مزایای عملکردی داشته باشند روی روش سازماندهی آنها زیرا امکان جداسازی سرویس های داغ و مقیاس بندی آنها مستقل از بقیه برنامه وجود دارد.
• اشتباهات کمتر: میکروسرویس ها با ایجاد مرزی سخت بین بخش های مختلف سیستم شما، توسعه موازی را امکان پذیر می کنند. با انجام این کار ، شما آن را سخت تر یا حداقل سخت تر می کنید تا کار اشتباهی انجام دهید: یعنی اتصال قطعاتی که نباید به هم وصل شوند ، و اتصال خیلی محکم آنهایی که باید به هم وصل شوند.

معایب میکروسرویس ها

• نگرانی های میان بخشی در هر سرویس: همانطور که در حال ساخت یک معماری میکروسرویس جدید هستید، احتمالاً نگرانی های متقابل زیادی را کشف خواهید کرد که در زمان طراحی آن ها را پیش بینی نمی کردید. شما یا باید هزینه های سربار ماژول های جداگانه را برای هر نگرانی متقاطع (یعنی آزمایش) متحمل شوید، یا نگرانی های مقطعی را در یک لایه سرویس دیگر که تمام ترافیک از طریق آن هدایت می شود، محصور کنید. در نهایت، حتی معماری‌های یکپارچه تمایل دارند ترافیک را از طریق یک لایه خدمات بیرونی برای نگرانی‌های متقاطع هدایت کنند، اما با یک معماری یکپارچه، ممکن است هزینه آن کار تا زمانی که پروژه بالغ‌تر شود به تأخیر بیاندازد.
• سربار عملیاتی بالاتر: میکروسرویس ها اغلب مستقر می شوند روی ماشین‌های مجازی یا کانتینرهای خودشان، باعث گسترش کار درگیری VM می‌شوند. این وظایف اغلب به صورت خودکار با container ابزارهای مدیریت ناوگان

تصمیم گیری درست برای سازمان شما

جوانب مثبت و منفی می تواند یک چارچوب کلی برای بحث در مورد مزایای احتمالی و اشکالات یک معماری نسبت به دیگری در هنگام نشستن با تیم خود فراهم کند. برای استفاده مؤثر از این اصول کلی ، من با ده ها CTO مصاحبه کردم تا هنگام تصمیم گیری در مورد آنچه برای سازمان شما بهتر است ، ملاحظات را برای شما ایجاد کنم.

آیا در منطقه ای آشنا هستید؟

داربی و تیمش در گالوت توانستند مستقیماً وارد خدمات میکروسرویس شوند زیرا او با سیستم عامل های تجارت الکترونیک تجربه داشت و شرکت وی دانش زیادی در مورد نیازها و خواسته های مشتریان خود داشت. اگر در مسیری ناشناخته حرکت می کرد روی از سوی دیگر، یکپارچه ممکن است در واقع گزینه ایمن تر بوده باشد.

آیا تیم شما آماده است؟

آیا تیم شما تجربه ای در زمینه میکروسرویس ها دارد؟ اگر تعداد تیم خود را در سال آینده چهار برابر کنید، آیا میکروسرویس ها برای آن موقعیت ایده آل هستند؟ ارزیابی این ابعاد از تیم شما برای موفقیت پروژه شما بسیار مهم است.

اگر تیم شما آماده شده است ، شروع با استفاده از میکروسرویس عاقلانه است زیرا به شما امکان می دهد تا از همان ابتدا به ریتم توسعه در یک محیط میکروسرویس عادت کنید.

زیرساخت شما چطور است؟

در واقع، شما به زیرساخت های مبتنی بر ابر نیاز دارید تا ریزسرویس ها برای پروژه شما کار کنند.

(قبلاً) می‌خواهید با یک monolith شروع کنید زیرا می‌خواهید یک سرور پایگاه داده را مستقر کنید. این ایده که باید یک سرور پایگاه داده برای هر میکروسرویس منفرد راه اندازی کرد و سپس آن را بزرگ کرد، یک کار بزرگ بود. دیوید استراوس، مدیر ارشد فناوری، فقط یک سازمان بزرگ و با دانش فنی می تواند این کار را انجام دهد پانتئون برای من توضیح داد “در حالی که امروز با خدماتی مانند Google Cloud و Amazon AWS ، شما گزینه های زیادی برای استقرار چیزهای کوچک بدون نیاز به داشتن لایه پایداری برای هر یک دارید.”

ریسک کسب و کار را ارزیابی کنید

ممکن است فکر کنید که میکروسرویس‌ها راه درستی است که می‌توانید به‌عنوان یک استارت‌آپ هوشمند با فناوری با جاه‌طلبی‌های بالا بروید. اما ریزسرویس ها یک ریسک تجاری هستند. دیوید اشتراوس توضیح داد:

بسیاری از تیم ها در ابتدا پروژه خود را بیش از حد ساخته اند. همه می‌خواهند فکر کنند استارت‌آپ‌شان تک‌شاخ بعدی خواهد بود و بنابراین، باید همه چیز را با میکروسرویس‌ها یا زیرساخت‌های بسیار مقیاس‌پذیر دیگر بسازند. اما این معمولاً اشتباه است، تقریباً همیشه.»

او رفت روی برای گفتن این نکته ، در این موارد ، مناطقی که فکر می کنید برای مقیاس کردن نیاز دارید احتمالاً قسمت هایی نیستند که ابتدا به مقیاس نیاز داشته باشند ، و این منجر به تلاش نادرست حتی برای سیستمهایی که نیاز به مقیاس دارند ، منجر می شود.

زمینه اهمیت دارد

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

چه زمانی باید با یک تک سنگ شروع کرد

در اینجا چند سناریو وجود دارد که نشان می دهد باید پروژه بعدی خود را با استفاده از معماری یکپارچه شروع کنید:

• تیم شما در مرحله تاسیس است: تیم شما کوچک است، بین 2 تا 5 عضو، و بنابراین قادر به مقابله با معماری میکروسرویس های گسترده تر و بالا نیست.
• شما در حال ساختن یک محصول اثبات نشده یا اثبات مفهوم هستید: آیا شما یک محصول اثبات نشده در بازار می سازید؟ اگر این یک ایده جدید باشد، احتمالاً در طول زمان تغییر می کند و تکامل می یابد، بنابراین یکپارچه ایده آل است تا امکان تکرار سریع محصول را فراهم کند. همین امر در مورد اثبات مفهومی نیز صدق می کند که در آن هدف شما فقط یادگیری هر چه سریعتر بیشتر است، حتی اگر در نهایت آن را دور بریزید.
• شما هیچ تجربه میکروسرویس ندارید: اگر تیم شما هیچ تجربه قبلی با میکروسرویس ها نداشته باشد، مگر اینکه بتوانید ریسک یادگیری را توجیه کنید.روی مگس» در چنین مرحله اولیه، احتمالاً نشانه دیگری است که برای شروع باید به یکپارچه بچسبید.

چه زمانی باید با میکروسرویس ها شروع کرد

در اینجا چند سناریو وجود دارد که نشان می دهد باید پروژه بعدی خود را با استفاده از میکروسرویس ها شروع کنید:

• شما به تحویل سریع و مستقل خدمات نیاز دارید: میکروسرویس ها امکان تحویل سریع و مستقل قطعات جداگانه را در یک سیستم بزرگتر و یکپارچه فراهم می کنند. توجه داشته باشید، بسته به روی اندازه تیم شما، مشاهده دستاوردهای ارائه خدمات در مقایسه با شروع با یکپارچه ممکن است زمان ببرد.
• بخشی از پلتفرم شما باید بسیار کارآمد باشد: اگر کسب و کار شما در حال پردازش فشرده پتابایت حجم گزارش است، احتمالاً می خواهید آن سرویس را به زبانی بسیار کارآمد (به عنوان مثال C++) بسازید در حالی که داشبورد کاربری شما ممکن است ساخته شده باشد. Ruby روی ریل.
• شما برای رشد تیم خود برنامه ریزی می کنید: شروع با میکروسرویس‌ها، تیم شما را از ابتدا به توسعه در سرویس‌های کوچک مجزا عادت می‌دهد، و داشتن تیم‌هایی که بر اساس مرزهای سرویس از هم جدا شده‌اند، افزایش مقیاس تیم خود را در مواقعی که نیاز دارید بدون ارائه پیچیدگی نمایی بسیار آسان‌تر می‌کند.

مونولیت مرده نیست و میکروسرویس ها برای هر زمینه ای مناسب نیستند. از وسوسه فرو رفتن در میکروسرویس ها صرفاً به دلیل انفجار در رشد آنها اجتناب کنید. در عوض، از خرد CTOهایی که قبلا آمده بودند استفاده کنید تا به دقت در نظر بگیرید که چه معماری برای شما معنادارتر است.