راهنمای پروژه‌های متوسط به بالا در سال 2019

در سال‌های اخیر پروژه‌های نرم‌افزاری بزرگ‌تر، پیچیده‌تر و دارای نیازمندهای بیشتری شده‌اند. شاید در دهه‌‌های قبلی یک پروژه‌ی نرم‌افزاری شامل چند صد نفر ساعت کار و حجم دیتابیس پروژه بیش از یک گیگابایت نبود اما این روزها کار کردن بر روی پروژه‌های با چند ده هزار ساعت نفر کار و حجم دیتابیس ترابایتی حتی در ایران هم یک امر مرسوم و متداول شده است. با هم نیم‌نگاهی به تکنولوژی‌های مطرح و معروف سال 2019 برای انجام یک پروژه‌ی متوسط و یا بزرگ می‌اندازیم.

معماری کلی نرم‌افزار

معماری پیشنهادی برای وب سایت‌های جدید مبتنی بر مایکروسرویس، داکر و تحت مدیریت نرم‌افزار Kubernetes می‌باشد.

استفاده از معماری مایکروسرویس امکان ماژولار کردن نرم‌افزار را فراهم می‌آورد. به دلیل ماهیت مستقل سرویس‌ها می‌توان با توجه به نیاز هر کدام از آنها را به صورت جداگانه Replicate‌ و به سادگی در گلوگاه‌های سیستم Load Balance‌ ایجاد کرد. همچنین طراحی، توسعه،‌ تست و Publish هر کدام از سرویس‌ها به طور مستقل انجام می‌پذیرد که این موضوع هزینه‌های توسعه و نگهداری سیستم را به طور عمده کاهش می‌دهد.

این روزها بروزرسانی و انتشار نرم‌افزار بدون استفاده از داکر کاری سخت و طاقت‌فرسا به شمار می‌رود. با استفاده از داکرایز کردن پروژه انتشار هر قسمت از پروژه به سادگی امکان‌پذیر می‌شود و اختلاف اجرا در محیط‌های عملیاتی به نسبت محیط Develop به حداقل می‌رسد.

برای مدیریت، بروزرسانی و ایجاد Load Balance بر روی کانینترها سیستم Kubernetes پیشنهاد می‌شود. کوبرنتیز یک سیستم متن باز می‌باشد که اولین برای توسط گوگل ایجاد و برای مدیریت هزارسرور و ده هزار کانتینر داکر مورد استفاده قرار گرفته است.

پیاده‌سازی یک سیستم CI/CD مناسب و ایجاد فرهنگ DevOps نیز زمان و هزینه‌ی نگهداری و توسعه نرم‌افزار را به اندازه‌ی قابل توجهی کاهش میدهد.

الگوی طراحی چند مستاجری

از جمله الگوهای طراحی مورد توجه این روزهای جامعه نرم‌افزاری میتوان به معماری چند مستاجری اشاره کرد. برای پروژه‌ها در دو سطح معماری چند مستاجری (Multi tenancy) می‌تواند مفروض واقع شود.

این الگوی طراحی دو پیاده‌سازی متفاوت دارد: 1-جداسازی دیتابیس، 2-جداسازی اسکیما.

در جدا سازی دیتابیس هر محصول دیتابیس، دیتا و لایه‌ی ارائه‌ی کننده‌ی دیتا خود را دارد، اما یک سرویس و هسته‌ی مشترک تمام عملیات را کنترل می‌کند.

در مدل جداسازی اسکیما تنها لایه‌ی ارائه‌کننده‌ی دیتا متفاوت است ولی همه از یک دیتابیس و هسته‌ی مشترک استفاده می‌کنند. به طور مثال اگر چندین فروشگاه اینترنتی متفاوتی دارید که هر کدام وب سایت و اپ متفاوت خود را دارند اما تمام فروشگاه‌ها هسته و دیتابیس یکسان دارند.

انتخاب فریمورک اصلی سیستم

پیشنهاد معماری اپلیکیشن اصلی استفاده از Web API و جداسازی کامل Back-End و Front-End می‌باشد. سرویس‌های شما به طور همزمان می‌توانند به تمام اپلیکیشن‌های موجود از جمله Front-End، اپلیکیشن‌های موبایلی و دیگر سیستم‌ها سرویس ارائه دهند.

از بین زبان‌های معروف و فریمورک‌های مختلف چند گزینه برای پیاده‌سازی اپلیکیشن اصلی سایت پیشنهاد می‌شود.

ASP.NET Core + grpc

فریمورک جدید مایکروسافت Cross Platform و Open Source است. سرعت و Performance این فریمورک همپا با سریع‌ترین زبان‌ها مانند Go می‌باشد. تعداد برنامه‌نویس زیاد این فریمورک در ایران از دیگر مزایای آن برای شرکت‌های خصوصی می‌باشد.

