نوشته های امیرحسین شریف نژاد

مقیاس پذیری دیتابیس: راه های افزایش سرعت و ظرفیت دیتابیس

امیرحسین شریف نژاد — Mon, 14 Jul 2025 18:14:06 +0330

Scaling دیتابیس: رازهای افزایش سرعت و ظرفیت سیستم‌های داده‌ایدر این مقاله میخوام که با یکی دیگر از قضیه ها و مفاهیمی که در طراحی سیستم (System Design) مفید هست بدانیم، صحبت کنم و اون هم مقیاس پذیری یا همون Scaling در دیتابیس ها هست. در ابتدایی که پروژه شما به تعداد یوزر بالایی نرسیده باشه شاید مقیاس پذیری یا اعمال بعضی از استراتژی ها در سرور های دیتابیستون شاید انچنان اولویتی نداشته باشه ولی وقتی که تعداد یوزر ها و درخواست ها بالا میرود و سرعت پاسخ دهی سرور دیتابیس پایین می آید برسی و اعمال استراتژی موثر و ساختارمند اونوقت هست که اولویت پیدا میکند.البته این موضوع رو توجه داشته باشید که ما قراره دیتابیس‌مون رو کم‌کم و مرحله‌ای مقیاس کنیم. یعنی اگه الان فقط ۱۰ هزار کاربر داریم، اینکه بیایم از الان دیتابیس رو برای ۱۰ میلیون کاربر آماده کنیم، فقط وقت و انرژی هدر دادن و اسمش میشه زیاده‌روی توی مهندسی (Over-Engineering). ما فقط تا حدی دیتابیس رو بزرگ می‌کنیم که نیاز کسب‌وکارمون رو جواب بده و لازم نباشه بیخودی هزینه و زمان بذاریم.SQL یا NoSQL؟ کدام بهتر هستند؟کلیه دیتابیس ها به دو نوع کلی تقسیم می شوند که در ادامه بهشون میپردازیم:SQLSQL دیتابیس‌های ساختاریافته مثل MySQL و PostgreSQL هستند که از جداول با اسکیمای ثابت و زبان SQL برای مدیریت داده‌ها استفاده می‌کنند و قوانین ACID را به‌خوبی رعایت می‌کنند.SQL مناسب پروژه‌هایی هست که ساختار داده ای مشخصی دارد و روابط پیچیده بین داده ای دارد و برای مقیاس پذیری بهتر است از روش افزایش منابع استفاده کرددیتابیس های زیر از نوع SQL هستند:MySQLPostgreSQLOracleSQL ServerSQLiteNoSQLNoSQL دیتابیس‌هایی مثل MongoDB و Cassandra هستند که ساختار منعطف‌تر و بدون اسکیمای ثابت دارند و برای مدیریت داده‌های بزرگ و غیرساختاریافته با مقیاس‌پذیری بالا استفاده می‌شوند. معمولاً محدودیت‌های کمتری در ذخیره و بازیابی سریع داده‌ها دارند و مدل Eventual Consistency به جای ACID در بسیاری از آن‌ها استفاده می‌شود. برای مقیاس پذیری در این نوع دیتابیس بهتر هست از روش مقیاس پذیری افقی (Horizontally Scale) استفاده کرد.دیتابیس های زیر از نوع NoSQL هستند:MongoDBCassandraروش های مقایس پذیری (Scaling)ایندکسینگ (Indexing)ایندکسینگ (Indexing) در دیتابیس یعنی ساخت یک ساختار داده کمکی (مثل یک کتابخانه با فهرست الفبایی) روی یک یا چند ستون جدول، تا هنگام اجرای کوئری‌ها، دیتابیس بتواند داده‌های موردنظر را سریع پیدا کند، بدون اینکه مجبور باشد کل جدول را خط به خط اسکن کند. این ایندکس‌ها معمولاً با استفاده از ساختارهایی مثل B-Tree یا Hash Table ساخته می‌شوند.زمانی که شما روی یک ستون ایندکس ایجاد می‌کنیددیتابیس یک ساختار داده (مثلاً B-Tree) می‌سازد و مقادیر ستون + یک اشاره به ردیف آن داده را در این ساختار قرار می‌دهد.وقتی کوئری اجرا می‌شود، دیتابیس به‌جای اسکن کل جدول، از این ساختار برای پیدا کردن سریع مقدار استفاده می‌کند.این ایندکس‌ها به‌روزرسانی می‌شوند هر زمان که داده جدید اضافه یا تغییر داده شود تا هماهنگ با جدول اصلی باقی بمانند.چه زمانی از ایندکس استفاده کنیم؟زمانی که داده‌های زیادی دارید و مرتباً روی ستون خاصی جستجو انجام می‌دهید.برای ستون‌هایی که در WHERE، ORDER BY، GROUP BY یا JOIN استفاده می‌شوند.برای بهبود سرعت گزارش‌گیری روی جداول حجیم.مزایای ایندکسینگسرعت جستجوی بالا: کوئری‌ها روی ستون‌های ایندکس شده بسیار سریع‌تر اجرا می‌شوند.بهبود سرعت عملیات JOIN: به‌ویژه وقتی ستون‌های مشترک بین جداول ایندکس شده باشند.بهبود سرعت ORDER BY و GROUP BY: مرتب‌سازی داده‌ها روی ستون‌های ایندکس شده سریع‌تر انجام می‌شود.کاهش مصرف CPU برای خواندن داده‌های زیاد: زیرا بجای اسکن کل داده، مستقیم به رکورد می‌رسد.معایب ایندکسینگافزایش مصرف فضای ذخیره‌سازی: ایندکس‌ها فضای اضافه روی دیسک مصرف می‌کنند.کند شدن عملیات INSERT و UPDATE: چون هر بار داده جدیدی اضافه یا ویرایش می‌شود، ایندکس هم باید به‌روزرسانی شود و این می‌تواند کمی سرعت نوشتن را کاهش دهد.نیاز به مدیریت: ایندکس‌های اضافی اگر بدون نیاز ساخته شوند، باعث کندی سیستم می‌شوند.پارتیشن بندی (Partitioning)Partitioning (پارتیشن‌بندی) یعنی تقسیم یک جدول بزرگ به چند بخش کوچکتر (Partition) با این هدف که مدیریت، نگهداری و کوئری گرفتن از داده‌های بزرگ ساده‌تر و سریع‌تر انجام شود. هر پارتیشن مانند یک جدول جداگانه عمل می‌کند اما از دید کاربر و کوئری، همچنان به عنوان یک جدول یکپارچه نمایش داده می‌شود.وقتی شما جدول را پارتیشن‌بندی می‌کنیدجدول براساس یک ستون (مانند تاریخ، ID یا محدوده مقادیر) به چند قسمت تقسیم می‌شود.دیتابیس هنگام اجرای کوئری، فقط به پارتیشن مربوطه دسترسی پیدا می‌کند و نیازی به اسکن کل داده‌ها ندارد (این ویژگی را Partition Pruning می‌نامند).پارتیشن‌ها می‌توانند در فایل‌های جداگانه ذخیره شوند و مدیریت آرشیو داده یا حذف داده‌های قدیمی در آن‌ها راحت‌تر است.چه زمانی مناسب است از روش Partitioning استفاده کنیم؟اگر اغلب کوئری‌های شما روی محدوده خاصی از داده‌ها اجرا می‌شوند (مثلاً داده‌های یک ماه یا یک سال خاص).اگر نیاز به آرشیو یا حذف داده‌های قدیمی به‌صورت دوره‌ای دارید.اگر عملیات نگهداری مانند ایندکس‌سازی مجدد، بکاپ‌گیری یا ریست کردن داده‌ها طولانی است.من این مورد در یک پروژه شخصی امتحان کردم، همان طور که در بالا هم گفتم این روش از مقیاس پذیری دیتابیس به نظر من فقط برای زمانی مناسب هست که بشه داده هارو بر اساس یک منطقه یا زمانی جدا کرد ولی اگر بر اساس غیر از آن جدا کنید مثل بر اساس id داده ها تاثیر انچنانی بر سرعت دیتابیس شما نمی گذارد.انواع PartitioningRange Partitioning: داده‌ها براساس بازه‌ها تقسیم می‌شوند (مثلاً تاریخ‌ها)List Partitioning: داده‌ها براساس یک لیست از مقادیر خاص تقسیم می‌شوندHash Partitioning: داده‌ها براساس یک تابع هش به چند پارتیشن تقسیم می‌شوند (برای توزیع یکنواخت داده)Composite Partitioning: ترکیبی از روش‌های بالا برای کنترل دقیق‌تر داده‌هامزایای Partitioningافزایش سرعت کوئری‌ها: به‌ویژه برای داده‌های بزرگ، زیرا فقط بخشی از داده‌ها اسکن می‌شود.مدیریت آسان داده‌های قدیمی: می‌توانید یک پارتیشن قدیمی را سریع حذف یا آرشیو کنید بدون تأثیر روی بقیه داده‌ها.بهبود عملکرد در مدیریت داده‌های بزرگ: جدول‌های خیلی بزرگ به قسمت‌های کوچک و قابل مدیریت تقسیم می‌شوند.بهینه‌سازی نگهداری: بازسازی ایندکس‌ها یا عملیات Vacuum (در PostgreSQL) سریع‌تر انجام می‌شود چون روی یک پارتیشن اجرا می‌شوند.پشتیبانی از Parallel Processing: برخی دیتابیس‌ها عملیات موازی روی پارتیشن‌ها انجام می‌دهند.معایب Partitioningپیچیدگی در طراحی: طراحی پارتیشن‌بندی نیاز به شناخت دقیق داده‌ها و الگوهای دسترسی دارد.مدیریت بیشتر: نیاز به مدیریت و مانیتورینگ دقیق تعداد و وضعیت پارتیشن‌ها دارد.محدودیت‌های دیتابیس: همه دیتابیس‌ها به یک اندازه از پارتیشن‌بندی پشتیبانی نمی‌کنند یا محدودیت‌هایی دارند.افزایش سربار در کوئری‌های اشتباه: اگر پارتیشن Pruning به‌درستی انجام نشود، کل پارتیشن‌ها اسکن می‌شوند.معماری Master-Slaveیکی دیگر از روش های اسکیلینگ دیتابیس استفاده از روش Master-Slave هست، این معماری تشکیل شده از چند سرور که یکی از آن سرور ها به عنوان Master باید باشه و وظیفه این را دارد که فقط درخواست های INSERT،UPDATE و DELETE را انجام دهد و یک یا چند سرور به عنوان Slave هستند که ضمن این که فقط به درخواست های Read پاسخ میدهند، خودشون رو با سرور Master جهت آپدیت داده ها از طریق Binary Log سینک میکنند.مزایای Master-Slave Architectureافزایش مقیاس‌پذیری خواندن: می‌توانید چندین Slave اضافه کنید و خواندن از دیتابیس را بین آن‌ها توزیع کنید.بهبود عملکرد: Master فقط روی نوشتن متمرکز است و بار خواندن کاهش می‌یابد.افزونگی و در دسترس بودن بالا: اگر Master از دسترس خارج شود، می‌توانید یکی از Slaveها را به Master ارتقا دهید.پشتیبان‌گیری آسان: می‌توانید از Slaveها برای گرفتن Backup بدون تأثیر روی عملکرد Master استفاده کنید.مناسب برای Report و Analytics: چون Slave فشار زیادی روی Master وارد نمی‌کند.معایب Master-Slave Architectureاحتمال تأخیر در Replication: بین Master و Slave ممکن است کمی تأخیر وجود داشته باشد (Replication Lag)، که می‌تواند داده‌های خوانده شده از Slave بروز نباشد.نقطه شکست تکی (Single Point of Failure): اگر Master از دسترس خارج شود و Failover تنظیم نشده باشد، نوشتن متوقف می‌شود.پیچیدگی مدیریت: نیاز به مانیتورینگ، تنظیم Failover و نگهداری دقیق دارد.خواندن داده قدیمی: ممکن است داده‌ای در Master نوشته شود اما هنوز به Slave منتقل نشده باشد و داده قدیمی به کاربر نمایش داده شود.چه زمانی از معماری Master-Slave استفاده کنیم؟در صورتی که دو روش قبلی یعنی Indexing و Partitioning دیگر جواب نمی دهدزمانی که تعداد درخواست‌های خواندن بالا هست و نیاز به توزیع بار داریددر زمانی که کاربران مختلف و زیاد در نقاط مختلف جغرافیایی دارید و میخواید با ایجاد یک سرور Slave در نقاط مختلف جغرافیایی سرعت خواندن از دیتابیستون رو بیشتر کندبرای گرفتن بکاپ بدون تأثیر روی عملکرد سیستم اصلیزمانی که نیاز به افزونگی و Disaster Recovery داریدMaster-Slave در چه دیتابیس‌هایی پشتیبانی می‌شود؟MySQLPostgreSQL (با Streaming Replication)MongoDB (در قالب Primary-Secondary)RedisCassandra (در قالب Masterless Architecture با Replication)معماری Multi-masterاین نوع معماری مانند معماری Master-Slave می باشد با این تفاوت که به جای یک سرور Master چند سرور Master داریم که هر سرور مستر هم زمان قابلیت این رو دارند که هم عملیات های INSERT،UPDATE و DELETE را انجام بدند و هم عملیات Read. این نوع معماری برای دیتابیس هایی مناسب هستند که کاربران در نقاط مختلف قرار دارند و میخواهند بر اساس منطقه جغرافیایی درخواست هارو پاسخ دهند.تقسیمبندی دیتابیس (Database Sharding)تقسیمبندی دیتابیس (Database Sharding) اگر بخوام به صورت ساده توضیح بدم به این مفهموم اشاره دارد که به جای داشتن یک دیتابیس بزرگ، چندین دیتابیس کوچک ایجاد میکنیم که هرکدام بخشی از داده را نگهدارند و باهم یک دیتابیس واحد را بسازند. حالا نحوه کار این نوع از روش مقیاس پذیری به ان صورت هست که داده ها بر اساس یک Shard Key (مثل user_id، customer_id یا country) تقسیم می شوند و هر Shard میتواند روی یک سرور جداگانه قرار بگیرد و درفرایند، اپلیکیشن تصمیمگیری میکند که برای گرفتن اطلاعات یا اپدیت داده ای به کدام Shard درخواست بزند.روش‌های Database Sharding برای مقیاس‌پذیری دیتابیسبر اساس محدوده (Range-based Sharding)داده‌ها بر اساس محدوده (Range) تقسیم می‌شوند.مزیت: ساده و قابل درک.عیب: ممکن است منجر به Hotspot روی یک Shard شود اگر داده‌های جدید فقط در یک Range باشند.بر اساس هش (Hash-based Sharding)از هش (Hash) روی Shard Key برای توزیع یکنواخت داده استفاده می‌شود.مزیت: توزیع یکنواخت داده‌ها و جلوگیری از Hotspot.عیب: افزودن Shard جدید دشوار است چون نیاز به Rehash و انتقال داده‌ها دارد.مبتنی بر دایرکتوری (Directory-based Sharding)از یک Shard Map Directory استفاده می‌شود که معلوم میکند هر داده در کدام Shard است.مزیت: انعطاف‌پذیری بالا و امکان تغییر Shard بدون تغییر Shard Key.عیب: اضافه شدن یک نقطه Failure (Directory) و پیچیدگی مدیریت.مزایای Database Shardingکاهش فشار بر سرورها: هر Shard فقط بخشی از داده‌ها را مدیریت می‌کند.افزایش سرعت Queryها: چون داده‌ها کمتر هستند، ایندکس‌ها کوچک‌تر و Query سریع‌تر اجرا می‌شود.افزایش Availability: اگر یک Shard از دسترس خارج شود، Shardهای دیگر همچنان فعال می‌مانند.معایب Database Shardingپیچیدگی مدیریت: نگهداری بکاپ، مانیتورینگ، مانیتور Queryها و Migration داده بین Shardها دشوارتر استQueryهای Cross-Shard سخت و کند هستند: اگر نیاز به Join بین Shardها باشد، Query پیچیده می‌شودتعیین Shard Key اشتباه می‌تواند باعث عدم تعادل شود: اگر Shard Key به درستی انتخاب نشود، یک Shard ممکن است خیلی سنگین و دیگری سبک بماند (Hotspot)پیاده‌سازی نیازمند تغییر در لایه اپلیکیشن است: اپلیکیشن باید باید تعین کند هر درخواست به کدام Shard ارسال شودچه زمانی بهتر هست از Sharding استفاده کنیم؟حجم داده و درخواست‌ها به حدی زیاد شده که دیگر ایندکسینگ و پارتیشن‌بندی روی یک سرور جوابگو نیست و Scale عمودی (Vertical Scaling) دردی را دوا نمی کنداپلیکیشن شما دارای الگوی دسترسی به داده قابل تقسیم است (مثلاً کاربران فقط داده خود را می‌خواهند).چه دیتابیس هایی از روش Database Sharding پشتیبانی می کنند؟MongoDBCassandraElasticsearchVitess (برای MySQL)CockroachDBAmazon DynamoDBHBaseRedisCouchbaseYugabyteDBممنون که تا این لحظه همراه من بودید. اگر سوال، انتقاد و یا پیشنهادی داشتید خوشحال میشم در بخش کامنت های این مطلب با من درمیون بزارید.

