خانه / microservices / microservices

microservices

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

مقدمه:

مایکروسرویس به عنوان جدیدترین معماری طراحی سیستم های نرم افزاری در چند سال گذشته به عنوان مهمترین و محبوب روش طراحی معماری سیستم های نرم افزارها شناخته شده, بطوریکه در سال 2014 این مفهوم به موضع داغ و پر بحث سال تبدیل شده بود. در این چند سال بحث ها, مقالات و صحبت های بسیار بسیار زیادی در باب این مفهوم گفته و شنیده شده, و در شرکتهای بزرگی از جمله Netflix و Amazon بصورت بسیار گسترده مورد استفاده قرار گرفته شد. آقای مارتین فاولر به عنوان یکی از شناخته شده ترین و معروف ترین افراد در حوزه نرم افزار در سال 2014 به همراه همکارشون آقای جیمز لویز مقاله ای مفصل در باب مایکروسرویس ها به رشته ی تحریر در آوردند.

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

 

تعریفی از این اصطلاح معماری جدید

اصطلاح “معماری مایکروسرویس” از چند سال پیش جهت توصیف یک روش خاص جهت طراحی برنامه های نرم افزاری به عنوان مجموعه ای از سرویس های قابل نصب مستقل؛ بسیار رشد کرده و مورد استفاده قرار گرفت. در حالی که تعریف و توضیح دقیقو مفیدی از این متد طراحی وجود ندارد؛ خصوصیات معین مشترکی پیرامون سازمان؛ میان توانایی کسب و کار؛ نصب خودکار؛ هوشمندی در نقاط پایانی-endpoint- و کنترل غیر متمرکز زبانها  و داده وجود دارد.

“مایکروسرویس ها”-اصطلاح جدید دیگری در جاده های شلوغ معماری نرم افزار. هر چند تمایل طبیعی ما نگاه کردن و قبول کردن موارد این چنینی با یک نگاه اجمالی و سطحی است؛ این اصطلاح فنی یک روش طراحی سیستم های نرم افزاری را توصیف می کند که ما آن را بسیار بسیار جذاب دیدیم. پروژه های بسیاری را در چند سال گذشته بر اساس این متد دیدیم؛ و نتیجه تا به اینجا مثبت بوده است؛ بنابراین برای بسیاری از همکاران ما؛ این مورد به عنوان روش و متد پیش فرض طراحی برنامه های سازمانی در نظر گرفته می شود. متاسفانه؛ آنقدرها اطلاعات وجود ندارد؛ که مشخص کند روش و معماری مایکروسرویس چیست و اینکه به چه صورت باید آن را انجام داد وجود ندارد.

مختصرا؛ روش معماری مایکروسرویس[1] رویکردی است جهت توسعه ی یک برنامه منفرد بر اساس مجموعه ای از سرویس های کوچک؛ که هر کدام بر روی پروسه ی خود اجرا می شوند؛ و بر اساس مکانیزم های سبک وزن(lightweight) -معمولا یک HTTP resource API؛ با یکدیگر ارتباط دارند. این سرویس ها بر اساس نیازمندی کسب و کار ایجاد می شوند؛ و می تواند توسط ساختارهای دیپلوی کاملا اتوماتیک شده؛ بصورت مستقل از سایر سرویس ها دیپلوی شود. همچنین کمترین میزان مدیریت متمرکز درباره ی این سرویس ها که ممکن است با زبان های برنامه نویسی متفاوتی نوشته شده و از تکنولوژی ذخیره سازی داده ی مختلفی استفاده کنند؛ وجود دارد.

جهت شروع توصیف روش مایکروسرویس؛ مقایسه آن با روش یکپارچه-monolithic- می تواند مفید واقع شود: یک برنامه ی یکپارچه بصورت یک واحد منفرد ایجاد می شود. برنامه های سازمانی بصورت متداول در سه بخش اصلی توسعه داده می شوند؛ یک بخش رابط کاربری سمت کلاینت(شامل صفحات HTML و جاوا اسکریپت که بر روی مرورگر روی ماشین کاربر اجرا می شود)؛ یک دیتابیس(شامل تعداد زیادی جدول که معمولا بصورت سیستم  مدیریت دیتابیس رابطه ای هستند), و برنامه سمت سرور. برنامه ی سمت سرور درخواست های HTTP را مدیریت کرده؛ منطق لایه تجاری را اجرا؛ دیتا را از دیتابیس بیرون کشیده و بهنگام می کند, و viewهای HTML مناسب را جهت ارسال به سمت مرور گر؛انتخاب و پر می کند. این برنامه سمت سرور یک مانولیت-یک واحد منطقی قابل اجرا- می باشد[2]. هر تغییری در سیستم نیازمند بیلد و انتشار نسخه ی جدیدی از برنامه ی سمت سرور می باشد.

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

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

