میکروسرویس‌ها چی هستند؟
https://mcsh.github.io/fa/microservice/2018/06/06/microservice1.html
در مورد چی حرف میزنیم؟
تو دنیای امروز یکی از buzz wordها کلمه microservice هست. کلمه‌ای که شاید زیاد شنیده باشیدش یک نوع طراحی سیستم هست که در اون اجزای مختلف اصطلاحا loosely coupled هستن و هر کدوم به تنهایی قابلیت scale شدن رو دارن.
داستان از اونجایی شروع میشه که ما هر وقت سیستممون نمی‌کشه میایم و ارتقا میدیم. سرعت پردازنده رو زیاد می‌کنیم، رم رو افزایش میدیم یا فضای هارد بیشتری خریداری می‌کنیم، اما واقعیت اینه که بالاخره هر چقدر هم قوی کنیم سیستم رو تعداد کاربرها که زیاد بشن باز کم میاریم. خب پس چاره چیه؟
یکی از راه حل‌ها scale کردن سیستم هست. به این معننا که شما به جای یک کامپیوتر خیلی قوی و خفن میای ۱۰ تا کامپیوتر نسبتا قوی میزاری، یکیش به عنوان load balance یا master یا هر اسم دیگه‌ای که دوست دارین که کارش میشه تقسیم درخواست‌ها بین ۹ سیستم دیگه. این روش خیلی خوب عمل کرد و الگوریتم‌های جدیدی تعریف شد برای استفاده بهینه ازش و کلی مسئله برامون به وجود اومد مثل مسائل race condition و transaction. اما باز مشکل خوردیم! هزینه کامپیوترهای نسبتا قوی هم کم نیستن و با افزایش کاربرها این هزینه خیلی سریع زیاد میشه.
اینجا بود که بعضی از مهندسا به این نتیجه رسیدن که نیازی نیست کل سیستم رو scale کرد و کافیه بخشی از اون scale شه. مثلا بخش مربوط به ایمیل زدن تبریک تولد به کاربرها نیازی نیست روی همه سرورها اجرا بشه و روی بعضی از اون‌ها کفایت می‌کنه، و از طرفی بخش مربوط به جواب دادن به api محبوب cat recognizer به شدت مورد استفاده قرار می‌گیره باید روی تعداد بیشتری سرور اجرا بشه. اینجا مهندس‌ها شروع کردن به بخش کردن نرم‌افزارهاشون به سرویس‌های کوچکتری که با هم صحبت می‌کنند و این شروعی از میکروسرویس‌هاست.
بحث دیگه‌ای که در زمینه میکروسرویس‌هاست بحث توسعه هست. تو تیم‌های بزرگ و نرم‌افزارهای پیچیده تغییر دادن چیزهای نامربوط ممکنه باعث خرابی کل سیستم بشه. اما توسعه ماژولار بسیار کمک می‌کنه که این مشکل‌ها کمتر پیش بیان. میکروسرویس‌ها که به نوعی خودشون ماژول‌ها هستن تو این زمینه به شدت به کمک توسعه دهنده‌ها میان.
تو این پست و پست‌های بعدی این سری میخوام در مورد این که چه مسائلی تو زمینه میکروسرویس‌ها هست و هرکدوم چه راهکارهایی دارن براتون بنویسم. بیشتر این مسائل از تجربه شخصیم تو پروژه‌های متفاوت حاصل شده، اگر جاییش مشکلی هست حتما بهم بگید اصلاح می‌کنم!
چه چیزی باید سرویس باشه؟
سوال بسیار جالبی هست. تو فلسفه یونیکس گفته میشه هر نرم‌افزار باید یک کار، و فقط یک کار، را انجام دهد و آن را به خوبی انجام دهد. این حرف شاید برای نرم‌افزارهای کامندلاین یونیکس مناسب باشه اما برای سرویس‌ها واقعا مناسب نیست. هر میکروسرویس هزینه توسعه جدایی داره و وجودش سربار برای سیستم تولید می‌کنه. هزینه پشتیبانی و مانیتورینگ و غیره بماند.
خب پس چه کار باید کرد؟ راهکار اینه که actionهایی که برای کاربرها تعریف می‌کنید رو گروه بندی کرد.
اولین رویکرد نزدیکی سیستمی هست مثلا وارد شدن به سیستم و ثبت‌نام کردن نزدیکی زیادی به هم دارن، هم از کتابخونه‌های یکسانی استفاده می‌کنند(برای رمزنگاری و تایید رمز)، هم سرویس های مشترکی رو(دیتابیس).
رویکرد دوم نزدیکی از لحاظ بار و فشار سیستم هست. مثلا سرویس ثبت‌نام و آپلود عکس کاربری معمولا با هم استفاده میشن و اگه تعداد زیادی کاربر یکهو تصمیم بگیرند ثبت‌نام کنند (مثلا بعد آگهی تلویزیونی در آخر یک سریال محبوب) شما کافیه این سرویس رو scale کنید.
تجربه من نشون داده رویکرد دوم معمولا عملکرد بهتری داره، تو پست بعدی در مورد این که چطوری این گروه‌ها رو تشخیص بدیم بیشتر صحبت می‌کنم.
https://mcsh.github.io/fa/microservice/2018/06/06/microservice1.html
در مورد چی حرف میزنیم؟
تو دنیای امروز یکی از buzz wordها کلمه microservice هست. کلمه‌ای که شاید زیاد شنیده باشیدش یک نوع طراحی سیستم هست که در اون اجزای مختلف اصطلاحا loosely coupled هستن و هر کدوم به تنهایی قابلیت scale شدن رو دارن.
داستان از اونجایی شروع میشه که ما هر وقت سیستممون نمی‌کشه میایم و ارتقا میدیم. سرعت پردازنده رو زیاد می‌کنیم، رم رو افزایش میدیم یا فضای هارد بیشتری خریداری می‌کنیم، اما واقعیت اینه که بالاخره هر چقدر هم قوی کنیم سیستم رو تعداد کاربرها که زیاد بشن باز کم میاریم. خب پس چاره چیه؟
یکی از راه حل‌ها scale کردن سیستم هست. به این معننا که شما به جای یک کامپیوتر خیلی قوی و خفن میای ۱۰ تا کامپیوتر نسبتا قوی میزاری، یکیش به عنوان load balance یا master یا هر اسم دیگه‌ای که دوست دارین که کارش میشه تقسیم درخواست‌ها بین ۹ سیستم دیگه. این روش خیلی خوب عمل کرد و الگوریتم‌های جدیدی تعریف شد برای استفاده بهینه ازش و کلی مسئله برامون به وجود اومد مثل مسائل race condition و transaction. اما باز مشکل خوردیم! هزینه کامپیوترهای نسبتا قوی هم کم نیستن و با افزایش کاربرها این هزینه خیلی سریع زیاد میشه.
اینجا بود که بعضی از مهندسا به این نتیجه رسیدن که نیازی نیست کل سیستم رو scale کرد و کافیه بخشی از اون scale شه. مثلا بخش مربوط به ایمیل زدن تبریک تولد به کاربرها نیازی نیست روی همه سرورها اجرا بشه و روی بعضی از اون‌ها کفایت می‌کنه، و از طرفی بخش مربوط به جواب دادن به api محبوب cat recognizer به شدت مورد استفاده قرار می‌گیره باید روی تعداد بیشتری سرور اجرا بشه. اینجا مهندس‌ها شروع کردن به بخش کردن نرم‌افزارهاشون به سرویس‌های کوچکتری که با هم صحبت می‌کنند و این شروعی از میکروسرویس‌هاست.
بحث دیگه‌ای که در زمینه میکروسرویس‌هاست بحث توسعه هست. تو تیم‌های بزرگ و نرم‌افزارهای پیچیده تغییر دادن چیزهای نامربوط ممکنه باعث خرابی کل سیستم بشه. اما توسعه ماژولار بسیار کمک می‌کنه که این مشکل‌ها کمتر پیش بیان. میکروسرویس‌ها که به نوعی خودشون ماژول‌ها هستن تو این زمینه به شدت به کمک توسعه دهنده‌ها میان.
تو این پست و پست‌های بعدی این سری میخوام در مورد این که چه مسائلی تو زمینه میکروسرویس‌ها هست و هرکدوم چه راهکارهایی دارن براتون بنویسم. بیشتر این مسائل از تجربه شخصیم تو پروژه‌های متفاوت حاصل شده، اگر جاییش مشکلی هست حتما بهم بگید اصلاح می‌کنم!
چه چیزی باید سرویس باشه؟
سوال بسیار جالبی هست. تو فلسفه یونیکس گفته میشه هر نرم‌افزار باید یک کار، و فقط یک کار، را انجام دهد و آن را به خوبی انجام دهد. این حرف شاید برای نرم‌افزارهای کامندلاین یونیکس مناسب باشه اما برای سرویس‌ها واقعا مناسب نیست. هر میکروسرویس هزینه توسعه جدایی داره و وجودش سربار برای سیستم تولید می‌کنه. هزینه پشتیبانی و مانیتورینگ و غیره بماند.
خب پس چه کار باید کرد؟ راهکار اینه که actionهایی که برای کاربرها تعریف می‌کنید رو گروه بندی کرد.
اولین رویکرد نزدیکی سیستمی هست مثلا وارد شدن به سیستم و ثبت‌نام کردن نزدیکی زیادی به هم دارن، هم از کتابخونه‌های یکسانی استفاده می‌کنند(برای رمزنگاری و تایید رمز)، هم سرویس های مشترکی رو(دیتابیس).
رویکرد دوم نزدیکی از لحاظ بار و فشار سیستم هست. مثلا سرویس ثبت‌نام و آپلود عکس کاربری معمولا با هم استفاده میشن و اگه تعداد زیادی کاربر یکهو تصمیم بگیرند ثبت‌نام کنند (مثلا بعد آگهی تلویزیونی در آخر یک سریال محبوب) شما کافیه این سرویس رو scale کنید.
تجربه من نشون داده رویکرد دوم معمولا عملکرد بهتری داره، تو پست بعدی در مورد این که چطوری این گروه‌ها رو تشخیص بدیم بیشتر صحبت می‌کنم.
mcsh.github.io
میکروسرویس‌ها چی هستند؟
در مورد چی حرف میزنیم؟ تو دنیای امروز یکی از buzz wordها کلمه microservice هست. کلمه‌ای که شاید زیاد شنیده باشیدش یک نوع طراحی سیستم هست که در اون اجزای مختل...
چگونه برنامه خود را به میکروسرویس‌ها بشکونیم؟
https://mcsh.github.io/fa/microservice/2018/06/14/breaking_services.html
چندین روش مختلف برای تقسیم کردن برنامه‌ها و سرویس‌ها به میکروسرویس‌ها وجود داره. شاید راحت‌ترین روش «میلی» باشه به طوری که شما بدون هدف و از روی غریزه یک سری میکروسرویس معرفی می‌کنید. واضحه که این روش اصلا مناسب نیست و ممکنه حتی باعث دردسر بشه. خب باید چیکار کرد؟ چند راهکار مختلف هست که تجربه به من یادشون داده:
تقسیم بندی بر اساس تیم‌ها
وقتی Gerstner ریاست IBM رو برعهده گرفت حرف جالبی زد «با نگاه کردن داخل یکی از کامپیوترهای IBM شما می‌تونید تیم‌های ما رو ببینید» این حرف که در واقع نقدی بر طراحی قبلی بود می‌تونه به شما کمک کنه. اگر تیم‌های زیادی همزمان با هم به توسعه محصول شما می‌پردازن تقسیم کردن سرویس‌ها با توجه به تیم‌ها می‌تونه بهتون کمک کنه تا کمترین تداخل رو داشته باشید. اینطوری هر تیم روی پروژه کوچکی کار می‌کنه که بر اساس یک schema بزرگتر که طراح سیستم (شما!) با بقیه اجزای سیستم کار می‌کند.
تقسیم بندی بر اساس کاربرد
در این روش شما ابتدا تمامی اعمال کاربر رو لیست می‌کنید. اعمالی مثل «لاگین/ریجستر/ایجاد پست جدید/لایک کردن پست دیگران/ایجاد کامنت/ آپلود عکس» رو مشخص می‌کنید سپس یکی از دو روش زیر رو در نظر می‌گیرید:
۱- با استدلال اعمال بالا رو دسته بندی کنید. مثلا به نظر می‌رسه افراد بعد از ریجستر کردن اقدام به آپلود عکس کنن. پس باید این دو عمل در یک سرویس قرار بگیرن تا وقتی تعداد زیادی کاربر ثبت‌نام می‌کنند شما تنها با scale کردن این سرویس مشکل رو حل کنید.
۲- ابتدا یک سرویس کلی بنویسید که همه چیز را لاگ می‌کند (توصیه می‌کنم از ELK استفاده کنید!) و سپس با تحلیل لاگ‌ها بین اعمال بالا ارتباط پیدا کنید و آن بخش‌ها را جدا کنید. این روش به خصوص وقتی به کار می‌آید که شما برنامه فعلیتان به صورت مونولتیک توسعه داده شده است و میخواهید به میکروسرویس‌ها سوییچ کنید. ممکن است مثلا با تحلیل لاگ‌ها به این نتیجه برسید که ریجستر کردن و ایجاد کامنت ارتباط نزدیک‌تری دارند تا ریجستر کردن و آپلود عکس!
تقسیم بندی بر اساس پیش‌نیازها
روش دیگه تقسیم بندی بر اساس نیازهای هر سیستم هست. مثلا سرویس لاگین و ریجستر هر دو به دیتابیس یوزرها نیاز دارند اما سرویس آپلود عکس نیاز به دسترسی به ftp server شما دارد.
نتیجه گیری
اساسا این که سرویس‌هاتون رو چطور تقسیم بندی کنید بستگی به این داره که چرا میخواهید از میکروسرویس ها استفاده کنید. احتمالا روش نهایی شما ترکیبی از همه روش‌های بالاست!
https://mcsh.github.io/fa/microservice/2018/06/14/breaking_services.html
چندین روش مختلف برای تقسیم کردن برنامه‌ها و سرویس‌ها به میکروسرویس‌ها وجود داره. شاید راحت‌ترین روش «میلی» باشه به طوری که شما بدون هدف و از روی غریزه یک سری میکروسرویس معرفی می‌کنید. واضحه که این روش اصلا مناسب نیست و ممکنه حتی باعث دردسر بشه. خب باید چیکار کرد؟ چند راهکار مختلف هست که تجربه به من یادشون داده:
تقسیم بندی بر اساس تیم‌ها
وقتی Gerstner ریاست IBM رو برعهده گرفت حرف جالبی زد «با نگاه کردن داخل یکی از کامپیوترهای IBM شما می‌تونید تیم‌های ما رو ببینید» این حرف که در واقع نقدی بر طراحی قبلی بود می‌تونه به شما کمک کنه. اگر تیم‌های زیادی همزمان با هم به توسعه محصول شما می‌پردازن تقسیم کردن سرویس‌ها با توجه به تیم‌ها می‌تونه بهتون کمک کنه تا کمترین تداخل رو داشته باشید. اینطوری هر تیم روی پروژه کوچکی کار می‌کنه که بر اساس یک schema بزرگتر که طراح سیستم (شما!) با بقیه اجزای سیستم کار می‌کند.
تقسیم بندی بر اساس کاربرد
در این روش شما ابتدا تمامی اعمال کاربر رو لیست می‌کنید. اعمالی مثل «لاگین/ریجستر/ایجاد پست جدید/لایک کردن پست دیگران/ایجاد کامنت/ آپلود عکس» رو مشخص می‌کنید سپس یکی از دو روش زیر رو در نظر می‌گیرید:
۱- با استدلال اعمال بالا رو دسته بندی کنید. مثلا به نظر می‌رسه افراد بعد از ریجستر کردن اقدام به آپلود عکس کنن. پس باید این دو عمل در یک سرویس قرار بگیرن تا وقتی تعداد زیادی کاربر ثبت‌نام می‌کنند شما تنها با scale کردن این سرویس مشکل رو حل کنید.
۲- ابتدا یک سرویس کلی بنویسید که همه چیز را لاگ می‌کند (توصیه می‌کنم از ELK استفاده کنید!) و سپس با تحلیل لاگ‌ها بین اعمال بالا ارتباط پیدا کنید و آن بخش‌ها را جدا کنید. این روش به خصوص وقتی به کار می‌آید که شما برنامه فعلیتان به صورت مونولتیک توسعه داده شده است و میخواهید به میکروسرویس‌ها سوییچ کنید. ممکن است مثلا با تحلیل لاگ‌ها به این نتیجه برسید که ریجستر کردن و ایجاد کامنت ارتباط نزدیک‌تری دارند تا ریجستر کردن و آپلود عکس!
تقسیم بندی بر اساس پیش‌نیازها
روش دیگه تقسیم بندی بر اساس نیازهای هر سیستم هست. مثلا سرویس لاگین و ریجستر هر دو به دیتابیس یوزرها نیاز دارند اما سرویس آپلود عکس نیاز به دسترسی به ftp server شما دارد.
نتیجه گیری
اساسا این که سرویس‌هاتون رو چطور تقسیم بندی کنید بستگی به این داره که چرا میخواهید از میکروسرویس ها استفاده کنید. احتمالا روش نهایی شما ترکیبی از همه روش‌های بالاست!
mcsh.github.io
چگونه برنامه خود را به میکروسرویس‌ها بشکونیم؟
چندین روش مختلف برای تقسیم کردن برنامه‌ها و سرویس‌ها به میکروسرویس‌ها وجود داره. شاید راحت‌ترین روش «میلی» باشه به طوری که شما بدون هدف و از روی غریزه یک سری...
به بهانه هیولای اسپاگتی - راسل
آقای برترند راسل ریاضی‌دان فوق‌العاده قرن بیستم و پایه گذار علم منطق عقاید جالبی درباره خدا و وجودش دارد. وی، برای مردم عادی، خود را خدا ناباور و برای مخاطبین فلسفی، ندانم گرا معرفی می‌کند...
ادامه مطلب:
https://mcsh.github.io/fa/god/logic/2018/12/03/FSM_Russell.html
آقای برترند راسل ریاضی‌دان فوق‌العاده قرن بیستم و پایه گذار علم منطق عقاید جالبی درباره خدا و وجودش دارد. وی، برای مردم عادی، خود را خدا ناباور و برای مخاطبین فلسفی، ندانم گرا معرفی می‌کند...
ادامه مطلب:
https://mcsh.github.io/fa/god/logic/2018/12/03/FSM_Russell.html