آشنایی با تئوریCAP در طراحی سیستم: از ویژگی ها تا محدودیت ها

امیرحسین شریف نژاد — Tue, 24 Jun 2025 19:57:10 +0330

در این مقاله میخوام که با یکی دیگر از قضیه ها و مفاهیمی که در طراحی سیستم (System Design) مفید هست بدانیم، صحبت کنیم و اون هم تئوریCAP هست. تئوریCAP برای سیستم توزیع‌شده (Distributed System) کاربرد داره که با استفاده از مفهوم مقیاس پذیری افقی (Horizontal Scaling) که در مقاله مقیاس پذیری (Scaling) در مورد این نوع ها از Scaleup صحبت کردیم، ایجاد میشه.سیستم توزیع‌شده (Distributed System) یعنی مجموعه‌ای از چند کامپیوتر (Node یا Server) که از طریق شبکه به هم وصل شدن و با هم مثل یک سیستم واحد کار می‌کنن.تئوری CAP چیست؟تئوری CAP از به سه بخش تقسیم میشه که عبارتند از:یکپارچگی داده (Consistency)یکپارچگی داده (Consistency) یعنی تمام داده ها در تمام نود ها یکسان و یکپارچه شود. فرض کنید که یک نرم افزار بانکی دارید که بر روی 3 نود اورده شده بالا و کاربران در زمان ارسال درخواست به وسیله لود بالنسر به یکی از نود ها منتقل می شوند، اگر کاربر در هنگام پرداخت به یک نود منتقل شود و فاکتوری را پرداخت کند و جهت مشاهده وضعیت فاکتور به یک نود دیگر منتقل شود که تراکنش پرداخت کاربر در اون نباشد، باعث می شود با عدم یکپارچگی داده روبرو شوید. اینجاست که Consistency کاربرد دارد و باید در هرلحظه داده ها بین نود ها سینک شوند.دردسترسی بودن (Availability)Availability یعنی در دسترسی بودن سرویس، فرض کنید که 3 نود دارید که کاربران با توجه به ترافیک روی هر کدام از نود ها بین آن ها جابه جا می شوند، حالا در فرایند یکی از نود ها مشکلی پیش امده که دیگه نمیتونه جواب گو باشه و در دسترس نیست، در این حالت اگر سیاست شما این باشد که در این جور موقعیت ها کاربر از خرابی سیستم اطلاع پیدا نکند Availability کاربرد پیدا میکند و اون نود مشکل دار به صورت خودکار و یا دستی باید از خط خارج شود و کاربران به نود های استیبل منتقل شوند.تاب‌آوری در برابر قطعی شبکه (Partition tolerance)تاب‌آوری در برابر قطعی شبکه (Partition tolerance) یعنی وقتی بخشی از شبکه قطع شد (مثل وقتی که چند سرور با هم ارتباط ندارن)، سیستم همچنان به کار خودش ادامه بده و از کار نیفته.ارتباط بین ویژگی‌های CAPارتباط بین ویژگی‌های CAPویژگی هایی که در ادامه میگم بسته به سیاست ها و نوع پروژه بایستی انتخاب کرد و این هم درنظر داشته باشید که هیچ وقت سه ویژگی CAP یعنی هم یکپارچگی (Consistency) و هم تحمل قطعی شبکه (Partition tolerance) و هم Availability، را نمی شود اعمال و رعایت کرد.یکپارچگی + تحمل قطعی شبکه (CP)ممکن هست که سیاستتون این باشه که داده ها بین نود ها سینک بشند و همواره یکسان باشند و در صورتی که شبکه مشکلی داشت سیستم به روال عادیش ادامه بده ولی یک بدی که این نوع ویژگی داره کندی سیستم و منتظر ماندن درخواست کاربر هست. چون که سیستم تا زمانی که نود ها خودشون رو آپدیت و سینک نکنند کاربران باید منتظر در دسترس بودن سیستم باشند.نرم افزار ها و پروژه هایی که در آن می شود این ویژگی درنظر گرفت و استفاده کرد عبارتند از:MongoDB (با تنظیم مناسب)HBaseZookeeperEtcdبانک‌ها (برای جلوگیری از دوبار برداشت پول)اپلیکیشن‌هایی که دقت داده خیلی مهمه (مالی، حسابداری، رای‌گیری)دسترس‌پذیری + تحمل قطعی شبکه (AP)ممکن هست که سیاستتون این باشه که نود ها آپدیت نشند ولی همواره در دسترس باشند و کاربر متوجه قطعی یکی از نود ها نشه. ولی یک بدی که این نوع ویژگی داره داده ها بین نود ها سینک و اپدیت نمی شود.نرم افزار ها و پروژه هایی که در آن می شود این ویژگی درنظر گرفت و استفاده کرد عبارتند از:CassandraCouchbaseDynamoDBRedis (با replication)سیستم‌های پربازدید که delay مهم‌تر از دقت لحظه‌ایهاپ‌هایی مثل پیام‌رسان‌ها، شبکه‌های اجتماعی، فروشگاه‌های آنلاین با caching بالایکپارچگی + دسترس‌پذیری (CA)ممکن هست که سیاستتون این باشه که سیستم همواره در دسترس باشد و داده ها بین نود ها باهم سینک شوند. ولی بدی این ویژگی این هست که هیچ وقت نمیشه تضمین داد که مشکل شبکه ای یک سیستم نداره، بنابراین Partition Tolerance در عمل اجتناب‌ناپذیر است.نرم افزار ها و پروژه هایی که در آن می شود این ویژگی درنظر گرفت و استفاده کرد عبارتند از:ساده‌ترین دیتابیس‌های تک‌سرور مثل PostgreSQL یا MySQL در حالت بدون replicationسیستم‌های داخل یک ماشین یا LAN بدون ریسک قطع ارتباطپروژه‌های ساده، MVPها، اپ‌های تک‌سرور، اپلیکیشن‌های داخلی شرکتمحدودیت‌های CAP Theoremهرچند قضیه CAP یک مفهوم بنیادی در طراحی سیستم‌های توزیع‌شده است، اما در عمل محدودیت‌هایی هم دارد که نمیشه ازشون گذشت و بهتر که درنظر گرفت:ساده‌سازی بیش از حد:CAP فقط سه ویژگی کلی را بررسی می‌کند و بسیاری از فاکتورهای مهم مانند تأخیر شبکه، هزینه ارتباط بین نودها، تحمل خطا و مسائل امنیتی را در نظر نمی‌گیرد.مدل باینری:این قضیه ویژگی‌ها را به صورت مطلق (همه یا هیچ) فرض می‌کند، در حالی که در واقعیت، اکثر سیستم‌ها ترکیبی از درجات مختلف Consistency و Availability را ارائه می‌دهند.تمرکز بر پارتیشن:CAP فقط شرایطی را پوشش می‌دهد که Partition اتفاق بیفتد، در حالی که در عمل، بسیاری از مشکلات شبکه‌ای کوتاه‌مدت هستند و نیاز به استراتژی‌های انعطاف‌پذیرتری دارند.نادیده گرفتن مفاهیم جدید:امروزه بسیاری از سیستم‌های مدرن از مدل‌های Consistency ضعیف‌تر (مثل Eventual Consistency) یا تکنیک‌های پیشرفته‌ای مثل Consensus Algorithms برای حل مشکلات CAP استفاده می‌کنند.به طور کلی، CAP یک چارچوب ذهنی ساده و مفید برای شروع طراحی سیستم‌های توزیع‌شده است، اما نباید تنها مبنای تصمیم‌گیری معماری باشد. باید سایر فاکتورهای عملیاتی و نیازهای خاص پروژه را هم در نظر گرفت.ممنون که تا این لحظه همراه من بودید. اگر سوال، انتقاد و یا پیشنهادی داشتید خوشحال میشم در بخش کامنت های این مطلب با من درمیون بزارید.