تصویر 1: مونولیت و مایکروسرویس

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

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

خصوصیات یک معماری مایکروسرویس

ما نمی توانیم بگوییم که یک تعریف رسمی از روش معماری مایکروسرویس وجود دارد؛ اما می توانیم تلاش کنیم مواردی را که به عنوان خصوصیات مشترک معماری ها متناسب با این اصطلاح خاص می باشند, و ما آنرا که مشاهده کردیم توضیح دهیم. همانند هر تعریفی که نمایانگر ویژگی های مشترک هستند؛ همه ی معماری های مایکروسرویس تمامی این ویژگی ها را ندارند, اما می توان انتظار داشت؛ که اکثر معماری های مایکروسرویس این خصوصیات را نمایش دهند. علیرغم اینکه ما نویسنده ها؛ عضو های فعال مایکروسرویس هستیم و نه community غیرفعال ؛ قصد ما تلاش برای توضیح مواردی است که ما در کار خود می بینیم و در تلاش های مشابه با تیم هایی که می شناسیم(اتفاق می افتد-مترجم). بطور خاص قصد نداریم یک سری تعاریف را جهت تایید و اثبات آنها ارائه دهیم.

مولفه سازی(Componentization)از طریق سرویس ها

در این مدتی که ما در صنعت نرم افزار هستیم, یک تمایل و گرایش جهت ایجاد سیستم ها بوسیله ی سرهم بندی مولفه ها با یکدیگر مشاهده شده است، کاملا شبیه به روشی که می بینیم چیزها در دنیای فیزیکی ساخته می شوند. در چند دهه گذشته؛ پیشرفت های قابل چشمگیری با هوشمندی زیاد کتابخانه های مشترک که بخشی از اکثر پلت فرم های زبان هستند؛ مشاهده کردیم.

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

معماری های مایکروسرویس؛ از کتابخانه ها استفاده می کنند, اما روش اصلی آنها در مولفه سازی نرم افزار خود, شکستن آن به سرویس ها می باشد. ما کتابخانه ها را به عنوان مولفه هایی که درون یک برنامه پیوند خوردند و از طریق فراخوانی توابع درون حافظه-in-memory- صدا زده می شوند تعریف می کنیم ؛ در حالیکه سرویس ها مولفه های خارج از فرآیندی هستند که ارتباط میان آنها از طریق مکانیزم هایی شبیه درخواست وب سرویس؛ یا فراخوانی پروسیجر از راه دور انجام می شود. (این یک مفهوم متفاوت به یک آبجکت سرویس در بسیاری از برنامه های شی گرایی می باشد[3].)

یکی از دلایل اصلی برای استفاده از سرویس ها به عنوان مولفه ها(بجای کتابخانه ها) این است که سرویس ها بصورت مستقل قابلیت منشتر شدن را دارا می باشند. اگر شما برنامه ای دارید[4] که از کتابخانه بسیاری در یک فرآیند منفرد تشکیل شده؛ هر تغییری در یکی از مولفه ها منجر به این می شود که مجبور باشید کل  برنامه را مجدد منتشر نمائید. اما در صورتی که همان برنامه به چندین سرویس تقسیم شود؛ می توانید انتظار داشته باشید بسیاری از تغییرات یک سرویس منفرد؛ نیازمند این می باشد که فقط همان سرویس مجددا منتشر شود. و البته این مورد مطلق نیست, برخی تغییرات که منجر به تغییر اینترفیس سرویس می شود باعث تغییر در یکسری هماهنگی-coordination- می شود, اما کمک یک معماری مایکروسرویس خوب؛ کمینه نمودن این موارد از طریق مرزبندی های سرویس به هم پیوسته و مکانیزم های تکاملی در قراردادهای-contracts- سرویس می باشد.

