بارها شده به مشکلات مربوط به راهاندازی زیرساخت برای توسعه نرمافزار برخورده باشیم و در ادامه این مشکلات، زمان و هزینهای را از دست دادیم که میتوانستیم آن را صرف توسعه نرمافزار و یا کارهای مفید دیگری کنیم. مشکل زمانی شدیدتر میشود که این امر تکرار پذیر شود که در اغلب موارد سراغ نوشتن اسکریپتهایی میرویم که این فرآیند را هموارتر کنند. ایدهی "کد" به جای "نصب زیرساخت به صورت دستی" از همین مشکلات سرچشمه میگیرد. مفهوم Infrastructure as Code (IaC) بیان میکند برای راهاندازی زیرساخت از کدها استفاده شود. مزایای زیادی برای اینکار شمرده میشود که به چندی از آنها اشاره میکنیم:
ابزارهای مختلفی برای تسهیل اجرایی کردن ایدهی IaC وجود دارند که از معروفترین آنها میتوان به Ansible و Terraform اشاره کرد.
دو مفهوم API Gateway و Service Mesh در کنار هم عمدهی تعاملات بین سرویسی و کلاینت-سرویسی را در نرمافزار شکل میدهند. API Gateway نقطهی ورود درخواستها به نرمافزارهای میکروسرویسی و یکپارچه (Monolithic) میباشد که به صورت خاص در معماری میکروسرویس نقش مهمی را ایفا میکند. API Gateway جلوی درخواستهای کلاینت قرار میگیرد. کلاینتها (موبایل اپلکیشنها و یا وباپلیکیشنها) به جای آنکه مستقیما با سرویسها صحبت کنند، درخواست خود را به API Gateway میدهند. API Gateway در قدم اول درخواستها را به سرویس مورد نظر Route میکند و در این بین میتواند بار روی سیستم را مدیریت کرده و با استفاده از الگوریتمهای Load Balancing، بار درخواستها را بین سرویسها پخش کند. همچنین API Gateway میتواند لایهای برای احراز هویت (Authentication و Authorization) درخواستها باشد تا درخواستهای غیر مجاز، لایهی سرویسهای نرمافزار را تحت تاثیر قرار ندهند. همچنین API Gateway میتواند با مدیریت تعداد درخواستها و اعمال Rate Limit و یا ایجاد صف برای درخواستها، حجم درخواستهایی که به سرویسها میرسد را مدیریت کند. در ادامهی مدیریت حجم درخواستها میتوان با تعریف درخواستهای پر تکرار که عموما جواب یکسانی دارند، لایههایی از کش تعریف کرد تا بتوان پردازشهای تکراری در سطح سرویس را تا حد خوبی کاهش داد.
در کنار ارتباط بین کلاینت و سرویس، ارتباط بین سرویسی را داریم. جایی که لازم است سرویسها همدیگر را پیدا کنند و در ارتباطی پایدار و امن اطلاعات را منتقل کنند. Service Meshدر اصل یک لایهی زیربنایی میباشد که ارتباط بین سرویسی را تسهیل میکند. از فواید استفاده از Service Mesh میتوان به موارد زیر اشاره کرد:
ابزارهای مختلفی برای API Gateway و Service Mesh وجود دارند که میتوان به nginx و Consul اشاره کرد.
عمده درخواستهایی که در نرمافزار به سمت سرویسها ارسال میشوند در دو دسته مجزا تقسیم میشوند:
بعضی وقتها پیش میآید که ساختاری برای دیتابیس طراحی شده است که نوشتن بر روی دیتابیس آسان است اما خواندن از دیتابیس به همان میزان پیچیدگی دارد. ممکن است با کمی افزایش پیچیدگی در نوشتن، پیچیدگی خواندن را کاهش دهیم و همواره درحال trade-off برای این موضوع باشیم. حال آنکه CQRS الگویی را معرفی میکند که بتوان پیچیدگی این مسئله را کمی تقلیل داد. در CQRS عنوان میشود که دیتابیس مربوط به خواندن اطلاعات از دیتابیس مربوط به ذخیره اطلاعات جدا باشد و این دو دیتابیس با الگوریتمهای مشخصی با هم سینک شوند.
در معماری مبتنی بر رخداد سیستمها از طریق واکنشها (Events) با یکدیگر تعامل میکنند. به عبارت بهتر سیستمها به جای آنکه با یکدیگر به صورت مستقیم ارتباط برقرار کنند از واسطهایی استفاده میکنند. این ارتباط بیشتر برای اعلام اتفاقی در سامانه استفاده میشود. برای مثال: کاربری ساخته شد. گروهی حذف شد. احراز هویت شخصی با موفقیت انجام شد. کالایی به سمت مشتری ارسال شد.
رخدادها ویژگیها منحصر به فردی دارند. اول آنکه مقصد آنها توسط فرستنده مشخص نیست. چرا که فرستنده پیامی را مخابره میکند و این گیرندگان هستند که مطابق نیاز به دنبال آن درخواست میروند. دوم آنکه ممکن از چند گیرنده آن پیام را دریافت کنند و سوم آنکه فرستنده به جواب مخابره پیام خود از طریق گیرندگان نیازی ندارد.
استفاده از معماری مبتنی بر رخداد سرعت توسعه را افزایش و وابستگی (coupling) بین سرویسها را کاهش میدهد.
برای پیادهسازی Event-Driven Architecture ابزارهای متعددی وجود دارد که از معروفترین آنها میتوان به Kafka و RabbitMQ اشاره کرد.
در معماری Serverless پیچدگیهای مربوط به استقرار نرمافزار بر روی سرور از چشم توسعهدهندگان پنهان میماند. این موضوع به این معنی نیست که هیچ سروری وجود دارد. زیرساختهای وجود دارد که توسعه تنها با نوشتن کد (یا حتی چند کلیک) میتواند زیرساخت لازم برای توسعه خود را فراهم کند. در این حالت توسعه دهندگان صرفا بر توسعه تمرکز میکنند.
در بعضی موارد ارائه خدمات به صورت رخداد محور میباشد به این صورت که پس از ایجاد یک رخداد، نرمافزاری اجرا میشود، کاری را انجام میدهد و در نهایت خاموش میشود که در اینجا Serverless Architectureها میتوانند مفید باشند چرا که منابع را میتوانند مدیریت کنند، تخصیص دهند و آزاد کنند.
از مزیتهای معماری Serverless میتوان به خودکارسازی فرآیندها، کمک به مقیاسپذیری بهتر سامانه و افزایش کارایی توسعه اشاره کرد چرا که حجم کاری با حذف دغدغههای مربوط به سرور کاهش مییابد و تمرکز بر روی توسعه میرود.
رویکرد API-First به فرآیندی اشاره دارد که در آن توسعهی APIها در اولویت قرار میگیرد. این رویکرد در سازمانهایی استفاده میشود که تعداد سرویسهای زیادی از طریق API با هم ارتباط برقرار میکنند. زمانی این رویکرد اتخاذ میشود که ساختار ارتباطی بین سرویسها اهمیت زیادی دارد و قرار است چند تیم به طور موازی با یکدیگر ویژگی خاصی را توسعه دهند. اگر ساختار دادهی ارتباطی مشخص نباشد ممکن است توسعهها ناهمگون پیش روند و سیستم متحمل هزینههای زیادی شود.
در این رویکرد، مقیاسپذیری سامانه به دلیل آنکه کانالهای ارتباطی مستند و دقیق هستند افزایش پیدا میکند و توسعه به راحتی انجام میشود و سرعت توسعه افزایش پیدا میکند. یکی از دلایل این امر ایجاد بستری است که باعث میشود تیمها به صورت مستقل و موازی با هم توسعه دهند.
مدل طراحی DDD توسط Eric Evans برای توسعه نرمافزارها مبتنی بر دامنه کسب و کار معرفی شد. تمرکز اصلی این مدل، طراحی برای کسب و کاری است که قرار است برای آن نرمافزار تولید شود و در ادامه بتوان دامنههای موجود در کسب و کار را بر روی نرمافزار نگاشت کرد. مفاهیم مختلفی در مدل طراحی DDD مطرح میشود که میتوان به آنها اشاره کرد:
مدل دامنه: مدلی که مفهومی از مسائل کسب و کار را نشان میدهد و فرآیندهای آن را شرح میدهد.
زبان مشترک: ایجاد یک زبان مشترک بین توسعهدهندگان و افراد کسب و کار برای شرح بهتر مسئله
مرزها (Bounded Context): تقسیم بندی دامنه به بخشهای مختلف و ایجاد مرزهایی برای جداسازی آنها برای آنکه مشخص باشد هر دامن به صورت مجزا چطور کار میکند.
اشتراکات (Shared Kernel): لازم است دامنهها بتوانند با یکدیگر ارتباط برقرار کنند و ممکن است اشتراکاتی با یکدیگر داشته باشند. این اشتراکات که به نوعی دامنهای جدید را شکل میدهند را Shared Kernel میگویند.
معماری Hexagonal به جداسازی منطق برنامه از ماژولهای جانبی مانند Databaseها اشاره دارد. این معماری را Ports and Adapters Architecture نیز مینامند. Portها interfaceهای استاندارد و پایداری هستند که راه ارتباطی منطق برنامه با دنیای بیرون هستند و Adapterها پیادهسازی مربوط به این portها. از مزیتهای این مدل معماری میتوان به انعطافپذیری سیستم اشاره کرد چرا که به راحتی میتوان ماژولهای خارجی را جابجا کرد بدون آنکه معماری داخلی منطق نرمافزار تغییری کند. همچنین امکان تست نوشتن بهتری برای نرمافزار فراهم میشود زیر میتوان بدون هیچگونه وابستگی به ماژولهای خارجی منطق برنامه را تست کرد و عملکرد آن را ارزیابی کرد. همچنین در فرآیند استقرار محصولاتی با معماری Hexagonal تسهیل میشود. چرا که به راحتی میتوان بدون آنکه interfaceهای قبلی تغییر کند interfaceهای جدیدی را به سامانه اضافه کرد. تا ماژولهای جدید بتوانند با آن ارتباط برقرار کنند. و اگر interfaceای deprecate شود به راحتی و به مرور زمان میتوان آن را حذف کرد.
در اکثر نرمافزارهایی که توسعه داده میشود آخرین وضعیت هر شی درون دیتابیس ذخیره میشود و این مدل ذخیرهسازی با CRUD مدیریت میشود که علاوه بر insert ما عملیات update و delete را برای ایجاد تغییر در دیتابیس داریم. اما در Event Sourcing مفهومی معرفی میشود که برای ایجاد تغییر در دیتابیس فقط عملیاتی insert را خواهیم داشت و تنها تغیرات مربوط به اشیاء ذخیره میشود و برای دریافت اطلاعات اشیاء لازم است تمامی تغییرات مربوط به اشیاء را که در دیتابیس ذخیره شده را ادغام کرد تا به شی اصلی برسیم. از محدودیتهای این روش میتوان به عملیات Read اشاره کرد که با ترکیب Event Sourcing و CQRS تا حد خوبی این مشکل بر طرف میشود. از مزایای این روش میتوان به Auditability اشاره کرد که تمامی تغییرات در طول زمان قابل دستیابی میباشد.
پلتفرمهای زیادی تحت عنوان Low-code/No-code platforms مطرح شدند که فرآیند تولید نرمافزار را به راحتی drag-and-drop کامپوننتها کردند. با استفاده از این نرمافزارهای میتوان هزینهها را کاهش داد، نرمافزارها را با سرعت بیشتری تغییر داد و به راحتی تستشون کرد. این پلتفرمها به صاحبان کسب و کارهای کوچک که توسعهدهنده ندارند کمک میکند که بتواند به راحتی نرمافزار خود را با دانش ابتدایی توسعه دهند.
این پلتفرمها عمدتا برای افرادی مناسب است که دانش پیچیدهای از توسعه نرمافزار ندارند ولی برای کارهای خاص منظوره میخواهند نرمافزاری را توسعه دهند و سریع به خروجی برسند.
از پلتفرمهای Low-code میتوان به OutSystems، Mendix و Appian اشاره کرد.
از پلتفرمهای No-code نیز میتوان به Wix، Bubble و Airtable اشاره کرد.
فرآیندهای مختلفی در سازمانها اجرا میشود که هرکدام نیازهای خاص منظوره خود را دارند. BPMSها کمک میکنند که بتوانیم فرآیندهای سازمان را تعریف و یا مدل کنیم به این منظور که بتوانیم آنها را پایش کنیم و گلوگاهها را شناسایی کنیم و بهبودشان بدهیم. همچنین BPMSها امکان خودکارسازی فرآیندهای سازمانی را تسهیل میکنند و جریانات کاری به صورت خودکار و بدون دخالت انسان کار خود را انجام میدهد. استفاده از BPMSها باعث کاهش هزینه و افزایش شفافیت و نظارت بهتر بر روی فرآیندها توسط مدیران میشود. BPMSها به نوعی زیرساختی برای اتصال ابزارها و یونیتهای کاری مختلف در سازمانها میباشند و با تعریف فرآیندهای کاری بهینه میتوانند پیچیدگیهای ارتباطی در سازمانها را به طور موثر کاهش دهند.
صفها کمک به ارتباطات آسنکرون بین سرویسها میکنند. زمانی حجم درخواستهای بالایی برای پردازش وجود دارد، لازم است آنها جایی ذخیره شوند و به ترتیب اولویت اجرا شوند بدون آنکه اختلالی در عملکرد سیستم به وجود بیاید. از مزیت تکنولوژیهایی مثل Kafka و RabbitMQ میتوان به تضمین Delivery اشاره کرد. به این صورت که پیامی که تحویل این تکنولوژیهای میشود تا زمانی که به موفقیت در سامانه مقصد اجرا نشود از صف پاک نمیشود و بارها برای اجرای آن تلاش میشود. مثلا اگر سرویسی خاموش باشد، صف تا زمانی که آن سیستم روشن شود پیام را در خود نگه میدارد. صفها در معماری رخداد محور (EDA) که پیشتر به آن اشاره کردیم استفاده میشوند و میتوانند رخدادها را به سرویسهای دیگر منتقل کنند.
کانتینرها با ایزولهسازی محتوای اجرای استقرار را راحتتر از قبل کردند. اما بعضا افزایش تعداد کانتینرها، مدیریت آنها را پیچیده میکند. ابزارهایی مانند Kubernetes با ارائهی امکاناتی مدیریت این کانتیرها را راحتتر میکنند. از مزیتیهای آن میتوان به مدیریت تعداد کانتینرها بر اساس میزان حجم درخواستها اشاره کرد که با افزایش تعداد درخواستها، تعداد کانتینرهای مربوطه به صورت خودکار افزایش مییابد. از دیگر مزایای Kubernetes میتوان به مدیریت منابع اشاره کرد به این صورت که میتواند کانتینرها را بر اساس میزان منبعی که مصرف میکنند در سرورهایی که ظرفیت باز دارند اجرا کند. همچنین این ابزارها میتوانند وضعیت سیستم را پایش کنند و در صورت ایجاد خطا رفتار مناسبی که برایشان تعریف شده را اجرا کنند.
بعضا پیش آمده که میخواهیم یک محصول را به چند مشتری ارائه دهیم. در اینجا لازم است که به ازای هر مشتری یک نسخه از نرمافزار را نصب شود که ممکن از هزینههای مربوط به سختافزار افزایش پیدا کند و صرف اقتصادی نداشته باشیم. Multi-Tenancy Architecture مفهومی را معرفی میکند که در آن با استفاده یک نسخه از نرمافزار میتوان به چند مشتری خدمت ارائه دهیم. فواید و مضراتی برای این مدل معماری گفته میشه که از فواید آن میتوان به کاهش هزینه زیرساخت و سهولت استقرار اشاره کرد و از مضرات آن میتوان به خطرات امنیتی اشاره کرد. چرا که اگر نرمافزار به درستی پیادهسازی نشود ممکن است اطلاعات مشتریهای مختلف به یکدیگر نمایش داده شود که مطلوب نیست.
تعدد سیستمها و سامانهها در سازمانها منجر به الزام ایجاد یکپارچگی در برخی لایهها برای مدیریت بهتر آنها میشود. الگوهای مختلفی برای یکپارچهسازی سامانهها مطرح میشود که به چند نمونه از آنها اشاره میشود:
الگوی Hub-and-Spoke: در این الگو یک هاب مرکزی به عنوان واسط بین سیستمهای مختلف عمل میکند.
الگوی Publish-Subscribe: این الگو زمانی مفید که بعد از ایجاد یک رخداد در سامانه لازم است چند سرویس بروزرسانی شوند
الگوی Message-Oriented Middleware: این الگو زمانی استفاده میشود که به ارسال اطلاعات به صورت آسنکرون نیاز داریم با تضمین Delivery پیام به سامانه مقصد و امکان ذخیرهسازی پیام تا زمانی که پردازش نشده است.