درک Scaling در طراحی سیستم: بهترین روش‌ها برای مقیاس‌پذیری هوشمند

امیرحسین شریف نژاد — Mon, 23 Jun 2025 16:09:18 +0330

در مقاله تعریف و اصول طراحی سیستم در مورد طراحی سیستم توضیح دادم و این که چرا باید در مورد طراحی سیستم مطالعه داشته باشیم صحبت کردم در این مقاله میخوام از یکی از مفاهیم دیگر این نوع طراحی یعنی Scaling (مقیاس پذیری) صحبت کنم.فرض کنید برای یک مناسبت میخواید برای سایت خودتون تبلیغات انجام بدید. بعد از شروع تبلیغات در سایت ها و اپ های مختلف تعداد کاربران زیادی میخوان به سایت شما مراجعه کنند و لندینگ شمارو ملاحضه کنند که این باعث افزایش ترافیک در سمت سرور شما میشه و باعث میشه که سرور به خاطر افزایش ترافیک down بشه و کاربران به مشکل بخورند.اینجاست که مفهوم Scaling (مقیاس پذیری) وسط میاد.انواع Scaling(مقیاس پذیری)مقیاس پذیری عمودی (Vertical Scaling)مقیاس پذیری عمودی (Vertical Scaling)خب برای این که افزایش ترافیک در سمت سرور خوتون مدیریت کنید ممکن هست که اولین راهکاری که به ذهن بیاد افزایش منابع سرور (Ram, CPU, Storage) هست که به این کار میگن مقیاس پذیری عمودی (Vertical Scaling). این نوع از مقیاس پذیری یکی از آسان ترین و سریع ترین کارهاست که میتوان برای این چالش انجام داد. این نوع از Scaling بیشتر در سرور های دیتابیسی و اپلیکیشن های stateful کاربرد داره و بهتر که استفاده بشه.منظور از اپلیکشن های stateful مانند اپلیکیشن های زیر می باشد:اپلیکیشن های session-based مانند WHMCS که برای لاگین کاربر به سشن نیاز دارهاپلیکیشن های چت و وب سوکت به این دلیل که هر connection به یک client وصل است. پیام‌ها باید به همان connection برگردد. اگر connection قطع شود یا سرور عوض شود، پیام‌ها از بین می‌روند یا دیر می‌رسند.اپلیکیشن های بانکی و تراکنش های مالی، به این دلیل که هر تراکنش باید atomic باشد و وضعیت آن دقیق نگهداری شود (rollback, commit). پخش شدن تراکنش بین چند سرور consistency را سخت می‌کند.مقیاس پذیری افقی (Horizontal Scaling)مقیاس پذیری افقی (Horizontal Scaling)در بعضی از سرور های و اپلیکیشن ها دیگر افزایش منابع کاربردی نداره و نمیتوان به صورت بینهایت منابع اون سرور به تنهایی زیاد کرد چون که علاوه بر این که هزینه افزایش منابع برای سازمان و شرکت زیاد می شود، هزینه نگهداری و پشتیبانی از اون هم زیاد و دشوار می شود. در این جا دیگه روش قبلی کاربردی نداره و بهتر که به جای افزایش منابع فقط برای یک سرور، پروژه های خورد را بر روی سرور های مختلفی بالا بیاریم و به وسیله load balancer ترافیک بین سرور های مختلف مدیریت کنیم که به این روش مقیاس پذیری افقی (Horizontal Scaling) می گویند.Vertical Scaling یا Horizontal Scaling؛ کدوم روش بهتر است؟بسته به نیاز و هزینه و پروژه باید ببینید کدوم براتون بهتر هست اگر تعداد کاربران زیادی ندارید میتونید روش Vertical Scaling استفاده کنید ولی اگر میبینید که تعداد کاربران زیادی دارید و با افزایش منابع بازهم با ترافیک بالا جواب گو نیست بهتر که از روش Horizontal Scaling استفاده کنیم.مقیاس پذیری خودکار (Auto Scaling)ممکن هست که سرور شما در بعضی از زمان ها و روز ها تعداد کاربر زیادی داشته باشد و در زمان های دیگر ان چنان ترافیک بالایی به سمت سرور نیاد، خب اگر که پیشفرض چند سرور آماده سازی کرده باشیم و به وسیله لود بالانسینگ ترافیک بین اون ها مدیریت کنیم خب در زمان هایی که تعداد کاربران انقدر بالا نیست که میتواند یک سرور هم جواب گوی درخواست های کاربران باشد نیاز نیست هزینه اضافی برای نگهداری سرور های دیگر بدیم، اینجاست که باید ساختار طوری بچنیم که در صورتی که ترافیک در سمت سرور زیاد شد سیستم load balancer باید سرور دیگیری بسته به ترافیک به مدار اضافه کنه. این کار هم میتوان با ابزارهایی مثل Kubernetes انجام داد.ممنون که تا این لحظه همراه من بودید. اگر سوال، انتقاد و یا پیشنهادی داشتید خوشحال میشم در بخش کامنت های این مطلب با من درمیون بزارید.