از دیگر پیامدهای استفاده از سرویس ها به عنوان مولفه ها, ساده و واضح تر شدن اینترفیس مولفه است. اکثر زبان ها؛ مکانیزم های مناسبی برای تعریف صریح  Published Interface ندارند. و این فقط اسناد و قوانین هستند که کلاینت ها را از تخطی از کپسوله سازی مولفه ها منع می کنند؛ و این منجر به پیوستگی سخت و محکم بیش از حد مولفه ها خواهد شد. سرویس ها از موارد این چنینی با استفاده از مکانیزم های فراخوانی از راه دور صریح؛ جلوگیری خواهند کرد.

استفاده از سرویس ها به این طریق مشکلاتی را هم به همراه خواهند داشت. فراخوانی از راه دور به نسبت به فراخوانی های درون فرآیندی بسیار گران تر می باشد؛ و این API های راه دور نیاز می باشد که دانه درشت-coarse-grained- باشند که استفاده از آنها معمولا سختر و بد قلق می باشد. اگر شما نیاز دارید که تخصیص مسئولیت های میان مولفه ها از جمله؛ تغییر و جابجایی رفتار سرویس ها؛ را تغییر دهید؛ اینکار نسبت به هنگامی که شما مرزهای فرآیندی متقاطع و چند مرزی دارید(و مرزهای سرویس ها نسبت به حالت مایکروسرویس ها با وضوح و با دقت و شفافیت مشخص نشده است)؛ سخت تر خواهد بود.

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

سازماندهی شده پیرامون توانایی کسب و کار

هنگامی که به دنبال تقسیم یک برنامه بزرگ به بخش های ریز تر هستیم, معمولا مدیریت بر روی لایه های تکنولوژی تمرکز می کند, که منجر به تیم های UI؛ تیم های منطق سمت سرور؛ و تیم های دیتابیس می شود. هنگامی که تیم ها از طریق این خط ها از هم جدا شوند؛ حتی یک تغییر کوچک می تواند منجر به تقابل تیم ها شود که از زمان و بودجه تصویب شده تخطی خواهد کرد. یک تیم باهوش پیرامون این بهینه خواهد شد و برای حداقل یکی از دو ضرر و زیان چاق و چله می شود-فقط منطق را به برنامه ای ببرید که آنها به آن دسترسی دارند. به عبارت دیگر منطق در هرجایی. این یک مثالی از قانون Conway[5] در عمل می باشد.

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

–Melvyn Conway, 1967

 

 

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

شکل 3- محدوه های سرویس ها بوسیله ی مرزهای تیم تقویت می شود.

یکی از شرکت هایی که به این صورت سازمندهی شده است  www.comparethemarket.comمی باشد. تیم های چندوظیفه ای مسئولیت ایجاد و عملیاتی کردن هر محصول را بر عهده دارند و هر محصول به تعدادی سرویس منحصر به فرد که از طریق گذرگاه پیام (message bus) با هم ارتباط برقرار می کنند تقسیم می شوند.

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

محصولات نه پروژها

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

طرفداران مایکروسرویس تمایل به اجتناب از این مدل را دارند, و این تصور که تیم باید یک محصول را در کل حیات خود داشت باشد را در عوض ترجیح می دهند. یک الهام متداول در این باره نظریه Amazon است  “you build, you run it” که در آن بیان می شود؛ یک تیم تولید مسئولیت کامل برای محصول در ساخت را بر عهده دارند. این موجب می شود که برنامه نویس ها درباره ی اینکه به چه صورت نرم افزار آنها در محیط عمل می کند تعامل روزانه داشته و نیز تماس با کاربرانشان را نیز افزایش می دهند چون آنها حداقل مقداری بار مسئولیت پشتیبانی را نیز خواهند داشت.

ذهنیت محصول با اتصال به ظرفیت های کسب و کار گره خورده است. بجای نگاه کردن به نرم افزار به عنوان مجموعه ی عملیاتی که باید تکمیل شود؛ یک ارتباط دایمی و همیشگی وجود دارد که سوال این است که چگونه نرم افزار می تواند به کاربران برای بهبود توانایی کسب و کار کمک کند.

دلیلی وجود ندارد که آیا این رویکرد با برنامه های مانولیت امکان وقوع دارد یا خیر؛ اما خوشه های کوچکتر سرویس ها(سرویس های کوچکتر و سبک تر) می تواند ایجاد ارتباطات شخصی میان توسعه دهنده های سرویس با کاربران آنها را راحت تر کند.

نقاط پایانی-endpoints- هوشمند و خطوط لوله احمق-dumb pipes-

