در مقاله قبلی ، ما به ویژگی های معماری میکروسرویس و مراحل مربوط به فرآیند طراحی آنها مانند تجزیه و تحلیل دامنه ، زمینه محدود کردن و انتخاب یک کانال ارتباطی به همراه نمونه ای از برنامه سفارش غذا ما پرداختیم. در این مقاله در مورد انتخاب بانکهای اطلاعاتی و استفاده از برخی الگوهای طراحی یا تکنیک های مقیاس گذاری در معماری میکروسرویس ما بحث خواهد شد.
مرحله 4. انتخاب بانک اطلاعاتی:
بانکهای اطلاعاتی بخش اساسی هر معماری است. در حین انتخاب یک بانک اطلاعاتی ، باید عوامل مختلفی مانند قوام ، عملکرد پرس و جو ، هزینه ، مقیاس پذیری و از همه مهمتر – نوع ساختاری را که در پایگاه داده ذخیره خواهیم کرد ، در نظر بگیریم. بیایید به انواع مختلف پایگاه داده ها نگاه کنیم:
SQL (MySQL ، PostgreSQL ، MSSQL)
از پایگاه داده های SQL برای ذخیره داده های ساختاری که مربوط به یکدیگر است استفاده می شود. اگر خدمات شما مجبور است داده های مربوط به اطلاعات مشتری ، معاملات مالی ، مدیریت موجودی یا موارد دیگری را که در آن اطلاعات مختلف به نوعی مربوط به یکدیگر است ، ذخیره کند و باید به طور مکرر پرس و جو شود ، پس باید از یک پایگاه داده SQL استفاده کنید بشر
عیاشی
از پایگاه داده های NOSQL برای ذخیره داده های بدون ساختار یا نیمه ساختار یافته استفاده می شود. آنها به طور گسترده در برنامه های وب برای ذخیره محتوای تولید شده توسط کاربر مانند پست های رسانه های اجتماعی ، نظرات و بررسی ها استفاده می شوند. بانکهای اطلاعاتی NOSQL در انواع مختلفی قرار دارند که هر کدام هدف خود را دارند.
- فروشگاه ارزش کلیدی (DynamoDB ، Redis ، Memcache): از فروشگاه های ارزش کلیدی برای ذخیره هرگونه ساختار داده مانند رشته ها ، عدد صحیح یا اشیاء که به یک کلید گره خورده است استفاده می شود. آنها به طور گسترده در ذخیره سازی و مدیریت جلسه استفاده می شوند. Redis یک بانک اطلاعاتی در حافظه است که عمدتا برای ذخیره سازی استفاده می شود. DynamoDB یک پایگاه داده بومی ابر است که توسط خدمات وب آمازون (AWS) ارائه می شود. این طراحی شده است تا ضمن حفظ عملکرد مداوم و سریع ، مقادیر زیادی از داده ها و ترافیک را کنترل کند.
- فروشگاه اسناد (MongoDB ، Couchdb): از فروشگاه های اسناد برای ذخیره داده های نیمه ساختار یافته مانند اسناد JSON استفاده می شود. آنها به طور گسترده در برنامه های وب برای ذخیره محتوای تولید شده توسط کاربر استفاده می شوند. اگر سرویس شما نیاز به ذخیره داده های مربوط به کاربران دارد که به احتمال زیاد بدون ساختار نیست یا تغییرات مکرر دارد و باید به راحتی مقیاس بندی شود ، پس MongoDB یا CouchDB گزینه های خوبی هستند.
-
فروشگاه ستون (کاساندرا ، HBase): از فروشگاه های ستون برای ذخیره مقادیر زیادی از داده ها استفاده می شود که می توانند به سرعت پرس و جو شوند. آنها به طور گسترده در برنامه های Big Data برای ذخیره و تجزیه و تحلیل مجموعه داده های بزرگ استفاده می شوند. فروشگاه های ستون نوعی ساختار را به پایگاه داده های NOSQL ارائه می دهند و باعث می شود که سریعتر نمایش داده شود. در صورت نیاز به پردازش زمان واقعی یا حجم زیاد داده ها ، باید پایگاه داده های فروشگاه ستون را انتخاب کنید.
فروشگاه نمودار (آمازون نپتون ، NEO4J): از فروشگاه های نمودار برای ذخیره داده هایی که روابط پیچیده ای دارند استفاده می شود. آنها به طور گسترده در سیستم های شبکه های اجتماعی و توصیه ها مورد استفاده قرار می گیرند. اگر خدمات شما مربوط به ارائه برخی از توصیه ها بر اساس فعالیت های گذشته کاربران است ، یک فروشگاه نمودار بهترین انتخاب است. -
هیبرید (سوسکدب ، postgresql): پایگاه داده های ترکیبی مزایای پایگاه داده های SQL و NOSQL را با هم ترکیب می کنند. آنها برای ذخیره داده های ساختاری و بدون ساختار استفاده می شوند. CockroachDB یک پایگاه داده SQL توزیع شده است که برای مقیاس پذیری و در دسترس بودن بالا طراحی شده است. PostgreSQL یک بانک اطلاعاتی ترکیبی است که از هر دو مدل داده SQL و NOSQL پشتیبانی می کند.
هنگام تصمیم گیری در مورد نوع بانک اطلاعاتی ، عوامل زیر را در نظر بگیرید:
ساخت داده ها: اگر داده های شما ساختار یافته و مربوط به یکدیگر است ، یک پایگاه داده SQL انتخاب خوبی است. اگر داده های شما بدون ساختار یا نیمه ساختار یافته است ، یک پایگاه داده NOSQL انتخاب بهتری است.
مقیاس پذیری: اگر نیاز به مقیاس پایگاه داده خود به صورت افقی دارید ، یک پایگاه داده NOSQL انتخاب بهتری است. اگر نیاز به مقیاس پایگاه داده خود به صورت عمودی دارید ، یک پایگاه داده SQL انتخاب بهتری است.
پرس و جو: اگر شما نیاز به انجام نمایش داده های پیچیده در داده های خود دارید ، یک پایگاه داده SQL انتخاب بهتری است. اگر نیاز به انجام نمایش داده های ساده در داده های خود دارید ، یک پایگاه داده NOSQL انتخاب بهتری است.
ثبات: اگر به ضمانت قوام قوی نیاز دارید ، یک پایگاه داده SQL انتخاب بهتری است. اگر می توانید قوام نهایی را تحمل کنید ، یک پایگاه داده NOSQL انتخاب بهتری است.
هزینه: پایگاه داده های SQL به طور کلی گران تر از پایگاه داده های NOSQL هستند. اگر هزینه یک نگرانی باشد ، یک بانک اطلاعاتی NOSQL انتخاب بهتری است.
بیایید با اختصاص یک پایگاه داده برای سفارش مواد غذایی ما در معماری MicroService.
برای کاربران و داده های مربوط به موجودی رستوران ، می توانیم از یک پایگاه داده SQL مانند Postgres استفاده کنیم.
برای مدیریت سفارشات ، می توانیم از یک پایگاه داده NOSQL مانند MongoDB استفاده کنیم.
برای ردیابی تحویل در زمان واقعی و نمایش داده شد ، می توانیم از Cassandra یا HBase استفاده کنیم.
برای سیستم های توصیه ، می توانیم از نپتون به عنوان نمودار DB استفاده کنیم.
مرحله 5. ادغام الگوهای یا تکنیک های طراحی
مرحله آخر استفاده از برخی از الگوهای طراحی یا تکنیک هایی است که می تواند به ما در حل برخی از مشکلات یا چالش های رایج در یک معماری میکروسرویس کمک کند. آنها در مرحله اولیه مورد نیاز نیستند ، اما در نهایت ، شما به آنها احتیاج خواهید داشت.
برخی از الگوهای یا شیوه های طراحی مشترک عبارتند از:
- الگوی عجیب و غریب
- الگوی حماسه
- الگوی CQRS
- مسیریابی دروازه API
- الگوی قطع کننده مدار
- پشتوانه برای جبهه
- تعادل بار
- هذیان ثابت
- پارتیشن بندی
- تکرار
- ذخیره سازی
- توری
- محدود کردن نرخ
- قفل کردن و برخورد با idempotency
- دست زدن به همزمان
- معیارهای کاربرد
- ورود به سیستم حسابرسی
بعداً در سریال خود به تفصیل در مورد آنها بحث خواهیم کرد.
چند مورد برای یادآوری
چند مورد کوچک دیگر وجود دارد که می تواند در فرآیند طراحی بیشتر کمک کند.
-
همیشه لازم نیست که یک سرویس ایجاد کنید اگر فقط به جداسازی نگرانی در کد نیاز دارید ، می توانید به جای آن یک کتابخانه یا یک بسته ایجاد کنید. به عنوان مثال ، بخشی از پایگاه کد شما در طراحی الگوهای ایمیل و تولید فاکتورهای PDF یا گزارش های اکسل کار می کند. این کارها به خودی خود کارکردهای مستقل هستند ، آنها فقط به ورودی احتیاج دارند و قرار است خروجی خود را ارائه دهند. آنها توابع و واردات مشترک مشترک را به اشتراک می گذارند و بعضی اوقات در خدمات مختلف مورد نیاز هستند. برای چنین کارهایی ، بهتر است به جای یک سرویس ، یک کتابخانه/بسته ایجاد کنید. با استفاده از کتابخانه ، می توانید بخشی از کد را از خدمات خود انتزاع کنید ، همچنین آنها سریعتر برای خدمت هستند زیرا هیچ ارتباط بین خدمات وجود ندارد.
-
سعی کنید ارتباطات خدمات را یک طرفه انجام دهید. ساختار میکروسرویس شما باید مانند یک درخت باشد ، با خدمات والدین و کودک. در جایی که والدین می توانند درخواست هایی را به کودکان بفرستند و پاسخی دریافت کنند ، اما باید تا حد امکان از معکوس جلوگیری شود.
-
همیشه از یک سیستم ورود به سیستم متمرکز با یک قالب استاندارد برای مشکلات آسان برای یافتن در بین درخواست های مختلف استفاده کنید. برای دیدن کلیه سیاهههای مربوط به یک معامله واحد در بین کلیه خدمات ، از هدره هایی مانند شناسه همبستگی استفاده کنید. همچنین برای بازیابی کلیه سیاهههای مربوط به آنها در هر نقطه ، نقاط داده کلیدی مانند سفارش را وارد کنید.
-
در نزدیکی کد بمانید ، جزئیات کسب و کار کوچک بسیار زیادی وجود دارد که هرگز در هیچ سندی پوشانده نشده است. آنها فقط در کد هستند. هیچ کس آنها را بهتر از کد شما نمی شناسد. بنابراین در نزدیکی کد یا شخصی که آنها را می نویسد بمانید. ترسیم جعبه ها و طراحی ساده تر است اما اجرای آن سخت تر است. دانستن چگونگی مواردی مانند صف پیام ، تعادل بار و محدود کردن نرخ اجرا شده و کار در سطح پایین به همان اندازه مهم است.
در مقاله بعدی ما ، ما قصد داریم در مورد تخمین زیرساخت ها برای معماری میکروسرویس ، نحوه انتخاب زیرساخت های مناسب و محاسبه هزینه ها بحث کنیم.