اصول پایه در طراحی سیستم: از چالش ها و راه حل ها

امیرحسین شریف نژاد — Sat, 21 Jun 2025 17:40:34 +0330

جدیدا یک مقاله ای دارم میخونم که خیلی کامل داره در مورد اصول طراحی سیستم صحبت میکنه، چون که جای خالی همچین مقاله ی مفصل و عالی در وب فارسی کم دیدم تصمیم گرفتم این مقاله به فارسی ترجمه کنم و در اختیار عموم بزارم.کاربر طراحی سیستم چیست؟ چرا اصلا باید در مورد طراحی سیستم مطالعه کنیم؟در پروژه های کوچک و شخصی شما ممکن هست که بدون درنظر گرفتن کاربرد هر زبان برنامه نویسی، منابع و تعداد یوزر ها، پروژتون بنویسید و در اختیار عموم قرار بدید.مثلا پروژتون ممکن که نرم افزار داخلی یک سازمان باشه که فقط برای افراد اون سازمان هست و تعداد یوزر های انقدر بالایی نداره و یا پروژه دانشگاهی باشه که فقط بدرد ارائه میخوره و بس.یا ممکن که پروژه ای باشه که در ختیار عموم قرار گرفته و کاربران فقط با ارسال درخواست هایی، برنامه با انجام یکسری محاسبات و کارب های غیر پیچیده ای پاسخ مناسبی به کاربر برمیگردونه.ولی بیان به این فکر کنید که یک پروژه دارید که هزاران و یا میلیون ها کاربر داره و فرایندهای پیچیده ای داره که اگر ساختار برنامه به خوبی روش فکر نشده باشه اون استارتاپ و یا سازمانی ممکن که شکست بخوره، ایجاست که مفاهیمی مثل امنیت، مانیتورینگ، سیستمی برای هندل کردن خطاها و مقیاس پذیری (scaling) باید بدونیم تا در چالش های مختلف بشه سریعا از راه حلی برای مشکل پیش امده پیدا کرد.Latency چیست و چرا اهمیت دارد؟در زمانی که کاربر به شما درخواستی ارسال میکنه به مدت زمانی که درخواست به سرور شما میرسه و پاسخ آن را دریافت میکنه میگن Latency یا میزان تاخیر، این مفهوم در طراحی سیستمها، شبکهها و برنامههای کاربردی (مثل بازیهای آنلاین یا تراکنشهای بانکی) نقش حیاتی دارد.واحد اندازه گیری Latency میلی ثانیه هست و هر چه میزان آن کم تر باشد تجربه کاربری بهتری خواهید داشت.Throughput (توان عملیاتی) چیست و چه کاربرد هایی دارد؟در هر سیستم ما نیاز داریم بفهمیم که در حالاحاضر نرم افزار و اپلیکیشنی که نوشتیم و بر روی پروداکشن منتشر کردیم در هر ثانیه چقدر داده میتونه پردازش بکنه به این موضوع میگن Throughput یا توان عملیاتی یک سیستم که بر حسب ثانیه اندازه گیری میکنند.مفهوم Throughput کاربرد های مختلفی داره مثلا در شبکه تعین کننده میزان پهنای باند، در پایگاه داده ها به میزان تعداد تراکنش های پردازش شده در هر ثانیه هست و یا در سرور به میزان کاربرانی که میتوانند درخواست ارسال کنند بدون این که در عملکرد سیستم خللی ایجاد شود.حالا Latency و Throughput باهم چه رابطه ای دارند؟معمولاً افزایش Throughput (مثلاً با اضافه کردن منابع) می‌تواند Latency را کاهش دهد. مثلا اضافه کردن خطوط پردازش در یک کارخانه باعث می‌شود هم محصولات بیشتری تولید شوند (Throughput بالا) و هم هر محصول سریع‌تر آماده شود (Latency پایین)وقتی سیستم به حداکثر ظرفیت خود نزدیک می‌شود، افزایش بیشتر Throughput ممکن است Latency را به شدت افزایش دهد، مثلا وقتی که روی یک سرور ترافیک خیلی زیادی میاد و باعث مشکل خورد اون سرور میشه.مقیاس پذیری (Scaling) چیست؟مقیاس‌پذیری به توانایی یک سیستم برای مدیریت افزایش بار کاری یا حجم کاربران بدون افت کارایی گفته می‌شود. این مفهوم یکی از اصول کلیدی در طراحی سیستم‌های مدرن است که به کسب‌وکارها کمک می‌کند با رشد کاربران یا داده‌ها، عملکرد پایدار و قابل اعتماد ارائه دهند. برای آشنایی کامل با انواع مقیاس‌پذیری و روش‌های Auto Scaling، پیشنهاد می‌کنم مقاله کامل مقیاس‌پذیری (Scaling) در طراحی سیستم را مطالعه کنید.تئوری CAPتئوریCAP یکی از اصول پایه‌ای طراحی سیستم‌های توزیع‌شده است که توضیح می‌دهد چرا در شرایط قطعی شبکه، نمی‌توان به‌طور هم‌زمان هم یکپارچگی داده، هم دسترس‌پذیری و هم تحمل قطعی را به‌طور کامل تضمین کرد. این مفهوم به مهندسان کمک می‌کند بفهمند کدام ویژگی‌ها در اولویت طراحی سیستم باید باشند. برای آشنایی دقیق‌تر با مفاهیم CAP و انواع آن (CP، AP، CA) و کاربرد هرکدام، پیشنهاد می‌کنم مقاله کامل من در این زمینه را مطالعه کنید. اینجا بخوانید: آشنایی با تئوریCAP در طراحی سیستمتفاوت مونولیت و میکروسرویس در طراحی سیستممونولیت (Monolith) به ساختار یکپارچه‌ای در طراحی سیستم گفته می‌شود که تمام بخش‌های برنامه (مثل احراز هویت، پرداخت، مدیریت کاربران) در یک کدبیس و سرویس اجرا می‌شوند، در حالی که میکروسرویس (Microservice) معماری مدرن‌تری است که هر بخش سیستم به صورت سرویس‌های مستقل و کوچک با دیتابیس و منطق جدا توسعه و دیپلوی می‌شود. این موضوع باعث می‌شود هر سرویس به‌روزرسانی و مقیاس‌پذیری جداگانه داشته باشد و مدیریت پروژه‌های بزرگ ساده‌تر شود. اگر می‌خواهی تفاوت‌ها و مزایا و معایب این دو معماری را به‌طور کامل و کاربردی یاد بگیری، مقاله تفاوت مونولیت و میکروسرویس در طراحی سیستم را حتما بخوانید.مقیاس پذیری دیتابیس (Scaling of Database)مقیاس‌پذیری دیتابیس یعنی توانایی افزایش ظرفیت و سرعت دیتابیس برای پاسخگویی به حجم بالای داده و کاربران بدون کاهش عملکرد. روش‌هایی مثل ایندکسینگ، پارتیشن‌بندی، معماری Master-Slave و شاردینگ برای مدیریت بهینه داده‌ها و حفظ کارایی استفاده می‌شوند. هر کدام از این روش‌ها مزایا و کاربردهای خاص خود را دارند و بسته به نیاز سیستم انتخاب می‌شوند. برای آشنایی کامل و کاربردی این مفاهیم، پیشنهاد می‌کنم مقاله جامع مقیاس پذیری دیتابیس (Scaling of Database) را مطالعه کنید.ممنون که تا این لحظه همراه من بودید. به خاطر این که مطالب زیاد هست به مرور این مقاله کامل میشه، اگر سوال، انتقاد و یا پیشنهادی داشتید خوشحال میشم در بخش کامنت های این مطلب با من درمیون بزارید.