بهنگام ایجاد ساختار ارتباطی میان فرآیندهای متفاوت؛ محصولات و رویکردهای بسیاری را مشاهده می کنیم که هوشمندی بسیاری را به مکانیزم های ارتباطی خود هدایت می کند. یک مثال خوب از این مورد؛ گذرگاه سرویس سازمانی-Enterprise Service Bus(ESB)- می باشد, که محصولات ESB معمولا شامل تسهیلاتی کامل برای مسیریابی پیام ها؛ رقص آرائی؛ انتقال و اعمال نقش های کسب و کار می باشد.

جامعه مایکروسرویس رویکرد دیگری را ترجیح می دهد: نقاط پایانی هوشمند و خطوط لوله احمق. برنامه های ایجاد شده توسط مایکروسرویس ها تمایل دارند تا حد امکان غیر وابسته و به هم پیوسته باشند-انها منطق دامین خاص خود را دارند و از فیلترهای کلاسیک یونیکس عملکردی بیشتر دارند- درخواستی را دریافت کرده؛ منطق مناسب و متناسب را اعمال و پاسخ مورد نظر را تولید می کنند. اینها از طریق پروتوکل های ساده ی RESTish بجای پروتوکل های پیچیده ی WS-Choreography یاBPEL  یا ارکتسراسیون بوسلیه یک ابزار مرکزی؛ استفاده و هدایت می شوند.

دو پروتوکلی که بیشترین استفاده را دارند؛ HTTP request-response با API منابع و مسیچینگسبک وزن-lightweight messaging- هستند[6]. بهترین بیان از مورد اول این می باشد:

بخشی از وب باشید؛ نه پشت آن.

Lan Robinson

تیم های مایکروسرویس از پروتوکل ها و سرویس هایی که سرویس جهان گستر وب(و در گسترش بزرگتر, یونیکس) بر اساس آنها ایجاد شده است استفاده می کند. اغلب منابع مورد استفاده را می توان با تلاش بسیار کمی در بخشی از افراد توسعه دهنده و یا عملیاتی کش کرد.

رویکرد دوم معمولا پیام رسانی بر روی گذرگاه پیام سبک وزن است. زیرساخت انتخاب شده معمولا خاموش است(خاموش از این نظر که فقط به عنوان مسیریاب پیام استفاده می شود)- پیاده سازیهای ساده ای از جمله RabbitMQ یا ZeroMQ چیزی بیشتر از مهیا کردن محصول غیرهمزمان قابل اعتماد انجام نمی دهند- هوشمندی همچنان در نقاط پایانی که در سرویس ها پیام ها را تولید و استفاده می کنند, وجود دارد.

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

اداره غیر متمرکز

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

در تقسیم کردن مولفه های مانولیت به سرویس ها, ما یک انتخاب بهنگام ایجاد هر کدام از آنها داریم. شما می خواهید از Node.js برای بالا آوردن یک صفحه ی ساده ی گزارش استفاده کنید؟ به دنبال آن بروید. C++ برای یک مولفه ی نزدیک به زمان واقعی؟ عالی. شما می خواهید که به مجموعه دیتابیس متفاوتی که عملکرد بهتری در خواندن یک مولفه دارا می باشد تغییر کنید؟ ما تکنولوژی برای ایجاد مجدد آن داریم.

البته, فقط به این دلیل که شما می توانید چیزی را انجام دهید, به این معنی نیست که شما باید آنرا انجام دهید­- تقسیم بندی سیستم در این روش به این معنی است که شما این انتخاب را خواهید داشت.

تیم هایی که مایکروسرویس ها را ایجاد می کنند رویکردهای متفاوتی به استانداردها نیز دارند. بجای استفاده از مجموعه ای از استانداردهای از پیش تعیین شده که جایی بر روی کاغذ آورده شده, آنها ایده ی ایجاد ابزارهای مناسب و مفید را ترجیح می دهند که سایر توسعه دهنده ها از آن ابزارها جهت مرتفع نمودن مشکلات مشابه به روشی که آنها با آن مواجه شدند می توانند استفاده کنند. این ابزارها معمولا ماحصل پیاده سازی و اشتراک با یک گروه بزرگتر است, گاهی اما نه منحصرا با استفاده از یک مدل منبع باز. در حال حاضر git و github دو سیستم کنترل نسخه ی متداول جهت انتخاب هستند, شیوه های منبع باز بیشتر و بیشتر درون سازمان متدوال می شوند.

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

