اصطلاح IAC به معنای اجرای تنظیمات زیرساختهای IT در موارد تکرارپذیر از طریق کدهای نرمافزاری است تا ضمن اتوماسیون و تسریع کار اشتباهات انسانی به حداقل برسد. این امر با کمک نرمافزارهایی چون Terraform، Ansible، Puppet و Chefو به دو شیوه صورت میپذیرد. رویکرد اول imperative است که به نرمافزار گفته میشود دقیقا چه اقداماتی باید انجام شود. مثل دستور آشپزی برای پختن یک غذا. رویکرد دوم declarative هست که تنها حالت نهایی که باید ایجاد شود به نرمافزار داده میشود و نرمافزار اقدامات لازم به منظور رسیدن به آن حالت را طراحی مینماید. مثل اینکه در آشپزی تنها بگوییم که چه غذایی میخواهیم.
هر دو ابزاری برای مدیریت سرویسها هستند که بیشتر در معماری میکروسرویس استفاده میشوند. با این تفاوت که API Gateway برای مدیریت سرویسها با کلاینت و یا مدیریت ارتباط بخش front نرمافزار اعم از اپلیکیشنهای موبایلی و یا صفحات وب با بخش backend آن است. API Gateway درخواستهای کلاینت را مدیریت کرده و به سمت سرویس مناسب هدایت میکند. بار ترافیکی را از طریق Cashing و یا در صورت وجود هستههای مختلف، با تعادل بخشی در توزیع بار بین هستههای مختلف کنترل میکند. Service Meshبرای مدیریت ارتباطات داخلی بین سرویسها است و وظایفی چون احراز هویت داخلی، مانیتورینگ و امنیت ارتباطات را فراهم میکند.
روشی در مدیریت و ذخیرهسازی داده ها است که داده ها به دو طریق که یکی برای خواندن از طریق کوئری بهینهسازی شده و دیگری برای نوشتن از طریق insert و یا update و یا دستورات مشابه بهینهسازی شده است، ذخیره میگردد. دلیل این امر نیز آن است که پایگاههای داده برای خواندن و نوشتن نیازهای متفاوتی دارند و این امر به تسریع در ورود اطلاعات و خواندن آن کمک میکند. هرچند به جهت تاخیر در بروزرسانی پایگاه داده مربوط به خواندن، میتواند منجر به ارائه پاسخ قدیمی گردد که این امر را Eventual consistency مینامند.
در شیوه معماری معمول نرمافزار که به صورت درخواست – پاسخ میباشد سرویسها به طور متوالی فراخوانی و اجرا میشوند و هر سرویس تنها زمانی خوانده و اجرا میشود که پاسخ در مرحله قبلی دریافت شده باشد. بنابراین در صورت وقوع مشکل در یک نقطه از این فرایند کار متوقف میماند و مابقی سرویسها فراخوانی نمیگردند؛ ولی در معماری رویدادمحور (EDA) همه سرویس ها خوانده میشوند و صفی از پیامها برای آنها درست میشود. در صورت وقوع رویداد موردنظر برای هر سرویس آن سرویس وظیفه خود را انجام میدهد و مستقل از سرویسهای دیگر عمل میکند. بدین معنا که برای فراخوانی و اجرا منتظر به نتیجه رسیدن کار سرویس قبلی نمیماند؛ بلکه از همان ابتدا اجرا شده و تنها منتظر وقوع رویداد موردنظر برای پردازش پیام است.
معماری بدون سرور بدان معنا است که به جای راهاندازی و یا اجاره یک فضا بر روی سرور که همیشه منتظر دریافت تقاضا از سمت فرانت اند نرمافزار است تنها زمان فراخوانی از سوی کاربر سمت سرور نرمافزار فعال گردد و هزینهها نیز بر حسب میزان زمان پردازش از سوی شرکتهای خدماتدهنده محاسبه گردد. برای مثال در معماری معمول در جانب سرور معمولاً یک خط کد به صورت زیر داریم:
2. app.listen( 3000, () => { console.log("Server running on port 3000"); });
اما در معماری بدون سرور نیازی به اجرای دائمی برنامه نیست. در عوض، یک تابع فقط هنگام دریافت درخواست اجرا میشود و بعد از انجام کار خاموش میشود.
رویکرد API اول بدین معناست که شروع کدنویسی برای نرمافزار از API شروع شود. از اینرو API اهمیت بسیاری در این نوع معماری پیدا میکند و در مرکز کار قرار میگیرد. همچنین رعایت استانداردهای مخصوص برای نوشتن آن نظیر OPENAPI، اهمیت بیشتری پیدا میکند تا به صورت reuseable و منعطف طراحی گردد و زمان بیشتری برای تفکر دربارهی طراحی یک API نیاز است. چون هر بخشی از نرمافزار که زودتر نوشته شود احتمالاً تغییرات بیشتری در طول حیات خود خواهد داشت. این رویکرد نیازمند توسعهی APIهایی است که یکپارچه و قابل استفادهی مجدد باشند و این امر با استفاده از یک زبان توصیف API میسر میشود تا قراردادی برای نحوهی عملکرد API تعیین شود.
به معنای طراحی دامنه محور است. در این رویکرد به جای آنکه طراحی از نیازهای فنی شروع شود از شناخت نیازهای تجاری و مشکلات واقعی کسب و کار و طراحی دقیق دامنه کسب و کار شروع میشود. شناخت دامنه کسب و کار به دو طریق در شکلگیری ساختار نرمافزار نقش دارد. یک تعریف زمینههای محدود (bounded context). بدین معنا که نرمافزار به چه بخشهایی تقسیم گردد و چه ماژولهایی داشته باشد. مثل تقسیم یک نرمافزار فروش انلاین به بخشهای مدیریت محصولات، مدیریت سفارش، پرداخت و ارتباط با مشتری دوم تعریف نقشه برداری زمینه (context mapping) بدین معنا که روابط حاکم بر بخشهای مختلف را تعریف میکند. مثل آنکه بگوییم برای آنکه یک سفارش تایید شود باید پرداخت انجام شده باشد.
هدف این معماری این است که هستهی نرمافزار از جزئیات فنی کاملاً مستقل باشد و از طریق پورتها و آداپتورها با دنیای بیرون ارتباط برقرار کند. پورت مانند آن است که یک تابع آبسترکت از پرداخت تعریف نماییم. ولی آداپتر یک پیادهسازی از آن پرداخت است. مثل پیادهسازی پرداخت از طریق یک درگاه بانکی. حال هروقت که در هسته بخواهیم به پرداخت اشاره کنیم از پورت استفاده میکنیم و به پیادهسازی آن کاری نداریم. لذا هر موقع که بخواهیم فناوری پرداخت را عوض نماییم این کار به راحتی انجام میشود و هیچ خللی در عملکرد هسته ایجاد نمیشود و این امر نرمافزار را منعطفتر و تغییرات در آن را سادهتر مینماید.
به معنای رویداد محور بودن بدین معناست که به جای ذخیره وضعیت فعلی، مجموعه رویدادهایی که منجر به تغییر داده میشوند ذخیره گردد. بدین ترتیب وضعیت فعلی را میتوان از طریق دنباله رویدادها محاسبه نمود، بدون آنکه مقدار فعلی آن را ذخیره نماییم. بدین ترتیب تاریخچه تمام تغییرات ثبت میگردد و تراکنشها بر روی داده قابل مشاهده و بررسی خواهد بود. اگر شرط انجام تراکنش مستقل از مقدار متغیر باشد و بدان وابستگی نداشته باشد با این روش مشکل به روزرسانی متغیر در پردازشهای موازی که قفلگذاری داده را در پایگاه داده الزامی میساخت برطرف میگردد و تراکنشها سریعتر انجام میشوند.
پلتفرمهایی هستند که رابطهای گرافیکی مانند مؤلفههای کشیدنی و رهاکردنی فراهم میآورند تا امکان تهیه نرمافزارهایی چون صفحات وب و یا اپلیکیشنهای موبایل با قابلیت تعامل با کاربر بدون نوشتن کد یا با حداقل نیاز به نوشتن کد فراهم گردد. در حالت low-code امکان افزودن فیچرهای پیشرفتهتر از طریق کد نویسی فراهم میگردد. ولی در حالت no-code ممکن است با محدودیتهایی در ایجاد حالتهای سفارشی مواجه گردیم. Webflow از پرکاربردترین نرمافزارهای no-code و Microsoft PowerApps از پرکاربردترین نرمافزارهای low code هست. بین این پلتفرمها با نرمافزارهایی چون wordpress که از طریق قالبهای آماده میتوانند صفحات وب را به سرعت طراحی نمایند و در سیستم مدیریت محتوا قرار میگیرند باید تفکیک قائل شد.
سیستمهای مدیریت فرآیند کسبوکار مجموعهای از ابزارها و فناوریها هستند که به سازمانها کمک میکنند تا فرآیندهای تجاری خود را مدلسازی، اجرا، نظارت و بهینهسازی کنند. سیستمهای مدیریت فرایند کسب و کار ذاتاً ارتباطی به نرمافزار ندارند و برای شناخت و طراحی روالهای کسب و کار در داخل یک سیستم یا سازمان هستند. اما زمانی که بخواهیم فرایندهای داخل یک سازمان را الکترونیکی نماییم و با سیستمهای نرمافزاری یکپارچه نماییم ناگزیر از آشنایی و بکارگیری آن هستیم. برای مثال اگر بخواهیم فرایند پرداخت وام توسط یک بانک را الکترونیکی نماییم ابتدا باید بدانیم فرایند پرداخت بانک در آن سازمان چه مراحل و روالی دارد و شرایط ورود به هر مرحله و اتمام آن چیست.
مکانیسمی برای امکان برقراری ارتباط غیرهمزمان بین دو سیستم است. بدین صورت که سیستم درخواست دهنده پس از ارسال تقاضا لازم نیست منتظر پاسخ بماند و میتواند کارهای دیگری را انجام دهد. در صورتی که دادههای تبادل شده به صورت پیوسته و لحظهای باشد مثل درخواستهای خرید ار سوی کاربران داده از نوع جریانی و ابزار kafka برای آن مناسب است. در صورتی که دادهها به صورت انبوه و در زمان مشخص جمعآوری و پردازش میشوند مثل گزارشگیری در پایان ساعت کاری داده از نوع دستهای و باز از ابزار Kafka به کمک Spark یا Flink برای آن استفاده میشود. برای پردازش پیامهای فوری و کوتاه مدت نیز ارسال ایمیلهای تاییدیه نیز از RabbitMQ استفاده میشود.
کوبرنتیز یک ابزار قدرتمند برای مدیریت کانتینرهاست که بهطور خودکار کانتینرها را اجرا، مقیاسگذاری و هماهنگ میکند. این پلتفرم میتواند نسخههای متعددی از یک کانتینر را راهاندازی کرده و آنها را روی هستههای مختلف سرورها توزیع نماید. در مواقعی مانند خرابی (Crash) یک کانتینر یا افزایش ترافیک، Kubernetes به صورت خودکار نسخههای جدیدی را راهاندازی میکند تا بار کاری متعادل شود. همچنین این سیستم قابلیت بازیابی خودکار دارد و اطمینان حاصل میکند که کانتینرها بهموقع اجرا شوند، با هم هماهنگ باشند و بهراحتی همدیگر را شناسایی کنند و با هم ارتباط برقرار نمایند. مقیاسگذاری کانتینرها به دو روش انجام میشود. روش اول روش افقی است که تعداد کانتینرها افزایش مییابد. این قابلیت در Kubernetes وجود دارد. روش دوم به صورت عمودی است که منابع اختصاصی مانند CPU و RAM را افزایش میدهیم. این روش در Kubernetes به طور پیشفرض فعال نیست و از طریق تنظیمات و نصب یک افزونه قابل دستیابی است. هرچند ممکن است به ریستارت کردن دستگاه نیاز باشد و برای سیستمهای حساس که نمیتوانند قطع گردند مناسب نیست.
معماری چند مستأجری مانند برنامههایی چونGMail به این صورت عمل میکند که کاربران مختلف از یک زیرساخت نرمافزاری مشترک بهره میبرند، اما دادههای هر یک بهصورت مجزا ذخیره میشود و هیچ کاربری به اطلاعات دیگران دسترسی ندارد. در این مدل این امکان وجود دارد این قابلیت را فراهم نمود هر کاربر میتواند تنظیمات خاص خود را اعمال کرده، ظاهر برنامه را شخصیسازی کند و تجربه کاربری منحصربهفردی داشته باشد. این معماری به دلیل استفاده بهینه از منابع سرور و زیرساخت، امکان پشتیبانی از تعداد زیادی کاربر را با هزینه کم فراهم میسازد. همچنین، نگهداری، بهروزرسانی و مقیاسپذیری نرمافزار سادهتر شده و تیم توسعه میتواند تغییرات را بهصورت یکپارچه پیادهسازی کند. در مدلهای رایج در این زمینه پایگاه داده و اسکیمای نرمافزار میتواند برای کاربران جداگانه و یا مشترک تعریف گردد.
الگوهای یکپارچهسازی سازمانی الگوهایی هستند که در سطح معماری برای اتصال نرمافزارهای مختلف یک سازمان معرفی میگردند؛ مثل اتصال سیستم حسابداری یک فروشگاه با نرمافزار انبار و نرمافزار فروش آنلاین که در صورت عدم به کارگیری این الگوها باید به صورت دستی توسط کارکنان وارد شوند و امکان خطا وجود دارد. لذا به صورت مفاهیم مطرح میگردند و نه جزئیات فنی و میتوانند روی هر الگوی نرمافزار اعم از JSON، SOAP، Kafka، RabbitMQ و ..... اعمال گردند. مثل الگوی Content Based Rout که بر اساس محتوای پیام باید تصمیم گرفت پیام به کدام سرویس هدایت گردد.