آشنایی با مفهوم Driver-based و نحوه راه ندازی و توسعه آن در لاراول

امیرحسین شریف نژاد — Tue, 26 Sep 2023 21:17:43 +0330

آشنایی با مفهوم Driver-based و نحوه راه ندازی و توسعه آن در لاراولدر یکی از پروژه ها که داشتیم زیر ساخت آن را توسعه می دادیم و از چند نوع provider استفاده میکردیم نیاز به ساختار و الگوییم داشتیم که طبق چارچوب و ساختاری عمل بکند، که اگر در آینده provider های دیگر برای ارائه خدمات اضافه شدند ضمن این که از اون ساختار پیروی کند، تغییرات زیادی در آن ایجاد نشود.در جلسه ای که در مورد ساختار و معماری مناسب پروژه داشتیم بحث می کردیم، یکی از همکاران یک پیشنهاد خوب داد و اون ساختار پیشنهاد شده Driver-base در لاراول بود. این ساختار یک الگو داخلی که خود لاراول از آن استفاده میکنه، بر خلاف داکیومنت کامل و جامع لاراول این ساختار اصلا جایی بهش پرداخته نشده و با توجه به این که در وب فارسی مقاله ای در مورد مفوم Driver-base ندیدم ترجیح دادم تجربه خودم رو در مورد این ساختار بنویسم.چه موقع بهتر هست از ساختار Driver-base در لاراول استفاده کنیم؟زمانی مناسب هست که از الگو درایور (Driver) در لاراول استفاده کنیم که در پروژه مورد نظر نیاز هست که با چندین تامین کننده (Provider) ارتباط برقرار بکنید و نیاز دارید در یک یا چند فرایند بتوانید تامین کننده (Provider) مورد نظر خودتون تغییر بدید.در این ساختار، هر تامین کننده (Provider) به عنوان یک درایور ایجاد می شود و میتوانید به صورت مستقل از هر کدام از آن ها استفاده کنید.چند فسادی که خود لاراول در زیرساخت آن ها از ساختار درایوری استفاده کرده عبارتند از:Log::debug('message'); Cache::get('key'); Session::get('key');مزایا پیاده سازی ساختار درایوری (Driver-based)با استفاده از الگوی Driver-based در لاراول، شما قادر خواهید بود به سادگی درایورهای مختلف را به برنامه اضافه کنید و از تامین کننده های مختلف استفاده کنید. ساختار مورد نظر این امکان را به کد شما می‌دهد تا براحتی با تغییرات و افزودن منابع جدید سازگارباشد.با استفاده از درایورها در لاراول، شما قادر خواهید بود کد مربوط به ارتباط با تامین کننده های مختلف را جدا کنید. این امر باعث می‌شود کد شما مرتب وخواناتر باشد.با جداسازی کد و استفاده از درایورها، تست و نگهداری برنامه راحت‌تر خواهد بود. شما می‌توانید درایورهای مربوط به تامین کننده های مختلف را به صورت مستقل تست کنید و در صورت بروز خطا، مشکل مورد نظر را رفع کنید.شما می توانید هر تنظیماتی که میخواید و در درایورد مورد نظر استفاده شود در فایل کانفیگ مربوطه اضافه کنید و در وقتش از اون به راحتی استفاده کنید.در صورتی که در فرایند نیاز به تغییر منبع خارجی دارید می توانید به راحتی با تغییر درایور آن را انجام بدید معایب پیاده سازی ساختار درایوری (Driver-based)در پروژه های بزرگ در صورت اضافه شده درایور ها و تامین کننده های مختلف زیاد امکان پیچیدگی در کد ایجاد می شود. در این ساختار شما باید به ازای هر تامین کننده خارجی که استفاده می کنید یک درایور بسازید و طبق الگوی ایجاد شده پیش روید،‌که این ممکن هست هزینه زمانی زیادی در ابتدا برای شما داشته باشد.بعضی از تنظیمات لازم هست در فایل کانفیگ قرار بگیرد تا بعد ها در صورت تغییر لازم نباشد در کد تغییری ایجاد شود و با یک تغییر کوچک در فایل کانفیگ همه جا تغییر کند. اما گاهی اوقات تنظییمات آنقدر زیاد و پیچیده هست که بعد ها تغییر آن سخت می شود. برای همین باید نسبت به ست کردن تنظیمات در فایل کانفیگ دقت زیادی داشته باشد و سعی کنید آن را مدیریت کنید.نحوه پیاده سازی ساختار Driver-based در لاراولدر این بخش میخوام به وسیله یک مثال بهتون یاد بدم که ساختار درایوری در لاراول چجوری پیاده سازی کنید. فرض کنید که میخواید یک میکروسرویسی ایجاد و توسعه بدید که کارش ایجاد و استعلام گواهی ssl باشه، خب برای خرید گواهی ssl دو تامین کننده خارجی معتبر به نام های Certum و Namecheap هستند که بیشتر سایت ها از خدمات اونها استفاده میکنند، پس بنابراین این دو تامین کننده در این پروژه ۲ درایور محسوب می شوند.قدم اول: ایجاد فایل کانفیگخب در ساختار درایوری لارول لیست درایور ها، تنظیمات هر کدام از آن ها و درایور پیش فرض در فایلی در دایرکتوری کانفیگ ایجاد و اضافه می شود.پس در ابتدا نیاز داریم که یک فایل کانفیگ ایجاد کنیم که در آن درایور پیش فرض و تنظیمات هر کدارم از تامین کننده ها را در آن معلوم باشد.// configs/ssl.php return [ 'default' => env('SSL_DRIVER', 'certum'), 'drivers' => [ 'certum' => [ 'username' => '', 'password' => '', ], 'namecheap' => [ 'username' => '', 'password' => ''. ] ] ]قدم دوم : ایجاد سرویس برای مدیریت درایورهابعد از ایجاد فایل کانفیگ نیاز هست که بستری ایجاد کنیم که بتونه درایور های ایجاد شده را مدیریت کنه، که لاراول برای آسان تر شدن این کار امکان استفاده از کلاسی به نام'Illuminate\Support\Manager داده که با استفاده از آن میتونیم به راحتی درایور های ایجاده شده را به راحتی تغییر و استفاده کنیم.برای ایجاد زیرساخت، در دایرکتوری App یک دایرکتوری به نام 'Services' ایجاد و کلاسی با نام SSLManager می سازیم.config->get('ssl.default'); } }خب، با ایجاد کلاس مورد نظر درایور پیش فرض ما برای ایجاد SSL تامین کننده Certum میشه.بعد از ایجاد کلاس لازم هست یک شی از آن را بسازیم تا بتونیم در همه جا از آن استفاده کنیم. برای این کار کد زیر در کلاس AppServiceProvider اضافه می کنیم.$this->app->singleton('SSL', function ($app) { return new \App\Services\SSLManager($app); });قدم سوم: ایجاد درایوریک دایرکتوری با نام دلخوا (که من در این مثال اسمشو SSLServices میزارم) ایجاد میکنیم.خرید گواهی و استعلام آن فرایند هایی هستند که در همه جا از آن ها استفاده میشه پس باید ساختاری ایجاد کرد که تمام درایور ها از اون ساختار پیروی کنند.در قدم بعدی به ازای هر تامین کننده یک دایرکتوری ایجاد میکنیم که منطق هر کدام از تامین کننده ها در اون دایرکتوری نوشته می شه.من نحوه ایجاد درایور یک تامین کننده در ادامه براتون مثال میزنمconfig = $config; } public function get() { // ...... } public function create() { // ..... } }قدم چهارم: ثبت درایوربرای استفاده از درایور نیاز هست که کلاس مورد نظر در زیرساخت مدیریت گواهی ها که در قدم دوم ایجاد کرده بودید اضافه کنیم. برای این کار ۲ راه حل داریم:ثبت درایور در AppServiceProvider :$SSL = app('SSL'); $SSL->extend('certum', function ($app) { return new CertumDriver($app); });ثبت درایور در خود کلاس مدیریت گواهی ها (یعنی SSLManager ) :public function createCertumDriver(): SSl { return new CertumDriver($this->config->get('ssl.drivers.certum')); } فقط توجه داشته باشید برای ثبت درایور های دیگر باید ساختار متد مورد نظر، یعنی create[Drivername]Driver حفظ کنید.قدم پنجم: ایجاد Facadeبرای راحتی در استفاده از کلاس مدیریت SSL میتونیم برای آن یک Facade ایجاد کنیم.get(); SSLFacade::create(); SSLFacade::get(); ممنون که تا این لحظه همراه من بودید. اگر سوال، انتقاد و یا پیشنهادی داشتید خوشحال میشم در بخش کامنت های این مطلب با من درمیون بزارید.منابع: https://inspector.dev/how-to-extend-laravel-with-driver-based-services/ https://pineco.de/drivers-and-managers-in-laravel/