از نظر community مایکروسرویس, سربارها مخصوصا غیر جذاب هستند. این اما بدین معنی نیست که بگوییم community برای قراردادهای سرویس ها ارزشی قائل نیست. کاملا برعکس, تمایل برای آن بسیار بسیار زیاد است. این تنها بدین معنی است که آنها بدنبال روش متفاوت برای مدیریت این قراردادها هستند. الگوهایی شبیه Tolerant Reader و Consumer-Driven Contracts اغلب به مایکروسرویس ها اعمال می شوند. این ها به قراردادهای سرویس در توسعه شدن تدریجی مستقل کمک می کنند. اجرا کردن consumer driven contracts به عنوان بخشی از بیلد شما؛ اعتماد را بالا می برد و بازخوردهای سریع درباره اینکه آیا سرویس شما درحال کار می باشد, در اختیار قرار می دهد. ما تیمی را در استرالیا می شناسیم که آنها ایجاد سرویس های جدید را با  consumer driven contracts استفاده می کنند. آنها از ابزارهای ساده ای که به آنها اجازه می دهد قراردادی را برای سرویس تعریف کنند استفاده می کنند. سرویس سپس در نقطه ای بیلد خواهد شد که قراداد را ارضا کند-یک رویکرد زیبا که بهنگام ایجاد نرم افزار جدید از مسئله ی ‘YAGNI’[9] اجتناب می کند. این رویکردها و ابزارهای گسترش داده شده بر اساس آنها, با کمینه نمودن coupling میان سرویس ها؛ نیاز به مدیریت متمرکز را کاهش می دهد.

شاید اوج مدیریت غیرمتمرکز  build it / run it  باشد که معنی آن بوسلیه ی Amazon متداول شد. تیم ها برای تمام جوانب نرم افزاری که در حال ساخت آن هستند شامل عملیاتی بودن نرم افزار بصورت 24/7 مسئول هستند. اختیارات در این سطح از مسئولیت پذیری مطمئنا متداول نیست اما ما شرکت های بیشتر و بیشتری را می بینیم که مسئولیت را به تیم های توسعه محول می کنند. Netflix سازمان دیگری است که با این رویکرد منطبق شده است [11]. خواب بودن ساعت 3 صبح هر شب با پیچر خود یک انگیزه قوی برای تمرکز بر روی کیفیت, بهنگام نوشتن کدهایتان می باشد. این ایده ها بدور از مدل مدیریت متمرکز سنتی تا جایی که امکان دارد می باشد.

مدیریت داده غیر متمرکز

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

این مسئله میان برنامه ها متداول است, اما می تواند درون برنامه ها نیز اتفاق بیافتد, بخصوص وقتی که آن برنامه به مولفه های مجزایی تقسیم می شوند. یک تفکر مفید در این باره, تفکر  Bounded Context از Domain-Driven Design می باشد. DDD یک دامین پیچیده را به چندین Bounded Context تقسیم کرده و ارتباط میان آنها را نگاشت می کند. این فرآیند هم برای مانولیت و هم مایکروسرویس مفید می باشد, اما همانطور که در بخش توانایی کسب و کار توضیح دادیم؛ یک ارتباط و هم بستگی طبیعی میان سرویس ها و مرزهای context آن سرویس ها وجود دارد که به روشن و واضح شدن کمک می کند؛ یعنی تقویت جداسازی ها.

به همان خوبی غیر متمرکزسازی تصمیم ها درباره مدل ها, مایکروسرویس همچنان تصمیمات ذخیره سازی داده ها را نیز غیر متمرکز می کند. در حالی که مانولیت یک دیتابیس منطقی منفرد برای ذخیره سازی داده ها را ترجیح می دهد؛ سازمانها معمولا یک دیتابیس را برای تعداد خاصی از برنامه ها ترجیح می دهند-خیلی از این تصمیمات از گواهینامه های مدل های تجاری فروشنده مشتق می شوند. مایکروسرویس ها ترجیح می دهند که اجازه دهند که هر سرویس دیتابیس خاص خود را داشته باشد, حتی نمونه های متفاوت از تکنولوژی های دیتابیس؛ یا حتی سیستم های دیتابیس کاملا متفاوت-یک رویکردی که  Polyglot Persistenceنامیده می شود. شما می توانید در یک مانولیت نیز از polyglot persistence استفاده کنید؛ اما این رویکرد با مایکروسرویس های بیشتر اتفاق می افتد.

 

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

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

خودکار کردن زیر ساخت