همچنین پیشنهاد می‌شود که به جای استفاده از Rest API از تکنولوژی grpc استفاده شود. grpc به جای HTTP1.1 از HTTP 2.0 استفاده می‌کند. همچنین استفاده از ProtoBuf به جای JSON (استفاده از نقل و انتقال باینری دیتا به جای String) موجب بهبود سرعت و علمکرد این تکنولوژی به نسبت Rest API شده است. همچنین در grpc امکان stream دو طرفه برای کلاینت و سرور نیز وجود دارد.

Node.js + GraphQL

علاوه بر فریمورک ASP.NET Core، گزینه‌ی جایگزین پیاده‌سازی با Node.js است. به دلیل ماهیت ذاتی Node.js تولید نرم‌افزار با این فریمورک سریع‌تر و به دور از پیچیدگی‌های مرسوم ASP.NET می‌باشد. همچنین پیشنهاد می‌شود که از GraphQL برای پیاده‌سازی APIهای سرویس‌ها استفاده شود. GraphQL به کلاینت‌ها اجازه می‌دهد که تنها فیلدها و دیتاهای مورد نیاز خود را از سمت سرویس دریافت کنند و تنها مبتنی بر سرویس‌های آماده شده در سمت Back End نباشند.

Front End:

مارکت Front End در چند سال اخیر در قبضه‌ی سه کتابخانه Angular، React و Vue بوده است. هر سه این کتابخانه نقاط قوت و ضعف خود را دارند. به توجه به کارایی، منحنی یادگیری و ترند این روزهای دنیا برنامه‌نویسی استفاده از کتابخانه Vue.js برای طراحی Front End پایگاه پیشنهاد می‌شود. همچنین ظاهر پایگاه باید Responsive باشد و از PWA پیشتیبانی کند.

دیتابیس اصلی سیستم

چند گزینه‌ی متفاوت برای انتخاب اصلی دیتابیس سیستم مطرح می‌باشد. بخشی از فرآیند انتخاب دیتابیس توجه به نوع کسب و کار و داده‌های آن است. در اصل دیتابیس باید پاسخگوی نیازهای کسب و کار شما باشد.

یکی از پیشنهاد‌های اصلی برای انتخاب دیتابیس استفاده از پایگاه‌داده MSSQL Server نسخه 2017 یا 2019 می‌باشد. این دیتابیس بنابر گزارش گارتنر در جایگاه بالاترین کارایی و رهبری بازار در حوزه‌ی دیتابیس است. علاوه بر قابلیت‌های بی‌شمار MSSQL Server امکان Always On آن که از نسخه‌ی 2017 اضافه شده است امکان ایجاد کپی‌های چندتایی فقط خواندنی از دیتایبس اصلی فراهم می‌آورد. این کپی‌ها می‌توانند به صورت همزمان/غیر همزمان تهیه شوند و در یک یا چند مرکز داده‌ی مختلف نگهداری شوند.

قابلیت Always On این امکان را فراهم می‌آورد که معماری CQRS را در سطح دیتابیس با پیچیدگی کم پیاده‌سازی کنیم و خواندن اطلاعات را نه از دیتابیس اصلی بلکه از دیتابیس‌های Read Only انجام دهیم و بدین صورت بار خواندن را از روی دیتابیس اصلی برداریم. همچنین می‌توانیم از این دیتابیس‌های بدون اختلال از پایگاه اصلی برای گزارش‌های مدیریتی و یا پردازش‌های متن کاوی استفاده کنیم.

همچنین قابلیت‌های بیشمار دیگر مانند Column Store Index و پشتیبانی از JSON ترکیب کارایی و اطمینان بالایی را برای استفاده‌کنندگان آن فراهم می‌آورد.

دیتابیس MongoDB پیشنهاد دوم برای ذخیره و بازیابی اطلاعات است. پشتیبانی بهتر از دیتاهای سندگرا و همچنین وجود ایندکس‌های خودکار و امکان توسعه افقی از مزایای MongoDB می‌باشد.

موتور جستجو

با توجه به اقبال جهانی، کارایی و عملکرد فوق‌العاده موتور جستجوی پایگاه موتور جستجوی الاستیک بهترین گزینه برای موتور جستجوی سیستم می‌باشد . جستجو‌ها، نمایش لیست‌ها و مدیریت فست‌ها را با خیال راحت می‌توان به این موتور جستجو واگذار کرد.

Object Storage:

