شما در حال ساخت اپلیکیشن سازمانی server-side هستید. این اپلیکیشن باید انواع مختلفی از کاربرها شامل مرورگرهای desktop، مرورگر موبایل و اپلیکیشن موبایل native را پشتیبانی کند. این اپلیکیشن ممکن است یک API را برای مصرف شخص ثالثی قرار دهد. همچنین ممکن است با اپلیکیشن های دیگر یا از طریق web service یا یک message broker ادغام شود. این اپلیکیشن به درخواست ها (درخواست های HTTP و پیغام ها) از طریق اجرای منطق کسب و کار، دسترسی به یک پایگاه داده، تبادل پیغام ها با دیگر سیستم ها و بازگرداندن یک پاسخ HTML/JSON/XML رسیدگی می کند. مؤلفه های منطقی متناسب با حوزه های عملیاتی مختلف اپلیکیشن وجود دارد.
مسائل و مشکلات
معماری ساخت و به کارگیری اپلیکیشن چیست؟
نیروها
– یک تیمی از برنامه نویسان بر روی اپلیکیشن کار می کنند.
– اعضای جدید تیم سریعاً باید بهره ور شوند.
– درک و اصلاح اپلیکیشن باید آسان باشد.
– شما می خواهید توسعه مداوم اپلیکیشن داشته باشید
– شما باید چندین نمونه از اپلیکیشن را بر روی چندین دستگاه اجرا کنید تا شرایط مقیاس پذیری و در دسترس بودن برآورده شود.
– شما می خواهید از مزایای تکنولوژی های نوظهور بهره مند شوید (framework ها، زبان های برنامه نویسی و غیره)
راهکارها
معماری استفاده کنید که اپلیکیشن را به عنوان مجموعه ای از سرویس های به هم پیوسته و هماهنگ بسازد. این رویکرد منطبق با محور Y در Scale Cube است. هر سرویس شامل:
– با قابلیت اطمینان و آزمایش بالا – امکان ساخت و به کارگیری سریع و پیوسته را فراهم می کند.
– با دیگر سرویس ها به طور گسترده متصل می شود – به یک تیم امکان می دهد تا بدون تحت تأثیر قرار دادن دیگر سرویس ها و بدون تحت تأثیر قرار گرفتن تغییرات در دیگر سرویس ها، اکثر مواقع به طور مستقل بر روی سرویس هایشان کار کنند.
– به کارگیری مستقل – به یک تیم امکان می دهد بدون هماهنگی با دیگر تیم ها، بتوانند سرویس را اجرا کنند.
– امکان ساخت توسط یک تیم کوچک – بدین طریق از ارتباطات زیادی که بر سر راه تیم های بزرگ است اجتناب می شود، که برای بهره وری بالا ضروری است.
سرویس ها یا از طریق پروتکل های Synchronous مانند HTTP/REST یا پروتکل های asynchronous مانند AMQP با هم ارتباط برقرار می کنند. سرویس ها می توانند به طور مستقل از یکدیگر توسعه و به کار گرفته شوند. هر سرویس برای متمایز شدن از دیگر سرویس ها، پایگاه داده خود را دارد. انسجام داده ها بین سرویس ها از طریق Saga pattern حفظ می شود.
نمونه مشابه
اپلیکیشن تجارت الکترونیک خیالی
تصور کنید در حال ساخت اپلیکیشن تجارت الکترونیکی هستید که سفارش ساخت آن را از مشتری گرفته اید، موجودی و اعتبار موجود را چک می کنید و آن را حمل می کنید. اپلیکیشن از چندین عنصر شامل StoreFrontUI تشکیل شده است که در کنار برخی از سرویس های backend برای چک کردن اعتبار، حفظ موجودی و انتقال سفارشات، رابط کاربری را پیاده سازی می کند. اپلیکیشن از یک مجموعه سرویس ها تشکیل شده است.
مفاد منتج
مزایا
این راهکار چند مزایا دارد:
– امکان تحویل مداوم و ساخت اپلیکیشن های بزرگ و پیچیده را فراهم می کند.
– بهبود قابلیت نگهداری – هر سرویس نسبتاً کوچک است. بنابراین، درک و تغییر آن آسان است.
– قابلیت تست بهتر – سرویس ها برای تست کردن کوچک تر و سریع تر هستند.
– قابلیت به کارگیری – سرویس ها می توانند به طور مستقل به کار گرفته شوند.
– به شما امکان می دهد تا تلاش های ساخت را حول چندین تیم مجزا ساماندهی کنید. هر تیم مسئول یک یا چند سرویس است. هر تیم می تواند سرویس های خود را به طور مستقل از تیم های دیگر بسازد، تست کند، مستقر و تراز کند.
– هر microservice نسبتاً کوچک است:
– درک آن برای برنامه نویسان آسان تر است.
– IDE در بهره ورتر ساختن برنامه نویسان سریع تر است.
– اپلیکیشن سریع تر شروع به کار می کند که برنامه نویسان را بهره ور تر می کند و سرعت ساخت را بیشتر می کند.
– بهبود جداسازی نقص و خطا. به عنوان مثال، در صورت وجود memory leak در یک سرویس، تنها سرویس مذکور تحت تأثیر قرار می گیرد. سرویس های دیگر رسیدگی به درخواست ها را ادامه می دهند. در مقایسه، یک عنصر نادرست از یک معماری یکپارچه می تواند کل سیستم را از کار بیندازند.
– تعهد و وفاداری به یک مجموعه تکنولوژی را حذف کنید. هنگام ساخت یک سرویس جدید می توانید از یک مجموعه تکنولوژی جدید استفاده کنید. به طور مشابه، هنگام ایجاد تغییرات عمده در یک سرویس موجود می توانید آن را با استفاده از یک مجموعه تکنولوژی جدید بازنویسی کنید.
معایب
این راهکار چند ایراد دارد:
– برنامه نویسان باید با پیچیدگی های اضافه مرتبط با ایجاد یک سیستم توزیع کار کنند:
– برنامه نویسان باید یک مکانیسم ارتباط درون سرویسی را اجرا کنند و با نارسایی های نسبی سروکار داشته باشند.
– اجرای درخواست هایی که چندین سرویس را span می کنند دشوارتر است.
– تست تعاملات بین سرویس ها دشوارتر است.
– اجرای درخواست هایی که چندی سرویس را span می کنند نیازمند هماهنگی دقیق بین تیم هاست.
– ابزارها/IDE های برنامه نویسان به سمت ساخت اپلیکیشن های یکپارچه و عدم ارائه پشتیبانی صریح و روشن برای ساخت اپلیکیشن های distribute شده، سوق دارد.
– پیچیدگی به کارگیری. در تولید، پیچیدگی عملیاتی در به کارگیری و مدیریت سیستم متشکل از سرویس های متفاوت وجود دارد.
– افزایش مصرف حافظه. این معماری microservice نمونه های اپلیکیشن یکپارچه N را با نمونه سرویس های NxM جایگزین می کند. اگر هر سرویس، JVM خود (یا معادل آن را) که معمولاً برای مجزاسازی نمونه ها ضروری است، را اجرا کند، بعد از آن به اندازه M بار بیشتر از اجرای JVM سربار وجود دارد. علاوه بر این، اگر هر سرویس روی VM خود (مانند EC2 instance) اجرا شود، سربار بیشتر از آن خواهد بود.