تکنیک های خودکار کردن زیر ساخت بخصوص در چند سال اخیر رشد و نمو بسیاری داشتند-تکامل cloud و AWS بخصوص پیچیدگی عملیاتی ساخت, انتشار, و عملیات مایکروسرویس ها را کاهش می دهند.

بسیاری از محصولات و سیستم های که با مایکروسرویس ها ایجاد شدند؛ بوسیله ی تیم هایی با تجارب ارزشمندی از Continuous Delivery  و پیش درآمد آن  Continuous Integration ساخته می شوند. تیم هایی که نرم افزار را به این روش می سازند از تکنیک های خودکار کردن زیر ساخت بصورت گسترده استفاده می کنند. این مورد در خط لوله تولید شکل زیر نمایش داده شده است.

شکل 5: خط لوله ی تولید پایه

از آنجایی که این نوشته یک مقاله درباره Continuous Delivery نیست ما فقط یکسری ویژگی های کلیدی آن را مورد توجه قرار خواهیم داد. می خواهیم که تا جایی که امکان دارد از اینکه نرم افزار در حال کار و فعالیت است اطمینان حاصل کنیم, بنابراین ما تعداد زیادی آزمون های اتوماتیک شده را اجرا می کنیم. پیشرفت “فعال  بودن” نرم افزار کاری تا پایان خط لوله بدین معنی است که انتشار اتوماتیک به تمام محیط ها را انجام دادیم.

یک برنامه ی مانولیت با خوشحالی کامل از طریق این محیط ها؛ بیلد و تست شده و قرار داده می شوند. به نظر می رسد که به محض اینکه شما بر روی اتوماتیک سازی مسیر تولید برای مانولیتسرمایه گذاری کردید؛ منتشر کردن برنامه های بیشتر آنقدر ترسناک نباشد. به یاد داشته باشید یکی از کمک های CD انتشار خسته کننده است؛ بنابراین تا زمانی که خسته کننده باشد؛ اینکه یک یا سه برنامه دارد, مهم نیست[12].

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

 

          شکل 6: انتشار ماژول ها معمولا متفاوت است


طراحی برای شکست

یکی از پیامدهای استفاده از سرویس ها به عنوان مولفه ها, این می باشد که برنامه ها نیازمند این هستند که طراحی بشوند؛ بنابراین آنها می توانند شکست سرویس ها را تحمل کنند. هر call کردن سرویس در صورتی که سرویس دهنده در درسترس نباشد می تواند شکست بخورد, کلاینت باید به این موارد تا جایی که ممکن است پاسخ مناسب بدهد. این یکی از اشکالات مقایسه با طراحی مانولیتاست که پیچیدگی بیشتری را جهت کنترل آن ایجاد می کند. پیامد آن این است که تیم های مایکروسرویس دائما چگونگی تاثیر گذاشتن شکست های سرویس بر روی تجربه ی کاربری را به نمایش می گذارند. Simian Army از شرکت Netflix شکست های سرویس ها و حتی مراکز داده ها را در حین ساعات کاری جهت آزمون هر دو مورد application’s resilience and monitoring استنتاج می کند.

 

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

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

این بخصوص برای معماری مایکروسرویس ها بسیار مهم است زیرا اولویت مایکروسرویس ها در به رقص آرایی و همکاری رویداد(event collaboration) منجر به رفتار ناگهانی و عجولانه می شود. در حالی که اکثر دانشمندان ارزش ظهور نعمت غیر مترقبه را ستایش می کنند؛ حقیقت این هست که رفتار ناگهانی گاهی اوقات می تواند بد باشد. مانیتورینگ جهت نشان دادن سریع رفتارهای بد ناگهانی حیاتی است بنابرین رفتار ناگهانی می تواند فیکس شود.

 

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

تیم های مایکروسرویس تمایل دارند که یک مانیتورینگ و ثبت کننده ی رویدادها که برای هر سرویس جداگانه برپاشده می شود را بصورت داشبوردهای نمایش دادن بالا/پایین بودن و طیف گسترده ای از استانداردهای متناسب کسب و کار و عملیاتی داشته باشند. جزییات بیشتر درباره وضعیت circulate breaker, خروجی فعلی و تاخیر مثال های دیگری است که غالبا با آنها مواجه هستیم.

 

طراحی تکاملی

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

 