تجربه استفاده از تلسکوپ: یکی از بهترین ابزارها برای مانیتورینگ در محیط توسعه

امیرحسین شریف نژاد — Fri, 01 Sep 2023 20:56:53 +0330

تجربه استفاده از تلسکوپ (laravel telescope)حتما براتون پیش امده که یک کدی نوشتید که در محیط لوکال به خوبی و بدون ارور کار می کرده اما وقتی روی سرور تست و محیط دولوپ (develop) اجرا می کردید ارور می داده و فرایند اجرای پروژتون به مشکل می خورده، حالا اگر خواسته باشید لاگ های اروری که برای این مشکل ایجاد شده رو بر روی سرور تست و محیط پروداکشن بدون دسترسی، برسی کنید چی کار می کنید؟ ?لاراول یک ابزاری داره به نام تلسکوپ که به راحتی می توانید با استفاده از اون بدون دسترسی به سرور لاگ های پروژتون رو برسی کنید، در این مقاله من تجربه و نحوه استفاده از این ابزار بهت میگم پس با من همراه باش.تلسکوپ (Laravel Telescope) چه ابزاری است؟لاراول تلسکوپ (Laravel Telescope) یک پکیج مانیتورینگ برای پروژه های لاراولی است که علاوه بر این که شما می توانید لاگ های و ارور های به وجود آمده را مشاهده و برسی کنید می توانید مواردی که در ادامه خدمتتون میگم مشاهده و برسی کنید.این امکانات عبارتند از:مشاهده جزئیات درخواست‌ها و پاسخ‌ها: با استفاده از Laravel Telescope می‌توانید جزئیات کاملی از درخواست‌ها و پاسخ‌های سرور را مشاهده کنید. این شامل اطلاعاتی مانند زمان پاسخ‌دهی، کدهای وضعیت HTTP، سرآیندها و پیام‌های خطا است.مانیتورینگ پایگاه داده: با استفاده از این پکیج می‌توانید عملیات‌های پایگاه داده را مشاهده کنید که شامل کوئری‌ها، زمان اجرا، پارامترها و نتایج بازگشتی می باشد.مشاهده صف‌ها (Queues): این ابزار به شما امکان می‌دهد تا صف‌ها و جاب ها را مشاهده و نتایج آن‌ها را بررسی کنید. می‌توانید اطلاعاتی مانند تعداد جاب در صف، زمان اجرا و وضعیت آن‌ها را مشاهده کنید.ثبت رویدادها (Events): پکیچ تلسکوپ در لاراول (Laravel Telescope) به شما اجازه می‌دهد رویدادهای مختلف سیستم را رصد کنید و جزئیات آن‌ها را ببینید. می‌توانید رویدادها را بر اساس نام، زمان و سایر ویژگی‌ها فیلتر کنید.مشاهده لاگ‌ها (Logs): پکیچ تلسکوپ لاراول به شما امکان می‌دهد تا لاگ‌های برنامه را به صورت مرتب و سازمان‌یافته مشاهده کنید. این ابزار به شما کمک می‌کند تا به راحتی لاگ‌های مربوط به خطاها (Exceptions)و اطلاعات لاگ ها را مشاهده و بررسی کنید.کش (Cache): Laravel Telescope به شما امکان می‌دهد تا فعالیت کش برنامه را مشاهده کنید. شما می‌توانید اطلاعاتی مانند زمان ایجاد، زمان انقضا کش و سایر جزئیات مربوطه را بررسی کنید. این امکان به شما کمک می‌کند تا عملکرد کش را مانیتور کنید و در صورت نیاز به بهبود عملکرد، تنظیمات کش را تغییر دهید.ردیس (Redis): تلسکوپ در لاراول اطلاعاتی درباره استفاده از Redis در برنامه شما نیز نمایش می‌دهد. شما می‌توانید اطلاعاتی مانند کلیدهای ثبت شده، نوع داده‌ها، زمان ایجاد و سایر جزئیات را بررسی کنید. این قابلیت به شما کمک می‌کند تا استفاده از آن Redis را مانیتور کنید و در صورت نیاز به بهبود عملکرد و تنظیمات آن بپردازید.ویوها (Views): با استفاده از Laravel Telescope، شما می‌توانید اطلاعاتی درباره ویوها (صفحات) در برنامه خود مشاهده کنید. شما می‌توانید مشخصاتی مانند نام ویو، زمان ایجاد، زمان بروزرسانی و سایر جزئیات مربوطه را بررسی کنید. این امکان به شما کمک می‌کند تا بهبود عملکرد صفحات را مانیتور کنید و در صورت نیاز، بهینه‌سازی‌های لازم را انجام دهید.برنامه‌ریزی زمانبندی (Schedule): تلسکوپ به شما این امکان را می‌دهد تا اطلاعات مربوط کران ها زمانبندی شده در برنامه خود را مشاهده کنید. شما ممی‌توانید جزئیاتی مانند نام کران، زمان اجرا، وضعیت اجرا و سایر جزئیات مربوطه را بررسی کنید.نحوه نصب Laravel Telescopeنصب Laravel Telescopeنصب تلسکوپ بسیار ساده هست و تنها با زدن چند کامند در کنسول میتونید به راحتی از اون استفاده کنید.composer require laravel/telescope php artisan telescope:install php artisan migrateبعد با مراجعه به آدرس زیر میتونید به داشبورد تلسکوپ دسترسی داشته باشید.http://mysite.com/telescopeفیلتر کردن قابلیت های تلسکوپبعد از نصب پکیج یک فایل در دایرکتوری برنامه شما با نام telescope.php ایجاد می شود. محتوایات این فایل شامل قابلیت هایی که در بالا خدمتتون عرض کردم هست که امکانات زیر را داریدمی توایند یک قابلیت را فعال و یا غیرفعال کنیدمیتوایند بعضی از امکانات را در هر بخش فیلتر کنید. به طور مثال شاید بخواهید که کامند زیر در تلسکوپ ثبت نشه.php artisan key:generateخب میتوانید به راحتی در فایل کانفیگ پکیج و در قسمت خودش نام کامند بالا اضافه کنید.'watchers' => [ Watchers\CommandWatcher::class => [ 'enabled' => env('TELESCOPE_COMMAND_WATCHER', true), 'ignore' => ['key:generate'], ] ],در صورتی که سرور تستتون زیاد حجم نداره و میخواید که هر چند روز یکبار لاگ های ثبتی حذف بشوند تلسکوپ به فکر شماهم بوده و می توانید از گذاشتن کامند های زیر در kernel کنسولتون از این قابلیت استفاده کنید.$schedule->command('telescope:prune')->daily(); $schedule->command('telescope:prune --hours=48')->daily();چرا توصیه نمی کنم که تلسکوپ در محیط پروداکشن استفاده کنید؟شاید با دیدن عنوان و برسی پکیج، این سوال براتون پیش آمده باشه که چرا امیرحسین این ابزار برای محیط پروداکشن و سرور اصلی توصیه نمیکنه و یا حرفی ازش نمیزنه؟! اگر که داکیومنت این پکیج بخونید توی قسمت معرفی تلسکوپ، لاراول گفته مناسب برای محیط توسعه (develop) ?ولی حالا چرا خود لاراول این حرف زده، با برسی هایی که بیشتر انجام دادم به ۳ نتیجه رسیدم که در ادامه اون ها براتون میگم:امنیت: همین طور که در بالا از قابلیت های این ابزار براتون گفتم یکی از قابلیت هایی که تلسکوپ (Laravel Telescope) داره نمایش کوئری هایی هست که به دیتابیس زده شده که این قابلیت به خاطر این که اطلاعات پایگاه داده در خودش داره ممکن که به وسیله آن سرور و دیتابیستون مورد نفوذ امنیتی قرار بگیره.افزایش منابع: تلسکوپ به صورت پیش فرض قابلیت هایی داره که در محیط توسعه مورد نیاز هست اما در محیط پروداکشن ممکن هست خیلی از قابلیت های این پکیج مورد نیاز نباشد و باعث اشغال بی مورد منابع سرور تون بشه و مجبور بشید به خاطر این موضوع منابع سرورتون افزایش بدید.کاهش عملکرد برنامه: در محیط پروداکشن، عملکرد سیستم باید بهینه و در حداکثر سرعت باشد اما تلسکوپ برای توسعه و اشکال زدایی طراحی شده است و عملکرد سیستم را با تعداد زیادی درخواست و عملیات مانیتورینگ و ثبت رویدادها ممکن هست کاهش دهد.حالا با توجه به مواردی که گفتم اگر می خواید که بر روی سرور اصلیتون و محیط پروداکشن (production) از ابزاری برای مانیتورینگ استفاده کنید که عملکرد برنامه کاهش نده و امنیت بالایی هم داشته باشه به نظر من از گرافانا استفاده کنید.منبع: https://laravel.com/docs/10.x/telescope