در سامانه‌های جدید اطلاعاتی، نیازمند سیستم فایلی هستیم که هر نوع موجودیت فایلی را به صورت یک شیء منحصر بفرد ذخیره کند یعنی همزمان بتواند عکس، فیلم، صدا، مستندات و سایر انواع فایل را به راحتی و به صورت یک شی با شناسه و خصوصیات خاص خود، ذخیره و بازیابی کند. نیز قادر باشد مشابه تمامی سامانه های نوین که از طریق REST API خدماتشان را به سایرین ارائه می‌کنند، از طریق یک درخواستHTTP ، بدون نیاز به یک وب سرور بتوانیم با فایلها کار کرده، آنها را ذخیره و جستجو کنیم. این نوع از سیستم‌های فایل که به آنها Object Storage می گوئیم در مقابل سیستم‌های فایل سنتی که به سیستم های File level معروفند، قرار می‌گیرند.در سیستم‌های File Level، هر فایل یک آدرس منحصر به فرد و یک نام دارد که از طریق آن قابل دسترسی خواهد بود. سیستم فایل بلاکی هم نوع دیگری از این گونه سیستم های فایل است که در آن هر فایل به چند بخش تقسیم شده و در تعدادی بلاک که سیستم فایل در اختیار یک فایل قرار می‌دهد، ذخیره می‌شود(منبع).

می‌توانیم برای لایه ذخیره و بازیابی از Ceph استفاده کنیم و برای ایجاد یک نمای هماهنگ از کل سیستم ازAlluxio بهره ببریم. یعنی ترکیبCeph وAlluxio را در کنار سیستم‌های فایل موجود مانند HDFS استفاده کنیم. Alluxio یک لایه کش و نهانگاه هم در حافظه ایجاد می کند که سرعت دستیابی به فایل‌ها در پشت صحنه که می تواندCeph و HDFS باشد را بسیار بهبود می‌بخشد (منبع).

هر چند به دلیل مسئولیت‌های بی‌شمار و با توجه به نیاز پروژه امکان راه‌اندازی یک سیستم مدیریت فایل بومی نیز وجود دارد. این سیستم باید با استفاده از لایه‌ی Caching، امکان مقیاس پذیری افقی، پشتیبانی از دیتای ترابایتی و .. را باید فراهم کند.

Message brokers:

در حال حاضر بین سه گزینه‌ی ActiveMQ، RabbitMQ و کافکا برای Message Brokers، نرم‌افزار RabbitMQ یک پیشنهاد مناسب می‌باشد. از دلایل انتخاب RabbitMQ د منحنی یادگیری کمتر به نسبت کافکا و منابع آموزشی بهتر میتوان نام برد (داشبود تصمیم گیری).

مثال استفاده از صف در پایگاه میتوان به ارتباط پایگاه با موتورهای جستجو، ارتباط پایگاه با Object Storage، ارتباط پایگاه با سیستم ذخیره لاگ و .. اشاره کرد.

برای گزینه‌ی دوم به دلیل امکان Stream Data برای استفاده برای لاگ و همچنین استفاده از ایندکس به جای حذف پیام، کافکا نیز گزینه‌ی قابل توجه‌ای می‌باشد.

Caching system:

برای ذخیره تمامی اطلاعات Read-only سیستم دسترسی‌های کاربر و دیتای چند زبانگی و .. استفاده از دیتابیس In Memory شرکت Redis پیشنهاد می‌شود. این دیتابیس از سیستم Key/Value استفاده می‌کند، همچنین به دلیل ذخیره اطلاعات در رم دسترسی بالا و با هزینه‌ی I/O پایین را فراهم می‌آورد.

گزینه‌های دیگر شامل دیتابیس Memcached و استفاده از قابلیت جداول In-Memory دیتابیس MSSQL Server می‌باشد.

Audit logging:

ذخیره رفتار کاربران بهترین چراغ راه توسعه سیستم در آینده می‌باشد. این امر باید از ابتدای توسعه نرم‌افزار جدی و مهم در نظر گرفته و پیاده سازی مناسبی برای آن انجام شود. استفاده از کافکا و الاستیک این روزها یکی از ترندهای اصلی ذخیره و پردازش لاگ می‌باشد.

Exception Log:

در حال حاضر استفاده از NLOG به همراه MongoDB و یا الاستیک به همراه Logstash از جمله گزینه‌های معتبر برای ذخیره سازی لاگ در سال 2019 هستند (منبع).

گزارش‌های مدیریتی

وظیفه‌ی ارائه‌ی گزارش‌های مدیریتی می تواند بر عهده‌ی سیستم Power BI باشد. نرم‌افزار Power BI بر طبق گزارش گارتنر به قدرتمندترین ابزار Self BI تبدیل شده است.

در اصل میتوان با استفاده از سیستم Dremio دیتاهای مناسب برای استفاده‌ی تحلیلی بخش‌های مختلف سازمان آماده کرد و وظیفه‌ی نمایش اطلاعات را بر عهده‌ی نرم‌افزار Power BI گذاشت.

سیستم مانتورینگ

سیستم‌های سنتی مانیتورینگ تنها زنده بودن یک پایگاه و یا یک سرویس را بررسی می‌کنند. در سیستم‌های بروزتر علاوه بر لاگ زنده موندن، بررسی SLA تعریف شده، میزان Performance هر قسمت و گزارش‌های آماری خیلی بیشتری ارائه می‌کنند.

ترند اصلی در این حوزه استفاده از Prometheus برای مانتورینگ سیستم‌ها و استفاده از Grafana برای سیستم گزارش مانتورینگ می‌باشد.