هنگامی که شما تلاش می کنید یک سیستم نرم افزاری را به مولفه ها تجزیه کنید؛ شما با تصمیم اینکه به چه صورت این قسمت ها را تقسیم کنید مواجه هستید- اصولی که بر اساس آن ما اقدام به بخش بندی برنامه ی خود می کنیم کدام ها هستند؟ خصوصیت اصلی یک مولفه ایده ی جایگزینی مستقل و قابلیت بروزرسانی آن می باشد[13]- که ما بدنبال نقطه ای هستیم که در آن قادریم تصور کنیم که می توانیم یک مولفه را بدون تاثیر بر مولفه هایی که با آنها همکاری می کند مجددا بنویسیم. در واقع بسیاری از گروه های مایکروسرویس بوسیله ی انتظار داشتن اینکه تعداد زیادی سرویس ها بجای اینکه در مدت طولانی تری تکامل یابند دورانداخته شوند, از این جلوتر می روند

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

این تاکید بر روی قابلیت جایگزینی؛ مورد خاصی از یک اصل عمومی تر طراحی ماژولار است, که ماژولار بودن از طریق الگوی تغییر مشتق می شود[14]. شما می خواهید که مواردی که در یک زمان مشابه تغییر می کنند را در یک ماژول قرار بدهید. بخش هایی از سیستم که به ندرت تغییر می کند باید در سرویس های جداگانه ای از آنهایی که در حال حاظر تحت تغییرات زیاد هستند قرار داده شوند. اگر دریافتید که دو سرویس را با هم و همزمان تغییر می دهید این نشانه ای است که آنها باید ترکیب شوند.

قرار دادن مولفه ها به درون سرویس ها موقعیت برای برنامه ریزی انتشار با granular  بیشتر را اضافه می کند. با یک مانولیت؛ هر تغییری نیازمند بیلد کامل و انتشار کل برنامه می باشد. با مایکروسرویس ها اما, شما فقط نیاز دارید که سرویس(هایی) که تغییر دادید را مجددا منتشر کنید. این کار می تواند باعث ساده شدن فرآیندهای انتشار و سرعت بخشید. روی بد قضیه این هست که شما باید نسبت به اینکه تغییرات به یک سرویس ممکن است منجر به شکستن استفاده کنندگانش شود نگران باشید. رویکرد سنتی مانولیت تلاش می کند که با این مشکل با استفاده از versioning  برخورد کند, اما کارایی در دنیای مایکروسرویس این است که Versioning را فقط به عنوان آخرین راه چاره استفاده کنید. با طراحی سرویس ها به نحوی که تا جایی که امکان دارد نسبت به تغییراتی که در تامین کنندگان آنها می شوند مقاوم باشند می توانیم از بسیاری از versioning ها اجتناب کنیم.

آیا ماکروسرویس ها آینده هستند؟

در نوشتن این مقاله؛ کمک اصلی ما توضیح درباره ی ایده های اصلی و اصول مایکروسرویس ها است. با در نظر گرفتن زمان انجام این کار, ما بوضوح فکر می کنیم که روش معماری مایکروسرویس ها یک ایده ی مهم است – یک ارزش مهم  و قابل توجه برای برنامه های سازمانی. اخیرا چندین سیستم با استفاده از این روش ایجاد کردیم و سایرین را می شناسیم که از این روش استفاده کرده و از این رویکرد راضی بودند.

کسانی که میشناسیم حدودا افرادی هستند که در برخی از روش های معماری پیشرو هستند شامل Amazon, Netflix,The Guardian  UK Government Digital Service, , realestate.com.au, Forward  و  comparethemarket.com. جریان کنفرانس در سال 2013 شامل مثال های بسیاری از شرکت هایی بود که در حال حرکت به سمتی بودند که class as microservices می باشد– شامل Travis CI.  به علاوه تعداد زیادی سازمان هست که برای مدت طولانی اقداماتی انجام می دادند که ما به عنوان class as microservices در نظر می گیریم, اما بدون نام بردن از مایکروسرویس ها( غالبا این ها به عنوان SOA برچسب خوردند- همانگونه که قبلا بیان کردیم, SOA در فرم های بسیار متناقضی آمده[15])

علیرغم این تجربیات مثبت؛ اما نمی خواهیم بحث کنیم که مایکروسرویس ها مسیر آینده معماری های نرم افزار هستند. درحالی که تجربیات ما تا به اکنون در مقایسه با برنامه های مانولیت مثبت بوده, از این حقیقت آگاه هستیم که زمان کافی که بتوانیم قضاوت کاملی انجام دهیم نداریم.

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

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

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

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