فرق معماری میکروسرویس و مونولیتیک: چگونه باید انتخاب کنیم؟

امیرحسین شریف نژاد — Fri, 11 Aug 2023 12:28:06 +0330

فرق میکروسرویس و مونولیتیک: چگونه باید انتخاب کنیم؟هر پروژه ای میخوام شروع کنم با توجه هزینه و مقیاس پروژه تصمیم میگیرم که از معماری میکروسرویسی استفاده کنم یا مونولوتیک (Monolithic)، حالا میخوام در ادامه شمارو با این دو معماری آشنا کنم و مزایا و معایب اونهارو بگم.مونولوتیک (Monolithic) چیست؟این نوع معماری یک روش عادی و قدیمی هست که در بسیاری از پروژه ها استفاده می شه. به صورت کلی هر پروژه از سه قسمت اصلی تشکیل شده:Front-endBack-endDatabaseپروژه و برنامه ای که از معماری مونولوتیک (Monolithic) استفاده میکنه، همه ی 3 قسمت بالا رو به صورت یکجا و واحد استفاده می کند که باعث می شود کد ها قسمت های مختلف بهم وابسته باشند و توسعه سخت تر بشه.البته استفاده از معماری مونولوتیک (Monolithic) کار اشتباهی نیست، همون طور که در مقدمه هم گفتم در پروژه هایی که زمان کمه، حجم پروژه پایین و یا برنامه نویس کمی در تیمتون دارید، استفاده از این نوع معماری شاید بهترین راهکار باشد.معماری میکروسرویسی (microservice) چیست؟میکروسرویس (Microservice) یک الگوی معماری است که در آن یک برنامه بزرگ را به چندین بخش کوچکتر و مستقل تقسیم می‌کند. هر بخش، به صورت یک سرویس جداگانه عمل می‌کند که مستقل از سایر بخش‌ها قابل توسعه و ارتقاء است. این الگوی معماری به توسعه و مدیریت برنامه‌ها کمک می‌کند و امکان ایجاد تغییرات در یک بخش از برنامه را بدون تاثیرگذاری بر سایر بخش‌ها فراهم می‌کند.پس معماری میکروسرویسی (Microservice) چه تفاوت هایی با معماری مونولوتیک (Monolithic) دارد؟سادگی در پیاده سازی: طراحی و پیاده‌سازی یک برنامه به صورت مونولوتیک بسیار ساده‌تر از سرویسی هست که به صورت میکروسرویسی طراحی و پیاده سازی شده باشد.تست و اجرا: امکان تست و اجرای در برنامه هایی که از معماری مونولوتیک استفاده میکنند بسیار ساده تر از برنامه هایی که از معماری میکروسرویسی استفاده میکنند هست.مدیریت: مدیریت و نگهداری یک برنامه با معماری منولوتیک ساده‌تر و کم‌هزینه‌تر است.قابلیت مقیاس‌پذیری: امکان مقیاس‌پذیری در سرویس هایی که از معماری مونولوتیک استفاده میکند به صورت کلی وجود ندارد و می‌بایست به صورت یکپارچه انجام شود در صورتی که در سرویس هایی که از معماری میکروسرویسی استفاده میکنند ساده تر هست.هزینه توسعه: تغییر کلیات یک سرویسی که از معماری مونولوتیک استفاده میکنه به دلیل این که در کد ها وابستگی وجود داره بسیار بالاتر از سرویسی است که از معماری میکروسرویسی استفاده میکنه.امنیت: در سرویس هایی که از معماری میکروسرویسی استفاده میکنند اگر مشکل امنیتی برای سرویسشون پیش بیاد ممکن هست در سایر بخش هاهم تاثیر خودش بزاره.سخن آخرممنون که تا این لحظه همراه من بودید. اگر سوال، انتقاد و یا پیشنهادی داشتید خوشحال میشم در بخش کامنت های این مطلب با من درمیون بزارید.

راه اندازی Jaeger در لاراول: یک قدم به جلو برای تحلیل و پیدا کردن باگ‌ها

امیرحسین شریف نژاد — Sun, 21 May 2023 23:57:31 +0330

