microservices

By | آوریل 19, 2017

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

مقدمه:

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

معماری های مایکروسرویس؛ از کتابخانه ها استفاده می کنند, اما روش اصلی آنها در مولفه سازی نرم افزار خود, شکستن آن به سرویس ها می باشد. ما کتابخانه ها را به عنوان مولفه هایی که درون یک برنامه پیوند خوردند و از طریق فراخوانی توابع درون حافظه-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 است که در آن بیان می شود؛ یک تیم تولید مسئولیت کامل برای محصول در ساخت را بر عهده دارند. این موجب می شود که برنامه نویس ها درباره ی اینکه به چه صورت نرم افزار آنها در محیط عمل می کند تعامل روزانه داشته و نیز تماس با کاربرانشان را نیز افزایش می دهد چون آنها حداقل مقداری بار مسئولیت پشتیبانی را نیز خواهند داشت.

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

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

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

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

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

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

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

Lan Robinson

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 


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

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

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

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

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

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

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

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

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

 

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


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

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

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

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

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

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

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

طراحی تکاملی

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

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

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

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

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

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

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

کسانی که میشناسیم حدودا افرادی هستند که در برخی از روش های معماری پیشرو هستند شامل Amazon, Netflix,The Guardian  UK Government Digital Service, , realestate.com.au, Forward  و  comparethemarket.com. جریان کنفرانس در سال 2013 شامل مثال های بسیاری از شرکت هایی بود که در حال حرکت به سمتی بودند که کلاس به عنوان مایکروسریس ها می باشد– شامل Travis CI.  به علاوه تعداد زیادی سازمان هست که برای مدت طولانی اقداماتی انجام می دادند که ما به عنوان کلاس به مثابه مایکروسرویس ها در نظر می گیریم, اما بدون نام بردن از مایکروسرویس ها( غالبا این ها به عنوان 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

 

 

 

پاسخ دهید

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