یک بحث قابل ملاحضه و قبول که ما شنیدیم این است که شما نباید با یک معماری مایکروسرویس ها شروع کنید. در عوض با یک مونولیت شروع کنید, آن را ماژولار نگه دارید, و سپس به محض اینکه این مونولیت دچار مشکل شد آنرا به مایکروسرویس ها تقسیم کنید.(با این وجود این توصیه ایده آل نیست, زیرا یک اینترفیس خوب در فرآیند معمولا یک اینترفیس سرویس خوب نیست.)

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

Footnotes

1: The term “microservice” was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on “microservices” as the most appropriate name. James presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices – Java, the Unix Way as did Fred George about the same time. Adrian Cockcroft at Netflix, describing this approach as “fine grained SOA” was pioneering the style at web scale as were many of the others mentioned in this article – Joe Walnes, Dan North, Evan Botcher and Graham Tackley.

2: The term monolith has been in use by the Unix community for some time. It appears in The Art of Unix Programming to describe systems that get too big.

3: Many object-oriented designers, including ourselves, use the term service object in the Domain-Driven Designsense for an object that carries out a significant process that isn’t tied to an entity. This is a different concept to how we’re using “service” in this article. Sadly the term service has both meanings and we have to live with the polyseme.

4: We consider an application to be a social construction that binds together a code base, group of functionality, and body of funding.

5: The original paper can be found on Melvyn Conway’s website here

6: At extremes of scale, organisations often move to binary protocols – protobufs for example. Systems using these still exhibit the characteristic of smart endpoints, dumb pipes – and trade off transparency for scale. Most web properties and certainly the vast majority of enterprises don’t need to make this tradeoff – transparency can be a big win.

7: We can’t resist mentioning Jim Webber’s statement that ESB stands for “Egregious Spaghetti Box”.

8: Netflix makes the link explicit – until recently referring to their architectural style as fine-grained SOA.

9: “YAGNI” or “You Aren’t Going To Need It” is an XP principle and exhortation to not add features until you know you need them.

10: It’s a little disengenuous of us to claim that monoliths are single language – in order to build systems on todays web, you probably need to know JavaScript and XHTML, CSS, your server side language of choice, SQL and an ORM dialect. Hardly single language, but you know what we mean.

11: Adrian Cockcroft specifically mentions “developer self-service” and “Developers run what they wrote”(sic) in this excellent presentation delivered at Flowcon in November, 2013.

12: We are being a little disengenuous here. Obviously deploying more services, in more complex topologies is more difficult than deploying a single monolith. Fortunately, patterns reduce this complexity – investment in tooling is still a must though.

13: In fact, Dan North refers to this style as Replaceable Component Architecture rather than microservices. Since this seems to talk to a subset of the characteristics we prefer the latter.

14: Kent Beck highlights this as one his design principles in Implementation Patterns.

15: And SOA is hardly the root of this history. I remember people saying “we’ve been doing this for years” when the SOA term appeared at the beginning of the century. One argument was that this style sees its roots as the way COBOL programs communicated via data files in the earliest days of enterprise computing. In another direction, one could argue that microservices are the same thing as the Erlang programming model, but applied to an enterprise application context.

References

While this is not an exhaustive list, there are a number of sources that practitioners have drawn inspiration from or which espouse a similar philosophy to that described in this article.

Blogs and online articles

Books

Presentations

Papers

  • Lamport, “The Implementation of Reliable Distributed Multiprocess Systems”, 1978 http:// research.microsoft.com/en-us/um/people/lamport/pubs/implementation.pdf
  • Lamport, R. Shostak, M. Pease, “The Byzantine Generals Problem”, 1982 (available at) http:// www.cs.cornell.edu/courses/cs614/2004sp/papers/lsp82.pdf
  • T. Fielding, “Architectural Styles and the Design of Network-based Software Architectures”, 2000 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
  • A. Brewer, “Towards Robust Distributed Systems”, 2000 http://www.cs.berkeley.edu/ ~brewer/cs262b-2004/PODC-keynote.pdf
  • Brewer, “CAP Twelve Years Later: How the ‘Rules’ Have Changed”, 2012, http:// www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

 

 

 

درباره ی masoud@admin

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

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

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

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

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

2 دیدگاه

  1. You made a number of nice points there. I did a quest on the theme and located mainly persons will agree with your blog.

  2. Its excellent as your other posts : D, regards for posting .

پاسخ دهید

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

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

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

پیوستن بستن