پست‌های انتشارات بینش‌های یک CTO

انواع دیتابیس‌ها در System Design

محمد حسین جلیلی — Tue, 30 Dec 2025 00:29:28 +0330

کِی از کدوم دیتابیس استفاده کنیم؟ (خیلی ساده و کاربردی)وقتی صحبت از طراحی سیستم می‌شود، یکی از اولین و مهم‌ترین تصمیم‌ها این است:داده‌ها را کجا و چطور ذخیره کنیم؟انتخاب اشتباه دیتابیس یعنی:سیستم کندهزینه‌ی بالامقیاس‌پذیری سختو در نهایت بازنویسی دردناکدر این بلاگ، قدم‌به‌قدم با نمونه‌های مختلف دیتابیس آشنا می‌شویم؛ نه با تعریف‌های دانشگاهی، بلکه با این سؤال کلیدی:«این دیتابیس دقیقاً به چه دردی می‌خورد و کِی باید سراغش بروم؟»دیتابیس‌های رابطه‌ای (Relational Databases)ایده‌ی اصلی چیست؟دیتابیس‌های رابطه‌ای داده‌ها را داخل جدول ذخیره می‌کنند.هر جدول:سطر دارد (رکورد)ستون دارد (فیلد)و یک شناسه‌ی یکتا (ID)جدول‌ها می‌توانند به هم وصل شوند؛ دقیقاً مثل اکسل، اما بسیار قوی‌تر.مثال ساده:جدول کاربرانجدول سفارش‌هاهر سفارش می‌داند متعلق به کدام کاربر است.چرا هنوز این‌قدر محبوب‌اند؟چون:ساختار مشخص دارندجلوی خراب شدن داده را می‌گیرندبرای داده‌های حساس فوق‌العاده‌انداین دیتابیس‌ها از چیزی به اسم تراکنش استفاده می‌کنند. یعنی:یا همه‌ی عملیات انجام می‌شود، یا هیچ‌کدام.این ویژگی برای پول، حساب، سفارش و پرداخت حیاتی است.کِی انتخاب درستی هستند؟اگر سیستم تو این ویژگی‌ها را دارد:داده‌ها ساختار مشخص دارندارتباط بین داده‌ها مهم استخطا در داده فاجعه استمثال‌های واقعی:سیستم‌های بانکیفروشگاه‌های آنلایننرم‌افزارهای سازمانی ( حقوق، انبار)جمع‌بندی سریعدیتابیس رابطه‌ای = نظم، امنیت، اعتماداگر شک داری، معمولاً شروع با دیتابیس رابطه‌ای انتخاب امن‌تری است. دیتابیس‌های Key-Value (کلید–مقدار)ایده‌ی اصلی چیست؟خیلی ساده:key → valueمثل یک دیکشنری بزرگ.مثال:"user:123" → { name: "Ali", theme: "dark" }نه جدول داریم، نه رابطه، نه پیچیدگی.چرا از این‌ها استفاده می‌کنیم؟چون:خیلی سریع‌اندبه‌راحتی مقیاس‌پذیر می‌شوندبرای داده‌های موقتی عالی‌اندولی حواست باشد:این دیتابیس‌ها برای تحلیل‌های پیچیده ساخته نشده‌اند.کِی انتخاب درستی هستند؟وقتی:فقط می‌خواهی چیزی را سریع ذخیره و سریع بخوانیرابطه‌ی بین داده‌ها مهم نیستسرعت از همه چیز مهم‌تر استمثال‌های واقعی:ذخیره‌ی session کاربرکش کردن اطلاعاتنگهداری توکن‌هاداده‌های لحظه‌ایجمع‌بندی سریعKey-Value = سرعت بالا، سادگی، مصرف کماگر دیتابیس رابطه‌ای مغز سیستم است، Key-Value حافظه‌ی کوتاه‌مدت آن است.دیتابیس‌های سندی (Document Databases)ایده‌ی اصلی چیست؟اینجا هر داده یک سند کامل است؛ معمولاً به شکل JSON.مثال:{ "name": "Laptop", "price": 1200, "features": ["SSD", "16GB RAM"], "reviews": [...] }هیچ اجباری نیست همه‌ی سندها دقیقاً شبیه هم باشند.چرا این انعطاف مهم است؟چون در خیلی از سیستم‌ها:داده‌ها دائم تغییر می‌کنندفیلدها اضافه یا حذف می‌شوندساختار ثابت ندارنددیتابیس‌های سندی این تغییرات را بدون دردسر می‌پذیرند.کِی انتخاب درستی هستند؟وقتی:داده‌ها نیمه‌ساختاریافته‌اندسرعت توسعه مهم‌تر از سخت‌گیری دیتابیس استمدل داده مرتب تغییر می‌کندمثال‌های واقعی:سیستم‌های محتوا (CMS)فروشگاه‌هایی با محصولات متنوعداده‌های IoTپروفایل کاربراندیتابیس‌های گرافی (Graph Databases)تا اینجا درباره‌ی جدول، کلید–مقدار و سند حرف زدیم.اما یک سؤال مهم:اگر خودِ «ارتباط» از خودِ داده مهم‌تر باشد چه؟اینجاست که دیتابیس‌های گرافی وارد بازی می‌شوند.ایده‌ی اصلی چیست؟در دیتابیس گرافی، داده‌ها به شکل نقشه‌ی ارتباطات ذخیره می‌شوند، نه جدول.سه مفهوم پایه داریم:Node (گره): موجودیت‌ها (مثل کاربر، محصول، مقاله)Edge (یال): رابطه‌ها (دوستِ، خریده، دنبال می‌کند)Property: اطلاعات اضافه روی گره یا رابطهمثال خیلی ساده:علی ← دوستِ → رضاعلی ← خریده → لپ‌تاپلپ‌تاپ ← متعلق به → برند Xاینجا «چه کسی به چه کسی وصل است» مهم‌تر از خود عددهاست.چرا دیتابیس‌های معمولی اینجا کم می‌آورند؟در دیتابیس رابطه‌ای:برای پیدا کردن ارتباط‌ها باید JOIN پشت JOIN بزنیهرچه ارتباط‌ها پیچیده‌تر شوند، کوئری‌ها کندتر و سخت‌تر می‌شونداما دیتابیس گرافی دقیقاً برای این سؤال ساخته شده:«از این نقطه، چطور به بقیه‌ی نقاط برسیم؟»کِی انتخاب درستی هستند؟وقتی:روابط چندلایه و تو در تو هستندتحلیل ارتباط‌ها مهم‌تر از ذخیره‌ی عدد و متن استسیستم باید سریع روی ارتباط‌ها حرکت کندمثال‌های واقعی و ملموسشبکه‌های اجتماعی (دوست، فالو، تعامل)سیستم‌های پیشنهاددهنده (این کاربر شبیه کیست؟)گراف دانش (ارتباط مفاهیم، اشخاص، محتوا)جمع‌بندی سریعGraph DB = قدرت تحلیل رابطه‌هااگر دیتابیس رابطه‌ای برای «داده» خوب است،دیتابیس گرافی برای «ارتباط» ساخته شده.نمونه‌ها:Neo4jAmazon Neptuneدیتابیس‌های Wide-Column (ستونیِ گسترده)اسمش ترسناک است، ولی ایده‌اش ساده‌تر از چیزی است که فکر می‌کنی.ایده‌ی اصلی چیست؟این دیتابیس‌ها شبیه جدول‌اند، اما:هر ردیف می‌تواند ستون‌های متفاوت داشته باشدستون‌ها می‌توانند خیلی زیاد باشندداده روی چندین سرور پخش می‌شودیعنی:مقیاس‌پذیری بالا، حتی با حجم عظیم دادهچرا ساخته شدند؟برای سیستم‌هایی که:داده خیلی زیاد می‌نویسندتوزیع‌شده‌اندباید همیشه در دسترس باشنداینجا سرعت نوشتن و تحمل خطا از «دقت لحظه‌ای» مهم‌تر است.محدودیت مهم (حواست باشد)JOIN پیچیده ندارندACID کامل ندارندبرای تراکنش‌های حساس مالی مناسب نیستندکِی انتخاب درستی هستند؟وقتی:لاگ، رویداد، کلیک، رفتار کاربر ذخیره می‌کنیداده‌ها پیوسته در حال اضافه شدن‌اندمقیاس خیلی بزرگ است (میلیون‌ها یا میلیاردها رکورد)مثال‌های واقعیآنالیتیکس وبمانیتورینگ سیستم‌هاداشبوردهای لحظه‌ایجمع‌بندی سریعWide-Column = حجم بالا + توزیع‌شده + سریعنمونه‌ها:Apache CassandraApache HBaseGoogle Bigtableدیتابیس‌های In-Memory (در حافظه)حالا برسیم به سریع‌ترین عضو این خانواده.ایده‌ی اصلی چیست؟به‌جای دیسک، داده مستقیماً داخل RAM نگه‌داری می‌شود.نتیجه؟سرعت بسیار بالاتأخیر بسیار کمپاسخ تقریباً آنیچرا این‌قدر سریع‌اند؟چون:دیسک حذف شدهI/O وجود نداردهمه‌چیز در حافظه استاما هیچ جادویی بدون هزینه نیست.محدودیت مهمRAM گران استحجمش محدود استاگر مراقب نباشی، داده از دست می‌رود (مگر با مکانیزم‌های پشتیبان)کِی انتخاب درستی هستند؟وقتی:سرعت از همه چیز مهم‌تر استداده موقتی یا نیمه‌موقتی استسیستم real-time می‌خواهیمثال‌های واقعیبازی‌های آنلاین (state بازی، session)معاملات لحظه‌ای مالیکش کردن داده‌های پرتکرارجمع‌بندی سریعIn-Memory = سرعت برق‌آسانه برای همه‌چیز،بلکه برای جاهایی که «کند بودن» غیرقابل قبول است.نمونه‌ها:RedisMemcachedیک نکته‌ی خیلی مهم (Blind Spot رایج)سیستم‌های واقعی معمولاً فقط یک دیتابیس ندارند.مثلاً:PostgreSQL برای داده‌های اصلیRedis برای کشCassandra برای لاگ‌هاGraph DB برای پیشنهاددهیاین یعنی:System Design = ترکیب هوشمندانه، نه تعصب روی یک ابزاردیتابیس‌های Time-Series (داده‌های زمانی)یک سؤال ساده اما کلیدی:اگر مهم‌ترین ویژگی داده، «زمان» باشد چه؟مثلاً:هر ثانیه CPU چقدر مصرف شده؟قیمت سهم در طول روز چطور تغییر کرده؟دمای سنسور هر ۵ ثانیه چقدر بوده؟اینجا با «داده‌ی معمولی» طرف نیستیم؛ با داده‌ی زمانی طرفیم.ایده‌ی اصلی چیست؟داده‌های Time-Series یعنی:یک مقدار + یک timestampمثال:(10:01:05) → CPU = 42% (10:01:10) → CPU = 47%این داده‌ها:پشت سر هم می‌آیندحجمشان زیاد استمعمولاً قدیمی‌ها کمتر استفاده می‌شونددیتابیس‌های معمولی با این الگو زود به زانو درمی‌آیند.TSDB چه کار متفاوتی می‌کند؟این دیتابیس‌ها برای زمان ساخته شده‌اند:نوشتن سریع پشت‌سرهمفشرده‌سازی هوشمندکوئری‌های مبتنی بر بازه‌ی زمانیحذف خودکار داده‌های قدیمی (Retention)کِی انتخاب درستی هستند؟وقتی:داده مرتب تولید می‌شود«روند» مهم‌تر از «رکورد تکی» استتحلیل در طول زمان داریمثال‌های واقعیمانیتورینگ سرورهاداده‌های IoT و سنسورهابازارهای مالیداشبوردهای performanceجمع‌بندی سریعTime-Series DB = استادِ داده‌های زمان‌داراگر دیتابیس رابطه‌ای برای «وضعیت فعلی» خوب است،TSDB برای «رفتار در طول زمان» ساخته شده.نمونه‌ها:InfluxDBTimescaleDBPrometheusدیتابیس‌های شی‌گرا (Object-Oriented Databases)حالا یک سناریوی آشنا برای برنامه‌نویس‌ها:اگر داده دقیقاً همان چیزی باشد که در کدت داری؟نه جدول،نه JSON،نه مپینگ.خودِ آبجکت.ایده‌ی اصلی چیست؟در دیتابیس شی‌گرا:داده = objectobject = instance از classهمراه با attribute و حتی behaviorیعنی همان چیزی که در Java، Python یا C++ می‌نویسی، مستقیم ذخیره می‌شود.چرا این ایده جذاب است؟چون:نیاز به ORM کم می‌شودتبدیل object ↔ table حذف می‌شودمدل‌های پیچیده راحت‌تر مدیریت می‌شونداما یک نکته‌ی مهم را نباید نادیده گرفت…واقعیت بازار (نکته‌ی مهم)این دیتابیس‌ها:رایج نیستنداکوسیستم کوچکی دارنددر مقیاس بزرگ کمتر استفاده می‌شوندبه همین دلیل، بیشتر خاص‌منظوره هستند.کِی انتخاب درستی هستند؟وقتی:مدل داده خیلی پیچیده استمنطق برنامه شدیداً شی‌گراستسادگی توسعه از همه چیز مهم‌تر استمثال‌های واقعیسیستم‌های شبیه‌سازیداده‌های چندرسانه‌ایاپلیکیشن‌های علمی یا تحقیقاتیجمع‌بندی سریعOODB = طبیعی برای OOP، خاص برای موارد محدودنمونه‌ها:ObjectDBdb4oدیتابیس‌های جستجوی متنی (Text Search Databases)سؤال:اگر کاربر بخواهد «جستجو» کند، نه فقط query ساده؟مثلاً:«لپ‌تاپ سبک برای برنامه‌نویسی»«خطاهای مربوط به timeout در لاگ‌ها»اینجا LIKE و WHERE کافی نیست.ایده‌ی اصلی چیست؟این دیتابیس‌ها برای:ایندکس‌کردن متنجستجوی سریعرتبه‌بندی نتایجساخته شده‌اند، نه برای ذخیره‌ی داده‌ی اصلی.چه قابلیت‌هایی دارند؟Full-Text Searchفازی سرچ (غلط املایی)Ranking نتایجفیلتر، highlight، aggregationکِی انتخاب درستی هستند؟وقتی:حجم متن زیاد استسرعت جستجو حیاتی استتجربه‌ی کاربر مهم استمثال‌های واقعیجستجوی محصولات فروشگاهموتورهای جستجوتحلیل و جستجوی لاگ‌هاجمع‌بندی سریعText Search DB = موتور جستجو، نه دیتابیس اصلیمعمولاً کنار دیتابیس اصلی می‌آید، نه به‌جای آن.نمونه‌ها:ElasticsearchApache SolrSphinxنکته‌ی استراتژیک (جایی که خیلی‌ها اشتباه می‌کنند)TSDB برای گزارش و مانیتورینگSearch DB برای جستجوDB اصلی برای داده‌ی مرجعدیتابیس‌های مکانی (Spatial Databases)یک سؤال ساده:اگر «مکان» جزو داده‌ی اصلی باشد چه؟نه فقط اسم شهر یا کشور،بلکه:فاصلهمسیرمحدودههم‌پوشانیاینجا دیتابیس معمولی جواب نمی‌دهد.ایده‌ی اصلی چیست؟دیتابیس‌های مکانی برای ذخیره و تحلیل داده‌های جغرافیایی ساخته شده‌اند.این داده‌ها می‌توانند باشند:نقطه (Point) → مثل موقعیت کاربرخط (Line) → مثل مسیر حرکتچندضلعی (Polygon) → مثل محدوده‌ی یک شهرو مهم‌تر از خود داده:«رابطه‌ی مکانی بین آن‌ها»چرا دیتابیس معمولی کم می‌آورد؟سؤالات مکانی از این جنس‌اند:نزدیک‌ترین رستوران به من کدام است؟این مسیر از کدام مناطق عبور می‌کند؟این دو محدوده هم‌پوشانی دارند یا نه؟برای این‌ها، دیتابیس‌های مکانی از ایندکس‌های مخصوص (مثل R-tree) استفاده می‌کنند تا کوئری‌ها سریع باشند.کِی انتخاب درستی هستند؟وقتی:مکان و فاصله مهم استکاربر location داردتحلیل جغرافیایی انجام می‌دهیمثال‌های واقعینقشه‌ها و مسیریابیسرویس‌های location-basedلجستیک و حمل‌ونقلردیابی خودرو و ناوگانجمع‌بندی سریعSpatial DB = داده + مکان + تحلیل جغرافیاییاغلب به‌صورت افزونه روی دیتابیس‌های دیگر استفاده می‌شوند، نه به‌تنهایی.نمونه‌ها:PostGISOracle SpatialBlob Datastore (ذخیره‌سازی فایل‌های حجیم)حالا یک اشتباه رایج:ذخیره‌ی فایل داخل دیتابیس رابطه‌ای.اگر این کار را می‌کنی، احتمالاً داری اشتباه می‌روی.ایده‌ی اصلی چیست؟Blob Datastore برای نگهداری:تصویرویدیوصدافایلبکاپساخته شده، نه برای جدول و رکورد.اینجا داده:ساختار نداردبزرگ استزیاد دانلود می‌شودچرا دیتابیس معمولی مناسب نیست؟چون:حجم فایل‌ها بالاستBackup سخت می‌شودPerformance می‌ریزدهزینه بالا می‌رودBlob Storage دقیقاً برای همین سناریو بهینه شده است.کِی انتخاب درستی هستند؟وقتی:فایل زیاد داریدسترسی global می‌خواهیdurability و scalability مهم استمثال‌های واقعیذخیره‌ی تصاویر اپلیکیشنویدیو استریملاگ‌های حجیمبکاپ و آرشیوجمع‌بندی سریعBlob Storage = فایل‌ها بیرون، دیتا داخل دیتابیساین دو را قاطی نکن.نمونه‌ها:Amazon S3Azure Blob StorageHDFSدیتابیس‌های Ledger (دفترکل / تغییرناپذیر)اینجا با یک مفهوم جدی طرفیم:داده‌ای که نباید تغییر کند. حتی توسط ادمین.ایده‌ی اصلی چیست؟Ledger Database یعنی:فقط اضافه می‌کنیحذف و ویرایش وجود نداردهمه‌چیز تاریخچه داردتغییر قابل اثبات استاین شبیه بلاک‌چین است، ولی الزاماً عمومی یا رمزنگاری‌شده مثل کریپتو نیست.چرا مهم‌اند؟چون در بعضی سیستم‌ها:اعتماد حیاتی استدستکاری فاجعه استردپا باید بماندکِی انتخاب درستی هستند؟وقتی:شفافیت مهم استaudit trail می‌خواهیداده حقوقی یا حساس استمثال‌های واقعیزنجیره تأمینسوابق پزشکیسیستم رأی‌گیریقراردادهاجمع‌بندی سریعLedger DB = حقیقتی که قابل پاک شدن نیستنمونه‌ها:Amazon QLDBHyperledger Fabricدیتابیس‌های سلسله‌مراتبی (Hierarchical Databases)و حالا یک مدل قدیمی، اما هنوز مهم برای فهم.ایده‌ی اصلی چیست؟داده‌ها به شکل درخت ذخیره می‌شوند:هر نود یک والد داردمی‌تواند چند فرزند داشته باشدرابطه فقط یک‌طرفه استمثل:پوشه‌هاساختار سازمانیچرا امروز کمتر استفاده می‌شوند؟چون:انعطاف کمی دارندتغییر ساختار سخت استروابط پیچیده را خوب هندل نمی‌کنندبه همین دلیل، دیتابیس‌های رابطه‌ای و NoSQL جای آن‌ها را گرفته‌اند.کِی هنوز کاربرد دارند؟وقتی:ساختار واقعاً درختی استرابطه‌ها ساده و ثابت‌اندتغییر کم استمثال‌های واقعیساختار فایل سیستمچارت سازمانیتنظیمات سیستمیجمع‌بندی سریعHierarchical DB = ساده، قدیمی، محدودبیشتر برای فهم مدل داده مهم‌اند تا انتخاب در پروژه‌های جدید.نمونه‌ها:IBM IMSWindows Registryدیتابیس‌های برداری (Vector Databases)یک سؤال خیلی مهم در دنیای امروز:اگر داده «شبیه» باشد، نه «برابر» چه؟مثلاً:این متن شبیه کدام متن‌هاست؟این تصویر به کدام تصاویر نزدیک‌تر است؟سلیقه‌ی این کاربر به کدام کاربران می‌خورد؟اینجا = و WHERE کاملاً بی‌مصرف‌اند.ایده‌ی اصلی چیست؟در دیتابیس‌های برداری:هر داده به یک بردار عددی تبدیل می‌شوداین بردارها در فضای چندبُعدی قرار می‌گیرندجستجو بر اساس شباهت انجام می‌شود، نه تطابق دقیقمثال ذهنی:متن، تصویر یا صدا → تبدیل به لیست عددسپس: «نزدیک‌ترین‌ها» پیدا می‌شوندچرا این دیتابیس‌ها ناگهان مهم شدند؟به‌خاطر AI.مدل‌های یادگیری ماشین:متن را embedding می‌کنندتصویر را embedding می‌کنندرفتار کاربر را embedding می‌کنندو این embeddingها بدون دیتابیس برداری عملاً بلااستفاده‌اند.کِی انتخاب درستی هستند؟وقتی:جستجوی معنایی می‌خواهیrecommendation هوشمند داریبا AI، NLP یا vision کار می‌کنیمثال‌های واقعیجستجوی تصویری (شبیه این عکس)پیشنهاد محتواتشخیص ناهنجاریsearch هوشمند (semantic search)جمع‌بندی سریعVector DB = قلب سیستم‌های AI-محوراین دیتابیس‌ها معمولاً کنار دیتابیس اصلی می‌آیند، نه به‌جای آن.نمونه‌ها:FaissMilvusPineconeدیتابیس‌های Embedded (توکار)حالا بیاییم برگردیم به ساده‌ترین، اما بسیار کاربردی‌ترین نوع دیتابیس.ایده‌ی اصلی چیست؟Embedded Database:سرور جدا نداردداخل خود اپلیکیشن اجرا می‌شودنصب و راه‌اندازی نمی‌خواهدیعنی:دیتابیس = بخشی از برنامهچرا این مهم است؟چون خیلی وقت‌ها:سیستم کوچک استیک کاربر داردمنابع محدودندسادگی مهم‌تر از مقیاس استراه‌اندازی PostgreSQL یا MongoDB برای این سناریوها زیاده‌روی است.کِی انتخاب درستی هستند؟وقتی:اپلیکیشن لوکال استgame یا desktop app داریداده پیچیده یا خیلی حجیم نیستمثال‌های واقعیذخیره‌ی progress بازیتنظیمات نرم‌افزارداده‌های آفلاین موبایل یا دسکتاپجمع‌بندی سریعEmbedded DB = سادگی، سرعت، بدون دردسرنمونه‌ها:SQLiteRocksDBBerkeley DBجمع‌بندی نهایی (نکته‌ی استراتژیک)اگر تا اینجا یک چیز باید یادت مانده باشد، این است:هیچ دیتابیسی برای همه‌چیز ساخته نشده.انتخاب دیتابیس یعنی پاسخ دادن به این سؤال‌ها:داده‌ام چه شکلی است؟سرعت مهم‌تر است یا دقت؟رابطه مهم است یا شباهت؟مقیاس چقدر است؟هزینه چقدر مهم است؟سیستم‌های حرفه‌ای:ترکیبی‌اندماژولارندتعصب ندارنداگر بخواهم این بلاگ را یک جمله جمع کنم:System Design یعنی انتخاب آگاهانه، نه استفاده‌ی کورکورانه از ابزار محبوب.سخن پایانیدر طراحی سیستم‌های نرم‌افزاری، انتخاب دیتابیس یک تصمیم صرفاً فنی یا سلیقه‌ای نیست؛ این انتخاب مستقیماً بر مقیاس‌پذیری، پایداری، هزینه و حتی آیندهٔ محصول اثر می‌گذارد. هر نوع دیتابیس—از رابطه‌ای و سندی گرفته تا گراف، زمانی، مکانی و برداری—برای حل مسئله‌ای خاص طراحی شده است و استفادهٔ نادرست از آن‌ها، معمولاً در مقیاس یا زمان رشد سیستم خودش را به شکل بحران نشان می‌دهد.آنچه در System Design اهمیت دارد، نه دانستن نام ابزارها، بلکه درک عمیق الگوهای داده، رفتار سیستم تحت بار، و ترکیب هوشمندانهٔ چند فناوری در کنار یکدیگر است. سیستم‌های واقعی معمولاً با یک دیتابیس ساخته نمی‌شوند، بلکه با معماری درست به تعادل می‌رسند.اگر در حال طراحی یا توسعهٔ سامانه‌های نرم‌افزاری مقیاس‌پذیر، سیستم‌های داده‌محور، یا محصولات مبتنی بر real-time، analytics یا AI هستید، تیم معماری و توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) می‌تواند از تحلیل مسئله و انتخاب معماری مناسب، تا طراحی زیرساخت داده و پیاده‌سازی عملیاتی، همراه شما باشد.این مقاله با هدف انتقال تجربه و ارتقای نگاه معماری در انتخاب دیتابیس‌ها، توسط تیم توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#System_Design#Database_Architecture#Software_Architecture#Backend_Engineering#Distributed_Systems#Scalable_Systems#Data_Engineering#NoSQL#AI_Systems#RealTime_Systems#شرکت_راهکار_نگار_هوشمند#arcanco

طراحی مکانیزم امتیازدهی بازی با Redis (Scoring)

محمد حسین جلیلی — Sat, 20 Dec 2025 11:57:03 +0330

قبل از هر چیز یک اعتراف صادقانه:این سناریو لزوماً از دل یک بازی واقعی نیامده. بیشتر یک مدل ذهنی است برای این‌که بفهمیم Redis چطور فکر می‌کند و چطور می‌شود از آن برای ساخت مکانیزم‌های بازی استفاده کرد.فرض کنیم یک بازی داریم به اسم Super Redis Brothers؛یک بازی پلتفرمر آنلاین که به یک سرور مرکزی وصل است. شخصیت اصلی بازی، Redisman، باید سکه جمع کند، با سکه‌ها power-up بگیرد و زنده بماند.تمرکز ما در این مقاله فقط روی امتیازدهی (جمع‌کردن سکه) است.ساده‌ترین حالت: شمارنده با Stringاگر فقط بخواهیم تعداد سکه‌های یک بازیکن را نگه داریم، ساده‌ترین راه استفاده از یک counter است.مثلاً:INCR pID123یا اگر چند سکه با هم جمع شود:INCRBY pID123 10کم‌کردن امتیاز هم با:DECRBY pID123 5این روش:سریع است (O(1))ساده استولی به‌شدت محدودمشکل کجاست؟به محض این‌که بخواهی:لیدربورد بسازیبازیکن‌ها را با هم مقایسه کنیرتبه بدهیدیگر string جواب نمی‌دهد.چرا Sorted Set انتخاب بهتری است؟اینجاست که Sorted Set وارد بازی می‌شود.ایده خیلی ساده است:یک کلید داریم برای همه‌ی امتیازهاmember = شناسه‌ی بازیکنscore = تعداد سکه‌هابا این مدل:هم امتیاز هر بازیکن را داریهم می‌توانی رتبه‌بندی بگیریهم لیدربورد بسازیمدل‌سازی جمع‌کردن سکه با Sorted Setفرض کنیم همه‌ی امتیازها زیر این کلید ذخیره می‌شوند:scoresوقتی بازیکن سکه جمع می‌کند:ZINCRBY scores 10 pID1234چند نکته‌ی مهم اینجا وجود دارد:اگر بازیکن قبلاً وجود نداشته باشد، Redis از صفر شروع می‌کندscore صفر یک مقدار معتبر استscore منفی هم مجاز است (که بعداً به دردسرش می‌خوریم!)پیچیدگی این عملیات:O(log n)برای بازی و آپدیت‌های پرتعداد کاملاً قابل قبولنمایش سکه‌ها در HUD بازیبرای نمایش تعداد سکه‌ها روی صفحه‌ی بازی، فقط کافی است امتیاز فعلی را بگیریم:ZSCORE scores pID1234نکته‌ی جالب:ZINCRBY خودش امتیاز جدید را برمی‌گرداندیعنی همان پاسخ Redis می‌تواند مستقیم وارد HUD شودبدون کوئری اضافهخرج‌کردن سکه‌ها (Power-Up)فرض کنیم یک power-up داریم که:۱۰ سکه می‌گیرددشمن‌ها را فریز می‌کنداز نظر Redis:ZINCRBY scores -10 pID1234کاملاً منطقی.یا اگر بخواهیم سکه‌ها را صفر کنیم (مثل Sonic وقتی ضربه می‌خورد):ZADD scores 0 pID1234اینجا شاید ZADD عجیب به نظر برسد،ولی در واقع یک upsert است:اگر عضو باشد → امتیازش آپدیت می‌شوداگر نباشد → با امتیاز صفر اضافه می‌شودمشکل واقعی: امتیاز منفی!اینجا به یک ساده‌سازی خطرناک می‌رسیم.اگر Redisman صفر سکه داشته باشد و power-up بخورد:ZINCRBY scores -10 pID1234نتیجه:-10که احتمالاً در منطق بازی غلط است.پس قبل از کم‌کردن امتیاز، باید چک کنیم:آیا بازیکن به‌اندازه‌ی کافی سکه دارد یا نه؟حل مسئله با Lua Script (اتمیک و تمیز)منطق به زبان ساده:امتیاز فعلی را بگیراگر کافی بود، کم کناگر نه، هیچ کاری نکنبه‌صورت شبه‌کد:if currentScore >= neededCoins: decrementدر Redis، بهترین جا برای این منطق یک Lua Script است؛چون:اتمیک اجرا می‌شودبین ZSCORE و ZINCRBY هیچ عملیات دیگری نمی‌پرداسکریپت نمونه:EVAL " if tonumber(redis.call('zscore',KEYS[1],ARGV[2])) >= (ARGV[1]*-1) then return tonumber(redis.call('zincrby',KEYS[1],ARGV[1],ARGV[2])) end " 1 scores -10 pID1234این اسکریپت:اول امتیاز را می‌گیردچک می‌کند به زیر صفر نرودفقط در صورت مجاز بودن، امتیاز را کم می‌کنددر محیط production:معمولاً از SCRIPT LOAD و EVALSHA استفاده می‌شودولی منطق دقیقاً همین استساخت لیدربورد با Sorted Setاگر تا این‌جا همراه بوده باشی، حالا یک نکته باید کاملاً روشن باشد:Sorted Set تقریباً برای لیدربورد ساخته شده است.ما همین حالا هم امتیاز هر بازیکن را به‌عنوان score داخل یک Sorted Set نگه می‌داریم.پس بخش بزرگی از منطق لیدربورد از قبل آماده است.نمایش نفرات برتر (Top-N)در بیشتر بازی‌ها، لیدربورد از بیشترین امتیاز به کمترین نمایش داده می‌شود.برای همین از ZREVRANGE استفاده می‌کنیم.ZREVRANGE scores 0 9 WITHSCORESاین دستور:۱۰ بازیکن اول را برمی‌گرداندبالاترین امتیاز در ابتدای لیست استامتیازها هم همراه اسم بازیکن‌ها برمی‌گرددنکته‌ی مهم:Redis تساوی امتیازها را هم درست مدیریت می‌کندممکن است ۱۰ نفر اول، همگی امتیاز یکسان داشته باشندترتیب همچنان پایدار و قابل پیش‌بینی استلیدربورد «اطراف من» (نه فقط Top 10)نمایش ۱۰ نفر اول برای همه مفید نیست.اگر کاربر تازه‌وارد باشد و رتبه‌اش مثلاً ۴۸٬۳۲۱ باشد،دیدن Top 10 هیچ انگیزه‌ای ایجاد نمی‌کند.آنچه کاربر واقعاً می‌خواهد ببیند:چند نفر بالاتر از خودشچند نفر پایین‌تر از خودشگرفتن رتبه‌ی کاربراول باید بفهمیم بازیکن چندم است:ZREVRANK scores pID1234این دستور:رتبه‌ی بازیکن را از بالا برمی‌گردانددقیقاً همان چیزی که برای لیدربورد لازم داریمنمایش بازه‌ای اطراف کاربرحالا که رتبه را داریم، می‌توانیم مثلاً:۵ نفر بالاترخود کاربر۵ نفر پایین‌تررا با یک ZREVRANGE بگیریم.ایده ساده است:start = rank - 5 end = rank + 5و بعد:ZREVRANGE scores start end WITHSCORESاین مدل لیدربورد:بسیار شخصی‌تر استانگیزه‌ی رقابت ایجاد می‌کنددر بازی‌های واقعی بسیار مؤثرتر از Top-N استاما یک مشکل جدی در مقیاس بالاتا این‌جا همه‌چیز عالی به نظر می‌رسد،اما این مدل یک نقطه‌ی ضعف معماری دارد.در تمام مثال‌ها، ما فقط با یک کلید کار می‌کنیم:scoresدر مقیاس کوچک مشکلی نیست.اما در یک بازی واقعی با ترافیک بالا چه اتفاقی می‌افتد؟مشکل Hot Keyدر Redis (به‌خصوص در حالت cluster):هر کلید روی یک shard مشخص قرار می‌گیردتمام عملیات روی آن کلید، روی همان نود انجام می‌شودنتیجه:همه‌ی ZINCRBYهمه‌ی ZREVRANGEهمه‌ی ZREVRANKروی یک ماشین می‌افتد.حتی اگر:ده‌ها shardیا چندین نود داشته باشیتا وقتی کلید یکی است،گلوگاه همان یک shard خواهد بود.به این حالت می‌گویند: Hot Keyدر یک بازی با:جمع‌کردن سکه‌ی زیادخرج‌کردن power-upکاربران هم‌زمان زیاداین محدودیت واقعاً خودش را نشان می‌دهد.راه‌حل ساده؟ نه کاملاًیک راه این است که:امتیاز هر بازیکن را در یک key جداگانه با INCR نگه داریمهر چند وقت یک‌بار با SCAN، یک Sorted Set بسازیماما این کار:real-time بودن لیدربورد را از بین می‌بردسیستم‌های جانبی و cron job می‌خواهدپیچیدگی را بالا می‌بردیعنی مشکل را حل نمی‌کند، فقط جابجا می‌کند.یک راه‌حل مقیاس‌پذیرتر (ولی خاص)در معماری‌های پیشرفته‌تر، می‌شود از Redis به‌صورت توزیع‌شده‌تر استفاده کرد.مثلاً در Redis Enterprise Active-Active:چند کلاستر هم‌رده داریمنوشتن‌ها بین آن‌ها پخش می‌شودداده‌ها بعداً با مدل CRDT همگام می‌شونددر این حالت:فشار نوشتن روی یک کلید تقسیم می‌شودبرای workloadهای bursty (افزایش ناگهانی ترافیک) مناسب‌تر استreal-time کامل نیست، ولی بسیار مقیاس‌پذیرتر استاین راه‌حل:عمومی نیستبرای همه پروژه‌ها هم لازم نیستولی دانستنش برای طراحی سیستم‌های بزرگ حیاتی استسخن پایانیدر بازی‌ها و سامانه‌های بلادرنگ، امتیازدهی و رتبه‌بندی فقط یک قابلیت ظاهری نیست؛ بخشی از هستهٔ طراحی سیستم است. Redis و به‌ویژه Sorted Set امکان پیاده‌سازی سریع و کارآمد مکانیزم‌هایی مثل امتیازدهی، لیدربورد و رتبهٔ شخصی کاربران را فراهم می‌کنند، اما در مقیاس بالا، تصمیم‌های معماری—مانند مدیریت hot key و الگوی توزیع داده—نقش تعیین‌کننده‌ای در پایداری سامانه دارند.اگر در حال طراحی یا توسعهٔ بازی‌ها و سیستم‌های real-time با بار بالا هستید، تیم معماری و توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) می‌تواند از تحلیل مسئله تا طراحی معماری مقیاس‌پذیر و پیاده‌سازی عملیاتی، همراه شما باشد.این مقاله با هدف انتقال تجربه و آگاهی‌بخشی فنی، توسط تیم توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#Redis#SortedSet#Leaderboard#Game_Mechanics#RealTime_Systems#Scalable_Architecture#Backend_Engineering#System_Design#High_Performance#Distributed_Systems#Software_Architecture#شرکت_راهکار_نگار_هوشمند#arcanco

طراحی لیدربورد و سیستم‌های رتبه‌بندی با Redis Sorted Set

محمد حسین جلیلی — Sat, 20 Dec 2025 11:22:57 +0330

برای این‌که Sorted Set را درست بفهمیم، لازم است خیلی خلاصه بدانیم Set و Hash در Redis چه کاری می‌کنند؛ چون ZSET عملاً از دل همین دو مفهوم بیرون آمده.Redis Set چیست؟Set در Redis یک مجموعه از رشته‌های یکتاست.هر عضو فقط یک‌بار می‌تواند وجود داشته باشدترتیب نداردفقط می‌توانی بپرسی «هست یا نیست؟»Set برای سناریوهایی خوب است که:تکراری بودن مهم نیستفقط عضویت مهم است، نه مقدار یا رتبهمثلاً:لیست کاربران آنلاینلیست آی‌دی‌هایی که قبلاً کاری را انجام داده‌انداما همین‌جا محدودیتش معلوم می‌شود:نه ترتیبی دارد، نه عددی، نه مفهومی از رتبه.مثال Set: فقط «هست یا نیست»فرض کن می‌خوای بفهمی کدوم کاربرها الان آنلاین‌اند.ذهنی که پشت داده استما فقط اینو می‌خوای:user_42 آنلاین هست یا نه؟user_99 آنلاین هست یا نه؟هیچ امتیاز، ترتیب یا اطلاعات اضافه‌ای مهم نیست.داده در Redis چطور ذخیره می‌شودSADD online_users user_42 SADD online_users user_99 SADD online_users user_7تو چطور می‌بینیشSMEMBERS online_usersخروجی:user_7 user_42 user_99نکته مهم:ترتیب هیچ معنایی ندارد. Redis عمداً ترتیب را به تو تضمین نمی‌دهد.اگر بپرسی:SISMEMBER online_users user_42خیلی سریع جواب می‌گیری: بله یا خیر.Redis Hash چیست؟Hash شبیه یک دیکشنری یا آبجکت است:یک کلید اصلی داریداخلش مجموعه‌ای از field → value نگه می‌داریHash برای این عالی است که:اطلاعات مرتبط یک موجودیت را کنار هم نگه داریبه هر فیلد جداگانه دسترسی داشته باشیمثلاً:پروفایل کاربر (name، level، xp، status)تنظیمات یک بازی یا سرویساما Hash هم یک ضعف جدی دارد:هیچ مفهومی از مرتب‌سازی بین چند عضو مختلف ندارد.مثال Hash: یک موجودیت با چند ویژگیحالا فرض کن می‌خوای پروفایل یک کاربر را ذخیره کنی.ذهنی که پشت داده استما یک کاربر داریم با چند ویژگی:ناملولامتیاز کلیهمه این‌ها به یک موجودیت تعلق دارند.داده در Redis چطور ذخیره می‌شودHSET user:42 name "Ali" level 7 totalScore 1850تو چطور می‌بینیشHGETALL user:42خروجی:name Ali level 7 totalScore 1850یا اگر فقط یکی از فیلدها مهم باشد:HGET user:42 levelاینجا Hash عالی است،اما هیچ راهی نداری بگویی:«کدام کاربر امتیازش بالاتر است؟»حالا چرا Sorted Set به‌وجود آمده؟اینجا Redis می‌گوید:از Set، یکتایی اعضا را بگیراز Hash، نگاشت عضو به مقدار را بگیرو یک چیز اضافه کن که هیچ‌کدام ندارند: ترتیب دائمینتیجه می‌شود Sorted Set:هر عضو یکتا است (مثل Set)هر عضو یک عدد دارد (مثل Hash)و کل مجموعه همیشه مرتب استنکته‌ای که معمولاً نادیده گرفته می‌شوداگر جایی داری:Set + سورت در کدیا Hash + مرتب‌سازی دستیدر واقع داری کاری می‌کنی که Redis از قبل برایش ساخته شده، ولی استفاده‌اش نمی‌کنی.این نه بهینه است، نه مقیاس‌پذیر، و نه تمیز.مثال Sorted Set: رتبه‌بندی واقعیحالا می‌رسیم به لیدربورد.ذهنی که پشت داده استما می‌خواهیم:هر کاربر یک امتیاز داشته باشدبتوانیم بفهمیم چه کسی بالاتر استسریع ۱۰ نفر اول را ببینیمداده در Redis چطور ذخیره می‌شودZADD leaderboard 1850 user_42 ZADD leaderboard 2100 user_7 ZADD leaderboard 1600 user_99اینجا:score = امتیازmember = شناسه‌ی کاربرتو چطور می‌بینیش۱۰ نفر اول:ZREVRANGE leaderboard 0 9 WITHSCORESخروجی:user_7 2100 user_42 1850 user_99 1600Redis بدون این‌که ازش بخواهی سورت کند،از اول داده را مرتب نگه داشته.مثال امتیاز مساوی (جایی که خیلی‌ها اشتباه می‌کنند)فرض کن دو نفر امتیاز برابر دارند:ZADD leaderboard 2000 user_20 ZADD leaderboard 2000 user_3Redis چه کار می‌کند؟چون score برابر است، می‌رود سراغ اسم‌ها.از نظر لغوی:user_20 > user_3پس ترتیب همیشه ثابت است و لیدربورد «به هم نمیریزد».تعریف سادهیک Redis Sorted Set مجموعه‌ای از رشته‌های یکتا (members) است که هر کدام یک امتیاز عددی (score) دارند و همیشه به‌صورت مرتب‌شده نگه‌داری می‌شوند.نکته‌ی کلیدی اینجاست:مرتب‌بودن، ویژگی ذاتی داده است، نه نتیجه‌ی کوئری.یعنی Redis از لحظه‌ی ذخیره‌سازی، ترتیب را حفظ می‌کند؛ نه این‌که هر بار موقع خواندن، سورت کند.Sorted Set دقیقاً چه مشکلی را حل می‌کند؟1. لیدربورد (Leaderboard)واضح‌ترین و مهم‌ترین کاربرد.امتیاز هر کاربر = scoreشناسه‌ی کاربر = memberگرفتن ۱۰ نفر اول؟ → O(log N)آپدیت امتیاز؟ → O(log N)برای یک بازی آنلاین با میلیون‌ها کاربر، این یعنی نجات پروژه.2. Rate Limiting (محدودسازی درخواست)با ZSET می‌توانی Sliding Window Rate Limiter بسازی:هر درخواست = یک timestamp به‌عنوان scoreحذف درخواست‌های قدیمیشمردن درخواست‌های بازه‌ی زمانیبدون نیاز به دیتابیس سنگین یا لاک پیچیده.Sorted Set ترکیب کدام ساختارهاست؟می‌تونی Sorted Set رو این‌طوری تصور کنی:از Set:اعضا یکتا هستندهیچ عضوی تکراری نیستاز Hash:هر عضو به یک مقدار (score) مپ شدهاما چیزی که هیچ‌کدام ندارند:مرتب‌سازی دائمی و ذاتیقانون مرتب‌سازی در Sorted SetRedis برای مرتب‌سازی دو قانون خیلی شفاف دارد:قانون اول: امتیاز (Score)اگر دو عضو score متفاوت داشته باشند:A > B اگر A.score > B.scoreیعنی امتیاز بالاتر = رتبه بالاتر.قانون دوم: ترتیب لغوی (Lexicographical)اگر دو عضو امتیاز یکسان داشته باشند:A > B اگر A.member از نظر لغوی بزرگ‌تر از B.member باشدمثلاً:score = 100 "user_20" > "user_3"نکته مهم:چون اعضا یکتا هستند، دو رشته‌ی کاملاً یکسان وجود ندارداین قانون باعث می‌شود ترتیب همیشه deterministic باشدچرا این جزئیات مهم‌اند؟چون در سیستم واقعی:امتیازها مساوی می‌شوندهزاران کاربر score برابر دارنداگر ترتیب مشخص نباشد، UI شما «به هم میریزه»کاربر حس بی‌عدالتی می‌گیردRedis این مشکل را در سطح ساختار دیتا حل کرده، نه در کد شما.یک مثال ساده: امتیازدهی به راننده‌ها با Redis Sorted Setبیایم همه‌چیز رو با یک مثال خیلی ساده شروع کنیم:فرض کن چند راننده داریم و هرکدوم توی اولین مسابقه یک امتیاز گرفته‌اند.هدف ما اینه که این امتیازها رو ذخیره کنیم و هر لحظه بتونیم رتبه‌بندی‌شون رو ببینیم.اضافه‌کردن داده‌ها به Sorted Setبرای این کار از دستور ZADD استفاده می‌کنیم.ZADD racer_scores 10 "Norem" ZADD racer_scores 12 "Castilla" ZADD racer_scores 8 "Sam-Bodden" 10 "Royce" 6 "Ford" 14 "Prickett"چند نکته‌ی خیلی مهم همین‌جا وجود دارد که معمولاً نادیده گرفته می‌شود:ZADD شبیه SADD است، اما قبل از هر عضو یک score می‌گیرداین دستور variadic است؛ یعنی می‌توانی چند score–member را یک‌جا اضافه کنیمقدار برگشتی نشان می‌دهد چند عضو جدید اضافه شده‌اند (نه این‌که چند تا دستور اجرا شده)از همین لحظه، Redis داده‌ها را مرتب‌شده نگه می‌دارد.دیدن لیست مرتب‌شده‌ی راننده‌هاحالا بدون هیچ سورت اضافه‌ای، می‌توانیم لیست را بگیریم.ZRANGE racer_scores 0 -1خروجی:Ford Sam-Bodden Norem Royce Castilla Prickettاین خروجی از کمترین امتیاز به بیشترین است.چرا؟ چون ZRANGE همیشه از پایین به بالا می‌آید.اگر برعکسش را بخواهی:ZREVRANGE racer_scores 0 -1خروجی:Prickett Castilla Royce Norem Sam-Bodden Fordاینجا بالاترین امتیاز اول می‌آید، دقیقاً چیزی که برای لیدربورد لازم داریم.نکته‌ی ظریف:0 یعنی اولین عنصر-1 یعنی آخرین عنصردقیقاً مثل LRANGE در لیست‌ها.دیدن امتیازها همراه با اسم‌هاتا این‌جا فقط اسم‌ها را دیدیم. اگر امتیاز هم بخواهیم:ZRANGE racer_scores 0 -1 WITHSCORESخروجی به‌صورت جفت‌های پشت‌سرهم برمی‌گردد:Ford 6 Sam-Bodden 8 Norem 10 Royce 10 Castilla 12 Prickett 14این شکل خروجی شاید اولش عجیب باشد،ولی برای پردازش ماشین‌محور عالی است و سریع.کار روی بازه‌ها (اینجا قدرت ZSET معلوم می‌شود)فرض کن فقط راننده‌هایی را می‌خواهیم که ۱۰ امتیاز یا کمتر گرفته‌اند.ZRANGEBYSCORE racer_scores -inf 10خروجی:Ford Sam-Bodden Norem Royceاینجا داریم به Redis می‌گوییم:از منفی بی‌نهایتتا ۱۰هر چی توی این بازه است را بدهاین یعنی فیلتر + مرتب‌سازی با هم، آن هم با پیچیدگی مناسب.حذف داده‌ها (تکی و گروهی)حذف یک راننده‌ی خاص خیلی ساده است:ZREM racer_scores "Castilla"اما قدرت واقعی اینجاست که بتوانی یک بازه را پاک کنی.مثلاً:همه‌ی کسانی که امتیازشان کمتر از ۱۰ است را حذف کنZREMRANGEBYSCORE racer_scores -inf 9Redis تعداد آیتم‌های حذف‌شده را برمی‌گرداند،که برای مانیتورینگ خیلی مهم است.بعد از حذف، اگر دوباره لیست را ببینیم:ZRANGE racer_scores 0 -1خروجی:Norem Royce Prickettگرفتن رتبه‌ی یک عضویکی از مهم‌ترین قابلیت‌های Sorted Set این است که بپرسی:«این شخص چندمه؟»ZRANK racer_scores "Norem"خروجی:0یعنی از پایین، اولین نفر.اگر رتبه از بالا را بخواهی (حالت لیدربورد واقعی):ZREVRANK racer_scores "Norem"خروجی:2یعنی نفر سوم از بالا.این دستور برای نمایش رتبه‌ی کاربر بدون گرفتن کل لیدربورد حیاتی است.مرتب‌سازی لغوی (Lexicographical) — وقتی همه امتیاز برابرنداز Redis 2.8 به بعد، اگر همه‌ی اعضا score یکسان داشته باشند،می‌توانی از Sorted Set به‌عنوان ایندکس لغوی استفاده کنی.بیایم همه راننده‌ها را با score صفر اضافه کنیم:ZADD racer_scores 0 "Norem" 0 "Sam-Bodden" 0 "Royce" 0 "Castilla" 0 "Prickett" 0 "Ford"حالا اگر لیست را بگیریم:ZRANGE racer_scores 0 -1خروجی:Castilla Ford Norem Prickett Royce Sam-Boddenکاملاً لغوی مرتب شده‌اند.گرفتن بازه‌ی لغویمثلاً همه‌ی اسم‌هایی که بین A و L هستند:ZRANGEBYLEX racer_scores [A [Lخروجی:Castilla Ford براکت [ یعنی شامل (inclusive)و می‌توانی بازه‌های باز یا بی‌نهایت هم تعریف کنی.چرا این قابلیت خیلی مهم است؟چون Sorted Set فقط برای لیدربورد نیست.با این تکنیک می‌توانی:ایندکس بسازیروی بازه‌های عددی بزرگ (مثلاً 128 بیت) جستجو کنیبدون دیتابیس سنگین، range query واقعی داشته باشیRedis این کار را با یک ساختار دوگانه انجام می‌دهد:Skip List برای مرتب‌سازیHash Table برای دسترسی سریعبه همین دلیل:اضافه‌کردن عضو: O(log N)خواندن داده‌ی مرتب: تقریباً بدون هزینهآپدیت امتیازها: چرا Sorted Set برای لیدربورد ایده‌آل است؟قبل از رفتن به مبحث بعدی، یک نکته‌ی بسیار مهم درباره‌ی Sorted Set وجود دارد که اگر درک نشود، کل ارزش آن از دست می‌رود:امتیاز (score) اعضای Sorted Set هر لحظه قابل تغییر است.و مهم‌تر از آن:این تغییر با پیچیدگی O(log N) انجام می‌شود.یعنی حتی اگر میلیون‌ها عضو داشته باشی،آپدیت امتیاز هنوز هم قابل‌اعتماد و سریع است.به همین دلیل است که Sorted Set انتخاب پیش‌فرض برای leaderboard محسوب می‌شود.لیدربورد در دنیای واقعی یعنی چه؟تصور کن یک بازی آنلاین داری (مثلاً بازی‌های اجتماعی شبیه بازی‌های فیسبوکی):می‌خواهی همیشه بتوانی Top-N را نشان بدهیمی‌خواهی به هر کاربر بگویی:«رتبه‌ی تو الان 4932 است»امتیازها مدام تغییر می‌کنندتعداد آپدیت‌ها خیلی زیاد استاگر این را با دیتابیس رابطه‌ای یا سورت در کد انجام بدهی،سیستم خیلی زود تحت فشار قرار میگیره.Sorted Set دقیقاً برای همین سناریو طراحی شده.دو مدل آپدیت امتیاز در لیدربورددر عمل، دو حالت داریم:حالت اول: امتیاز جدید را دقیق می‌دانیممثلاً بازی تمام شده و امتیاز نهایی مشخص است.در این حالت، ZADD کافی است.ZADD racer_scores 100 "Wood" ZADD racer_scores 100 "Henshaw"اگر همان عضو دوباره اضافه شود:ZADD racer_scores 150 "Henshaw"اینجا Redis:عضو جدید اضافه نمی‌کندفقط امتیاز را جایگزین می‌کندو جایگاه عضو در لیدربورد را به‌روزرسانی می‌کندنکته‌ی ظریف:مقدار برگشتی 0 استیعنی عضو از قبل وجود داشتهحالت دوم: می‌خواهیم امتیاز را افزایش بدهیمدر خیلی از بازی‌ها، امتیاز تجمعی است:هر برد → +50هر مأموریت → +20اینجا استفاده از ZINCRBY منطقی‌تر است.ZINCRBY racer_scores 50 "Wood"خروجی:"150"Redis امتیاز جدید را برمی‌گرداند.حالا اگر همین کار را برای Henshaw انجام بدهیم:ZINCRBY racer_scores 50 "Henshaw"خروجی:"200"اینجا اتفاقات مهمی افتاده:امتیاز قبلی مهم نیستRedis خودش جمع می‌زندرتبه بلافاصله اصلاح می‌شودبدون race condition، بدون lock، بدون دردسر.تفاوت رفتاری ZADD و ZINCRBY (خیلی مهم)ZADDامتیاز را جایگزین می‌کندوقتی امتیاز نهایی را می‌دانیZINCRBYامتیاز را افزایش یا کاهش می‌دهدوقتی امتیاز مرحله‌ای یا تجمعی استاگر این دو را اشتباه استفاده کنی،لیدربوردت به‌مرور غلط و غیرقابل اعتماد می‌شود.دستورات پایه‌ای که لیدربورد روی آن‌ها می‌چرخدبدون وارد شدن به لیست بلندبالا، لیدربورد واقعی معمولاً فقط به این‌ها نیاز دارد:ZADDاضافه‌کردن یا آپدیت امتیازZRANGEگرفتن لیست مرتب‌شده (از پایین به بالا)ZRANKگرفتن رتبه‌ی کاربر از پایینZREVRANKگرفتن رتبه‌ی کاربر از بالا (حالت لیدربورد)با همین چهار دستور می‌توان یک لیدربورد کامل ساخت.نکته‌ی عملکردی که نباید نادیده بگیریبیشتر عملیات‌های Sorted Set:O(log N) هستندو برای آپدیت‌های پرتعداد عالی‌انداما یک هشدار جدی وجود دارد:اگر ZRANGE را با خروجی خیلی بزرگ صدا بزنی(مثلاً ده‌ها هزار یا صدها هزار عضو)،هزینه‌اش دیگر فقط لگاریتمی نیست.در این حالت:هزینه می‌شود O(log N + M)که M تعداد آیتم‌های برگشتی استنتیجه‌ی عملی:لیدربورد را صفحه‌بندی‌شده بگیر، نه یک‌جا.اگر Sorted Set تنها کافی نبود چه؟گاهی Sorted Set فقط نقش ایندکس را دارد،و داده‌ی اصلی جای دیگری است.در این سناریوها:می‌توانی ZSET را برای رتبه‌بندی نگه داریو دیتای واقعی را در ساختارهای دیگر ذخیره کنییا سراغ امکانات Query و JSON در Redis برویاما این تصمیم، بعد از درک درست Sorted Set گرفته می‌شود، نه قبلش.سخن پایانیبا رشد سیستم‌های بلادرنگ، حجم بالای داده و نیاز به پاسخ‌دهی سریع در محصولات دیجیتال، انتخاب درست ساختار داده و الگوی معماری نقش مستقیمی در مقیاس‌پذیری و پایداری سامانه‌ها دارد. Redis و به‌ویژه Sorted Set نمونه‌ای از ابزارهایی هستند که اگر درست درک و استفاده شوند، می‌توانند بخش مهمی از پیچیدگی سیستم‌هایی مثل لیدربورد، رتبه‌بندی و محدودسازی درخواست‌ها را به‌صورت ذاتی حل کنند.اگر در حال طراحی یا بازطراحی سامانه‌هایی با بار بالا، نیاز به رتبه‌بندی، یا منطق‌های real-time هستید، تیم معماری و توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) می‌تواند از تحلیل مسئله تا طراحی معماری و پیاده‌سازی عملیاتی، همراه شما باشد.این مقاله با هدف انتقال تجربه و آگاهی‌بخشی فنی، توسط تیم توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#Redis#SortedSet#Leaderboard#Scalable_Systems#Backend_Architecture#System_Design#High_Performance#RealTime_Systems#Data_Structures#Software_Engineering#DevTools#شرکت_راهکار_نگار_هوشمند#arcanco

معماری MaMa-CRM در قالب arc42

محمد حسین جلیلی — Sun, 14 Dec 2025 13:36:18 +0330

در ادامهٔ مجموعه مقالات ما دربارهٔ مستندسازی معماری با الگوی arc42، اینبار به سراغ یکی از مهمترین و پیچیدهترین مثالها میرویم: سیستم MaMa-CRM؛ سامانهای واقعی، عملیاتی و بزرگ که در دنیای کسبوکارهای انبوه (Mass Market) بهکار گرفته میشود.MaMa-CRM برای سازمانهایی طراحی شده که روزانه با میلیونها مشتری سر و کار دارند؛سازمانهایی مثل:شرکتهای بیمهاپراتورهای تلفن همراهارائهدهندگان خدمات انرژی و آببانکها و شرکتهای کارت اعتباریشرکتهای بزرگ مدیریت املاکدر چنین بازارهایی، ارتباط با مشتری معمولاً گسترده، تکرارشونده و در مقیاس بسیار بزرگ است. در بسیاری از این صنایع، این ارتباطها سالها روی کاغذ مدیریت میشد. وظیفهٔ MaMa-CRM این بود که این بار سنگین را از دوش سازمانها بردارد و بهصورت دیجیتال و خودکار مدیریت کند.جالبتر اینکه MaMa-CRM ابتدا برای یک پروژهٔ بسیار مهم و حساس ساخته شد:پشتیبانی از راهاندازی “کارت سلامت الکترونیک آلمان”.بعدها همین پلتفرم در کمپینهایی مثل صدور قبوض تلفن، قرائت کنتور برق، مدیریت اطلاعات مشترکین و موارد مشابه نیز استفاده شد.یکی از ویژگیهای منحصربهفرد این سیستم این است که:برای هر مشتری سازمانی (Mandator)، یک نسخه کاملاً مستقل و جداگانه از MaMa-CRM اجرا میشود.این استقلال باعث میشود هر سازمان بتواند بهصورت اختصاصی، با پیکربندی مخصوص خود و برای کمپینهای خاص خود از سیستم استفاده کند. همین نیاز به انعطافپذیری عمیق موجب شد تصمیمات معماری مهمی در طراحی MaMa-CRM گرفته شود—و این مثال را به یک نمونه ایدهآل برای آموزش arc42 تبدیل میکند.تیم توسعهٔ MaMa-CRM شامل ۷ تا ۱۰ نفر بود که طی ۱۵ ماه، در اسپرینتهای ۲ تا ۴ هفتهای روی این پروژه کار کردند.خود گرنوت استارکه (نویسندهٔ arc42) یکی از اعضای اصلی این تیم بوده و اجازه یافته دربارهٔ این سیستم صحبت کند—البته بدون افشای نام شرکت.در این مقاله، ما قصد داریم:معماری سیستم MaMa-CRM را از زاویهٔ الگوی arc42 بررسی کنیمنیازمندیهای کلیدی و چالشهای طراحی را تحلیل کنیمو ببینیم چگونه یک سیستم واقعی در دنیای کسبوکارهای انبوه میتواند از مستندسازی معماری بهره ببرداین مثال، برخلاف HSC، کاملاً صنعتی، بزرگ و چندلایه است؛به همین دلیل، بهترین نمونه برای یادگیری معماری سیستمهای واقعی محسوب میشود.III.1 مقدمه و اهداف سیستم MaMa-CRMسیستم MaMa-CRM یک پلتفرم نرمافزاری گسترده و انعطافپذیر است که برای مدیریت و هماهنگی فرآیندهای ارتباط با مشتری در کسبوکارهای انبوه طراحی شده است؛ کسبوکارهایی که میلیونها مشتری دارند و تعاملات روزانهشان آنقدر زیاد است که مدیریت آنها بهصورت دستی یا کاغذی کاملاً غیرواقعی و پرخطا میشود.این پلتفرم بهگونهای ساخته شده که بتواند برای صنایع مختلف، با نیازهای کاملاً متفاوت، پیکربندی شود—بدون آنکه نیاز به تغییر کد داشته باشد. همین موضوع، MaMa-CRM را از یک «سامانهٔ ساده» به یک خانوادهٔ محصول (Product Family) تبدیل میکند؛ سیستمی که هستهٔ مشترک دارد، اما هر مشتری سازمانی میتواند نسخهٔ اختصاصی خود را دریافت کند.MaMa-CRM توسط چه سازمانی توسعه و راهبری میشود؟این سیستم توسط یک دیتاسنتر نوآور (که در این متن “InDAC” نامگذاری شده) ساخته و پشتیبانی شده است—شرکتی که خدمات نرمافزاری مدیریتشده (Hosted Services) برای سازمانهای بزرگ ارائه میدهد.InDAC بهعنوان پیمانکار، برای هر یک از mandatorها (سازمان مشتری) یک نسخهٔ مستقل از MaMa-CRM را اجرا و عملیاتی میکند.مسئلهای که MaMa-CRM حل میکند چیست؟کسبوکارهای انبوه—مانند بیمه، مخابرات، بانکداری و مدیریت انرژی—نمیتوانند ارتباطات مشتری را بهصورت دستی مدیریت کنند.این ارتباطات شامل:ارسال پیشنهادهای جدیداطلاعرسانی تغییرات قرارداددریافت بازخورد مشتریجمعآوری اسناد یا تأییدیههاپیگیری وضعیت ارتباطاتاست و معمولاً از چندین کانال مختلف انجام میشود:ایمیل، پیامک، تماس تلفنی، فکس، نامه، یا حتی مراجعه حضوری.بدون یک سیستم متمرکز، این ارتباطات:گم میشوندخطا دارندقابل نظارت نیستندو کیفیت خدمات بهشدت افت میکندMaMa-CRM برای حل همین مشکل طراحی شده است.چند مثال واقعی از استفادهٔ MaMa-CRMبرای درک بهتر دامنهٔ سیستم، چند نمونه از کمپینهای رایج که MaMa-CRM پشتیبانی میکند را مرور میکنیم:۱) مدیریت تغییرات قرارداد و تعرفههای جدید (Telecom، Insurance، ISP)مثلاً:اپراتور تلفن همراه یک طرح جدید ارائه میدهد و مشتریان باید تأیید کنند، سؤال بپرسند یا نظرشان را اعلام کنند.MaMa-CRM تمام این تعاملات را ساماندهی میکند.۲) ارسال صورتحساب و رسیدگی به پشتیبانی (Call-by-call Providers)Mandator دادههای صورتحساب را به MaMa ارسال میکند و سیستم:چاپ قبضهاارسال آنهاو مدیریت درخواستهای پشتیبانیرا هماهنگ میکند.(تسویه حساب مالی خارج از محدودهٔ سیستم است.)۳) مدیریت عکسهای کارتها (Credit Cards، Insurance، e-Health Card)در برخی سیستمها، عکس مشتری باید روی کارت چاپ شود.MaMa-CRM مدیریت ذخیره، پردازش و تخصیص این تصاویر را انجام میدهد.۴) قرائت کنتور برق، آب یا گازشرکتهای انرژی یا املاک از MaMa-CRM برای:جمعآوری دادهپیگیری وضعیتو مدیریت چرخهٔ ارتباط با مشتریاناستفاده میکنند.تمرکز اصلی معماری MaMa-CRM: انعطافپذیری شدیداز آنجا که MaMa-CRM قرار است برای صنایع مختلف، با ورودیها، خروجیها، کانالها و فرآیندهای کاملاً متفاوت استفاده شود، یک الزام کلیدی وجود دارد:سیستم باید بدون تغییر کد، برای هر mandator و هر کمپین قابل پیکربندی باشد.این نیاز معماری را بهشدت تحت تأثیر قرار داده و باعث شده طراحی سیستم بر پایهٔ موارد زیر انجام شود:جداسازی کامل هستهٔ سیستم از اجزای پیکربندیشوندهپشتیبانی از کانالهای مختلف ارتباطیپشتیبانی از مدلهای مختلف دادهپشتیبانی از انواع متفاوت فرآیندهای کاریاجرای نسخههای کاملاً مستقل برای هر mandatorاین نیازمندیها بسیاری از تصمیمات معماری مهم را شکل دادهاند که در بخشهای بعدی arc42 به آنها خواهیم پرداخت.III.1.1 – مرور نیازمندیها Requirements OverviewMaMa-CRM یک سیستم بسیار انعطافپذیر و چندمنظوره است که برای پشتیبانی از کمپینهای CRM در مقیاس انبوه طراحی شده.در این سیستم، سازمانهایی مانند:اپراتورهای تلفن همراهشرکتهای بیمهارائهدهندگان اینترنتشرکتهای انرژی و آبو حتی مؤسسات مدیریت املاکنقش «Mandator» یا مشتری سازمانی را دارند.این سازمانها بخشی از فرآیندهای ارتباط با مشتریشان را به شرکت InDAC واگذار میکنند، و InDAC با استفاده از MaMa-CRM آنها را بهصورت حرفهای اجرا و مدیریت میکند.به بیان سادهتر:MaMa-CRM، مغز عملیاتی کمپینهای بزرگ ارتباط با مشتری است.و باید بتواند با سازمانهایی کار کند که میلیونها مشتری دارند و تعاملاتشان از دهها مسیر مختلف وارد سیستم میشود.کمپینهایی که MaMa-CRM باید پشتیبانی کندبرای اینکه MaMa-CRM یک پلتفرم واقعی و صنعتی باشد، باید بتواند چند نوع کمپین CRM را بدون تغییر کد، تنها با پیکربندی پشتیبانی کند. برخی از مهمترین سناریوها عبارتاند از:۱) تغییر تعرفه یا بهروزرسانی قراردادهادر صنایع مانند بیمه، مخابرات، اینترنت یا انرژی، قراردادها و تعرفهها دائماً تغییر میکنند.ماجرا گاهی ساده است (بهروزرسانی قیمت)، اما اغلب پیچیدهتر:مشتری باید آگاه شودباید تصمیم بگیردپاسخ از کانالهای مختلف میرسدو درصورت پذیرش، قرارداد باید بهصورت قانونی آپدیت شودMaMa-CRM باید بتواند همهٔ این اتفاقات را هماهنگ کند.۲) پردازش اطلاعات صورتحساببرای مثال:شرکتهای «call-by-call» دادههای خام صورتحساب را به MaMa میفرستند.MaMa:دادهها را دریافت و پردازش میکندآنها را برای چاپ و ارسال آماده میکندو پشتیبانی لازم پس از ارسال را مدیریت میکندپرداخت و امور مالی خارج از محدودهٔ سیستم هستند.۳) مدیریت تصاویر کارتها (Credit Card / Insurance / e-Health Card)بسیاری از کارتها مانند کارت سلامت آلمان، تصویر دارنده را روی کارت چاپ میکنند.MaMa-CRM باید بتواند:تصاویر را ذخیره کندمدیریت چرخه پردازش را انجام دهدو نتیجه را برای چاپگر کارت آماده کند۴) مدیریت قرائت کنتور آب/برق/گازشرکتهای انرژی یا املاک، دادههای مربوط به قرائت کنتور را جمعآوری و مدیریت میکنند.MaMa-CRM باید فرآیند جمعآوری داده، هماهنگی، پاسخگویی و پردازش را مدیریت کند.نکتهٔ کلیدی معماری: انعطافپذیری مطلق در ورودی/خروجیچون MaMa-CRM نقش یک «پلتفرم CRM چندصنعتی» دارد، یک الزام بزرگ وجود دارد:MaMa-CRM باید بدون نیاز به تغییر کد، برای هر Mandator و هر کمپین قابل پیکربندی باشد.این یعنی:فرمتهای مختلف داده باید پشتیبانی شوندکانالهای ارتباطی مختلف باید قابل انتخاب باشندفرآیندها باید قابل تغییر و تنظیم باشندسیستم باید بتواند با انواع OCR، چاپگر، مرکز تماس، API و غیره صحبت کندهمین الزام پایهٔ بسیاری از تصمیمات معماری MaMa-CRM بوده است.III.1.1.1 مثال کمپین: اصلاح قرارداد مشترکین یک اپراتور موبایلبرای درک بهتر دامنه و پیچیدگی سیستم، مثال MoPho—a hypothetical mobile provider—در کتاب آورده شده است.این مثال، ترکیبی از چالشهای تجاری، حجم دیتای بالا و کار عملیاتی است.MoPho میلیونها مشترک دارد و قصد دارد تعرفههای قدیمی و غیرسودده خود را حذف کند. بنابراین:تعرفههای جدید را طراحی میکند.مشتریان واجد شرایط را انتخاب میکند (حدود ۱۰ میلیون نفر).پیشنهاد جدید را برای آنها ارسال میکند.به واکنش مشتریان از هر کانال ممکن پاسخ میدهد.و در صورت پذیرش، قرارداد جدید را ثبت میکند.MoPho خودش نمیخواهد با پیچیدگیهای عملیاتی درگیر شود:چاپ نامهمدیریت بازگشت نامههاپاسخگویی تلفنیپردازش فاکسOCR و پردازش فرمهاتشخیص خطاهای مشتریانمدیریت استثناهاو صدها حالت مختلف تعامل انسانیاینها خارج از حوزهٔ تخصص اپراتور هستند.بنابراین همهٔ این فرایندها را به MaMa-CRM میسپارد.چرخهٔ کامل این کمپین—گامبهگام۱) انتخاب و ارسال داده مشتریان به MaMaMoPho داده ۱۰ میلیون مشتری را استخراج و به MaMa ارسال میکند.MaMa آنها را وارد سیستم میکند.۲) ارسال داده لازم برای چاپ نامهMaMa اطلاعات لازم را به شرکت چاپ (Partner) میفرستد.این شرکت نامههای شخصیسازی شده را تولید و ارسال میکند.۳) آمادهسازی مرکز تماس (Partner)MaMa اطلاعات کمپین را برای Call Center ارسال میکند تا آمادهٔ پاسخگویی باشند.۴) مدیریت نامههای برگشتی یا ردشدهPostal Service موارد زیر را گزارش میدهد:آدرس اشتباهForwarding requestمشتری نامه را نپذیرفتهMaMa این موارد را تحلیل و تصمیم لازم را میگیرد.۵) مشتری تصمیم میگیردو حالتهای مختلف رخ میدهد:فرم را کامل میکند و امضا میکندفرم را پر میکند اما امضا نمیکندفرم ناقص ارسال میشودمشتری از طریق تلفن سؤال میکندمشتری بیتفاوت استیا شرایط ویژه وجود دارد: زیر سن قانونی، فوت شده، ناتوانی حقوقی و…۶) فرمها اسکن و OCR میشوندشرکت Partner فرمها را اسکن و نتیجه را برای MaMa ارسال میکند.۷) MaMa نتایج را دریافت و تحلیل میکند۸) تصمیمگیری براساس وضعیت هر مشتریMaMa باید همهٔ حالات ممکن را مدیریت کند—از کامل بودن تا ناقص بودن یا عدم ارسال.۹) بهروزرسانی اطلاعات در سیستم Mandatorدر نهایت، قراردادهای جدید برای مشتریانی که پذیرش کردهاند ثبت میشود.مزیت اصلی برای اپراتور چیست؟MoPho یک چیز بهدست میآورد:یک نقطهٔ مرکزی برای مدیریت کل کمپین—بدون نیاز به دخالت مستقیم.و این یعنی:هزینه کمترسرعت بالاترکیفیت پاسخگویی بهترکاهش خطاامکان مدیریت میلیونها مشتریو مخصوصاً:انعطافپذیری بینهایت در هماهنگسازی با انواع سیستمها و شرکای بیرونی.1.1.2 Campaign Configuration – پیکربندی کمپینها در MaMa-CRMMaMa-CRM یک پلتفرم عمومی نیست که بتوان آن را «نصب و اجرا» کرد.این سیستم یک زیرساخت CRM چندمنظوره است که برای هر Mandator (سازمان مشتری) باید:پیکربندی شودشخصیسازی شودبه چندین شریک (Partner) متصل شودو همهٔ این موارد بدون تغییر کد انجام شوندبهعبارت دیگر:هر کمپین در MaMa مانند یک سیستم مستقل است که کاملاً با تنظیمات ساخته میشود.در ادامه، مراحل اصلی پیکربندی یک کمپین—با مثال MoPho—را مرور میکنیم.۱) پیکربندی دادههای اصلی مشتری (Client Master Data)این مرحله معمولاً توسط خود Mandator تأمین میشود و شامل تعریف تمام اطلاعات لازم دربارهٔ:قرارداد مشتریتعرفه فعلیتعرفههای پیشنهادی جدیدتاریخ اعتبار قرارداد فعلیتاریخ شروع تعرفهٔ جدیداین دادهها در قالب مدلهای UML بهعنوان Extension روی مدل پایهٔ MaMa اعمال میشوند.به این ترتیب:مدل پایه ثابت میمانداما برای هر صنعت (Telecom، Insurance، Banking…) دادههای اختصاصی تعریف میشوداین بخش یکی از مهمترین پایههای انعطافپذیری معماری است.۲) پیکربندی کانالهای ارتباطیMaMa-CRM باید با چندین Partner و Mandator ارتباط داشته باشد، بنابراین نیاز است:تبادل اطلاعات امنیتی مانند رمز عبور، Certificate و User IDتعریف کانالهای تبادل دادهمشخص کردن نقطه تماس فنی در هر سازماناین کانالها میتوانند شامل:اتصال به Print Service Providerاتصال به Call Centerاتصال به Scan Service Providerارتباط با سیستمهای IT خود Mandatorباشند.۳) تعریف فراداده کمپین (Campaign Meta Data)برای اینکه یک کمپین CRM بتواند اجرا شود، باید ابتدا:تاریخ شروع و پایان کمپینتاریخهای مهم برای فعالیتهاآدرسهای پاسخ (Reply Address)ایمیل و شمارهٔ اختصاصی Call Centerتعریف شوند.این اطلاعات برای هماهنگی هزاران یا میلیونها تعامل انسانی ضروری است.۴) تعریف فعالیتهای کمپین (Campaign Activities)در MaMa هر کمپین از چندین فعالیت تشکیل شده است که در سه گروه اصلی قرار میگیرند:الف) فعالیتهای خروجی (Output Activities)کارهایی که MaMa باید برای ارسال داده انجام دهد، مثلاً:ارسال داده به شرکت چاپ: PrintLetterارسال داده به Call Centerارسال داده به Scan Service Providerارسال نتایج نهایی به Mandatorارسال سفارش تولید کارت (Card Production Order)ب) فعالیتهای ورودی (Input Activities)دادههایی که MaMa باید از Mandator یا Partners دریافت کند:دادههای اولیه مشتریان (Master Data Import)دادههای OCR پس از اسکن فرمهادادههای Call Centerخروجی فروشگاههای حضوری (Sales Outlet Import)ج) فعالیتهای داخلی (Internal Activities)کارهای نگهداری و پاکسازی دیتای حساس، مانند:حذف دادهٔ مشتری ۶۰ روز پس از پایان پردازشحذف کل دادههای کمپین ۱۲۰ روز پس از پایان رسمی کمپین(این موارد برای رعایت قوانین امنیت و حریم خصوصی ضروریاند.)۵) مدلسازی جریان کمپین (Campaign Flow Modeling)پس از تعریف فعالیتها، باید مشخص شود:چه فعالیتی در چه شرایطی اجرا میشود؟مسیرهای خوشرفتار (Happy Path) و مسیرهای خطا چیست؟اگر داده ناقص باشد چه باید کرد؟اگر مشتری پاسخ ندهد چه اتفاقی میافتد؟چگونه plausibility validation انجام میشود؟این مدل کسبوکار پیچیده، یکی از تفاوتهای اساسی MaMa-CRM با یک CRM معمولی است.1.1.3 فعالیتهایی که هزینه ایجاد میکنند (Activities Subject to Charge)در بسیاری از کمپینها، بعضی فعالیتها هزینهٔ مستقیم مالی دارند، مانند:چاپ و ارسال نامه برای مشتریتولید کارت برای بیمه یا کارت بانکی (Card Production Charges)از آنجا که ممکن است میلیونها فعالیت در یک کمپین انجام شود، هزینهها بسیار قابلتوجه هستند.نکتهٔ مهم:MaMa-CRM مسئول مدیریت مالی یا تسویه حساب نیست.صورتحساب و پرداختها توسط واحد مالی InDAC یا خود Mandator مدیریت میشود.MaMa فقط باید:تعداد فعالیتهاوضعیت پیگیریو گزارش دقیق برای حسابداریرا ارائه دهد.1.1.4 نیازمندیهای تکمیلیدر این بخش چند الزام مهم و غیرقابلچشمپوشی مطرح میشود:۱) گزارشدهی وضعیت و گزارشهای مالیMaMa باید گزارشهای جامع ارائه دهد، شامل:تعداد نامههای ارسالشدهتعداد تماسهای Call Centerتعداد فرمهای بازگشتیتعداد مشتریانی که تغییر تعرفه را پذیرفتهاندو بهویژه:گزارش دقیق فعالیتهای دارای هزینه.این گزارشها پایهٔ محاسبهٔ هزینهها در InDAC است.۲) مالکیت داده و الزامات امنیتییک اصل بنیادین در MaMa-CRM:دادهٔ مشتری همیشه متعلق به Mandator است، نه InDAC.این یعنی:داده باید محرمانه نگه داشته شودفقط برای همان کمپین استفاده میشودپس از پایان رسمی کمپین،تمام دادهها—شامل Backup، پیکربندی، Metadata—باید حذف شونداین الزام معماری را بهشدت تحت تأثیر قرار میدهد، مخصوصاً در بخشهای دیتابیس، ذخیرهسازی و جریان داده.1.2 اهداف کیفی MaMa-CRM – چرا «انعطافپذیری» مهمترین اصل معماری است؟اگر بخواهیم فقط یک واژه برای توصیف هویت معماری MaMa-CRM انتخاب کنیم، آن واژه Flexibility یا «انعطافپذیری» است.MaMa-CRM در اصل یک Data Hub بسیار تطبیقپذیر است؛ سیستمی که باید بتواند:از دهها نوع منبع داده ورودی دریافت کندقوانین تجاری کاملاً متفاوت را اجرا کندداده را به انواع شرکای تجاری صادر کندو این کار را بدون تغییر کد و تنها با «پیکربندی» انجام دهداین نیازها باعث شده معماری MaMa-CRM حول محور چهار نوع انعطافپذیری طراحی شود:Aspect 1 — انعطافپذیری در ساختار و فرمت دادهMaMa در تمام کمپینها با دادهٔ مشتری سر و کار دارد؛ اما مشکل اینجاست که:هر Mandator (بیمه، بانک، تلفن همراه، انرژی…)هر Partner (چاپ، مرکز تماس، OCR، فروشگاهها)همه فرمت دادهٔ مخصوص خودشان را دارند.MaMa باید همهٔ این فرمتها را پشتیبانی کند، از جمله:فرمتهای متداولCSV با جداکنندههای مختلف (, ، ; ، | و…)رشتههایی با کوتیشنهای مختلف (" , ' , « »)فایلهایی با طول ثابت (Fixed-Length Records)مجموعهای از XMLهای متفاوت با Schema یا DTDهای سفارشیاما مهمتر اینکه:MaMa باید بتواند بدون تغییر کد، فرمت هر Mandator را فقط با پیکربندی قبول کند.بنابراین سیستم باید:ترتیب ستونهاانواع دادههاقواعد اعتبارسنجی (Validation & Plausibility Checks)را برای هر کمپین بهطور سفارشی پیکربندی کند.Aspect 2 — انعطافپذیری در روشها و پروتکلهای انتقال دادهMaMa فقط با فرمتها سروکار ندارد—بلکه باید داده را از طریق چندین کانال مختلف دریافت و ارسال کند.MaMa باید بتواند کار کند با:ftp و sftphttp و https(هم به عنوان Client و هم Server)و همچنین باید بتواند:دادهٔ فشردهشده را بپذیرد (Compression الگوریتممحور و قابل پیکربندی)دادهٔ رمزگذاریشده را مدیریت کند (PGP یا مشابه آن)چکسام تولید کند (MD5، SHA-1 یا شمارندههای مخصوص)Credentials اختصاصی هر Mandator را مدیریت کندبه زبان ساده:هر کمپین باید بتواند کانال ارتباطی مخصوص خودش را داشته باشد.این سطح از انعطافپذیری الزامات امنیتی، کارایی و سازگاری را مستقیماً تحت تأثیر قرار میدهد.Aspect 3 — انعطافپذیری در قوانین تجاری و قوانین کمپیناینجا جایی است که MaMa-CRM از یک سیستم ساده به یک «پلتفرم فرآیندی» تبدیل میشود.برای هر کمپین باید بتوان پیکربندی کرد:قوانین اساسی کمپین:کدام فعالیتها باید انجام شوند؟ترتیب اجرای فعالیتها چیست؟چه رویدادهایی از طرف Partner باید باعث اجرای کدام فعالیت شوند؟قوانین تعامل با مشتری:چند بار باید نامهٔ یادآوری ارسال شود؟چه زمانی باید مشتری را تلفنی پیگیری کرد؟کدام اطلاعات از مشتری الزامی است؟چه زمانی باید دادهها حذف یا آرشیوشده شوند؟قوانین واکنشی:اگر مشتری پاسخ نداد چه کنیم؟اگر فرم ناقص بود چه کنیم؟اگر امضا نداشت، چطور پیگیری کنیم؟اینها قوانین ثابتی نیستند؛هر Mandator قوانین مخصوص خودش را دارد، و MaMa باید همهٔ آنها را بدون تغییر کد پشتیبانی کند.Aspect 4 — انعطافپذیری در خروجی دادهپس از پردازش دادههای مشتری، MaMa باید نتیجه را به چند Partner مختلف ارسال کند.هر Partner الزامات خاص خود را دارد:شرکت چاپ → فرمت Fixed-Lengthمرکز تماس → CSVسیستم کارت سلامت → XMLMandator → فرمت سفارشیبه همین دلیل، معماری MaMa-CRM باید بتواند:از یک ورودی مشترک، چندین خروجی متفاوت بسازد—کاملاً با نیاز هر Partner.یک سناریوی واقعی:داده از Mandator به صورت CSV وارد MaMa میشودMaMa آن را پردازش میکندبخشی از داده باید به Partner A به صورت XML صادر شودبخش دیگر باید به Partner B در قالب Fixed-Length فرستاده شوداین نیاز، طراحی لایههای Import / Processing / Export را عمیقاً تحت تأثیر قرار میدهد.1.2.2 Quality Goals (Scenarios) — کیفیتهای سطح ۱کیفیت شماره یک MaMa-CRM، Flexibility است؛ اما باید بهصورت سناریوی عملی تعریف شود تا معماری سیستم بتواند حول آن طراحی شود.Prio = 1 (بالاترین اولویت)سناریوهای کیفیتی شامل این موارد هستند:۱) MaMa میتواند فرمتهای مختلف داده را Import / Export کند:CSV قابل پیکربندیFixed-LengthXML۲) MaMa میتواند از چندین پروتکل ارتباطی استفاده کند:ftp، sftp، http، httpsهمزمان Client و Server۳) دادهٔ فشرده و رمزگذاریشده را مدیریت میکندالگوریتم فشردهسازی قابل تنظیمPGP یا ابزارهای مشابه برای رمزگذاریتبادل امن Certificateها پیش از شروع کمپین۴) مدیریت Metadata مربوط به انتقالمثلاً:هش فایلشمارندهٔ انتقالثبت آخرین انتقال موفق۵) تمام این موارد باید طی یک روز قابل پیکربندی باشنداین نیاز باعث شده بخش "Campaign Configuration" پایهٔ اصلی معماری شود.1.2.2 اهداف کیفی سطح دوم و سوماولویت ۲: امنیت (Security)در MaMa-CRM، امنیت فقط یک ویژگی فنی نیست؛ هستهٔ وجودی سیستم است.این پلتفرم حجم عظیمی از دادههای حساس مشتریان را میان Mandatorها، شرکای تجاری، و زیرساخت InDAC جابهجا میکند—و کوچکترین نشت داده میتواند یک بحران حقوقی، مالی و اعتباری ایجاد کند.بنابراین:هیچ طرف بیرونی کمپین نباید به دادهها یا فرادادهها دسترسی داشته باشد.تمام دادهها—اعم از ورودی، خروجی، ذخیرهشده و موقت—باید در کنترل کامل InDAC باقی بماند.ادمینهای InDAC، قبل از دسترسی به دادهٔ هر کمپین، باید قرارداد عدم افشای اطلاعات امضا کنند (این بخش سازمانی است و جزئیات آن خارج از محدوده سیستم قرار میگیرد).نتیجهٔ معماری:معماری MaMa باید امنیت را در تمام لایهها در نظر بگیرد: زیرساخت، الگوهای ارتباطی، رمزگذاری، دسترسیها، تفکیک محیطها، و جداسازی دادههای Mandatorهای مختلف.اولویت ۳: کارایی اجرایی (Runtime Performance)MaMa-CRM در برخی کمپینها باید دادههایی در مقیاس کشور پردازش کند. برای مثال:سیستم باید بتواند ۲۵۰٬۰۰۰ نامه اسکنشده را در کمتر از ۲۴ ساعت پردازش کند.این الزام باعث میشود:پردازش داده باید کاملاً بهینه و موازیپذیر باشدورودی و خروجی کمپینها باید مقیاسپذیر طراحی شوندصفها، پردازشهای دستهای و مکانیزمهای Retry بخش جداییناپذیر معماری باشنداین سناریو کیفیت «Performance» را به یک الزام معماری جدی تبدیل میکند.1.2.3 موارد خارج از محدوده (Non-Goals)برای جلوگیری از انحراف معماری، MaMa-CRM بهصورت شفاف مشخص کرده چه چیزهایی در حوزهٔ وظایفش نیست:۱) MaMa یک محصول تجاری عمومی نیستMaMa قرار نیست تبدیل به نرمافزاری مشابه Salesforce، Siebel یا محصولات CRM بازار شود.این سیستم صرفاً برای استفادهٔ داخلی InDAC طراحی شده و مستقیماً برای فروش عرضه نخواهد شد.۲) MaMa جایگزین CRM سازمانی نیستMandatorها همچنان CRM اصلی خودشان را دارند؛MaMa صرفاً یک سیستم عملیات کمپین (Operational Campaign Engine) است—not یک CRM کامل.۳) MaMa فرایندهای مالی و پرداخت را مدیریت نمیکندهرچند کمپینها هزینه ایجاد میکنند (مثل چاپ نامه، کارت، تماس تلفنی و…)،پردازش مالی و پرداختها خارج از محدوده MaMa بوده و توسط بخش مالی InDAC یا خود Mandator انجام میشود.این تفکیک باعث میشود معماری MaMa سبکتر و متمرکزتر باقی بماند.1.3 ذینفعان (Stakeholders) — چه کسانی به MaMa شکل میدهند؟MaMa-CRM یک سیستم چندذینفعی است و معماری آن باید نیازهای گروههای مختلفی را برآورده کند. در ادامه، هر ذینفع را با زبان بلاگی توضیح دادهام.Mandator — سازمانهایی که کمپینها را سفارش میدهنداینها شرکتهایی هستند که InDAC را برای اجرای کمپینهای بزرگ انتخاب میکنند: بیمهها، اپراتورها، بانکها، شرکتهای انرژی و…برای Mandator مهمترین خواستهها عبارتاند از:وارد کردن دادهٔ اولیه با کمترین تلاشدریافت خروجیها در قالبهای موردنیاز خودپیکربندی سریع قوانین کمپینشفافیت کامل در گزارشدهی فعالیتهاMandatorها معمولاً دغدغهٔ اجرایی ندارند؛ آنها فقط داده میدهند، نتیجه میخواهند.مدیریت InDAC — مالک سیستم و مسئول گسترش آندر سمت InDAC، مدیریت نیاز دارد:یک پلتفرم انعطافپذیر که بتواند سالها با Mandatorهای جدید سازگار شودعملکرد بالا و قابلاتکا برای پردازش داده در مقیاس بزرگامکانی برای توسعهٔ تدریجی سیستم بر اساس نیازهای جدیدآنها در چرخهای مستمر با تیم معماری و توسعه همکاری میکنند تا نیازهای جدید تعریف شود و سیستم در طول زمان ارتقا پیدا کند.توسعهدهندگان MaMa-CRM — معماران و سازندگان سیستمتیم توسعه وظایف زیر را بر عهده دارد:طراحی ساختار داخلی MaMaپیادهسازی مؤلفهها و ماژولهامشارکت فعال در تصمیمات معماریتضمین پایداری، امنیت و مقیاسپذیریبرای آنها، MaMa یک پلتفرم در حال رشد است، نه یک محصول تمامشده.شرکای تجاری (Partners) — ارائهدهندگان خدمات جانبیاین گروه شامل:شرکتهای چاپمراکز تماسسرویسهای اسکن و OCRارائهدهندگان کارت هوشمندشرکتهای پستی و لجستیکنیاز اصلی آنها:دریافت داده از MaMa در قالبی دقیق و سازگارارسال دادهٔ پردازششده به MaMa با فرمت توافقشدهداشتن رابطهای ارتباطی پایدار و امنتعامل مؤثر MaMa با این شرکا، موفقیت کمپین را تضمین میکند.نهادهای دولتی و قانونگذاردر بسیاری از کشورها کمپینهایی مثل تغییر قرارداد بیمه یا کارت سلامت تحت مقررات سختگیرانه هستند.نهادهای دولتی وظیفه دارند اطمینان حاصل کنند:دادهٔ مشتریان بهدرستی محافظت میشودفرآیندها با قوانین IT-security و حفاظت داده سازگار هستندمحرمانگی و نگهداری داده با استانداردهای قانونی همخوان استاین نقش مستقیماً روی سیاستهای امنیتی MaMa تأثیر میگذارد.جامعه Eclipse RCP (پلتفرم UI)MaMa برای UI خود از Eclipse RCP استفاده میکند.چالش اصلی اینجاست که Eclipse API را مرتب تغییر میدهد و این موضوع روی توسعهٔ رابط کاربری MaMa اثرگذار است.بنابراین تیم MaMa باید دائماً تغییرات پلتفرم را رصد و با نسخههای جدید هماهنگ شود.۱.۳.۱ مورد ویژه: پروژهٔ کارت سلامت الکترونیک آلمان (German e-Health Card)یکی از پیچیدهترین کمپینهایی که InDAC با استفاده از MaMa-CRM میزبانی کرد، پروژهٔ آزمایشی کارت سلامت الکترونیک آلمان بود.این پروژه تحت نظارت یک نهاد دولتی تازهتأسیس انجام میشد؛ نهادی که مسئول تعریف استانداردهای فنی و امنیتی کارت سلامت بود.نکتهٔ چالشبرانگیز برای تیم MaMa-CRM:در آغاز توسعه، استانداردهای رسمی هنوز وجود نداشتند.یعنی تیم باید سیستمی طراحی میکرد که:با استانداردهایی غیرقطعی و در حال تدوین سازگار شودسطح امنیت بسیار بالا داشته باشدبتواند در آینده با الزامات رسمی منطبق گرددو هنوز انعطافپذیری گسترده MaMa را حفظ کنداین سناریو یکی از نقاطی بود که «اهمیت انعطافپذیری» در معماری MaMa را بهشدت برجسته کرد.۱.۳.۲ نقش Mandator و Partner در تعیین جزییات ارتباطیMaMa-CRM مجموعهای از اسناد استاندارد مشخصات اتصال ارائه میدهد؛ اسنادی که باید توسط شرکای کمپین (مثل چاپ، اسکن، مرکز تماس، شرکت پستی و…) برای اتصال به MaMa استفاده شوند.اما در عمل همیشه اینگونه پیش نمیرود.به دلیل انعطاف زیاد MaMa، معمولاً اتفاق برعکس میافتد:Mandatorها و Partnerها فرمت داده و قرارداد ارتباطی خودشان را ارائه میکنند،و MaMa فقط آنها را پیکربندی میکند—بدون تغییر کد.این ویژگی برای InDAC یک مزیت رقابتی عظیم است:اضافهکردن یک Partner یا شروع یک کمپین جدید فقط به تنظیمات وابسته است، نه توسعهٔ نرمافزار.III.2 محدودیتها و الزاماتی که معماری MaMa را شکل دادهانددر طراحی یک پلتفرم CRM در مقیاس ملی، محدودیتها نقشی تعیینکننده دارند.در MaMa، این Constraints جزو ستونهای اصلی معماری هستند.۱) محدودیتهای کلی معماریبدون برنامهنویسی، فقط با پیکربندی باید بتوان کمپین ساختاین مهمترین اصل معماری است:برای ساخت یا اجرای یک کمپین جدید، هیچ تغییری در کد نباید لازم باشد.هرچیز باید از طریق پیکربندی (فایل، UI یا ابزار اختصاصی) انجام شود.تکنولوژی پایه: JavaMaMa باید روی نسخههای جدید JVM قابل اجرا باشد (حداقل نسخه ۱.۶).تمام قابلیتها و توسعهها بر این اساس طراحی شدهاند.بانک اطلاعاتی اجباری: Oracleاین محدودیت به انتخاب تیم نبود؛Holding شرکت InDAC قرارداد سازمانی با Oracle داشت،بنابراین MaMa-CRM اجباری بود روی Oracle پیادهسازی شود.۲) محدودیتهای زیرساخت نرمافزارسیستمعامل: Linux (ترجیحاً RedHat Enterprise)به دلیل سختگیریهای امنیتی، نسخههای Hardened ردهت انتخاب اصلی بودند.استفاده از نرمافزارهای متنباز با لایسنس آزادGNU و FSF مجاز نبودند—در نتیجه انتخاب ابزارها کاملاً محدود میشد.ترجیح توسعه مبتنی بر Code Generation / مدلسازی MDSDتوسعه باید با حداقل کدنویسی و حداکثر تولید خودکار انجام شود.این موضوع بر ساختار لایه دامنه و مدل داده اثر جدی گذاشت.استفاده از ابزار مدلسازی (UML) توصیهشدهبه دلیل نیاز به مستندسازی سنگین، UML یکی از ابزارهای کلیدی تیم بود.توسعهٔ تدریجی (Iterative) توصیه میشوداما اجباری نبود؛ تیم آزادی عمل داشت تا روش مناسب خود را انتخاب کند.نیاز به مستندسازی فنی «عمیق و پایدار»InDAC تأکید داشت که:سیستم باید قابل نگهداری در درازمدت باشدمستندات باید واضح، بهروز، و دقیق باشندبه همین دلیل arc42 اساس کار قرار گرفت.۳) محدودیتهای عملیاتی (Operational Constraints)هر کمپین باید روی یک VM جداگانه اجرا شوداین الزام امنیتی باعث شد MaMa یک سیستم کاملاً Multi-Instance باشد.هیچ کمپینی نباید داده یا فرآیند کمپین دیگر را ببیند.اجرا به صورت Batch / Backgroundبیشتر پردازشها:زمانبر،دادهمحور،و شدیداً وابسته به شرکا هستند.بنابراین MaMa باید بدون رابط تعاملی،و صرفاً در حالت پردازش پسزمینه اجرا شود.تمام پیکربندیها باید از طریق یک افزونهٔ سفارشی Eclipse یا رابط وب قابل انجام باشدتیم InDAC به ابزاری نیاز داشت که بتواند:کمپین را ایجاد کندورودی/خروجیها را تنظیم کندقوانین را تعریف کندو تمام چیزها را بدون لمس Backend پیکربندی کنداین مورد تأثیر مستقیم روی طراحی UI و API داخلی MaMa داشت.III.3 محدودهٔ سیستم و تعاملات آن System Scope and ContextMaMa-CRM یک سیستم کاملاً «بین سازمانی» است.هر نمونه از MaMa برای یک Mandator و چندین Partner کار میکند.این یعنی هر instance دارای مجموعهای کاملاً مستقل از ورودیها، خروجیها، قوانین و تبادلات داده است.۳.۱ زمینه کسبوکار (Business Context)MaMa میان سه گروه داده جریان ایجاد میکند:۱) Mandator ↔ MaMaMandator دادههای اولیه کمپین را ارائه میکند، شامل:دادهٔ مشتریقراردادهاتعرفههاقوانین کمپینMaMa این داده را پردازش میکند و در پایان، نتیجه نهایی کمپین را به Mandator بازمیگرداند.تبادلات دادهٔ کلیدی شامل:Master Data (ورودی)وضعیت کمپین (خروجی دورهای)درخواستهای رفع ابهام(مثلاً وقتی آدرس غلط است، امضا ناقص است یا دادهٔ مشتری معتبر نیست)این دادهها کاملاً حساس هستند و باید طبق قانون حفاظت داده نگهداری شوند.۲) Partner ↔ MaMaPartnerها شامل:چاپاسکنOCRپستمرکز تماسفروشگاههاارائهدهندگان کارت سلامتهستند.دادههای رد و بدلشده:ارسال دادهٔ مشتری به Partner (Outbound)دریافت نتایج اولیه از Partner (Inbound)این دادهها شامل:اسکنهانتیجهٔ تماسهاوضعیت تحویل نامهلاگهای پردازشMaMa باید قبل از استفاده، نتایج را تحلیل و به وضعیت نهایی تبدیل کند.۳) اصل "Data Minimization"نکتهٔ بسیار مهم در معماری:هر Partner فقط دادهای را دریافت میکند که واقعاً نیاز دارد.مثلاً:مرکز تماس → فقط نام و شماره تماسسرویس چاپ → فقط آدرس و دادههای مربوط به نامهشرکت کارت → فقط تصویر و مشخصات لازم برای چاپ کارتاین اصل، هم امنیت را افزایش میدهد، هم ریسکهای قانونی را کاهش میدهد.۳.۱ زمینهٔ کسبوکار (نسخهٔ رسمی) – Formal Business Contextدر نسخهٔ رسمیتر از دیاگرام زمینهٔ کسبوکار MaMa-CRM، یک بخش مهم اضافه میشود: رابط مدیریت (Admin Interface).این رابط برای تیمهای MaMa و مدیران کمپینها ضروری است، زیرا تمام عملیات حیاتی سیستم از طریق آن انجام میشود:ایجاد یک کمپین جدیدپیکربندی قوانین، فعالیتها و جریان کارتعریف ورودی و خروجیهای دادهمدیریت کاربران و سطح دسترسیهانظارت بر وضعیت کمپین و کنترل عملیاتدر واقع، Admin Interface مغز کنترل MaMa است؛ بخشی که اجازه میدهد بدون تغییر کد، دهها کمپین مختلف برای دهها Mandator اجرا شود.در این دیاگرام رسمی (که در کتاب arc42 نمایش داده شده)، MaMa در مرکز قرار میگیرد و بهعنوان سیستم هماهنگکنندهٔ اصلی بین Mandator، Partnerها و مدیران سیستم عمل میکند.۳.۱.۲ زمینهٔ کسبوکار اختصاصی – سناریوی «اصلاح قرارداد موبایل»در بخش 1.1.1 یک نسخهٔ مفهومی از این سناریو ارائه شد. اما در اینجا ساختار دقیقتر و رسمیتری از تعامل سیستمها و جریان داده نمایش داده میشود.این سناریو یکی از پیچیدهترین نمونههای کمپین است، زیرا:چندین منبع دادهچند مقصد خروجیتبادلات چندمرحلهایفرآیندهای انسانی و ماشینیو قواعد پیچیده تجاریرا درگیر میکند.تصویر کلی سناریو:Mandator (اپراتور موبایل) دادهٔ مشتریان را بارگذاری میکند →MaMa داده را پردازش میکند →اطلاعات لازم به Partnerهای مختلف ارسال میشود (چاپ، اسکن، مرکز تماس…) →نتایج آنها به MaMa بازمیگردد →MaMa همه چیز را تفسیر کرده و نتیجهٔ نهایی را به Mandator برمیگرداند.جریانهای داده در سناریوی اصلاح قرارداد موبایل۱) دادهٔ ورودی از Mandator → به MaMa (Inbound)Mandator مجموعهای از اطلاعات پایه مشتری را ارسال میکند:نام، آدرس و اطلاعات تماساطلاعات قرارداد فعلیجزئیات تعرفهٔ فعلی و تاریخ اعتبارشناسهٔ مشتری و شمارهٔ قرارداداین دادهها معمولاً:در قالب CSVZip شدهو از طریق sftpبارگذاری میشوند.این انتقال دو بار انجام میشود:بار اول: هنگام شروع کمپینبار دوم: هنگام پاسخ به Clarification Requestهای MaMa۲) خروجی MaMa → به Mandator (Outbound)زمانی که MaMa تمام دادهها را پردازش کرد، نتیجهٔ نهایی را ارسال میکند:کدام مشتریان پیشنهاد جدید را پذیرفتهاندتغییرات لازم در قراردادتعرفهٔ جدید و تاریخ اعمال آناین خروجی نیز Zip و از طریق sftp ارسال میشود.MaMa همچنین درخواستهای رفع ابهام را نیز از همین مسیر ارسال میکند:دادهٔ ناقصآدرس اشتباهنبودن امضادادهٔ متناقض با قوانین کمپین۳) دادهٔ خروجی MaMa → به Print ProviderMaMa باید بخشهای مرتبط از داده را به سرویس چاپ ارسال کند:نامآدرسبخشهایی از اطلاعات قرارداد یا تعرفهبرای امنیت بیشتر:فایل CSV فشرده میشود (Zip)سپس PGP رمزگذاری میشودو از طریق HTTP Upload امن منتقل میشودنگاشت فیلدها و قالب دادههر Mandator و Partner فرمت مخصوص خود را دارد.بنابراین لازم است:برای هر Instance از MaMa، نگاشت دقیق فیلدهای داده به ستونهای CSV یا رکوردهای ثابت تعریف شود.این کار با استفاده از یک DSL اختصاصی انجام میشود(توضیح کامل این DSL در بخش ۸.۳ کتاب آمده است: CSV-Import/Export).این DSL به MaMa اجازه میدهد:بدون تغییر حتی یک خط کدساختار دادهٔ هر Mandator را تعریف و اعمال کندو ورودی و خروجیهای متعدد را مدیریت کنداین بخش یکی از دلایل کلیدی معماری «پلتفرم چندسازمانی» بودن MaMa است.۳.۱.۲ زمینهٔ کسبوکار اختصاصی: سناریوی «اصلاح قرارداد موبایل»این بخش نسخهٔ رسمیتر و فنیتر همان مثال فصل 1.1.1 است: کمپین تغییر تعرفهٔ یک اپراتور موبایل (MoPho).در این سناریو، MaMa-CRM نقش «ستون فقرات داده و فرآیند» را ایفا میکند و ارتباط میان Mandator، شرکای بیرونی، و مشتریان را هماهنگ میسازد.این سناریو دقیقاً نشان میدهد که چرا MaMa باید اینقدر انعطافپذیر، مقیاسپذیر و ایمن باشد.جریانهای داده در کمپین تغییر قرارداد موبایل۱) دادهٔ ورودی از Mandator → به MaMaMandator (اپراتور موبایل) برای شروع کمپین، اطلاعات کامل مشتریان را در اختیار MaMa قرار میدهد. این داده شامل:نام و نام خانوادگیآدرس کاملاطلاعات تماساطلاعات قرارداد فعلیتعرفهٔ فعلی و تاریخهای اعتبارکد مشتری یا شناسهٔ مشترکاین دادهها در دو موقعیت ارسال میشوند:در آغاز کمپینهنگام پاسخ به Clarification Requestهاقالب انتقالفایل CSVفشردهشده با Zipمنتقلشده از طریق sftpآپلود توسط خود Mandator۲) خروجی MaMa → به Mandatorپس از پردازش کامل دادهها و دریافت اطلاعات از Partnerها، MaMa نتیجهٔ نهایی را برای Mandator ارسال میکند.این نتایج شامل:وضعیت نهایی هر مشتریتعرفهٔ جدید انتخابشدهتغییرات لازم در قراردادتاریخ اعمال تغییرخروجی نیز مانند ورودی:CSVZip شدهاز طریق sftp ارسال میشودMaMa همچنین درخواستهای رفع ابهام (Clarification Requests) را نیز از همین مسیر ارسال میکند.۳) خروجی MaMa → به سرویس چاپ (Print Service Provider)برای ارسال نامههای پیشنهاد به مشتریان، MaMa بخشهای مرتبط از دادهها را به شرکت چاپ ارسال میکند:نام مشتریآدرس پستیبخشهای موردنیاز از اطلاعات قرارداد و تعرفهاما این انتقال از حساسترین بخشهای کمپین است.به همین دلیل:دادهها ابتدا Zip میشوندسپس با PGP رمزگذاری میشوندو نهایتاً از طریق HTTP Upload امن ارسال میگردنداینجا امنیت، محرمانگی و یکپارچگی داده نقش حیاتی دارند.نگاشت فیلدها: هر Mandator، زبانی متفاوت برای داده داردیکی از چالشهای اصلی MaMa این است که:هر Mandator و هر Partner قالب داده مخصوص خودش را دارد.برای همین، MaMa یک زبان DSL اختصاصی ارائه کرده است که با آن میتوان:فیلدهای مشتریستونهای CSVفرمت رکوردهاقواعد پردازش و اعتبارسنجیرا برای هر کمپین، بدون تغییر در کد، فقط از طریق پیکربندی تعریف کرد.این DSL ستون اصلی Data Flexibility در معماری MaMa است.توضیح فنی این DSL در بخش ۸.۳ کتاب آمده.۳.۲ زمینهٔ فنی و استقرار (Technical / Deployment Context)MaMa-CRM یک سیستم کاملاً multi-instance است؛ یعنی:برای هر Mandator، یک MaMa مستقل اجرا میشودهر کمپین، محیط مخصوص خود را داردهیچ دادهای نباید میان کمپینهای مختلف قابل مشاهده باشدبه همین دلیل معماری MaMa از پایه چند-نمونهای طراحی شده است.استقرار MaMa چگونه انجام میشود؟۱) هر MaMa instance روی یک ماشین مجازی جداگانه اجرا میشوددر حالت استاندارد:هر کمپین یک VM لینوکسی مستقل داردبانک اطلاعاتی آن نیز روی همان VM قرار داردارتباطات خارجی فقط از مسیرهای کنترلشده مجاز استدسترسی ssh تنها برای شبکه داخلی InDAC فعال استاما برخی Mandatorهایی که سطح امنیت بسیار بالایی میخواستند، اصرار داشتند:MaMa برای کمپین آنها باید روی یک سرور فیزیکی اختصاصی نصب شود.این موضوع به طور طبیعی هزینهٔ کمپین را افزایش میدهد.۲) سختافزار InDACتمام instanceها روی سرورهای سازمانی مستقر هستند:Dell، HP یا سختافزار مشابهسیستمعامل RHELمجهز به زیرساخت مجازیسازی (Hypervisor)۳) Mandator و Partnerبرای هر MaMa:یک Mandator وجود دارد (اپراتور موبایل، بیمه، بانک، انرژی و…)چندین Partner وجود دارد (چاپ، اسکن، مرکز تماس، پست، OCR و…)هر Partner یک کانال ارتباطی اختصاصی با MaMa دارد.این کانال میتواند:sftpftphttp(s)و حتی پروتکلهای سفارشیباشد.۴) بانک اطلاعاتی مستقلهر MaMa instance بانک اطلاعاتی Oracle خودش را دارد.چرا؟جداسازی امنیتیاستقلال عملیاتیامکان پاکسازی کامل دادهها پس از پایان کمپینپرهیز از درهمتنیدگی ساختار داده Mandatorهای مختلفIII.4 استراتژی راهحل (Solution Strategy)«چطور معماری MaMa کیفیتهای موردنیاز را تأمین میکند؟»در این بخش، MaMa-CRM توضیح میدهد که برای رسیدن به مهمترین نیازهای کیفی—بهخصوص Flexibility و Performance—از چه رویکردهای معماری استفاده شده است.این بخش عصارهای از تصمیمات کلیدی است؛ تصمیماتی که پایهٔ کل معماری MaMa را شکل میدهند.۱) انعطافپذیری در ساختار داده (Flexible Data Structure)یکی از چالشهای اصلی MaMa این است که هر Mandator ساختار دادهٔ مشتریان خود را دارد.راهحل معماری:ساختار پایگاه داده و کد persistence بهطور ۱۰۰٪ از مدل UML تولید میشود.یعنی:برای هر کمپین، یک مدل دامنه تعریف میشودکد و جدولهای پایگاه داده از آن مدل تولید میشوندبدون نیاز به دستکاری دستی، کد همیشه مطابق مدل بهروز استاین باعث میشود MaMa بتواند برای هر Mandator و هر کمپین، ساختاری متفاوت داشته باشد—بدون تغییر در منطق اصلی سیستم.۲) انعطافپذیری در فرمتهای ورودی/خروجی (CSV & Fixed-Length Files)MaMa باید داده را در فرمتهای مختلفی دریافت و ارسال کند.راهحل:یک زبان دامنهمحور (DSL) اختصاصی برای تعریف CSV و Fixed-Length ایجاد شده است.این DSL:ساختار هر فایلترتیب فیلدهاقواعد اعتبارسنجینحوهٔ تفسیر دادهرا بهصورت پیکربندی تعریف میکند.برای این DSL، تیم MaMa:یک Parser مبتنی بر ANTLR ساختهو Interpreterهای لازم را پیادهسازی کردهاین باعث شده اضافهکردن یک Partner جدید فقط به معنی ایجاد یک فایل DSL جدید باشد نه نوشتن کد جدید.۳) ایجاد Editor اختصاصی برای DSL (Eclipse Plugin)برای اینکه مدیران کمپین بتوانند بدون دانش فنی ساختار داده را تعریف کنند، MaMa یک ویرایشگر اختصاصی داخل Eclipse RCP ساخته است.این ویرایشگر:خطاها را در لحظه بررسی میکندساختار فایل و انواع داده را پیشنهاد میدهدامکان تولید خودکار mapping را فراهم میکنداین ابزار عملاً DSL را از یک ابزار توسعهای به یک قابلیت عملیاتی تبدیل کرده است.۴) کارایی بالا برای پردازش تصویر (Performance Strategy)در کمپینهایی مثل کارت سلامت، MaMa باید صدها هزار تصویر را پردازش کند.راهحل:تصاویر در پایگاه داده ذخیره نمیشوندبلکه روی فایلسیستم ذخیره میشوندبرای هر تصویر از Client-ID یک مسیر و نام یکتای قابل پیشبینی ساخته میشودتست بار (Load Testing) بخشی از CI شدهابزار تولید دادهٔ تست برای عملکرد ایجاد شدهاین تصمیم باعث شده MaMa بتواند:۲۵۰٬۰۰۰ تصویر را در کمتر از ۲۴ ساعت پردازش کند.III.5 نمای بلوکهای سازنده (Building Block View)«معماری MaMa از چه بخشهایی تشکیل شده و هر بخش چه نقشی دارد؟»نمای Building Block لایههای اصلی سیستم را توضیح میدهد.در سطح ۱ (Whitebox Level 1)، ما ساختار کلی MaMa را میبینیم—تقسیمشده بر اساس مسئولیتهای عملکردی.۵.۱ سطح سفید MaMa (Whitebox Level 1)معماری MaMa بر پایهٔ دو اصل ساخته شده است:Functional Decomposition → تقسیم سیستم به بخشهایی با مسئولیت مشخصGenerated Persistence → تولید کامل بخش داده بر اساس UMLدر این سطح، MaMa از چند بلوک اصلی تشکیل شده است:۱) Import Handler — ورودیگیر انعطافپذیراین ماژول وظیفه دارد:داده را از Mandator یا Partner دریافت کندفرمتهایی مثل CSV، Fixed-Length و XML را پردازش کنددادهٔ فشرده یا رمزگذاریشده را مدیریت کندخطاهای ارتباطی یا ساختاری را مدیریت کندویژگی کلیدی:پشتیبانی از کانالهای ورودی کاملاً پیکربندیپذیر.۲) Export Handler — ارسالکنندهٔ داده به شرکاکارها شامل:ارسال دادهٔ پردازششده به چاپ، اسکن، مرکز تماس یا Mandatorاعمال فیلترها و تبدیلهامدیریت رمزگذاری، فشردهسازی و اعتبارسنجیاین Handler مکمل Import Handler است و مشابه آن بر پایهٔ DSL عمل میکند.۳) Configuration — قلب پیکربندی کمپینهااین بخش مسئول تمام پیکربندیهای حیاتی است:قالب ورودی/خروجیکانالهای ارتباطیاطلاعات امنیتیقوانین کمپین (Campaign Rules)فعالیتها، فلوها و شرطهانگهداری و آرشیو دادهتنها با تغییر این بخش، میتوان یک کمپین کاملاً جدید ایجاد کرد.۴) Reporting — گزارشدهی وضعیت کمپینوظایف:تولید گزارشهای وضعیت برای Mandator و Partnerهانمایش پیشرفت کمپینارائهٔ گزارش فعالیتهای حساس مالی۵) Process Control — موتور اجرای کمپینمهمترین بخش MaMa:اجرای قوانین کمپینترتیب فعالیتهامدیریت Workflowزمانبندی عملیاتاجرای Import/Export بر اساس رویدادهاProcess Control چیزی شبیه «موتور جریان کار» (Workflow Engine) است.۶) Campaign Data Management — لایهٔ دادهٔ تولید شدهکاملًا:از روی UML تولید میشودمستقل برای هر کمپینشامل ساختار مشتری، قرارداد، فعالیتها و وضعیتها۷) Operations Monitoring — نظارت عملیاتیوظایف:مانیتورینگ Import و Exportنظارت بر دیتابیسمشاهدهٔ وضعیت کمپینمدیریت هشدارهااین ابزارهای نظارت برای مدیریت چندین کمپین همزمان حیاتی هستند.۸) Code Generator — قلب توسعهٔ سریعاین بخش بهصورت خودکار:ساختار DBکد persistenceentityهارا بر اساس مدل UML ایجاد میکند.این قابلیت یکی از نقاط قوت اساسی MaMa است.Import Handler — قلب ورودی داده در MaMa-CRMImport Handler یکی از حیاتیترین اجزای MaMa است؛ زیرا دقیقاً همان نقطهای است که دادهها از Mandatorها و Partnerها وارد سیستم میشوند.در کمپینهایی که میلیونها مشتری یا صدها هزار فایل اسکنشده وارد سیستم میشود، نحوهٔ مدیریت دادهٔ ورودی نقش تعیینکنندهای در کارایی و صحت کل کمپین دارد.Import Handler مسئول انجام سه کار کلیدی است:دریافت داده از طریق کانالهای مختلفاعمال پردازشهای لازم براساس فرمتها، فیلترها و رمزگذاریهاتبدیل دادهٔ خام به مدل دامنهٔ MaMa و ذخیرهٔ آنبه صورت خلاصه:Import Handler پلی میان دنیای نامنظم شرکای بیرونی و مدل دادهٔ دقیق MaMa است.مسئولیتها و قصد طراحیImport Handler میتواند:CSV،فایلهای Fixed-Length،یا XMLرا با ساختارهای قابل پیکربندی دریافت و پردازش کند.حتی اگر داده:فشرده شده،رمزگذاری شده،یا ترکیبی از این دو باشد،Import Handler آن را مدیریت میکند.این قابلیت به دلیل نیاز کمپینها به فرمتهای متنوع اطلاعات واقعاً حیاتی است.چگونه کار میکند؟ (Interfaces)شرح بلاگی از رفتار Import Handler:۱) خواندن تنظیمات Importپیش از هر چیز، Import Handler تنظیمات مخصوص کمپین را میخواند:ساختار CSVقوانین فیلتر (decrypt, unzip…)کانال انتقال (ftp، http، sftp)اطلاعات امنیتیاینکار باعث میشود Import Handler در هر کمپین رفتار متفاوتی داشته باشد—بدون هیچ تغییر در کد.۲) دریافت فایل یا داده از Mandator/PartnerImport Handler مستقیماً با محیط بیرونی تعامل دارد:اتصال به ftp یا sftpخواندن فایل از سیستم فایلدریافت داده از یک سرویس httpاین نقطهٔ تماس معماری با محیط خارج از سیستم است.۳) تبدیل داده به Client و ذخیره کردنپس از پردازش:دادههای خام تبدیل به آبجکتهای دامنه (Client, Contract…) میشوندسیستم با CampaginDataManagement تماس میگیرد تا این اطلاعات درج یا بهروزرسانی شوداین نقطهٔ اتصال ورودی به مدل دادهٔ داخلی MaMa است.مدیریت خطا: نقطهٔ قوت Import HandlerImport Handler مجموعهٔ قدرتمندی از مکانیسمهای مدیریت خطا دارد:خطاهای ارتباطی (شبکه، دسترسی، ftp…)خطاهای ساختار دادهخطاهای مربوط به فشردهسازیخطاهای رمزگشاییخطاهای رکوردهای ناسالمتقریباً همهٔ خطاهای سطح رکورد قابل بازیابیاند و فقط لاگ میشوند.فقط خطاهای بحرانی باعث توقف فرآیند میشوند.این طراحی به MaMa امکان میدهد با کیفیت دادهٔ بسیار متفاوت شرکا کنار بیاید.Configuration — موتور انعطافپذیری MaMaاگر Import Handler «دهان سیستم» باشد، Configuration مغز سیستم است.همهچیز در MaMa باید بدون برنامهنویسی قابل تغییر باشد؛ از جمله:قالبهای ورودی و خروجیمسیرها و پروتکلهای ارتباطیقوانین کمپینفعالیتها و ترتیب آنهانحوهٔ رمزگذاری/فشردهسازی دادههاConfiguration دقیقاً این کار را انجام میدهد.چه چیزهایی با Configuration کنترل میشود؟۱) تنظیمات Import/Exportشامل:CSVهای قابلپیکربندیfixed-length formatsXML-customendpointهای شبکهنوع رمزگذاری و فشردهسازیاطلاعات امنیتی برای اتصال به شرکا۲) تنظیمات کمپیندر هر کمپین نیاز است تعریف شود:چه فعالیتهایی وجود دارد؟ (Import, Export, Maintenance…)چه دادههایی الزامی هستند؟چه رویدادهایی باعث اجرای چه فعالیتی میشوند؟دادهها چه زمانی پاک/آرشیو میشوند؟این بخش یکی از حساسترین قسمتهای MaMa است.۳) قوانین نگهداری و آرشیومثلاً:حذف داده ۶۰ روز پس از پایان پردازشحذف کل دادهٔ کمپین ۱۲۰ روز پس از پایان رسمی کمپیننحوهٔ تعاملتمام فراخوانیهای Configuration باید با:campaignIDmandatorIDانجام شوند، زیرا هر کمپین کاملاً مستقل است.چیزی که مهم است:هیچ بخشی از سیستم بهطور مستقیم ساختار فایلها را نمیداند؛ همهچیز از Configuration میآید.این معماری باعث ایجاد استقلال شدید، و انعطافپذیری حداکثری میشود.MaMa Level 2 — ساختار Whitebox Import Handlerبرای مدیریت جریان ورودی داده، Import Handler به بخشهای داخلی مختلفی تقسیم شده است. این یک معماری pipeline-محور است:دریافت فایلفیلترها (decrypt/unzip)تقسیم رکوردهااعتبارسنجیتبدیل به آبجکتذخیرهسازیاجزای زیر این مراحل را انجام میدهند:Receiver — نقطهٔ ورود دادهوظیفهٔ Receiver:گوش دادن به پوشهها (Directory Listener)یا سرویسهای وبیا Listenerهای پیامReceiver اولین نقطهای است که داده وارد سیستم میشود.ImportErrorHandler — خطامدیری قدرتمنداین بخش:هر نوع خطا را شناسایی میکندخطاهای جدی را متوقف میکندخطاهای سطح رکورد را ثبت میکندبرای خطاهای قابلبازیابی، پردازش را ادامه میدهداین توانایی برای کار با دادههای ناسازگار از چندین Partner ضروری است.ImportData Port — اتصال به بیروناین مؤلفه مستقیماً با سیستمهای خارجی صحبت میکند:ftphttpVPNاین دقیقاً "دروازهٔ ارتباطی MaMa" است.FileArchiver — آرشیو غیرقابل حذفتمام فایلهای ورودی باید برای ممیزی ذخیره شوند.این آرشیو:غیرقابل حذفقابل بازرسیو مستقل از فرایند Importاست.FileFilter — لایهٔ فیلترهای پردازششامل:decryptunzipdecompressionو هر فیلتر دیگری که در DSL تعریف شوداین همانجاست که قالب فایل به حالت استاندارد تبدیل میشود.Validator — اعتبارسنج دادهاز سطح فایل تا سطح رکورد، Validator بررسی میکند:فرمت داده درست باشدمقادیر با قوانین کمپین سازگار باشنداشیاء ساختهشده معتبر باشندUnMarshaller — تبدیل رشته به آبجکتیکی از بخشهای جادویی MaMa.با استفاده از Reflection:خطوط و رکوردهای فایل تبدیل به آبجکتهای دامنه (Client, Contract…) میشوند.این بخش پیچیده است، اما ستون اصلی سیستم هنگام ورود داده است.MaMa Level 3 — جزئیات داخلی ReceiverReceiver خود به چند بخش تقسیم میشود:لایهی Directory/WebService/Message Listenerاین لایه:ورود فایلها را زیر نظر داردپوشههای محلی یا ریموت را مانیتور میکندپیامها یا سرویسهای وب را گوش میدهدReceiver بسته به کمپین، متفاوت پیکربندی میشود.FileProcessor — قلب جریان ورودیاین بخش:فایل را unzip میکندdecrypt میکندآن را آرشیو میکندرکوردها را جدا میکندو همهٔ فیلترها را اعمال میکنددر کتاب اشاره شده:«کد آن شبیه اسپاگتی است!»اما در عمل، این بخش حجم اصلی پردازش خام ورودی را انجام میدهد.مولفه FileToRecordSplitterاین مؤلفه:فایل را به رکوردهای منطقی تبدیل میکندمعمولاً هر خط = یک رکورد استاما در برخی فرمتها چند خط یک رکورد را تشکیل میدهنداین بخش کاری شبیه parsing اولیه انجام میدهد.III.6 نمای زمان اجرا (Runtime View)«MaMa در عمل چگونه کار میکند؟»تا اینجا معماری MaMa-CRM را بهصورت ایستا دیدیم: کامپوننتها، مسئولیتها و ساختار کلی.اما Runtime View نشان میدهد که این اجزا در زمان اجرا چگونه با هم تعامل میکنند و یک سناریوی واقعی را به پایان میرسانند.یکی از مهمترین و پرتکرارترین سناریوها در MaMa، وارد کردن فایل (Import File) است.6.1 سناریوی Import Fileفایلهای ورودی میتوانند از طرف Mandator یا Partner ارسال شوند، اما یک ویژگی مشترک دارند:همهٔ آنها حاوی دادههای مرتبط با Client هستندو در قالبهایی مانند CSV، Fixed-Length یا XML میآیند.معماری MaMa این سناریو را عمداً به دو فاز جدا تقسیم کرده است:Import Raw File (دریافت و آمادهسازی فایل خام)Validate & Process (اعتبارسنجی و بهروزرسانی دیتابیس داخلی)این جداسازی باعث میشود سیستم هم مقاومتر باشد، هم قابلگسترشتر.6.1.1 فاز اول: Import Raw File (پردازش خام و عمومی)در این فاز، هیچ قانون کمپینی اجرا نمیشود.هدف فقط این است که فایل:سالم دریافت شودامن ذخیره شودو به شکل قابل پردازش تبدیل گرددگامهای اصلی این فاز به ترتیب اجرا:۱) شروع Import توسط Process Controlفرآیند Import با یک شناسه یکتا آغاز میشود که شامل:MandatorCampaignActivityاست. این شناسه بعداً برای ردیابی، گزارش و ممیزی استفاده میشود.۲) دریافت تنظیمات ImportMaMa تمام تنظیمات لازم را از Configuration میگیرد:کانال دریافت (ftp, http, …)قالب فایلفیلترهای لازم (decrypt, unzip, …)هیچ چیزی hardcode نیست.۳) آمادهسازی کانال دریافت (configureReceiveChannel)در این مرحله، اتصال به دنیای بیرون شکل میگیرد:URLنام فایلاعتبارنامههامسیرهای دسترسی۴) آرشیو فایل خام (Archive)قبل از هر پردازشی، فایل خام وارد آرشیو غیرقابل حذف میشود.این آرشیو معمولاً write-once است و برای اهداف قانونی و ممیزی نگهداری میشود.این تصمیم معماری، نقش حیاتی در قابلیت audit سیستم دارد.۵) ساخت زنجیره فیلترها (instantiateFilterChain)بر اساس پیکربندی، یک pipeline از فیلترها ساخته میشود؛ مثلاً:unzipdecryptverify checksum۶) اجرای فیلترها (pipes-and-filters)فایل از این زنجیره عبور میکند تا به دادهای «خوانا و امن» تبدیل شود.این طراحی از الگوی Pipes & Filters استفاده میکند و کاملاً پویا و قابل پیکربندی است.6.1.2 فاز دوم: Validate & Process (اعتبارسنجی داده)پیشنیاز:فایل باید سالم دریافت، decrypt و decompress شده باشد.در این مرحله:دادهها بررسی میشوندرکوردهای معیوب شناسایی میشونددادههای معتبر وارد سیستم میشوندنکتهٔ مهم اینجاست:مدیریت خطا فقط در صورت بروز مشکل فعال میشوددر حالت ایدهآل، ImportErrorHandler اصلاً فراخوانی نمیشود.اما اگر خطایی رخ دهد:خطاهای بحرانی → توقف پردازشخطاهای سطح رکورد → ثبت، گزارش و ادامهٔ کاراین طراحی باعث میشود MaMa بتواند با دادههای «واقعیِ دنیای واقعی» کنار بیاید.III.7 نمای استقرار (Deployment View)«MaMa کجا و چگونه اجرا میشود؟»7.1 نمای کلی استقراراز همان ابتدای طراحی، یک اصل غیرقابل مذاکره وجود داشت:هر کمپین MaMa باید روی یک ماشین مجازی اختصاصی اجرا شود.دلایل این تصمیم:جداسازی کامل دادهٔ Mandatorهاافزایش امنیتسادهسازی ممیزی و حذف دادههاپیکربندی سیستمعامل، VM و Host تأثیر مستقیمی روی امنیت کمپین دارد و باید بهطور منظم بررسی شود.به دلیل حساسیت دادهها، جزئیات امنیتی در این مستند عمداً افشا نشدهاند.7.2 ماشین مجازی اختصاصی برای هر کمپینبرای هر کمپین:یک VM مجزا وجود داردیک دیتابیس اختصاصیکل کد MaMa (بهجز UI پیکربندی)هیچ اشتراکی در سطح داده یا پردازش وجود ندارد.این طراحی هزینه را بالا میبرد، اما امنیت و شفافیت را تضمین میکند.7.3 مخزن متادیتای مشترک (Common Metadata Store – CoMeS)در پروژهٔ کارت سلامت آلمان، یک چالش خاص وجود داشت:تولید Common Insurance ID (CID).CID فقط میتوانست توسط یک نهاد دولتی تولید شود و هر درخواست باید شامل:شناسه سازمان درخواستکنندههدف درخواستیک شماره ترتیبی بدون هیچ وقفه (RSN)مشکل کجا بود؟MaMa روی چندین VM مستقل اجرا میشد،اما RSN باید کاملاً پیوسته و هماهنگ میبود.راهحل معماری:ساخت یک Common Metadata Store اختصاصیبدون استفاده از دیتابیس عمومیبا تمرکز بر همگامسازی امن و قابل اعتماداین یک مثال عالی از تصمیم معماری کاملاً زمینهمحور است.7.4 ماشین پیکربندی کمپینپس از استقرار VMها، اپراتورها نیاز دارند کمپین را پیکربندی کنند.این کار از طریق:یک یا چند Workstation استانداردبا UI مبتنی بر Eclipse RCP Pluginانجام میشود.این UI امکان:تعریف کمپینتنظیم ورودی/خروجیقوانینفعالیتهارا بدون دست زدن به Backend فراهم میکند.III.8 مفاهیم سرتاسری (Cross-Cutting Concepts)«تصمیمهایی که در تمام MaMa حضور دارند»مفاهیم سرتاسری در arc42 به آن دسته از ایدهها و الگوهایی گفته میشود که:فقط به یک ماژول خاص محدود نیستنددر چندین بخش از سیستم تکرار میشوندو بهشدت روی معماری، توسعه و نگهداری سیستم اثر میگذارنددر MaMa-CRM، این مفاهیم ستون فقرات معماری را تشکیل میدهند. مهمترین آنها عبارتاند از:persistence تولیدشده از مدل دامنهDSL برای فرمت دادهفیلترهای قابل پیکربندیموتور قوانین برای کنترل فرآیند8.1 Persistence تولیدشده بر اساس مدل دامنه (Generated Persistence)یکی از جسورانهترین و در عین حال هوشمندانهترین تصمیمات معماری MaMa این است که:تمام کد مربوط به persistence (ذخیرهسازی داده) بهصورت خودکار از روی مدل UML تولید میشود.یعنی:هیچ جدول دیتابیسی بهصورت دستی نوشته نمیشودهیچ entity یا repository بهصورت دستی ساخته نمیشودهمهچیز از مدل دامنه استخراج میشوداین رویکرد باعث میشود انعطافپذیری MaMa در سطح داده به حداکثر برسد.چرا این کار منطقی بود؟ (پیشفرضهای معماری)این تصمیم بر اساس چند واقعیت دامنهای گرفته شد:هر MaMa instance با دادهٔ اشخاص حقیقی (Client) سروکار داردهمهٔ Clientها تعدادی ویژگی مشترک دارندهر Mandator ویژگیهای اختصاصی خودش را اضافه میکندبعضی کمپینها انواع دادهٔ کاملاً جدید دارند (مثل قرارداد بیمه یا قرارداد موبایل)ساختار داده پس از شروع کمپین تقریباً هرگز تغییر نمیکندنکتهٔ جالب:در چند سال کار عملی MaMa، هیچوقت نیاز به migration دیتابیس در یک کمپین فعال پیش نیامد.8.1.1 مدل دامنهٔ عمومی (MaMa Core Domain)در قلب MaMa یک مدل دامنهٔ عمومی وجود دارد که همهٔ کمپینها از آن استفاده میکنند.این مدل شامل مفاهیم پایهای است، از جمله:Client: یک کلاس انتزاعی که نمایندهٔ یک شخص و اطلاعات تماس اوستContact: اطلاعات ارتباطی که در طول کمپین استفاده میشودNext Action: نمایشدهندهٔ فعالیت بعدی در جریان کمپیناین مدل «هستهٔ مشترک» همهٔ کمپینهاست.8.1.2 مدل دامنهٔ اختصاصی کمپینهر کمپین، علاوه بر Core Domain، یک کپی فیزیکی از آن را به همراه توسعههای اختصاصی خودش دارد.در این مدلها:Client همیشه subclass میشودروابط جدید اضافه میشوندموجودیتهای اختصاصی دامنه (مثلاً InsuranceContract یا MobileContract) تعریف میشونداین یعنی هر کمپین:مدل دادهٔ خودش را دارد، اما روی یک هستهٔ مشترک سوار شده است.8.1.3 جزئیات Code Generatorبرای تولید persistence، MaMa از ابزارهای زیر استفاده میکند:OpenArchitectureWare (OAW) برای تولید کدHibernate برای ORM و persistenceکد تولیدشده شامل موارد زیر است:DDL کامل دیتابیس (schema، جدولها، indexها)فایلهای mapping هابرنیتمتدهای campaign-specific برای جستوجو و پردازشمتدهای گزارشگیری و مانیتورینگمحدودیتها:ارتباطهای m:n پشتیبانی نمیشوندتغییر ساختار داده در کمپین فعال مجاز نیستبه دلیل قراردادهای عدم افشا، نمونه کد قابل انتشار نیست.چرا این ابزار انتخاب شد؟ (Alternative Analysis)MaMa ابتدا از AndroMDA استفاده میکرد، اما پروژه عملاً متوقف شدMagicDraw امکان تولید کد داشت، اما برای Hibernate بیش از حد محدود بوددر نهایت OAW بهترین توازن بین انعطافپذیری و کنترل را فراهم کرد8.2 Import / Export CSV (نگاه کلی)در MaMa، CSV فقط یک فرمت ساده نیست؛بلکه بخشی از یک زبان دامنهمحور (DSL) است که تعریف میکند:فیلدها چه هستندترتیبشان چیستچگونه اعتبارسنجی میشوندو چطور به مدل دامنه نگاشت میشوندبرای این DSL:Parser اختصاصی نوشته شدهEditor سفارشی در Eclipse ساخته شده(جزئیات کاملتر در نسخهٔ اصلی کتاب آمده است.)8.3 فیلترهای فایل قابل پیکربندی (Configurable File Filters)هر فایلی که از بیرون وارد MaMa میشود، باید از یک زنجیرهٔ فیلتر عبور کند.این دقیقاً همان چیزی است که در Runtime View دیدیم.دو نوع فیلتر اصلی وجود دارد:۱) فیلترهای رمزنگاری (Encryption Filters)سازگار با Java Cryptography Architectureقابل استفاده با Providerهایی مثل BouncyCastleنیازمند کلید، certificate یا credentialبه دلیل حساسیت دادهها، جزئیات پیادهسازی امنیت منتشر نشده است.۲) فیلترهای فشردهسازی (Compression Filters)فقط الگوریتمهای بدون اتلاف (Lossless)مثل DEFLATE (zip / gzip) یا Lempel-Zivبدون پارامتر پیچیدهاین فیلترها بهصورت زنجیرهای و پویا پیکربندی میشوند.8.4 موتور قوانین برای کنترل فرآیند (Rule Engine)یکی از تفاوتهای اساسی MaMa با CRMهای سنتی، استفاده از Rule Engine واقعی است.8.4.1 جریان اقدام (Flow of Action)رفتار کمپینها با قوانین تعریف میشود، نه با if/elseهای سختکد شده.این یعنی:تغییر رفتار بدون redeployامکان تنظیم سریع کمپینجداسازی منطق کسبوکار از کد8.4.2 Drools بهعنوان Rule EngineMaMa از Drools (متنباز) برای تعریف و اجرای قوانین استفاده میکند.ویژگیهای کلیدی:قوانین بهصورت فایل متنی تعریف میشونددر زمان اجرا تفسیر میشوندبدون نیاز به کامپایل کل سیستمقالب قوانین بسیار ساده است:when then که در آن A و B عبارات جاوایی هستند.⚠️ نکتهٔ مهم معماری:قوانین اشتباه میتوانند یک کمپین فعال را مختل کنند؛به همین دلیل تست قوانین قبل از اجرا الزامی است.III.9 تصمیمات معماری (Architecture Decisions)«چند تصمیم کلیدی که سرنوشت MaMa را ساخت»هر سیستم بزرگ، چند تصمیم دارد که اگر اشتباه گرفته شوند، کل محصول را زمین میزنند.در MaMa-CRM هم چند تصمیم خیلی تعیینکننده وجود داشت؛ تصمیمهایی که مستقیماً از نیازهای کیفیتی سیستم (خصوصاً انعطافپذیری و کارایی) آمدهاند.۱) استفاده نکردن از ابزارهای CRM تجاریتیم MaMa از همان ابتدا تصمیم گرفت هیچ CRM تجاری آمادهای را بهعنوان پایهٔ سیستم انتخاب نکند.دلیلش ساده ولی حیاتی بود:سطح انعطافپذیری موردنیاز برای راهاندازی سریع کمپینها، با معماری CRMهای آماده سازگار نبود.این تصمیم بعداً ثابت کرد درست بوده؛ چون رقبای اولیهای که سعی کردند با «کمی دستکاری» روی CRMهای استاندارد وارد این بازار شوند، عملاً شکست خوردند و نتوانستند وارد فضای عملیاتی شوند که MaMa در آن کار میکرد.۲) انتخاب JBoss Drools برای پردازش قوانینMaMa برای کنترل منطق کمپینها و تصمیمگیریهای فرآیندی، به یک Rule Engine واقعی نیاز داشت. انتخاب نهایی:JBoss Droolsتیم گزینهٔ دیگری مثل Python/Jython را هم بررسی کرد، اما نتیجه واضح بود:برای نوع پردازش MaMa، Jython بیش از حد کند بودDrools هم سریعتر بود و هم برای مدل «قوانین قابل تغییر در زمان اجرا» مناسبتراین تصمیم کاملاً با نیاز انعطافپذیری و تغییر سریع قوانین کمپین همراستا بود.۳) عدم استفاده از ابزار ETL برای Import دادهخیلیها در چنین سیستمهایی سراغ ETL میروند؛ اما MaMa این کار را نکرد.علت اصلی، فنی نبود؛ اقتصادی و سازمانی بود:شرکت InDAC حاضر نشد هزینهٔ لایسنس ابزارهای ETL تجاری را بپذیرد،پس تیم حتی فرصت ارزیابی جدی آنها را هم نداشت.در نتیجه Import/Export در MaMa بهصورت داخلی و با DSL و pipelineهای قابل پیکربندی ساخته شد—که البته در نهایت به انعطافپذیری بالاتری هم منجر شد، ولی با هزینهٔ پیچیدگی توسعه.III.10 نیازمندیهای کیفی (Quality Requirements)«کیفیت یعنی چیزی که قابل اندازهگیری باشد»MaMa فقط نمیگوید “سیستم باید منعطف باشد”.این سیستم کیفیت را به سناریوهای عملیاتی تبدیل کرده؛ یعنی چیزی که بتوان با آن تست کرد، سنجید و الزام ایجاد کرد.سناریوهای انعطافپذیری (Flexibility Scenarios)هدف اصلی این سناریوها این است که MaMa بتواند بدون برنامهنویسی و در زمان کوتاه، فرمتها را تغییر دهد یا فرمت جدید اضافه کند.در MaMa معیار مشخص است:هر فرمت جدید باید در زمان پیکربندی کمپین (CCT) و حداکثر ظرف ۲ ساعت قابل راهاندازی باشد.این الزام برای همهٔ حالتها تعریف شده است:اضافه کردن فرمت جدید برای Import از نوع CSVاضافه کردن فرمت جدید برای Import از نوع Fixed-Fieldاضافه کردن فرمت جدید برای Import از نوع XMLاضافه کردن فرمت جدید برای Export از نوع CSVاضافه کردن فرمت جدید برای Export از نوع Fixed-Fieldاضافه کردن فرمت جدید برای Export از نوع XMLو یک شرط جدی هم دارد:مستند فرمت باید وجود داشته باشدحداقل ۱۰ رکورد دادهٔ تست متنوع باید ارائه شوداین یعنی انعطافپذیری «شعاری» نیست؛ یک قرارداد عملیاتی دقیق است.سناریوهای کارایی زمان اجرا (Runtime Performance Scenarios)MaMa باید در مقیاس واقعی کار کند. دو الزام اصلی عملکرد:پردازش کامل ۲۵۰٬۰۰۰ سند اسکنشده در ۲۴ ساعتاین شامل:CSVو تصاویر به صورت فایلهای جدااست.اگر بخواهیم به زبان ساده تبدیلش کنیم:یعنی سیستم باید به طور متوسط حدود ۳ سند کامل در ثانیه را از ابتدا تا انتها پردازش کند.پردازش کامل ۱۰۰٬۰۰۰ رکورد CSV در کمتر از ۳۰ دقیقهاین یعنی تیم معماری از ابتدا پذیرفته که “کمپینها حجیماند” و سیستم باید روی throughput طراحی شود.سناریوهای امنیت (Security Scenarios)سه الزام امنیتی کلیدی:جداسازی کامل دادهها بین Mandatorهاهیچ دادهای از یک Mandator نباید برای Mandator دیگر قابل دسترس باشد. این همان دلیل VM و DB جداگانه برای هر کمپین است.قابلیت ممیزی سریع دادههای آرشیویMaMa موظف است تمام دادههای ورودی (فایلها/پیامها) را برای بازهٔ زمانی مشخص (معمولاً ۹۰ تا ۱۸۰ روز پس از پایان کمپین) نگه دارد.و اگر ممیز بخواهد، سیستم باید:حداکثر ظرف ۹۰ دقیقه همهٔ دادههای آرشیو را قابل دسترسی کند.انطباق با PCI-DSS در صورت وجود دادهٔ مالیاگر کمپینی اطلاعات بانکی/کارت اعتباری داشته باشد، پردازش و نگهداری باید مطابق PCI-DSS انجام شود.III.11 ریسکها (Risks)«چیزهایی که اگر اصلاح نشوند، دیر یا زود ضربه میزنند»این بخش از آن قسمتهایی است که تیم معماری واقعاً شفاف حرف زده—و این دقیقاً همان چیزی است که arc42 دوست دارد: واقعیت، نه تبلیغ.۱) Receiver یک نقطهٔ درد مزمن استکامپوننت Receiver به دلیل اینکه در طول زمان توسط چند توسعهدهنده و بدون هماهنگی رشد کرده، بیش از حد پیچیده و درهم شده است.نتیجه عملی:از همان روزهای اول، بیشتر باگهای پروداکشن از همین بخش آمدهاند.این یعنی Receiver از نظر معماری «نیاز به بازطراحی یا refactor سنگین» دارد.۲) انعطافپذیری زیاد، ریسک رفتار اشتباهاین سیستم عمداً runtime-configurable است. ولی یک مشکل بزرگ دارد:هیچ بررسی/اعتبارسنجی جدی برای پیکربندیها وجود نداردپس ممکن است:سیستم اشتباه کار کندو این اشتباه حتی دیر تشخیص داده شودبدتر از آن:یک ادمین بدخواه میتواند هر لحظه سیستم را misconfigure کند.۳) پیکربندیها آرشیو نمیشوندیکی از خطرناکترین ریسکها:تنظیمات کمپینها نسخهبندی و آرشیو نمیشوندممکن است تنظیمات درست گم شوندو هیچ راه برگشتی به “آخرین پیکربندی سالم” وجود نداشته باشدبرای سیستمی که همه چیزش configuration است، این یک ضعف جدی است.۴) Common Metadata Store ناکارآمد استCoMeS یک راهحل ساده و سریع برای همگامسازی RSN بود، ولی مشکلاتش واضح است:ساده و ابتدایی استمنابع را هدر میدهدو باید سریعاً با یک سیستم درستتر جایگزین شودپیشنهاد خود متن هم روشن است:بهتر است با یک مکانیزم async / event-based جایگزین شود.سخن پایانیبا رشد سیستمهای سازمانی پیچیده، برونسپاری فرآیندها، کمپینهای دادهمحور و معماریهای منعطف مبتنی بر پیکربندی، داشتن یک مستند معماری شفاف و استاندارد دیگر یک گزینهٔ لوکس نیست؛ یک ضرورت عملیاتی است. نمونهای مثل MaMa-CRM نشان میدهد که arc42 فقط برای سیستمهای آموزشی یا کوچک نیست، بلکه میتواند ستون فقرات مستندسازی معماری سامانههای بزرگ، حساس و چندسازمانی باشد—از CRMهای مبتنی بر کمپین گرفته تا پلتفرمهای دادهمحور در مقیاس ملی.arc42 کمک میکند تصمیمات معماری، نیازمندیهای کیفی، محدودیتها، ریسکها و منطق طراحی سیستم بهصورت ساختیافته، قابل فهم و قابل انتقال مستند شوند؛ بهگونهای که هم تیم فنی، هم ذینفعان غیر فنی و هم تیمهای آینده بتوانند به یک درک مشترک برسند. همین شفافیت است که نگهداری، توسعه و تکامل سیستم را در بلندمدت ممکن میکند.اگر در پروژههای خود با چالشهایی مثل پیچیدگی معماری، نبود مستند قابل اتکا، یا نیاز به استانداردسازی طراحی سیستم مواجه هستید، تیم معماری و توسعهی نرمافزار شرکت راهکار نگار هوشمند (آرکان) میتواند از تحلیل معماری موجود تا تدوین مستند arc42 و همراهی در پیادهسازی عملی، کنار شما باشد.این مقاله با هدف آگاهیبخشی و انتقال تجربهی معماری، توسط تیم توسعهی نرمافزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#معماری_نرمافزار#arc42#مستندسازی_معماری#CRM#enterprise_architecture#تحلیل_سامانه#طراحی_سیستم#معماری_فنی#Software_Architecture#architecture_documentation#distributed_systems#quality_attributes#technical_writing#شرکت_راهکار_نگار_هوشمند#arcanco

تحلیل و مستندسازی معماری ابزار HSC بر اساس arc42

محمد حسین جلیلی — Mon, 08 Dec 2025 22:27:43 +0330
در ادامه‌ی مسیرمان برای یادگیری و تمرین عملی الگوی مستندسازی arc42، حالا زمان آن رسیده که از یک سیستم واقعی کمک بگیریم؛ سیستمی که به اندازه‌ی کافی کوچک باشد تا بتوانیم تمام بخش‌های معماری‌اش را تحلیل کنیم، اما به‌قدری کاربردی باشد که مثال‌ها و تصمیم‌های معماری‌ آن واقعی و قابل لمس باشند.در میان مثال‌های موجود، ابزار HTML Sanity Check (HSC) یکی از بهترین گزینه‌هاست.HSC یک ابزار متن‌باز کوچک است که روی فایل‌های HTML «سلامت‌سنجی» انجام می‌دهد—یعنی لینک‌های خراب، تصاویر گم‌شده، منابع محلی وجود‌نداشته، alt-tagهای ناقص و ده‌ها اشکال رایج دیگر را شناسایی می‌کند.این ابزار معمولاً زمانی استفاده می‌شود که صفحات HTML از ابزارهایی مانند Asciidoctor یا Markdown تولید می‌شوند؛ جایی که تبدیل‌کننده‌ها مسئولیت بررسی کیفیت خروجی را برعهده نمی‌گیرند و این خطاها معمولاً تا زمان انتشار پنهان می‌مانند.اما دلیل ما برای انتخاب این ابزار فقط کارکردش نیست.HSC در کتاب "arc42 by Example" به‌عنوان یک نمونه‌ی رسمی برای مستندسازی معماری استفاده شده است.این یعنی ساختار، تصمیم‌های فنی، زیرسیستم‌ها، آداپتورها، کیفیت‌ها و ریسک‌هایش به‌خوبی قابل تحلیل و تبدیل به یک سند arc42 هستند.در این مقاله، ابتدا این سیستم را معرفی می‌کنیم تا مشخص شود HSC دقیقاً چه می‌کند، از چه بخش‌هایی تشکیل شده، و چه نوع چک‌هایی انجام می‌دهد. پس از آن، در بخش‌های بعدی وارد دنیای arc42 می‌شویم و گام‌به‌گام سند معماری این ابزار را مطابق با سرفصل‌های arc42 بازسازی و تحلیل می‌کنیم.اگر قصد داری معماری نرم‌افزار را به‌صورت حرفه‌ای یاد بگیری یا می‌خواهی بفهمی مستندات arc42 در عمل چه شکلی دارند، HSC بهترین نقطه‌ی شروع است.II.1 مقدمه و اهداف سیستم (HTML Sanity Check – HSC)در این بخش از مستند arc42، معمولاً توضیح داده می‌شود که چرا این سیستم ساخته شده و چه نیازهایی آن را شکل می‌دهند. هدف اصلی این قسمت، این است که ذینفعان بتوانند قبل از ورود به جزئیات فنی معماری، تصویر روشنی از مسئله، هدف و ارزش سیستم به‌دست آورند.برای مثال HTML Sanity Check (HSC)، این بخش نقش مهم‌تری دارد؛ چون HSC یک ابزار کوچک اما چندمنظوره است که در سناریوهای متفاوتی (CLI، Gradle، Maven، کتابخانه) استفاده می‌شود و لازم است پیش از بررسی معماری‌اش بفهمیم قرار است چه مسئله‌ای را حل کند.محتوا و انگیزه ساخت سیستمنقطه‌ی آغاز HSC، چالش رایجی است که نویسندگان و مستندسازان دیجیتال با آن مواجه می‌شوند:وقتی خروجی HTML از ابزارهایی مثل Asciidoctor یا Markdown تولید می‌شود، اغلب هیچ تضمینی درباره‌ی صحت و کیفیت لینک‌ها، تصاویر، IDها و منابع وجود ندارد.بنابراین HSC با هدف اصلی زیر طراحی شد:پشتیبانی از نویسندگان محتوا با بررسی خودکار لینک‌ها، تصاویر و منابع داخل فایل‌های HTML و تولید گزارش شفاف از خطاهای موجود.این ابزار یک sanity checker است؛ یعنی کاری می‌کند که HTML تولید شده از نظر معنا و ساختار (Semantic Integrity) بررسی شود، نه فقط از نظر شکل ظاهری.۱.۱ نمای کلی نیازمندی‌هاپیش از ورود به معماری، لازم است فهم دقیقی از کارکردهای اصلی سیستم داشته باشیم.این بخش به خواننده کمک می‌کند «وظیفه اصلی HSC چیست» را بفهمد.هدف کلیدی سیستمتولید گزارش‌های دقیق، تمیز و قابل‌فهم از خطاهای HTML.این گزارش‌ها می‌توانند مشابه گزارش‌های تست واحد (unit test reports) باشند و شامل:لینک‌های شکستهتصاویر گم‌شدهمنابع محلی ناپیداتکرار IDهالینک‌های خارجی خرابمشکلات syntax و ساختاربرای مثال، نویسندگان معمولاً این مسیر را طی می‌کنند:نوشتن متن در AsciiDoc یا Markdownدریافت HTML نهایی توسط ابزارهای تبدیلاستفاده از HSC برای بررسی خروجی HTMLدریافت گزارش مشکلاتsemanticاین جریان، فلسفه‌ی وجودی HSC را تعریف می‌کند.سناریوهای پایه‌ی استفادهبرای درک بهتر سیستم، رفتار HSC را در ابتدایی‌ترین حالت مرور کنیم:کاربر مسیر چند فایل HTML یا پوشه مربوطه را تنظیم می‌کند.ابزار مجموعه‌ای از چک‌ها را روی فایل‌ها اجرا می‌کند.نتیجه را یا در کنسول نمایش می‌دهد یا یک گزارش HTML تولید می‌کند.HSC می‌تواند از طریق CLI یا Gradle اجرا شود، و این تنوع در روش استفاده، بعدها روی ساختار معماری سیستم نیز تأثیر می‌گذارد.نیازمندی‌های اصلی سیستم (Goals)برای اینکه بتوانیم معماری HSC را درست تحلیل کنیم، باید ابتدا اهداف و نیازمندی‌های اصلی سیستم را بشناسیم. این نیازمندی‌ها مشخص می‌کنند که HSC در اصل برای انجام چه کارهایی طراحی شده و معماری آن باید چه قابلیت‌هایی را پشتیبانی کند.۱) بررسی خطاهای معنایی HTMLهسته‌ی اصلی HSC این است که فایل‌های HTML را از نظر semantic integrity بررسی کند؛ یعنی بتواند مشکلاتی مثل لینک‌های داخلی شکسته، تصاویر گم‌شده یا منابع ناپیدا را شناسایی کند.۲) قابل اجرا بودن به‌عنوان پلاگین Gradle و MavenHSC باید قابلیت یکپارچه‌سازی در فرآیند ساخت پروژه را داشته باشد. بنابراین لازم است به‌عنوان پلاگین Gradle و پلاگین Maven قابل اجرا باشد تا تیم‌های مختلف بتوانند آن را در ساختار CI/CD خود قرار دهند.۳) پشتیبانی از چندین فایل ورودی در یک اجراکاربر باید بتواند به‌جای یک فایل HTML، مجموعه‌ای از فایل‌ها یا یک پوشه کامل را به ابزار بدهد. HSC باید همه آن‌ها را در یک مرحله پردازش و یک گزارش واحد و تجمیع‌شده تولید کند.۴) ارائه پیشنهاد برای رفع خطاهاوقتی HSC خطایی را پیدا می‌کند، فقط گزارش آن کافی نیست؛ باید بتواند پیشنهاد یا سرنخی برای رفع خطا ارائه دهد. مثلاً اگر لینک شکسته است، مقادیر مشابه یا اشتباه تایپی ممکن را پیشنهاد کند.۵) پیکربندی‌پذیری بالارفتار سیستم باید قابل تنظیم باشد.کاربر باید بتواند:مسیر فایل‌هامسیر خروجی گزارشtimeout چک لینک‌هانحوه برخورد با status codeهای لینک‌های بیرونیرا تغییر دهد.چک‌های مورد نیاز (Functional Requirements – Checks)HSC باید مجموعه‌ای از sanity checks زیر را فراهم کند:چک ✔ Missing Imagesآیا فایل تصویری که در img src آمده واقعاً وجود دارد؟چک ✔ Broken Internal Linksآیا href="#XYZ" واقعاً به یک id تعریف‌شده اشاره می‌کند؟چک ✔ Missing Local Resourcesمانند css، js، pdf و سایر منابعی که لینک شده‌اند اما وجود ندارند.چک ✔ Duplicate IDsآیا یک id دوبار تعریف شده؟چک ✔ Malformed Linksاشکالات syntax در href یا ساختار لینک‌ها.چک ✔ Illegal Link Targetsاهداف لینک ناسازگار یا نادرست.چک ✔ Broken External Linksبررسی status code لینک‌های HTTP.چک ✔ Broken ImageMapsبررسی ابتدایی صحت ImageMap.این چک‌ها بخش عمده‌ی دامنه عملکردی سیستم را تشکیل می‌دهند و بعداً در Building Block View تبدیل به ماژول‌ها و CheckerClassهای جداگانه خواهند شد.۱.۲ اهداف کیفی (Quality Goals)برای اینکه معماری HSC بتواند نیازهای واقعی کاربران را پوشش دهد، باید بدانیم این سیستم در بلندمدت به چه کیفیت‌هایی متعهد است. این اهداف کیفی، تصمیمات معماری را شکل می‌دهند و مشخص می‌کنند سیستم چه چیزی را باید همیشه تضمین کند.در HSC، کیفیت‌ها در سه محور اصلی خلاصه می‌شوند:۱) صحت (Correctness)مهم‌ترین هدف کیفیتی HSC، درست‌بودن نتایج است.سیستم باید:هر لینک داخلی شکسته را پیدا کند.هرگونه خطای معنایی احتمالی را گزارش دهد حتی در موارد مشکوک یا مبهم.به‌عبارتی، HSC باید «وسواسی» عمل کند؛ اگر در صحت لینک تردید دارد، باید گزارش دهد و تصمیم نهایی را به کاربر بسپارد.۲) ایمنی (Safety)یک اصل غیرقابل‌مذاکره:HSC هرگز نباید محتوای فایل‌های HTML را تغییر دهد.کارش فقط تحلیل است، نه بازنویسی، اصلاح یا اعمال تغییرات.۳) انعطاف‌پذیری (Flexibility)HSC باید بتواند:چندین الگوریتم بررسی مختلف را پشتیبانی کند،فرمت‌های متنوع گزارش تولید نماید،و در کلاینت‌های مختلف اجرا شود: Gradle، CLI و غیره.این انعطاف‌پذیری جزو اهداف کیفیتی سطح دوم است، اما برای معماری اهمیت عملی دارد.۴) تست‌پذیری و صحت درونی سیستمهر چکر (checker) باید هم برای موارد مثبت و هم موارد منفی تست شود.این موضوع کیفیت «درونی» سیستم را تضمین می‌کند و اجرای خودکار تست‌ها بخشی از معماری سیستم است.۵) کارایی (Performance)چک کردن یک فایل HTML حدود ۱۰۰ کیلوبایت باید زیر ۱۰ ثانیه انجام شود—البته بدون احتساب زمان راه‌اندازی Gradle.این هدف نشان می‌دهد کارایی مهم است، اما بعد از صحت و ایمنی قرار می‌گیرد.۱.۳ ذینفعان (Stakeholders)HSC یک سیستم کوچک است و ذینفعان محدودی دارد؛ اما همین تعداد کم نیز خواسته‌های متفاوتی دارند که در معماری اثر می‌گذارد.نویسندگان مستنداتکسانی که محتوا را با ابزارهای تولید HTML (مثل Asciidoctor) ایجاد می‌کنند.هدف‌شان این است که مطمئن شوند لینک‌ها، تصاویر و منابع HTML درست کار می‌کنند.کاربران arc42افرادی که می‌خواهند یک نمونهٔ ساده و واقعی از مستندسازی معماری مشاهده کنند.HSC برای این گروه نقش یک مثال آموزشی را دارد.توسعه‌دهندگان نرم‌افزارکسانی که می‌خواهند:کیفیت لینک‌ها و تصاویر داخل مستندات را بررسی کنند،HSC را در خط build خود ادغام کنند،و یک مثال عملی از معماری کوچک اما تمیز ببینند.این سه گروه، خواسته‌های معماری سیستم را تعریف می‌کنند.II.2 محدودیت‌ها (Constraints)در طراحی HSC، مجموعه‌ای از محدودیت‌ها وجود دارد که آزادی عمل معماری را تعیین می‌کنند و تصمیم‌ها را شکل می‌دهند.۱) باید روی پلتفرم‌های مختلف اجرا شودHSC باید مستقل از پلتفرم باشد و روی Windows، Linux و MacOS قابل اجرا باشد.۲) پیاده‌سازی مبتنی بر JVMزبان پیاده‌سازی باید Java یا Groovy باشد.این موضوع انتخاب runtime و سازگاری ابزار را مشخص می‌کند.۳) ادغام با Gradleسیستم باید به‌صورت پلاگین Gradle قابل استفاده باشد.این محدودیت تأثیر مستقیم بر ساختار پروژه و نحوهٔ بسته‌بندی ماژول‌ها دارد.۴) قابلیت اجرا از خط فرمانCLI باید مستقل از ابزار ساخت باشد؛ یعنی کاربر بتواند تنها با نصب ابزار، آن را اجرا کند.۵) حداقل وابستگی‌هاHSC باید سبک باشد. فقط به یک Java Runtime نیاز دارد و نباید کتابخانه‌های سنگین یا پیچیده داشته باشد.۶) لایسنس متن‌باز و سازگارکد باید تحت Apache-2.0 منتشر شود و دیگر کتابخانه‌های استفاده‌شده باید با Creative Commons سازگار باشند.این محدودیت‌ها مسیر طراحی را مشخص می‌کنند و در بخش‌های بعدی معماری منعکس خواهند شد.II.3 محدوده و کانتکست سیستم (System Scope & Context)۳.۱ کانتکست کسب‌وکاری (Business Context)برای فهم محدوده سیستم، باید بدانیم HSC با چه موجودیت‌هایی در محیط خود تعامل دارد.Business contextکاربر (User)کسی که مستندات می‌نویسد یا خروجی HTML تولید می‌کند.هدف او این است که مطمئن شود فایل HTML خروجی سالم، بدون لینک شکسته و بدون تصویر گم‌شده باشد.سیستم Build (اغلب Gradle)HSC معمولاً بخشی از pipeline تولید مستندات است.در این نقش:Gradle HSC را اجرا می‌کند،HSC HTMLها را بررسی،و گزارش تولید می‌کند.فایل‌های HTML محلیورودی اصلی سیستم هستند.HSC این فایل‌ها را parse و بررسی می‌کند.تصاویر و فایل‌های محلیسیستم باید بررسی کند که فایل‌هایی که HTML به آن‌ها لینک داده، واقعاً وجود داشته باشند.منابع خارجی (external web resources)کاربر می‌تواند بخواهد لینک‌های بیرونی نیز چک شوند.اما این بخش:کندتر است،ممکن است به دلیل مشکلات شبکه نتایج نادرست بدهد.بنابراین یک سناریوی اختیاری است که محدودیت‌های خاص خود را دارد.II.4 استراتژی راه‌حل (Solution Strategy)برای اینکه معماری HTML Sanity Check (HSC) بتواند اهداف کیفی تعریف‌شده—مثل صحت، ایمنی، انعطاف‌پذیری و کارایی—را پاسخ دهد، مجموعه‌ای از تصمیم‌ها و راهبردهای بنیادی در طراحی این سیستم اتخاذ شده است. این بخش خلاصه‌ای از ایده‌های کلیدی پشت معماری HSC را بیان می‌کند؛ ایده‌هایی که همهٔ افراد درگیر در توسعه، تست و نگهداری سیستم باید با آن‌ها آشنا باشند.۱) انتخاب Groovy و Java با کمترین وابستگی خارجیهستهٔ اصلی HSC عمدتاً با Groovy و بخشی از آن با Java پیاده‌سازی شده است.این انتخاب چند دلیل معماری مهم دارد:نیاز به حداقل وابستگی‌ها برای اجرای سریع و سبکامکان سازگاری کامل با JVM و ابزارهای مرتبطقابلیت نوشتن چکرها و منطق تحلیل HTML به‌صورت ساده، مختصر و خوانااین تصمیم مستقیماً کیفیت‌های ایمنی، قابلیت نگهداری و کارایی را تقویت می‌کند.۲) تبدیل سیستم به یک پلاگین Gradle برای اجرای خودکاربرای اینکه HSC بتواند بخشی طبیعی از فرآیند ساخت (build pipeline) باشد، پیاده‌سازی آن در قالب یک Gradle Plugin انجام شده است.نتیجهٔ این تصمیم:امکان استفادهٔ خودکار در CI/CDسازگاری با تیم‌هایی که اسنادشان را با Asciidoctor و Gradle تولید می‌کننداجرای کاملاً بدون دخالت انسانپلاگین Maven نیز در حال توسعه است تا این سناریو در محیط‌های گسترده‌تر هم برقرار شود.این استراتژی پاسخ مستقیمی به نیاز انعطاف‌پذیری و سهولت ادغام است.۳) استفاده از Template Method Pattern برای پشتیبانی از چندین الگوریتم بررسیبرای اینکه HSC بتواند:چکرهای مختلف داشته باشد،خروجی‌ها را در چند قالب تولید کند (مثل HTML و Console)،و قابلیت گسترش‌پذیری داشته باشد،در طراحی آن از الگوی Template Method استفاده شده است.این الگو باعث می‌شود:ساختار کلی الگوریتم ثابت بماند،اما بخش‌های قابل تغییر (مثل نوع چک یا نوع گزارش) قابل جایگزینی باشند،افزودن چکرهای جدید بدون دست‌زدن به ساختار کلی سیستم انجام شود.این انتخاب معماری، کیفیت‌های درست‌کارکردن، انعطاف‌پذیری و قابلیت توسعه را تضمین می‌کند.۴) اتکا به conventions استاندارد Gradle و Groovy برای تنظیماتHSC یک فایل پیکربندی ساده دارد که مطابق conventions این اکوسیستم است.این یعنی:کاربر بدون نیاز به تنظیمات پیچیده می‌تواند ابزار را اجرا کندرفتار سیستم به‌روشنی قابل انتظا‌رش استخروجی‌ها، ورودی‌ها و مسیرها استاندارد و قابل پیش‌بینی‌انداین تصمیم کیفیت استفاده‌پذیری و سادگی نگهداری را تقویت می‌کند.البته، همین وابستگی به conventions ممکن است برای نسخهٔ Maven Plugin چالش‌هایی ایجاد کند، زیرا ساختار Maven با Gradle متفاوت است.II.۵ نمای بلوک‌های سازنده یا Building Block Viewدر نمای سازه‌ای (Building Block View)، معماری سیستم از نگاه ایستا بررسی می‌شود:سیستم از چه بخش‌هایی ساخته شده است؟ این بخش‌ها چگونه سازمان‌دهی شده‌اند؟ و هر بخش چه مسئولیتی دارد؟در HSC، این ساختار به شکل عملکردهای تجزیه شده (Functional Decomposition) طراحی شده است: هستهٔ سیستم تمام منطق بررسی HTML را انجام می‌دهد، و بخش‌های دیگر فقط روش‌های مختلف استفاده از این هسته را فراهم می‌کنند.این بخش در سه سطح توضیح داده می‌شود:Level 1: ساختار کلی سیستم (Whitebox HtmlSC)Level 2: اجزای داخلی هستهٔ سیستم (HSC Core)Level 3: اجزای داخلی مدیریت نتایج (Results Collector)بیایید قدم‌به‌قدم جلو برویم.5.1 ساختار سطح ۱ – HtmlSanityChecker (Whitebox)در بالاترین سطح، HSC از چند بلوک اصلی تشکیل شده است.در این سطح هدف این است که «نقش‌های کلیدی سیستم» را مشخص کنیم، نه جزئیات پیاده‌سازی را.چرا این ساختار؟به‌جای اینکه همهٔ وظایف در یک پکیج یا کلاس قرار بگیرند، مسئولیت‌ها تفکیک شده‌اند:هستهٔ HSC → مسئول تحلیل HTML و اجرای چک‌هاپلاگین‌ها (مثل Gradle Plugin) → مسئول نحوه اجرا و ادغام HSC در ابزارهای خارجیابزارهای کمکی مثل NetUtil و FileUtil → برای بررسی شبکه و سیستم فایلرابط کاربری گرافیکی (UI) → پیش‌بینی شده، ولی هنوز پیاده‌سازی نشدهمهم‌ترین بخش‌ها در سطح کلان:۱) HSC Coreمرکز تمام منطق بررسی HTML؛ شامل پارس HTML، اجرای چک‌ها، تولید پیشنهاد و جمع‌آوری نتایج.۲) Gradle Pluginراهی برای استفاده از HSC در build pipeline پروژه‌ها.۳) NetUtilابزار کمکی برای بررسی اتصال اینترنت و وضعیت لینک‌های HTTP.۴) FileUtilابزار کمکی برای مدیریت فایل‌ها و مسیرها.۵) Graphical UI (برنامه‌ریزی شده)نسخهٔ گرافیکی احتمالی HSC برای کاربران غیرتکنیکال.5.2 ساختار سطح ۲ – HSC Core (Whitebox)در این سطح، وارد قلب سیستم می‌شویم؛ جایی که تمام منطق تحلیل HTML قرار دارد.هستهٔ HSC بر اساس «تفکیک وظیفه‌ای» ساخته شده است. یعنی بخش‌های مختلف هر کدام یک وظیفهٔ روشن دارند و باهم برای رسیدن به هدف کنار می‌آیند.الگوهای اصلی ساختار Core:مدیریت پیکربندیخواندن و پارس فایل‌های HTMLاجرای چک‌های مختلفتولید پیشنهاد (Suggestions)جمع‌آوری نتایج برای تولید گزارشبلوک‌های اصلی Level 2:۱) Checker (Blackbox)مهم‌ترین بخش سیستم.اینجا یک کلاس انتزاعی (abstract) وجود دارد به نام Checker.تمام چکرها از آن ارث‌بری می‌کنند.وظیفه آن:تعریف یک رابط یکسان (check())پیاده‌سازی الگوریتم چک با Template Method Patternاین ساختار اجازه می‌دهد:انواع چک‌ها (لینک شکسته، تصویر گم‌شده، ID تکراری و…) به‌سادگی افزوده شوندرفتار مشترک در superclass تعریف شودفقط بخش‌های متفاوت override شونداین بخش دقیقاً پاسخ‌دهندهٔ کیفیت انعطاف‌پذیری و قابلیت توسعه است.۲) AllChecksRunnerپردهٔ نمایشی (Facade) بین Core و دنیای بیرونی.این بخش:تمام چکرها را مدیریت می‌کندبراساس پیکربندی تعیین می‌کند چه چک‌هایی اجرا شوندخروجی همهٔ چک‌ها را جمع‌آوری می‌کندپلاگین Gradle مستقیماً این بخش را فراخوانی می‌کند.۳) Configurationهمه‌چیز در HSC قابل پیکربندی است:مسیر فایل‌هامسیر گزارش خروجیtimeout بررسی لینک‌هاوضعیت‌هایی که باید خطا یا هشدار محسوب شوندانواع چک‌هایی که باید فعال باشنداین بخش یکی از پایه‌های کیفیت انعطاف‌پذیری (Flexibility) است.۴) Reporterنتایج چک‌ها باید:یا در کنسول چاپ شوندیا به صورت فایل HTML یا متن ذخیره شوندReporter این مسئولیت را بر عهده دارد.این طراحی اجازه می‌دهد در آینده Report Formatهای جدید هم اضافه شوند.۵) Suggester (Blackbox)بخش جذاب سیستم!وقتی یک خطا پیدا می‌شود، HSC سعی می‌کند نزدیک‌ترین گزینهٔ صحیح را پیشنهاد دهد.مثلاً اگر نویسنده نوشته باشد: و تصویر واقعی logo.png باشد، Suggester باید بتواند این پیشنهاد را ارائه دهد.این بخش با الگوریتم Jaro-Winkler Distance کار می‌کند تا شباهت رشته‌ها را پیدا کند.کاربردهایش:تصویر گم‌شده → پیشنهاد تصویر مشابهلینک داخلی خراب → پیشنهاد id نزدیک5.3 ساختار سطح ۳ – Results Collector (Whitebox)این بخش مسئول سازمان‌دهی نتایج چک‌هاست و ساختاری کاملاً سلسله‌مراتبی دارد.سه سطح نتیجه وجود دارد:۱) PerRunResultsنتیجهٔ کلی برای یک اجرای کامل HSC(ممکن است شامل چندین فایل HTML باشد)۲) SinglePageResultsنتایج چک‌های یک فایل HTML مشخص۳) SingleCheckResultsخروجی یک چکر خاص؛ مانند:چک MissingImagesچک BrokenLinksچک DuplicateIDs۴) Findingهر خطا یا هشدار یک Finding است.می‌تواند شامل توضیح و حتی پیشنهاد از Suggester باشد.این ساختار چند مزیت دارد:گزارش‌ها تمیز و قابل فهم می‌شوندافزودن چک‌های جدید ساده استساختار گزارش‌دهی با نیازهای مختلف (CLI، HTML، IDE) هماهنگ می‌ماندII.۶ رفتار سیستم در زمان اجرا یا Runtime Viewمعماری ایستا به ما می‌گوید سیستم از چه بخش‌هایی تشکیل شده است؛اما Runtime View توضیح می‌دهد که این بخش‌ها هنگام اجرا چگونه با یکدیگر تعامل می‌کنند.در HSC دو سناریوی اصلی وجود دارد:II.۶.۱ سناریو اول: اجرای همهٔ چک‌هااین سناریو رایج‌ترین حالت استفاده از HSC است—زمانی که کاربر یا سیستم Build می‌خواهد مجموعه‌ای از فایل‌های HTML را بررسی کند.فرایند اجرای چک‌ها به صورت زیر پیش می‌رود:۱) اجرای هدف (Task) توسط کاربر یا سیستم Buildکاربر معمولاً دستور htmlSanityCheck را اجرا می‌کندیا Gradle در طی یک Build آن را فراخوانی می‌کند.۲) Gradle کنترل را به HSC منتقل می‌کندGradle تسک sanityCheckHtml را اجرا می‌کند که مستقیماً به HSC متصل است.۳) HSC پیکربندی را بارگذاری می‌کنداین شامل موارد زیر است:مسیر HTMLهای ورودیمسیر خروجی گزارشtimeout لینک‌هافعال یا غیرفعال بودن چک‌های مختلف۴) ایجاد AllChecksRunnerاین بخش «موتور اجرای چک‌ها»ست.AllChecksRunner مسئول است:چکرها را آماده کندفایل‌های ورودی را جمع کندو اجرای چک‌ها را مدیریت کند۵) جمع‌آوری فایل‌هاHSC تمام فایل‌هایی را که باید بررسی شوند در یک مجموعه (allFiles) جمع می‌کند.۶) (برنامه‌ریزی‌شده) کشف خودکار Checkerهادر نسخهٔ آینده، HSC قرار است به‌وسیلهٔ Annotationها چکرهای موجود را کشف کند تا توسعهٔ آن آسان‌تر شود.۷) اجرای چک‌ها و جمع‌کردن نتایجهر Checker روی HTML اجرا می‌شود و یافته‌ها (Findings) در ساختار سلسله‌مراتبی نتایج ذخیره می‌شود.II.6.2 سناریو دوم: تولید گزارش چک‌هابعد از اجرا، HSC باید نتایج را با ساختاری قابل درک و هماهنگ ارائه دهد.این ساختار مطابق با سلسله‌مراتب ResultsCollector است:۱) نتایج سطح اجرا (PerRunResults)شامل:تاریخ و زمان اجراتعداد فایل‌های بررسی‌شدهپیکربندی اعمال‌شدهخلاصهٔ کلی نتایج۲) نتایج سطح صفحه (SinglePageResults)برای هر فایل HTML یک بخش جداگانه ایجاد می‌شود.در این مرحله:عنوان صفحهتعداد خطاهانوع خطاهانمایش داده می‌شود.۳) نتایج سطح چک (SingleCheckResults)برای هر چک—مثل بررسی لینک‌های داخلی یا تصاویر—یک بخش مستقل ایجاد می‌شود که شامل:فهرست یافته‌هاپیشنهادهای احتمالی برای اصلاح خطااین روش گزارش‌دهی باعث می‌شود خروجی HSC بسیار تمیز، قابل جستجو و قابل تحلیل باشد—درست مانند گزارش تست‌های واحد.II.۷ معماری استقرار یا HSC Deployment Viewدر Deployment View، معماری سیستم از نگاه محیط اجرا و نحوه استقرار آن بررسی می‌شود.با اینکه HSC ابزاری کوچک است، اما در معماری استقرار آن سه بازیگر اصلی نقش دارند:۱) سیستم توسعهٔ HSC (Development Environment)اینجا جایی است که خود HSC توسعه و کامپایل می‌شود.پیش‌نیازهای محیط توسعه:JDKGroovyGradleکتابخانهٔ Jsoup برای تحلیل HTMLدر این محیط خروجی باینری نهایی تولید و برای انتشار آماده می‌شود.۲) مخزن عمومی (Artifact Repository)بعد از Build، نسخهٔ کامپایل‌شده HSC (به‌صورت Plugin) در یک مخزن عمومی نظیر:Maven CentralGradle Plugin Portalمنتشر می‌شود.کاربران HSC باینری‌ها را مستقیماً از این مخازن دریافت می‌کنند.۳) سیستم کاربر (User Machine)کاربر نهایی HSC را روی سیستم خودش اجرا می‌کند؛ معمولاً در یکی از این سناریوها:در خط فرمان (CLI)به‌عنوان پلاگین Gradle داخل build.gradleهمراه با تولید مستندات AsciiDocپیش‌نیازهای کاربر:Java Runtime (نسخه ۱.۶ یا بالاتر)فایل build.gradle که پلاگین HSC در آن پیکربندی شده باشددر این سیستم است که:فایل‌های HTML ساخته می‌شوندHTML Sanity Check اجرا می‌شودو گزارش نهایی تولید می‌شودII.8 مفاهیم فراگیر (Cross-cutting Concepts)در هر سیستم نرم‌افزاری مجموعه‌ای از قواعد، الگوها و مفاهیم وجود دارد که فقط مربوط به یک بخش خاص نیستند؛ بلکه در سراسر معماری دیده می‌شوند. در HSC این مفاهیم شامل الگوهای طراحی، مدل دامنه، ساختار لینک‌های HTML، الگوریتم‌های بررسی، و نحوهٔ گزارش‌دهی است.در ادامه، چهار مفهوم مهم HSC را به زبان ساده و معمارانه بررسی می‌کنیم.8.1 مدل دامنه (Domain Model)برای اینکه HSC بتواند HTML را تحلیل کند، ابتدا باید مفاهیم اصلی مرتبط با ساختار HTML را در قالب یک «مدل دامنه» تعریف کند. این مدل تعیین می‌کند که سیستم چه چیزهایی را می‌شناسد و با چه مفاهیمی کار می‌کند.در ادامه مهم‌ترین مفاهیم دامنه را توضیح می‌دهیم:مفهوم Anchorهمان تگ که لینک ایجاد می‌کند.Anchor همیشه شامل یک link target است.Cross Reference (لینک داخلی)لینکی که به بخشی دیگر از همان صفحه یا همان سند اشاره می‌کند.این همان چیزی است که HSC باید بررسی کند تا ببیند آیا id مقصد واقعاً وجود دارد یا نه.External Link (لینک بیرونی)لینکی که به یک صفحهٔ وب یا دامنهٔ دیگر اشاره می‌کند.بررسی این لینک‌ها حساس است، چون ممکن است مشکلات شبکه باعث خطاهای ظاهری شود.Finding در HSCهر مشکلی که یکی از Checkerها پیدا می‌کند—مثلاً «تصویر logo.png پیدا نشد».گاهی همراه با پیشنهاد برای رفع خطا است.HTML Element در HSCواحدهای سازندهٔ صفحه، مثل , ,
.برای تحلیل ساختاری HTML، HSC باید این عناصر را به‌درستی استخراج کند.HTML Page / Document در HSCیک فایل HTML کامل که شامل مجموعه‌ای از HTML elements است.حداقل شرط آن این است که parser بتواند آن را به‌درستی پردازش کند.id در HSCشناسهٔ یک عنصر در HTML، معمولاً هدف لینک‌های داخلی (href="#id").Internal Link / Local Link در HSCلینکی که به بخش دیگری از همین صفحه یا همین پروژه اشاره می‌کند.Link و Link Targetهر چیزی که از یک نقطه به نقطهٔ دیگر ارجاع می‌دهد.Link Target می‌تواند:یک id داخل همان صفحهیک فایل HTML دیگریا یک منبع خارجی باشدLocal Resource در HSCفایل‌هایی مثل PDF، CSS یا JS که صفحهٔ HTML به آن‌ها ارجاع می‌دهد.8.2 ساختار لینک‌های HTMLHSC بخش زیادی از کار خود را روی لینک‌ها انجام می‌دهد، بنابراین باید ساختار URI را عمیقاً بشناسد.یک URI معمولاً شامل این بخش‌هاست:پروتکل (http/https)آدرس میزبان (Host)شماره پورتمسیر فایلQuery stringFragment یا همان anchor (#someLabel)HSC با بررسی این ساختار می‌تواند تشخیص دهد:آیا لینک معتبر است؟آیا ساختار لینک درست نوشته شده؟آیا مقصد لینک وجود دارد؟این دانش در تمام Checkerها استفاده می‌شود.8.3 الگوریتم‌های بررسی (Checking Algorithms)یکی از تصمیم‌های طراحی مهم در HSC استفاده از Template Method Pattern برای تعریف الگوریتم‌های چک است.چرا این الگو انتخاب شد؟چون HSC چندین نوع چک مختلف دارد:چک لینک‌های داخلیچک فایل‌های تصویریچک تکراری بودن idهاچک لینک‌های بیرونیچک منابع محلیهمهٔ این چک‌ها ساختار کلی مشابهی دارند اما در جزئیات متفاوت هستند.Template Method این امکان را می‌دهد:اسکلت الگوریتم در یک کلاس پایه نوشته شودفقط بخش‌های متغیر در subclassها override شوندافزودن چک‌های جدید بسیار ساده باشدساختار کار این الگو در HSC:۱) چکر ساخته می‌شود۲) مقدمات اجرا (initResults) انجام می‌شود۳) متد performCheck() فراخوانی می‌شود۴) الگوریتم خاص چکر در متد check() اجرا می‌شود۵) نتایج جمع‌آوری و بازگردانده می‌شودبا این ساختار، توسعه‌دهندگان می‌توانند هر نوع چک جدیدی را بدون تغییر در هستهٔ سیستم اضافه کنند—این موضوع کیفیت انعطاف‌پذیری را تضمین می‌کند.8.4 سیستم گزارش‌دهی (Reporting)گزارش‌دهی نیز مانند چکرها از Template Method Pattern استفاده می‌کند.در HSC دو نوع خروجی گزارش وجود دارد:گزارش HTMLگزارش متنی (Console)اما در هر دو حالت، ساختار گزارش یکسان است:ایجاد بخش ابتدایی گزارش (initReport)نمایش خلاصهٔ کلی (صفحات بررسی‌شده، میزان موفقیت، تعداد خطاها)گزارش نتایج هر صفحهگزارش نتایج هر چک برای آن صفحهایجاد بخش انتهایی گزارش (footer)این ساختار یکپارچه باعث می‌شود:اضافه کردن فرمت‌های جدید گزارش بسیار ساده باشدساختار گزارش همیشه ثابت و قابل درک بماندبرنامه‌های دیگر بتوانند گزارش را به‌راحتی پردازش کننداین سیستم گزارش‌دهی، کیفیت قابلیت استفاده و قابلیت گسترش را افزایش می‌دهد.II.۹ تصمیمات معماری (Architecture Decisions)در این بخش، مهم‌ترین تصمیمات معماری که مسیر طراحی HSC را مشخص کردند توضیح داده می‌شود. این تصمیم‌ها معمولاً مواردی هستند که یا پرهزینه‌اند، یا ریسک دارند، یا نقش مهمی در کیفیت نهایی سیستم بازی می‌کنند. ثبت این تصمیمات به تیم توسعه کمک می‌کند منطق پشت انتخاب‌ها را درک کند.۹.۱ تعویق بررسی لینک‌های خارجیدر نسخه فعلی HSC، بررسی لینک‌های خارجی انجام نمی‌شود. این قابلیت عمداً به نسخه‌های آینده موکول شده است.چرا؟بررسی منابع بیرونی به شبکه وابسته استسرعت و پایداری آن قابل تضمین نیستممکن است نتایج نادرست بدهد (به‌دلیل timeout، مشکلات DNS، محدودیت سرور مقصد)بنابراین تیم توسعه تصمیم گرفته ابتدا روی قابلیت‌های داخلی و مطمئن تمرکز کند و سپس در نسخه‌های آینده سراغ لینک‌های خارجی برود.۹.۲ انتخاب Jsoup برای پارس HTMLHSC برای تحلیل ساختار HTML و استخراج لینک‌ها و تصاویر، نیاز به یک parser داشت. از میان گزینه‌های موجود، Jsoup انتخاب شد.دلایل این انتخاب:۱) بدون وابستگی خارجیJsoup یک کتابخانه سبک است و خودش به چیز دیگری وابسته نیست.این موضوع باعث می‌شود اندازه نهایی ابزار کوچک بماند و نصب آن آسان باشد.۲) API ساده و قدرتمندJsoup ترکیبی از:DOMCSS selectorsو سبک jQueryرا ارائه می‌دهد؛ یعنی با چند خط کد می‌توان:همهٔ لینک‌ها را پیدا کردهمهٔ تصاویر را استخراج کردهمهٔ idها را جمع کرد۳) انعطاف‌پذیری بالاJsoup می‌تواند ورودی را از فایل، رشته، stream یا منابع دیگر دریافت کند.جایگزین‌ها و دلیل رد شدنشانHTTPUnit → جهت تست وب‌سایت‌ها ساخته شده، وابستگی‌های زیاد داردHtmlCleaner → گزینه‌ای مناسب اما API محدودترJsoup در نهایت بهترین توازن را داشت: سبک، پرقدرت، سادهاین تصمیم قلب معماری سیستم را شکل می‌دهد، چون تمام چکرها به این ساختار DOM متکی هستند.II.10 نیازمندی‌های کیفی (Quality Requirements)کیفیت در HSC فقط یک مبحث تئوریک نیست؛ نیازمندی‌های کیفی این سیستم کاملاً قابل اندازه‌گیری و عملیاتی هستند. بخشی از این نیازها در ابتدای سند معرفی شدند و در این قسمت همان اهداف را به‌صورت دقیق‌تر و سناریومحور می‌بینیم.صحت (Correctness)HSC باید تضمین کند که:هر لینک داخلی شکسته شناسایی شودهر تصویر گم‌شده تشخیص داده شودتمام چکرها با تست مثبت و منفی اعتبارسنجی شونداین یعنی هیچ خطا یا هشدار نباید از چشم سیستم پنهان بماند.کامل بودن گزارش (Completeness)گزارش خروجی باید شامل تمام یافته‌ها باشد—حتی موارد جزئی.انعطاف‌پذیری (Flexibility)سیستم باید به‌گونه‌ای طراحی شود که:چکر جدید به آن اضافه شودگزارش‌دهی در قالب‌های جدید توسعه یابداز سیستم‌های build دیگر (غیر از Gradle) هم قابل استفاده باشدایمنی (Safety)HSC باید همیشه تمام فایل‌ها را بدون تغییر باقی بگذارد.این یک اصل غیرقابل‌مذاکره است:هیچ تغییری در HTML ورودی نباید ایجاد شود.کارایی (Performance)برای یک فایل HTML به اندازه ۱۰۰ کیلوبایت، تمام چک‌ها باید در کمتر از ۱۰ ثانیه انجام شوند.(بدون احتساب زمان startup Gradle)II.11 ریسک‌ها و بدهی فنی (Risks & Technical Debt)HSC پروژه کوچکی است، اما همچنان شامل چند ریسک فنی و تجاری است که باید به آن‌ها توجه شود.۱۱.۱ ریسک‌های فنی۱) وابستگی به یک توسعه‌دهندهدر حال حاضر فقط یک نفر دسترسی انتشار نسخه‌های جدید پلاگین را دارد.در صورت غیبت او، انتشار نسخه‌های جدید یا رفع اشکال ممکن است متوقف شود.۲) حساسیت نسبت به تغییرات Gradleبه‌روزرسانی Gradle در گذشته نیازمند تغییرات دستی در HSC بوده.هر ارتقای API ممکن است دوباره وقت‌گیر شود.این دو ریسک ممکن است در آینده هزینه‌زا باشند.۱۱.۲ ریسک‌های تجاری / دامنه‌ایاحتمال از رده خارج شدن سیستماگر AsciiDoc یا Markdown در آینده قابلیت بررسی لینک و تصویر را به‌صورت داخلی اضافه کنند:HSC ممکن است کارکرد اصلی خود را از دست بدهدنیاز به مدل کسب‌وکار جدید یا ارزش افزوده جدید خواهد بوداین ریسک استراتژیک است و به روند توسعه ابزارهای تولید مستندات بستگی دارد.II.12 واژه‌نامه (Glossary)برای اینکه ارتباط بین کاربران و توسعه‌دهندگان شفاف باشد، لازم است مفاهیم کلیدی دامنهٔ HSC معنی مشخصی داشته باشند.Linkهر ارجاعی در فایل HTML که کاربر را به بخشی دیگر یا منبع دیگری هدایت می‌کند.Cross Referenceنوعی لینک داخلی که به یک id داخل همان صفحه اشاره می‌کند.External Hyperlinkلینکی که خارج از دامنهٔ فعلی (مثلاً به یک وب‌سایت دیگر) اشاره می‌کند.Run Resultنتیجهٔ کامل یک اجرای HSC روی چندین فایل.SinglePageResultsخروجی تمام چکرها برای یک فایل HTML مشخص.بخش پایانیدر نهایت، مثال HTML Sanity Check نشان می‌دهد که حتی یک ابزار کوچک و مینیمال هم می‌تواند معماری شفاف، قابل‌توسعه و حرفه‌ای داشته باشد—به‌شرط آنکه از یک الگوی مستند‌سازی استاندارد مانند arc42 استفاده شود. این مثال ثابت می‌کند که معماری فقط مخصوص سیستم‌های عظیم و سازمانی نیست؛ حتی پروژه‌های کوچک نیز با داشتن یک ساختار معماری اصولی، درک‌پذیرتر، پایدارتر و قابل نگه‌داری‌تر می‌شوند.مستندسازی HSC نشان داد چگونه:تصمیمات کوچک مثل انتخاب Jsoupالگوهای طراحی مانند Template Methodو مفاهیم دامنه‌ای واضح مانند Link، Finding و HTML Elementمی‌توانند در کنار هم یک سیستم ساده را به یک نمونهٔ عالی از معماری تمیز و قابل توسعه تبدیل کنند.این مقاله همچنین گام‌به‌گام نشان داد که arc42 چگونه کمک می‌کند:بخش‌های کلیدی یک سیستم را شناسایی کنیمتعامل اجزا را درک کنیمکیفیت‌ها را قابل اندازه‌گیری کنیمو ریسک‌های احتمالی را از ابتدا شفاف کنیمبدون داشتن چنین چارچوبی، تحلیل و توسعهٔ سیستم—even اگر کوچک باشد—در بلندمدت هزینه‌بر و گیج‌کننده خواهد شد.با رشد ابزارهای خودکار، سیستم‌های توزیع‌شده، و توسعهٔ محصول مبتنی بر هوش مصنوعی، اهمیت داشتن مستند معماری استاندارد روزبه‌روز بیشتر می‌شود. arc42 یکی از روش‌هایی است که هم برای سیستم‌های بزرگ کاربردی است، هم برای ابزارهای کوچک مثل HSC؛ و همین موضوع، ارزش آن را در چرخهٔ عمر محصول دوچندان می‌کند.اگر نیاز دارید معماری پروژه‌های خود را استاندارد کنید، مستند arc42 بسازید، یا معماری فعلی‌تان را بازطراحی و عملیاتی کنید، تیم معماری و توسعه‌ی نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) همراه شماست—از تحلیل اولیه تا مستندسازی و پیاده‌سازی کامل.این مقاله با هدف آگاهی‌بخشی توسط تیم توسعه‌ی نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#معماری_نرم‌افزار#arc42#مستندسازی_معماری#تحلیل_سامانه#طراحی_سیستم#معماری_فنی#HTMLSanityCheck#Software_Architecture#architecture_documentation#design_patterns#clean_architecture#devtools#quality_engineering#technical_writing#شرکت_راهکار_نگار_هوشمند#arcanco

راهنمای arc42؛ استاندارد جهانی برای مستندسازی معماری نرم‌افزار

محمد حسین جلیلی — Sat, 29 Nov 2025 10:49:29 +0330
اگر درگیر طراحی سیستم‌های مبتنی بر میکروسرویس‌ها، سیستم‌های توزیع‌شده، معماری کلان‌داده، سامانه‌های سازمانی یا توسعه‌ی نرم‌افزار مقیاس‌پذیر هستید، شناخت arc42 به شما کمک می‌کند معماری‌تان را نه‌تنها بهتر طراحی کنید، بلکه بتوانید آن را طوری مستند کنید که برای همه اعضای تیم قابل فهم و قابل توسعه باشد.در شکل زیر می‌توانید یک نمای کلی از arc42 داشته باشید:arc42 چیست؟arc42 یک قالب استاندارد برای مستندسازی معماری نرم‌افزار است.نه یک ابزار است، نه یک فریم‌ورک؛ فقط یک ساختار هوشمندانه که به تو کمک می‌کند به دو سؤال حیاتی پاسخ بدهی:چه چیزهایی باید درباره معماری سیستمم توضیح بدهم؟چطور باید آن‌ها را توضیح بدهم؟arc42 مثل یک کمد با کشوهای برچسب‌خورده عمل می‌کند:هر کشو موضوع مشخصی از معماری را در خود دارد.در نسخه کامل arc42 تعداد ۱۲ کشو وجود دارد که تقریبا همه چیز از «اهداف سیستم» تا «تصمیم‌های مهم معماری» و «کیفیت‌های سیستمی» را پوشش می‌دهد.به خاطر همین ساختار شفاف، arc42 کمک می‌کند معماری سیستم—حتی اگر پیچیده باشد—با کمترین هزینه قابل توضیح و قابل درک شود.چرا arc42 تا این حد محبوب است؟معمولاً دو دلیل باعث می‌شود تیم‌ها و سازمان‌ها عاشقش شوند:۱) مستندسازی قابل فهمساختار استاندارد arc42 باعث می‌شود هر کسی—چه توسعه‌دهنده تازه‌وارد، چه مدیر فنی—بتواند به‌سرعت معماری را بفهمد.این یعنی سردرگمی کمتر، زمان آموزش کمتر و تصمیم‌گیری سریع‌تر.۲) مستندسازی بدون دردبه آن می‌گویند “painless documentation”.چون مجبور نیستی زمان زیادی صرف نوشتن توضیحات پراکنده و بی‌ساختار کنی.فقط کافی است کشوها را پر کنی؛ همین.مزیت اصلی arc42: وضوح + کارآمدیarc42 از تو می‌خواهد معماری را در یک بستر قابل‌فهم و قابل تکرار توضیح بدهی.این یعنی هر بخش از معماری، تصمیم‌ها و وابستگی‌ها در یک جای مشخص و روشن قرار می‌گیرند.نتیجه؟معماری‌ای که:قابل خواندن استقابل نگهداری استقابل انتقال به تیم‌های جدید استو در جلسات مدیریتی اعتماد ایجاد می‌کندسؤال معروف: چرا اسمش «۴۲» است؟این بخش کمی فان است.سازندگان arc42 اسمش را از رمان معروف “Hitchhiker’s Guide to the Galaxy” گرفته‌اند؛ جایی که عدد ۴۲ به‌عنوان:«پاسخ نهایی به سؤال زندگی، جهان و همه‌چیز»معرفی می‌شود.arc42 هم برای معماری قصد دارد همان جواب نهایی باشد—حداقل از نگاه سازندگانش!📦 بخش‌های arc42 و توضیح هر کدام۱. Introduction and Goalsدر این بخش توضیح می‌دهید چرا این سیستم ساخته می‌شود و چه اهدافی دارد.شامل موارد زیر است:نیازمندی‌ها و اهداف سیستمذینفعان (stakeholders) و انتظارات آن‌هااهداف کیفی مهم (Quality Goals) که روی معماری تأثیر مستقیم دارنداین بخش باید تصویری کلی از سیستم بدهد و توضیح بگوید «هدف از این معماری چیست و برای چه مشکلی طراحی شده است».۲. Constraintsاین بخش شامل تمام محدودیت‌هایی است که طراحی معماری را شکل می‌دهند:محدودیت‌های فنی (مثلاً اجبار به استفاده از زبان یا سرویس خاص)محدودیت‌های سازمانی (خط‌مشی‌ها، استانداردها، رویه‌ها)محدودیت‌های محیطی و قانونیاین‌ها همان خطوط قرمز پروژه‌اند. معماری باید با این محدودیت‌ها سازگار باشد.۳. Context and Scopeدر این بخش محدوده سیستم و تعاملات آن با محیط بیرون مشخص می‌شود:سیستم شما دقیقاً کجای دنیا قرار می‌گیرد؟چه بازیگران یا سیستم‌هایی با آن تعامل دارند؟چه چیزهایی داخل محدوده سیستم هستند و چه چیزهایی خارج آن؟نتیجه این بخش معمولاً شامل یک دیاگرام کلی و توضیح روابط/اینترفیس‌ها است.۴. Solution Strategyدر اینجا تصمیم‌های بزرگ و بنیادین معماری ثبت می‌شود:سبک معماری انتخاب‌شدهرویکرد کلی برای تقسیم‌بندی سیستمانتخاب تکنولوژی‌های مهمروش‌های رسیدن به اهداف کیفیتاین بخش نگاه «کلان» به معماری را ارائه می‌کند.۵. Building Block Viewاینجا ساختار ایستای سیستم نمایش داده می‌شود:ماژول‌ها، لایه‌ها، بسته‌ها و کامپوننت‌هانحوه‌ی وابستگی آن‌هاتوضیح هر جزء با رویکرد Black-Box / White-Boxاین بخش مثل نقشه طبقات یک ساختمان است: چه چیزهایی کجا قرار دارند و چه کار می‌کنند.۶. Runtime Viewدر این بخش توضیح داده می‌شود که اجزای سیستم در زمان اجرا چگونه با هم تعامل می‌کنند:سناریوهای مهم اجرامسیر دادهتعامل کامپوننت‌هارفتار سیستم در شرایط خاص (استارتاپ، خطا، پردازش درخواست و …)این بخش رفتار واقعی سیستم را نشان می‌دهد، نه فقط ساختار کد را.۷. Deployment Viewدر این بخش زیرساخت و محیط اجرای سیستم نمایش داده می‌شود:سرورهامحیط‌های استقرار (dev, staging, production)شبکه، پیکربندی‌ها و توپولوژیاینکه هر جزء نرم‌افزار روی کدام ماشین/نود اجرا می‌شوداین دید برای تیم‌های DevOps و عملیات حیاتی است.۸. Crosscutting Conceptsمفاهیم و الگوهایی که چند بخش سیستم را تحت تأثیر قرار می‌دهند، اینجا مستند می‌شوند:احراز هویتلاگینگ و مانیتورینگاستانداردهای معماریقواعد طراحیالگوهای مشترک پیاده‌سازیاینجا قوانین مشترک سیستم را یکجا توضیح می‌دهید.۹. Architecture Decisionsاین بخش مخصوص ثبت تصمیم‌های مهم معماری است:موضوع تصمیمزمینه و دلیل آنگزینه‌های بررسی‌شدهتصمیم نهاییپیامدهای مثبت و منفیاین کار کمک می‌کند در آینده بدانید «چرا» یک انتخاب انجام شده.۱۰. Quality Requirements (Quality)الزامات کیفیتی سیستم در این بخش مشخص می‌شوند:کیفیت‌هایی مثل امنیت، کارایی، مقیاس‌پذیری، نگه‌داشت‌پذیریساختار درخت کیفیت (Quality Tree)سناریوهای دقیق کیفیت برای ارزیابی اهدافاین بخش کمک می‌کند معماری فقط از نظر عملکرد، نه بلکه از نظر کیفیت هم قابل سنجش باشد.۱۱. Risks and Technical Debtدر این بخش موارد زیر مستند می‌شود:ریسک‌های فنی و عملیاتیمشکلات شناخته‌شدهبدهی فنی موجودبخش‌هایی که احتمال مشکل‌دار شدن دارندهدف این است که نسخه‌ی شفاف و قابل پیگیری از ریسک‌ها وجود داشته باشد.۱۲. Glossaryاین قسمت شامل واژه‌ها و اصطلاحات مهم پروژه است:اصطلاحات دامنه کسب‌وکاراصطلاحات فنی اختصاصی پروژههدف: همه اعضای تیم یک معنی واحد از واژه‌ها داشته باشند.در پایان، باید گفت که قالب arc42 تنها یک الگوی مستندسازی نیست؛ بلکه رویکردی نظام‌مند برای شفاف‌سازی معماری، یکپارچه‌سازی دانش تیم، کاهش ریسک‌ها و تسهیل توسعه در بلندمدت است. چه در حال طراحی یک سامانه‌ی میکروسرویسی باشید، چه یک سیستم بلادرنگ، ERP سازمانی، پلتفرم گیمیفیکیشن یا اپلیکیشن مقیاس‌پذیر، arc42 کمک می‌کند از ابتدا معماری را درست تعریف کنید و با تیم‌تان به درک مشترک برسید.در آینده با رشد معماری‌های مدرن، سیستم‌های توزیع‌شده و توسعه‌ی محصول با کمک هوش مصنوعی، استفاده از الگوهای استانداردی مانند arc42 به یکی از نیازهای اصلی تیم‌های نرم‌افزاری تبدیل خواهد شد. این قالب نه‌تنها سرعت تصمیم‌گیری را بالا می‌برد، بلکه امکان نگهداری، توسعه و مقیاس‌پذیری سیستم را بسیار آسان‌تر می‌کند.اگر برای طراحی معماری، مستندسازی حرفه‌ای، یا پیاده‌سازی arc42 در پروژه‌های نرم‌افزاری خود نیاز به مشاوره دارید، تیم معماری و توسعه‌ی نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) با تجربه‌ی عملی در پروژه‌های بزرگ، از همراهی با شما خوشحال خواهد شد.این مقاله با هدف آگاهی‌بخشی توسط تیم توسعه‌ی نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#معماری_نرم‌افزار#arc42#مستندسازی_معماری#سازه_نرم‌افزار#سیستم_توزیع_شده#میکروسرویس#طراحی_سیستم#software_architecture#architecture_documentation#enterprise_architecture#cloud_native#iot#devops#مهندسی_نرم‌افزار#technical_architecture#شرکت_راهکار_نگار_هوشمند#arcanco

مقیاس‌پذیری نرم‌افزار با مدل Virtual Actor در سیستم‌های توزیع‌شده

محمد حسین جلیلی — Fri, 28 Nov 2025 15:21:19 +0330
آیا تا به حال به این فکر کرده‌اید که چگونه می‌توان یک نرم‌افزار پیچیده و توزیع‌شده را به شکلی ساده، سریع و مقیاس‌پذیر طراحی کرد؟اگر با مفاهیمی مثل مدل بازیگر در نرم‌افزار، بازیگر مجازی (Virtual Actor) یا فریم‌ورک‌هایی مثل Proto.Actor آشنایی دارید یا می‌خواهید درک عمیق‌تری از آن‌ها پیدا کنید، این مقاله برای شما نوشته شده است.امروزه بسیاری از سازمان‌ها برای ساخت سامانه‌هایی با معماری پیشرفته، به سمت استفاده از مدل بازیگر (Actor Model) در سیستم‌های خود حرکت کرده‌اند. به‌ویژه در زمینه‌هایی مانند توسعه نرم‌افزار مقیاس‌پذیر، پردازش بلادرنگ و سیستم‌های توزیع‌شده، استفاده از مدل بازیگر یک رویکرد قدرتمند و عملیاتی است. در این مقاله، با تمرکز بر مفاهیم کلیدی، مثال‌های واقعی و معرفی ابزارهایی مانند Proto.Actor، به بررسی این مدل جذاب می‌پردازیم.در گذشته، بسیاری از برنامه‌ها بدون نیاز به مقیاس‌پذیری برای حجم‌های زیاد داده توسعه می‌یافتند. این وضعیت، فرآیند برنامه‌نویسی را نسبتاً ساده می‌کرد. کافی بود از یک مدل ساده‌ی شی‌گرا (Object-Oriented) استفاده کرده و داده‌ها را مستقیماً در حافظه پردازش کنید.اما امروز، مقیاس‌پذیری و پردازش حجم عظیمی از داده‌ها—به‌خصوص در راهکارهای اینترنت اشیاء (IoT)—به عناصر کلیدی در عملکرد برنامه‌ها و همچنین مزیت رقابتی استراتژیک آن‌ها تبدیل شده‌اند.مقیاس‌پذیری حالا خودش یک چالش واقعی است—و با خود، لایه‌ی کاملاً جدیدی از پیچیدگی را به همراه می‌آورد. در بسیاری از موارد، پشته‌ی فناوری (Tech Stack) مورد استفاده آن‌قدر پیچیده می‌شود که دیگر برای تیم‌های کوچک توسعه‌دهنده قابل مدیریت نیست.آیا می‌توان مقیاس‌پذیر شد بدون اینکه سادگی برنامه‌نویسی را فدا کرد؟با این حال، ممکن است راهی وجود داشته باشد تا بتوان در عین حفظ مدل برنامه‌نویسی ساده و رویدادمحور (event-driven)، برنامه را روی چند رشته (multi-threaded) و حتی چند ماشین (multi-machine) اجرا کرد.و همه‌ی این‌ها در همان محیط آشنا و دلخواه برنامه‌نویسی که به آن عادت دارید!اجازه دهید شما را با مفهومی آشنا کنم که این کار را ممکن می‌سازد:مدل بازیگرهای مجازی (Virtual Actors).مسأله چیست؟بیایید با یک نمایش ساده شروع کنیم. نگاهی بیندازید به یک اپلیکیشن نمونه که به‌عنوان دموی فریم‌ورک Proto.Actor ساخته شده است. این برنامه، حرکت اتوبوس‌ها در شهر تهران را به‌صورت بلادرنگ (real-time) ردیابی می‌کند.فرض کنیم می‌خواهیم اپلیکیشنی مشابه بسازیم، و این نیازها را داریم:موقعیت لحظه‌ای هر اتوبوس را نمایش دهد.مسیر طی‌شده‌ی اتوبوس در ۵ دقیقه گذشته را نشان دهد.نقشه را به‌صورت بلادرنگ (real-time) به‌روزرسانی کند، ولی فقط بخش‌هایی که برای کاربر قابل مشاهده هستند.موقعیت اتوبوس‌هایی که خارج از دید کاربر هستند، اصلاً از طریق شبکه منتقل نشود.تا اینجا چیز پیچیده‌ای نداریم. اما بیایید کمی چالش‌برانگیزترش کنیم و نیازهای زمانی و مکانی بیشتری اضافه کنیم:اگر یک اتوبوس بیش از ۱۰ دقیقه در جایی متوقف شده باشد و درب‌های آن بسته باشد، برای کاربر نوتیفیکیشن ارسال شود.سازمان صاحب اتوبوس‌ها می‌تواند محدوده‌های جغرافیایی (Geofence) تعریف کند. هر زمان که یک اتوبوس وارد یا خارج از این محدوده شد، به کاربر اطلاع داده شود.شاید بگویید که تهران با بیش از ۴۰۰۰ وسیله‌ی نقلیه‌ی عمومی فعال به‌صورت هم‌زمان، خیلی مقیاس بزرگی نیست. پس بیایید سناریو را بزرگ‌تر کنیم:برنامه باید قابلیت مقیاس‌پذیری برای تمام شهرهای بزرگ ایران را داشته باشد.حالا سؤال اینجاست:چگونه می‌توان اپلیکیشنی با چنین نیازهایی طراحی کرد؟رویکرد سنتیبرای حل این مسئله، روش‌های متعددی وجود دارد. یکی از آن‌ها به‌صورت زیر است:در این رویکرد سنتی، با مشکلات متعددی مواجه هستیم:در این مدل، هیچ تطابقی با دنیای واقعی وجود ندارد. نه مفهومی به نام "اتوبوس" داریم، نه "سازمان‌ها". در عوض، فقط با "جریان موقعیت‌ها (stream of positions)" سروکار داریم که باید پردازش شود.برای پردازش داده‌ها، باید روی پایگاه‌داده‌ی موقعیت‌ها، کوئری‌های سنگین و هزینه‌بر اجرا کنیم—و البته باید آن‌ها را کش (cache) کنیم تا عملکرد بهتری داشته باشیم.باید به مقیاس‌پذیری پایگاه‌داده نیز فکر کنیم: چگونه آن را توزیع کنیم؟ چگونه بار ترافیک را تقسیم کنیم؟باید تاخیر شبکه و پیچیدگی‌های ارتباطات توزیع‌شده را در طراحی در نظر بگیریم.با مشکلات همروندی (concurrency) دست‌و‌پنجه نرم می‌کنیم. اگر دو عملیات همزمان روی یک موقعیت اعمال شود چه؟ چه کسی مسئول هماهنگی است؟باید از یک پشته‌ی فناوری (tech stack) مقاوم و پیچیده استفاده کنیم—که البته این هم به توسعه‌دهندگانی با مهارت‌های گسترده و متنوع نیاز دارد.در کل، این معماری به‌مراتب پیچیده‌تر از چیزی است که برای این مسئله‌ی نسبتاً ساده لازم است. پیچیدگی موجود، ناشی از نیاز به مقیاس‌پذیری است.آیا راه ساده‌تری وجود دارد؟قطعاً خیلی خوب می‌شد اگر می‌توانستیم همه‌ی مفاهیم دنیای واقعی را به‌عنوان اشیاء (objects) در یک اپلیکیشن واحد مدل کنیم، و تمام الگوریتم‌ها را مستقیماً در حافظه اجرا کنیم.در این مدل، ما هر اتوبوس، سازمان، و محدوده‌ی قابل‌مشاهده روی نقشه (viewport) را به‌عنوان یک شیء منحصربه‌فرد در نظر می‌گیریم و تعامل بین آن‌ها را نیز به‌شکل شی‌گرا مدل‌سازی می‌کنیم.هر شیء دارای وضعیت داخلی (state) است، و می‌تواند آن را در واکنش به سیگنال‌هایی از دنیای بیرون یا سایر اشیاء، تغییر دهد.نتیجه چیست؟این برنامه بسیار آسان‌تر برای ساخت است نسبت به معماری سنتی قبلی، و به‌مراتب قابل‌فهم‌تر برای توسعه‌دهندگان.اما آیا چنین اپلیکیشن شی‌گرایی واقعاً مقیاس‌پذیر است؟ایرادی که می‌توان وارد کرد این است که:یک برنامه‌ی شی‌گرا و ساده، احتمالاً طبق نیاز ما قابل مقیاس‌پذیری نیست.ما نمی‌توانیم همه‌ی این اشیاء را روی یک ماشین واحد جای دهیم.و از طرفی راهی برای گسترش آن به چند ماشین هم وجود ندارد—حداقل نه در معماری شی‌گرای سنتی.یه جور دیگه بزار بگم:"ای کاش می‌شد همه چیز رو مثل دنیای واقعی، به‌صورت شی‌ء (object) در نظر بگیریم. هر اتوبوس، هر سازمان، هر محدوده‌ی نقشه → یک object مجزا، با وضعیت خاص خودش."و بعد، تمام منطق برنامه (مثل بررسی توقف ۱۰ دقیقه‌ای، عبور از geofence و...) رو داخل حافظه اجرا کنیم.نتیجه‌اش چی می‌شه؟برنامه ساده‌تر نوشته می‌شهراحت‌تر فهمیده می‌شهکمتر نیاز به هماهنگی بین اجزاء پیچیده داره🛑 اما مشکل کجاست؟مشکل اینه که:این مدل ساده فقط روی یک ماشین جواب می‌ده و اگر بخوای ده‌ها هزار شیء (اتوبوس و...) رو همزمان مدیریت کنی، حافظه و پردازنده‌ی یک سیستم جواب نمی‌ده.از طرف دیگه، معماری شی‌گرا به‌صورت سنتی، برای توزیع روی چند ماشین طراحی نشده.پاسخ: بله، راهی وجود دارد—"بازیگرهای مجازی" (Virtual Actors)مدلی به نام بازیگران مجازی (Virtual Actors)—که گاهی با نام "غله‌ها" (Grains) نیز شناخته می‌شوند—این امکان را فراهم می‌کنند که:مدل شی‌گرای ساده‌ی شما همچنان حفظ شوددر عین حال بتوان آن را به خوشه‌های بزرگی از ماشین‌ها گسترش دادبه‌طوری که هر ماشین، بخشی از اشیاء یا بازیگران را مدیریت کنداین یعنی می‌توانیم سادگی مدل برنامه‌نویسی شی‌گرا را با مقیاس‌پذیری افقی واقعی ترکیب کنیم—بدون پیچیدگی‌های معماری مرسوم!یعنی اینجوری بگم که:این مدل به ما اجازه می‌ده که:همون سبک ساده‌ی شی‌گرا رو حفظ کنیماما اشیاء (اتوبوس‌ها، سازمان‌ها، و...) در پشت صحنه روی چندین سرور پخش (توزیع) بشنهر سرور، فقط بخشی از اشیاء رو نگه‌داری و مدیریت می‌کنهو ما به‌عنوان توسعه‌دهنده، نیازی نداریم بدونیم شیء موردنظر کجاست یا کی بارگذاری می‌شه—همه چیز اتوماتیکهمدل بازیگر (Actor Model)بیایید ابتدا در مورد بازیگرهای معمولی و مدل اصلی Actor که در سال ۱۹۷۳ معرفی شد صحبت کنیم.این مدل به‌عنوان یک «مدل ریاضی برای محاسبات همروند (concurrent computation)» تعریف شده است،اما اجازه بده ساده‌تر توضیحش دهیم.🎭 بازیگر چیست؟یک Actor را مثل یک شیء تصور کن که:پیام‌ها را از یک صف (Queue) دریافت می‌کندیک وضعیت داخلی (In-Memory State) در حافظه نگه می‌داردمثلاً:بازیگر اتوبوس (BusActor) می‌تواند تاریخچه‌ی موقعیت‌های اخیر یک اتوبوس را در خودش ذخیره کند.بازیگر Geofence می‌تواند لیستی از اتوبوس‌هایی که در محدوده‌ی خاصی قرار دارند را نگه دارد.هر پیام جدیدی که دریافت می‌شود ممکن است این وضعیت را تغییر دهد (mutate).و چون همه چیز در حافظه اتفاق می‌افتد، این کار بسیار سریع‌تر از تعامل با دیتابیس انجام می‌شود.بعضی بازیگرها حتی می‌توانند روی دنیای بیرون اثر بگذارند (مثلاً چیزی در کنسول چاپ کنند، نوتیف بفرستند، یا به سیستم خارجی پاسخ دهند).وضعیت اجرا چگونه است؟پیام‌ها یکی‌یکی پردازش می‌شوند، آن هم روی یک Thread.وضعیت داخلی Actor فقط برای خودش است و از بیرون غیرقابل دسترسی.بنابراین:هیچ مشکل همروندی (Concurrency) نداریم.کدها ساده‌تر، قابل تست‌تر و بدون نیاز به قفل‌گذاری هستند.آیا این مدل واقعاً مقیاس‌پذیر است؟با وجود اینکه هر Actor فقط روی یک Thread اجرا می‌شود،پاسخ بله است.با ایجاد تعداد زیادی Actor و اجرای همزمان آن‌ها، می‌توانید به موازی‌سازی (Massive Parallelism) برسید.مثلاً:برای هر اتوبوس در شهر تهران، یک بازیگر جداگانه داشته باشید.این بازیگرها می‌توانند با هم کار کنند، بدون اینکه به وضعیت همدیگر دست بزنند.این چیزهایی که گفتیم خیلی انتزاعی بود، بگذارید یک نگاهی به کد داشته باشیم:public class HelloActor : IActor { public Task ReceiveAsync(IContext context) { if (context.Message is Hello helloMsg) Console.WriteLine($"Hello {helloMsg.Who}"); return Task.CompletedTask; } }توضیح کدpublic class HelloActor : IActorتعریف یک Actor با نام HelloActorاین کلاس از اینترفیس IActor پیروی می‌کند که نشان می‌دهد این کلاس می‌تواند پیام دریافت و پردازش کند.public Task ReceiveAsync(IContext context)متدی که در زمان دریافت پیام، توسط سیستم فریم‌ورک Proto.Actor فراخوانی می‌شود.آرگومان context اطلاعات مربوط به پیام و وضعیت فعلی بازیگر را در خود دارد.if (context.Message is Hello helloMsg)بررسی می‌کند که آیا پیام دریافتی از نوع Hello است یا نه.اگر بود، آن را به متغیر helloMsg تبدیل می‌کند که به داده‌های داخلش دسترسی داریم.Console.WriteLine($"Hello {helloMsg.Who}");خروجی چاپ می‌کند به صورت:Hello <نام ارسال‌کننده>مثلاً اگر Who = "Ali" باشد، خروجی می‌شود:Hello Alireturn Task.CompletedTask;نشان می‌دهد که بازیگر بعد از دریافت و پردازش این پیام، کاری ندارد.این متد باید Task برگرداند، و CompletedTask یعنی عملیات تموم شده.کاربرد در واقعیت چیه؟این کد می‌تونه بخشی از یک سیستم بزرگ باشه که در آن، بازیگرها به عنوان موجودیت‌هایی مستقل، هر کدام فقط مسئول یک نوع خاص از رفتار هستند—در اینجا مثلاً بازیگر سلام‌دهنده.حالا کد بعدی رو هم نگاه کنیم:public class BusActor : IActor { List _positionHistory = new(); public Task ReceiveAsync(IContext context) { switch (context.Message) { case Position position: _positionHistory = _positionHistory .Where(p => DateTimeOffset.UtcNow - p.Timestamp < TimeSpan.FromMinutes(5)) .ToList(); _positionHistory.Add(position); break; case GetPositionsHistoryRequest: context.Respond(new PositionBatch { Positions = _positionHistory }); break; } return Task.CompletedTask; } }توضیح BusActorpublic class BusActor : IActorتعریف یک کلاس Actor به نام BusActorاز رابط IActor پیروی می‌کند، یعنی یک Actor استاندارد در Proto.Actor استList _positionHistory = new();تعریف یک لیست از نوع Position برای نگه‌داری تاریخچه‌ی موقعیت‌های اتوبوساین لیست فقط آخرین ۵ دقیقه‌ی موقعیت‌ها را ذخیره می‌کندمثل حافظه‌ی داخلی یک GPS که فقط حرکات اخیر را نگه می‌داردpublic Task ReceiveAsync(IContext context)متدی که در زمان دریافت پیام، اجرا می‌شودcontext.Message حاوی پیام دریافتی استبا استفاده از switch نوع پیام بررسی می‌شودحالت اول: دریافت موقعیت جدیدcase Position position:اگر پیام دریافتی از نوع Position بود:_positionHistory = _positionHistory .Where(p => DateTimeOffset.UtcNow - p.Timestamp < TimeSpan.FromMinutes(5)) .ToList();این خط، فیلتر می‌کند که فقط موقعیت‌هایی که در ۵ دقیقه‌ی گذشته ثبت شده‌اند باقی بمانندموقعیت‌های قدیمی‌تر از لیست حذف می‌شوند._positionHistory.Add(position);موقعیت جدید دریافتی به لیست اضافه می‌شودحالت دوم: درخواست برای دریافت تاریخچه موقعیت‌هاcase GetPositionsHistoryRequest: context.Respond(new PositionBatch { Positions = _positionHistory }); break;اگر پیام دریافتی از نوع GetPositionsHistoryRequest بود:Actor به درخواست پاسخ می‌دهدپاسخ شامل شیئی از نوع PositionBatch است که شامل کل تاریخچه موقعیت‌هاستreturn Task.CompletedTask;این متد async است و باید یک Task برگرداندچون عملیات ما ساده و کوتاه است، یک CompletedTask کفایت می‌کندجمع‌بندی کارکرد کلی BusActor به صورت متنیوقتی یک پیام موقعیت جدید (Position) دریافت می‌شود، بازیگر لیست موقعیت‌های قبلی را بررسی می‌کند و فقط موقعیت‌هایی که در ۵ دقیقه‌ی گذشته ثبت شده‌اند را نگه می‌دارد. سپس، موقعیت جدید را به این لیست اضافه می‌کند.وقتی یک پیام درخواست تاریخچه (GetPositionsHistoryRequest) دریافت می‌شود، بازیگر به آن پاسخ می‌دهد و لیست موقعیت‌های فعلی را به‌صورت یک شیء جدید از نوع PositionBatch ارسال می‌کند.تمام ذخیره‌سازی داده‌ها فقط در حافظه انجام می‌شود. هیچ دیتابیسی در کار نیست، بنابراین خواندن و نوشتن اطلاعات بسیار سریع انجام می‌شود.پردازش پیام‌ها به‌صورت تک‌ریسمانی (single-threaded) انجام می‌شود، به همین دلیل هیچ مشکلی از نوع رقابت هم‌زمانی (concurrency) وجود ندارد. این یعنی نیازی به قفل‌گذاری یا مدیریت حالت پیچیده نیست.هر نمونه از BusActor فقط نماینده‌ی یک اتوبوس خاص است و کاملاً ایزوله عمل می‌کند. بازیگرها به‌طور مستقل رفتار می‌کنند و وضعیت‌شان را فقط خودشان تغییر می‌دهند.این بازیگرها می‌توانند در سیستم‌های توزیع‌شده روی نودهای مختلف یک خوشه (cluster) توزیع شوند، بدون اینکه تغییری در کد نیاز باشد.این ساختار به راحتی امکان مدیریت هزاران یا حتی میلیون‌ها بازیگر (مثل اتوبوس‌های مختلف) را فراهم می‌کند، درحالی‌که معماری ساده، قابل فهم و توسعه‌پذیر باقی می‌ماند.ماندگاری (Persistence)در بسیاری از موارد، اینکه فقط وضعیت بازیگر (Actor) در حافظه نگه‌داری شود، قابل‌قبول نیست.ما نیاز داریم که وضعیت بازیگر در برابر اتفاقاتی مثل ری‌استارت شدن ماشین، ارتقاء نرم‌افزار یا خاموشی‌ها، حفظ شود.اما از طرفی، قبلاً گفتیم که پردازش Actor خیلی سریع است چون کاملاً در حافظه انجام می‌شود.آیا این دو گزاره با هم تناقض دارند؟پاسخ: خیر، تضادی نیست. راه‌حل، ذخیره‌سازی هوشمند است.در عمل، بسیار رایج است که وضعیت بازیگرها در نوعی ذخیره‌ساز پایدار (persistent storage) نگهداری شود.ترجیحاً باید از دیتابیس‌هایی با عملکرد بالا استفاده شود، مثل:RedisAzure Table StorageGoogle Bigtableاما نکته‌ی مهم اینجاست:باید به وضعیت ذخیره‌شده، به‌چشم یک "تصویر لحظه‌ای (snapshot)" یا "بک‌آپ" نگاه کرد، نه به‌عنوان داده‌ی عملیاتی اصلی.نحوه‌ی استفاده:وضعیت بازیگر فقط زمانی بارگذاری می‌شود که بازیگر برای اولین‌بار در حافظه ایجاد می‌شود.نیازی نیست قبل از پردازش هر پیام، دوباره داده را از دیتابیس بخوانیم (برخلاف برنامه‌های stateless معمول).همین ویژگی به‌تنهایی می‌تواند تا ۵۰٪ از زمان صرف‌شده برای عملیات I/O را حذف کند.ضمناً:وضعیت موجود در حافظه، مرجع اصلی (source of truth) است، نه فقط یک cache موقت.بنابراین مشکلی به نام "همگام‌سازی کش (cache invalidation)" نخواهیم داشت.نوشتن وضعیت (Write Strategy):شما در ذخیره‌سازی وضعیت، انعطاف زیادی دارید. می‌تونید تصمیم بگیرید که:بعد از هر پیام، یک نسخه‌ی پشتیبان از وضعیت گرفته شود.یا پس از دریافت تعداد مشخصی پیامیا مثلاً هر چند دقیقه یک‌بار (بک‌آپ دوره‌ای)انتخاب این روش بستگی به نیازهای برنامه‌ی شما دارد.ارتباط (Communication)ارتباط در مدل Actor بسیار ساده اما قدرتمند است.شما می‌توانید از:کلاینتیا یک Actor دیگربه یک بازیگر پیام بفرستید، صرفاً با قرار دادن پیام در صف پیام‌های آن (message queue).این ارتباط به‌صورت ذاتی ناهمزمان (asynchronous) است.اما بعضی فریم‌ورک‌ها این ارتباط را با استفاده از APIهایی بر پایه‌ی:Task در .NETیا Promise در JavaScript و سایر زبان‌هاساده‌تر می‌کنند، به‌طوری‌که می‌توانید منتظر پاسخ بمانید، بدون اینکه ساختار برنامه‌تان پیچیده شود.در کد، ارتباط با بازیگر چطور انجام می‌شود؟شما معمولاً یک ارجاع (handle) به بازیگر موردنظر دارید و از طریق آن پیام می‌فرستید.مثلاً: ارسال پیام به بازیگر یک سازمان خاص.context.Send(OrganizationActorePid, position);در ادامه مقاله، یاد می‌گیریم که چطور حتی نیاز به نگه داشتن این ارجاع را هم حذف کنیم—که بخشی از قدرت مدل بازیگرهای مجازی است.سلسله‌مراتب بازیگرها (Actor Hierarchies)اگه مدل بازیگر (Actor Model) رو در گوگل یا هر موتور جستجو جستجو کنی،خیلی زود با نمودارهای پیچیده‌ای از سلسله‌مراتب بازیگرها مواجه می‌شی.مثلاً مثل این تصویر:چرا این نمودارها پیچیده هستند؟در مدل سنتی Actor:بازیگرها می‌تونند بازیگرهای فرزند (child actors) ایجاد کنند.مسئولیت چرخه‌ی عمر (lifecycle) بازیگرهای فرزند به عهده‌ی والد است.در صورت بروز خطا در زنجیره، Actor پدر مسئول رسیدگی به خطاهاست.اغلب استراتژی‌های خاصی برای مدیریت خطا (مثل بازنشانی، نادیده گرفتن یا جایگزینی) اعمال می‌شود.اما:ارتباط بین این سلسله‌مراتب‌ها، اگر روی ماشین‌های مختلف اجرا شوند، ساده و مستقیم نیست.خبر خوبدر بسیاری از برنامه‌های واقعی و مدرن،نیازی به این سطح از پیچیدگی وجود ندارد.مدل ساده‌تری هم هست که همان مزایا را دارد، ولی پیچیدگی‌ها را حذف می‌کند.ادامه مقاله: مدل بازیگرهای مجازی (Virtual Actor Model)در بخش بعدی مقاله، وارد دنیای بازیگرهای مجازی می‌شویم—جایی که:نیازی به مدیریت ارجاع مستقیم به Actorها نیستمدیریت حافظه، ماندگاری، مقیاس‌پذیری و ساختار Actorها به‌طور کامل خودکار و ساده‌سازی شده استبازیگرهای مجازی (Virtual Actors)بازیگرهای مجازی یا همان Grains این‌طور فرض می‌شوند که همیشه وجود دارند.شما هیچ‌گاه لازم نیست آن‌ها را به‌طور دستی ایجاد (create) یا حذف (destroy) کنید.این بازیگرها ممکن است در لحظه:در حافظه فعال باشند،یا غیرفعال شده باشند (مثلاً برای صرفه‌جویی در منابع).اما از دید کلاینتی که می‌خواهد با آن ارتباط برقرار کند، این تفاوت هیچ اهمیتی ندارد.تنها کاری که انجام می‌دهید، این است که یک پیام برای آن Actor می‌فرستید،و فریم‌ورک بازیگر مجازی به‌صورت خودکار اطمینان حاصل می‌کند که آن Actor فعال شده و آماده دریافت پیام است.شناسایی Actor چگونه انجام می‌شود؟در این مدل:نیازی به نگه‌داشتن اشاره‌گر (handle) یا ریفرنس مستقیم به Actor ندارید.به‌جای آن، مقصد پیام را بر اساس "نوع (type)" و "شناسه (id)" مشخص می‌کنید.یعنی می‌گویید:"می‌خوام با Actor نوع OrganizationActor با شناسه 42 صحبت کنم"نه اینکه یک متغیر به‌خصوص از اون Actor رو از قبل داشته باشید.خوشه‌بندی (Clustering)ویژگی‌هایی که در بالا توضیح دادیم باعث می‌شن مدل Actor مجازی به‌صورت شفاف (transparent) در سراسر چندین ماشین مقیاس‌پذیر باشد.یعنی:مکان Actor مهم نیست.تا زمانی که نوع و شناسه‌ی آن را بدانید، می‌توانید پیام بفرستید.فریم‌ورک به‌صورت خودکار پیام را به مکان درست مسیریابی (route) می‌کند.حتی اگر Actor به دلیل مثلا خاموش شدن نود، به مکان جدیدی منتقل شود (migrate)،کلاینت همچنان می‌تواند با آن بدون هیچ مشکلی ارتباط برقرار کند.نتیجه این رویکرد چیست؟این مدل، در عین اینکه ساده و قابل درک است،انعطاف‌پذیری و قدرت بالایی در مقیاس‌پذیری و توزیع‌شدگی در اختیار شما می‌گذارد—بدون اینکه مدل برنامه‌نویسی پیچیده شود.ابزارها و فریم‌ورک‌هادر دنیای .NET، چند فریم‌ورک محبوب برای پیاده‌سازی مدل Actor مجازی وجود دارند:OrleansProto.ActorAkka.NETهمچنین بخش‌هایی از Daprموارد استفاده (Use Cases)به‌طور کلی، زمانی که برنامه‌ی شما با تعداد زیادی موجودیت کوچک (small entities) سروکار دارد که:هرکدام منطق خودش را اجرا می‌کندو وضعیت خودش را به‌صورت ایزوله مدیریت می‌کندمدل Actor می‌تواند انتخاب بسیار مناسبی باشد.برای مثال‌های مشخص‌تر، اینجا چند مورد از کاربردهای متداول آورده شده است:مدل‌سازی یک دستگاه به‌عنوان Actor با منطق آلارم، قوانین و آستانه‌هادوقلوهای دیجیتال (Digital Twins) برای اشیاء فیزیکیمدیریت تعاملات کاربران به‌صورت پیام بین Actorهاجمع‌آوری و تحلیل جریان‌های داده به‌صورت نقشه‌کاهش (MapReduce)پیگیری وضعیت بازی‌ها، بازیکنان، اشیاء، منابع و امتیازهاسیستم‌های Matchmaking (مانند بازی‌های آنلاین)توزیع وظایف میان نودهای پردازشی مختلفوظایفی که به اجرای مستقل نیاز دارند و باید با هم تبادل اطلاعات داشته باشندنتیجه‌گیریمدل بازیگرهای مجازی (Virtual Actor Model)یک رویکرد قدرتمند و اثبات‌شده برای ساخت برنامه‌های توزیع‌شده است.با این مدل می‌توانید برنامه‌هایی بسازید که:کارایی بالا داشته باشنددر مقیاس بزرگ توزیع‌شده اجرا شوندو با همان ابزارهایی که هم‌اکنون با آن‌ها آشنایی دارید، توسعه پیدا کننددر پایان، باید گفت که مدل بازیگر، به‌ویژه در قالب بازیگرهای مجازی، فرصتی منحصربه‌فرد برای طراحی و توسعه‌ی معماری نرم‌افزار پیشرفته در اختیار تیم‌های نرم‌افزاری قرار می‌دهد. چه در حال ساخت یک سامانه‌ی مبتنی بر سیستم‌های توزیع‌شده باشید، چه در مسیر پیاده‌سازی توسعه نرم‌افزار مقیاس‌پذیر یا سرویس‌های بلادرنگ، این رویکرد می‌تواند به‌سادگی پیچیدگی‌ها را کاهش دهد.در آینده، به‌ویژه با رشد ابزارهایی مانند Proto.Actor در دنیای دات‌نت، استفاده از مفاهیمی مانند مدل بازیگر در نرم‌افزار به یکی از استانداردهای طراحی سیستم‌های بزرگ تبدیل خواهد شد. اگر به دنبال یادگیری عمیق‌تر، مشاوره یا اجرای پروژه‌هایی در این حوزه هستید، خوشحال می‌شویم در شرکت راهکار نگار هوشمند (آرکان) همراه شما باشیم.این مقاله با هدف آگاهی‌بخشی توسط تیم توسعه‌ی نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#سیستم_توزیع_شده#بازیگر_مجازی#توسعه_نرم_افزار#مشاوره_نرم_افزار#معماری_میکروسرویس#برنامه_نویسی#دات_نت#proto_actor#Orleans#cloud_native#IoT#real_time#نرم_افزار_سفارشی#شرکت_راهکار_نگار_هوشمند#arcanco

نظرتون درباره تست نویسی چیه؟ بیاید یه چالش راه بندازیم و این هیولای دوستداشتنی رو اهلی کنیم!

Mostafa Akbarizadeh — Mon, 09 Dec 2024 20:36:01 +0330
بیاید راستشو بگیم، وقتی حرف از تست‌نویسی می‌شه، بیشترمون قیافه می‌گیریم انگار یکی گفته "بیا ظرف‌ها رو بشور!" یه سری می‌گن: "وقت نداریم"، یه سری دیگه: "این واسه پروژه‌های خیلی بزرگه" و بعضیا هم کلاً: "حال نداریم." ولی خب، اگه تا حالا تو یه تیم فنی یا پروژه شخصی بودی، می‌دونی که بدون تست، هر تغییر کوچیک ممکنه مثل دومینوی خرابکاری همه چیز رو بریزه بهم!واقعیت اینه که ما تست‌نویسی رو جدی نمی‌گیریم چون بیشتر حواسمون به اینه که پروژه رو سریع تحویل بدیم، نه اینکه مطمئن باشیم بعدش زندگی آسون‌تری داریم. اما صبر کن! بیاید یه نگاهی به Unit Testing بندازیم و ببینیم چرا انقدر مهمه و چطوری می‌تونه کارمون رو متحول کنه.Unit Testing – Software Testingتست واحد (Unit Testing) چیه؟تصور کن داری یه ماشین می‌سازی. قبل از اینکه کل ماشین رو سرهم کنی، میای تک‌تک قطعاتش رو تست می‌کنی. چرخ‌ها رو می‌چرخونی، فرمان رو تکون می‌دی، مطمئن می‌شی ترمز درست کار می‌کنه. چرا؟ چون نمی‌خوای وسط جاده بفهمی یه جای کار می‌لنگه، درسته؟تست واحد هم همینه! یعنی هر بخش کوچیکی از کدت (مثل یه تابع، یه متد یا یه کلاس) رو جداگانه تست می‌کنی و می‌بینی همون‌طور که باید، کار می‌کنه. انگار داری به این قطعه کوچیک از کدت یه مُهر تضمین می‌زنی و می‌گی: "آی مردم! من مطمئنم که این بچه هر وقت اجرا بشه، یه چیزی رو خراب نمی‌کنه!" 😄چطوری باید تست واحد بنویسیم؟۱.توسعه مبتنی بر تست Test-Driven Development (TDD): این سبک رو وقتی دوست داری که می‌خوای خیلی شسته‌رفته کار کنی. اول تست می‌نویسی و بعد کد. شاید به نظرت عجیب بیاد، ولی این روش باعث می‌شه کمتر کد بزنی، چون دقیقاً می‌دونی چی می‌خوای.۲. شبیه‌سازی (Mocking): فرض کن داری یه سیستم پیچیده رو تست می‌کنی، ولی نمی‌خوای همه‌چیز رو بیاری تو تستت. اینجا از Mock استفاده می‌کنی؛ یعنی یه نسخه الکی (اما هوشمند) از قسمت‌هایی که نیاز داری، می‌سازی.۳. آزمون هرم (Pyramid Testing): این استراتژی می‌گه بیشتر تمرکزت روی تست‌های واحد باشه، بعد برو سراغ تست یکپارچه سازی(Integration) و بعد End-to-End. انگار داری یه هرم می‌سازیخب واقعاً چرا باید تست بنویسیم؟ بذار چند تا دلیل خفن برات بیارم:1. کیفیت بالا:با تست واحد، مطمئن می‌شی که هر تغییر کوچیکی تو کدت، سیستم رو به فنا نمی‌ده. یه جورایی خیال خودت و تیمت رو راحت می‌کنی که همه چیز سر جاشه.2. کمتر شدن باگ‌ها:تست‌نویسی دقیقاً مثل واکسن زدنه. شاید اولش وقت و انرژی بگیره، ولی بعداً جلوی مریضی‌های سنگین رو می‌گیره. باور کن پیدا کردن یه باگ تو محیط تولید مثل درمان سرماخوردگی نیست، بیشتر شبیه جراحی قلب بازه!3. اعتمادبه‌نفس:وقتی همه تست‌ها سبز بشن، حس می‌کنی یه ابرقهرمانی که می‌تونه با یه دست کد بزنه و با دست دیگه دنیا رو نجات بده. انگار کدت داره بهت می‌گه: "من آماده‌ام، بزن بریم!"4. سرعت در توسعه:شاید اولش فکر کنی تست‌نویسی سرعتت رو کم می‌کنه، ولی در درازمدت کمک می‌کنه کمتر وقتت رو روی رفع مشکلات تکراری بذاری و با خیال راحت پیش بری. مثل اینه که اول مسیر یه پلی بسازی تا لازم نباشه هر بار از رودخونه شنا کنی!همون‌طور که هر چیز خوبی یه سری چالش داره، تست‌نویسی هم بی‌ایراد نیست. بیایید منصف باشیم:1. وقت‌گیر:تست‌نویسی زمان می‌بره، مخصوصاً وقتی تیمت کوچیک باشه یا تحت فشار باشی که پروژه رو سریع تحویل بدی. انگار داری برای یه ماراتن آماده می‌شی، ولی کارفرما می‌خواد صد متر رو همون لحظه بدوی!2. نیاز به دانش فنی:نوشتن تست خوب، خودش یه هنره. مثل رانندگی نیست که با آزمون و خطا یادش بگیری؛ باید برایش وقت بذاری و یاد بگیری چی کجا تست بشه. اوایل شاید کمی چالش‌برانگیز باشه، ولی وقتی یاد بگیری، دیگه به کارت نمی‌آدازن.3. پوشش محدود:تست‌های واحد همه مشکلات رو نمی‌گیرن. مثل اینه که فقط چرخ‌های ماشین رو چک کنی، ولی موتور رو ندیده بگیری. برای اینکه همه چیز رو پوشش بدی، به تست‌های دیگری مثل Integration و End-to-End نیاز داری.کجاها Unit Testing کم‌فایده‌ست؟حقیقت اینه که تست‌نویسی همیشه هم راه‌حل مناسبی نیست. بعضی مواقع بهتره بدون دردسر پیش بری. مثلاً:1. پروژه‌های کوچیک:اگه پروژه کوچیکه و تغییراتش محدود، شاید نوشتن تست اصلاً ارزش وقت گذاشتن نداشته باشه. برای این جور مواقع، شاید به جای وقت گذاشتن روی تست‌ها، بهتر باشه سریع‌تر کد رو بنویسی و تمامش کنی.2. تیم‌های کوچک با منابع محدود:وقتی تیم کوچیکی داری و منابع (یعنی آدم و زمان) هم محدود، تست‌نویسی ممکنه اولویت بالایی نداشته باشه. در این شرایط باید انتخاب کنی که کجاها بیشتر به کار میاد و کجا می‌تونی فشاری که رو دوش تیم هست رو کمتر کنی.3. ددلاین‌های سنگین:وقتی مشتری می‌خواد "دیروز پروژه رو تحویل بگیره"، تست‌نویسی معمولاً می‌ره تو لیست اولویت‌ها و سقوط آزاد می‌کنه! این مواقع بیشتر دنبال تحویل سریع و بدون دردسر هستی تا اینکه بخوای وارد جزئیات تست بشی.تست‌نویسی همیشه عالی نیست، اما در خیلی از شرایط می‌تونه مثل یه ابرقهرمان عمل کنه که جلوی فاجعه‌ها رو می‌گیره.تجربه شخصیتو یکی از پروژه‌های بزرگ، تست‌نویسی رو جدی نگرفتیم. نه تنها تیم، بلکه بیشتر بچه‌ها اصلاً تسلط کاملی هم روی تست‌نویسی نداشتن. به عنوان یه تیم فنی همیشه فکر می‌کردیم که هر چی سریع‌تر پیش بریم و پروژه رو تموم کنیم، بهتره. درسته که پروژه بزرگ بود، ولی چون فکر می‌کردیم وقت نداریم، تست‌نویسی رو کنار گذاشتیم. نتیجه؟ هر بار که یه آپدیت جدید می‌دادیم، به جای اینکه فقط یه مشکل رو حل کنیم، یه عالمه مشکل دیگه هم از دلش بیرون می‌اومد!از اونجایی که ردیابی خطاها تو محیط پروداکشن یه مصیبت عظمایی که همه شما تجربه‌شو داشتین، این وضعیت برامون تبدیل به یه درس عبرت بزرگ شد. حس کردیم که این اشتباه، نه تنها کیفیت پروژه رو پایین آورد، بلکه زمان زیادی از تیم رو هم تلف کرد.

چرا Cohesion (یکپارچگی) و Coupling (وابستگی) مهم‌اند؟

Mostafa Akbarizadeh — Sun, 08 Dec 2024 07:57:15 +0330
Differences between Coupling and Cohesionتوی دنیای نرم‌افزار، همیشه یکسری اصول پایه‌ای بودن که شاید به ظاهر ساده و پیش‌پاافتاده به نظر برسن، ولی اگر عمیق‌تر نگاه کنیم، این اصول ستون‌های پنهان هر سیستم نرم‌افزاری قدرتمندن. مشکل اینجاست که این اصول اون‌قدر عادی شدن که خیلی از مهندسان نرم‌افزار کمتر بهشون توجه می‌کنن، یا بهتره بگم، مغفول می‌مونن.حالا چرا این موضوع مهمه؟ چون همین غفلت از اصول می‌تونه مثل یه بمب ساعتی عمل کنه و هر لحظه پروژه نرم‌افزاری شما رو به نابودی بکشونه. خیلی از Legacy System‌هایی که الان باهاشون دست‌وپنجه نرم می‌کنیم، دقیقاً به‌خاطر رعایت نکردن همین اصول به این حال‌وروز افتادن. باگ‌های عجیب، کدهای غیرقابل نگهداری، و سیستم‌هایی که به محض لمس شدن، مثل برج جِنگا فرو می‌ریزن، همه از این درد رنج می‌برن.حالا شاید بپرسین، این اصول چی هستن که این‌قدر مهمن؟ اجازه بدید وقتتون رو زیاد نگیرم و بریم سر اصل ماجرا. اینجا قراره با دو استاد بزرگ طراحی نرم‌افزار آشنا بشیم: Cohesion و Coupling. شاید اسمشون ساده به نظر بیاد، ولی این دو استاد طوری حرفه‌ای بازی می‌کنن که حتی باتجربه‌ترین مهندسان هم گاهی تو دامشون می‌افتن.پس بیاید این دو مفهوم کلیدی رو مثل دوستای قدیمی بشناسیم، چالش‌هاشون رو درک کنیم، و یاد بگیریم چطور با احترام و هوشمندی در کنار این دو، یه سیستم نرم‌افزاری بی‌نقص طراحی کنیم. 😉تصور کنید در حال طراحی یک نرم‌افزار بزرگ هستید؛ مثل یک فروشگاه اینترنتی یا یک سیستم مدیریت کتابخانه. این سیستم‌ها از بخش‌های مختلفی تشکیل شده‌اند که باید باهم کار کنند، اما اگر این بخش‌ها خیلی به هم وابسته باشند (یعنی یک تغییر کوچک در یکی از آن‌ها باعث شود کل سیستم به هم بریزد) یا اگر هر بخش خودش نداند دقیقا چه‌کار می‌کند، این پروژه تبدیل به یک کابوس واقعی می‌شود!اینجاست که دو مفهوم بسیار مهم به نام‌های Cohesion (یکپارچگی) و Coupling (وابستگی) وارد ماجرا می‌شوند.یکپارچگی Cohesion به ما می‌گوید که هر بخش از نرم‌افزار (یا ماژول) باید چقدر منسجم و یکپارچه باشد. چسبندگی Coupling نشان‌دهنده این است که ماژول‌ها چقدر به هم وابسته‌اند.هدف اصلی ما این است که Cohesion را تا می‌توانیم بالا ببریم و Coupling را تا حد ممکن پایین نگه داریم. حالا بیایید باهم ببینیم که این مفاهیم چه هستند و چرا این‌قدر مهم‌اند.مفهوم Cohesion: خودکفا و منظمیکپارچگی (Cohesion) یعنی عناصر داخل یک ماژول چقدر خوب با هم کار می‌کنند تا یک هدف مشخص را محقق کنند. وقتی می‌گوییم یک ماژول "High Cohesion" دارد، یعنی تمام عناصر آن فقط و فقط روی یک هدف مشخص تمرکز دارند. از طرف دیگر، اگر ماژولی "Low Cohesion" داشته باشد، یعنی درون خودش چند کار مختلف انجام می‌دهد که ممکن است به هم بی‌ربط باشند.مثال: ماژول مدیریت کاربرانفرض کنید یک سیستم داریم که ماژولی به نام "User Management" دارد. این ماژول کارهایی مثل ثبت‌نام (Register)، ورود (Login)، و خروج (Logout) را انجام می‌دهد. حالا تمام این عملیات‌ها حول محور یک هدف خاص یعنی مدیریت کاربران می‌چرخند. این یعنی High Cohesion.اما اگر همین ماژول بخواهد هم مدیریت کاربران انجام دهد، هم محصولات را اضافه کند، و هم گزارش‌های مالی تولید کند، در این حالت با یک ماژول "Low Cohesion" روبه‌رو هستیم. این وضعیت باعث می‌شود نه‌تنها فهمیدن کد سخت‌تر شود، بلکه تغییرات هم به‌راحتی ممکن است مشکلات جدیدی ایجاد کنند.مفهوم Coupling: وابستگی یا استقلال؟حالا بیایید به Coupling نگاه کنیم. Coupling یعنی اینکه دو ماژول چقدر به هم وابسته‌اند. اگر تغییر در یک ماژول باعث شود ماژول دیگر هم نیاز به تغییر داشته باشد، به این حالت High Coupling می‌گوییم. اما اگر ماژول‌ها مستقل از هم عمل کنند، این به معنای Low Coupling است.مثال: ماژول‌های کتاب و اعضا در یک کتابخانهفرض کنید یک سیستم کتابخانه داریم. دو ماژول داریم:ماژول مدیریت کتاب‌ها (Book Management): اضافه کردن و حذف کتاب.ماژول مدیریت اعضا (Member Management): اضافه کردن و حذف اعضا.این دو ماژول مستقل عمل می‌کنند و تغییر در یکی باعث نمی‌شود دیگری به مشکل بخورد. مثلا، اگر فرایند اضافه کردن کتاب تغییر کند، هیچ اثری روی فرایند اضافه کردن اعضا ندارد. این یعنی Low Coupling. اما اگر این دو ماژول برای کار کردن کاملا به هم متکی باشند، مثلا هر تغییری در مدیریت اعضا باعث شود کد مدیریت کتاب‌ها هم تغییر کند، این یعنی High Coupling.تفاوت‌های کلیدی بین Cohesion و Couplingبرای درک بهتر این دو مفهوم، بیایید تفاوت‌های اصلی‌شان را بررسی کنیم:Difference Between Cohesion and Couplingچرا High Cohesion و Low Coupling مهم است؟وقتی Cohesion بالا و Coupling پایین دارید:نگهداری و توسعه راحت‌تر است.تغییر در یک بخش باعث خراب شدن بخش‌های دیگر نمی‌شود.تست‌پذیری بهتر است.ماژول‌ها را می‌توان به‌صورت جداگانه تست کرد.درک کد ساده‌تر می‌شود.هر ماژول یک هدف مشخص دارد و دیگر نیازی به بررسی وابستگی‌های پیچیده نیست.انواع Cohesion و Couplingحالا که فهمیدیم Cohesion و Coupling چقدر مهم هستند، وقتشه کمی عمیق‌تر بشیم و انواع هر کدوم رو بررسی کنیم. این بخش مثل نقشه‌ایه که شما رو راهنمایی می‌کنه چطور ماژول‌هاتون رو طراحی کنید. هر نوع رو با مثال توضیح می‌دم که موضوع حسابی جا بیافته.انواع Cohesion: از بدترین تا بهترین! یکپارچگی (Cohesion) به ۷ نوع تقسیم می‌شه که از خیلی ضعیف شروع می‌شه و به خیلی قوی ختم می‌شه حالا بریم سراغ انواعش1.تصادفی (Coincidental Cohesion)وقتی عناصر یک ماژول هیچ ارتباط منطقی‌ای با هم ندارن و صرفا از روی شانس کنار هم جمع شدن.مثال: ماژولی دارید که توش هم یک فایل می‌سازید، هم به کاربر ایمیل می‌فرستید، هم یه API رو صدا می‌زنید. این‌ها هیچ ارتباطی به هم ندارن، ولی به‌صورت تصادفی کنار هم جمع شدن.مشکل: مثل گذاشتن سیب‌زمینی، کفش، و لپ‌تاپ توی یه کشو. بی‌ربط و گیج‌کننده!2. منطقی (Logical Cohesion)وقتی عناصر یک ماژول کارهای مرتبط انجام می‌دن ولی انتخاب کار به یک شرط منطقی وابسته‌ست.مثال: یک ماژول دارید که بسته به ورودی، یا به فایل می‌نویسه یا ایمیل ارسال می‌کنه یا دیتابیس رو به‌روز می‌کنه.مشکل: وابستگی به ورودی باعث می‌شه که فهمیدن کد و نگهداریش سخت بشه.3. زمانی (Temporal Cohesion)وقتی عناصر یک ماژول کارهایی رو انجام می‌دن که در یک زمان خاص باید انجام بشه.مثال: یک ماژول که وقتی کاربر لاگین می‌کنه، کوکی رو ذخیره می‌کنه، لاگ رو ثبت می‌کنه، و تاریخچه رو آپدیت می‌کنه.مشکل: این کارها به زمان وابسته هستن، نه به هدف مشخص.4. رویه‌ای (Procedural Cohesion)وقتی عناصر ماژول به‌خاطر ترتیب و مراحل خاصی کنار هم هستن.مثال: ماژولی که اول داده‌ها رو بخونه، بعد اعتبارسنجی کنه، و بعد اون‌ها رو در دیتابیس ذخیره کنه.مشکل: هنوز هدف مشخصی دیده نمی‌شه؛ فقط رویه مشخصه.5. ارتباطی (Communicational Cohesion)وقتی عناصر ماژول با استفاده از داده‌های مشترک کارهای متفاوتی انجام می‌دن.مثال: ماژولی که برای یک سفارش، هم تخفیف محاسبه می‌کنه و هم مالیات رو.مشکل: بهتره این دو کار رو جدا کنیم؛ چون هر دو به داده سفارش نیاز دارن، اما هدف متفاوتی دارن.6. کارکردی (Functional Cohesion)وقتی همه عناصر ماژول برای رسیدن به یک هدف خاص کار می‌کنن.مثال: ماژول محاسبه قیمت نهایی که تخفیف، مالیات، و هزینه حمل‌ونقل رو با هم ترکیب می‌کنه.مزیت: بهترین نوع Cohesion که باعث نظم و استقلال ماژول می‌شه.7. توالی‌ای (Sequential Cohesion)وقتی خروجی یک عنصر مستقیماً ورودی عنصر دیگه باشه.مثال: ماژول پردازش تصویر که اول تصویر رو بخونه، بعد فشرده کنه، و بعد ذخیره کنه.مزیت: نزدیک به Functional Cohesion و بسیار مناسب.انواع Coupling: از بدترین تا بهترین!حالا بریم سراغ Coupling. این مفهوم هم به انواع مختلفی تقسیم می‌شه که از خیلی وابسته شروع می‌شه و به مستقل‌ترین حالت ختم می‌شه.1. محتوایی (Content Coupling)وقتی یک ماژول مستقیم به کد داخلی ماژول دیگه دسترسی داره.مثال: ماژول A مستقیماً یک متغیر خصوصی (Private) در ماژول B رو تغییر بده.مشکل: این بدترین نوع Coupling هست. تغییر در یکی، کل سیستم رو خراب می‌کنه.2. اشتراکی (Common Coupling)وقتی دو ماژول از یک متغیر یا منبع مشترک استفاده می‌کنن.مثال: دو ماژول به یک متغیر Global دسترسی دارن و مقدارش رو تغییر می‌دن.مشکل: شبیه به دعوا سر کنترل تلویزیون؛ هرکی کانال رو عوض کنه، بقیه شاکی می‌شن.3. بیرونی (External Coupling)وقتی دو ماژول به یک واسط یا سیستم خارجی وابسته باشن.مثال: ماژول پرداخت آنلاین و ماژول سفارش که هردو به یک Gateway پرداخت وابسته هستن.مشکل: وابستگی به ابزار خارجی می‌تونه خطرساز باشه.4.کنترلی (Control Coupling)وقتی یک ماژول به ماژول دیگه بگه دقیقاً چه کاری انجام بده.مثال: ماژول A به ماژول B یک Flag بفرسته که بگه با این مقدار خاص کار کن.مشکل: تغییرات در Flag نیازمند تغییر در هر دو ماژول هست.سؤال چالش‌برانگیز: آیا می‌شود همه‌چیز ایده‌آل باشد؟خب، حقیقت این است که همیشه نمی‌توان به Low Coupling و High Cohesion به‌طور کامل دست یافت. گاهی وابستگی‌هایی بین ماژول‌ها وجود دارند که اجتناب‌ناپذیرند. اما هدف این است که این وابستگی‌ها را تا جای ممکن کاهش دهیم.جمع‌بندیبه‌طور خلاصه، Cohesion و Coupling دو مفهوم کلیدی در طراحی نرم‌افزار هستند که اگر درست رعایت شوند، می‌توانند سیستم‌های نرم‌افزاری ما را قابل‌اعتمادتر، مقیاس‌پذیرتر و آسان‌تر برای نگهداری کنند. در طراحی‌های بعدی‌تان، همیشه تلاش کنید ماژول‌هایتان را با Cohesion بالا و Coupling پایین طراحی کنید. این کار، مثل استفاده از یک دستور آشپزی دقیق، نتیجه کار را خوشمزه‌تر می‌کنه! 😄

چرا جمع‌آوری نیازمندی‌ها این‌قدر مهم است؟ یک گپ دوستانه با شما!

Mostafa Akbarizadeh — Sat, 07 Dec 2024 09:52:30 +0330
Requirements Gathering in Software Developmentسلام دوستان عزیزم ! بذارین یه داستان براتون تعریف کنم که شاید پروژه بعدیتون از کلی دردسر نجاتتون بده. موضوعش Requirements Gathering یا همون جمع‌آوری نیازمندی‌هاست. نترسین، قول میدم خشک و کسل‌کننده نباشه. می‌خوام بگم چرا این مرحله اونقدر مهمه که می‌تونه یه پروژه رو از موفقیت به فاجعه برسونه یا بالعکس. آماده‌ای؟ بزن بریم!مرحه اول: Identify Stakeholders – کی کیه؟خب اول از همه، باید بفهمیم چه کسایی از پروژه استفاده می‌کنن و چه کسایی قراره نظر بدن. از کاربر نهایی گرفته تا مدیر پروژه، همه باید تو این مرحله صداشون شنیده بشه.تصورش کنین: دارین یه برنامه مدیریت محتوا (CMS) طراحی می‌کنیم. Content Creators هامی‌خوان محیط کاربری ساده باشه، Editor ها دنبال تأیید محتوا قبل از انتشارن، و تیم IT هم می‌خواد زیرساخت قوی باشه. هر کسی یه چیزی می‌خواد و اینجاست که همه رو دور یه میز می‌نشونیم.مرحله دوم: Define Objectives and Scope – چی می‌خوایم بسازیم؟تو این مرحله، باید دقیقاً مشخص کنیم هدف سیستم چیه و پروژه قراره چه کارایی انجام بده.اینجا مثل اینه که داری نقشه گنج می‌کشیم. اگه ندونیم دنبال چی می‌گردیم، سر از ناکجاآباد در میاریم! به عبارتی، Define clear objectives and scope تا پروژه از مسیرش خارج نشه.مرحله سوم: Conduct Interviews and Workshops – بزن بریم مصاحبه!حالا وقتشه که بریم سراغ ذینفع‌ها و باهاشون صحبت کنیم. باهاشون مصاحبه کنیم، ورکشاپ راه بندازیم یا حتی یه فنجون چای بخوریم و گپ بزنیم! تو این مرحله، باید بفهمیم واقعاً چی می‌خوان. سوالات باز بپرسیم تا چیزی رو از قلم نندازیم. اینجا می‌خواییم با تکنیک‌های Interviews and Workshops حرفای دلشون رو بخونیم. 😉مرحله چهارم: Document Requirements – همه چیزو بنویس!حالا که اطلاعات جمع شد، وقتشه همه چیزو مرتب و مستند کنیم. می‌تونیم از Use Cases، User Stories، یا حتی Functional Requirements Specifications (FRS) و Non-Functional Requirements Specifications (NFRS) استفاده کنیم.اینو یادتون باشه: مستندات باید واضح، مختصر و بدون ابهام باشن، وگرنه وسط پروژه داد همه درمیاد که «این چیزی نبود که ما می‌خواستیم!»مرحله پنجم: Prioritize Requirements – چی از همه مهم‌تره؟وقتی همه چیزو نوشتیم، وقتشه که نیازمندی‌ها رو اولویت‌بندی کنیم. از تکنیک‌هایی مثل MoSCoW Prioritization استفاده کنیم:Must have: بدون ایناها سیستم فایده‌ای نداره.Should have: خیلی مهمن ولی بدونش هم می‌تونیم زندگی کنیم.Could have: اگه بود خوبه، اگه نبود هم کسی شکایت نمی‌کنه.Won’t have: باشه برای بعد!مرحله ششم: Validate Requirements – یه دور چک کنیم!الان وقتشه که هر چی نوشتیم رو با ذینفع‌ها چک کنیم. اگه اختلاف نظر یا ابهامی هست، همین حالا حلش کنیم. یه Validation Session خوب می‌تونه کلی دردسر آینده رو کم کنه. حتماً مطمئن بشیم که نیازمندی‌ها ، نیاز واقعی و دقیق رو منعکس می‌کنند.مرحله هفتم: Iterate and Refine – تا می‌تونی بهترش کنیم!یه نکته طلایی: جمع‌آوری نیازمندی‌ها خط صاف نیست؛ بیشتر شبیه یه مسیر پرپیچ‌وخم و پر ماجراست. پس آماده باشیم که چندین بار Iterate and Refine کنیم. هیچ‌وقت نگا نکنیم که این تغییرات نشونه ضعف هستن؛ نشونه اینه که پروژه داره زنده پیش میره.مرحله هشتم: Manage Requirements Changes – تغییرات رو مدیریت کنیم!یکی از بزرگ‌ترین دردسرهای پروژه‌ها همینه: Scope Creep یا همون زیاد شدن بی‌برنامه نیازمندی‌ها. پس یه سیستم تغییرات مثل Change Control Mechanism داشته باشیم تا همه تغییرات رو ارزیابی، تأیید و ردیابی کنیم.مرحله نهم: Review and Approval – امضا بگیریم!م: Communication and Collaboration – مثل یک تیم کار کنید!م. اینجوری وقتی وسط کار کسی ایراد گرفت، می‌تونیم بگیمم: «همینه که هست، خودتون امضا کردید!» 😄مرحله دهم: Communication and Collaboration – مثل یک تیم کار کنیم!آخرین و شاید مهم‌ترین نکته: Communication and Collaboration رو فراموش نکنیم. پروتوتایپ درست کنیم، از ابزارهای تصویری استفاده کنیم، و مطمئن بشین همه تو جریانن. همه چیز وقتی خوب پیش میره که همه هم‌راستا باشن.چرا باید این همه زحمت بکشیم؟ببین، اگه نیازمندی‌ها درست جمع نشه:پروژه از مسیرش خارج میشه،کلی وقت و پول حروم میشه،در نهایت محصولی ساخته میشه که به درد هیچ‌کس نمی‌خوره.ولی اگه این مرحله درست انجام بشه:محصول دقیقاً مطابق انتظارات کارفرما میشه(Alignment with Stakeholder Needs)کسی نمی‌تونه بگه «من فکر می‌کردم اینو می‌سازید!» (Clear Understanding of Project Scope)مشکلات را با چشم باز از ابتدا میشناسیم و راه حل میدیم (Identification of Risks and Constraints) همه تیم یه زبان مشترک پیدا می‌کنن( Improved Communication)وقت و منابعمون به هدر نمیره (Efficient Resource Allocation)یه مثال واقعی: جمع‌آوری نیازمندی‌ها برای یک Fitness Appخب، فرض کن قراره یه اپلیکیشن Fitness Tracking بسازیم. توی مرحله Identify Stakeholders ما می‌فهمیم که مشتری‌ها دنبال این هستن که فعالیت‌های ورزشی‌شون رو راحت‌تر ثبت کنن و اون‌ها را پیگیری کنن. حالا این مرحله به معنی شناسایی ذینفعان پروژه‌ست. هر پروژه نرم‌افزاری آدم‌ها و گروه‌هایی داره که یا از نتیجه نهایی پروژه تأثیر می‌گیرن یا به نوعی می‌تونن روند پروژه رو تحت تأثیر بذارند.حالا بیایید کمی دقیق‌تر بگیم این ذینفعان چی هستند:کاربران نهایی (End-users): یعنی همون افرادی که قراره از اپ استفاده کنن. تمام نیازها و تجربیات این افراد باید اولویت اول تیم توسعه باشه.مدیران (Managers): این‌ها کسانی هستن که تصمیمات کلیدی می‌گیرن. ممکنه به گزارش‌ها و اطلاعات مدیریتی نیاز داشته باشن که بتونن پروژه رو پیگیری کنن و به درستی مدیریت کنن.مشتریان (Clients): این‌ها همون کسانی هستن که در نهایت اپلیکیشن به اون‌ها تحویل داده میشه. انتظار دارن که اپ دقیقاً نیازها و خواسته‌های خاص‌شون رو برآورده کنه.توسعه‌دهندگان (Developers): این تیم‌های فنی هستن که قراره این اپلیکیشن رو بسازن. تخصص‌شون تو کدنویسی و پیاده‌سازی سیستمه.متخصصین حوزه (Subject Matter Experts): این افراد ممکنه تو زمینه‌هایی مثل تکنولوژی، صنعت یا فرآیندهای تجاری تخصص داشته باشن و می‌تونن مشاوره‌های فنی یا راهکارهای کاربردی به تیم بدن.گروه‌های پشتیبانی و IT: کسانی که بعد از پیاده‌سازی مسئول نگهداری، آپدیت و پشتیبانی از سیستم هستن.شناسایی این ذینفعان به تیم توسعه کمک می‌کنه تا دقیقاً متوجه بشن که هرکسی چی می‌خواد و چطور می‌تونن نیازهاشون رو درست جمع‌آوری کنن. این کار باعث میشه در آینده مشکلات و سوء تفاهم‌ها کمتر بشه و پروژه به خوبی پیش بره.حالا توی مرحله Document Requirements باید مشخص کنیم که سیستم باید Personalized Recommendations ارائه بده. این یعنی به هر کاربر بر اساس علایق و رفتارهای خاص خودش پیشنهادهایی داده بشه. مثلا فرض کن یک کاربر دنبال رژیم غذایی برای کاهش وزن باشه. سیستم می‌تونه پیشنهاد بده که بر اساس تاریخچه تمرینی و اهداف شخصی‌ش، بهترین برنامه‌های تمرینی و غذایی برای اون طراحی بشه.هدف از این پیشنهادات اینه که تجربه کاربری به شدت بهبود پیدا کنه. وقتی کاربر می‌بینه که سیستم دقیقاً می‌دونه چی می‌خواد، احساس می‌کنه که تجربه‌ای منحصر به فرد داره.حالا توی Prioritize Requirements هم باید مشخص کنیم که چطور این نیازمندی‌ها رو اولویت‌بندی کنیم. این یعنی این که کدوم ویژگی‌ها یا نیازمندی‌ها می‌تونن به تأخیر بیفتند یا اصلاً پیاده‌سازی نشن. این کار کمک می‌کنه که تیم منابع، زمان و انرژی‌ش رو به درستی تخصیص بده.جمع‌بندی: هنر جمع‌آوری نیازمندی‌هادوست من، جمع‌آوری نیازمندی‌ها یک هنره. اگه این هنر رو درست انجام بدی، پروژه‌ت یه اثر هنری میشه که همه عاشقش میشن. حالا دست‌به‌کار شو و دفعه بعدی که پروژه گرفتی، این مراحل رو دقیق اجرا کن. موفق باشی! 💪

طراحی سیستم: چرا اهمیت دارد؟

Mostafa Akbarizadeh — Tue, 03 Dec 2024 08:09:43 +0330
System Designمقدمهدر دنیای توسعه نرم‌افزار، طراحی سیستم (System Design) به‌عنوان یکی از پایه‌های اصلی موفقیت یک پروژه شناخته می‌شود. هدف از طراحی سیستم، ایجاد یک معماری جامع، تعریف کامپوننت‌های اصلی و طراحی رابط‌هایی است که بتوانند نیازهای کاربران نهایی را به بهترین شکل برآورده کنند. اما چرا طراحی سیستم این‌قدر اهمیت دارد؟ و چگونه می‌توان یک سیستم را به گونه‌ای طراحی کرد که هم پایداری، هم مقیاس‌پذیری (Scalability) و هم قابلیت نگهداری (Maintainability) داشته باشد؟این مقاله به بررسی عمیق اهمیت طراحی سیستم در توسعه نرم‌افزار پرداخته و نکات فنی و تجربی مرتبط با این حوزه را معرفی می‌کند.1. تعریف طراحی سیستمطراحی سیستم فرایند تعیین ساختار کلی یک سیستم نرم‌افزاری است که شامل تصمیم‌گیری درباره معماری (Architecture)، کامپوننت‌ها (Components)، و نحوه ارتباط میان آن‌ها (Interfaces) می‌شود.این طراحی شامل دو سطح اصلی است: طراحی سطح بالا High-Level Design (HLD) تمرکز بر معماری کلی، شناسایی کامپوننت‌های بزرگ مانند سرویس‌ها، دیتابیس‌ها و ارتباطات بین آن‌ها. طراحی سطح پایین Low-Level Design (LLD) جزئیات داخلی هر کامپوننت مانند ساختار داده‌ها، الگوریتم‌ها و منطق داخلی.2. اهمیت طراحی سیستم در توسعه نرم‌افزارقابلیت مقیاس‌پذیری (Scalability):هر سیستم نرم‌افزاری که در محیط تولید (Production) اجرا می‌شود، با چالش‌هایی مانند افزایش ترافیک یا نیاز به منابع بیشتر روبه‌رو خواهد شد. طراحی سیستمی که بتواند به‌راحتی منابع بیشتری اضافه کند (مانند Scaling Out با افزایش سرورها) یا منابع موجود را بهینه‌تر استفاده کند، کلید موفقیت است.پایداری (Reliability):سیستم‌هایی که به طور مکرر دچار خرابی می‌شوند، اعتماد کاربران را از بین می‌برند. طراحی خوب باید Fault Tolerance را مدنظر قرار دهد، مانند استفاده از Load Balancer یا Replication برای اطمینان از دسترسی‌پذیری بالا (High Availability).قابلیت نگهداری و توسعه (Maintainability & Extensibility):طراحی ضعیف باعث پیچیدگی بیش از حد در توسعه و رفع مشکلات می‌شود. یک معماری مدولار (Modular Architecture) و استفاده از اصول SOLID، سیستم را برای تغییرات آینده آماده می‌کند.3. تأثیر طراحی ضعیف بر سیستم‌هاطراحی ضعیف سیستم می‌تواند منجر به مشکلات زیر شود:گلوگاه (Bottleneck) در عملکرد: یک نقطه‌ضعف در سیستم که باعث کاهش سرعت پردازش کل می‌شود.عدم مقیاس‌پذیری: نیاز به بازطراحی کامل سیستم با افزایش کاربران.هزینه‌های بالای نگهداری: کد پیچیده و غیرقابل تغییر که زمان توسعه را افزایش می‌دهد.خرابی‌های مکرر: عدم وجود Backup یا Recovery مناسب، که باعث از دست رفتن داده‌ها یا کاهش اعتماد کاربران می‌شود.4. ویژگی‌های یک طراحی سیستم ایده‌آلبرای داشتن یک سیستم کارآمد و حرفه‌ای، باید اصول زیر رعایت شود: ماجولاریتی Modularity:سیستم به ماژول‌های مستقل تقسیم شود تا تغییرات در یک بخش، تأثیری بر بخش‌های دیگر نگذارد. بهینه سازی تاخیر Latency Optimization:بهینه‌سازی تاخیر (Latency) از طریق استفاده از Caching یا نزدیک‌کردن سرورها به کاربران (CDN). مقیاس پذیری Scalability:استفاده از Partitioning و Sharding برای مقیاس‌پذیری دیتابیس‌ها و استفاده از Load Balancing برای مدیریت بار. مانیتورینگ Observability:اضافه‌کردن لاگ‌ها (Logs)، متریک‌ها (Metrics) و Tracing برای بررسی و رفع مشکلات سیستم. در دسترس بودن بالا High Availability:طراحی با استفاده از Replication، Failover و تکنیک‌های Disaster Recovery.5. مراحل اولیه طراحی سیستمهنگام شروع طراحی یک سیستم، باید به سوالات کلیدی زیر پاسخ دهید:چه مقدار بار (Load) را انتظار دارید؟تعداد درخواست‌ها در ثانیه (Requests per Second) یا اندازه داده‌ها.چه سطحی از پایداری و دسترس‌پذیری نیاز دارید؟آیا سیستم باید 24/7 بدون Downtime کار کند؟چه داده‌هایی نیاز به ذخیره‌سازی دارند؟نوع داده‌ها (Structured vs Unstructured) و روش ذخیره‌سازی (SQL vs NoSQL).6. نگاهی به آیندهدر مقالات بعدی، به بررسی دقیق هر یک از این مفاهیم خواهیم پرداخت:طراحی سیستم‌های توزیع‌شده (Distributed Systems)الگوریتم‌های مقیاس‌پذیری دیتابیس (Database Sharding)بهینه‌سازی عملکرد با استفاده از Cachingمدیریت Fault Tolerance و High Availabilityاین سفر یادگیری، شما را از اصول ابتدایی تا تکنیک‌های پیشرفته در طراحی سیستم همراهی خواهد کرد.نتیجه‌گیری:طراحی سیستم، هنر ترکیب دانش فنی، خلاقیت و تجربه برای ایجاد سیستمی است که نیازهای حال و آینده کاربران را برآورده کند. با درک عمیق مفاهیم و استفاده از ابزارها و تکنیک‌های مناسب، می‌توانید سیستمی بسازید که نه‌تنها عملکرد بالایی داشته باشد، بلکه قابلیت توسعه و مقیاس‌پذیری در شرایط مختلف را نیز دارا باشد.منتظر مقالات بعدی من در مورد همین موضوع باشید!

چگونه با OpenTelemetry ، سیستم‌های میکروسرویسی را بی‌نقص ردیابی کنیم؟

Mostafa Akbarizadeh — Mon, 02 Dec 2024 11:23:05 +0330
چالش‌های ردیابی در سیستم‌های میکروسرویسیسیستم‌های میکروسرویسی با وجود مزایای زیادی مانند انعطاف‌پذیری، مقیاس‌پذیری و قابلیت استقرار مستقل، چالش‌های جدیدی را در زمینه مانیتورینگ و رفع خطاها ایجاد می‌کنند. برخلاف معماری‌های یکپارچه (Monolithic)، که تمام بخش‌های سیستم در یک مکان متمرکز هستند، میکروسرویس‌ها به دلیل توزیع‌شدگی اجزای خود، بررسی جریان درخواست‌ها و شناسایی خطاها را دشوار می‌سازند. در این سیستم‌ها، هر درخواست ممکن است از چندین سرویس عبور کند، و تشخیص منشأ خطا نیازمند ابزاری دقیق و استاندارد است.چرا ردیابی توزیع‌شده مهم است؟کشف مشکلات پیچیده: در یک سیستم میکروسرویسی، خطا ممکن است در یکی از سرویس‌ها رخ دهد اما تأثیر آن در سرویس‌های دیگر ظاهر شود.مدیریت عملکرد: برای بهبود تجربه کاربر، باید بدانیم کدام سرویس باعث تأخیر در پاسخ‌دهی شده است.شناسایی نقاط شکست: به کمک ردیابی، می‌توان نقاط حساس و بحرانی سیستم را پیدا کرد و از خرابی‌های بزرگ جلوگیری کرد.راه‌حل‌ها برای ردیابی، مانیتورینگ و رفع خطا در میکروسرویس‌ها1. ردیابی توزیع‌شده (Distributed Tracing)نحوه کارکرد: در این روش، هر درخواست یک شناسه یکتا (Trace ID) دریافت می‌کند که با آن می‌توان کل مسیر درخواست را از ابتدا تا انتها دنبال کرد. این شناسه به تمامی سرویس‌هایی که درخواست از آن‌ها عبور می‌کند، اضافه می‌شود.ابزارهای کلیدی:OpenTelemetry: یک استاندارد باز برای جمع‌آوری داده‌های ردیابی، متریک‌ها و لاگ‌ها.Jaeger: برای ذخیره‌سازی و نمایش Traceها.Zipkin: ابزاری مشابه Jaeger برای ردیابی درخواست‌ها در سیستم‌های توزیع‌شده.2. مانیتورینگ متریک‌هانحوه کارکرد: متریک‌ها داده‌های عددی هستند که وضعیت عملکرد سیستم را نمایش می‌دهند (مانند زمان پاسخ‌دهی، تعداد درخواست‌ها و غیره).ابزارهای کلیدی:Prometheus: ابزاری قدرتمند برای ذخیره و کوئری متریک‌ها.Grafana: برای نمایش گرافیکی داده‌های جمع‌آوری‌شده توسط Prometheus.3. سیستم‌های لاگینگ متمرکزنحوه کارکرد: لاگ‌ها اطلاعاتی در مورد وضعیت داخلی سرویس‌ها ارائه می‌دهند و برای رفع خطا حیاتی هستند.ابزارهای کلیدی:ELK Stack (Elasticsearch, Logstash, Kibana): یک راه‌حل کامل برای ذخیره، پردازش و نمایش لاگ‌ها.Fluentd: جایگزینی برای Logstash که برای پردازش داده‌های لاگ استفاده می‌شود.4. ردیابی خطاها (Error Tracking)نحوه کارکرد: این سیستم‌ها به شما کمک می‌کنند خطاهای سیستم را جمع‌آوری و بررسی کنید.ابزارهای کلیدی:Sentry: ابزاری برای شناسایی و گزارش خطاها.Raygun: مشابه Sentry اما با تمرکز بیشتر روی تجربه کاربر.https://opentelemetry.io/docs/معماری و استقرار ابزارها در محیط میکروسرویسیپیکربندی OpenTelemetry:در هر سرویس، SDK مربوط به OpenTelemetry نصب می‌شود. سپس، پروایدر ردیابی (Trace Provider) به آن متصل شده و داده‌ها را به سرور مرکزی (مانند Jaeger) ارسال می‌کند.ادغام Prometheus و Grafana:سرویس‌ها با اکسپوز کردن متریک‌ها (به کمک endpointهای HTTP) داده‌های خود را برای Prometheus قابل دسترسی می‌کنند. این داده‌ها در Grafana به صورت داشبوردهای زیبا نمایش داده می‌شوند.راه‌اندازی ELK Stack:لاگ‌های جمع‌آوری‌شده از سرویس‌ها به Logstash ارسال می‌شود. سپس، داده‌ها در Elasticsearch ذخیره شده و در نهایت از طریق Kibana نمایش داده می‌شوند.نمونه کامل ردیابی توزیع‌شده در سیستم‌های میکروسرویسی با .NET Core و OpenTelemetryمعماری پروژه و ابزارهاOpenTelemetry برای ردیابی توزیع‌شده.Jaeger برای مشاهده و تحلیل داده‌های ردیابی.ASP.NET Core برای توسعه میکروسرویس‌ها.PostgreSQL برای ذخیره‌سازی داده‌ها.Docker برای استقرار ابزارها.Adding OpenTelemetry to .NET ApplicationsconfigureDistributed TracingPublishing a message with MassTransitExamining additional trace informationنتیجه‌گیریردیابی توزیع‌شده و مانیتورینگ پیشرفته نه‌تنها باعث بهبود عملکرد سیستم‌های میکروسرویسی می‌شوند، بلکه از طریق شناسایی مشکلات، هزینه‌های نگهداری را کاهش می‌دهند. ابزارهایی مانند OpenTelemetry، Prometheus، Jaeger و ELK Stack به توسعه‌دهندگان کمک می‌کنند تا دید کاملی نسبت به سیستم داشته باشند و در مواقع بحرانی، به‌سرعت مشکل را برطرف کنند.

کاهش تاخیر (Latency) در میکروسرویس‌ها

Mostafa Akbarizadeh — Sat, 30 Nov 2024 11:19:46 +0330
تصور کنید یک کاربر به سایت شما سر زده تا خریدی انجام بده. وارد صفحه محصول میشه، کمی گشت می‌زنه، محصول مورد نظرش رو انتخاب می‌کنه، اما... صفحه پرداخت چند ثانیه بیشتر از حد معمول طول می‌کشه تا لود بشه. نتیجه؟ کاربر خسته میشه و خرید رو نیمه‌کاره رها می‌کنه. حالا این چند ثانیه چقدر هزینه داره؟در دنیای دیجیتال امروز، صبر کاربران کمتر از همیشه شده. وقتی چیزی کند میشه، احساس ناراحتی فوراً جایگزین تجربه کاربری خوب میشه.برای میکروسرویس‌ها، این مسئله حتی پیچیده‌تره. میکروسرویس‌ها مثل گروهی از موزیسین‌ها هستن که هر کدوم یک ساز رو می‌زنن، اما برای اینکه یک موسیقی هماهنگ تولید بشه، باید همه با ریتم درست کار کنن. حالا تصور کنید یکی از موزیسین‌ها (یعنی یکی از میکروسرویس‌ها) کمی کندتر باشه؛ این باعث میشه کل قطعه بهم بخوره. در دنیای میکروسرویس‌ها، یه تاخیر کوچیک در یکی از سرویس‌ها می‌تونه مثل دومینو روی همه سیستم تاثیر بذاره.چرا کاهش Latency اینقدر مهم است؟Latency در میکروسرویس‌ها فقط یک چالش فنی نیست، بلکه تأثیر مستقیمی روی تجربه کاربری، هزینه‌های عملیاتی، و توانایی مقیاس‌پذیری سیستم دارد. در ادامه دلایل اهمیت آن را بررسی می‌کنیم:تجربه کاربری بهترکاربران انتظار پاسخ سریع دارند. هر ثانیه تأخیر می‌تواند باعث رها کردن سرویس و کاهش رضایت مشتریان شود. در صنعت‌هایی مانند تجارت الکترونیک یا بازی‌های آنلاین، این موضوع حیاتی است.بالاترین کاراییعملکرد بهتر زمانی رخ می‌دهد که ارتباطات بین سرویس‌ها سریع‌تر و بهینه‌تر باشد. این موضوع نه‌تنها سرعت سیستم را بالا می‌برد، بلکه مصرف منابع را کاهش می‌دهد.مقیاس‌پذیری (Scalability)میکروسرویس‌ها برای مقیاس‌پذیری طراحی شده‌اند. اگر یک بخش از سیستم دچار Latency شود، گلوگاه ایجاد می‌شود که کل سیستم را مختل می‌کند.کاهش هزینه‌هامنابع بیشتر یعنی هزینه‌های بیشتر. کاهش Latency یعنی استفاده بهینه از منابع، که در نهایت به کاهش هزینه‌های سخت‌افزاری و زیرساختی منجر می‌شود.پردازش آنی داده‌ها (Real-Time Processing)در سیستم‌هایی که نیاز به پردازش داده‌ها در لحظه دارند، مثل سیستم‌های مالی، هرگونه تأخیر غیرقابل قبول است و به‌سرعت مشکلات بزرگی ایجاد می‌کند.دلایل رایج Latency در میکروسرویس‌هابرای کاهش Latency، ابتدا باید دلایل رایج آن را بشناسیم. در زیر برخی از مهم‌ترین این دلایل آورده شده است:ارتباطات بین سرویس‌ها (Service-to-Service Communication)ارتباطات ناهمزمان، درخواست‌های شبکه‌ای سنگین، یا فاصله جغرافیایی بین سرویس‌ها، از عوامل اصلی ایجاد تأخیر در انتقال داده‌ها هستند.تماس‌های بیش از حد (Excessive Service Calls)وقتی میکروسرویس‌ها بیش از حد با هم ارتباط برقرار می‌کنند، زمان کلی پاسخگویی سیستم افزایش می‌یابد.الگوهای ارتباطی پرسر و صدا (Chatty Communication Patterns)در مواردی که یک میکروسرویس برای انجام کارهای ساده نیاز به درخواست‌های مکرر دارد، تأخیرها به‌طور تصاعدی افزایش می‌یابند.کوئری‌های پیچیده (Complex Queries)استفاده از کوئری‌های ناکارآمد در دیتابیس‌ها می‌تواند زمان پاسخگویی را به‌شدت افزایش دهد.استفاده از کانتینرها و ماشین‌های مجازی (Containers and Virtual Machines)ماشین‌های مجازی و کانتینرها، علی‌رغم مزایای زیاد، گاهی اوقات به دلیل سربار منابع اضافی، تأخیر ایجاد می‌کنند.لاگ‌گذاری و نظارت (Logging and Monitoring)افزایش نظارت و لاگ‌گذاری می‌تواند به کند شدن عملکرد سیستم منجر شود، به‌ویژه در سیستم‌های بسیار بزرگ.روش‌های بهینه‌سازی برای کاهش Latency1. بهینه‌سازی ارتباطات بین سرویس‌هاارتباطات ناهمزمان (Asynchronous Communication)استفاده از Message Queueهایی مثل RabbitMQ یا Kafka می‌تواند تاخیرها را کاهش دهد. این روش به سرویس‌ها اجازه می‌دهد به‌جای منتظر ماندن برای پاسخ، کارهای خود را ادامه دهند.استفاده از فرمت‌های داده‌ای بهینهفرمت‌های باینری مثل Protocol Buffers یا Avro سریع‌تر از فرمت‌هایی مثل JSON و XML هستند.کاهش تعداد تماس‌هااطلاعات مرتبط را در یک درخواست دسته‌بندی کنید تا نیاز به تماس‌های مکرر کاهش یابد.2. استفاده از کش (Caching)کش در حافظه (In-Memory Caching)ابزارهایی مثل Redis و Memcached برای ذخیره‌سازی داده‌های پرتکرار بسیار کارآمد هستند.کش توزیع‌شدهدر معماری‌های بزرگ، می‌توانید از کش‌های توزیع‌شده برای کاهش فشار بر روی سرویس‌های اصلی استفاده کنید.کش سمت کلاینتبرخی داده‌ها را می‌توان در سمت کلاینت ذخیره کرد تا فشار روی سرورها کاهش یابد.3. بهینه‌سازی دیتابیس‌هاپارتیشن‌بندی و شاردینگ (Partitioning and Sharding)داده‌های بزرگ را به بخش‌های کوچکتر تقسیم کنید تا کوئری‌ها سریع‌تر انجام شوند.استفاده از Connection Poolingزمان ایجاد اتصال به دیتابیس با استفاده از Poolهای اتصالات کاهش می‌یابد.کوئری‌های بهینهاز ابزارهایی مثل Entity Framework Profiler برای بررسی و بهینه‌سازی کوئری‌ها استفاده کنید.4. ابزارهای نظارتی و مانیتورینگابزارهایی مثل Prometheus و Grafana برای نظارت بر عملکرد سیستم و شناسایی گلوگاه‌ها بسیار مفید هستند.5. استفاده از شبکه‌های سرویس (Service Mesh)ابزارهایی مثل Istio یا Linkerd برای مدیریت ارتباطات سرویس به سرویس، کنترل ترافیک، و نظارت بر عملکرد بهینه‌سازی بسیار مفید هستند.مثال‌های واقعی کاهش Latency در میکروسرویس‌ها1. نتفلیکس (Netflix)نتفلیکس یکی از پیشگامان معماری میکروسرویس است. این شرکت به دلیل حجم بالای کاربران جهانی، نیاز به کاهش Latency را به‌خوبی درک کرده و اقدامات زیر را انجام داده است:بهینه‌سازی ارتباطات بین سرویس‌هاراه‌حل: استفاده از پروتکل gRPC به‌جای REST برای ارتباطات داخلی سرویس‌ها.نتیجه: کاهش چشمگیر در زمان انتقال داده بین میکروسرویس‌ها، زیرا gRPC مبتنی بر HTTP/2 است و داده‌ها را به شکل باینری انتقال می‌دهد.کش سمت کلاینتراه‌حل: استفاده از Edge Caching برای ذخیره محتوای پرکاربرد در سرورهای نزدیک به کاربران.نتیجه: کاربران در هر نقطه از دنیا، محتوای ویدئویی را بدون تأخیر تجربه می‌کنند.استفاده از Circuit Breakerراه‌حل: پیاده‌سازی ابزار Hystrix برای جلوگیری از خرابی‌های زنجیره‌ای در میکروسرویس‌ها.نتیجه: اگر یک سرویس کند یا غیرقابل دسترس باشد، سرویس‌های دیگر به‌سرعت از آن عبور کرده و پاسخ‌های پیش‌فرض ارائه می‌دهند.2. آمازون (Amazon)آمازون به‌عنوان یکی از بزرگ‌ترین فروشگاه‌های آنلاین جهان، با میلیاردها درخواست روزانه روبه‌روست. کاهش Latency در سیستم این شرکت ضروری است.کاهش تعداد درخواست‌هاراه‌حل: گروه‌بندی داده‌ها در یک درخواست (Batching) برای کاهش تعداد تماس‌ها به دیتابیس و سرویس‌های داخلی.نتیجه: Latency کلی به‌طور قابل‌توجهی کاهش یافت، به‌ویژه در روزهای پر ترافیک مثل بلک فرایدی.کش توزیع‌شدهراه‌حل: استفاده از DynamoDB به‌همراه Elasticache برای کشینگ داده‌های پرتکرار.نتیجه: کاربران به داده‌ها با سرعت بالا دسترسی پیدا می‌کنند، حتی در صورت فشار سنگین بر سیستم.استفاده از Retry Patternراه‌حل: در زمان بروز خطاهای موقتی (مثل خطای شبکه)، درخواست‌ها مجدداً ارسال می‌شوند.نتیجه: کاهش نرخ شکست درخواست‌ها بدون نیاز به تلاش دستی کاربران.3. اوبر (Uber)اوبر که میلیون‌ها سفر روزانه را مدیریت می‌کند، نیاز دارد تا درخواست‌ها و پاسخ‌ها با کمترین تأخیر ممکن انجام شوند.بهینه‌سازی دیتابیسراه‌حل: استفاده از Sharding برای تقسیم‌بندی داده‌ها بر اساس مناطق جغرافیایی.نتیجه: کاهش زمان پاسخگویی به درخواست‌های کاربران محلی.استفاده از Service Meshراه‌حل: پیاده‌سازی Istio برای مدیریت ترافیک بین میکروسرویس‌ها.نتیجه: کاهش پیچیدگی مدیریت ارتباطات بین سرویس‌ها و بهبود کارایی کلی.راه‌حل: استفاده از پیام‌رسان‌هایی مثل Kafka برای مدیریت ارتباطات ناهمزمان.نتیجه: سرویس‌ها به‌جای منتظر ماندن برای پاسخ، به کار خود ادامه می‌دهند و داده‌ها به‌صورت بلادرنگ پردازش می‌شوند.4. لینکدین (LinkedIn)لینکدین به‌عنوان یک شبکه اجتماعی حرفه‌ای با کاربران زیاد، از روش‌های زیر برای کاهش Latency استفاده کرده است:بهینه‌سازی نمایش داده‌هاراه‌حل: استفاده از GraphQL به‌جای REST برای درخواست‌های API.نتیجه: کاربران فقط داده‌های موردنیاز خود را دریافت می‌کنند، که این موضوع باعث کاهش حجم انتقال داده و زمان پاسخ می‌شود.کش توزیع‌شدهراه‌حل: استفاده از Voldemort، یک سیستم کش توزیع‌شده، برای داده‌های پرتکرار مثل پروفایل‌ها و ارتباطات کاربران.نتیجه: سرعت بارگذاری صفحات به شکل قابل‌توجهی افزایش یافت.نتیجه‌گیری از مثال‌هاتجارب شرکت‌های بزرگ نشان می‌دهد که کاهش Latency نیازمند ترکیبی از استراتژی‌های طراحی معماری، انتخاب ابزارهای مناسب و بهینه‌سازی فرآیندها است. برای کاهش Latency در پروژه‌های میکروسرویسی خود، می‌توانید از این تجربیات الهام بگیرید و ابزارهای مشابه را متناسب با نیازهای خود پیاده‌سازی کنید. #MicroservicesOptimization #LatencyReduction #SystemPerformance #TechInnovation #ScalableSystems #EcommerceArchitecture #RealTimeProcessing #CloudComputing#DistributedSystems #TechForBusiness #AppPerformance #SoftwareEngineering #LatencyChallenges #MicroservicesArchitecture #EfficientTech #TechSolutions #APIOptimization #ServerlessComputing #NetworkLatency #TechStrategy

مانیتورینگ و Observability در Microservices: تسلط کامل بر عمق سیستم‌ها!

Mostafa Akbarizadeh — Wed, 27 Nov 2024 09:25:12 +0330
مانیتورینگ و هشدار: چشم و گوش سیستمت باش!تصور کن یه کشتی بزرگ داری و روی اقیانوس در حال حرکت هستی. کسی رادار رو چک نمی‌کنه، کسی به وضعیت موتور نگاه نمی‌کنه و خبری از زنگ خطر نیست. خب، فقط یه موج کافیه تا همه چیز بره زیر آب! سیستم‌های نرم‌افزاری هم دقیقاً مثل همین کشتی هستند: اگه Monitoring و Alerting نداشته باشی، یه خطای کوچیک می‌تونه به یه فاجعه بزرگ تبدیل بشه.حالا بیایید بررسی کنیم چرا این دو مفهوم حیاتی هستن، چطور می‌تونیم از ابزارها و تکنیک‌های مناسب استفاده کنیم، و در نهایت، روش‌های دیباگ بین سرویس‌ها در معماری Microservices رو یاد بگیریم.چالش‌ها: چرا Monitoring و Alerting ضروریه؟۱. خطاهای پنهانبدون مانیتورینگ مناسب، ممکنه مشکلات و خطاها برای مدت‌ها شناسایی نشن. این خطاها به مرور زمان انباشته می‌شن و در نهایت به اختلالات بزرگ منجر می‌شن.۲. نارضایتی کاربرانکاربران همیشه توقع یه تجربه سریع و بدون مشکل دارن. اگه یه باگ یا قطعی به موقع برطرف نشه، احتمال زیادی هست که کاربرها رو از دست بدی.۳. از دست دادن درآمدمشکلاتی مثل server downtime یا خرابی دیتابیس می‌تونه مستقیماً روی درآمد تاثیر بذاره، چون تراکنش‌ها متوقف می‌شن و اعتماد کاربران خدشه‌دار می‌شه.۴. مدیریت پیچیدگیتوی سیستم‌های بزرگ که اجزای مختلف به هم متصل هستن، یه مشکل کوچیک می‌تونه کل سیستم رو تحت تأثیر قرار بده. پیدا کردن علت این نوع مشکلات بدون مانیتورینگ واقعاً سخته.راه‌حل‌ها: سیستم همیشه زیر ذره‌بین!۱. استفاده از ابزارهای مانیتورینگابزارهایی مثل Prometheus، Grafana یا ELK Stack می‌تونن برای بررسی لحظه‌ای عملکرد سیستم استفاده بشن.این ابزارها شاخص‌های کلیدی مثل CPU Usage، Memory Usage یا Response Time رو رصد می‌کنن و اطلاعات ارزشمندی در اختیارت می‌ذارن.۲. تنظیم هشدارهابرای رویدادهای خاص مثل پر شدن فضای دیسک، بالا رفتن زمان پاسخ‌دهی یا افزایش خطاهای HTTP 500، هشدارهای خودکار تعریف کن.ابزارهایی مثل PagerDuty یا Slack Notifications می‌تونن این هشدارها رو به تیم مربوطه ارسال کنن.۳. مانیتورینگ سلامت سرویسبا استفاده از Health Check APIs، می‌تونی وضعیت سرویس‌ها رو به‌صورت خودکار بررسی کنی و به محض بروز مشکل اقدام لازم رو انجام بدی.۴. ذخیره‌سازی لاگ‌هالاگ‌های سیستمت رو به یه سیستم متمرکز مثل ElasticSearch یا Fluentd منتقل کن. این کار کمک می‌کنه تا اگه مشکلی پیش اومد، به راحتی دلیلش رو پیدا کنی.۵. داشبوردهای گرافیکیبا ابزارهایی مثل Grafana یا Kibana داشبوردهای زیبا و کاربردی بساز. این داشبوردها بهت کمک می‌کنن تا وضعیت سیستم رو فقط با یه نگاه بررسی کنی.۶. هشدار هوشمندبه جای این که برای هر مشکل کوچیکی هشدار ارسال بشه، از سیستم‌های هوشمند استفاده کن که فقط وقتی مشکل جدیه هشدار بدن. این کار از خستگی تیم پشتیبانی جلوگیری می‌کنه و به مدیریت بهتر زمان کمک می‌کنه.روش دیباگ بین سرویس‌ها در معماری Microservicesیکی از بزرگ‌ترین چالش‌ها در معماری Microservices، دیباگ بین سرویس‌هاست. وقتی یک درخواست از چندین سرویس عبور می‌کنه و در نهایت خطایی ایجاد می‌شه، پیدا کردن منبع اصلی مشکل می‌تونه بسیار سخت باشه. در ادامه روش‌های کلیدی دیباگ بین سرویس‌ها رو بررسی می‌کنیم:۱. استفاده از Distributed Tracingبا استفاده از ابزارهایی مثل Jaeger یا Zipkin می‌تونی trace کامل یک درخواست رو در بین سرویس‌ها ردیابی کنی.این ابزارها هر مرحله از پردازش درخواست رو ثبت می‌کنن و بهت نشون می‌دن که درخواست چطور از یک سرویس به سرویس دیگه منتقل شده.شاخص‌هایی مثل زمان تأخیر، نقاط شکست، و سرویس‌های متأثر رو به وضوح نمایش می‌ده.۲. استفاده از Correlation IDیک Correlation ID به هر درخواست ورودی اختصاص بده و این شناسه رو در طول چرخه حیات درخواست بین سرویس‌ها حفظ کن.این شناسه رو در لاگ‌های هر سرویس ذخیره کن تا بتونی جریان کامل درخواست رو دنبال کنی.برای پیاده‌سازی این روش، از یک Middleware برای اضافه کردن و مدیریت Correlation ID استفاده کن.۳. تحلیل لاگ‌هاابزارهایی مثل ELK Stack (Elasticsearch, Logstash, Kibana) بهت اجازه می‌ده لاگ‌های تمامی سرویس‌ها رو در یک مکان متمرکز ذخیره و تحلیل کنی.با استفاده از این ابزارها می‌تونی به راحتی مشکلات خاصی رو که در یک سرویس یا جریان رخ داده، پیدا کنی.ایجاد فیلترهایی بر اساس Correlation ID می‌تونه جریان‌های مرتبط رو به صورت مستقیم نمایش بده.۴. مانیتورینگ متریک‌هابا ابزارهایی مثل Prometheus، می‌تونی متریک‌های دقیق هر سرویس مثل تعداد درخواست‌ها، زمان پاسخ‌دهی، و خطاها رو مانیتور کنی.این اطلاعات بهت کمک می‌کنه تا سرویس‌هایی که عملکرد غیرعادی دارن رو شناسایی کنی.همچنین می‌تونی با تنظیم هشدارهای خودکار، به موقع از مشکلات آگاه بشی.۵. شبیه‌سازی خطابرای تست و دیباگ مؤثرتر، از ابزارهایی مثل Chaos Monkey استفاده کن تا خطاها رو شبیه‌سازی کنی و واکنش سیستم رو در شرایط بحرانی ارزیابی کنی.مثال کاربردی: دیباگ در یک فروشگاه اینترنتیفرض کن فروشگاه اینترنتی داری و کاربر هنگام ثبت سفارش با خطای 500 Internal Server Error مواجه می‌شه.مراحل دیباگ به این صورت خواهد بود:تحلیل لاگ‌ها: شناسه Correlation ID رو از لاگ درخواست کاربر پیدا کن.ردیابی درخواست: با ابزار Jaeger، مراحل عبور درخواست از سرویس‌های مختلف (مثل Order Service و Payment Service) رو بررسی کن.بررسی متریک‌ها: متریک‌های Order Service و Payment Service رو در Prometheus بررسی کن و ببین کدوم سرویس بیشترین زمان تأخیر یا خطا رو داره.رفع مشکل: با تحلیل نتایج، مشکل شناسایی و برطرف می‌شه.نتیجه‌گیری ابزارهای دیباگ و Monitoring، Alerting مثل داشتن دوربین امنیتی و ابزارهای پیشرفته تجزیه و تحلیل تو سیستم‌هات هستن. اگه بخوای یه سیستم قابل اعتماد و پایدار بسازی، باید همیشه وضعیت سرویس‌هات رو زیر نظر داشته باشی و برای مشکلات غیرمنتظره آماده باشی.با ترکیب ابزارهای مانیتورینگ، هشداردهی و دیباگ، نه‌تنها می‌تونی مشکلات رو سریع‌تر حل کنی، بلکه می‌تونی از وقوع بسیاری از مشکلات جلوگیری کنی. سیستم‌ت رو حرفه‌ای‌تر مدیریت کن و همیشه یک قدم جلوتر باش. 🚀#Microservices#Monitoring #Observability #DevOps #SystemReliability #Metrics #DistributedSystems #LoggingAndTracing #IncidentManagement #CloudComputing #Prometheus #Grafana #ErrorReporting #DebuggingTechniques #ScalableArchitecture

Handling Large Files in Microservices - مدیریت فایل‌های بزرگ در معماری میکروسرویس‌ها

Mostafa Akbarizadeh — Tue, 26 Nov 2024 10:39:10 +0330
مدیریت فایل‌های بزرگ یکی از چالش‌های اساسی در سیستم‌های مبتنی بر معماری میکروسرویس‌هاست. این مسئله به‌ویژه زمانی که نیاز به ارسال یا دریافت فایل‌های حجیم باشد، خود را به‌وضوح نشان می‌دهد. در این مقاله، راهکارهای مختلف این موضوع را بررسی می‌کنیم، خوبی‌ها و بدی‌های هر روش را تحلیل می‌کنیم و به مثال‌هایی از دنیای واقعی مثل یوتیوب، نتفلیکس و اینستاگرام اشاره خواهیم کرد.چالش‌ها: چرا فایل‌های بزرگ دردسرساز هستند؟سرعت پایین انتقال داده: ححجم زیاد فایل‌ها می‌تواند زمان انتقال را به شدت افزایش دهد و تجربه کاربری را تحت تأثیر قرار دهد.مثال: کاربری که قصد دارد ویدیویی 4K با حجم چند گیگابایت را در یوتیوب آپلود کند.استفاده زیاد از منابع سرور : ذخیره و پردازش فایل‌های بزرگ، فشار زیادی بر منابع CPU، حافظه و فضای ذخیره‌سازی وارد می‌کند.مثال: نتفلیکس باید ویدیوهای بزرگ را در چند فرمت مختلف برای دستگاه‌های گوناگون تبدیل کند.محدودیت پهنای باند : انتقال فایل‌های حجیم باعث مصرف زیاد پهنای باند می‌شود که ممکن است عملکرد سایر بخش‌های سیستم را مختل کند.از دست رفتن داده‌ها : قطع اتصال هنگام انتقال فایل‌های بزرگ می‌تواند باعث از دست رفتن کامل داده و لزوم شروع دوباره فرآیند شود.مقیاس‌پذیری محدود : مدیریت فایل‌های حجیم در سیستم‌هایی که به طور مداوم در حال گسترش هستند، دشوارتر است.راهکارهای مدیریت فایل‌های بزرگ1. استفاده از Object Storageتوضیح:این روش به‌جای ذخیره مستقیم فایل‌ها روی سرورها، از سرویس‌های ذخیره‌سازی ابری مثل Amazon S3، Azure Blob Storage یا Google Cloud Storage استفاده می‌کند.مزایا:مقیاس‌پذیری بالا. کاهش هزینه‌های ذخیره‌سازی به دلیل پرداخت بر اساس استفاده. امکان دسترسی از نقاط مختلف جهان با تاخیر کم.معایب:ممکن است هزینه‌های انتقال داده (Data Egress) بالا باشد. به وابستگی به ارائه‌دهنده ابری منجر می‌شود.مثال واقعی:یوتیوب و نتفلیکس از Amazon S3 و Google Cloud برای ذخیره فایل‌های حجیم و دسترسی سریع کاربران استفاده می‌کنند.2. تقسیم فایل‌ها به بخش‌های کوچک‌تر (Chunking)توضیح:فایل‌های بزرگ به بخش‌های کوچک‌تر تقسیم شده و هر بخش به‌صورت جداگانه آپلود می‌شود. در انتها، بخش‌ها در سرور تجمیع می‌شوند.مزایا:قابلیت ادامه آپلود در صورت قطع ارتباط.کاهش فشار بر شبکه و منابع سرور.معایب:سربار اضافی برای تجمیع بخش‌ها.نیاز به مدیریت متادیتای بخش‌ها.مثال واقعی:یوتیوب از آپلود قطعه‌ای (Chunked Upload) استفاده می‌کند تا کاربران بتوانند ویدیوهای خود را حتی با اینترنت ناپایدار بارگذاری کنند.3. استفاده از Block Storageتوضیح:این روش داده‌ها را در بلوک‌های کوچک ساختارمند ذخیره می‌کند و برای برنامه‌هایی که نیاز به IOPS بالا دارند، ایده‌آل است.مثال: Amazon EBS، Azure Managed Disks.مزایا:سرعت بالا در ذخیره و دسترسی.مناسب برای پایگاه‌های داده و فایل‌های حجیم با دسترسی مکرر.معایب:هزینه بالاتر نسبت به Object Storage.نیاز به مدیریت دقیق‌تر.مثال واقعی:نتفلیکس از این روش برای نگهداری داده‌های قابل تغییر مثل زیرنویس‌ها یا متادیتای فیلم‌ها استفاده می‌کند.4. فشرده‌سازی (Compression)توضیح:فایل‌ها قبل از انتقال با استفاده از الگوریتم‌هایی مثل GZIP یا Brotli فشرده می‌شوند.مزایا:کاهش حجم داده‌های انتقالی.بهبود سرعت انتقال.معایب:سربار محاسباتی برای فشرده‌سازی و باز کردن فایل.کاهش کارایی برای فایل‌هایی که از قبل فشرده شده‌اند.مثال واقعی:اینستاگرام از فشرده‌سازی تصاویر و ویدیوها برای کاهش حجم فایل‌های ارسالی کاربران استفاده می‌کند.5. استفاده از پروتکل‌های سریع‌ترتوضیح:پروتکل‌های مدرنی مثل HTTP/2 یا gRPC می‌توانند سرعت انتقال داده‌ها را افزایش دهند.مزایا:انتقال موازی چندین جریان داده.کاهش زمان تأخیر (Latency).معایب:نیاز به زیرساخت و پشتیبانی مناسب.مثال واقعی:گوگل در محصولات خود مثل Google Drive از gRPC برای افزایش سرعت انتقال فایل‌ها استفاده می‌کند.6. امکان ادامه آپلود (Resume Upload)توضیح:در صورت قطع انتقال، فایل می‌تواند از همان نقطه ادامه پیدا کند. پروتکل‌هایی مثل Tus یا Multipart Upload این قابلیت را فراهم می‌کنند.مزایا:جلوگیری از اتلاف وقت و منابع.تجربه کاربری بهتر.معایب:پیچیدگی در پیاده‌سازی.نیاز به نگهداری متادیتای انتقال.مثال واقعی:یوتیوب و نتفلیکس برای مدیریت آپلودها و دانلودهای کاربران از این روش بهره می‌برند.درس‌هایی از دنیای واقعینتفلیکس:نتفلیکس با استفاده از Object Storage و الگوریتم‌های فشرده‌سازی پیشرفته، ویدیوها را به قطعات کوچک تقسیم کرده و برای هر دستگاه نسخه بهینه تولید می‌کند. این کار باعث کاهش تاخیر و بهبود تجربه کاربری شده است.اینستاگرام:تصاویر و ویدیوها در اینستاگرام قبل از ارسال، فشرده و به قطعات کوچک تقسیم می‌شوند. این روش آپلود پایدار حتی در شرایط اینترنت ضعیف را تضمین می‌کند.یوتیوب:آپلود قطعه‌ای همراه با امکان Resume Upload باعث شده کاربران بتوانند بدون نگرانی از قطع ارتباط، ویدیوهای حجیم خود را بارگذاری کنند.نتیجه‌گیریمدیریت فایل‌های بزرگ در معماری میکروسرویس‌ها مانند عبور از یک پل شلوغ با یک کامیون پر از بار است. استفاده از راهکارهای مناسب مانند Object Storage، Chunking، یا پروتکل‌های مدرن می‌تواند انتقال فایل‌ها را ساده‌تر و مطمئن‌تر کند. با انتخاب راهکار مناسب بر اساس نیازهای سیستم خود، می‌توانید این چالش را به فرصتی برای بهبود کارایی تبدیل کنید.#MicroservicesArchitecture #FileManagement #LargeFileHandling #CloudStorage #DataTransfer #ObjectStorage #FileChunking #CompressionTechniques #ScalableSolutions #HighPerformanceComputing #HTTP2 #GRPC #ResumableUploads #ServerOptimization #DistributedSystems #NetflixEngineering #YouTubeScaling #TechnicalWriting #DevOpsSolutions #SoftwareDesignPatterns

مهاجرت از سیستم‌های قدیمی: راهکارهای عملی برای موفقیت در پروژه‌های پیچیده

Mostafa Akbarizadeh — Mon, 25 Nov 2024 18:55:17 +0330
سلام به همه دوستان 🌟دهه‌های ۷۰ و ۸۰: عصر دلفی و ویژوال بیسیکیادتونه اون روزهایی که نرم‌افزارهایی مثل دلفی و ویژوال بیسیک همه‌جا حرف اول رو می‌زدن؟ اون موقع، برنامه‌نویس‌ها بیشتر شبیه مهندسانی بودن که سیستم‌های پیچیده و سنگین می‌ساختن. این سیستم‌ها، که امروز بهشون "سیستم‌های قدیمی" می‌گیم، ستون اصلی خیلی از کسب‌وکارها بودن.امروز: تغییرات دنیای تکنولوژیاما حالا زمانه عوض شده. دیگه اون سیستم‌های قدیمی جوابگو نیستن. تکنولوژی پیشرفت کرده، نیازهای کسب‌وکارها تغییر کرده و برنامه‌نویس‌های قدیمی هم کم‌کم بازنشسته می‌شن. این سیستم‌ها که زمانی شاهکار بودن، حالا مثل باری سنگین روی دوش شرکت‌ها افتادن.مشکلات سیستم‌های قدیمیاین سیستم‌ها مشکلات جدی دارن:قدیمی و منسوخ: تکنولوژی‌شون دیگه کارایی نداره.پیچیده و سخت: تغییر یا توسعه‌شون مثل حل یک پازل سخت و بی‌انتهاست.داده‌های سنگین: حجم بالای اطلاعات کار انتقال رو دشوار کرده.کمیاب بودن تخصص: برنامه‌نویس‌هایی که بتونن باهاشون کار کنن، نایاب شدن.عدم انطباق با نیازهای جدید: انتظارات مدرن کسب‌وکارها رو برآورده نمی‌کنن.هزینه‌های بالا: نگهداری این سیستم‌ها به‌صرفه نیست.وقت تغییر استتغییر همیشه سخت و چالش‌برانگیز است، اما برای پیشرفت، گریزناپذیر. به‌روزرسانی سیستم‌های قدیمی مثل جراحی قلب یک بیمار است؛ حساس و دقیق. این کار فقط آپدیت یک نرم‌افزار نیست، بلکه باید تمام ابعاد سیستم، از داده‌ها تا فرآیندها، دقیقاً بررسی و ارزیابی بشه.تصور کنید سیستمی که سال‌ها ازش استفاده شده، هر برنامه‌نویس به سلیقه خودش توش تغییراتی داده و حالا تبدیل شده به یک ساختار پیچیده که فقط خودش و خالقش می‌فهمن! چطور می‌شه مدیران و برنامه‌نویس‌ها رو قانع کرد که تغییر این سیستم، به‌رغم همه چالش‌ها، ضروریه؟تجربه‌ها و درس‌هامن بارها در این مسیر قدم گذاشتم و با چالش‌های زیادی روبرو شدم. تیم‌های فنی و برنامه‌نویس‌ها معمولاً اول راه با اشتیاق شروع می‌کنن، اما وسط مسیر از حجم مشکلات ناامید می‌شن. از طرفی، صاحبان کسب‌وکار به دلیل فشار بازار و نیازهای جدید، انتظارات بالایی دارن و سیستم‌های قدیمی توان پاسخگویی ندارن.راه‌حل‌هایی مثل ساخت سیستم‌های جزیره‌ای یا بازنویسی کامل از صفر اغلب امتحان می‌شه. ولی وقتی به میانه راه می‌رسیم، تازه ابعاد واقعی چالش نمایان می‌شه؛ از مسئله یکپارچگی و گزارش‌دهی تا کانورت داده‌ها و تطبیق با نیازهای جدید.چرا شکست می‌خوریم؟با اینکه شرکت‌های بزرگ دنیا موفق به این تغییرات می‌شن، خیلی از پروژه‌ها در ایران به نتیجه نمی‌رسن. چرا؟شاید چون برنامه‌ریزی کافی انجام نمی‌شه یا جزئیات حیاتی نادیده گرفته می‌شه.تجربه شما چیست؟آیا شما هم با چنین چالش‌هایی روبرو شدین؟ تجربه‌های خودتون رو در مهاجرت از سیستم‌های قدیمی به تکنولوژی‌های جدید با ما به اشتراک بذارین. 😊

مهندسی نرم افزار در گوگل

محمد حسین جلیلی — Thu, 11 Apr 2024 16:09:45 +0330
این بلاگ خلاصه‌ای از تجربیات آقای Fergus Henderson هست که بیش از ده سال در گوگل، مهندس نرم افزار است و نشان می‌دهد که چگونه گوگل بازی توسعه نرم افزار را انجام می‌دهد.گوگل محصولات پیچیده و زیادی دارد مانند Google Search, AdWords, Maps و Android ... اما چگونه این همه محصولات را مدیریت می‌کنند و توسعه می‌دهد؟ما در این بلاگ سعی می‌کنیم که شیوه‌های مهندسی نرم‌افزار را که در گوگل استفاده می‌شود، بررسی کنیم و ببینیم که گوگل چگونه محصولات نرم افزاری خود را مدیریت می‌کند. دانستن فرآیند‌های یک شرکت موفق مانند گوگل می‌تواند یک معیار ارزیابی خوب برای سازمان‌های دیگر باشد.یکی از دلایل مهم موفقیت گوگل استفاده از این شیوه‌ها هست، مانند:· مخزن کد یکپارچه: گوگل تمام کدهای خود را در یک کتابخانه دیجیتالی عظیم نگه می دارد که هر مهندس می تواند به آن دسترسی داشته باشد. این مانند داشتن یک پوشه آنلاین غول پیکر و مشترک برای همه پروژه های Google است که پیدا کردن کد مورد نیاز و کار با آن را برای همه آسان تر می کند.· سیستم Build معروف به Blaze : آنها از ابزار خاصی به نام Blaze برای انجام کارهای سنگین کامپایل و تست کد استفاده می کنند. Blaze به‌عنوان یک خط مونتاژ تصور کنید که همه نرم‌افزارهایی را که Google می‌سازد کنار هم قرار می‌دهد و بررسی می‌کند و از اجرای روان همه چیز اطمینان می‌دهد.· بازنگری کد: قبل از اینکه هر کدی بخشی از پروژه های گوگل شود، مهدنس‌های دیگری آن‌ها را به طور کامل بررسی می کنند. این مرحله مطمئن می شود که کد نقص کمی دارد و کار تیمی را ارتقا می دهد.· تست کردن مداوم: گوگل به جای اینکه منتظر تست همه چیز باشد، دوست دارد نرم افزار خود را اغلب و در قطعات کوچک تست کند. این شبیه به چشیدن سوپ در حین پختن است و در آخر به جای همه چیز، چاشنی را کم کم تنظیم کنید.· مدیریت پروژه ها و افراد: گوگل روش هوشمندانه ای برای اجرای پروژه ها و مراقبت از مهندسان خود دارد. به عنوان مثال، مهندسان می توانند 20 درصد از زمان خود را صرف هر پروژه ای کنند که به آن علاقه دارند. این آزادی جرقه خلاقیت و ایده های جدید می دهد.· نرم‌افزار بازنویسی: گوگل به‌جای اینکه به قدیمی‌ها بچسبد، بیشتر نرم‌افزارهای خود را با نیاز‌های جدید و تکنولوژی‌های جدید بازنویسی می‌کند.1 توسعه نرم افزار1-1 مخزن کدبیشتر کد‌های گوگل در یک مخزن قرار دارند و اکثر مهندس‌ها به این مخزن دسترسی دارند.(( داده‌های کاربران کاملا محافظت شده هست، فقط کد‌ها برای مهندس‌ها در دسترس هست)). البته قسمت‌هایی از کد‌ها برای برخی از پروژه‌ها محافظت شده هستند. اما پروژه‌های متن باز مثلا اندروید و کروم کاملا قابل دسترس هستند. . دسترسی نوشتن برای اطمینان از کیفیت کد‌ها کنترل می‌شود، اما فرهنگ به گونه‌ای هست که هر مهندس را تشویق می‌کند تا در پروژه‌های مختلف مشارکت کنند و احساس مسئولیت جمعی برای دارایی‌های نرم‌افزاری شرکت را تقویت کند.توسعه همیشه روی head یا آخرین ورژن هست نه بر روی برنچ‌ها. این کار مشکلات merg و integrity را کاهش می‌دهد.سیستم‌های تست خودکار بر روی توسعه‌ها مرتبا در حال اجرا هست.موضوعات مالکیت کد‌ها هست از این جهت که کاملا مشخص است چه کدی را چه کسی زده است و آن شخص می تواند روی آن قسمت دسترسی‌هایی ایجاد کند و یا تغییری بدهد. این موضوع را در مخزن‌های مدیرت subtreeها می‌گویند و این باعث می‌شود که آن شخصی که تغییری را ایجاد می‌کند همان شخصی هست که بیشترین عمق شناخت از کد را دارد.1-2 سیستم Build در گوگلگوگل از یک سیستم ‌build توزیع شده به نام Blaze استفاده می کند تا فرآیند توسعه نرم افزار خود را ساده کند. Blaze عملیات کامپایل، Link، و تست نرم افزار را انجام می دهد و دستورات استانداردی را برای این وظایف در کل مخزن کد Google ارائه می دهد. بهینه‌سازی و یکنواختی آن، مراحل ساخت و تست را برای مهندسان ساده و تسریع می‌کند، و آنها را قادر می‌سازد تا به طور مؤثر روی پروژه‌هایی که فراتر از حوزه کاری خود هستند، کار کنند و در آنها مشارکت کنند. این سیستم یک محیط توسعه مشارکتی و انعطاف پذیر را فراهم کرده است.در فرآیند توسعه گوگل، برنامه نویسان فایل های “BUILD” را ایجاد می کنند که پیکربندی‌های Blaze است و این سیستم با استفاده از این فایل عملیات Build را انجام می‌دهد. این فایل ها حاوی دستورالعمل های سطح بالا یا "مشخصات ساخت" برای اجزای مختلف نرم افزار مانند کتابخانه ها، برنامه ها و تست ها هستند.در فرآیندBuild گوگل، هر مرحله Build به گونه‌ای طراحی می‌شود که «hermetic» باشد، به این معنی که صرفاً فقط از ورودی های صراحتاً اعلام شده خود استفاده می کند. این تضمین می کند که سیستم ‌Build به طور دقیق همه وابستگی‌ها را دارد، زیرا تنها ورودی های اعلام شده به ماشینی که Build را انجام می دهد ارائه می شود. این رویکرد به کامپایلرهای مورد استفاده در فرآیند Build، که به عنوان ورودی نیز در نظر گرفته می شوند، گسترش می یابد. این اصل hermetic، قابلیت اطمینان سیستم ‌Build را در مدیریت موثر وابستگی ها تضمین می کند.سیستم Build گوگل تضمین می کند که هر مرحله Build قطعی است، به این معنی که به طور مداوم خروجی یکسانی را با همان ورودی تولید می کند. این اجازه می دهد تا نتایج Build در کش ذخیره شود، و مهندسان نرم افزار را قادر می سازد تا به نسخه قبلی کار خود بازگردند و دقیقا همان باینری را بازتولید کنند. ماهیت قطعی فرآیند Build همچنین به این معنی است که این نتایج ذخیره شده در کش می توانند به طور ایمن بین کاربران مختلف به اشتراک گذاشته شوند و کارایی و همکاری را افزایش دهند. دستیابی به این امر مستلزم حذف هر چیز رندومی در ابزارهای Build، مانند حذف time stamp از فایل های خروجی برای اطمینان از نتایج ثابت است.سیستم ‌Build گوگل برای قابلیت اطمینان بالا طراحی شده است و نه تنها تغییرات کد، بلکه تغییرات در قوانین Build را ردیابی می کند. اگر تغییری در نحوه Build چیزی ایجاد شود، مانند تغییر در گزینه های کامپایلر بدون تغییر فایل های ورودی، سیستم به طور خودکار می داند که قسمت های آسیب دیده را بازسازی کند. علاوه بر این، وقفه‌ها را به خوبی مدیریت می کند. اگر یک Build در میانه راه متوقف شد یا اگر فایل ها در طول Build تغییر کردند، به سادگی راه اندازی مجدد دستور Build کافی است. هیچ نیازی به فرآیندهای پاکسازی دستی مانند «make clean» و streamlining development نیست.سیستم Build گوگل نتایج Build را کش می‌کند و علاوه بر آن نتایج میانی را هم ذخیره می‌کند و در نهایت در فضای ابری ذخیره می‌کند. این راه‌اندازی به آن اجازه می‌دهد تا به طور مؤثر از این نتایج برای درخواست‌های Build بعدی که به نتایج یکسانی نیاز دارند، استفاده مجدد کند و از Rebuild غیرضروری اجتناب کند. این ویژگی به طور کلی اعمال می‌شود، حتی زمانی که درخواست‌هایی از سوی کاربران مختلف ارائه می‌شود، کارایی را افزایش می‌دهد و زمان Build را در سراسر ‍‍‍‍‍‍پروژه کاهش می‌دهد.عملیات Rebuild تدریجی سریع است. سیستم Build در حافظه باقی می ماند به طوری که برای Rebuild می تواند به صورت تدریجی فقط فایل‌هایی را که از آخرین Build تغییر کرده اند تجزیه و تحلیل کند.1-3 باز نگری کد در گوگلگوگل ابزارهای مبتنی بر وب پیشرفته‌ای را برای بررسی کد، توسعه داده است که با ایمیل یکپارچه شده اند و روند بررسی را ساده می کند. این ابزارها با رنگبندی‌هایی که روی متن‌ها ایجاد می‌کنند راحتی کار را برای کسی که بازنگری می‌کند و کسی برنامه نویسی می‌کند فراهم کرده‌اند. وقتی بازنگری (code review) درخواست می‌شود، بازنگر از طریق ایمیل مطلع می‌شوند که یک لینک به تغییر خاص است که در ابزار مشخص است. آنها همچنین پس از ارسال نظرات بررسی، ایمیل را دریافت می کنند. علاوه بر این، سیستم‌های خودکار با ارسال اعلان‌هایی درباره نتایج تست یا یافته‌های ابزارهای تحلیل استاتیک، این فرآیند را بهبود می‌بخشند و یک گردش کار بررسی جامع و کارآمد را ارائه می‌دهند.فرآیند‌های Google موظف می‌کند که هر تغییری که در مخزن کد اصلی ایجاد می‌شود، توسط حداقل یک مهندس دیگر برای تضمین کیفیت بررسی شود. علاوه بر این، اگر شخصی که تغییر را انجام می‌دهد مالک فایل‌های در حال تغییر نیست، حداقل یکی از صاحبان فایل باید اصلاحات را بررسی و تأیید کند و اطمینان حاصل کند که تغییرات توسط کسانی که بیشتر با محتوا آشنا هستند نظارت می‌شوند.در شرایط اضطراری، صاحب کد می‌تواند تغییراتی را در بخش مخزن خود بدون بررسی قبلی انجام دهد. با این حال، باید یک بازنگر به آن تغییر اختصاص داده شود و تا زمانی که تغییر، بررسی و تایید نشود، هم فرد تغییر دهنده و هم بازنگر، یادآوری دریافت خواهند کرد. اگر بازنگر مشکلاتی را شناسایی کرد، هر گونه اصلاحات لازم باید از طریق ارسال جدید انجام شود، زیرا تغییر اولیه قبلاً در پایگاه کد ادغام شده است.گوگل از ابزارهای خودکار برای توصیه به بازنگران احتمالی برای تغییرات کد استفاده می‌کند، بر اساس عواملی مانند مالکیت کد، نویسنده، سابقه افرادی که تغییرات مشابه را بررسی کرده‌اند، و حجم کار بررسی فعلی هر نامزد. در حالی که حداقل یکی از مالکان ناحیه کد تحت تأثیر این تغییر باید آن را تأیید کند، نویسنده این امکان را دارد که بازنگر‌های دیگری را بر اساس اولویت خود انتخاب کند.چالشی که در فرآیند بررسی کد وجود دارد، احتمال تأخیر در صورت کندی بازنگران در تأیید تغییرات است که می تواند توسعه را کند کند. با این حال، گوگل با فراهم کرده اجازه‌هایی برای برنامه نویس، این مشکل را کاهش می دهد. این انعطاف‌پذیری به مهندسان اجازه می‌دهد تا بازنگر‌هایی را انتخاب کنند که بسته به پیچیدگی تغییر، سریع‌تر و مناسب‌تر پاسخ دهند، در نتیجه سرعت توسعه را با دوری از بازنگر‌های بیش از حد محتاط یا صاحب نظر برای به‌روزرسانی‌های ساده، حفظ کرده و بازنگر‌های با تجربه‌تر را برای تغییرات پیچیده انتخاب کنند.گوگل به طور خودکار بحث‌های بازنگری کد پروژه‌ها را به لیست ایمیل خاصی که توسط نگهدارند‌های پروژه مدیریت می شود ارسال می کند. این راه‌اندازی به هر کسی اجازه می‌دهد تا در هر زمانی قبل یا بعد از ایجاد تغییر، بدون توجه به نقش رسمی خود به‌عنوان بازنگر، درباره هر تغییر پیشنهادی نظر دهد. اگر یک اشکال بعداً شناسایی شود، این یک روش معمول است که تغییری را که باعث آن شده است پیدا کنند و در موضوع بررسی اصلی اظهار نظر کنند. این تضمین می کند که هم شخصی که تغییر را ایجاد کرده و هم بازنگران در مورد موضوع برای ارجاع و یادگیری در آینده مطلع می شوند.گوگل اجازه می‌دهد تغییرات کد توسط چندین نفر بررسی شود و به محض اینکه یک بازنگر، که باید مالک یا نویسنده باشد، آن را تأیید کند، اجازه می‌دهد تغییر انجام شود. این فرآیند می‌تواند حتی قبل از اینکه دیگر بازبینان بازخورد خود را ارائه دهند، رخ دهد. هر گونه نظر اضافی از بازبینان را می توان در به روز رسانی های بعدی بررسی کرد. این رویکرد به سرعت بخشیدن به روند بررسی با اجازه دادن به تأییدها و تنظیمات سریعتر بر اساس بازخورد کمک می کند.مخزن Google شامل یک بخش "تجربه" است که در آن قوانین سختگیرانه بررسی کد اعمال نمی شود. با وجود این، برای استفاده از کد در production، باید در بخش اصلی مخزن قرار گیرد. مهندسان به شدت تشویق می شوند که از همان ابتدا در بخش اصلی کار کنند و تأکید می کنند که بررسی کد در طول توسعه به جای بعد از آن سودمندتر است. با این وجود، معمولاً مهندسان به دنبال بررسی برای کار در بخش آزمایشی هستند و به بهترین شیوه ها برای تضمین کیفیت پایبند هستند.گوگل مهندسان خود را تشویق می‌کند تا تغییرات کوچک و قابل مدیریتی در کد ایجاد کنند، و پیشنهاد می‌کند که به‌روزرسانی‌های بزرگ‌تر باید به قطعات کوچک‌تر و قابل بررسی‌تر تقسیم شوند. این رویکرد نه تنها فرآیند بررسی را تسهیل می‌کند، بلکه به نویسندگان اجازه می‌دهد تا بازخورد را با سهولت بیشتری اجرا کنند. برای ترویج این عمل، ابزارهای بررسی کد گوگل تغییرات را بر اساس اندازه طبقه‌بندی می‌کنند، با برچسب‌هایی از «medium-size» برای تغییراتی که بر 30 تا 99 خط تأثیر می‌گذارند تا توصیف‌کننده‌هایی مانند «large» یا «freakin huge» برای تغییرات اساسی‌تر. این سیستم، در حالی که کاربردی است، اما با گیمیفیکیشن‌های خاصی به فرآیند‌ها تزریق می‌شود.1-4 تستگوگل تاکید زیادی بر تست واحد دارد و انتظار دارد تمام کدهای production با تست های واحد همراه باشد. ابزارهای بازبینی کد به طور خودکار هر فایل منبع جدیدی را که فاقدunit test است علامت گذاری می کند. بررسی‌کنندگان معمولاً اصرار دارند که هرگونه افزودن ویژگی‌های جدید با تست‌های جدید تطبیق داده شود تا اطمینان حاصل شود که عملکرد همانطور که در نظر گرفته شده است کار می‌کند. برای راحت کردن تست، حتی برای کدهایی که به کتابخانه های پیچیده وابسته هستند، مهندسان گوگل اغلب از mocking frameworks استفاده می کنند که امکان ایجاد تست های کارآمد و سبک را فراهم می کند.تست یکپارچه سازی و تست رگرسیون نیز به طور گسترده انجام می شود.گوگل همچنین ابزارهای خودکاری برای اندازه گیری test coverage دارد. نتایج همچنین به عنوان یک لایه اختیاری در مرورگر کد یکپارچه شده است.گوگل قبل از استقرار نرم‌افزار، تست load را الزامی می‌کند و تیم‌ها را ملزم می‌کند تا نحوه عملکرد سیستم در شرایط فشار مستند کنند. این شامل تولید داده‌هایی مانند جداول یا نمودارها است که شاخص‌های عملکرد کلیدی مانند تاخیر و نرخ خطا را در پاسخ به سطوح مختلف درخواست‌های کاربر نشان می‌دهند. این عمل تضمین می کند که سیستم ها در شرایط دنیای واقعی قوی و قابل اعتماد هستند.1-5 ردیابی bugگوگل از یک ابزار ردیابی bugبه نام Buganizer برای مدیریت مسائل مختلف از جمله bug، درخواست‌های featureو مشکلات مشتری، در کنار ردیابی انتشار و عملیات پاکسازی استفاده می‌کند. مشکلات موجود در Buganizerبه دسته‌هایی با قابلیت تخصیص کنترل‌کننده‌های پیش‌فرض و اطلاع دادن به اشخاص مربوطه از طریق ایمیل، سازمان‌دهی شده‌اند. مهندسان تشویق می شوند تا هرگونه تغییر کد ارائه شده برای بررسی را به versionهای خاص مرتبط کنند و ردیابی و حل مشکل سازمان یافته و کارآمد را تسهیل کنند و کاملا بفهمند که چه bugای در چه نسخه‌ای بوده و در چه وضعیتی هست.1-6 زبان‌های برنامه نویسیمهندسان نرم افزار در گوگل به شدت تشویق می شوند که به یکی از پنج زبان برنامه نویسی رسمی تایید شده در گوگل برنامه نویسی کنند: C++، Java، Python، Go یا JavaScript. به حداقل رساندن تعداد زبان های برنامه نویسی مختلف استفاده شده، موانع استفاده مجدد از کد و همکاری برنامه نویس را کاهش می دهد.گوگل برای اطمینان از سازگاری در code style، طرح‌بندی، و قراردادهای نام‌گذاری، راهنماهایی را برای زبان‌های برنامه‌نویسی مختلف حفظ می‌کند. علاوه بر این، گوگل یک برنامه آموزشی خوانایی کد را اجرا کرده است که در آن مهندسان با تجربه دیگران را در نوشتن کد واضح راهنمایی می کنند. این شامل بررسی تغییرات قابل توجه کد است تا زمانی که مربی از توانایی مربی در نوشتن کد قابل خواندن مطمئن شود. هر کد جدید قابل توجهی باید تاییدیه شخصی دریافت کند که استانداردهای خوانایی زبان را تایید کرده است و اهمیت کد واضح و قابل نگهداری را تقویت می کند.گوگل ارتباط بین زبان های برنامه نویسی مختلف را عمدتاً از طریق Protocol Buffers تسهیل می کند، روشی برای رمزگذاری موثر داده های ساختاریافته. بافرهای پروتکل شامل یک زبان تخصصی برای تعریف ساختارهای داده و یک کامپایلر است که کدی را برای مدیریت این ساختارهای داده در C++، جاوا و پایتون تولید می کند. این سیستم، که با کتابخانه‌های (RPC) Google یکپارچه شده است، به RPC‌های چندزبانه ساده اجازه می‌دهد تا به‌طور خودکار سریال‌سازی و سریال‌زدایی داده‌ها را در محیط‌های برنامه‌نویسی مختلف مدیریت کنند.گوگل فرآیند توسعه نرم افزار خود را با استفاده از مجموعه ای یکپارچه از دستورات برای وظایف مهندسی رایج در پایگاه کد گسترده و زبان های برنامه نویسی مختلف ساده می کند. این استانداردسازی به این معنی است که توسعه‌دهندگان می‌توانند بدون توجه به پروژه یا زبانی که با آن کار می‌کنند check out, edit, build, test, review, commit و گزارش باگ را با استفاده از دستورات مشابه انجام دهند. در نتیجه، توسعه دهندگان می توانند به راحتی بین پروژه ها بدون نیاز به یادگیری فرآیندهای جدید جابجا شوند و کارایی و سادگی در کار توسعه را افزایش دهند.1-7 رفع اشکال و ابزار‌های profilingگوگل اشکال زدایی سرور را با کتابخانه های مجهز به ابزارهایی که ثبت و تجزیه و تحلیل خطا را خودکار می کند، افزایش می دهد. در صورت خرابی سرور، این ابزارها به‌طور خودکار گزارش‌های خطا، از جمله stack tracesو core files را ضبط و ثبت می‌کنند. آنها همچنین می توانند مسائلی مانند سرریز حافظه را با logging the memory allocation at fault در خطا شناسایی کنند. به‌علاوه، Google رابط‌های وب را برای اشکال‌زدایی عمیق ارائه می‌کند، اطلاعاتی در مورد ارتباطات سرور، معیارهای عملکرد، و استفاده از منابع سیستم ارائه می‌دهد. این قابلیت‌ها امکان تنظیمات دقیق و عیب‌یابی را فراهم می‌کنند، و اغلب نیاز به روش‌های عیب‌یابی سنتی مانند استفاده از gdb را از بین می‌برند، بنابراین فرآیند اشکال‌زدایی را به طور قابل توجهی ساده می‌کنند.1-8 مهندسی انتشار یا Release engineerinبرای انتشار چندین مهندس متخصص مجزا وجود دارد، اما برای اکثر تیم‌های گوگل، کار مهندسی انتشار توسط مهندسان نرم‌افزار معمولی انجام می‌شود.هدف گوگل، انتشار نرم‌افزارهای مکرر - هفتگی، دو هفته‌ای یا حتی روزانه برای برخی تیم‌ها - از طریق اتوماسیون گسترده فرآیندهای انتشار است. این چرخه انتشار سریع، انگیزه مهندس را افزایش می دهد و با فعال کردن تکرارهای بیشتر سرعت توسعه را تسریع می کند. انتشار مکرر به معنای فرصت های بیشتر برای بازخورد و پاسخ به موقع به آن بازخورد است که کیفیت و ارتباط نرم افزار را افزایش می دهد.فرآیند انتشار گوگل با راه‌اندازی یک فضای کاری جدید و استفاده از آخرین buildهای مطمئن به عنوان پایه برای ایجاد release branch آغاز می‌شود. سپس مهندس انتشار ممکن است به روز رسانی های خاصی را برای گنجاندن در این branch انتخاب کند. در ادامه این نرم افزار به صورت جامع بازسازی و تست می شود. اگر هر مشکلی شناسایی شود، برطرف می‌شود و به‌روزرسانی‌ها به branchانتشار اضافه می‌شوند و سپس یک دور دیگر build و آزمایش انجام می‌شود. این چرخه تا زمانی ادامه می‌یابد که نرم‌افزار تمام تست‌ها را پشت سر بگذارد و در این مرحله برای انتشار پکیج می‌شود. این فرآیند تا حد زیادی خودکار است و به مهندس انتشار اجازه می‌دهد آن را با دستورات ساده یا از طریق یک رابط کاربر پسند مدیریت کند و آماده‌سازی انتشار را ساده‌تر کند.هنگامی که یک build کاندید پکیج شد، معمولاً برای تست یکپارچه سازی بیشتر توسط مجموعه کوچکی از کاربران (گاهی اوقات فقط تیم توسعه) روی یک سرور "stage" بارگذاری می شود.تکنیکی که توسط Google به کار می‌رود شامل mirror کردن بخشی از درخواست‌های کاربران live به یک سرور stage است، در حالی که درخواست‌های واقعی توسط سرورهای productionپردازش می‌شوند. پاسخ‌های سرور stageاستفاده نمی‌شود، اما این راه‌اندازی به Google اجازه می‌دهد تا بررسی کند که چگونه محیط استیجینگ، ترافیک واقعی را مدیریت می‌کند. این روش به شناسایی و حل مشکلات احتمالی، مانند خرابی سرور، در مرحله قبل از تأثیرگذاری بر محیط تولید کمک می‌کند و از ثبات و قابلیت اطمینان در استقرارهای زنده اطمینان می‌دهد.پس از تست اولیه، گوگل معمولاً به استقرار به‌روزرسانی‌ها روی سرورهای «قناری» می‌رود که ترافیک واقعی کاربر را در مقیاس کوچک‌تر مدیریت می‌کنند. این مرحله امکان آزمایش مستقیم تغییرات را با کاربران واقعی فراهم می‌کند، اما تأثیر بالقوه را محدود می‌کند. در صورت موفقیت آمیز بودن، به‌روزرسانی به تدریج در طول چند روز در تمام سرورهای مراکز داده، به‌ویژه برای سرویس‌های حیاتی ارائه می‌شود. این رویکرد مرحله‌ای با هدف به حداقل رساندن اختلالات ناشی از باگ‌های کشف‌نشده احتمالی، تضمین انتقال روان به نسخه جدید است.1-9 تایید راه اندازیقبل از اینکه Google بتواند تغییرات قابل مشاهده برای کاربران یا به‌روزرسانی‌های قابل توجه طراحی را منتشر کند، این تغییرات باید توسط سهامداران مختلف فراتر از تیم مهندسی اصلی تأیید شود. این فرآیند بررسی کامل، انطباق با استانداردهای قانونی، حریم خصوصی، امنیت، و قابلیت اطمینان و سایر الزامات را تضمین می کند. این شامل بررسی های مربوط به پایبندی به اهداف تجاری و گنجاندن مکانیسم هایی مانند نظارت خودکار برای مسائلی مانند قطع شدن سرور است، اطمینان از اینکه به روز رسانی قوی و مطابق با سیاست های شرکت و انتظارات کاربر است.گوگل از یک ابزار داخلی تخصصی برای مدیریت و پیگیری فرآیند بررسی و تأیید برای راه اندازی محصول استفاده می کند. این ابزار تضمین می‌کند که هر محصول به رویه‌های راه‌اندازی خاص خود، از جمله بررسی‌های انطباق و تأییدیه‌ها پایبند است. به گونه‌ای طراحی شده است که انعطاف‌پذیر باشد و امکان سفارشی‌سازی برای نیازهای مختلف محصولات یا مناطق مختلف را فراهم کند، بنابراین فرآیند راه‌اندازی را ساده‌تر می‌کند و در عین حال استانداردهای بالایی را برای هر نسخه حفظ می‌کند.1-10 پس از فاجعه یا مرگ (Post-mortems)پس از یک قطعی یا مشکل قابل توجه در سیستم های production، پرسنل درگیر باید یک سند Post-mortems جمع آوری کنند. این گزارش جزئیات این حادثه را شامل ماهیت، اثرات، توالی رویدادها، علل ریشه‌ای و پاسخ‌های مؤثر و غیرمؤثر آن است. تاکید بر درک موضوع و راهبردهای پیشگیری، اجتناب از سرزنش شخصی است. با اندازه‌گیری زمان خرابی، اختلالات خدمات و پیامدهای مالی، تأثیر قطعی را ارزیابی می‌کند. این سند همچنین جدول زمانی حادثه را از شروع تا حل مشخص می کند و ارزیابی می کند که چه اقداماتی در رسیدگی به مشکل موفق بوده یا نه. درس‌های آموخته‌شده برای راهنمایی بهبودهای آینده و به حداقل رساندن بازگشت، با اقدامات بعدی خاص برای رفع کاستی‌های شناسایی‌شده مشخص می‌شوند.1-11 بازنویسی های مکررگوگل به طور مکرر نرم افزار خود را به روز می کند، معمولاً هر چند سال یک بار آن را بازنویسی می کند تا اطمینان حاصل کند که با پیشرفت های تکنولوژیکی و نیازهای در حال تکامل کاربر مطابقت دارد.در حالی که بازنویسی منظم نرم افزار بخش قابل توجهی از منابع Googleرا مصرف می کند، این استراتژی است که مزایای کلیدی را برای چابکی و موفقیت پایدار شرکت ارائه می دهد. با تکامل فناوری و نیازهای کاربر، نیازهای نرم افزار تغییر می کند و برنامه های قدیمی را کارآمدتر یا مرتبط تر می کند. نرم‌افزار بازنویسی نه تنها پیچیدگی‌های قدیمی را حذف می‌کند، بلکه پایگاه کد را نیز جوان‌سازی می‌کند و اطمینان می‌دهد که نیازهای فعلی را برآورده می‌کند. این فرآیند همچنین اعضای جدیدتر تیم را درگیر می‌کند و حس مالکیت و بهره‌وری را القا می‌کند، زیرا مهندسان انگیزه بیشتری برای کار روی کدهایی دارند که آنها را متعلق به خود می‌دانند. به‌علاوه، بازنویسی‌های مکرر محیطی پویا را ایجاد می‌کند که در آن مهندسان بین پروژه‌ها حرکت می‌کنند، تبادل ایده‌ها را ترویج می‌کنند و اطمینان می‌دهند که نرم‌افزار Google از آخرین پیشرفت‌ها و روش‌های فناوری استفاده می‌کند.2 مدیریت پروژه2-1 بیست درصد زمانگوگل به مهندسان اجازه می‌دهد تا ۲۰ درصد از زمان خود را به پروژه‌های مورد نظر خود اختصاص دهند و فرهنگ اعتماد و نوآوری را تقویت کنند. این سیاست مزایای متعددی دارد: کاوش و توسعه ایده‌های جدیدی را که در غیر این صورت ممکن است مورد توجه قرار نگیرند را امکان‌پذیر می‌سازد، شفافیت پروژه‌های نوآورانه را برای مدیریت تضمین می‌کند، با اجازه دادن به مهندسان برای کار بر روی پروژه‌های پرشور در کنار وظایف معمول، از فرسودگی جلوگیری می‌کند و به طور قابل توجهی بهره‌وری و انگیزه را افزایش می‌دهد. علاوه بر این، این روش فرهنگ نوآوری را در شرکت ترویج می کند، زیرا مهندسان از دیدن همکاران خود در پروژه های خلاقانه و تجربی الهام می گیرند. به طور کلی، قانون 20 درصد یک رویکرد استراتژیک برای پرورش استعدادها و تشویق نوآوری مستمر در گوگل است.2-2 اهداف و نتایج کلیدی (OKR)در Google، افراد و تیم‌ها موظف هستند اهداف روشنی را تعیین و مستند کنند، سپس پیشرفت خود را به سمت این اهداف از طریق اهداف فصلی و سالانه دنبال کنند. این اهداف با نتایج کلیدی قابل اندازه‌گیری و همسویی با اهداف گروهی و کلی شرکت، کمیت می‌شوند. پیشرفت در پایان هر کوارتر ارزیابی می شود و هر گل در مقیاسی از 0.0 تا 1.0 به ثمر می رسد که نشان دهنده میزان تکمیل است. اگرچه این اهداف و نتایج کلیدی (OKR) و امتیازات آن‌ها عموماً در گوگل شفاف هستند، اما مستقیماً برای ارزیابی عملکرد استفاده نمی‌شوند. این سیستم همسویی اهداف را در سطوح مختلف سازمان تضمین می کند و فرهنگ مسئولیت پذیری و پیگیری پیشرفت را ترویج می کند.رویکرد گوگل برای تعیین اهداف و نتایج کلیدی (OKR) از هدف گذاری جاه طلبانه با هدف میانگین نمره ایده آل 65 درصد حمایت می کند. این تیم ها را تشویق می کند تا حدود 50٪ بیشتر از آنچه که ممکن است به طور واقعی به آن دست یابند، کارهایی را هدف قرار دهند. تیم هایی که از این هدف بهتر عمل می کنند، انگیزه بیشتری برای هدف گذاری در سه ماهه بعدی دارند، در حالی که به آنهایی که امتیازهای زیر را کسب می کنند، توصیه می شود OKRخود را طوری تنظیم کنند که دست یافتنی تر باشد و از تعادل بین جاه طلبی و عملی بودن در هدف گذاری اطمینان حاصل کنند.موضوع OKRها در Googleبه عنوان ابزاری حیاتی برای ترسیم و انتقال اهداف در سراسر شرکت عمل می‌کنند و فرهنگ عملکرد بالا را از طریق مشوق‌های اجتماعی پرورش می‌دهند. اگرچه OKRها مستقیماً بر بررسی عملکرد یا جبران خسارت تأثیر نمی‌گذارند، آگاهی از اینکه دستاورد آنها در جلسات تیم بررسی و امتیازدهی می‌شود، مهندسان را برای برتری انگیزه می‌دهد. با تنظیم نتایج کلیدی واضح، عینی و قابل اندازه‌گیری، OKRها تمایل کارکنان را برای عملکرد خوب به سمت فعالیت‌هایی هدایت می‌کنند که به‌طور محسوسی اهداف جمعی شرکت را پیش می‌برد و اطمینان حاصل می‌کند که تلاش‌ها همسو و تاثیرگذار هستند.2-3 تایید پروژهدر حالی که گوگل فرآیند روشنی برای تایید راه اندازی دارد، این شرکت فاقد یک سیستم یکسان برای تایید یا لغو پروژه ها است. تصمیم گیری در سازمان متفاوت است و مدیران در سطوح مختلف در مورد پروژه های تیم خود صلاحدید خود را اعمال می کنند. در برخی موارد، تصمیمات پروژه از پایین به بالا گرفته می شود و به مهندسان امکان می دهد پروژه های خود را انتخاب کنند. برعکس، در سناریوهای دیگر، تصمیمات از بالا به پایین است و مدیران یا مدیران جهت پروژه، تخصیص منابع و لغو را تعیین می کنند. این انعطاف پذیری در مدیریت پروژه نشان دهنده رویکرد متنوع گوگل به نوآوری و نظارت بر پروژه است.2-4 سازماندهی مجدد شرکت هادر Google، تصمیمات اجرایی می‌تواند منجر به لغو پروژه‌های بزرگ یا ادغام پروژه‌های پراکنده جغرافیایی شود و مهندسان را ملزم به یافتن نقش‌ها یا تیم‌های جدید کند. در طول چنین سازمان‌دهی‌هایی، مهندسان معمولاً این آزادی را دارند که موقعیت‌های جدید را در محل خود انتخاب کنند یا در موارد ادغام، گزینه جابجایی برای ادامه تیم فعلی خود را دارند. سازمان‌دهی مجدد شرکت‌ها، از جمله ادغام یا تقسیم تیم‌ها و تغییرات در ساختارهای گزارش‌دهی، در Google نسبتاً رایج هستند. این تنظیمات برای حفظ کارایی و انطباق با فناوری‌ها و الزامات در حال تحول ضروری تلقی می‌شوند، با هدف جلوگیری از تأثیرگذاری بیش از حد ساختار سازمان بر طراحی و عملکرد محصولاتش.2-5 هفته‌های hackسالانهگوگل با میزبانی سالانه hackathons یک هفته ای، نوآوری را تقویت می کند و به مهندسان اجازه می دهد از وظایف معمول خود برای توسعه پروژه های جدید منحرف شوند. این رویدادها با جلسه ای شروع می شوند که در آن ایده ها مطرح می شوند و منجر به تشکیل تیم‌هایی می شود که روی ایجاد دمو یا نمونه های اولیه کار می کنند. نقطه اوج هفته یک جلسه ارائه است که در آن پروژه‌ها به نمایش گذاشته می‌شوند و جوایز کوچکی اعطا می‌شوند، اگرچه بزرگترین پاداش این است که یک پروژه hackathonsبه یک پروژه در مقیاس کامل تبدیل شود. علیرغم تشویق رسمی، مشارکت واقعی به دلیل تقاضاهای شغلی روزانه نسبتاً کم است، با 5 تا 20٪ از مهندسان شرکت می کنند، اگرچه بسیاری دیگر به ارائه های اولیه و پایانی علاقه نشان می دهند و از نوآوری های نمایش داده شده الهام می گیرند.3 مدیریت افراد3-1 نقش‌هاگوگل مسیرهای شغلی متمایزی برای مهندسی و مدیریت دارد که به وضوح نقش رهبران فناوری را از مدیران متمایز می کند. این ساختار همچنین تحقیقات را مستقیماً در تیم‌های مهندسی ادغام می‌کند و از طریق نقش‌هایی مانند مدیران محصول، مدیران پروژه، و مهندسین قابلیت اطمینان سایت (SREs)، پشتیبانی جامع را فراهم می‌کند و فرهنگ قوی نوآوری را تقویت می‌کند. در حوزه مهندسی، گوگل نقش‌های مختلفی را ارائه می‌کند که هر کدام دارای یک پیشرفت شغلی تعریف‌شده، از جمله سطوح متعدد و فرصت ارتقاء هستند، که با مزایایی مانند افزایش حقوق همراه است. این رویکرد شناخت عملکرد را تضمین می کند و از توسعه شغلی در شرکت پشتیبانی می کند.نقش‌های اساس عبارتند از:3-1-1 مدیر مهندسان یا Engineering Managerمدیران مهندسی در گوگل، اغلب با پیشینه مهندسان نرم افزار، نقش اصلی مدیریت افراد در شرکت را تشکیل می دهند که دارای مهارت های فنی و بین فردی هستند. برخلاف مدیران فنی، که بر هدایت جهت فنی پروژه ها تمرکز می کنند، مدیران مهندسی بیشتر درگیر مدیریت افراد از جمله انتخاب رهبران فنی، نظارت بر عملکرد تیم، مربیگری، توسعه شغلی، ارزیابی عملکرد و جنبه های پاداش و استخدام هستند. به طور معمول، یک مدیر مهندسی بر 3 تا 30 نفر نظارت می کند که 8 تا 12 نفر رایج ترین محدوده هستند. این تعیین تمایز واضح بین توسعه پروژه پیشرو و پویایی تیم مدیریت را تضمین می کند.3-1-2 مهندسان نرم افزار یا (SWE)نقش مهندس نرم‌افزار در میان کسانی که توسعه نرم‌افزار را در گوگل انجام می‌دهند رایج‌ترین نقش است، جایی که معیارهای انتخاب به‌طور مشخص برای اطمینان از خروجی‌های با کیفیت بالا و مشکلات نرم‌افزاری کمتری سخت‌گیرانه هستند. Googleمسیرهای شغلی متمایزی را برای مهندسی و مدیریت حفظ می‌کند و به مهندسان نرم‌افزار اجازه می‌دهد بدون اینکه لزوماً نقش‌های مدیریت افراد را بر عهده بگیرند، پیشرفت کنند. رهبری در سطوح ارشد به طور گسترده تعریف شده است، از جمله کمک های قابل توجهی به توسعه نرم افزار، افراد با تخصص فنی قوی اما تمایل کمتری به مدیریت را قادر می سازد تا شغل خود را ارتقا دهند. این رویکرد از سناریویی که اغلب در سازمان‌های دیگر دیده می‌شود، جلوگیری می‌کند، که در آن افراد نقش‌های مدیریتی را صرفاً برای پیشرفت شغلی دنبال می‌کنند و این امر به‌طور بالقوه به قیمت از دست دادن رهبری مؤثر تیم انجام می‌شود.3-1-3 محققان یا Research Scientistگوگل استانداردهای استخدامی بسیار بالایی را برای نقش دانشمند پژوهشی تعیین می کند و نه تنها به یک سابقه اثبات شده در تحقیقات، همانطور که توسط انتشارات نشان داده شده است، بلکه همچنین مهارت کدنویسی را می طلبد. علیرغم واجد شرایط بودن بسیاری از دانشگاهیان برای موقعیت های مهندسی نرم افزار، همه نمی توانند معیارهای یک دانشمند پژوهشگر در گوگل را برآورده کنند. دانشمندان پژوهشگر و مهندسان نرم افزار در گوگل در حالی که عناوین متمایز دارند، مسئولیت های زیادی از جمله انجام تحقیقات اصلی، توسعه فناوری های جدید و نوشتن کد را به اشتراک می گذارند. این همکاری که اغلب روی پروژه‌های مشابهی با هم کار می‌کنند، ادغام یکپارچه تحقیقات نوآورانه را در محصولات کاربردی و آماده بازار تسهیل می‌کند، که نمونه‌ای از رویکرد Googleبرای ترکیب تحقیقات با مهندسی است.3-1-4 مهندسان اطمینان سایت یا Site Reliability Engineerدر Google، تعمیر و نگهداری سیستم‌های عملیاتی توسط تیم‌های مهندسی نرم‌افزار به جای مدیران سیستم سنتی انجام می‌شود و مهندسان قابلیت اطمینان سایت (SRE) نقش کلیدی را ایفا می‌کنند. معیارهای موقعیت‌های SREبا معیارهای مهندسین نرم‌افزار کمی متفاوت است و به طیف وسیع‌تری از تخصص اجازه می‌دهد. در حالی که سطح مهارت مهندسی نرم افزار مورد نیاز برای SRE ها ممکن است انعطاف پذیرتر باشد، این می تواند با دانش قوی در زمینه هایی مانند شبکه یا سیستم یونیکس متعادل شود. مشخصات نقش SRE و اهمیت آن به طور گسترده در کتاب SREشرح داده شده است و عملکرد مهم آن را در چارچوب عملیاتی Google برجسته می کند.3-1-5 مدیر محصولمدیران محصول در گوگل نقش مهمی در نظارت بر توسعه و مدیریت محصولات دارند. آنها در نقش حامیان کاربر، مهندسان نرم‌افزار را با اولویت‌بندی ویژگی‌ها، همکاری با تیم‌های دیگر، مدیریت باگ‌ها و زمان‌بندی‌ها، و اطمینان از در دسترس بودن تمام منابع لازم برای ایجاد محصولات با کیفیت بالا راهنمایی می‌کنند. در حالی که معمولاً در کدنویسی دخالتی ندارند، مدیران محصول از نزدیک با مهندسان کار می کنند تا اطمینان حاصل کنند که توسعه با دیدگاه محصول و نیازهای کاربر همسو است.3-1-6 مدیر برنامه یا برنامه فنی Program Manager / Technical Program Managerمدیران برنامه در Google، دقیقاً مانند مدیران محصول، به جای خود محصولات، بر اجرای پروژه‌ها، فرآیندها یا عملیات نظارت می‌کنند و بر جنبه‌هایی مانند جمع‌آوری داده‌ها تمرکز می‌کنند. مدیران برنامه های فنی، زیرمجموعه ای از این نقش، با نیازشان به مهارت های فنی خاص مرتبط با پروژه هایشان، مانند تخصص زبان شناسی برای پروژه های داده گفتاری، متمایز می شوند. نسبت مهندسان نرم‌افزار به مدیران محصول و برنامه در Googleنسبتاً بالا است، معمولاً از 4:1 تا 30:1 متغیر است، که نشان‌دهنده تأکید شدید بر مهندسی در چارچوب مدیریت پروژه و محصول شرکت است.4 امکاناتمحل کار Google به گونه ای طراحی شده است که هم سرگرم کننده و هم کاربردی باشد و دارای امکاناتی مانند سرسره، گودال توپ، اتاق بازی، کافه رایگان، و «میکرو آشپزخانه» است که تنقلات و نوشیدنی های رایگان ارائه می دهد که به جذب و حفظ استعدادها کمک می کند. این فضاها نه تنها کارمندان را تشویق می کنند که مدت بیشتری در محل کار بمانند، بلکه تعاملات غیررسمی و اشتراک ایده را نیز تقویت می کنند. امکانات اضافی مانند سالن های ورزشی، ورزش، و خدمات ماساژ باعث ارتقای سلامت و شادی، افزایش بهره وری و حفظ کارمندان می شود. طرح دفتر برای تسهیل ارتباطات، علیرغم تأثیرات بالقوه بر تمرکز، طرح باز است. صندلی‌ها اختصاص داده می‌شوند، اما اغلب برای تشویق تعامل‌های جدید تغییر می‌کنند. علاوه بر این، اتاق‌های جلسه مجهز به فناوری کنفرانس ویدیویی پیشرفته برای ارتباط یکپارچه هستند که نشان‌دهنده تعهد Google به یک محیط کاری مشترک و نوآور است.4-1 آموزشگوگل تاکید زیادی بر آموزش کارکنان دارد و فرصت‌های یادگیری مختلف و ساختارهای پشتیبانی را برای نیروی کار خود فراهم می‌کند. این شامل آموزش اجباری برای استخدام‌های جدید، معروف به "Nooglers" و "Codelabs" برای کارکنان فنی است تا از طریق دوره‌های آنلاین مختصر، در مورد فناوری‌های خاص بیاموزند. علاوه بر این، Google طیف گسترده‌ای از دوره‌های آموزشی آنلاین و حضوری را ارائه می‌دهد و از آموزش‌های بیشتر در مؤسسات خارجی پشتیبانی می‌کند. برای کمک به ادغام و یادگیری، به کارمندان جدید یک «مرشد» رسمی برای راهنمایی و یک «رفیق» برای حمایت غیررسمی‌تر اختصاص داده می‌شود که با راهنمایی‌های غیررسمی از طریق تعامل با مدیران، شرکت در جلسات بررسی تیم و کد، و سایر فرآیندهای غیررسمی محل کار تکمیل می‌شود.4-2 ارزیابی عملکرد و پاداشگوگل برای بازخورد در میان کارمندان خود ارزش زیادی قائل است و فرهنگ شناخت را از طرق مختلف پرورش می دهد. مهندسان و کارمندان می‌توانند برای کار یا مشارکت‌های استثنایی «peer bonuses» و «kudos» به یکدیگر اعطا کنند، با پاداش‌های همتا که 100 دلار مشوق نقدی ارائه می‌کنند و تجلیل به عنوان ستایش غیرپولی ارائه می‌شود. به‌علاوه، مدیران این اختیار را دارند که برای دستاوردهای خاص، جوایزی بدهند. فرآیند ارتقاء Google کامل است، شامل نامزدهای شخصی، بررسی همتایان و مدیران، و تصمیمات کمیته، با مکانیسم‌هایی برای تجدیدنظر. این شرکت از طریق برنامه‌های بهبود هدفمند، عملکرد ضعیف را برطرف می‌کند، که خاتمه آن یک نتیجه نادر است. کیفیت مدیریت نیز از طریق نظرسنجی های دوسالانه کارکنان، حصول اطمینان از پاسخگویی و فرصتی برای بهبود مدیریت ارزیابی می شود. این سیستم بازخورد و شناسایی جامع، کلید تلاش Google برای ایجاد انگیزه و حفظ استانداردهای بالا در میان نیروی کار خود است.آدرس لینکدین:https://www.linkedin.com/in/mohammadhosseinjalili/

چگونه یک CTO بشویم

محمد حسین جلیلی — Sun, 07 Apr 2024 19:10:21 +0330
قدم گذاشتن توی مسیر تبدیل شدن به یک CTO نیازمند تشخیص ارزش‌های مختلف فناوری‌هاست. اگر هنوز به این فکر هستید که یک پست وبلاگی در مورد نقاط ضعف PHP یا هر فناوری دیگری بنویسید، این یک نشانه‌ای است که شاید آماده ورود به این مسیر نباشید. رهبری واقعی به معنیه بهره‌برداری از نقاط قوت هر ابزار است، نه فقط برجسته کردن نقاط ضعف اون.تبدیل شدن به یک CTO به این معنی نیست که بهترین کد نویس یا هکرترین هکر موجود در جهان باشید.در واقع، نوشتن کد احتمالا آخرین چیزی است که یک CTO شاید انجام بدهد. به جای این، CTO شخصی است که توانمندی تجزیه و تحلیل فناوری‌ها را دارد و می‌تواند آن‌ها را به اعضای تیم انتقال دهد و آن‌ها را در انجام پروژه هدایت ‌کند. CTO از تیم فناوری در برابر هرج و مرج‌های خارجی محافظت می کند و زمانی که همه چیز جهت می‌گیرد، در مقابل خطا‌ها و مشکلات فناوری مسئولیت قبول می‌کند.شاید بشه به راحتی و تصادفی با استخدام توی یک شرکت کوچیک و بدون برنامه نویس، CTO شد، مثل حالت‌هایی که در اکثر استارتاپ‌ها دیده می‌شه. اما در حالی که عنوان ممکن است «مدیر ارشد فناوری» باشد، احتمالاً فقط یک مخفف شیک برای «برنامه نویس پرکار» هست. ولی این مسئله می‌تونه خودش باعث بشه که نیاز پیدا کنیم که چگونه باید مسیر CTO شدن رو طی کنیم.من به شخصه پذیرشی از تیم‌هایی که همه‌ی دارایی‌های استراتژیک فناوری رو از تیم‌های دیگه کپی گرفته‌اند، ندارم. با ارجاع به Camille Fournier که در "در مورد نقش CTO" توضیح می دهد، یک CTO باید اطمینان پیدا کند که تیم فناوری بدون ورودی یا ایده‌های نوآورانه‌ی خودش چیزی را اجرا نمی کند. این موضوع به رهبری CTO بر می‌گردد، شخص CTO باید تجربه و تخصص خودش و تیمش رو خوب بشناسه و اون‌ها رو ارتقاء بدهد.یه موضوعی که خیلی سخته و من عمیقا حسش کردم 😓 موضوع ایجاد تعادل بین فرهنگ نوآوری و هم سویی تصمیم گیری‌های این فرهنگ و انتخاب‌هاش با استراتژی‌های کسب و کاره.این جوری که استراتژیست‌های لایه‌ی کسب و کار چیزای مختلفی می‌خوان (( اونا هم مقصر نیستند ولی خب مجبورند دیگه 🥴)). اینجوریه که برای پول گرفتن از آدما باید بازیشون بدی و پیچیدگی‌ها و بیچارگی‌های تیم توسعه و فناوری و بقیه از همینجا شروع می‌شه. البته این بیشتر توی کسب‌هایی که وابستگی ندارند صدق می‌کنه! 🤠اگر شرکتی به یک CTO یا مدیر ارشد فنی نیاز داشته باشه، اون شخص به تعریف چشم انداز تأثیر بلندمدت بر فناوری می‌پردازه. امروزه اینجوری نیست که بیشتر کسب و کارهای از فناوری استفاده کنند، بلکه حتی بیشتر توسط فناوری تعریف می شوند. به طور خلاصه، نقش در حال تحول CTO نشان دهنده اهمیت فناوری در تعریف و هدایت موفقیت کسب و کارهای مدرن هست. CTO نه تنها چشم انداز فناوری را تعیین می کند، بلکه تضمین می کند که شرکت به طور مداوم نوآوری دارد و از فناوری به عنوان ستون اساسی استراتژی تجاری و مزیت رقابتی خود استفاده می کند.مثلا یک استارتاپ رو در نظر بگیرید که هدفش ارائه‌ی سرویس‌های نوآورانه در حوزه مالی یا fintech هست، حالا نقش CTO خیلی حساس می‌شه.در این فضا یه CTO نمی‌تونه کنار بکشه و بذاره که تیم سر خود، تکنولوژی‌ای را انتخاب و اجرا کنند،😤 دلیلش هم اینه که آخرش CTO مسئولیت پاسخ گویی را دارد.😑یکی از چالش‌های مشترک CTO‌ها، مبارزه بر سر فناوری و توسعه‌ی آن هست!مثلاً) قانع کردن هیت مدیره شرکت برای تست‌های مختلف! ((غالباً این افراد فرآیند‌های فروش را خیلی اهمیت می‌دهند و CTOها باید بتونند موضوعات فناوری را خوب به دیگر قسمت‌های شرکت ارائه دهند و منابع برای فناوری جذب کنند.))یک CTO واقعی باید قدرت تصمیم‌گیری فنی و اجرای اون رو بدون نیاز به تأیید یا اجماع از بخش‌های غیرفنی سازمان داشته باشد، و اینجا هم یک نقطه تمایز یک CTO و مهندس ارشد هست.👊در کل اقتدار و نقش CTO در سازمان یا شرکت بسیار پر اهمیت هست.مدیر ارشد فناوری یا CTO یک شغل یا یک موقعیت در لایه‌ی استراتژی کسب و کار است که جهت فناوری در داخل یک شرکت یا سازمان را مشخص می کند. اگرکه از جلسات، تعامل با افراد غیر فنی متنفر هستید و فکر می‌کنید که همه مدیران تمام روز می نشینند و کاری انجام نمی دهند، این شغل مناسب شما نیست. اما اگر که این موضوعات برای شما مشکلی به همراه ندارد، می‌توان همه اینها را آموخت، به ویژه از آنجایی که کتاب های بسیار خوبی برای کمک کردن به شما وجود دارد. هر جلسه بحثی است در مورد مسیری که کسب و کار در آن در حال حرکت است و اینکه چگونه فناوری می تواند به آن کمک کند، یا گاهی اوقات چگونه فناوری می تواند فرصت های جدیدی برای رشد ایجاد کند. همه اینها باید به زبان ساده توضیح داده شود، به نحوی که برای همه قابل درک باشد.🤩 هر حال جلسه زیاد دارید بنابراین درک نیازهای کسب و کار و مشتریان ضروری است. از تجربه من:بسیاری از افراد فنی دوست دارند از "موضوعات کسب‌و‌کار" فاصله بگیرند. با این حال، این اولین چیزی است که باید به عنوان یک CTO بدانید. هیچ تصمیم فنی نباید در خلاء نگرانی‌های صرفاً نرم افزاری یا سخت افزاری اتفاق بیفتد. در بیشتر مواقع CTO باید با مدیران محصول همراه باشد تا این که استراتژی محصولات با عملیات توسعه، سازگار باشند.در نهایت CTO باید محیطی را ایجاد می کند که به تیم اجازه می دهد به چیزهای بزرگ دست یابد. امروزه بخش بزرگی از مشکلات مربوط به استخدام است. همه به دنبال توسعه دهندگان هستند، از طرفی هم تعداد آنها بسیار زیاد است، بنابراین محیط باید تا حد امکان، پذیرا باشد. این چیزی است که CTO باید بداند که چگونه آن را به خوبی انجام دهد، چرا که خودش هم یک زمانی یکی از آنها بوده است. اگر تیم بخواهد TDD یا pair programming، یا staging serversرا انجام دهد – باید همه آنها توسط CTO تایید شوند. این موضوعات تغییرات بزرگتری را به همراه خواهند داشت که باید CTO آن‌ها را در نظر بگیرد.و اما رابطه‌ی CTO و موضوعات مالی 🤔:در نظر گرفتن پیامدهای مالی مربوط به عملیات فناوری بسیار مهم است. در حالی که استارت‌آپ‌ها ممکن است انعطاف‌پذیری برای استفاده از جدیدترین فناوری‌ها را داشته باشند، ولی سازمان‌های بزرگتر باید بسیار محتاط‌تر باشند و هر تصمیم را بر اساس بازگشت سرمایه (ROI) ارزیابی کنند. سوال اصلی این است: یک فناوری چقدر برای مشتری ارزش دارد؟ اغلب، این در مورد یافتن تعادل بین به روز رسانی زیرساخت های موجود و اجتناب از دام انجام بازنویسی های گسترده و پرهزینه است. یک استراتژی مهم شامل اعمال قانون 80-20 با هدف دستیابی به 80 درصد از منافع تنها از 20 درصد سرمایه گذاری است.در مواقعی بوده که در برخی از تعاملات نظرات دوستان با سابقه‌ای رو شنیدم، اغلب با سوالاتی مانند "چرا این نسخه قدیمی را ارتقاع و از React.js استفاده نمی‌کنید؟" درک این نکته مهم است که بازنویسی کامل برنامه‌ها، به‌ویژه برای استفاده از فناوری‌های جدید، همیشه بهترین رویکرد نیست. در حالی که مدیریت برنامه های قدیمی می تواند در طول زمان پرهزینه شود، بازنویسی آنها معمولاً ارزش کمی برای مشتری ایجاد می کند. تمرکز باید بر ایجاد توازن در تلاش‌های توسعه باشد. گردآوری تیمی که فقط می‌خواهد با جدیدترین فناوری ها کار کند در دراز مدت عملی نیست.این رویکرد چارچوبی را برای اولویت بندی آنچه که بیشتر اهمیت دارد ایجاد می کند. به عنوان مثال، من قابلیت اطمینان و امنیت را اولویت اصلی هر نرم افزاری می دانم. بنابراین، هرگونه تغییر در اهداف کسب‌و‌کار با توجه به این اولویت ها ارزیابی می شود. حریم خصوصی نیز بسیار مهم است، مفهومی که افراد غیر فنی اغلب درک کامل آن را چالش برانگیز می دانند. با این حال، اگر ابتکارات خاصی با استانداردهای حفظ حریم خصوصی مطابقت نداشته باشد، می تواند گزینه های موجود برای یک شرکت را محدود کند. اطمینان از رعایت و مدیریت این مرزها بخش مهمی از نقش من است.تمرکز من روی فناوری است، با این حال معتقدم که باید یکپارچه و seamless باشد. بحث در مورد شایستگی PHP، یا هر فناوری، در نهایت برای من موضوع بی ربطی است. در حالی که برخی ممکن است چنین بحث‌هایی را جذاب بدانند، اما برای یک سازمان اهمیت کمی دارند. فراتر رفتن از این نگرانی‌ها، نقطه عطفی در مسیر تبدیل شدن به یک مدیر ارشد فناوری یا CTO است. این در مورد تغییر توجه از جزئیات فناوری به مسئولیت‌های گسترده تر، از جمله رهبری تیم و اهداف کلان سازمانی است.و در نهایت:یک مدیر ارشد فناوری یا CTO بودن نیازمند دانش گسترده تری از فناوری است، روزانه سوالاتی که در ذهن یک CTO می‌گذرد متفاوت است. دیگر سوالات از جنس مهندسی و فناوری نیست بلکه به خدمت در آوردن فناوری برای موفقیت کسب و کار هست و این نیازمند درک عمیقی از فناوری هست و چشم انداز وسیع تری را می‌خواهد.آدرس لینکدین بنده:https://www.linkedin.com/in/mohammadhosseinjalili/

فرایندکاوی به‌عنوان سرویس

علی حنیفی — Sat, 12 Feb 2022 18:26:17 +0330
امروزه سیستم‌های اطلاعاتی بیش از گذشته در فرایندهای عملیاتی دخیل هستند و به همین دلیل مشخصات رویدادهای بسیاری توسط این سیستم‌ها ذخیره می‌شوند. هدف فرایندکاوی، استفاده از این اطلاعات رویدادها و استخراج فرایندهای عملیاتی از آن‌هاست. فرایندکاوی این امکان را فراهم می‌سازد که بتوان با استفاده از لیست رویدادهای عملیاتی کسب‌وکار که در سیستم‌های اطلاعاتی ذخیره شده‌اند، اطلاعاتی راجع به نحوه انجام کار و بهینگی آن بدست آورد.از سوی دیگر، اصطلاح سرویس به مجموعه‌ای از عملکردهای نرم‌افزاری با هدفی اشاره دارد که مشتریان مختلف می‌توانند از آن برای اهداف مختلف، همراه با یکسری سیاست‌هایی کنترلی، مجدداً استفاده کنند. بنابراین موضوع فرایندکاوی به‌عنوان سرویس، به مفهومی اشاره دارد که در آن یک سرویس قابل استفادۀ مجدد که در آن می‌توان با ارائۀ یک نگارۀ رویدادها را به‌عنوان ورودی، یک مدل فرایند به‌عنوان خروجی دریافت می‌شود، تعریف نمود.مطلبی که پیش روی خود می‌بینید، در واقع یک مستند معماری نرم‌افزار است که جهت ارائۀ یک معماری یکپارچه فرایندکاوی ترکیبی ایجاد شده است. نام این پروژه عبارتست از «ارائۀ یک معماری مناسب برای رویکرد ترکیبی فرایندکاوی به‌عنوان سرویس» و خروجی این پروژه عبارتست از یک معماری نرم‌افزار فرایندکاوی به‌عنوان سرویس. تمامی خروجی‌ها در قالب نمودارهای UML و توسط نرم‌افزار Visual Paradigm ترسیم شده و تمامی فایل‌های خروجی این پروژه به‌صورت متن‌باز در گیت‌هاب منتشر شده‌اند. برای مشاهده ریپازیتوری گیت‌هاب لطفا از این لینک دیدن فرمایید.قسمت اول: تعاریف، محدوده و دامنههدف این مطلب، ارائۀ توضیحات و تشریح یک معماری یکپارچه جهت سیستم‌های فرایندکاوی ترکیبی بوده و به پنج قسمت کلی تقسیم می‌شود: قسمت اول شامل تعاریف، محدوده و دامنۀ معماری است. قسمت دوم به نماهای مختلف معماری (منطقی، پیاده‌سازی و غیره) پرداخته و در قسمت سوم نیز، پیاده‌سازی بیان شده و برخی قطعات کد معرفی می‌شوند. درنهایت قسمت چهارم به جمع‌بندی اختصاص دارد. پیشنهاد می‌شود که این قسمت‌ها به‌ترتیب مطالعه شوند و جهت بررسی دقیق پیاده‌سازی به صفحۀ گیت‌هاب این پروژه مراجعه شود، زیرا ارائۀ دقیق همۀ قطعات کد در مستند ممکن نیست. (ریپازیتوری)مخاطبان این مطلبمشخص نمودن مخاطبان این مطلب دشوار است؛ اما به‌طور کلی می‌توان اشخاص زیر را نام برد:فعالان و متخصصان حوزۀ فرایندکاوی جهت طراحی نرم‌افزار و پلاگین‌های جدید.پژوهشگران حوزۀ فرایندکاوی و آمار و احتمالات جهت بررسی روند عملیات فرایندکاوی.دانشجویان معماری نرم‌افزار و یا فرایندکاوی جهت مطالعه و گرفتن الگو.نمای موارد کاربرینمای موارد کاربری (Use Case Diagram) منجر به تجزیه و تحلیل عناصر ساختاری در نمای منطقی و پیاده‌سازی در نمای توسعه می شود. سناریوها در این نما، در نمای فرایند تحقق یافته و در نمای فیزیکی مستقر می‌شوند. در شکل (1) نمای موارد کاربری مربوط به سیستم سرویس فرایندکاوی آورده شده است.شکل (1): نمای موارد کاربری سیستم سرویس فرایندکاویهمانطور که در این شکل قابل مشاهده است، کل سیستم به سه دسته تقسیم می‌شود: سرویس‌های تحت وب، سرویس‌های فرایندکاوی و سرویس‌های مدیریت کاربران. سرویس‌های تحت وب در واقع مامور کسب درخواست‌ها از کاربران و همچنین نمایش بازخورد سایر سرویس‌ها به کاربران هستند؛ یعنی این سرویس به‌عنوان یک دیوار بین سرویس‌های داخلی و کاربر عمل می‌نماید. سرویس‌های فرایندکاوی، درواقع سرویس‌های عملکردی هستند که فایل‌های نگارۀ رویداد را دریافت کرده و سپس از روی آن مدل را کشف می‌کنند. همچنین محاسبۀ معیارهای فرایندکاوی نیز به عهدۀ این سرویس‌هاست. در نهایت سرویس‌های مدیریت کاربران نیز جهت مدیریت اطلاعات کاربران و نگهداری نشست‌ها (Sessions) و سایر موارد مانند فایل‌ها و غیره استفاده می‌شوند.برای مثال چنین سناریویی را درنظر بگیرید:کاربری می‌خواهد فایل Log خود را در سامانه آپلود کند و مدل کشف شده از آن را ببیند.برای انجام این عملیات، کاربر باید درخواست خود را از طریق سرویس وب ثبت نموده و فایل خود را آپلود کند. همچنین کاربر باید پارامترهای مربوطه و همچنین الگوریتم‌های مورد نظرش را انتخاب نماید. سپس سرویس وب این اطلاعات را به سرویس فرایندکاوی می‌دهد و سرویس فرایندکاوی نیز مدل را استخراج کرده و آن را در پایگاه داده ذخیره می‌نماید. سپس پیغامی به کاربر نمایش داده می‌شود که مدل استخراج شده و آماده است. در نهایت کاربر درخواست جدیدی به سرویس وب می‌دهد که می‌خواهد مدل را ببیند و سرویس وب نیز مدل را از پایگاه داده فراخوانی نموده و به کاربر نمایش می‌دهد.نمونه‌ای از این فرایند اجرایی به‌صورت یک نمودار BPMN در شکل (2) نمایش داده شده است. این نمودار که در واقع Hand-off را نمایش می‌دهد، جابه‌جایی اطلاعات میان سرویس‌های مختلف به تصویر کشیده شده و جهت ادراک بهتر سناریوی بالا مفید است.شکل (2): نمودار BPMN یک سناریوی فرضیمحدودیت‌هامحدودیت‌های این پروژه را می‌توان به دو قسمت تقسیم نمود: (1) محدودیت‌های فنی شامل محدودیت‌های نرم‌افزاری، سخت‌افزاری و سایر موارد مرتبط؛ (2) محدودیت‌های سازمانی شامل محدودیت‌های ساختاری، بودجه‌بندی و غیره. به‌صورت کلی محدودیت‌های پروژه در جداول (1) و (2) آورده شده‌اند.جدول (1): محدودیت‌های فنیجدول (2): محدودیت‌های سازمانیویژگی‌های کیفی سناریو‌های عمومیدر جداول (3) تا (11) ویژگی‌های کیفی سناریو‌های عمومی مربوط به سرویس فرایندکاوی به‌ترتیب اهمیت آورده شده است. در این جداول یک یا چند سناریو نیز برای درک بهتر ویژگی کیفی و همچنین نحوۀ محاسبه ویژگی‌ها نوشته شده است.1) قابلیت استفاده (Usability)جدول (3): ویژگی کیفی عمومی - قابلیت استفاده2) دسترسی پذیری (Availability)جدول (4): ویژگی کیفی عمومی - دسترسی‌پذیری (1)جدول (5): ویژگی کیفی عمومی - دسترسی‌پذیری (2)جدول (6): ویژگی کیفی عمومی - دسترسی‌پذیری (3)3) کارایی(Performance)جدول (7): ویژگی‌های کیفی عمومی - کارایی (1)جدول (8): ویژگی‌های کیفی عمومی - کارایی (2)جدول (9): ویژگی‌های کیفی عمومی - کارایی (3)4) توسعه‌پذیری(Modifiability)جدول (10): ویژگی‌های کیفی عمومی - توسعه‌پذیری5) امنیت (Security)جدول (11): ویژگی‌های کیفی عمومی - امنیتویژگی‌های کیفی سناریو‌های خاصدر جداول (12) و (13) ویژگی‌های کیفی سناریو‌های خاص مربوط به سرویس فرایندکاوی به‌ترتیب اهمیت آورده شده است. در این جداول یک یا چند سناریو نیز برای درک بهتر ویژگی کیفی و همچنین نحوۀ محاسبه ویژگی‌ها نوشته شده است.1) تحلیل گزارش‌ها و مدل‌ها به‌منظور بهینه‌سازیجدول (12): ویژگی‌های کیفی خاص - تحلیل گزارشات و مدل‌ها به‌منظور بهینه‌سازی2) اطمینان از گزارش‌ها و مدل‌های ایجاد شده در سیستمجدول (13): ویژگی‌های کیفی خاص - اطمینان از گزارش‌ها و مدل‌های ایجاد شده در سیستمویژگی‌های کیفیدر قسمت‌های قبلی ویژگی‌های سناریو‌های عمومی و خاص به‌صورت نمونه‌ای بیان شدند. در جدول (14) سایر ویژگی‌های کیفی کل سیستم به همراه معیار اندازه‌گیری و مقدار مطلوب برای هر معیار آورده شده است.جدول (14): سایر ویژگی‌های کیفیقسمت دوم: معماری سیستمدر این مطلب برای تشریح معماری سرویس فرایندکاوی از نماهای 1+4 استفاده شده است. همچنین در ادامه الگوها و روش‌های معماری استفاده شده بیان شده‌اند. البته توضیحاتی که در این مطلب آورده شده‌اند مختصر بوده و برای درک بهتر می‌توانید به آدرس گیت‌هاب این پروژه مراجعه کنید. همچنین مستندات از پنجرۀ زیر نیز قابل مشاهده است. https://alihanifi.github.io/PMService/ نمای کلی معمارینمای کلی معماری این سیستم را می‌توان چنین تشریح نمود که چندین سرویس برای تشکیل این سیستم گردهم آمده و نیازمندی‌ها را فراهم می‌کنند. این سیستم از معماری میکروسرویس استفاده می‌کند چون: معماری یکپارچه با افزایش مقیاس دچار مشکل می‌شود. این پروژه در حالت پیش‌فرض مقیاس بزرگ است و لذا باید از معماری یکپارچه دوری کرد.این سیستم درواقع مجموعه‌ای از خدمات جدا از هم است که می‌توان آن‌ها را دسته‌بندی کرد. بنابراین هر خدمت را می‌توان به‌عنوان یک سرویس جداگانه درنظر گرفت.فرایندکاوی یک شاخۀ جدید است که در آینده یقیناً دچار تغییرات بسیاری خواهد شد. میکروسرویس‌ها راه توسعه و پیشرفت را هموار می‌نمایند.در شکل (3) نمایی کلی از سیستم فعلی نشان داده شده است. در این سیستم مولفه‌های مختلفی وجود دارند که در زیر به آن‌ها اشاره شده است:میکروسرویس Event Data Extraction: استخراج داده‌ها از فایل‌های Log و یا ایجاد داده‌های مصنوعی.میکروسرویس Event Data Transformation: پیش‌پردازش داده‌ها (مثلاً فیلترکردن) قبل از تجزیه و تحلیل.میکروسرویس Process Model Extraction: استخراج مدل از نگاره‌های رویدادها.میکروسرویس Process Model & Event Data Analysis: آنالیز مدل‌ها و نگاره‌ها و همچنین محاسبۀ معیارها.میکروسرویس Process Model Transformation: تبدیل مدل‌ها به اشکال مختلف. در این پروژه پیش‌فرض مدل براساس BPMN درنظر گرفته شده است.میکروسرویس Process Model Enhancement: غنی‌سازی گزارش‌ها و مدل‌های استخراج شده به‌منظور بهبود الگوریتم‌های استخراج.شکل (3): نمای کلی معماری سیستمنمای منطقینمای منطقی این سیستم به کمک نمودار کلاس (Class Diagram) ترسیم شده است. به‌صورت کلی چهار دیاگرام کلاس وجود دارند که در ادامه توضیح داده خواهند شد. همچنین به‌دلیل بدیهی بودن و همچنین عدم ارتباط به این پروژه، از ترسیم کلاس‌های مرتبط با ذخیره‌سازی و پایگاه داده خودداری شده است. در شکل‌های (4) تا (7) نمودار کلاس‌های BPMN، سرویس وب، مدیریت کاربران و فرایندکاوی آورده شده است.شکل (4): نمودار کلاس مربوط به کلاس BPMNکلاس BPMN مربوط به مدل خروجی فرایندکاوی است که در قسمت قبلی بیان شد. در این کلاس:از الگوی طراحی Proxy استفاده شده است که در آن کلاس BPMN Graph Impl در واقع کل زیر سیستم را کنترل می‌کند و به‌نوعی نمایندۀ کل آن است.از الگوی Private Data استفاده شده است که در آن اطلاعات کلاس‌ها فقط به همان کلاس مربوط شده و برای دسترسی به اطلاعات باید از set و یا get استفاده کرد.شکل (5): نمودار کلاس مربوط به کلاس Web Serviceکلاس Web Service مربوط به صفحات تحت وب است که در قسمت قبلی بیان شد. در این کلاس:از الگوی طراحی Composite استفاده شده است که در آن فُرم درخت‌گونه مشهود است.از الگوی طراحی Singleton استفاده شده است که در آن فقط یک نمونه از کلاس Web Page Controller وجود دارد که اقدام به ساخت صفحات وب می‌کند.شکل (6): نمودار کلاس مربوط به کلاس User Managementکلاس User Management مربوط به کاربران است که در قسمت قبلی بیان شد. در این کلاس:از الگوی طراحی Singleton استفاده شده است که در آن فقط یک نمونه از کلاس‌های Login Controller و User Controller وجود دارد که جهت مدیریت کاربران استفاده می‌شود.از الگوی طراحی Proxy استفاده شده است که در آن کلاس User Service Impl در واقع کل زیر سیستم را کنترل می‌کند و به‌نوعی نمایندۀ کل آن است.از الگوی Private Data استفاده شده است که در آن اطلاعات کلاس‌ها فقط به همان کلاس مربوط شده و برای دسترسی به اطلاعات باید از set و یا get استفاده کرد.شکل (7): نمودار کلاس مربوط به کلاس Process Miningکلاس Process Mining مربوط به استخراج فرایند است که در قسمت قبلی بیان شد. در این کلاس:از الگوی طراحی Singleton استفاده شده است که در آن فقط یک نمونه از کلاس Log Handler وجود دارد که جهت مدیریت کاربران استفاده می‌شود.از الگوی طراحی Proxy استفاده شده است که در آن کلاس Miner Impl در واقع کل زیر سیستم را کنترل می‌کند و به‌نوعی نمایندۀ کل آن است.از الگوی Private Data استفاده شده است که در آن اطلاعات کلاس‌ها فقط به همان کلاس مربوط شده و برای دسترسی به اطلاعات باید از set و یا get استفاده کرد.نمای فیزیکینمای فیزیکی این سیستم به کمک نمودار استقرار (Deployment Diagram) ترسیم شده است. شکل (8) نشان‌دهندۀ نمای فیزیکی سیستم است. طبق آنچه در قسمت نمای معماری کلی گفته شد، سیستم از سه قسمت برای استقرار تشکیل می‌شود: سرویس وب، محل ذخیره‌سازی و برنامۀ کاربردی. سرویس وب در واقع همان Host یا میزبان است. محل ذخیره‌سازی می‌تواند با Host یکسان باشد اما برای نمایش بهتر و درک عمیق‌تر از یکدیگر جدا ترسیم شده است. برنامۀ کاربردی نیز قسمت‌های مختلف کُد است که مهمترین آن‌ها، برنامۀ استخراج فرایند به‌شمار می‌رود.شکل (8): نمودار استقرار سرویس فرایندکاوینمای پیاده‌سازینمای پیاده‌سازی این سیستم به کمک نمودار مولفه (Component Diagram) ترسیم شده است. شکل (9) نشان‌دهندۀ نمای پیاده‌سازی سیستم است. روند کلی آن است که سرویس Http Request Handler به‌عنوان یک Mediator عمل کرده و درواقع درخواست‌ها را به سرویس‌های مختلف ارسال نموده و پاسخ‌ آن‌ها را دریافت نموده و به کاربر ارائه می‌دهد. به همین ترتیب سایر سرویس‌ها نیز با ارائه درخواست عملیاتی را انجام داده و پاسخ آن را به فرستنده بازمی‌گردانند.شکل (9): نمودار مولفه سرویس فرایندکاوینمای فرایندنمای فرایند این سیستم به کمک نمودار فعالیت (Activity Diagram) ترسیم شده است. برای مشاهدۀ تمامی نمودارهای فعالیت لطفاً به این لینک مراجعه کنید. نمایش تمامی نمودارهای فعالیت در این مطلب جاگیر و خسته کننده است؛ لذا در شکل (10) فقط به چندین نمونه از آن اشاره شده است.شکل (10): نمودار فعالیت برخی روندها در سرویس فرایندکاویقسمت سوم: پیاده‌سازیپیاده‌سازی این سیستم با زبان Java انجام شده است و کُدهای آن در ریپازیتوری گیت‌هاب موجود است. کدهای منتشر شده همگی به‌صورت یک قالب کلی بوده و فاقد دستورات ترتیبی هستند. در واقع آن‌ها نمایندۀ یک معماری کلی جهت سرویس فرایندکاوی هستند. شاخه‌بندی کُدها به‌صورت مرکب است؛ یعنی مثلاً کلاس Node یک زیرشاخه از کلاس BPMN است و لذا در فولدر جداگانه در داخل همان کلاس به‌نام Elements نگهداری می‌شود. برای استفاده از کلاس‌های مختلف از مرجع‌دهی استاندارد استفاده شده است. مثلاً برای ارجاع به کلاس Node باید از BPMN.Elements.Node استفاده کرد.همچنین بخاطر استفاده از الگوی طراحی Private، برای دستیابی به فیلدهای مختلف در یک کلاس از توابع get استفاده شده است. مثلاً در کلاس BPMNGraph این تابع وجود دارد:public SwimLane[] getLanes() { return this._lanes; }در واقع این تابع عملیات خاصی را انجام نمی‌دهد و فقط برای دستیابی به فیلدها تعبیه شده است.در کلاس‌هایی که با Impl پایان می‌یابند (کلاس‌های Proxy) فقط توابع آورده شده‌اند و این توابع باید به کلاس پروکسی مربوطه وصل شوند. برای مثال این قطعه کد مربوط به کلاس UserServiceImpl است:package UserManagement; public interface UserServiceImpl { public void addUser(User aUser); public void disableUser(User aUser); public void changePassword(User aUser, String aPwd); public void updateUser(object[] aDetails); public void addCredential(Credential aCred); public void removeCredential(Credential aCred); public void checkUserDetails(User aUser); public void login(String aUsername, String aPwd); public void logout(String aSession); public void register(object[] aDetails); }تمامی توابع و فیلدهای این کلاس باید به کلاس UserController متصل شوند.قسمت آخر: نتیجه‌گیری و کارهای آیندهدر این مطلب معماری یک سرویس فرایندکاوی ارائه شد. ابتدا به نیازمندی‌ها، محدودیت‌ها، ویژگی‌های کیفی و دامنۀ مبحث پرداخته شد و روند کلی یک سناریوی فرضی ارائه شد. در ادامه به کمک نماهای 1+4، معماری این سیستم تشریح شده و سپس نمودارهای کلاس، مولفه و پیاده‌سازی تشریح شدند. درنهایت نیز توضیحات کوتاهی مربوط به کُدهای پیاده‌سازی ارائه شد.برای تکمیل این پروژه در آینده می‌توان عملیات زیر را نام برد:تکمیل کدهای مربوط به نگهداری فایل‌ها و پایگاه‌های داده.تکمیل کدهای داخلی و ارتباط توابع با یکدیگر.اضافه کردن مدل‌های الگوریتم‌های فرایندکاوی به‌عنوان پلاگین‌های قابل نصب.این مطلب به‌عنوان پاسخی برای پروژۀ پایانی درس معماری نرم‌افزار در دانشگاه شهید بهشتی، به کمک دوست عزیزم آقای محمدحسین جلیلی نوشته شده است که امیدوارم از آن استفاده برده باشید. لطفاً موارد زیر را راجع‌به مطالب بالا درنظر داشته باشید:این مستند یک نوشتۀ فنی و بررسی شده نیست و نباید آن را به چشم یک مرجع یا رفرنس برای پروژه‌های عملی در دنیای واقعی مشاهده نمود.این مستند پیشنهادی نیست؛ یعنی هیچ پیشنهادی دربارۀ توسعه، اولویت‌بندی، روش و تکنولوژی سیستم فرایندکاوی نمی‌دهد، حتی اگر پیشنهاد دادن در متن آمده باشد. تصمیم صحیح و یا غلط بودن مطالب ذکر شده در این مستند به عهدۀ خواننده است.این مستند تاییدی نیست؛ مطالب ذکر شده در این مستند هیچ روش و تکنیک خاصی را تایید و یا رد نمی‌نمایند.مراجعA. Augusto, R. Conforti, M. Dumas, M. La Rosa, A. Polyvyanyy, Split miner: automated discovery of accurate and simple business process models from event logs, Knowledge and Information Systems. 2019, 59, 251–284. I.H. Kwon, Book Review: Process Mining: Discovery, Conformance and Enhancement of Business Processes, 2014. A. Augusto, R. Conforti, M. Dumas, M. La Rosa, F.M. Maggi, A. Marrella, M. Mecella, A. Soo, Automated Discovery of Process Models from Event Logs: Review and Benchmark, IEEE Transactions on Knowledge and Data Engineering. 2019, 31, 686–705. J. De Weerdt, M. De Backer, J. Vanthienen, B. Baesens, A multi-dimensional quality assessment of state-of-the-art process discovery algorithms using real-life event logs, Information Systems. 2012, 37, 654–676. J.C.A.M. Buijs, B.F. Van Dongen, W.M.P. Van Der Aalst, On the role of fitness, precision, generalization and simplicity in process discovery, in: Lecture Notes in Computer Science, Springer, Berlin, Heidelberg: pp. 305–322. R. Conforti, M. Dumas, L. García-Bañuelos, M. La Rosa, Beyond tasks and gateways: Discovering BPMN models with subprocesses, boundary events and activity markers, Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). 2014, 8659 LNCS, 101–117. R. Conforti, M. Dumas, L. García-Bañuelos, M. La Rosa, BPMN Miner: Automated discovery of BPMN process models with hierarchical structure, Information Systems. 2016, 56, 284–303. T. Molka, D. Redlich, M. Drobek, X.J. Zeng, W. Gilani, Diversity guided evolutionary mining of hierarchical process models, GECCO 2015 - Proceedings of the 2015 Genetic and Evolutionary Computation Conference. 2015, 1247–1254. S.K.L.M. vanden Broucke, J. De Weerdt, Fodina: A robust and flexible heuristic process discovery technique, Decision Support Systems. 2017, 100, 109–118. K. Diba, K. Batoulis, M. Weidlich, M. Weske, Extraction, correlation, and abstraction of event data for process mining, Wiley Interdisciplinary Reviews: Data Mining and Knowledge Discovery. 2020, 10, 1–31. S. Katoch, S.S. Chauhan, V. Kumar, A review on genetic algorithm: past, present, and future, Multimedia Tools and Applications, 2021. J. Mendling, H.A. Reijers, W.M.P. van der Aalst, Seven process modeling guidelines (7PMG), Information and Software Technology. 2010, 52, 127–136. I. Zakarija, F. Škopljanac-Mačina, B. Blašković, Automated simulation and verification of process models discovered by process mining, Automatika. 2020, 61, 312–324. O. Kramer, Genetic Algorithm Essentials, 2017. A. Adriansyah, B.F. Van Dongen, W.M.P. Van Der Aalst, Conformance checking using cost-based fitness analysis, in: Proceedings - IEEE International Enterprise Distributed Object Computing Workshop, EDOC, : pp. 55–64. A. Adriansyah, J. Munoz-Gama, J. Carmona, B.F. van Dongen, W.M.P. van der Aalst, Measuring precision of modeled behavior, Information Systems and E-Business Management. 2015, 13, 37–67. W.M.P. Van Der Aalst, K.M. Van Hee, A.H.M. Ter Hofstede, N. Sidorova, H.M.W. Verbeek, M. Voorhoeve, M.T. Wynn, Soundness of workflow nets: Classification, decidability, and analysis, Formal Aspects of Computing. 2011, 23, 333–363. M. Camargo, M. Dumas, O. González-Rojas, Learning Accurate Business Process Simulation Models from Event Logs via Automated Process Discovery and Deep Learning, 2021,. J. Munoz-Gama, J. Carmona, Enhancing precision in Process Conformance: Stability, confidence and severity, IEEE SSCI 2011: Symposium Series on Computational Intelligence - CIDM 2011: 2011 IEEE Symposium on Computational Intelligence and Data Mining. 2011, 184–191. J. De Weerdt, M. De Backer, J. Vanthienen, B. Baesens, A robust F-measure for evaluating discovered process models, IEEE SSCI 2011: Symposium Series on Computational Intelligence - CIDM 2011: 2011 IEEE Symposium on Computational Intelligence and Data Mining. 2011, 148–155.

معماری نرم‌افزار در ابزارهای پردازش داده‌های حجیم

امین برجیان — Thu, 10 Feb 2022 10:34:07 +0330
شبکه‌های اجتماعی و افزایش تولید حجم متن، تصویر یا ویدیو در بستر اینترنت و ... حجم عظیمی از داده را امروزه تولید می‌کنند. تمامی این شرکت‌ها بزرگ همچون لینکدن، توییتر، گوگل، مایکروسافت و ... نیاز به ذخیره‌سازی حجم عظیمی از اطلاعات و در عین پردازش آن برای استخراج اطلاعات آماری، پاسخ‌گویی نیاز کاربران، تحلیل داده و ... دارند. همچنین اکثر این شرکت‌ها اگر چه روش‌هایی را در طول زمان برای مدیریت داده‌های خود در نظر گرفته‌اند، اما هر کدام معمولا مقالات یا ابزارهایی را از روش‌های نگهداری و پردازش داده‌ی خود در طول زمان منتشر و عمومی کرده‌اند. هر کدام از این ابزارها به شکل مختلفی بخش یا کلیه‌ی نیازمندی حوزه‌ی داده‌های حجیم را پوشش داده‌اند. به طور کلی، می‌توانیم ابزارهای موجود در حوزه‌ی داده‌های حجیم را در یک طیف قرار دهیم که دو سر این طیف به شکل زیر است:فراهم‌کردن بستری برای ذخیره‌سازی دادهفراهم‌سازی امکانات پردازش و پرس‌وجواکثر ابزارها معمولا به دو سر این طیف نزدیک هستند و بخشی از ابزارها نیز در میانه قرار دارند. هدف در این پروژه این هست که تا حد خوبی معماری ابزارهای مختلفی از این طیف را مورد بررسی قرار دهیم.اکثریت تمرکز در این مقاله بر روی رویکرد صنعتی (مرور ابزارها، فناوری‌ها و ..) می‌باشد. البته تعداد این ابزارها بسیار زیاد می‌باشد و همگی آن‌ها نیز به صورت مبنع‌باز نبوده و تنها تعدادی مقاله در مورد آن‌ها منتشر شده است. با این حال تلاش بر این بوده است که اکثر ابزارهای معروف پوشش داده شوند. بررسی‌های این مقاله در مورد اکثر ابزارهای موجود در بخشی زیر می‌باشد:Apache HDFSApache Hadoop YARNApache HBaseApache SparkApache StormApache FlinkApache DrillApache HiveApache PigApache ImpalaApache FlumeApache OozieApache ZooKeeperApache AccumuloPrestoDbApache SamzaApache TezApache BeamApache Kuduدر ادامه رویکرد یکسانی برای بررسی هر کدام از ابزارهای بالا مشخص شده است. برای این منظور یکسری معیارهای مشخص تعیین شده و هدف بر این است تا هر کدام از این معیارها برای ابزارهای ارائه‌شده در فهرست بالا بررسی شود.نام ابزارکارکرد اصلی: نگهداری داده، مدیریت، پردازش داده، پایگاه‌داده، زمان‌بند، استخراج یا وارد‌سازی داده، ...توضیح کارکرد اصلیویژگی‌های کارکردیمعماری: خلاصه ساختار و مدل‌های معماری ابزاردسترس‌پذیری: تصمیمات معماری در زمینه‌ی Availabilityکارایی: تصمیمات معماری در زمینه‌ی Performanceمقیاس‌پذیری: تصمیمات معماری در زمینه‌ی Scalabilityتعامل‌پذیری: شامل رابط کاربری، پروتکل‌های پشتیبانی‌کننده، زبان‌های برنامه‌نویسی پشتیبانی‌شونده، ...محدودیت‌ها: خلاصه محدودیت‌های ابزاردر ادامه به ترتیب برای بخشی از فهرست ابزارها که بررسی شده‌اند، توضیحات هر کدام از معیارهای بالا را مشاهده می‌کنیم.ابزار Apache Hadoop Distributed File System (HDFS)کارکرد اصلی ابزار نگهداری داده است. این ابزار مجموعه‌ای از نرم‌افزارهای منبع باز است که استفاده از شبکه‌ای از رایانه‌های زیادی را برای حل مشکلات مربوط به حجم عظیم داده و محاسبات تسهیل می‌کند. بخش HDFS این ابزار یک چارچوب نرم‌افزاری برای ذخیره‌سازی توزیع شده فراهم می‌کند.ویژگی‌های کارکردیفضای ذخیره‌سازی یکپارچه توزیع‌شده: این ابزار یک انتزاع برای ذخیره‌سازی داده در چندین گره از کلاستر به صورت توزیع‌شده ایجاد می‌کند. مقاوم‌بودن نسبت به خرابی دیسک‌های نگهداری دادهپشتیبانی از فرمت‌های متنوع فایل برای ذخیره‌سازی دادهدسترسی و پردازش سریع‌ترمعماریابزار یک سیستم فایل با ساختار بلوکی است که در آن هر فایل به بلوک‌هایی با اندازه از پیش تعیین شده تقسیم می‌شود. این بلوک‌ها در یک خوشه (cluster) از یک یا چند ماشین ذخیره می‌شوند. این ابزار از معماری Master/Slave پیروی می‌کند، که در آن یک خوشه از یک گره اصلی (NameNode) تشکیل شده است و همه گره‌های دیگر، گره‌های برده (DataNodes) هستند. HDFS را می‌توان بر روی طیف وسیعی از سرورها که صرفا جاوا را پشتیبانی می‌کنند مستقر کرد. با توجه به کارکرد Namenode، این مولفه به محیطی با فضای ذخیره‌سازی کم و منابع محاسباتی بالا نیاز دارد.ساختار ساده معماری ابزار HDFS (منبع عکس)وظایف Namenode به شرح زیر می‌باشد:این مولفه‌ی اصلی است که گره‌های برده (DataNodes) را نگهداری و مدیریت می‌کند.فراداده‌های (metadata) تمام فایل‌های ذخیره‌شده را ثبت می‌کند مانند مکان بلوک‌های ذخیره شده، اندازه فایل‌ها، مجوزها، سلسله مراتب و غیره.هر تغییری که در فراداده سیستم فایل رخ می‌دهد را ثبت می‌کند. به عنوان مثال، اگر فایلی حذف شود، بلافاصله آن را در Edit Log ثبت می‌کند.به طور منظم یک Heartbeat و یک گزارش بلوک از تمام گره‌های برده خوشه دریافت می‌کند تا اطمینان حاصل شود که DataNodes فعال هستند.مسئول مراقبت از ضریب تکرار (replication) همه بلوک‌ها است. (برای افزایش مقاوم‌پذیری)در صورت خرابی DataNode، هدف‌های جدید را برای کپی‌های جدید انتخاب می‌کند، استفاده از دیسک را متعادل می‌کند و ترافیک ارتباطی به گره‌های برده را مدیریت می‌کند.تمام داده‌ها در گره‌های برده ذخیره می‌شود و از این رو به منابع ذخیره‌سازی بیشتری نیاز دارد. این گره‌های برده می‌توانند سروهای معمولی در محیط توزیع شده باشند. گره‌های برده درخواست‌های سطح پایین خواندن و نوشتن را از کاربرهای سیستم فایل انجام می‌دهد. به منظور ذخیره‌سازی داده در هنگام نوشتن یا خواندن داده به منظور پردازش، ارتباط کاربر با گره اصلی برقرار می‌شود و خود گره اصلی این درخواست را در صورت نیاز به گره‌های برده‌ی مرتبط انتقال می‌دهد.دسترس‌پذیریدر معماری ارائه‌شده برای این ابزار، گره اصلی به صورت پیشفرض نقطه‌ی شکست سیستم (Single Point of Failure) محسوب می‌شود. ابزار در دسترس‌بودن گره اصلی را با اجازه‌دادن به ما برای داشتن دو گره اصلی در پیکربندی فعال/غیرفعال (active/passive) فراهم می‌کند. برای این منظور می‌توان از یکی از رویکردهای زیر استفاده کنیم:استفاده از Quorum Journal Nodes: گره اصلی آماده به کار و غیرفعال از طریق یک گروه جداگانه از گره‌ها به نام گره‌های Journal با یکدیگر همگام می‌شوند. گره‌های Journal از ساختار حلقه پیروی می‌کنند که در آن گره‌ها به یکدیگر متصل می‌شوند تا یک حلقه را تشکیل دهند. یک گره درخواستی را که به آن ارسال می‌شود، سرویس می‌دهد و اطلاعات را در سایر گره‌های حلقه کپی می‌کند. این قابلیت تحمل خطا را در صورت رخداد خطا در گره‌های Journal فراهم می‌کند.فضای ذخیره‌سازی مشترک با استفاده از NFS: گره غیرفعال و فعال با استفاده از یک مخزن ذخیره‌سازی مشترک با یکدیگر همگام می‌شوند. گره فعال هرگونه تغییر انجام شده در فضای نام خود را در یک EditLog موجود در این مخرن مشترک ثبت می‌کند. گره غیرفعال تغییرات ایجاد شده را از طریق مخزن مشترک می‌خواند و آن را در فضای حافظه خود اعمال می‌کند. (در این حالت لازم است که فضای مشترک خود دارای دسترسی بالا باشد تا خوشه هم دسترسی بالا باشد)برای افزایش دسترس‌پذیری گره‌های برده، مکانیزم‌های مختلفی شامل تکرارکردن داده در گره‌ها (replication)، مکانیزم آگاهی از وضعیت و ساختار Rack ها و ... ارائه شده است تا در صورت از دسترس خارج‌شدن چندین گره برده از خوشه (بسته به نحوه‌ی تنظیمات) مشکلی برای خوشه ایجاد نشود. از آنجایی که ما از سخت‌افزار برای نگهداری داده استفاده می‌کنیم و می‌دانیم که میزان خرابی این سخت‌افزارها بسیار بالا است، بنابراین اگر یکی از گره‌ها خراب شود، HDFS همچنان کپی آن بلوک‌های داده از دست رفته را خواهد داشت. به همین دلیل تا حد خوبی به خطاهای سخت‌افزاری در سطح نگهداری داده مصون هستیم.کاراییبه منظور کاهش سربار ابزار در هنگام راه‌اندازی (بعد از رخداد فاجعه یا خاموش‌شدن موقتی به دلیل تعمیرات)، یک فرایند دیگر به نام Secondary Namenode ایجاد شده است. (این ابزار برای HA کردن مولفه نیست و صرفا به منظور ایجاد یکسری تصویر لحظه‌ای از وضعیت گره‌های اصلی هست)عملکرد مولفه‌ی Secondary Namenode (منبع عکس)کارکردهای Secondary Namenode شامل موارد زیر می‌شود:به طور مداوم تمام سیستم‌های فایل و ابرداده‌ها را از فضای حافظه گره اصلی می‌خواند و آن را در دیسک یا سیستم فایل می‌نویسد.تاخیرات اخیر روی شوخه (EditLogs) را با تصویر قبلی وضعیت خوشه (FsImage) ترکیب می‌کند تا تصویر جدیدی از وضعیت خوشه ایجاد نماید.در نهایت وضعیت جدید خوشه را به گره اصلی کپی می‌کند، که هر زمان که گره اصلی به هر دلیلی شروع به اجرای دوباره کرد، سریع‌تر بالا آمده و به وضعیت جاری برسد.گره اصلی تضمین می‌کند که همه کپی‌های یک بلاک در یک Rack ذخیره نشوند. برای کاهش تأخیر و همچنین ارائه تحمل خطا از یک الگوریتم هوشیاری Rack داخلی استفاده می‌شود. به عنوان مثال با در نظر گرفتن ضریب تکرار 3، الگوریتم Rack Awareness می‌گوید که اولین نسخه از یک بلوک در یک Rack محلی و دو کپی بعدی در یک Rack متفاوت (از راه دور) ذخیره شوند. مزایای الگوریتم Rack Awareness شامل موارد زیر است:بهبود عملکرد شبکه: ارتباط بین گره‌های مستقر در Rack‌های مختلف از طریق سوئیچ هدایت می‌شود. به طور کلی، پهنای باند شبکه بیشتری را بین ماشین‌های موجود در یک Rack نسبت به ماشین‌هایی که در Rack‌های مختلف قرار دارند، مشاهده می‌کنیم. بنابراین از طریق این الگوریتم، ترافیک نوشتن در بین Rack‌های مختلف کاهش یافته و در نتیجه عملکرد نوشتن بهتری ارائه می‌شود. همچنین، به دلیل استفاده از پهنای باند چندین Rack، سرعت خواندن افزایش می‌یابد.جلوگیری از از دست رفتن داده‌ها: حتی اگر کل Rackبه دلیل خرابی سوئیچ یا قطعی برق از کار بیفتد، داده هدف در Rackهای دیگری نیز وجود خواهد داشت.یکی از چالش‌های مهم در حوزه‌ی داده‌های حجیم بحث نگهداری و مقاوم‌بودن نبست به از دست رفتن داده است. معمولا وقتی یک سرور را به تنهایی نگاه می‌کنیم تکنیک‌های مختلفی مثل RAID و ... استفاده می‌شود تا نسبت به از دست‌رفتن داده مقاوم شویم و در عین حال کارایی خواندن و نوشتن افزایش داده شود. اما این رویکردها و همچنین اتصال حجم زیادی دیسک به یک سرور یا استفاده از دیسک‌های حجیم برای سرور مناسب نیست. استفاده از دیسک‌های حجیم با توجه به سرعت محدود IO یک دیسک می‌تواند کارایی را کاهش دهد و همچنین در تعداد دیسک‌ها نیز محدودیت وجود دارد. رویکردی که در HDFS استفاده می‌شود این است که داده در گره‌های کلاستر توزیع می‌شود و مدیریت این توزیع‌ها و استفاده از دیسک تمامی سرورها به صورت یکپارچه توسط این ابزار فراهم می‌شود. با توجه به موازی‌سازی کارایی خواندن داده‌ها و همچنین نوشتن داده‌ها (با توجه به تکرار داده‌ها برای مقاوم‌سازی) افزایش می‌یابد.به منظور دستیابی به پردازش با کارایی بالا، پردازش را به داده و نه داده را به پردازش منتقل می‌کند. در واقع به جای انتقال داده‌ها به یک گره و سپس پردازش آن، منطق پردازش به گره‌های مختلف ارسال می‌شود و سپس داده‌ها به موازات گره‌های مختلف پردازش می‌شوند. سپس نتایج پردازش شده به گره‌ای ارسال می‌شود که در آن نتایج ادغام می‌شوند و پاسخ به کاربر برگردانده می‌شود.مقیاس‌پذیریبا توجه به معماری ارائه‌شده توسط این ابزار، به راحتی از طریق افزودن گره‌های اصلی می‌توانیم فضای ذخیره‌سازی و قدرت پردازشی خوشه را افزایش دهیم. البته این مورد به راحتی در مورد گره‌های اصلی صادق نیست و نیاز به افزایش منابع به صورت عمودی شامل فضای اصلی و ... (Vertical Scaling) دارد. با این حال به راحتی می‌توانیم گره‌های برده را به صورت افقی افزایش دهیم و تعدادشان برای تقسیم بار و پردازش سریع‌تر اضافه کنیم. (Horizontal Scaling)تعامل‌پذیریاز آن‌جایی که یک فرمت یکسان برای تمام نیازمندی‌ها و سازمان‌های دنیا کافی نیست، وجود پشتیبانی از فرمت‌های متنوع و عدم ایجاد محدودیت در این زمینه بسیار مهم است. HDFS می‌تواند انواع داده‌ها را شامل ساختاریافته، نیمه ساختاریافته یا بدون ساختار ذخیره کند.ابزار نوشته‌شده امکان ارتباط با کلاستر HDFS را از طریق رابط کنسولی و همچنین محیط وب فراهم می‌کند. البته قابلیت‌های ارائه‌شده در محیط وب شامل موارد محدودی مثل مشاهده‌ی فایل‌ها، وضعیت کنونی کلاستر، تنظیمات و ... می‌باشد و برای بهره‌گیری از تمامی قابلیت‌های مدیریت و نگهداری ابزار استفاده از رابط کنسولی الزامی است. این ابزار مبتنی بر زبان Javaپیاده‌سازی شده است و به همین دلیل کلاینت‌های آن معمولا برای زبان‌های مبتنی برا JVM مثل جاوا و اسکالا بیش‌تر می‌باشد. از کلاینت‌ها به منظور پردازش داده‌های کلاستر استفاده می‌شود.محدودیت‌هادسترسی به داده‌ها با تاخیر کم (دسترسی سریع به بخش‌های کوچک داده) در این ابزار امکان‌پذیر نیست.ساختار HDFS تنها زمانی مناسب‌ است که هدف اصلی خواندن داده‌ها باشد و داده‌های نوشته‌شده را ویرایش نکنیم.ساختار HDFS برای سناریوهایی مناسب است که فایل‌های کمی داشته باشیم اما حجم این فایل‌ها زیاد باشد. در مواردی که معمولا حجم زیادی فایل کوچک داریم به دلیل سربار نگهداری فراداده‌های مربوط به داده‌ها، ابزار خوب عمل نخواهد کرد.ابزار Apache Hadoop Yet Another Resource Negotiator (YARN)کارکرد اصلی ابزار مدیریت پردازش داده و زمان‌بندی است. این ابزار به روش‌های مختلف پردازش داده مانند پردازش گراف، پردازش تعاملی، پردازش جریانی و همچنین پردازش دسته‌ای اجازه می‌دهد تا داده‌های ذخیره شده در سیستم توزیع‌شده هادوپ را پردازش کنند. به عبارتی این ابزار امکان اجرای انواع رویکردهای پردازش داده‌‌ی حجیم فراتر از MapReduce را فراهم می‌کند.ویژگی‌های کارکردیاین ابزار همان‌طور که گفته شد در کنار ابزار HDFS مورد استفاده قرار می‌گیرد. این ابزار به عنوان بخش پردازشی اصلی هادوپ شناخته می‌شود و وظیفه‌ی مدیریت پردازش‌هایی را که روی کلاستر انجام می‌شوند، بر عهده دارد. همچنین این ابزار وظایف زمان‌بندی کارها را (Job Scheduling) نیز انجام می‌دهد. برای این منظور تمام فعالیت‌های پردازشی را با تخصیص منابع (بر اساس سیاست‌های مختلف) و زمان‌بندی وظایف انجام می‌دهد.معماریاین ابزار از دو مولفه‌ی اصلی به نام Resource Manager و Node Manager تشکیل شده است و دو بخش فرعی‌تر آن Application Master و Container است.نحوه‌ی ارتباط بخش‌های مختلف ابزار (منبع عکس)بخش Resource Manager وظایف زیر را بر عهده دارد:تخصیص منابع توسط این بخش ابزار انجام می‌شود.درخواست‌های پردازش را از سمت کاربران دریافت می‌کند و سپس بخش‌هایی از درخواست‌ها را به Node Manager های مربوطه می‌فرستد، جایی که پردازش واقعی انجام می‌شود.بهینه‌سازی استفاده از خوشه مانند استفاده از همه‌ی منابع در تمام مدت با در نظر گرفتن محدودیت‌های مختلف مانند تضمین ظرفیت منابع سرورها، انصاف (fairness)، تعهد سطح سرویس و ...این بخش از مولفه خود از دو بخش داخلی و مهم تشکیل شده است:زمان‌بند (Scheduler): زمانبند، مسئول تخصیص منابع به برنامه‌های مختلف در حال اجرا با توجه به محدودیت سرورها، صف‌ها و ... می‌باشد. این بخش به صورت خالص تنها زمان‌بندی را انجام می‌دهد و بعد از زمان‌بندی اجرای موفق آن یا وضعیت آن توسط این بخش بررسی نمی‌شود. برنامه‌ریزی را بر اساس منابع موردنیاز برنامه‌ها انجام می‌دهد. دو نوع زمان‌بندی پیش‌فرض به نام زمانبندی بر اساس ظرفیت منابع و زمانبندی منصفانه در حال حاضر پشتیبانی می‌شوند.مدیریت برنامه (Application Manager): مسئولیت پذیرش برنامه‌های ارسالی از سمت کاربران را بر عهده دارد. اولین ظرف اجرا (Container) را از مدیر منابع برای اجرای مدیر برنامه (Application Master) خاص برنامه ارسالی مورد استفاده قرار می‌دهد. اجرای کلیه‌ی مدیر برنامه‌های مختلف را در یک خوشه مدیریت می‌کند و خدماتی از جمله راه‌اندازی مجدد ظرف اجرا را در صورت خرابی ارائه می‌دهد.بخش گره اجرایی (Node manager) روی هر گره برده حاوی مولفه‌ی DataNode نصب می‌شود و وظیفه اجرای درخواست‌های آمده به سمتش را بر روی گره‌های برده به عهده دارد. استفاده از منابع (حافظه، CPU و ...) ظروف اجرایی جداگانه را نظارت می‌کند و مدیریت لاگ را نیز انجام می‌دهد. همچنین طبق دستور مدیر منابع، ظرف اجرایی (Container) را در صورت لزوم متوقف می‌کند.به ازای هر برنامه (Job) که از طریق این ابزار و به درخواست کاربر برنامه‌ریزی می‌شود، یک مدیر برنامه (Application Master) منحصر به فرد ایجاد می‌شود. این مولفه اجرای برنامه را در خوشه هماهنگ می‌کند و همچنین خطاها را مدیریت می‌کند. وظیفه آن تعامل با منابع از طریق مدیر منابع (Resource Manager) و همکاری با گره‌های اجرایی (Node Manager) برای اجرا و نظارت بر وظایف اجزا می‌باشد.بخش ظرف (Container) مجموعه‌ای از منابع فیزیکی مانند RAM، هسته‌های CPU و دیسک‌های موجود در یک گره خوشه است که برای یک برنامه ارسالی از سمت کاربر استفاده می‌شود تا مقدار خاصی از منابع موجود در یک گره خاص را برای آن فراهم کند.دسترس‌پذیریامکان بالا آوردن چندین نسخه از مدیر منابع (Resource Manager) برای افزایش دسترس‌پذیری سرویس ممکن می‌باشد. نحوه‌ی بالا بردن دسترس‌پذیری ابزار کردن به صورت حالت فعال/غیرفعال می‌باشد و بعد از اتصال به Zookeeper می‌تواند به صورت خودکار در صورت متوقف‌شدن مولفه فعال، مولفه‌ی غیرفعال جایگزین آن شود. (بدیهی است که دسترس‌پذیری ابزار وابسته به تنظیم درست ابزار وابسته می‌باشد)همچنین Resource Manager کارهای ارسالی از سمت کاربر را بر روی گره‌های اجرایی (Node Manager) اجرا می‌کند که در صورت از دست‌رفتن هر کدام از آن‌ها (به دلیل خرابی ماشین یا ...)، امکان اجرای آن قسمت از کار بر روی گره اجرایی دیگری فراهم هست. به همین دلیل نسبت به از دست‌رفتن تعدادی گرده در خوشه بسته به تنظیمات صورت‌ گرفته مقاوم می‌باشد.کاراییاین ابزار از طریق مکانیزم‌های داخلی خود (مانند Node Manager و Scheduler) می‌تواند به صورت مناسب و همچنین پویا (dynamic) منابع موردنیاز برای اجرای درخواست‌های کاربر را تخصیص دهد. فراهم‌نمودن رویکردهای مختلف توسط این ابزار از جمله معیارهای مختلف مثل انصاف، بهره‌وری و ... برای نحوه‌ی تخصیص منابع، بررسی پویای منابع در هنگام اجرا، اولویت‌بندی و ... از ویژگی‌های زمان‌بند این ابزار می‌باشد. البته بدیهی است که برای دستیبای به کارایی خوب، لازم است که که ابزار هادوپ به خوبی تنظیم شود.مقیاس‌پذیریبا توجه به سوارشدن این ابزار بر روی کلاستر هادوپ و مقیاس‌پذیری خود هادوپ، این ابزار نه تنها مقیاس‌پذیری هادوپ را کاهش نداده بلکه با رویکری مشابه امکان پردازش عظیم بر روی کلاستر هادوپ را با رویکردی مقیاس‌پذیر مشابه هادوپ فراهم کرده است. البته بدیهی است که برای دستیبای به مقیاس‌پذیری خوب، لازم است که که ابزار هادوپ به خوبی تنظیم شود.تعامل‌پذیریاین ابزار نه تنها بستری را برای پردازش‌های توزیع‌شده روی کلاستر هادوپ فراهم می‌کند، بلکه این ویژگی را با انعطاف زیاد فراهم می‌کند. به این صورت که نه تنها امکان زمان‌بندی و مدیریت منابع برای برنامه‌های MapReduce که فریم‌ورک محبوب هادوپ در زمینه‌ی اجرای پردازش‌های توزیع‌شده می‌باشد را فراهم می‌کند، بلکه برای ابزارهای توسعه‌داده‌شده توسط دیگر شرکت‌های مثل اسپارک، Hive و ... نیز بستری را فراهم می‌کند. به همین دلیل تقریبا در اکثر دیگر ابزارها به جای استفاده از زمان‌بند و مدیریت منابع داخلی، به صورت مستقیم از خود YARN استفاده می‌شود.این ابزار این امکان را نیز فراهم می‌کند تا از طریق docker containerization چندین نسخه از یک برنامه در کنار هم اجرا کنیم که برای برخی نیازها مفید می‌باشد.فراهم‌نمودن قابلیت‌ها از جمله مشاهده کارهای در حال اجرا، منابع تخصیص‌داده‌شده، میزان پیشرفت کارها و مدیریت لاگ از دیگر مزایای خوب این ابزار می‌باشد. این موارد هم از طریق API و هم از طریق محیط وب ساده‌ای فراهم شده است. از طریق رابط تعاملی (CLI) نیز می‌توان با این ابزار تعامل کرد.محدودیت‌هابا توجه به قرارگرفتن این ابزار بر روی ابزار هادوپ، محدودیت‌های مشاهده‌شده برای آن ابزار نیز در این قسمت صادق می‌باشد.ابزار Apache HBaseکارکرد اصلی ابزار، فراهم‌سازی پایگاه داده درحوزه‌ی کلان‌داده می‌باشد. HBase یک پایگاه داده متن‌باز، چندبعدی (multidimensional)، توزیع شده، مقیاس‌پذیر و NoSQL است. HBase بر روی زیرساخت HDFS اجرا می‌شود و قابلیت‌هایی یک پایگاه‌داده را در اختیار Hadoop قرار می‌دهد. این ابزار به گونه‌ای طراحی شده است که با تحمل خطای بالا، امکان ذخیره مجموعه بزرگی از داده‌های توزیع‌شده را ارائه می‌دهد.ویژگی‌های کارکردیقابلیت خواندن و نوشتن سریع را در مجموعه داده‌های عظیم با توان بالا و تاخیر کمدسترسی سریع و تصادفی (random) به حجم زیادی از داده‌هاپشتیبانی از داده‌های نیمه ساختار یافته یا بدون ساختار یا ترکیبی از هر دوذخیره‌سازی داده‌ها به صورت ستونی (column oriented)قابلیت نگهداری چندین نسخه‌ برای یک داده با کلید مشخصمعماریاز نظر شیوه‌ی نگهداری داده، این ابزار از روش column oriented برای نگهداری داده استفاده می‌کند که به منظور ذخیره‌سازی حجم زیادی داده و همچنین انجام پردازش‌های OLAP مناسب‌تر است. برای این منظور همانند پایگاه‌داده‌های معمولی شامل جدول (table) می‌باشد اما هر جدول به صورت ستونی شامل تعدادی Column Family می‌باشد. یک Column Family می‌تواند از چندین Column Qualifier تشکیل شده باشد اما تمامی محتوای هر Column Family به صورت پیوسته روی دیسک ذخیره می‌شود. ذخیره‌سازی داده‌ها به همراه زمان (Timestamp) مربوط به ویرایش/اضافه‌شدن می‌باشد که امکان جستجو روی نسخه‌های مختلف یک داده را فراهم می‌کند. در نگاه قضیه‌ی CAP، تمرکز HBase بر روی فراهم‌سازی دسترس‌پذیری (Availability) و سازگاری (Consistency) بوده است. در این راستا، در یک ردیف، ابزار خواندن و نوشتن واحد (atomic) را فراهم می‌کند.این ابزار از سه مولفه‌ی اصلی شامل سرور HBase Region، سرور HMaster و منطقه‌ها (Regions) تشکیل‌شده است که برای هماهنگی با یکدیگر از ابزار خارجی Zookeeper استفاده می‌کنند.معماری ابزار HBase (منبع عکس)یک جدول به چند منطقه (Region) تقسیم می‌شود. منطقه یک محدوده مرتب‌شده از ردیف‌هایی است که داده‌ها را بین یک کلید شروع و یک کلید پایان ذخیره می‌کند. یک منطقه دارای اندازه پیش‌فرض 256 مگابایت است که می‌تواند بر اساس نیاز تغییر کند. یک گروه از مناطق توسط یکسرور منطقه (Region Server) به کاربران (clients) ارائه می‌شود. (مسئول مدیریت، اجرای عملیات خواندن و نوشتن در آن مجموعه از مناطق است) یک سرور منطقه می‌تواند تقریباً شامل 1000 منطقه باشد که نشان‌دهنده‌ی قدرت پردازشی خوب این ابزار است.سرور HMaster عملیات ایجاد و حذف جداول (DDL) را انجام می‌دهد و تخصیص مناطق به سرورهای مناطق توسط آن انجام می‌شود. هماهنگی و مدیریت مناطق به خصوص در هنگام راه‌اندازی بر عهده‌ی آن می‌باشد. در حین بازیابی و متعادل‌سازی بار، منطقه‌ها را دوباره به سرورهای منطقه اختصاص می‌دهد. تمام سرورهای مناطق را با کمک Zookeeper در خوشه نظارت می‌کند و فعالیت‌های بازیابی را هر زمان که سرور منطقه‌ای از کار بیفتد، انجام می‌دهد. Zookeeper مانند یک هماهنگ‌کننده در محیط توزیع‌شده ابزار عمل می‌کند و با برقراری ارتباط از طریق نشست‌ها، به حفظ وضعیت سرور در داخل خوشه کمک می‌کند. هر سرور منطقه به همراه سرور HMaster ضربان قلب مداوم را در فواصل منظم به Zookeeper می‌فرستد و بررسی می‌کند که کدام سرور زنده و موجود است. (وضعیت سرورهای منطقه توسط جدول META در Zookeeper نگهداری می‌شود)دسترس‌پذیریهمان‌طور که در بخش معماری توضیح داده شد، تعداد زیادی سرور منطقه وجود دارد و قابلیت بازیابی خطا برای هر کدام از آن‌ها به صورت خودکار توسط زوکیپر وجود دارد. در نتیجه به راحتی قابلیت مقیاس‌پذیری و در عین حال فراهم‌سازی دسترس‌پذیری دارند. همچنین بخش HMaster می‌تواند با کمک Zookeeper به صورت دسترس‌پذیر بالا با معماری Active/Passive اجرا شود و دسترس‌پذیری خوشه را افزایش دهد.ابزار از طریق ماکنیزم WAL (Write Ahead Log) که بر روی سراسر خوشه‌ی HDFS ارائه می‌دهد، قابلیت این را دارد که در زمان رخداد خطا و مشکل، به صورت خودکار خود را ترمیم و راه‌اندازی مجدد کند.کاراییفشرده‌سازی و عملیات درون حافظه (In-memory) برای برآورده‌کردن نیازهای خواندن و نوشتن سریع فراهم می‌کند.از Block Cache در سرورهای منطقه استفاده می‌شود که به صورت نگهداری داده‌های اخیر (LRU) عمل کرده و داده‌هایی را که اخیرا مورد دسترسی قرار گرفته‌اند، برای دسترسی‌های بعدی در مموری نگه می‌دارد.از تکنیک‌های Bloom Filters (ساختار داده‌ای که می‌گوید آیا یک مقدار در یک مجموعه وجود دارد یا نه) برای بهینه‌سازی پرس و جو با حجم بالا پشتیبانی می‌کند و می‌تواند از طریق آن هنگام خواندن داده، حجم خوبی از داده را چشم‌پوشی کرد و میزان IO و شبکه مصرفی را کاهش داد.از آنجایی که جستجو در محدوده ردیف‌ها انجام می‌شود، ابزار کلیدهای سطر‌ها را به ترتیب واژگانی (sorted) ذخیره می‌کند. با استفاده از این کلیدهای مرتب‌شده می‌توان یک درخواست بهینه ایجاد کرد و با کمترین تاخیر پاسخ آن را دریافت کرد.از روش‌های فشرده‌سازی (compaction) مختلف به منظور فشرده‌سازی داده و حذف داده‌های اضافی استفاده می‌کند که سرعت خواندن را برای درخواست‌های آینده افزایش می‌دهد.مقیاس‌پذیریمقیاس‌پذیری افقی از نظر ذخیره‌سازی: از آن‌جایی که مجموعه داده‌ها بر روی خوشه HDFS توزیع می‌شوند، بنابراین به صورت افقی در گره‌های مختلف خوشه می‌تواند مقیاس‌پذیر باشد.مقیاس‌پذیری افقی از نظر استقرار: نحوه‌ی پیاده‌سازی و استقرار آن به صورت ماژولار (modular) بوده و این امکان وجود دارد که حداکثر بار قابل تحمل آن را با افزایش تعداد مولفه‌های در حال اجرای آن به صورت خطی روی گره‌های خوشه افزایش داد، به همین دلیل از نظر استقرار نیز مقیاس‌پذیر است.تقسیم سرورهای منطقه به صورت خودکار: به صورت خودکار با افزایش حجم داده‌ی گروهی از مناطق، سرور منطقه مربوطه به دو سرور کوچکتر شکسته می‌شود که هم مقیاس‌پذیری و امکان پردازش موازی را افزایش می‌دهد.تعامل‌پذیریبرای اتصال به کلاستر HBase در زمینه‌ی جاوا کلاینت خیلی خوبی فراهم شده است که به راحتی امکان اتصال و بهره‌وری از امکانات HBase را به صورت برنامه‌نویسی فراهم می‌کند. همچنین در زمینه‌ی روش‌های مبتنی بر Restful API و Thrift نیز امکاناتی برای اتصال کاربران فراهم شده است.محدودیت‌هابرخلاف جداول معمول که امکان عملیات Join را فراهم می‌کنند، معماری ابزار برای این منظور طراحی نشده است. به جای پایگاه داده، Joinها در لایه MapReduce مدیریت می‌شوند.هیچ پشتیبانی برای تراکنش وجود ندارد.طراحی کنونی ابزار تنها وجود یک فیلد برای ایندکس‌کردن (همان row key) را پشتیبانی می‌کند و برای مواردی که نیاز به چندین ایندکس برای جستجوی سریع‌تر نیاز باشد، به صورت پیشفرض مکانیزمی فراهم نشده است.برای نگهداری فایل‌های باینری با حجم خیلی زیاد مناسب نیست.ابزار نمی‌تواند عملکردهایی مانند SQL را انجام دهد. از ساختار SQL پشتیبانی نمی‌کند، بنابراین حاوی هیچ بهینه‌سازی برای پرس و جو نیست.هیچ مجوز یا احراز هویت داخلی وجود ندارد.ترکیب ابزار با مواردی مثل Map-Reduce، منجر به تاخیرهای غیرقابل پیش‌بینی می‌شود.ابزار Apache Sparkکارکرد اصلی ابزار پردازش داده می‌باشد. Apache Spark یک چارچوب محاسباتی خوشه‌ای منبع باز و توزیع‌شده برای پردازش بلادرنگ (real-time) محسوب می‌شود.ویژگی‌های کارکردیپردازش به صورت لحظه‌ای (به جای پردازش دسته‌ای) صورت می‌گیرد. سرعت آن چندین برابر MapReduce برای پردازش داده در مقیاس بزرگ می‌باشد.محاسبات اسپارک بلادرنگ است و به دلیل محاسبات درون حافظه آن، تأخیر کمی دارد. اسپارک برای مقیاس‌پذیری عظیم طراحی شده است و خوشه‌هایی با هزاران گره اجرا و چندین مدل محاسباتی را پشتیبانی می‌کند.اسپارک سازگاری روان با Hadoop را فراهم می‌کند. Spark یک جایگزین بالقوه برای توابع MapReduce است، در حالی که این توانایی را دارد که در بالای یک خوشه Hadoop موجود با استفاده از YARN برای زمان‌بندی منابع اجرا شود.بخش Spark Streaming برای پردازش داده‌های جریانی در زمان واقعی استفاده می‌شود. پردازش جریان‌داده‌ها با توان و تحمل خطای بالا را امکان پذیر می‌کند.بخش Spark SQL پردازش رابطه‌ای را با API برنامه‌نویسی تابعی اسپارک یکپارچه می‌کند.بخش GraphX برای پردازش داده‌های دارای ساختار درختی به صورت موازی مناسب است.بخش MLlib برای یادگیری ماشین و نیازمندی‌های مشابه مناسب است.قابلیت‌های ذخیره‌سازی و کش‌کردن اطلاعات را بر روی دیسک فراهم می‌کند.معماریدر معماری اسپارک، ما یک گره master داریم که به عبارتی برنامه ما در آن اجرا می‌شود و مدیریت کل اجرای برنامه را به عهده می‌گیرد. (به عبارتی می‌تواند هر گره‌ای باشد که قابلیت اتصال به خوشه اسپارک را دارد) همچنین در کنار این گره master، کلی گره در خوشه داریم که از آن‌ها در اسپارک با عنوان worker یاد می‌شود. در گره اصلی، برنامه درایور (driver program) را داریم که همان برنامه‌ی نوشته‌ شده‌ی ما می‌باشد. در واقعیت کدی که نوشته می‌شد به عنوان یک برنامه درایور عمل می‌کند یا اگر از shell استفاده کنیم، shell به عنوان برنامه درایور عمل می‌کند. در داخل برنامه درایور، اولین کاری که انجام می‌شود این است که یک Spark Context ایجاد می‌شود. این Context به صورت یک دروازه برای همه عملکردهای اسپارک عمل می‌کند.معماری ساده ابزار (منبع عکس)بخش Context با مدیر خوشه برای مدیریت کارهای مختلف هماهنگ می‌شود. برنامه درایور و Context از اجرای کار در خوشه مراقبت می‌کنند. یک کار یا برنامه به وظایف (task) متعددی تقسیم می‌شود که بر روی گره‌های کارگر توزیع می‌شوند (توسط Executorsها اجرا می‌شوند) و سپس نتیجه به Context برگردانده می‌شود. گره‌های کارگر، گره‌های برده‌ای هستند که کار آن‌ها اساسا اجرای وظایف است. هنگامی که کاربر کد برنامه کاربردی را برای اجرا ارسال می‌کند، درایور به طور ضمنی کد کاربر را که شامل تبدیل‌ها و اقدامات است به یک گراف غیر حلقه‌ای منطقی (logical DAG) تبدیل می‌کند. در این مرحله بهینه‌سازی‌هایی مانند جابه‌جایی اجرای دستورات و ... نیز انجام می‌شوند. پس از آن، نمودار منطقی با چندین مرحله به طرح اجرای فیزیکی نهایی (Physical Plan) که همان اجرای واقعی روی خوشه اسپارک می‌باشد، تبدیل می‌شود. پس از تبدیل به یک طرح اجرای فیزیکی، وظایف (tasks) مختلف مبتنی بر آن ایجاد می‌شوند و به خوشه ارسال می‌شوند. قبل از ارسال، ابتدا از طریق Cluster Manager منابع لازم درخواست می‌شود و مدیر خوشه اجراکننده‌ها را (Executors) در گره‌های کارگر راه‌اندازی می کند. سپس وظایف برای مجریان ارسال می‌شوند و مجری‌ها شروع به کار می‌کنند، خودشان را نزد Context ثبت می‌کنند. در طول اجرای وظایف، برنامه درایور مجموعه‌ای از مجریانی که اجرا می‌شوند را نظارت می‌کند. درایور گره همچنین وظایف آینده را بر اساس قراردادن داده‌ها زمان‌بندی می‌کند.وظایفی که توسط اسپارک ایجاد می‌شوند، مبتنی بر ساختارهای داده‌ی RDD هستند. کلمه‌ی RDD مخفف سه عبارت زیر می‌باشد:ارتجاعی (Resilient): تحمل خطا دارد و قادر به بازسازی داده‌ها در صورت خرابی است.توزیع شده (Distributed): داده‌‌ها توزیع‌شده بین گره‌های متعدد در یک خوشه هستند.مجموعه‌داده (Dataset): مجموعه‌ای از داده‌های پارتیشن‌بندی‌شدهدسترس‌پذیریاسپارک به منظور فراهم‌سازی دسترس‌پذیری بالا از معماری active/passive برای گره‌های اصلی استفاده می‌کند. همچنین در زمینه‌ی کارگرها نیز به صورت تحمل‌خطا عمل کرده و در صورت پیش‌آمدن هر مشکلی برای یکی از گره‌ها، از طریق دیگر گره‌ها به اجرای دوباره‌ی آن بخش خاص از برنامه می‌پردازد. (البته لازمه‌ی آن این است که داده فقط بر روی آن گره خاص نباشد. مثلا از طریق HDFS داده تکرار شده باشد و در چندین گره موجود باشد وگرنه خود داده باعث عدم دسترس‌پذیری بالا خواهد شد.)اسپارک با استفاه از تعریف RDD و تبدیل داده‌های ورودی به این انتزاع تلاش می‌کند تا در عین مستقل‌شده نسبت به داده‌ی ورودی، دسترس‌پذیری و تحمل خطای بالا را ایجاد کند.کاراییاگر تعداد کارگران افزایش داده شود، کارها می‌توانند به وظایف بیش‌تری تقسیم شوند و آن‌ها به طور موازی در چندین گره کارگر اجرا شوند که بسیار سریع‌تر خواهد بود. با افزایش تعداد کارگران، اندازه حافظه نیز افزایش می‌یابد و می‌توانید کارها را در حافظه اصلی نگه داشت (cache) تا سریع‌تر اجرا شوند.همچنین ابزار قادر است از طریق پارتیشن‌بندی کنترل‌شده داده‌ها، به سرعت بسیار زیاد دست یابد. استفاده از این روش به موازی‌سازی پردازش داده‌های توزیع‌شده با حداقل ترافیک شبکه کمک می‌کند.اسپارک ارزیابی خود را تا زمانی که کاملا ضروری باشد به تاخیر می‌اندازد. این یکی از عوامل کلیدی در سرعت آن است. برای این منظور، اسپارک تبدیلات و دستورهای کاربر را به یک گراف غیر حلقه‌دار جهت‌دار (DAG) محاسبات اضافه می‌کند و تنها زمانی که کاربر مقداری داده را درخواست کند، این DAG واقعاً اجرا می‌شود. (همچنین قبل اجرا محتوای گراف تا حد امکان ساده و بهینه می‌شود)مقیاس‌پذیریبا توجه به معماری برای اسپارک که شامل گره‌های اصلی و کارگر می‌شود و اجرای وظایف تنها توسط کارگرها می‌باشد، می‌توان با افزایش تعداد کارگرها به صورت خطی قدرت پردازشی و همچنین حجم پردازش موازی یا تحمل خطا را افزایش داد.تعامل‌پذیریاسپارک به منظور تعامل با خوشه، APIهای سطح بالایی را در جاوا، اسکالا، پایتون و R ارائه می‌دهد. کد اسپارک را می‌توان به هر یک از این چهار زبان نوشت. همچنین اسپارک نصب‌شده به صورت پیش‌فرض برای یکسری زبان‌ها از جمله اسکالا و پایتون رابط کنسولی فراهم نموده است.اسپارک از چندین منبع‌داده مانند Parquet، JSON، Hive و Cassandra جدا از فرمت‌های معمول مانند فایل‌های متنی، CSV و RDBMS پشتیبانی می‌کند. اسپارک مکانیزمی قابل اتصال برای دسترسی به داده‌های ساختاریافته از طریق Spark SQL نیز فراهم می‌کند.محدودیت‌هاهیچ سیستم مدیریت فایلی در اسپارک وجود ندارد و به همین دلیل باید با ابزارهای دیگر مانند Hadoop یا هر پلتفرم مبتنی بر ابر (cloud) استفاده شود. اسپارک به طور کامل از پردازش جریان‌داده به صورت بلادرنگ (real-time) پشتیبانی نمی‌کند. اسپارک، جریان داده زنده را به دسته‌هایی تقسیم می‌کند و عملیاتی مانند اتصال، نگاشت یا کاهش و ... بر روی این دسته‌ها اعمال می‌کند. پس از پردازش، نتیجه دوباره به دسته‌ها تبدیل می‌شود. به این ترتیب، جریان اسپارک فقط پردازش میکرو دسته‌ای است و از پردازش کاملاً بلادرنگ پشتیبانی نمی‌کند.در پردازش کلان‌داده، نگهداری داده‌ها در حافظه آسان نیست و در حین کار با اسپارک مصرف حافظه بسیار بالا دارد.تأخیر اسپارک زیاد است که باعث کاهش توان عملیاتی آن می‌شود.ابزار Apache Stormکارکرد اصلی ابزار پردازش داده بلادرنگ است. چارچوب محاسباتی پردازش جریانی منبع باز و توزیع‌شده است. پردازش جریان‌های نامحدود داده به صورت قابل اعتماد (تحمل خطای بالا) فراهم می‌کند و برای پردازش بلادرنگ استفاده می‌شود.ویژگی‌های کارکردیبه پردازش کلان داده‌ها کمک می‌کند. یک سیستم پردازش سریع و قابل اعتماد است.این ابزار می‌تواند داده‌های با حجم بالا و سرعت بالا را جذب کند.مکانیزم‌های توسط این ابزار ارائه می‌شود که می‌تواند برای تجزیه و تحلیل بلادرنگ، یادگیری ماشینی و پردازش جریان نامحدود استفاده شود. همچنین این ابزار می‌تواند پیام‌های تولید شده را به طور مداوم دریافت کند و به چندین سیستم خروجی دهد.معماریابزار هیچ‌گونه قابلیت مدیریت داخلی ندارد و برای مدیریت وضعیت خوشه‌ای خود، مواردی مانند تایید پیام، وضعیت‌های پردازش و سایر پیام‌ها، به ZooKeeper متکی است. همچنین دو مدل داده‌ی زیر در این ابزار استفاده می‌شوند:مدل tuple: یک لیست مرتب‌شده از مقادیر نامگذاری شده مشابه یک ردیف پایگاه‌داده است. هر فیلد در آن دارای یک نوع داده است که می تواند پویا باشد. فیلد می‌تواند از هر نوع داده‌ای مانند انواع متداول یا آرایه بایتی باشد. انواع داده‌های تعریف شده توسط کاربر نیز مجاز هستند.مدل stream: جریان یک توالی نامحدود از tupleها است.معماری این ابزار مبتنی بر master/slave می‌باشد. یک سرور اصلی به نام Nimbus وجود دارد که روی یک گره به نام Master Node اجرا می‌شود. سرویس‌های به نام سرپرست (Supervisor) وجود دارند که روی هر گره کارگر اجرا می‌شوند. سرپرستان یک یا چند فرآیند کارگری (worker process) شروع می‌کنند که به صورت موازی برای پردازش ورودی اجرا می‌شوند.معماری ابزار (منبع عکس)فرآیند Nimbus وظایف را به گره‌های کارگر اختصاص داده و توزیع می‌کند. همچنین در عین حال وظایف را نظارت می‌کند تا از اجرای درست آن‌ها مطمئن شود و وظایف مربوط به خرابی گره را مجدداً اختصاص می‌دهد. فرآیند سرپرست (Supervisor) روی هر گره کارگر از خوشه اجرا می‌شود. هر وظیفه را که از سمت گره اصلی به آن محول می‌شود، به عنوان یک فرآیند جداگانه به نام فرآیند کارگر (worker process) اجرا می‌کند. فرآیند کارگر همان کار و پردازش واقعی را انجام می‌دهد. اجراهای آن‌ها توسط بخش سرپرست شروع و نظارت می‌شود. تعداد فرآیندهای کارگر برای هر وظیفه یا کار ایجادشده توسط کاربر بر روی خوشه، قابل پیکربندی است.ابزار از دو مولفه‌ی اصلی به نام‌های Spout و Bolt تشکیل شده است. این دو نوع مولفه، جریان ورودی یا داخلی را پردازش می‌کنند. بخش دهانه‌ها (spout) داده‌های خارجی سیستم را برای تولید جریان‌های tuple پردازش می‌کنند و آن‌ها را به boltها می‌فرستند. این مولفه، داده‌ها را از سایر سیستم‌های صف مانند کافکا، توییتر و ... می‌تواند دریافت کند. پیاده‌سازی Spout برای تولیدکنندگان داده محبوب در دسترس است. یک Spout واحد می‌تواند چندین جریان خروجی تولید کند که در صورت نیاز هر خروجی توسط یک یا چندین بخش دیگر مصرف شوند. Boltها جریان tuple ارسال‌شده به خودشان را دریافت می‌کنند و پردازش می‌کنند. خروجی آن‌ها دوباره جریانی از tupleها خواهد بود که متناسب با کارکرد برنامه به مقصد مناسب ارسال می‌شود.منطق هر برنامه در قالب یک توپولوژی بسته‌بندی شده است که اساساً شبکه‌ای از Boltها و Spoutها است. توپولوژی برای همیشه اجرا می شود مگر اینکه کاربر سامانه به صراحت آن را متوقف کند. شبکه شامل گره‌هایی است که منطق پردازش را تشکیل می‌دهند و پیوندهایی که انتقال داده‌ها و اجرای فرآیندها را نشان می‌دهند. انواع توپولوژی‌های کاربردی به صورت پیشفرض توسط ابزار فراهم شده است.دسترس‌پذیریدسترس‌پذیری این ابزار با توجه به معماری آن به دسترس‌پذیری Zookeeper نیز وابسته می‌باشد. با این حال پیاده‌سازی آن به گونه‌ای است که بر روی گره‌های فراوانی (workers) استقرار می‌یابد و نحوه‌ی پیاده‌سازی آن تحمل از دست‌رفتن تعدادی گره را فراهم می‌کند. همچنین پیاده‌سازی گره‌ اصلی به صورت active/passive می‌باشد که دسترس‌پذیری بالایی را فراهم می‌کند.قابلیت اعتماد یا تحمل خطای این نرم‌افزار متناسب با نیاز کاربر می‌تواند تضمین کند که هر واحد داده حداقل یک بار یا دقیقا یک بار پردازش شود. پیام‌ها فقط زمانی دوباره پردازش می‌شوند که خرابی وجود داشته باشد. برای این منظور لازم است که پیاده‌سازی مربوط به spoutها و boltها در صورت رخداد خطا، در صورت نیاز کاربر فرایند پردازش را تکرار کنند. البته پیاده‌سازی این قابلیت به تنهایی از طریق Storm ممکن نیست. در مورد بخش‌های ورودی داده (spout) لازم است که منبع ورودی داده قابلیت دریافت بازخورد داشته باشد و بتواند در صورت نیاز داده را دوباره ارسال کند. (مثلا اگر UDP باشد Storm در آن صورت کاری نمی‌تواند انجام دهد) همچنین برای بخش‌های داخلی (Bolt) لازم است که پردازش‌های رخ‌داده در لایه‌ی ذخیره‌کننده‌ی میانی (مثل یک حافظه‌ی in-memory یا دیتابیس یا ...) ذخیره شوند تا در صورت خطا امکان ادامه‌ی فرآیند و از دست‌نرفتن داده‌ها وجود داشته باشد. اگر این امکان فراهم نشود، Storm دوباره کاری نخواهد کرد. به عبارتی این ابزار در صورت فراهم‌سازی شرایط امکان تحمل‌خطا و پردازش تمامی‌داده‌ها را دارد اما به تنهایی این امکان را به صورت داخلی فراهم نکرده است. (غیر از پیاده‌سازی یکسری امکانات برای اتصال به ابزارهای معروف مثل Kafka یا Hadoop)کاراییمتناسب با تنظیماتی که برای اجرای jobها مشخص می‌شود و منابعی که در اختیار آن گذاشته می‌شود می‌تواند کارایی خوبی در پردازش داده‌های درون خوشه داشته باشد.همچنین بسته به این که پیاده‌سازی مربوط به ورودی‌دهنده‌های داده (spout) به چه صورتی باشد، می‌تواند توانایی پردازش حجم زیادی داده با نرخ بالای ورودی را داشته باشد. به عبارتی کارایی آن در بخش ورودی متناسب با نوع ورودی داده است. (به عنوان مثال اگر از کافکا برای ورودی داده استفاده شود، کارایی برنامه وابسته به کافکا خواهد بود یا اگر از Hadoop به عنوان مبدا ورودی داده استفاده شود، کارایی وابسته به تنظیمات و توانایی خوشه Hadoop خواهد بود)زمان تاخیر مربوط به این ابزار با توجه به مسئله‌ی مدل‌شده می‌تواند متفاوت باشد و وابسته به نرخ ورودی یا محاسبات انجام‌شده باشد. به همین دلیل در مورد تاخیر با قطعیت نمی‌توان نظری داد.مقیاس‌پذیریمقیاس‌پذیری این ابزار در درجه‌ی اول وابسته به نحوه‌ی دریافت ورودی داده و خروجی داده و محل‌های میانی ذخیره‌ی داده می‌باشد. با فرض مقیاس‌پذیر بودن وابستگی‌های خارجی ابزار که در بالا ذکر شد، در آن صورت خود ابزار به راحتی با افزوده‌شدن گره‌های به کلاستر (به عنوان مثال برای افزایش توان پردازشی) به صورت افقی گسترش پیدا کند.تعامل‌پذیریتنظیمات استاندارد برای اجرای این ابزار در روز صفر مناسب هستند و تقریبا با کمترین هزینه می‌توان ابزار را اجرا نموده و به کار کردن و کسب تجربه پرداخت.استفاده از این ابزار و ارتباط با آن توسط زبان‌های برنامه‌نویسی متنوعی پشتیبانی می‌شود. همچنین این ابزار می‌تواند بر روی YARN هم سوار شود و کاملا با اکوسیستم Hadoop ادغام شود.محدودیت‌هایک جریان کامل از داده‌ها را به‌عنوان یک «رویداد» به‌جای رویکرد دسته‌ای دریافت می‌کند. به همین دلیل، برای داده‌هایی که قرار است به‌عنوان یک موجودیت واحد مصرف شوند، مناسب‌تر است.برای به روزرسانی توپولوژی در حال اجرا، تنها گزینه در حال حاضر حذف توپولوژی فعلی و ارسال مجدد توپولوژی جدید است. (این از نظر به دلیل پایین‌بودن موقتی برنامه خوب نیست)برای داشتن دسترسی بالا و کارایی خوب به ابزارهای خارجی وابسته است.در صورتی که نیاز به پردازش‌های کلان‌داده به صورت دسته‌ای دارید، این ابزار راه‌حلی ارائه نداده است. (تنها برای جریان داده‌های بلادرنگ مناسب می‌باشد)ابزار Apache Flinkکارکرد اصلی ابزار پردازش داده است. ابزار یک چارچوب متن‌باز و موتور پردازش توزیع‌شده برای محاسبات دارای حالت (stateful) بر روی جریان‌های داده نامحدود و محدود است.ویژگی‌های کارکردیپشتیبانی از پردازش جریانی (stream) و دسته‌ای (batch) به صورت همزمانپشتیبانی از ورودی‌های بلادرنگ و ذخیره‌شدهپشتیبانی از عملکرد درون حافظهدارای پردازش تکراری برای یادگیری ماشین و پشتیبانی از تجزیه و تحلیل گرافپشتیبانی از پردازش زمان رویداد (event-time processing)پشتیبانی از مکانیزم‌هایی برای مدیریت داده‌های دارای تاخیر مانند watermarking و ...پشتیبانی از ویژگی‌های جریانی پیشرفته مانند trigger، Sessions و ...معماریابزار برای اجرای برنامه‌های جریانی در هر مقیاسی طراحی شده است. برنامه‌ها به هزاران وظیفه موازی تقسیم می‌شوند که به طور همزمان در یک خوشه از گره‌ها توزیع و اجرا می‌شوند. مکانیزم تقسیم کار توسط ابزار مدیریت می‌شود اما مکانیزم اجرای آن توسط گره‌های خوشه می‌تواند توسط خود ابزار به صورت standalone یا توسط پیکربندی ابزارهای دیگر (مثل YARN و ...) مدیریت شود. علاوه بر این، ابزار به راحتی حالت (state) برنامه بسیار بزرگ را حفظ می‌کند. الگوریتم checkpoint که به صورت ناهمزمان (آسنکرون) و افزایشی اجرا می‌شود، حداقل تأثیر را بر تأخیرهای پردازش تضمین می‌کند و در عین حال ثبات حالت را دقیقاً یک بار (exactly-one consistency) تضمین می‌کند.معماری ابزار (منبع عکس)دسترس‌پذیریابزار می‌تواند به صورت HA استقرار پیدا کند و شامل نقطه‌ی شکست (Single Point of Failure) نمی‌باشد. البته در صورتی که برای مواردی مثل ذخیره‌سازی checkpointها یا زمان‌بندی اجرای کارها (Scheduling) از ابزار خارجی استفاده شود (پیکبرندی به گونه‌ای باشد که از قابلیت‌های این ابزارها استفاده شود) در آن صورت دسترس‌پذیری ابزار وابسته به دسترس‌پذیری آن ابزارها نیز خواهد بود.تحمل خطا ابزار برای مقاوم‌شدن نسبت به خرابی‌ها به صورت داخلی پیاده‌سازی شده است. برای این منظور ابزار هر از چند گاهی از طریق checkpoint وضعیت سامانه را ذخیره‌سازی و حفظ می‌کند. نقاط checkpoint به ابزار امکان بازیابی وضعیت و موقعیت‌های موجود در جریان‌ها را برای بازیابی (recovery) از وضعیت ناموفق می‌دهد.کاراییبرنامه‌های Stateful Flink برای دسترسی به حالت محلی بهینه شده‌اند. وضعیت کارها همیشه در حافظه حفظ می‌شود یا اگر اندازه حالت از حافظه موجود بیشتر باشد، در ساختارهای داده روی دیسک با دسترسی کارآمد حفظ می‌شود. به همین دلیل، کارها همه محاسبات را با دسترسی به حالت محلی، اغلب در حافظه، انجام می‌دهند که تأخیر پردازش بسیار پایینی را ایجاد می‌کند. ابزار با کنترل دوره‌ای و ناهمزمان تلاش می‌کند تا تاثیر کمی بر روی تاخیر و توان پردازشی ایجاد کند.به منظور رسیدن به کارایی‌های بیش‌تر می‌توان آن را با ابزارهای دیگر در موضوعات check-pointing و ورودی داده و زمان‌بندی کارها متصل کنید تا از کارایی بیش‌تری برخوردار شوید. (متناسب با امکانات فراهم‌شده توسط ابزارهای خارجی)مقیاس‌پذیریاین ابزار پشتیبانی خوبی برای پارتیشن‌بندی و مقیاس‌بندی دارد. در صورتی که از ابزارهای دیگر مانند Yarn یا Mesos و ... برای پیکربندی زیرساخت اجرای عملگرها استفاده شود، مقیاس‌پذیری و دسترس‌پذیری وابسته به آن ابزارهای خارجی خواهد بود اما اگر از روش خوشه مستقل (standalone) استفاده شود، امکان فراهم‌سازی مقیاس‌بندی خوبی را فراهم می‌کند.تعامل‌پذیریابزار را می‌توان بر روی ارائه‌دهندگان منابع مختلف مانند YARN، Apache Mesos و Kubernetes و همچنین به عنوان خوشه مستقل روی گره‌ها مستقر کرد. تعامل با آن برای پیاده‌سازی منطق‌های برنامه می‌تواند مبتنی بر زبان‌های برنامه‌نویسی Java/Scala صورت بگیرد.ابزار برای ذخیره‌سازی checkpointها با ابزارهای خارجی مختلفی می‌تواند تعامل داشته باشد. از نمونه این ابزارها می‌توان به ابزارهای مدیریت صف مانند کافکا، Google Pub/Sub، RabbitMQ یا فضای فایلی مانند هادوپ، GFS، S3، NFS، Ceph اشاره کرد که امکان پیکربندی‌شدن به عنوان محل ذخیره‌سازی را دارند.به منظور تعامل با این ابزار امکانات رابط کنسولی فراهم شده است. ابزار به منظور پایش وضعیت کارها قابلیت‌های زیر را فراهم نموده است:رابط کاربری وب: رابط کاربری وب برای بازرسی، نظارت و اشکال‌زدایی برنامه‌های در حال اجرالاگ: استفاده از ابزار محبوب slf4j و قابلیت ادغام با چارچوب‌های log4j یا logbackمتریک‌ها: دارای سیستم متریک کامل برای جمع‌آوری و پایش سیستممحدودیت‌هادر صورتی که نیاز دارید تا از روش‌های متنوع‌تری (به غیر از جاوا یا اسکالا) برای تعامل استفاده کنید، نیاز به ابزار متفاوتی دارید.اگر چه ابزار امکانات پردازش داده‌های غیر جریانی (مثل جریان‌داده‌های ذخیره‌شده) را فراهم می‌کند اما امکانات فراوانی برای این ابزار در زمینه‌ی داده‌های جریانی ارائه شده است و احتمالا ابزارهای اختصاصی در زمینه‌ی پردازش داده‌ی دسته‌ای (batch processing) بهتر عمل خواهند کرد.ابزار Apache Drillکارکرد اصلی ابزار، پردازش داده با زبان SQL می‌باشد. یک موتور جستجوی SQL منبع باز برای جستجو داده‌های بزرگ است. اجرای پرس‌وجو بر روی داده‌های نیمه ساختاریافته و برنامه‌های کاربردی کلان‌داده را پشتیبانی می‌کند، در حالی که هنوز اکوسیستم ANSI SQL، زبان پرس و جو استاندارد صنعت را فراهم می‌کند.ویژگی‌های کارکردی پشتیبانی از استاندرادهای SQLجستجو به صورت پویا بر روی داده‌های خودتوصیف کننده (مانند JSON، Parquet، ...) بدون نیاز به تعریف اطلاعات افزوده (metadata) برای توصیف ساختار داده پیش از انجام جستجوپشتیبانی از مدل داده‌های متنوع و انعطاف‌پذیرپشتیبانی از داده‌های تو در توامکان انجام پرس‌وجو بر روی چندین پایگاه‌داده‌ی مختلف به صورت همزمان و اتصال خروجی آن‌ها در قالب مکانیزم‌های Join زبان SQLمعماریابزار شامل یک محیط اجرای توزیع شده است که برای پردازش داده در مقیاس بزرگ ساخته شده است. در هسته این ابزار سرویس Drillbit قرار دارد که مسئولیت پذیرش درخواست‌های کاربر، پردازش پرس‌وجوها و برگرداندن نتایج به کاربر را بر عهده دارد. ابزار از ZooKeeper برای نگهداری وضعیت عضویت گره‌ها در کلاستر و اطلاعات سلامت سرویس‌ها استفاده می‌کند. البته ابزار توانایی اجرا در هر محیط خوشه‌ای توزیع‌شده را دارد و تنها پیش‌نیاز آن Zookeeper است.کاربر (client) یک پرس و جو را ارسال می‌کند. هر سرویس (Drillbit) در خوشه می‌تواند درخواست‌های کاربران را بپذیرد و مفهوم ارباب یا برده در معماری ابزار وجود ندارد. سپس سرویس پرس و جو را تجزیه می‌کند، آن را بهینه می‌کند و یک طرح پرس و جو توزیع شده ایجاد می‌کند که برای اجرای سریع و کارآمد بهینه شده است. سرویسی که پرس‌وجو را می‌پذیرد به گره محرک (driver) برای درخواست تبدیل می‌شود. این سرویس فهرست گره‌های دیگر را از زوکیپر دریافت می‌کند و گره‌های مناسب را برای اجرای قطعات طرح پرس‌وجوی مختلف برای به حداکثر رساندن محلی‌بودن داده‌ها تعیین می‌کند. سرویس‌ محرک اجرای قطعات پرس‌وجو را بر روی گره‌های جداگانه طبق برنامه اجرا زمان‌بندی می‌کند. گره‌های مجزا اجرای خود را به پایان می‌رسانند و داده‌ها را به سرویس محرک برمی‌گردانند. سرویس محرک جواب‌های بازگردانده‌شده را در قالب جریان داده به کاربر باز می‌گرداند.تصویر زیر نشان‌دهنده اجزای سرویس Drillbit است:معماری سرویس Drillbit (منبع عکس)اجزای مهم این سرویس موارد زیر هستند:بخش نقطه اتصال RPC: فراهم‌کننده‌ی نیازمندی‌های ارتباطی از سمت کاربران (پشتیبانی از پروتکل‌های متنوع ارتباطی)بخش تحلیل‌کننده‌ی SQL: تبدیل پرس‌وجوهای ورودی به خروجی مستقل از زبان (برای تحلیل‌های موردنزار در ادامه) از طریق ابزار منبع‌باز Calciteبخش بهینه‌ساز: استفاده از بهینه‌سازی‌های مختلف مانند قوانین مبتنی بر قواعد یا مبتنی بر هزینه، موقعیت مکانی داده‌ها، سایر قوانین بهینه‌سازی مربوط به ابزار فراهم‌کننده داده، ... برای بازنویسی و تقسیم پرس‌و‌جوماشین اجرایی: یک موتور اجرای توزیع‌شده برای انجام پردازش پرس و جو در گره‌های مختلف خوشهرابط‌های افزونه داده: یک لایه انتزاعی برای ارتباط با منبع‌داده‌های مختلف به منظور فراهم‌سازی فراداده موجود در منبع، رابط‌هایی برای خواندن و نوشتن در منابع داده، مکان داده‌ها و مجموعه‌ای از قوانین بهینه‌سازی برای کمک به اجرای کارآمد و سریعتر پرس و جوهادسترس‌پذیریبا توجه به نبود مکانیزم master/slave و امکان افزایش تعداد سرویس‌ها در خوشه، به راحتی امکان افزایش دسترس‌پذیری ابزار وجود دارد. همچنین در هنگام اجرای پرس و جوها، در صورت رخداد خطا در هر گره، اجرای آن را به گره‌های دیگر منتقل می‌کند که سبب نمی‌شود نسبت به رخداد خطا تحمل‌پذیر بوده و دسترس‌پذیری آن افزایش یابد. البته متناسب با نوع داده‌ای که برای کوئری انتخاب می‌شود (مثلا مخزن HDFS و ...)، تحمل خطای ابزار در برابر مشکلات وابسته به ابزار جانبی نیز خواهد بود.کارایی بهینه‌ساز درونی ابزار، اطلاعات ارائه‌شده توسط ابزار (مثلا metadataهای فایل پارکت یا جدول Hive و ...) به‌طور خودکار استفاده می‌کند تا طرح پرس‌وجو را بازسازی کرده و از قابلیت‌های پردازش داخلی پایگاه‌داده‌ی هدف استفاده کند.پشتیبانی از مکانیزم تشخیص داده‌های محلی به منظور کاهش پنهای باند شبکه و افزایش سرعتمدیریت تخصصی حافظه به منظور کاهش میزان مصرف حافظه و حذف جمع‌آوری زبالهبهینه‌ساز پیشرفته مبتنی بر هزینه که در صورت امکان، پردازش را تا حد امکان به لایه‌ی خواندن داده‌ی ذخیره‌شده نزدیک می‌کند.بردارسازی (Vectorization): به جای کار بر روی مقادیر یک رکورد جدول در زمان، بردارسازی به CPU اجازه می‌دهد تا بر روی بردارهایی که مجموعه‌ای از رکوردها هستند، کار کند. (با استفاده از تکنولوژی‌های جدید این نوع محسابات خیلی سریع‌تر هستند)کامپایل در زمان اجرا: کامپایل در زمان اجرا در مقایسه با اجرای تفسیرشده سریع‌تر بوده و کد سفارشی بسیار کارآمد را برای هر پرس و جو و هر اپراتور تولید می‌کند.مقیاس‌پذیریاین ابزار به راحتی با بالا آوردن یکسری سرویس (Drillbet) اجرا می‌شود و به راحتی توسط ابزار ZooKeeper مقیاس پیدا کرده و روی چندین گره بالا بیاید. ابزار برای شروع فرآیند اجرای پرس و جو نیازی به مشخصات طرح یا نوع برای داده‌ها ندارد. این ابزار ساختارداده‌ها را را در حین پردازش کشف می‌کند. برخلاف سایر فناوری‌های مانند پایگاه‌داده سنتی رابطه‌ای، ابزار نیازی به ابرداده (metadata) متمرکز ندارد. به منظور پرس و جو از داده‌ها، کاربران نیازی به ایجاد و مدیریت جداول/نماها در یک مخزن ندارند و به همین دلیل به راحتی می‌تواند بر روی هر نوع داده‌ای سوار شده و مقیاس آن به راحتی کاهش یا افزایش پیدا کند.تعامل‌پذیریکاربر (client) یک پرس و جو را از طریق روش‌های JDBC، ODBC، رابط خط فرمان یا REST API ارسال می‌کند. ابزار در کنار فایل محلی سیستم عامل از انواع داده‌های NoSQL از جمله موارد زیر پشتیبانی می‌کند:HBase، MongoDB، MapR-DB، HDFS، MapR-FS، Amazon S3، Azure Blob Storage، Google Cloud Storage، Swift، NAS, ...کاربران تجاری، تحلیلگران داده می‌توانند از ابزارهای استاندارد BI زیر برای تعامل با داده‌های غیرمرتبط استفاده کنند. توسعه‌دهندگان می‌توانند از REST API ساده ابزار در برنامه‌های سفارشی خود برای ایجاد داشبوردهای مفید استفاده کنند:Tableau، Qlik، MicroStrategy، Spotfire، SAS, Excel, ...ابزار یک معماری قابل توسعه را در همه لایه‌ها، از جمله لایه افزونه ذخیره‌سازی، لایه پرس و جو، بهینه‌سازی، اجرای پرس و جو و API های کاربر ارائه می‌دهد. هر لایه را برای نیازهای خاص می‌توان سفارشی کرد یا لایه را به مجموعه وسیع‌تری از ابزار گسترش داد.محدودیت‌هاعدم پشتیبانی از عملکرد تجميعي فراوانمحدودیت در توابع تعریف شده توسط کاربر (UDF)عدم پشتیبانی از پرس و جو سلسله مراتبیعدم پشتیبانی از پرس و جو فرعی (subquery) تک ردیفیمحدودیت‌هایی در عملیات join و group byابزار Apache Hiveکارکرد اصلی ابزار پردازش داده‌های روی سیستم منبع‌باز Hadoop می‌باشد. یک ابزار ذخیره‌سازی داده در اکوسیستم Hadoop است که زبانی شبیه SQL را برای پرس و جو و تجزیه و تحلیل کلان داده ارائه می‌کند. انگیزه اصلی ایجاد ابزار، مسیر یادگیری ساده‌تر برای توسعه دهندگان و تحلیلگران کلان‌داده می‌باشد.ویژگی‌های کارکردیتجزیه و تحلیل داده‌های ساخت‌یافته و نیمه‌ساختار یافته بر روی سیستم Hadoopکاهش پیچیدگی MapReduce با فراهم‌سازی امکانات پرس‌وجوهای به زبان Hive Query Language شبیه به دستورات SQLمعماریبا توجه به اجرای Hive بر روی خوشه Hadoop، معماری این ابزار پیچیدگی‌های کمی داشته و می‌توان آن را به صورت خلاصه در تصویر زیر مشاهده نمود:معماری ابزار Hive (منبع عکس)بخش کلایت: این ابزار از برنامه‌های نوشته شده در بسیاری از زبان‌ها با استفاده از پروتکل‌های مختلف به منظور ارتباط با سرور پشتیبانی می‌کند.خدمات Hive: خدمات مختلفی مانند رابط کاربری وب، کنسول و ... برای انجام پرس و جو ارائه شده است.چارچوب پردازش و مدیریت منابع و ذخیره‌سازی توزیع شده: در داخل ابزار از چارچوب Hadoop MapReduce به عنوان موتور واقعی برای اجرای پرس و جوها استفاده می‌شود. از آن‌جایی که ابزار بر روی هادوپ نصب می‌شود، از HDFS زیرساخت هادوپ برای ذخیره‌سازی توزیع شده استفاده می‌کند.درایور (driver) پرس و جو را به کامپایلر ارسال می‌کند که در آن تجزیه، بررسی نوع و تحلیل معنایی با کمک طرح‌های تعریف‌شده در metastore انجام می‌شود. در مرحله بعد، یک طرح منطقی بهینه شده در قالب DAG از MapReduceها تولید می‌شود. در نهایت موتور اجرایی این وظایف را به ترتیب وابستگی‌ها با استفاده از زیرساخت هادوپ اجرا می‌کند.بخش metastore به عنوان یک مخزن مرکزی برای ذخیره تمام اطلاعات فراداده موردنیاز ابزار استفاده می‌شود. این اطلاعات شامل ساختار جداول و پارتیشن‌ها به همراه ستون، نوع ستون، نوع تبدیل فرمت‌ها یعنی serializer و deserializer و ... می‌باشد. این بخش از دو واحد اساسی تشکیل شده است: سرویسی که دسترسی بخش را برای سایر سرویس‌های ابزار فراهم می‌کند و پایگاه‌داده‌ای مستقل از HDFS که برای نگهداری اطلاعات فراداده استفاده می‌شود.مدل داده‌ی استفاده شده در این ابزار اطلاعات داده‌ها را مبتنی بر 3 مفهوم زیر نگهداری می‌کند:جداول: این جداول مشابه جداول در پایگاه‌های داده رابطه‌ای هستند. جداول را می‌توان فیلتر، متصل و متحد (union) کرد. علاوه بر این، تمام داده‌های یک جدول در یک پوشه در HDFS ذخیره می‌شود.پارتیشن: هر جدول می‌تواند یک یا چند کلید پارتیشن داشته باشد که نحوه ذخیره داده‌ها را تعیین می‌کند. داده‌های مربوط به جدول برای هر ترکیب‌های مختلف پارتیشن‌ها، در پوشه‌های جداگانه HDFS ذخیره می‌شوند. (به همین دلیل برای رسیدن به پرارتیشن P1=V1و P2=V2 از جدول T کافی است پوشه‌ی T/P1=V1/P2=V2 خوانده شود)تقسیم‌بندی: داده‌های هر پارتیشن ممکن است بر اساس hash یک ستون جدول به قسمت‌هایی (buckets) تقسیم شوند. این روش به ابزار اجازه می‌دهد تا به طور موثرتر پرس و جوهایی را که به نمونه‌ای از داده‌ها بستگی دارد، ارزیابی کند.دسترس‌پذیریبا توجه به امکانات ابزار امکان بالاآوردن چندین نسخه از سرور (server) ابزار وجود داشته که امکانات دسترس‌پذیری را فراهم می‌کند. با توجه به وابستگی کامل ابزار به زیرساخت هادوپ، مواردی مثل تحمل‌پذیری، دسترس‌پذیری و ... ابزار کاملا مستقل نبوده و وابسته به نحوه‌ی استقرار HDFS هستند. از طریق استفاده از امکانات remote/local metastore قابلیت بالاآوردن چندین metastore را به صورت همزمان دارید که در نتیجه دسترس‌پذیری را افزایش می‌دهد. البته این metastore ها طبق توضیحات بالا از یک پایگاه‌داده جدا مستقل از HDFS استفاده می‌کنند. بدیهی است که دسترس‌پذیری ابزار به دسترس‌پذیری پایگاه‌داده‌ی استفاده‌شده نیز وابسته می‌باشد.کاراییذخیره اطلاعات فراداده ابزار در یک RDBMS به منظور کاهش زمان بررسی‌های معنایی (semantic) در طول اجرای پرس و جو از مهم‌ترین ویژگی‌های این ابزار می‌باشد. همچنین کامپایلر درونی این ابزار به گونه‌ای عمل می‌کند که پرس و جوهای ورودی را با توجه به اطلاعات فراداده به بهترین شکل (بهینه‌ترین حالت) به برنامه‌ی منطقی که درختی از MapReduce ها می‌باشد تبدیل کند. با این حال با توجه به وابستگی کامل ابزار به زیرساخت هادوپ، مواردی مثل کارایی اجرای پرس و جوها به قابلیت‌های فراهم‌شده توسط زیرساخت HDFS وابسته می‌باشد که در بخش‌های قبلی توضیح داده شده است.مقیاس‌پذیریاین ابزار با توجه به معماری ارائه‌داده قابلیت استقرار چندین سرور (Hive server) و همچنین چندین metastore را فراهم نموده است. با این حال افزایش تعداد این استقرارها سبب افزایش مقیاس‌پذیری اجرای پرس و جو نمی‌شوند و تنها دسترس‌پذیری را افزایش می‌دهند. این ابزار از زمان‌بندهای هادوپ و زیرساخت هدوپ استفاده می‌کند و به همین دلیل مقیاس‌پذیری آن منطبق بر مقیاس‌پذیری زیرساخت HDFS می‌باشد.تعامل‌پذیریابزار از هر برنامه کاربری نوشته شده در جاوا، PHP، Python، C یا Ruby پشتیبانی می‌کند و می‌تواند این برنامه‌ها را از طریق Thrift خود اجرا کند. همچنین ابزار رابط‌های کنسول (CLI) و رابط کاربری وب را نیز برای ارتباط فراهم نموده است.محدودیت‌هابا توجه به محدودیت زیرساخت Hadoop، ابزار از عملیات update و delete پشتیبانی نمی‌کند.این ابزار برای پردازش‌های لحظه‌ای (real-time) یا تراکنشی (OLTP) مناسب نمی‌باشد.پرس و جوهای فرعی (sub-query) پشتیبانی نمی‌شوند.زبان HQL از ویژگی پردازش تراکنشی (Transactional) پشتیبانی نمی‌کند.ابزار Apache Pigکارکرد اصلی ابزار پردازش داده می‌باشد. این ابزار یک پلتفرم برای تجزیه و تحلیل مجموعه داده‌های بزرگ است که از یک زبان سطح بالا برای بیان برنامه‌های تجزیه و تحلیل داده‌ها تشکیل شده است.ویژگی‌های کارکردیزبان Pig یک زبان سطح بالا (بر خلاف MapReduce به زبان جاوا) است.پشتیبانی از رویکرد چند پرس و جو به منظور کاهش حجم کد (یک پرس و جو می‌تواند به چندین MapReduce تبدیل شود)دارای مجموعه‌ای غنی از عملگرها مانند پیوستن، مرتب‌سازی، فیلتر کردن و ... برای خواندن، نوشتن و پردازش مجموعه داده‌های بزرگگسترش زبان با نوشتن توابع سفارشی در Pig (به هر زبانی مانند جاوا، پایتون، روبی، جیتون، جی روبی و ...)مدیریت انواع داده‌ها شامل داده‌های ساختاریافته، نیمه ساختاریافته یا بدون ساختارپشتیبانی از عملیات استخراج، تبدیل و بارگزاری (ETL)پشتیبانی از تعریف طرحواره (schema) برای داده‌هامعماریمعماری این ابزار با توجه به قرارگیری بر روی زیرساخت HDFS، ساده و به صورت زیر می‌باشد:معماری ابزار (منبع عکس)در ابتدا اسکریپت نوشته‌شده به زبان Pig به محیط اجرای Pig توسط محیط تعاملی (shell) یا سرور ارسال می‌شوند. Pig Script ها در ادامه به بخش پارسر منتقل می‌شوند. پارسر پس از بررسی نوع و نگارش اسکریپت، یک DAG (گراف غیر چرخه‌ای جهت دار) را خروجی می‌دهد. عملگرهای منطقی به صورت گره‌ها و جریان‌های داده به صورت یال‌ها نمایش داده می‌شوند. سپس DAG به بهینه‌ساز ارسال می‌شود. بهینه‌ساز فعالیت‌های بهینه‌سازی مانند عملگرهای تقسیم، ادغام، تبدیل و ترتیب مجدد و ... را انجام می‌دهد. پس از فرآیند بهینه‌سازی، کامپایلر کد بهینه شده را در قالب یکسری MapReduce کامپایل می‌کند. کامپایلر وظیفه تبدیل کارهای Pig را به طور خودکار به MapReduce بر عهده دارد. MapReduce برای اجرا به موتور اجرا ارسال می‌شوند و بعد از اجرا نتیجه لازم متناسب با نیاز کاربر ذخیره یا نمایش داده می‌شوند.دسترس‌پذیریتوضیحات مبنی بر امکان بالاآوردن برنامه به صورت HA در مستندات نرم‌افزار یافت نشد. متاسفانه امکان اجرای چندین نسخه (instance) از مولفه وجود دارد اما هر نسخه به صورت مستقل عمل می‌کند و اطلاعات داخلی یک نسخه در صورت رخداد مشکل در اختیار نسخه دیگر نیست. اگر چه با توجه به وابستگی کامل ابزار به زیرساخت هادوپ، مواردی مثل تحمل‌پذیری، دسترس‌پذیری و ... ابزار کاملا مستقل نبوده و وابسته به نحوه‌ی استقرار HDFS می‌باشد، اما اگر خود برنامه قابلیت HA نداشته باشد، امکان دارد در هنگام ارسال MapReduce ها به زیرساخت هادوپ دچار مشکل شود. (حتی اگر زیرساخت هادوپ کاملا در دسترس باشد) کاراییابزار به طور خودکار وظایف و پرس و جوهای تعریف‌شده را قبل از اجرا بهینه می‌کند. برای این منظور از تکنیک‌های مختلفی به صورت پیشفرض بهره می‌گیرد شامل موارد زیر (لیست کامل آن‌ها و توضیحاتشان را می‌توانید از این لینک مشاهده کنید)PushUpFilter, PushDownForEachFlatten, ColumnPruner, MapKeyPruner, LimitOptimizer, ...با توجه به وابستگی کامل ابزار به زیرساخت هادوپ، مواردی مثل کارایی اجرای پرس و جوها به قابلیت‌های فراهم‌شده توسط زیرساخت HDFS وابسته می‌باشد که در بخش‌های قبلی توضیح داده شده است.مقیاس‌پذیریاین ابزار از زمان‌بندهای هادوپ و زیرساخت هدوپ استفاده می‌کند و به همین دلیل مقیاس‌پذیری آن منطبق بر مقیاس‌پذیری زیرساخت HDFS می‌باشد. البته خود برنامه بار محساباتی کمی دارد با این حال امکان بالاآوردن چند نسخه از ابزار به صورت مستقل وجود دارد که می‌توان از این طریق برای کاهش بار روی یک نسخه اقدام کرد.تعامل‌پذیریابزار از زبان اسکریپت خاصی و مشخصی استفاده می‌کند. با این حال در صورتی که نیاز به این باشد که یکسری توابع شخصی برای توسعه قابلیت‌های ابزار نوشته شود، امکان نوشتن این کدهای توسعه‌دهنده در قالب زبان‌های مبتنی بر JVM مثل جاوا و اسکالا وجود دارد. همچنین ابزار تنها رابط‌های کنسول (CLI) را فراهم نموده است.محدودیت‌هابا توجه به محدودیت زیرساخت Hadoop، ابزار از عملیات update و delete پشتیبانی نمی‌کند.خطاهای ایجادشده در ابزار مخصوصا در موارد UDF بسیار ناقص هستند.پشتیبانی این ابزار در سایت‌های مثل stackoverflow و ... کم می‌باشد.برای زبان اسکریپت آن IDE مناسب وجود نداشته و باید به مستندات تکیه کرد.ابزار Apache Impalaکارکرد اصلی پردازش داده‌ می‌باشد. Impala یک موتور پرس و جوی SQL با پردازش موازی انبوه، منبع باز، کاملاً یکپارچه است که به طور خاص برای استفاده از انعطاف‌پذیری و مقیاس‌پذیری Hadoop طراحی شده است.ویژگی‌های کارکردیتاخیر کم و همزمانی بالا برای پرس و جوهای تحلیلی بر روی Hadoopرابط SQL آشنا که تحلیلگران داده با آن آشنا هستند.علاوه بر ویژگی‌های اولیه SQL (انتخاب، پیوستن، گروه‌بندی، ترتیب، محدود کردن)، از نماهای درون خطی، پرسش‌های فرعی (subquery) ناهمبسته و همبسته، همه انواع اتصالات بیرونی (outer-join) شامل چپ/راست نیمه یا ضد اتصال (anti-join) و توابع پنجره تحلیلی (window function) پشتیبانی می‌کند.معماریمعماری این ابزار به صورت خلاصه از سه سرویس اصلی تشکیل شده است. معماری سطح بالای ابزار را در عکس زیر مشاهده می‌کنید:معماری ابزار Impala (منبع عکس)سرویس Impala daemon (impalad) به صورت همزمان دو وظیفه پذیرش پرس‌و‌جوها از سمت کاربر (client) و هماهنگی اجرای آن‌ها در سراسر خوشه را بر عهده دارد. البته این سرویس در اجرای قطعات پرس و جو از طرف دیگر سرویس‌های impalad موجود در خوشه نیز مشارکت می‌کند. هنگامی که این سرویس با مدیریت اجرای پرس و جو کاربر در نقش اول عمل می‌کند، به عنوان هماهنگ‌کننده پرس و جو (Coordinator) عمل می‌کند. همه این سرویس‌ها متقارن هستند و هر کدام ممکن است در همه نقش‌ها (اجراکننده یا هماهنگ‌کننده) عمل کنند. این ویژگی به تحمل خطا و تعادل بار کمک می‌کند.یک سرویس impalad بر روی هر ماشینی در خوشه که datanode اجرا می‌کند، مستقر می‌شود. این به Impala اجازه می‌دهد تا از موقعیت داده‌ها استفاده کند و بلوک‌ها را از سیستم فایل بدون نیاز به استفاده از شبکه بخواند. دومین سرویس، سرویس نگهدارنده‌ی وضعیت (Statestore) می‌باشد که یک سرویس برای اشتراک فراداده (metadata) از طریق مکانیزم انتشار/اشتراک (publish-subscribe) می‌باشد. فراداده‌های خوشه در تمام سرویس‌های Impala توسط این قسمت منتشر می‌شود. درواقع همه گره‌ها باید مثلاً نسخه‌های به‌روز کاتالوگ سیستم و نمای اخیر عضویت خوشه (گره‌هایی که سالم بوده و توانایی مشارکت دارند) و ... داشته باشند تا درخواست‌ها به درستی زمان‌بندی شوند. طراحی ابزار برای جلوگیری از RPC های همزمان و چالش‌های آن، به گونه‌ای انجام شده است تا به‌روزرسانی‌ها برای همه طرف‌های علاقه‌مند ارسال شود. پیاده‌سازی این سرویس شبیه ترکیبی از Zookeeper و Kafka می‌باشد اما به صورت مستقل توسط ابزار توسعه و استقرار می‌یابد. سومین سرویس، سرویس کاتالوگ (Catalog) می‌باشد که به عنوان مخزن کاتالوگ عمل می‌کند. تغییرات اعمال‌شده در کاتالوگ از طریق سرویس نگهدارنده‌ی وضعیت پخش می‌شود. سرویس کاتالوگ اطلاعات را از ابزارهای دیگر (به عنوان مثال Hive Metastore یا HDFS Namenode) دریافت و آن اطلاعات را در یک ساختار کاتالوگ سازگار با Impala نگهداری می‌کند. این معماری به ابزار اجازه می‌دهد تا نسبت به ساختار ابزارهای دیگر بی‌اعتنا باشد و امکان اضافه‌کردن فراداده‌های ابزارهای دیگر (مثلاً HBase) وجود داشته باشد. از آن‌جایی که کاتالوگ‌ها اغلب بسیار بزرگ هستند، فراداده‌ها در پس‌زمینه به صورت lazy بارگزاری می‌شوند.در کنار موارد بالا ابزار از دو بخش اصلی frontend و backend تشکیل شده است. بخش frontend مبتنی بر زبان جاوا توسعه یافته است و بخش backend مبتنی بر زبان C++ توسعه یافته است. بخش forntend مسئول کامپایل متن SQL در طرح‌های پرس و جو برای اجرا توسط سرویس‌های ابزار است. کامپایل شامل تجزیه کننده SQL، بهینه‌ساز پرس و جو مبتنی بر هزینه و ... است که همگی از ابتدا پیاده‌سازی شده‌اند. (از ابزارهای دیگر استفاده نشده است) بخش backend قطعات پرس و جو را از frontend دریافت می‌کند و مسئول اجرای سریع آن‌ها است. (طراحی این بخش متناسب با امکانات سخت‌افزار مدرن می‌باشد) دسترس‌پذیریتمامی سرویس‌های impalad موجود در خوشه به دلیل قابلیت دریافت پرس و جو از سمت کاربر، شبیه هم بوده و به همین دلیل دسترس‌پذیری در زمینه ارسال پرس و جو به خوشه و اجرای آن کاملا بالا می‌باشد. بخش نگه‌دارنده‌ی وضعیت (statestore) هیچ ابرداده‌ای را روی دیسک نگه نمی‌دارد و همه ابرداده‌های فعلی توسط مشترکین زنده به آن منتقل می‌شوند. بنابراین، در صورت راه‌اندازی مجدد این سرویس (به علت مشکل یا بعد از اعمال یک تغییر)، وضعیت آن در مرحله اولیه ثبت‌نام توسط مشترکان (سرویس‌های impalad) بازیابی می‌شود. اگر دستگاهی که سرویس روی آن کار می‌کند از کار بیفتد، سرویس جایگزین می‌تواند در جای دیگری راه‌اندازی شود و مشترکان از این به بعد از آن استفاده کنند. ابزار به صورت خودکار مکانیزمی برای انتقال درخواست‌ها به سمت سرویس جدید ندارد و معمولا از ابزارها و روش‌های دیگر مثل تنظیمات DNS استفاده می‌کنند تا مشترکان را به طور خودکار به سرویس جدید متصل شوند.بدیهی است که به دلیل قرارگیری این سرویس بر روی سرویس‌های HDFS یا HBase و ...، دسترس‌پذیری این سرویس وابسته به سرویس‌های نامبرده نیز می‌باشد.کاراییابزار به جای استفاده از RPCهای همزمان که دارای کندی‌ها و چالش‌ها هستند، از رویکرد انتشار/ اشتراک استفاده نموده است. این رویکرد البته شاید چالش‌های دیگری داشته باشد اما تا حد خوبی توسط ابزار رفع شده‌اند.در زمینه‌ی سرویس کاتالوگ، از آنجایی که اطلاعات فراداده دیگر ابزارها اغلب بسیار بزرگ هستند و دسترسی به جداول به ندرت یکنواخت است، سرویس کاتالوگ فقط برای هر جدولی که در راه‌اندازی پیدا می‌کند یک اسکلت کلی ایجاد می‌کند. فراداده‌های جدول به صورت دقیق‌تر در پس‌زمینه بارگیری می‌شود. اگر جدول قبل از بارگیری کامل موردنیاز باشد، ابزار به صورت خودکار این را تشخیص داده و یک درخواست با اولویت را به سرویس کاتالوگ صادر می‌کند. این درخواست تا زمانی که جدول به طور کامل بارگیری شود سرویس را مسدود می‌کند.در زمینه‌ی اجرای کوئری، مکانیزم‌هایی برای تحلیل و بهینه‌سازی پرس و جو بیش از اجرا استفاده می‌کند. ابزار از زبان C++ برای بخش اجرای پرس و جو استفاده می‌کند و از تولید کد در زمان اجرا برای تولید مسیرهای کد کارآمد (با توجه به تعداد دستورالعمل‌ها) و سربار حافظه کوچک، به ویژه در مقایسه با سایر موتورهای پیاده‌سازی شده در جاوا استفاده می‌کند. مقیاس‌پذیریتمامی سرویس‌های impalad موجود در خوشه، مشابه با یکدیگر بوده و هر کدام می‌توانند به عنوان مدیریت‌کننده‌ی پرس و جو یا اجراکننده عمل کنند. به همین دلیل به راحتی می‌توان با بالابردن تعداد سرویس‌ها، مقیاس ابزار را برای پردازش و اجرای کوئری‌ها افزایش داد. در پیاده‌سازی ارائه‌شده توسط ابزار، تنها یک سرویس statestore در نظر گرفته‌شده است و طبق ادعای ابزار برای کلاسترهایی با اندازه‌های کوچک تا میانه نیز کافی است. با این حال امکان بالا آوردن چند عدد از این سرویس برای تقسیم بار و مقیاس‌پذیری ممکن است.تعامل‌پذیرییک موتور کاملاً جدید است که از ابتدا به زبان C++ و جاوا نوشته شده است و با استفاده از مولفه‌های استاندارد از جمله HDFS، HBase، YARN و ... انعطاف‌پذیری Hadoop را حفظ می‌کند و می‌تواند اکثر فرمت‌های فایل پرکاربرد مانند Sequence File، Parquet، Avro، RCFile و ... را بخواند.از بیش‌ترین استاندارها و دستورات موجود در حوزه‌ی SQL پشتیبانی می‌کند. منطق‌های سفارشی موردنیاز برنامه را می‌توان از طریق توابع ساده یا تجمعی تعریف‌شده توسط کاربر (UDF) به زبان‌های جاوا و C++ اضافه نمود. تعامل با این ابزار برای اجرای پرس و جو از طریق رابط تعاملی (shell)، ارتباطات ODBC یا JDBC یا Hue قابل انجام است.محدودیت‌هابا توجه به محدودیت زیرساخت Hadoop، ابزار از عملیات update و delete پشتیبانی نمی‌کند.اگر چه می‌تواند برای عملیات پردازش دسته‌ای استفاده شود اما برای پردازش ad-hoc مناسب‌تر است.هیچ پشتیبانی از Serialization و Deserialization در Impala وجود ندارد.وقتی رکوردها/فایل‌های جدیدی به فهرست داده‌ها در HDFS اضافه می‌شود (به صورت مستقیم و از نه طریق ابزار)، باید دستور بروزرسانی جدول بر روی ابزار اجرا شود.امکان خواندن فایل‌های باینری سفارشی (نه فرمت‌های معروف مثل پارکت و ...) در ابزار وجود ندارد.ابزار Apache Flumeکارکرد اصلی واردنمودن یا خارج‌سازی داده می‌باشد. یک ابزار استاندارد، ساده، قوی، انعطاف‌پذیر و قابل توسعه برای دریافت داده‌ها از تولیدکنندگان مختلف داده (مانند فایل‌های گزارش، رویدادها، ...) و واردسازی آن‌ها به یک مخزن داده متمرکز (معمولا Hadoop یا HBase) یا بلعلکس است.ویژگی‌های کارکردیپشتیبانی از مجموعه بزرگی از انواع منابع و مقصد (شامل Hadoop و HBase)فراهم‌سازی یک جریان داده ثابت بین داده‌های ورودی و خروجی در صورت وجود تفاوت در نرخ ورودی و نوشته‌شدن در مخزن‌های متمرکزپشتیبانی از جریان‌های multi-hop، جریان‌های fan-in fan-out، مسیریابی زمینه‌ای و ...تضمین تحویل مطمئن پیام بین فرستنده و دریافت‌کنندهمعماریمعماری ابزار در عین سادگی مزیت‌های فراوانی را به همراه آورده است. معماری این ابزار از یکسری عامل (Agent) تشکیل شده است. هر عامل از تعدادی ورودی داده (Source) دریافت می‌کند، داده‌ها را به یک یا چند کانال (Channel) ارسال می‌کند و تعدادی ارسال‌کننده (Sink) دارد که هر کدام بسته به نیاز به یک یا چند کانال وصل هستند و داده‌های کانال را دریافت کرده و به مقصد بعدی (مخزن داده یا یک عامل دیگر به عنوان گره بعدی) ارسال می‌کنند. رخدادها که در ورودی‌ها دریافت می‌شوند، به عنوان واحدی از جریان داده تعریف می‌شود که دارای بدنه بایتی (payload) و مجموعه‌ای اختیاری از ویژگی‌ها (headers) هستند. یک عامل یک فرآیند سیستمی مبتنی بر جاوا است که در ورودی خود رویدادها را دریافت و آن‌ها را به مقصد بعدی (hop) ارسال می‌کند.ساختار یک عامل در معماری ابزار (منبع عکس)با توجه به این معماری و امکان سواردکردن عامل‌ها به صوت زنجیره‌ای پشت سر هم، امکان ایجاد جریان داده‌های متنوع از جمله موارد زیر وجود دارد:جریان چند عامله (multi-hop): یک رویداد قبل از رسیدن به مقصد نهایی، ممکن است از طریق بیش از یک عامل سفر کند.جریان Fan-out: جریان داده از یک منبع به چندین کانال به عنوان جریان خروجی ارسال می‌شود. در این حالت ممکن است رویداد ورودی به همه‌ی خروجی‌ها برود یا صرفا به برخی از ورودی‌ها برود.جریان Fain-in: رویدادها از چندین منبع به یک کانال منتقل می‌شود.انتقال بین فرستنده و دریافت‌کننده در تمامی قسمت‌های جریان داده به صورت تراکنشی و ثبتی رخ می‌دهد و تا زمان عدم اطمینان از ارسال یک رویداد، فرآیند تکرار می‌شود. معماری به منظور افزایش کارایی و فراهم‌سازی کابردهای مختلف، مفاهیم دیگری را از جمله موارد زیر فراهم نموده است:گروه‌بندی بخشی از خروجی‌ها (Sink): فراهم‌سازی امکانات تقسیم بار و Failoverتعریف رهگیرها (interceptors): تغییر/بازرسی رویدادهادسترس‌پذیریابزار به منظور مقاوم‌بودن نسبت به مشکلات احتمالی در عامل‌ها، مکانیزمی به نام پردازنده‌های خروجی (Sink Processors) فراهم نموده است. از طریق این مفهوم می‌توان خروجی‌ها را گروه‌بندی نمود. گروه‌های خروجی به کاربران این امکان را می‌دهند که چندین خروجی را در یک موجودیت گروه‌بندی کنند. گروهبندی خروجی‌ها را می‌توان به منظور ارائه قابلیت‌های متعادل‌کننده بار (load balancing) در تمام خروجی‌های داخل گروه یا برای دستیابی به مقاوم‌کردن یک خروجی نسبت به خرابی موقت استفاده کرد. همچنین در قسمت ورودی مربوط به عامل‌ها، می‌تواند با اجرا کردن چندین عامل به منظور دریافت ورودی (جریان داده Fan-in) ورودی داده را نیز نسبت به خطاها مقاوم نمود. البته دسترس‌پذیری کامل ابزار وابسته به نحوه‌ی دریافت ورودی، نوع کانال‌های استفاده شده و نحوه‌ی ارسال خروجی می‌باشد. به عنوان مثال در صورتی که فرستنده از روش UDP برای ارسال ورودی استفاده کند، در صورت رخداد هر مشکل و عدم دریافت بسته و همچنین عدم ارسال دوباره از سمت فرستنده، بسته گم خواهد شد. یا در حالت استفاده از کانال in-memory در صورت رخداد خطا در عامل، اطلاعات درون حافظه از بین خواهد رفت. به همین دلیل دستیابی به دسترس‌پذیری کامل امکان‌پذیر است به شرطی که تنظیمات کانال و نحوه‌ی دریافت و ارسال به مخزن خروجی با نوع‌های مناسبی تنظیم شوند.کاراییبرخلاف استفاده از روش‌های ساده مانند put کردن در مخزن داده‌ی HDFS، ساخت فایل‌های Avro و ... که هر کدام تنظیمات فراوانی و موازی‌سازی برای رسیدن به کارایی خوب لازم دارند، با استفاده از معماری ابزار و اجرا کردن چند عامل یا استفاده از قابلیت‌های دسته‌بندی (batch) ابزار می‌توان به کارایی خوبی در نوشتن داده‌ها در خروجی دست یافت. همچنین بسته به نوع کانال‌های میانی می‌توان از مزیت‌های کارایی ابزارهای میانی نیز استفاده نمود. (به عنوان مثال کانال از نوع کافکا مزایا و کارایی‌های کافکا را نیز فراهم می‌کند)مقیاس‌پذیریمعماری ابزار به گونه‌ای است که به راحتی می‌توان به صورت افقی (horizontal) مقیاس برنامه را افزایش داد. افزایش یا کاهش مقیاس‌پذیری به راحتی و از طریق افزودن یا حذف یکسری عامل‌ها انجام می‌شود.تعامل‌پذیریتنظیم و مدیریت وضعیت و ساختار جمع‌کننده‌ها و فرستنده‌ها به راحتی و از طریق یکسری فایل کانفیگ صورت می‌گیرد که استفاده از ابزار را ساده و لذت بخش می‌کند. ابزار به صورت پیشفرض از لیست فراوانی از ورودی‌ها و خروجی‌ها پشتیبانی می‌کند که لیست کامل آن‌ها را از این لینک می‌توانید مشاهده کنید. به عنوان نمونه:Sources: Avro, Thrift, JMS, Kafka, NetCat, Sequence Generator, Syslog, HTTP Source, ...Channels: Memory, JDBC, Kafka, File, ...Sinks: HDFS, Hive, Avro, Thrift, File Roll, HBase, Elastic Search, Kafka, ...محدودیت‌هاضمانت‌های ضعیف‌تری نسبت به سیستم‌های دیگر در ترتیب ارسال داده‌ها (رویدادها حداقل یک بار تحویل داده می‌شوند، اما ترتیب دریافت داده‌ها در سمت دریافت‌کننده می‌تواند کاملا متفاوت از ترتیب ارسال باشد)امکان ارسال داده تکراری در سامانهابزار Apache Oozieکارکرد اصلی زمان‌بندی اجرای جریان کارها می‌باشد. در موارد بلادرنگ، یک کار به کارهای دیگر وابسته است، مانند خروجی یک کار MapReduce ممکن است برای پردازش بیشتر به Hive job منتقل شود. همچنین برنامه‌ریزی مجموعه‌ای از کارها می‌تواند بر اساس زمان مانند روزانه، هفتگی، ماهانه یا بر اساس در دسترس بودن داده باشد. ابزار این امکان را در اختیار شما قرار می‌دهد تا به راحتی این نوع سناریوها را مدیریت کنید.ویژگی‌های کارکردیمدیریت و اجرای کارهای Hadoop در یک محیط توزیع شدهاجرای ترکیب انواع مختلف وظایف مانند Spark، Hive، Pig، Sqoop یا MapReduce و ...امکان استفاده از قابلیت‌های Fork/Join برای اجرای موازی کارهایقابلیت زمان‌بندی اجرای کارهای بر اساس زمان، داده و شرایط رخدادپشتیبانی از انتظام‌های مختلف اجرا مانند FIFO، LIFO و ...معماریمدل‌های موجود در ابزار در قالب سه مفهوم قرار می‌گیرند:کارهای گردش کار (Workflow Jobs): نمودارهای غیر چرخشی جهت‌دار (DAG) که دنباله‌ای از کارها را برای اجرا توسط ابزار مشخص می‌کنند.کارهای هماهنگ‌کننده (Coordinator Jobs): شامل کارهای گردش کار (Workflow) است که متناسب با تنظیم صورت‌گرفته، بر اساس زمان، در دسترس بودن داده و دیگر شرایط راه‌اندازی (trigger) می‌شوند.دسته (Bundle): مجموعه‌ای از چندین هماهنگ‌کننده (Coordinator) و کارهای گردش کار (Workflow)مدل‌هایموجود در ابزار (منبع عکس)معماری ابزار به سادگی تصویر زیر می‌باشد (در تصویر نحوه‌ی در دسترس بودن بالا نیز نمایش داده شده است):نمای در دسترس بالای ابزار در هنگام استقرار (منبع عکس)یک سرور Oozie به عنوان برنامه وب جاوا که در سرور Tomcat میزبانی می‌شود مستقر می‌شود و تمام اطلاعات مرحله‌ای مانند تعاریف گردش کار، کارها و ... در یک پایگاه داده ذخیره می‌شوند. بخش کاربر (کلاینت) Oozie در واقعی کاربری است که به منظور تعریف گردش کار، اجرای یک کار، تنظیم و ... به سرور متصل می‌شود.دسترس‌پذیریدسترس‌پذیری بالا در ابزار از طریق بالاآوردن چندین نسخه از برنامه به صورت همزمان انجام می‌شود. تمامی این نسخه‌ها برای مشاهده‌ی یک وضعیت یکسان و ارتباط با یکدیگر، به یک پایگاه‌داده‌ی یکسان متصل می‌شوند. (بدیهی است که برای رسیدن به حداکثر دسترسی و حذف نقطه‌ی شکست، لازم است پایگاه داده نیز به صورت دسترس‌پذیر تنظیم و اجرا شود)همچنین خود ابزار هیچ وضعیتی را در زمان اجرا در مموری نگه نمی‌دارد و اجرای تمای کارهای تعریف‌شده توسط کلاسترها‌ی دیگر (مانند Hadoop، Hive، Spark و ...) انجام می‌شود. به همین دلیل در عمل دسترس‌پذیری کامل این ابزار وابسته به تنظیم درست وابسته‌های زیرساختی ابزار می‌باشد. کاراییبا توجه به شیوه‌ی طراحی ابزار، میزان منابع مصرفی سرور بسیار کم می‌باشد و به همین دلیل به راحتی با حداقل منابع، بهترین عملکرد را خواهد داشت. البته بدیهی است که کارایی این ابزار وابسته به پایگاه‌داده‌ی استفاده‌شده، نوع کارها و تنظیمات مربوط به خوشه‌های اجراکننده‌ی کارها می‌باشد که در بخش‌های قبلی توضیح داده شده‌اند. مقیاس‌پذیریابزار به راحتی در مقیاس افقی (horizontal) قابل توسعه است. اجرای کار خاص در فرآیند سرور ابزار نیست. سرور تنها مسئول اجرای گردش کار است، در حالی که اقدامات در گردش کار، مانند MapReduce یا جاوا، توسط خوشه‌ای دیگر اجرا می‌شوند. سرور تنها مسئول استعلام وضعیت اجرا و نتایج این اقدامات است، بنابراین بار سرور کم می‌باشد. با این حال اگر تعداد گردش کار ارسالی توسط کاربران افزایش یافت، به سادگی می‌توان تعداد سرورهای Oozie را اضافه کرد. وضعیت کار در پایگاه داده رابطه‌ای حفظ می‌شود. از آن‌جایی که وضعیت کار به جای حافظه یک ماشین، در پایگاه داده ذخیره می‌شود، بسیار مقیاس‌پذیر است.تعامل‌پذیریپایگاه داده مربوط به ذخیره‌سازی وضعیت ابزار می‌تواند انوع مختلفی از پایگاه‌داده‌ها از جمله موارد زیر باشد:Apache Derby، HSQL، Oracle، MySQL, PostgreSQL, ...همچنین بخش کلاینت به منظور اتصال به سرور می‌تواند از مکانیزم‌های مختلفی مانند HTTP و رابط کاربری وب، REST API، رابط تعاملی (CLI) و ... استفاده کند.محدودیت‌هاابزارهای دیگری نیز امکانات تعریف گردش کار و زمان‌بندی را ارائه می‌دهند در حالی که امکان استقرار آن‌ها به شکل بهتری در محیط‌های جدید همچون کوبرنتیز و ... موجود است. امکانات پیشرفته برای استفاده‌ی منصفانه از منابع در هنگام زمان‌بندی ارائه نشده است.وابستگی فراوان به پایگاه‌داده در شرایط بار زیاد می‌تواند بسته به تنظیمات پایگاه داده منجر به کندی شود.جمع‌بندیابزارهای فراونی در این زمینه موجود هستند و تنها بخشی از آن‌ها بررسی و تحلیل شدند. اطلاعات دقیق فنی این ابزارها، تعاملات آن‌ها، ویژگی‌های آن‌ها و ... همه در بخش‌های قبلی قابل مشاهده است. برای هر ابزار می‌توانید با مطالعه همان ابزار به اطلاعات خلاصه‌ای در مورد جنبه‌های مختلف معماری آن برسید. با این حال اگر نیاز داشته باشید که یک یا چند ابزار را از نظر «تعامل‌پذیری» مقایسه کنید، می‌توانید توضیحات مربوط به این بخش را برای هر کدوم از دو ابزار مطالعه کنید و مقایسه کنید. به همین دلیل با توجه به این که امکان مشاهده‌ی کامل تمامی اطلاعات ابزار یا مقایسه یکسری ویژگی‌های ابزارهای مختلف با یکدیگر وجود دارد، در ادامه تلاش است که بر اساس چند رویکرد خاص و توضیحات قبلی، دسته‌بندی‌هایی را ایجاد کنیم.مهم‌ترین و شاید متمایزترین ویژگی بین ابزارهای بررسی‌شده، کارکرد ابزار می‌باشد. ابزارها هر کدام یک کارکرد اصلی داشته و در عین حال از چندین کارکرد دیگر نیز پشتیبانی می‌کردند. به همین دلیل در جدول زیر دسته‌بندی مربوط صورت‌گرفته برای کارکردهای مختلف را مشاهده می‌کنید. در این جدول نام یک ابزار می‌تواند در چندین سطر مشاهده شود که نشان‌دهنده‌ی پشتیبانی ابزار از کارکردهای مختلف می‌باشد. همچنین بخشی از ابزارها به دلیل حجم بالای مقاله مورد بررسی دقیق قرار نگرفتند اما بر اساس یه جستجوی ساده، دسته‌بندی آن‌ها مشخص شده و با رنگ قرمز مشخص شده‌اند. (البته دقت این روش کم بوده و ممکن است ابزار کارکردهای دیگری هم داشته باشد که در نظر گرفته نشده باشد)مقایسه کارکرهای مختلف ابزارهای بررسی‌شدهاین ابزارها در زمان‌های مختلفی ایجاد شده و ممکن است این پنداشت وجود داشته باشد که ابزارهای جدید نسبت به ابزارهای قدیمی رویکرد بهتری داشته باشند. با این حال خوب است که بدانیم محبوبیت این ابزارها طبق بررسی صورت‌گرفته به صورت زیر می‌باشد (معیار بررسی میزان محبوبیت مخزن توسعه می‌باشد):محبوبیت ابزارهای مختلفهمان‌طور که مشاهده می‌شود ابزارهای Apache HDFS & YARN، Apache Spark و Apache Flink جزو مواردی هستند که محبوبیت بسیار زیادی دارند. این در حالی است که این موارد معمولا بهترین عملکرد خود را در کنار ابزارهای دیگر دارند و همراه با آن استفاده می‌شوند. تقریبا این ابزارها با توجه به community فعالی که دارند در حال توسعه و پیشرفت بوده و روز به روز بر محبوبیت آن‌ها افزوده می‌شود.نکته‌ی جالب دیگر در این مورد ابزارها بررسی زمان انتشار اولین نسخه‌ی رسمی آن‌ها می‌باشد. نمودار زمانی می‌تواند نکات جالب دیگری را در مورد این ابزارها نسبت به نمودارهای قبلی نشان دهد.نمودار زمانی انتشار ابزارها مختلف بررسی‌شده در مقالههمان‌طور که در این نمودار مشاهده می‌شود، ابزار Apache HDFS & YARN که جزو محبوب‌ترین ابزارها نیز بود، خوب جزو پیشگامان و اولین‌ها در حوزه‌ی پردازش داده می‌باشد. این در حالی است که ابزار Apache Spark که محبوبیت فراوانی داشت در سال 2014 (تقریبا 8 سال بعد) منتشر شده است. همچنین ابزار معروف دیگر یعنی Apache Flink نیز در سال 2011 (تقریبا 5 سال بعد) منتشر شده است. در کنار هم قرار دادن نمودار زمانی انتشار ابزارها و نمودار محبوبیت آن‌ها نشان می‌دهد که هر ابزاری مورد قبول جامعه قرار نمی‌گیرد و اگر چه امروزه تکنولوژی پیشرفت‌های فراوانی کرده است، اما ابزارهای قدیمی خود را به خوبی با تکنولوژی‌های جدید همگام کرده‌اند و به همین دلیل حس نیاز به ابزاری جدید برای سازگاری با معماری‌های جدید خیلی کم دیده شده است. (با توجه به نبود ابزارهای خیلی قوی جدید که در چند سال اخیر منتشر شده باشد)در کنار موارد بالا خوب است که با توجه بررسی‌هایی که در بخش‌های قبلی انجام شده است، گراف وابستگی/تعامل این ابزارها با یکدیگر را نیز بررسی کنیم.گراف وابستگی یا تعاملات ابزارهای مختلف بررسی‌شدهدر این گراف که در تصویر بالا مشاهده می‌کنید، هر کدام از ابزارهای بررسی‌شده به صورت یک گره هستند و ارتباط میان گره‌ها، وابستگی/تعامل ابزارهای را نشان می‌دهد. گراف به صورت جهت‌دار بوده و به همین دلیل وجود یال جهتداری از A به B نشان‌دهنده‌ی وابسته‌بودن/تعامل‌داشتن یک طرفه از سمت A به B می‌باشد. گره‌ها دارای دو حالت می‌باشند.گره‌های دارای پیکان توپور نشان‌دهنده‌ی وابستگی بین دو ابزار می‌باشند. به عبارتی ابزار برای عملکرد خود نیازمند ابزار دیگر بوده و بدون آن قابل استفاده نیست.پیکان‌های توخالی نشان‌دهنده‌ی تعامل بین دو ابزار هستند. به عبارتی ابزارها قابلیت اتصال و استفاده‌شدن در کنار هم را دارند. یک ابزار می‌تواند از قابلیت‌های ابزار دیگر استفاده کند اما این به معنای این نیست که حتما باید ابزار مربوطه استفاده شود.این گراف نیز به ما نشان می‌دهد میزان استفاده‌شده/تعامل‌پذیری ابزار Apache HDFS & YARN بسیار زیاد می‌باشد که حاکی از قدرت این ابزار می‌باشد. همچنین برخی ابزارهای مثل Hive اگر چه امروزه محبوبیت کمی دارند اما تعامل‌پذیری بالایی دارند که امکان مهاجرت را برای سازمان‌ها ساده می‌کنند. (مثلا سازمان از ابزار محبوب‌تری استفاده کند اما در عین حال مشابه قبل از آن استفاده کند) البته شما می‌توانید با قراردادن این نمودار در کنار دیگر نمودارها و تحلیل‌های آن‌ها به نکات جالبی دیگری نیز برسید!با این حال همان‌طور که مشاهده می‌کنید با توجه به معیارهای مختلف بیان‌شده در بخش‌های قبلی و اطلاعات ارائه‌شده در این بخش، ابزاری همه‌کاره به منظور رفع همه‌ی نیازمندی‌ها وجود دارد. هر کدام از ابزارها برای کارکردهایی خاص با ویژگی‌های خاص ارائه شده و بدون محدودیت نیستند. همچنین روز به روز تکنولوژی در حال پیشرفت می‌باشد و شرکت‌های بیش‌تری در این حوزه ابزارهای خود را متن‌باز کرده تا توسعه آن‌ها سرعت بیابد. به همین دلیل با توجه به این که نیاز شما در چه زمینه می‌باشد و به دنبال چه نوع کارهایی هستید، انتخاب شما متفاوت خواهد بود. در این مقاله تلاش شده است تا به صورت خلاصه و از نگاه‌های مختلف ابزارها بررسی شوند تا در زمان کوتاهی دید خوبی به شما بدهند. امیدوارم که توانسته باشید تصمیم خود را گرفته باشید!این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.منابعHadoop EcosystemApache Hadoop HDFS architectureHow to set up Hadoop cluster with HDFS high availabilityHadoop YARN tutorialDifferent types of failures in HadoopHBase tutorialHBase tutorialHBase architectureHBase pros and consSpark tutorialSpark architectureSpark architecture in depthApache Spark limitationsWatermarking in Spark structured streamingApache Storm the Hadoop of real timeApache Storm architectureEverything you need to know about Apache StormBig data tutorial Apache StormIntroduction to Apache FlinkExactly once is not exactly the sameApache Flink use casesApache Flink architectureApache Flink applicationsApache Flink operationsApache Flink blogApache DrillApache Drill architectureApache Drill introductionApache Drill in 10 minutesApache Hive tutorialApache Hive designApache Hive features and limitationsApache Pig tutorialApache PigApache Pig architecture in HadoopApache Pig advantages and disadvantagesApache Impala overviewApache Impala articleApache Impala introductionPros and cons of Apache ImpalaApache Flume ConfigurationApache Flume ChannelsApache Flume data flowApache Flume architectureTutorials point Apache Flume architectureApache Flume features limitationsIntroduction to Oozie architecture and operation modelApache Oozie tutorialOozie architecture and job scheduling