راه اندازی Jaeger در Laravel: یک قدم به جلو برای تحلیل و پیدا کردن باگ‌هادر یکی از پروژه ها به یک مشکل برخوردیم که حدود یک ماه مارو درگیر خودش کرده بود و باعث به وجود آمدن یکسری از مشکلات در سیستم شده بود. کد برنامه رو که برسی میکردیم هیج موردی توش پیدا نمیکردیم که علت اون مشکل باشه، برای همین نیاز به ابزاری داشتیم تا بفهمیم که کدوم یکی از فرایند ها هست که مدت زمان اجرای اون خیلی زیاده و در نهایت باعث اون مشکل میشه.در این بین با ابزار jaeger آشنا شدم و کنجکاو شدم که باهاش کار کنم و در موردش بیشتر بدونم.به خاطر این که من خیلی دوست دارم که چیزهایی که یادمیگرمو به بقیه هم آموزش بدم تصمیم گرفتم که آموزش و نحوه کار با این ابزار به اشتراک بزارم. بنابراین در ادامه بیشتر در مورد این ابزار بهتون میگم و نحوه نصب در لاراول و کار با اون رو بهتون آموزش میدم.آشنایی با jaegerjaeger یک نرم افزار متن باز هست که با زبان GO توسعه داده شده و بدرد پروژه هایی میخوروه که از چند تا میکروسرویس تشکیل شده و فرایندها در میکروسرویس ها زیاد و پیچیده هست.در واقع، jaeger به شما اجازه می‌دهد تا در یک فرایند، مسیر حرکت یک درخواست در میکروسرویس ها مشاهده کنید و در صورت نیاز، از آن برای رفع مشکلات و ارتقای کیفیت سرویس‌های خود استفاده کنید. آشنایی با اجزای اصلی jaegerتعریف Traceبه مجموع عملیات هایی که در یک فرایند انجام میشود Trace گفته میشه. فرض کنید می خواهید از یک سایت یک موبایل بگیرید و عملیات هایی که فرضا نیاز هست در فرایند خرید موبایل انجام بشه به صورت زیر است:برسی موجود بودن موبایل سفارش شدهثبت سفارشثبت آدرس برای ارسال موبایلانتخاب روز و زمان ارسال و ثبت آنایجاد فاکتورانتقال کاربر به درگاه بانکی برای پرداخت هزینهگرفتن تاییده پرداخت از درگاه بعد از پرداخت صورت حسابآپدیت کردن وضعیت فاکتور به پرداخت شدهمجموع تمام این عملیات هایی که در بالا لیست کردم، بهش trace گفته میشود.تعریف Spanبه هرکدام از عملیات هایی که در یک فرایند انجام می شود span گفته می شود.نحوه راهندازی jaeger در لاراولنصب jaegerنصب jaegerدر قدم اول نیاز هست که jaeger بر روی لوکال و یا سرور نصب کنیم. خود سایت jaeger نحوه نصبُ با داکر به صورت زیر گفته:docker run -d --name jaeger \ -e COLLECTOR_OTLP_ENABLED=true \ -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \ -p 5775:5775/udp \ -p 6831:6831/udp \ -p 6832:6832/udp \ -p 5778:5778 \ -p 16686:16686 \ -p 14250:14250 \ -p 14268:14268 \ -p 14269:14269 \ -p 4317:4317 \ -p 4318:4318 \ -p 9411:9411 \ jaegertracing/all-in-one:1.45اما من در فایل داکری که آماده کردم هم لاراول و هم jaeger نصب میکنم میتونید از طریق لینک زیر به داکر فایل و داکرکامپوز اون دسترسی داشته باشید. https://github.com/sharifnezhad/docker-compose-archive/tree/main/laravel-and-jaeger-all-in-one بعد از نصب jaeger، پنل مدیریت اون بر روی پورت 16686 قابل دسترس قرار میگیره.نصب پکیج laravel-jaegerمن برای اتصال jaeger به لاراول از پکیج laravel-jaeger استفاده کردم، اما شما میتونید از پکیج های دیگه برای این موضوع استفاده کنید فقط اشکالی که این پکیج داره فعلا روی لاراول ۹ قابل استفاده هست که من برای این که بتونم در لارول 10 ازش استفاده کنم یکسری تغییر کوچیکی در اون دادم و میتونید با قرار گیری آدرس زیر در composer.json به جای نصب از دایرکتوری اصلی از دایرکتوریی که من فروک گرفتم و یکسری تغییرات در اون دادم استفاده کنید. https://github.com/sharifnezhad/laravel-jaeger.git نحوه تغییر آدرس پکیج در فایل composer.json خیلی ساده هست، میتوانید از طریق این لینک آدرس دانلود پکیج رو عوض کنید.بعد از نصب پکیج کامند زیر رو در کانتینر مربوطه اجرا کنید تا فایل کانفیگ jaeger به دایرکتوری config لاراول اضافه بشه.php artisan vendor:publish --provider="Chocofamilyme\LaravelJaeger\LaravelJaegerServiceProvider" --tag="config"و در آخر مقادیر زیر رو به فایل .env پروژتون اضافه کنید.JAEGER_HTTP_LISTENER_ENABLED=true JAEGER_CONSOLE_LISTENER_ENABLED=true JAEGER_QUERY_LISTENER_ENABLED=true JAEGER_JOB_LISTENER_ENABLED=true JAEGER_SERVICE_NAME=testJAEGER_HTTP_LISTENER_ENABLED با فعال کردن آن jaeger تمام درخواست هایی که از طریق http انجام می شود را ثبت می کند.JAEGER_CONSOLE_LISTENER_ENABLEDبا فعال کردن آن jaeger تمام کامند هایی از طریق artisan انجام می شود را ثبت می کند.JAEGER_QUERY_LISTENER_ENABLEDبا فعال کردن آن jaeger تمام کوئری هایی که زده میشه را ثبت می کند.JAEGER_SERVICE_NAMEنام میکروسرویس مربوطه در jaeger.و تمام شما با اجرای پروژه میتونید فرایند هایی که در پروژتون انجام شده را مشاهد کنید.سخن آخرممنون که تا این لحظه همراه من بودید. اگر سوال، انتقاد و یا پیشنهادی داشتید خوشحال میشم در بخش کامنت های این مطلب با من درمیون بزارید.

آشنایی با RabbitMQ: بهترین راهکار برای مدیریت پیام ها در پروژه های میکروسرویسی

امیرحسین شریف نژاد — Sat, 06 May 2023 20:46:26 +0330

اگر که بر روی پروژه ای کار میکنید که از چند میکروسرویس تشکیل شده و ابعاد آن از لحاظ ساختاری بزرگ است این مطلب میتونه به شما برای مدیریت بهتر فرایند ها بین میکروسرویسی کمک کنه.ابزاری که قصد دارم به شما معرفیش کنم RabbitMQ که یک Message Broker محسوب میشه.message broker یک نوع واسط بین میکروسرویسی است که باعث می شود میکروسرویس ها به صورت غیرمستقیم با هم در ارتباط باشند.مزایا استفاده از Message Brokerکاهش وابستگی بین میکرویسرویس هامیشه با میکروسرویس هایی ارتباط برقرار کرد که از زبان های مختلفتی در توسعه آن ها استفاده شدهقابلیت صف بندی درخواست هاامنیت بالاRabbitMQ چیست؟همان طور که با message broker و مزایای آن آشنا شدید، حالا نوبت میرسه به rabbitMQ، این ابزار یک نوع واسط بین میکروسرویسی است که با زبان Erlang نوشته شده و قابلیت ایجاد و مدیریت صف، روت کردن پیام و اطمینان از اتمام فرایند نیز دارد.اجزای تشکیل دهنده RabbitMQProducerاین بخش به عنوان ایجاد کننده پیام و یا درخواست عمل میکند و درخواست هارا که ممکن هست از هر نوعی باشند (حتی اطلاعات یک فرایند) به صف های مربوطه که برای ارسال به فرستند ایجاد شده اند ارسال میکند.Consumerاین بخش یک فرستند محسوب می شود که در هر لحظه صف خودش را برسی می کنه و در صورت وجود پیامی یکی یکی آن ها را انجام می دهد.Exchange (مبدل)من این بخش مثل یک بانک میدونم که از ۳ نوع باجه تشکیل شده است، که مراجعه کنندگان با توجه به نوع درخواستشان به باجه مربوطه مراجعه میکنند و بعد از ایجاد و ارسال درخواست، متصدی بانک درخواست برای برسی و انجام به صف مخصوص خودش اضافه میکنه.در زمانی که Producer یک پیام برای پردازش ارسال میکند Exchange با توجه به کلید ارسالی از سمت Producer تشخیص میدهد که پیام را به کدام از صف های ایجاد شده ارسال کند.نوع های مختلف Exchange (مبدل)Directاولین نوع از مبدل ها، مبدل دایرکت هست که درخواست و یا پیام را به صفی که عینا همان کلید برایش بایند شده اضافه میکند Topicدومین نوع از مبدل ها، مبدل تاپیک هست که نحوه استفاده از آن نسبت به مبدل های دیگر یکمی تفاوت دارد.در مبدل دایرکت باید Producer یک کلید خاص که به آن binding key گفته میشه ارسال کند اما در مبدل دایرکت به جای binding key از routing pattern استفاده می شود.با توجه به ویدئو بالا هنگامی Producer یک درخواست با استفاده از یک روت ارسال میکند مبدل روت ارسالی را با روت های متصل به خودش مطابقت میدهد و در صورتی که شباهتی بین آن ها پیدا کند، درخواست را به صف مربوطه خودش اضافه میکند.Fanoutنوع آخر مبدل ها، مبدل Fanout هست که کار با این نوع مبدل خیلی آسونه. این نوع مبدل مانند مبدل های دیگر نیست و لازم نیست برای اضافه شدن درخواست در صف یک کلید مخصوص ارسال شود. در صورتی که مبدل از نوع Fanout باشد، درخواست ارسالی برای همه ی صف های متصل شده به مبدل اضافه می شود.ممنون که تا این لحظه همراه من بودید. اگر سوال، انتقاد و یا پیشنهادی داشتید خوشحال میشم در بخش کامنت های این مطلب بیان کنید.منابع:RabbiMQRabbitMQ Exchanges