نوشته های JavadAgha

ساخت APIهای مقیاس‌پذیر: بهترین روش‌ها برای برنامه‌های پرترافیک

JavadAgha — Fri, 24 Jan 2025 04:52:30 +0330

در دنیای دیجیتال امروز، APIها (رابط‌های برنامه‌نویسی کاربردی) به عنوان ستون فقرات بسیاری از برنامه‌های پرترافیک عمل می‌کنند و ارتباط بین سرویس‌ها، پلتفرم‌ها و دستگاه‌های مختلف را ممکن می‌سازند. چه در حال اجرای یک پلتفرم رسانه‌اجتماعی باشید، چه یک وب‌سایت تجارت الکترونیک یا یک محصول SaaS، طراحی APIهایی که بتوانند تحت ترافیک سنگین مقیاس‌پذیر باشند، برای تضمین عملکرد، قابلیت اطمینان و رضایت کاربران حیاتی است.ساخت APIهای مقیاس‌پذیر نیازمند برنامه‌ریزی دقیق، طراحی هوشمندانه و پیاده‌سازی بهترین روش‌هاست. این راهنما استراتژی‌ها و ابزارهایی را بررسی می‌کند که برای ایجاد APIهایی که بتوانند میلیون‌ها درخواست را به طور موثر مدیریت کنند، نیاز دارید.مقیاس‌پذیری برای APIها به چه معناست؟مقیاس‌پذیری به توانایی یک API برای مدیریت تعداد درخواست‌ها یا کاربران در حال رشد بدون کاهش عملکرد اشاره دارد. دو نوع اصلی وجود دارد:مقیاس‌پذیری عمودی: افزودن منابع بیشتر (مثل CPU، حافظه) به یک سرور.مقیاس‌پذیری افقی: افزودن سرورها یا نمونه‌های بیشتر برای توزیع بار.برای APIها، دستیابی به مقیاس‌پذیری اغلب بر روی مقیاس‌پذیری افقی تمرکز دارد، تا اطمینان حاصل شود که سیستم می‌تواند با توزیع درخواست‌ها بین چندین سرور یا سرویس، ترافیک افزایش یافته را مدیریت کند.چالش‌های کلیدی در ساخت APIهای مقیاس‌پذیرترافیک بالا: مدیریت هزاران یا میلیون‌ها درخواست همزمان بدون ایجاد گلوگاه.سازگاری داده‌ها: اطمینان از سازگاری داده‌ها در سیستم‌های توزیع‌شده، به ویژه در برنامه‌های بلادرنگ.تأخیر: کاهش تأخیرها برای اطمینان از زمان پاسخ‌گویی سریع برای کاربران.تحمل خطا: اطمینان از اینکه سیستم حتی در صورت خرابی برخی اجزا در دسترس باقی می‌ماند.هزینه‌های بهینه: مقیاس‌پذیری به صورت کارآمد بدون تحمیل هزینه‌های اضافی.بهترین روش‌ها برای ساخت APIهای مقیاس‌پذیر۱. APIها را با مقیاس‌پذیری در ذهن طراحی کنیدالف. اصول RESTfulاز اصول REST (انتقال حالت بازنمایی) پیروی کنید تا اطمینان حاصل شود که API شما بدون حالت (stateless) است، به این معنی که هر درخواست شامل تمام اطلاعات لازم برای پردازش آن است.از روش‌های HTTP مناسب (GET, POST, PUT, DELETE) و کدهای وضعیت برای استانداردسازی ارتباطات استفاده کنید.ب. استفاده از نسخه‌بندی APIنسخه‌بندی را پیاده‌سازی کنید (مثلاً /v1/resource) تا سازگاری با نسخه‌های قبلی را تضمین کنید و به‌روزرسانی‌ها را بدون شکستن کلاینت‌های موجود انجام دهید.ج. استفاده از GraphQL یا gRPC برای موارد استفاده پیچیدهGraphQL: انعطاف‌پذیری را با اجازه دادن به کلاینت‌ها برای درخواست فقط داده‌های مورد نیازشان فراهم می‌کند و از دریافت داده‌های اضافی یا کم جلوگیری می‌کند.gRPC: یک پروتکل با عملکرد بالا که برای ارتباطات کم‌تأخیر و با توان عملیاتی بالا ایده‌آل است و معمولاً در معماری‌های میکروسرویس استفاده می‌شود.۲. بهینه‌سازی عملکرد APIالف. پیاده‌سازی کشپاسخ‌ها را در چندین سطح کش کنید:کش سمت کلاینت: از هدرهای HTTP مانند Cache-Control و ETags استفاده کنید.شبکه تحویل محتوا (CDN): از CDNهایی مانند Cloudflare یا Akamai برای توزیع محتوای کش‌شده به سرورهای نزدیک به کاربران استفاده کنید.کش سمت سرور: از ابزارهایی مانند Redis یا Memcached برای ذخیره داده‌های پراستفاده استفاده کنید.ب. استفاده از صفحه‌بندی و محدودیت دادهبرای endpointهایی که مجموعه‌های داده بزرگ برمی‌گردانند، صفحه‌بندی، فیلتر کردن و مرتب‌سازی را پیاده‌سازی کنید تا مقدار داده ارسالی در هر پاسخ محدود شود.مثال: /users?page=2&limit=20.ج. کاهش اندازه payloadاز فرمت‌های داده سبک مانند JSON یا Protocol Buffers (در مورد gRPC) استفاده کنید.پاسخ‌ها را با استفاده از gzip یا Brotli فشرده کنید.د. پردازش ناهمزمانوظایف طولانی‌مدت یا غیرضروری (مثل ارسال ایمیل، پردازش مجموعه‌های داده بزرگ) را به کارهای پس‌زمینه با استفاده از صف‌های پیام مانند RabbitMQ, Apache Kafka یا AWS SQS منتقل کنید.۳. اطمینان از دسترسی بالاالف. تعادل بارترافیک ورودی را با استفاده از متعادل‌کننده‌های بار بین چندین سرور توزیع کنید:متعادل‌کننده‌های بار سخت‌افزاری (مثل F5 Networks).متعادل‌کننده‌های بار نرم‌افزاری (مثل NGINX, HAProxy).متعادل‌کننده‌های بار ابری (مثل AWS Elastic Load Balancer, Google Cloud Load Balancer).ب. محدودیت نرخ و کنترل ترافیکAPI خود را در برابر سوءاستفاده یا استفاده بیش از حد تصادفی با پیاده‌سازی محدودیت نرخ محافظت کنید.مثال: اجازه ۱۰۰۰ درخواست در دقیقه به ازای هر کاربر.ابزارها: از کتابخانه‌هایی مانند RateLimiter یا دروازه‌های API مانند Kong, Apigee یا AWS API Gateway استفاده کنید.ج. تحمل خطاAPI خود را طوری طراحی کنید که بتواند خرابی‌های جزئی را به‌طور مناسب مدیریت کند:از قطع‌کننده‌های مدار (مثل Netflix Hystrix, Resilience4j) برای جلوگیری از خرابی‌های آبشاری استفاده کنید.برای خطاهای موقت، از سیاست‌های تلاش مجدد با تأخیر نمایی استفاده کنید.د. توزیع جغرافیاییAPI خود را در چندین منطقه مستقر کنید تا تأخیر کاهش یابد و دسترسی تضمین شود. از ارائه‌دهندگان ابری مانند AWS، Azure یا Google Cloud برای استقرار جهانی استفاده کنید.۴. استفاده از زیرساخت مقیاس‌پذیرالف. کانتینری‌سازیاز کانتینرها با Docker برای بسته‌بندی سرویس‌های خود استفاده کنید تا سازگاری بین محیط‌های توسعه و تولید تضمین شود.کانتینرها را با Kubernetes برای مقیاس‌پذیری خودکار، تعادل بار و تحمل خطا مدیریت کنید.ب. معماری‌های سرورلساز سرویس‌های سرورلس مانند AWS Lambda، Google Cloud Functions یا Azure Functions استفاده کنید تا API شما بر اساس تقاضا به‌طور خودکار مقیاس‌پذیر شود.مزایا:عدم نیاز به مدیریت سرور.قیمت‌گذاری پرداخت به ازای استفاده.ج. معماری میکروسرویسبرنامه‌های یکپارچه (monolithic) را به سرویس‌های کوچک‌تر و مستقل تقسیم کنید.از یک دروازه API (مثل Kong, NGINX) برای مدیریت ارتباط بین میکروسرویس‌ها استفاده کنید.۵. نظارت و بهینه‌سازی عملکرد APIالف. تنظیم مشاهده‌پذیریثبت‌ رویدادها: از ابزارهایی مانند ELK Stack (Elasticsearch, Logstash, Kibana) یا Fluentd برای جمع‌آوری و تحلیل رویدادها استفاده کنید.نظارت: معیارهایی مانند نرخ درخواست‌ها، نرخ خطا و تأخیر را با ابزارهایی مانند Prometheus و Grafana ردیابی کنید.ردیابی توزیع‌شده: از OpenTelemetry, Jaeger یا Zipkin برای ردیابی درخواست‌ها در بین سرویس‌های توزیع‌شده استفاده کنید.ب. تست مقیاس‌پذیریتست بار و تست استرس را با استفاده از ابزارهایی مانند:Apache JMeterk6LocustArtilleryانجام دهید.گلوگاه‌ها را شناسایی کنید و عملکرد را تحت شرایط ترافیک بالا بهینه کنید.۶. امنیت API خود را تضمین کنیدالف. استفاده از احراز هویت و مجوزروش‌های احراز هویت ایمن مانند OAuth 2.0 یا JWT (توکن‌های وب JSON) را پیاده‌سازی کنید.کنترل دسترسی مبتنی بر نقش (RBAC) را برای محدود کردن دسترسی به endpointهای حساس اعمال کنید.ب. رمزگذاری ارتباطاتاز HTTPS برای رمزگذاری ترافیک API و تضمین ارتباط ایمن بین کلاینت‌ها و سرورها استفاده کنید.ج. اعتبارسنجی ورودیتمام ورودی‌های کاربر را پاکسازی و اعتبارسنجی کنید تا از حملات تزریق (مثل تزریق SQL, XSS) جلوگیری کنید.د. محافظت در برابر DDoSاز ابزارهایی مانند AWS Shield, Cloudflare یا Akamai برای محافظت در برابر حملات DDoS استفاده کنید.۷. برنامه‌ریزی برای مقیاس‌پذیری افقیالف. APIهای بدون حالتAPIها را طوری طراحی کنید که بدون حالت باشند تا هر درخواست توسط هر سرور قابل پردازش باشد.داده‌های session را در کش‌های توزیع‌شده مانند Redis به جای حافظه برنامه ذخیره کنید.ب. مقیاس‌پذیری پایگاه دادهاز sharding پایگاه داده، replicaهای خواندن یا پایگاه‌های داده توزیع‌شده (مثل CockroachDB, Amazon Aurora) برای مدیریت ترافیک افزایش یافته استفاده کنید.بهینه‌سازی کوئری را پیاده‌سازی کنید تا بار پایگاه داده کاهش یابد.ج. استفاده از مقیاس‌پذیری خودکاراز پلتفرم‌های ابری (مثل AWS Auto Scaling, Google Cloud Autoscaler) برای افزایش یا کاهش خودکار منابع بر اساس ترافیک استفاده کنید.مثال واقعی: مقیاس‌پذیری یک API تجارت الکترونیکسناریو:یک پلتفرم تجارت الکترونیک در طول حراج‌های بلک فرایدی با ترافیک سنگین مواجه می‌شود. API وظایفی مانند جستجوی محصولات، ثبت سفارش‌ها و به‌روزرسانی موجودی را مدیریت می‌کند.طراحی API مقیاس‌پذیر:بهینه‌سازی پایگاه داده:از replicaهای خواندن برای کوئری‌های کاتالوگ محصولات استفاده کنید.کش‌گذاری را برای جزئیات محصولات پراستفاده پیاده‌سازی کنید.تعادل بار:نمونه‌های API را پشت یک متعادل‌کننده بار در چندین منطقه مستقر کنید.محدودیت نرخ:فقط ۱۰۰ درخواست در دقیقه به ازای هر کاربر مجاز کنید تا از سوءاستفاده جلوگیری شود.پردازش ناهمزمان سفارش‌ها:از یک صف پیام (مثل RabbitMQ) برای پردازش سفارش‌ها در پس‌زمینه استفاده کنید.نظارت:از داشبوردهای Grafana برای نظارت بر تأخیر API و نرخ خطا استفاده کنید.محافظت در برابر DDoS:از AWS Shield برای محافظت در برابر افزایش ترافیک ناشی از حملات مخرب استفاده کنید.

تسلط بر معماری میکروسرویس‌ها: یه راهنمای کامل

JavadAgha — Fri, 24 Jan 2025 04:43:00 +0330

معماری میکروسرویس‌ها این روزها خیلی محبوب شده و به شرکت‌ها کمک می‌کنه تا برنامه‌هایی بسازن که هم مقیاس‌پذیر باشن، هم مقاوم و هم سریع. با پیشرفت فناوری، میکروسرویس‌ها هم تکامل پیدا کردن و ابزارها و روش‌های جدیدی بهشون اضافه شده تا بتونن با چالش‌های سیستم‌های توزیع‌شده بهتر کنار بیان.این راهنما یه مرور کامل از میکروسرویس‌ها ارائه می‌ده و بهت می‌گه که چی هستن، چرا مهم‌ن، چه روندهایی دارن و چطوری می‌تونی اون‌ها رو طراحی، پیاده‌سازی و مدیریت کنی.میکروسرویس‌ها چی هستن؟معماری میکروسرویس‌ها یه روش طراحی‌ست که توش یه برنامه از چند تا سرویس کوچیک و مستقل تشکیل شده که از طریق API با هم حرف می‌زنن. هر میکروسرویس یه کار خاص رو انجام می‌ده و می‌تونه به طور مستقل توسعه، اجرا و بزرگ‌تر بشه.ویژگی‌های اصلی میکروسرویس‌ها:استقلال: هر میکروسرویس کد، دیتابیس و چرخه حیات خودش رو داره.اتصال سست: میکروسرویس‌ها طوری طراحی شدن که وابستگی‌ها کم باشه و بتونن به طور مستقل رشد کنن.تمرکز روی کارهای تجاری: هر میکروسرویس روی یه کار خاص تجاری تمرکز می‌کنه.مقیاس‌پذیری: هر سرویس می‌تونه بر اساس نیازش بزرگ‌تر یا کوچیک‌تر بشه.مقاومت: اگر یه سرویس خراب بشه، کل سیستم از کار نمی‌افته.چرا میکروسرویس‌ها مهم هستند؟۱. مقیاس‌پذیری و انعطاف‌پذیریبا رشد برنامه‌های ابری و استفاده بیشتر از فناوری، شرکت‌ها به سیستم‌هایی نیاز دارن که بتونن به راحتی بزرگ‌تر بشن. میکروسرویس‌ها این امکان رو فراهم می‌کنن.۲. عرضه سریع‌تر به بازاربا میکروسرویس‌ها، تیم‌ها می‌تونن روی بخش‌های مختلف برنامه به طور همزمان کار کنن و ویژگی‌های جدید رو سریع‌تر ارائه بدن.۳. مقاومت بیشتراگر یه سرویس خراب بشه، بقیه سرویس‌ها به کار خودشون ادامه می‌دن. این موضوع برای برنامه‌هایی که نیاز به کارکرد مداوم دارن خیلی مهمه.۴. هماهنگی با DevOps و CI/CDمیکروسرویس‌ها با روش‌های DevOps خیلی خوب کار می‌کنن و امکان تست خودکار، استقرار مداوم و به‌روزرسانی سریع رو فراهم می‌کنن.۵. پشتیبانی از فناوری‌های جدیدمیکروسرویس‌ها می‌تونن با فناوری‌های جدید مثل هوش مصنوعی، اینترنت اشیا و محاسبات لبه (Edge Computing) ادغام بشن.روندهای جدید میکروسرویس‌ها۱. Kubernetes به عنوان پایهKubernetes الان بهترین ابزار برای مدیریت کانتینرهاست و بیشتر میکروسرویس‌ها روی اون اجرا می‌شن.۲. استفاده از شبکه سرویس (Service Mesh)ابزارهایی مثل Istio و Linkerd برای مدیریت ارتباط بین سرویس‌ها و امنیت‌شون خیلی مهم شدن.۳. معماری‌های مبتنی بر رویدادبا استفاده از ابزارهایی مثل Kafka، سرویس‌ها می‌تونن به صورت ناهمزمان با هم ارتباط برقرار کنن و این کار باعث می‌شه سیستم‌ها مقاوم‌تر و مقیاس‌پذیرتر بشن.۴. استفاده از چند نوع دیتابیسهر سرویس می‌تونه از دیتابیسی استفاده کنه که برای کارش مناسب‌تره، مثلاً بعضی‌ها از دیتابیس‌های رابطه‌ای و بعضی‌ها از NoSQL استفاده می‌کنن.۵. ادغام با محاسبات لبه (Edge Computing)میکروسرویس‌ها بیشتر نزدیک به کاربران اجرا می‌شن تا تأخیر کم‌تر و عملکرد بهتری داشته باشن.۶. مشاهده‌پذیری هوشمندابزارهایی مثل Datadog و New Relic از هوش مصنوعی استفاده می‌کنن تا مشکلات سیستم رو تشخیص بدن و عملکرد رو بهبود بدن.۷. استفاده از GraphQL به جای RESTGraphQL داره به عنوان یه جایگزین انعطاف‌پذیر برای REST محبوب می‌شه و به سرویس‌ها کمک می‌کنه تا داده‌ها رو بهتر مدیریت کنن.چطوری یه معماری میکروسرویس‌ها طراحی کنیم؟۱. مرزهای سرویس‌ها رو مشخص کناز طراحی مبتنی بر دامنه (DDD) استفاده کن تا بفهمی هر سرویس چه کاری باید انجام بده.مطمئن شو که مسئولیت‌ها بین سرویس‌ها تداخل نداشته باشن.۲. روش ارتباط بین سرویس‌ها رو انتخاب کنبرای ارتباط همزمان از REST یا gRPC استفاده کن.برای ارتباط ناهمزمان از ابزارهایی مثل Kafka یا RabbitMQ استفاده کن.۳. طراحی API-محورAPIها رو طوری طراحی کن که برای مصرف‌کننده‌ها راحت باشن و به خوبی مستند شده باشن.۴. هر سرویس دیتابیس خودش رو داشته باشههر سرویس باید دیتابیس خودش رو داشته باشه تا وابستگی‌ها کم‌تر بشه.۵. مشاهده‌پذیری رو از همون اول اضافه کناز ابزارهایی مثل Prometheus و Grafana برای نظارت و ردیابی مشکلات استفاده کن.چطوری میکروسرویس‌ها رو پیاده‌سازی کنیم؟۱. از چارچوب‌های مدرن استفاده کنبرای هر سرویس از چارچوبی استفاده کن که تیم‌ت بلده، مثلاً Spring Boot برای جاوا یا Flask برای پایتون.۲. سرویس‌ها رو کانتینری‌سازی کناز Docker برای کانتینری‌سازی سرویس‌ها استفاده کن.۳. کانتینرها رو با Kubernetes مدیریت کنKubernetes بهت کمک می‌کنه تا سرویس‌ها رو به راحتی مقیاس‌پذیر و مدیریت کنی.۴. امنیت رو جدی بگیراز ابزارهایی مثل Istio برای ایمن‌سازی ارتباط بین سرویس‌ها استفاده کن.۵. خطوط CI/CD رو خودکار کناز ابزارهایی مثل Jenkins یا GitHub Actions برای تست و استقرار خودکار استفاده کن.چطوری میکروسرویس‌ها رو مدیریت کنیم؟۱. نظارت و مشاهده‌پذیریاز ابزارهایی مثل Grafana برای نظارت بر سلامت سرویس‌ها استفاده کن.۲. مدیریت خرابی‌هااز قطع‌کننده‌های مدار (Circuit Breakers) استفاده کن تا اگر یه سرویس خراب شد، بقیه سرویس‌ها از کار نیفتن.۳. مدیریت پیکربندی و اسراراز ابزارهایی مثل HashiCorp Vault برای مدیریت اطلاعات حساس استفاده کن.۴. بهینه‌سازی عملکردبه طور منظم سرویس‌ها رو بررسی کن تا مشکلات عملکردی رو پیدا کنی.چالش‌های میکروسرویس‌ها و راه‌حل‌ها۱. پیچیدگیچالش: مدیریت تعداد زیادی سرویس می‌تونه سخت باشه.راه‌حل: از Kubernetes و شبکه‌های سرویس استفاده کن تا کارها رو خودکار کنی.۲. سازگاری داده‌هاچالش: داده‌ها ممکنه بین سرویس‌ها ناسازگار بشن.راه‌حل: از الگوهایی مثل SAGA استفاده کن.۳. اشکال‌زداییچالش: پیدا کردن مشکل در بین چندین سرویس می‌تونه سخت باشه.راه‌حل: از ردیابی توزیع‌شده و ثبت‌ رویدادها استفاده کن.۴. هماهنگی استقرارچالش: به‌روزرسانی چندین سرویس می‌تونه مشکل‌ساز بشه.راه‌حل: از استراتژی‌های استقرار مثل canary releases استفاده کن.ابزارها و فناوری‌های مهم برای میکروسرویس‌هامدیریت کانتینرهاKubernetes، Docker، Helm.ارتباط بین سرویس‌هاREST، gRPC، Kafka.شبکه سرویس (Service Mesh)Istio، Linkerd.مشاهده‌پذیریPrometheus، Grafana، Datadog.مدیریت APIKong، AWS API Gateway.امنیتHashiCorp Vault، Istio.

درک سیستم‌های توزیع‌شده با مثال‌های واقعی

JavadAgha — Fri, 24 Jan 2025 04:32:12 +0330

سیستم‌های توزیع‌شده در دنیای امروز که فناوری‌محور است، همه‌جا حضور دارند. از سرویس‌های استریم مثل Netflix تا پلتفرم‌های خرید آنلاین مثل Amazon، سیستم‌های توزیع‌شده نیروی محرکه مهم‌ترین برنامه‌هایی هستند که هر روز استفاده می‌کنیم. اما دقیقاً سیستم توزیع‌شده چیست و چگونه کار می‌کند؟ بیایید این مفهوم را بررسی کنیم و با مثال‌های واقعی این حوزه جذاب و پیچیده از علوم کامپیوتر را بهتر درک کنیم.سیستم توزیع‌شده چیست؟یک سیستم توزیع‌شده مجموعه‌ای از کامپیوترهای مستقل است که با هم کار می‌کنند تا به کاربر نهایی به عنوان یک سیستم واحد ظاهر شوند. این سیستم‌ها برای رسیدن به یک هدف مشترک با هم همکاری می‌کنند، منابع را به اشتراک می‌گذارند و از طریق شبکه با هم ارتباط برقرار می‌کنند.ویژگی‌های کلیدی یک سیستم توزیع‌شده عبارتند از:چندین گره: شامل چندین کامپیوتر مستقل (یا گره) است.هماهنگی: گره‌ها با هم ارتباط برقرار می‌کنند و اقدامات خود را هماهنگ می‌کنند تا به هدف مشترک برسند.شفافیت: برای کاربر، سیستم به عنوان یک واحد منسجم ظاهر می‌شود، حتی اگر از چندین ماشین تشکیل شده باشد.تحمل خطا: اگر یک گره از کار بیفتد، سیستم می‌تواند به کار خود ادامه دهد (تا حدی).مقیاس‌پذیری: سیستم‌های توزیع‌شده می‌توانند با اضافه کردن گره‌های بیشتر، به صورت افقی مقیاس‌پذیر شوند.اجزای اصلی سیستم‌های توزیع‌شدهگره‌ها: ماشین‌های مستقل (مثل سرورها، ماشین‌های مجازی یا کانتینرها) که در سیستم مشارکت می‌کنند.شبکه: یک زیرساخت ارتباطی (مثل اینترنت) که گره‌ها را به هم متصل می‌کند.میان‌افزار (Middleware): نرم‌افزاری که ارتباط، هماهنگی و اشتراک منابع بین گره‌ها را ممکن می‌سازد.چرا از سیستم‌های توزیع‌شده استفاده می‌کنیم؟سیستم‌های توزیع‌شده چندین مزیت دارند:مقیاس‌پذیری: اضافه کردن گره‌های بیشتر می‌تواند عملکرد را بهبود بخشد و بار کاری بیشتری را مدیریت کند.تحمل خطا: خرابی در یک بخش از سیستم لزوماً باعث از کار افتادن کل سیستم نمی‌شود.عملکرد: وظایف می‌توانند بین چندین گره تقسیم شوند و پردازش موازی و نتایج سریع‌تر را ممکن سازند.توزیع جغرافیایی: گره‌ها می‌توانند در سراسر جهان توزیع شوند تا تأخیر برای کاربران در مناطق مختلف کاهش یابد.اشتراک منابع: سیستم‌های توزیع‌شده امکان اشتراک منابعی مانند ذخیره‌سازی، قدرت محاسباتی یا داده را فراهم می‌کنند.مثال‌های واقعی سیستم‌های توزیع‌شدهبرای درک بهتر سیستم‌های توزیع‌شده، بیایید چند مثال واقعی و نحوه کار آن‌ها را بررسی کنیم.۱. گوگل (نمایه‌سازی و جستجوی توزیع‌شده)کاربرد: وقتی چیزی را در گوگل جستجو می‌کنید، انتظار دارید تقریباً بلافاصله نتایج را ببینید. برای رسیدن به این هدف، قدرت محاسباتی و ذخیره‌سازی عظیمی لازم است.نحوه کار:گوگل وب را به بخش‌های کوچک‌تر تقسیم می‌کند و هر بخش را روی سرورهای مختلف در سراسر جهان ذخیره می‌کند.فرآیند نمایه‌سازی (خزش، تحلیل و ذخیره صفحات وب) بین هزاران سرور توزیع می‌شود.وقتی چیزی را جستجو می‌کنید، درخواست شما به چندین سرور ارسال می‌شود که به طور موازی داده‌های خود را جستجو می‌کنند.نتایج جمع‌آوری و رتبه‌بندی می‌شوند و سپس به شما ارسال می‌شوند.ویژگی‌های کلیدی:تحمل خطا: اگر یک سرور از کار بیفتد، سرورهای دیگر می‌توانند بار را مدیریت کنند.مقیاس‌پذیری: با رشد وب، گوگل می‌تواند سرورهای بیشتری اضافه کند تا داده‌های بیشتر را مدیریت کند.تأخیر کم: سرورهای توزیع‌شده پاسخ‌های سریع‌تری برای کاربران در سراسر جهان فراهم می‌کنند.۲. نتفلیکس (شبکه تحویل محتوا - CDN)کاربرد: نتفلیکس فیلم‌ها و سریال‌ها را برای میلیون‌ها کاربر در سراسر جهان استریم می‌کند، اغلب با کیفیت بالا یا 4K، در حالی که پخش روان را حفظ می‌کند.نحوه کار:نتفلیکس از یک شبکه تحویل محتوا (CDN) به نام Open Connect استفاده می‌کند تا محتوا را به کاربران نزدیک‌تر کند.نمایش‌ها و فیلم‌های محبوب روی سرورهایی که در مراکز داده و شبکه‌های ارائه‌دهندگان اینترنت (ISP) در سراسر جهان قرار دارند، ذخیره می‌شوند.وقتی کاربری یک ویدیو درخواست می‌کند، از نزدیک‌ترین سرور استریم می‌شود تا تأخیر کاهش یابد و عملکرد بهبود یابد.ویژگی‌های کلیدی:توزیع جغرافیایی: سرورهای توزیع‌شده تأخیر کم را برای کاربران در مناطق مختلف تضمین می‌کنند.تحمل خطا: اگر یک سرور از کار بیفتد، ویدیو می‌تواند از سرور دیگری در نزدیکی استریم شود.مقیاس‌پذیری: نتفلیکس می‌تواند با توزیع بار در شبکه خود، افزایش تقاضا (مثل انتشار یک نمایش محبوب) را مدیریت کند.۳. آمازون (پلتفرم تجارت الکترونیک)کاربرد: آمازون تجربه خرید بی‌درزی را به میلیون‌ها کاربر ارائه می‌دهد و همه چیز را از جستجوی محصول تا پرداخت و مدیریت موجودی مدیریت می‌کند.نحوه کار:سیستم آمازون یک معماری توزیع‌شده دارد که در آن سرویس‌های مختلف (مثل جستجوی محصول، پیشنهادات، پرداخت‌ها و موجودی) روی سرورهای جداگانه اجرا می‌شوند.میکروسرویس‌ها با هم ارتباط برقرار می‌کنند تا تجربه یکپارچه‌ای برای کاربر فراهم کنند.داده‌ها در چندین سرور در مناطق مختلف تکثیر می‌شوند تا دسترسی بالا و تحمل خطا تضمین شود.ویژگی‌های کلیدی:مقیاس‌پذیری: در فصل‌های اوج (مثل بلک فرایدی)، سرورهای اضافی بار افزایش یافته را مدیریت می‌کنند.تحمل خطا: حتی اگر یک سرویس از کار بیفتد (مثل جستجوی موجودی)، سرویس‌های دیگر (مثل پرداخت‌ها) به کار خود ادامه می‌دهند.توزیع جغرافیایی: سفارش‌ها و موجودی بر اساس موقعیت کاربر مدیریت می‌شوند تا زمان تحویل به حداقل برسد.۴. بیت‌کوین و بلاک‌چین (سیستم توزیع‌شده غیرمتمرکز)کاربرد: بیت‌کوین یک ارز دیجیتال غیرمتمرکز است که برای تأیید و ثبت تراکنش‌ها به یک دفترکل توزیع‌شده (بلاک‌چین) متکی است.نحوه کار:تراکنش‌ها به شبکه‌ای از گره‌ها (کامپیوترها) ارسال می‌شوند که آن‌ها را تأیید و به بلاک‌چین اضافه می‌کنند.هر گره یک کپی از بلاک‌چین دارد، که تضمین می‌کند هیچ نهاد واحدی شبکه را کنترل نمی‌کند.سیستم از الگوریتم‌های اجماع (مثل اثبات کار) استفاده می‌کند تا مطمئن شود فقط تراکنش‌های معتبر اضافه می‌شوند.ویژگی‌های کلیدی:غیرمتمرکز بودن: هیچ مرجع مرکزی سیستم را مدیریت نمی‌کند، که آن را در برابر سانسور و نقاط شکست مقاوم می‌کند.تحمل خطا: حتی اگر برخی گره‌ها از کار بیفتند، سیستم به کار خود ادامه می‌دهد.شفافیت: تراکنش‌ها برای همه شرکت‌کنندگان قابل مشاهده است، که اعتماد را تضمین می‌کند.۵. اوبر (پلتفرم اشتراک‌گذاری سواری)کاربرد: اوبر رانندگان و مسافران را به صورت بلادرنگ به هم متصل می‌کند و تأخیر کم و ارتباط بی‌درز را تضمین می‌کند.نحوه کار:معماری اوبر بین چندین میکروسرویس توزیع شده است، مثل ردیابی موقعیت، تطبیق سواری، پرداخت‌ها و اعلان‌ها.داده‌ها در سرورهای سراسر جهان تکثیر می‌شوند تا زمان پاسخ‌گویی سریع برای کاربران در مناطق مختلف تضمین شود.سیستم از پروتکل‌های ارتباطی بلادرنگ استفاده می‌کند تا مسافران را با نزدیک‌ترین رانندگان موجود تطبیق دهد.ویژگی‌های کلیدی:مقیاس‌پذیری: سیستم می‌تواند میلیون‌ها درخواست سواری را به طور همزمان مدیریت کند.تحمل خطا: اگر یک میکروسرویس از کار بیفتد (مثل اعلان‌ها)، بقیه پلتفرم به کار خود ادامه می‌دهد.عملکرد بلادرنگ: سرورهای توزیع‌شده تأخیر کم را برای وظایفی مثل تطبیق راننده و بهینه‌سازی مسیر تضمین می‌کنند.۶. فیسبوک (پلتفرم رسانه اجتماعی)کاربرد: فیسبوک از میلیاردها کاربر پشتیبانی می‌کند و به آن‌ها امکان می‌دهد به‌روزرسانی‌ها را ارسال کنند، رسانه به اشتراک بگذارند و به صورت بلادرنگ تعامل کنند.نحوه کار:فیسبوک از یک معماری توزیع‌شده استفاده می‌کند که در آن سرویس‌های مختلف (مثل فید خبری، پیام‌رسانی، اعلان‌ها) روی سیستم‌های جداگانه اجرا می‌شوند.محتوا در مراکز داده در سراسر جهان ذخیره و تکثیر می‌شود تا تأخیر به حداقل برسد.سیستم‌های پیام‌رسانی از پروتکل‌های توزیع‌شده بلادرنگ استفاده می‌کنند تا پیام‌ها را فوراً تحویل دهند.ویژگی‌های کلیدی:مقیاس‌پذیری: فیسبوک با توزیع بار کاری بین سرورهای خود، میلیاردها تعامل روزانه را مدیریت می‌کند.تحمل خطا: اگر یک مرکز داده از کار بیفتد، مراکز دیگر کار را ادامه می‌دهند تا خدمات بدون وقفه ارائه شود.توزیع جغرافیایی: سرورهای مستقر در سراسر جهان تأخیر را برای کاربران در مناطق مختلف کاهش می‌دهند.چالش‌های سیستم‌های توزیع‌شدهبا وجود مزایای زیاد، سیستم‌های توزیع‌شده چالش‌هایی نیز دارند:یکپارچگی: اطمینان از اینکه همه گره‌ها داده‌های یکسانی دارند (مثلاً در یک پایگاه داده) می‌تواند به دلیل تأخیر شبکه یا خرابی دشوار باشد.مثال: در یک سیستم تجارت الکترونیک جهانی، اطمینان از اینکه تعداد موجودی‌ها به‌صورت بلادرنگ دقیق است.تحمل خطا: طراحی سیستم‌هایی که با وجود خرابی‌ها به کار خود ادامه دهند، پیچیده است.مثال: اگر یک سرور نتفلیکس از کار بیفتد، کاربران باید همچنان بتوانند محتوا را از سرور دیگری استریم کنند.تأخیر: ارتباط بین گره‌ها می‌تواند تأخیر ایجاد کند.مثال: اطمینان از پاسخ‌های کم‌تأخیر برای برنامه‌های بلادرنگ مثل اوبر.امنیت: ایمن‌سازی ارتباطات و داده‌ها در یک سیستم توزیع‌شده بسیار مهم است.مثال: جلوگیری از دسترسی غیرمجاز به داده‌های حساس کاربر در یک سیستم پرداخت.

(Serverless) چرا این فناوری آینده توسعه ابریه؟

JavadAgha — Fri, 24 Jan 2025 04:23:47 +0330

محاسبات سرورلس داره روش ساخت، اجرا و مدیریت برنامه‌ها رو توی فضای ابری عوض می‌کنه. با این فناوری، دیگه لازم نیست نگران مدیریت سرورها باشی. همه چیز رو شرکت‌های ارائه‌دهنده ابر (مثل AWS، Azure و Google Cloud) مدیریت می‌کنن و تو فقط روی نوشتن کد تمرکز می‌کنی. این یعنی دیگه نیازی نیست وقتت رو صرف کارهایی مثل تنظیم سرورها، مقیاس‌پذیری یا نگهداری زیرساخت‌ها کنی.البته، اسمش سرورلس (بدون سرور) هست، ولی این به معنی نیست که سروری وجود نداره. بلکه به این معنیه که دیگه لازم نیست خودت سرورها رو مدیریت کنی. شرکت‌های ابری این کار رو برات انجام می‌دن و تو فقط برای زمانی که کدت اجرا می‌شه هزینه پرداخت می‌کنی. این مدل داره خیلی سریع محبوب می‌شه و خیلی‌ها معتقدن که آینده توسعه ابری همینه. اما چرا اینقدر مهمه و چه چیزی اون رو این‌قدر قدرتمند کرده؟سرورلس چیه؟سرورلس یه مدل توسعه ابریه که توش تو کد می‌نویسی و اون رو اجرا می‌کنی، بدون اینکه بخوای نگران سرورها باشی. توی این مدل:تو فقط کد می‌نویسی: مثلاً یه تابع کوچیک که یه کار خاص رو انجام می‌ده.شرکت ابری همه کارها رو انجام می‌ده: مثل تنظیم سرورها، مقیاس‌پذیری و نگهداری.هزینه‌ها بر اساس مصرفه: یعنی فقط وقتی پول می‌دی که کدت اجرا می‌شه.ویژگی‌های اصلی سرورلس این‌ها هستن:اجرای کد با رویدادها: کدت وقتی اجرا می‌شه که یه اتفاق خاص بیفته، مثلاً یه درخواست HTTP بیاد یا یه فایل آپلود بشه.مقیاس‌پذیری خودکار: اگه برنامه‌ات یه کاربر داشته باشه یا یه میلیون، سیستم خودش رو با تعداد کاربران تطبیق می‌ده.هزینه‌های بدون استفاده: توی مدل‌های قدیمی، حتی اگه از سرورها استفاده نکنی بازم باید پول بدی. ولی توی سرورلس فقط وقتی پول می‌دی که کدت اجرا بشه.بعضی از پلتفرم‌های معروف سرورلس عبارتند از: AWS Lambda، Azure Functions، Google Cloud Functions و Cloudflare Workers.سرورلس چطور کار می‌کنه؟سرورلس حول توابع کوچیک و مستقل می‌چرخه که بهشون می‌گن توابع به عنوان سرویس (FaaS). کارش به این صورته:کد می‌نویسی: یه تابع کوچیک می‌نویسی که یه کار خاص رو انجام بده.کد رو آپلود می‌کنی: کد رو به پلتفرم سرورلس می‌دی و اونجا خودش همه چیز رو راه‌اندازی می‌کنه.رویدادها تابع رو اجرا می‌کنن: مثلاً اگه یه درخواست HTTP بیاد یا یه فایل آپلود بشه، تابعت اجرا می‌شه.مقیاس‌پذیری خودکار: اگه تعداد درخواست‌ها زیاد بشه، سیستم خودش منابع رو اضافه می‌کنه.پرداخت فقط برای اجرا: فقط وقتی پول می‌دی که کدت اجرا بشه.چرا سرورلس انقلابی در توسعه ابریه؟۱. مدیریت ساده‌تر زیرساختتوی مدل‌های قدیمی، باید خودت سرورها رو تنظیم می‌کردی و نگهداری می‌کردی. ولی توی سرورلس، همه این کارها رو شرکت ابری انجام می‌ده و تو فقط روی کدت تمرکز می‌کنی.تأثیر: کارهای عملیاتی کمتر و توسعه سریع‌تر.مثال: یه استارت‌آپ می‌تونه یه برنامه وب رو بدون نیاز به تیم DevOps مستقر کنه.۲. صرفه‌جویی در هزینهتوی مدل‌های قدیمی، حتی اگه از سرورها استفاده نکنی بازم باید پول بدی. ولی توی سرورلس فقط وقتی پول می‌دی که کدت اجرا بشه.تأثیر: صرفه‌جویی زیاد در هزینه‌ها، مخصوصاً برای کارهایی که ترافیکشون متغیره.مثال: یه سایت فروشگاهی که فقط موقع حراج‌ها ترافیکش زیاد می‌شه، فقط همون موقع پول می‌ده.۳. مقیاس‌پذیری خودکارسرورلس خودش رو با تعداد کاربران تطبیق می‌ده. چه یه نفر از برنامه‌ات استفاده کنه، چه یه میلیون نفر، سیستم خودش رو تنظیم می‌کنه.تأثیر: برنامه‌ها حتی موقع ترافیک بالا هم کار می‌کنن.مثال: یه برنامه شبکه‌اجتماعی می‌تونه یه پست ویروسی رو بدون مشکل مدیریت کنه.۴. زمان سریع‌تر برای عرضه به بازاربا سرورلس، دیگه نیازی نیست وقتت رو صرف تنظیم سرورها کنی. فقط کدت رو بنویس و اجرا کن.تأثیر: تیم‌ها می‌تونن سریع‌تر کار کنن و محصولات رو زودتر به بازار برسونن.مثال: یه توسعه‌دهنده می‌تونه یه ویژگی جدید رو توی چند ساعت اضافه کنه.۵. معماری‌های مبتنی بر رویدادسرورلس برای برنامه‌هایی که با رویدادها کار می‌کنن خیلی خوبه. مثلاً وقتی یه فایل آپلود می‌شه یا یه درخواست HTTP میاد، کدت اجرا می‌شه.تأثیر: انعطاف‌پذیری بیشتر برای ساخت سیستم‌های ماژولار.مثال: یه تابع سرورلس می‌تونه بلافاصله بعد از آپلود یه عکس، اون رو پردازش کنه.۶. دسترسی جهانیسرورلس معمولاً به صورت جهانی کار می‌کنه، یعنی برنامه‌ات برای کاربران سراسر دنیا در دسترسه.تأثیر: کاربران از هر جای دنیا می‌تونن با سرعت خوبی از برنامه‌ات استفاده کنن.مثال: یه API سرورلس می‌تونه کاربران رو به نزدیک‌ترین سرور هدایت کنه تا سرعتشون بیشتر بشه.موارد استفاده از سرورلسسرورلس برای خیلی کارها خوبه، مثلاً:بک‌اند وب و موبایل:ساخت API برای احراز هویت کاربر یا پردازش پرداخت.مثال: یه API سرورلس برای یه برنامه فروشگاهی که هزاران کاربر رو مدیریت می‌کنه.گردش کار مبتنی بر رویداد:خودکارسازی کارهایی که با رویدادها شروع می‌شن، مثلاً وقتی یه کاربر جدید ثبت‌نام می‌کنه.مثال: یه تابع سرورلس که وقتی یه کاربر جدید میاد، یه ایمیل براش می‌فرسته.پردازش داده:پردازش داده‌های بزرگ به صورت بلادرنگ.مثال: یه تابع سرورلس که داده‌های دستگاه‌های IoT رو پردازش می‌کنه.وب‌سایت‌های سرورلس:میزبانی وب‌سایت‌های استاتیک با عملکرد بک‌اند.مثال: یه CMS سرورلس که محتوا رو به کاربران سراسر دنیا ارائه می‌ده.چت‌بات‌ها و هوش مصنوعی:ساخت چت‌بات یا استقرار مدل‌های هوش مصنوعی.مثال: یه چت‌بات سرورلس که به کاربران کمک می‌کنه.چالش‌های سرورلسبا وجود مزایای زیاد، سرورلس چالش‌هایی هم داره:شروع سرد (Cold Starts):وقتی تابعت بعد از مدتی غیرفعال بودن اجرا می‌شه، ممکنه یه تأخیر کوچیک داشته باشه.راه‌حل: از روش‌هایی برای گرم‌کردن توابع استفاده کن.وابستگی به شرکت‌ها (Vendor Lock-In):اگه از یه پلتفرم خاص استفاده کنی، ممکنه انتقال به یه پلتفرم دیگه سخت باشه.راه‌حل: از استانداردهای باز استفاده کن.اشکال‌زدایی و نظارت:اشکال‌زدایی برنامه‌های سرورلس می‌تونه سخت باشه.راه‌حل: از ابزارهای نظارت مثل AWS CloudWatch استفاده کن.محدودیت‌های اجرایی:توابع سرورلس محدودیت‌هایی در زمان اجرا و حافظه دارن.راه‌حل: کارها رو به توابع کوچیک‌تر تقسیم کن.چرا سرورلس آینده توسعه ابریه؟افزایش بهره‌وری: دیگه نیازی نیست وقتت رو صرف مدیریت سرورها کنی.صرفه‌جویی در هزینه: فقط وقتی پول می‌دی که کدت اجرا بشه.مقیاس‌پذیری خودکار: برنامه‌ات با هر تعداد کاربر کار می‌کنه.هم‌خوانی با معماری‌های مدرن: سرورلس با میکروسرویس‌ها و سیستم‌های مبتنی بر رویداد خیلی خوب کار می‌کنه.نوآوری مداوم: شرکت‌های ابری دائماً سرورلس رو بهتر می‌کنن.

چطور Web3 داره دنیای مهندسی نرم‌افزار رو عوض می‌کنه؟

JavadAgha — Fri, 24 Jan 2025 04:08:49 +0330

Web3، که به عنوان نسل بعدی اینترنت شناخته می‌شه، داره روش ساخت، اجرا و نگهداری نرم‌افزارها رو کاملاً تغییر می‌ده. برخلاف Web2 که بیشتر روی پلتفرم‌های متمرکز و واسطه‌ها تکیه داره، Web3 تمرکز رو روی غیرمتمرکز بودن، شفافیت و مالکیت جمعی از طریق فناوری‌هایی مثل بلاک‌چین می‌ذاره.برای مهندسای نرم‌افزار، این تغییر بزرگ هم چالش‌ها و هم فرصت‌های جدیدی ایجاد کرده. از ساخت برنامه‌های غیرمتمرکز (dApps) تا تغییر در طراحی سیستم‌ها، Web3 داره اساس مهندسی نرم‌افزار رو دگرگون می‌کنه. اما دقیقاً چه چیزی داره تغییر می‌کنه و مهندسا چطور باید خودشون رو برای این عصر جدید آماده کنن؟Web3 چیه؟Web3 در واقع اینترنتی غیرمتمرکزه که با فناوری بلاک‌چین کار می‌کنه. هدف اصلی‌ش اینه که کنترل رو از دست شرکت‌ها و پلتفرم‌های بزرگ بگیره و به دست کاربران و جامعه بسپاره. بعضی از اصول اصلی Web3 این‌ها هستن:غیرمتمرکز بودن: داده‌ها به جای اینکه روی سرورهای متمرکز ذخیره بشن، روی شبکه‌های بلاک‌چین پخش می‌شن.مالکیت: کاربران با استفاده از کیف‌پول‌های دیجیتال و کلیدهای رمزنگاری، مالک داده‌ها و دارایی‌های خودشون هستن.توکن‌سازی: توکن‌هایی مثل ارزهای دیجیتال یا NFTها، مدل‌های اقتصادی جدیدی ایجاد می‌کنن و مردم رو به مشارکت تشویق می‌کنن.قراردادهای هوشمند: این قراردادها خودکار هستن و بدون نیاز به واسطه، کارهایی مثل انتقال پول یا تأیید اطلاعات رو انجام می‌دن.قابلیت همکاری: برنامه‌های غیرمتمرکز (dApps) می‌تونن با همدیگه کار کنن و اطلاعات رو به راحتی بین خودشون جابه‌جا کنن.این اصول دارن صنایع مختلف مثل مالی (DeFi)، رسانه‌های اجتماعی، بازی‌ها (GameFi) و مدیریت زنجیره تأمین رو متحول می‌کنن.چطور Web3 داره مهندسی نرم‌افزار رو تغییر می‌ده؟۱. معماری غیرمتمرکزتوی مهندسی نرم‌افزار سنتی، همه چیز روی سرورهای متمرکز و فضای ابری اجرا می‌شد. اما Web3 از شبکه‌های غیرمتمرکز مثل Ethereum، Solana یا IPFS استفاده می‌کنه. این یعنی مهندسا باید روش طراحی سیستم‌ها رو عوض کنن.چالش: مدیریت سیستم‌های غیرمتمرکز سخت‌تره، چون هیچ مرکز کنترلی وجود نداره و باید مسائلی مثل تأخیر شبکه و امنیت رو در نظر گرفت.فرصت: سیستم‌های غیرمتمرکز امن‌تر و مقاوم‌تر هستن و کمتر در معرض سانسور قرار می‌گیرن.۲. قراردادهای هوشمند به جای بک‌اندقراردادهای هوشمند برنامه‌هایی هستن که روی بلاک‌چین اجرا می‌شن و کارهایی مثل انتقال پول یا تأیید اطلاعات رو خودکار می‌کنن. این‌ها نیاز به بک‌اند سنتی رو کم می‌کنن.چالش: نوشتن قراردادهای هوشمند نیاز به یادگیری زبان‌های خاصی مثل Solidity داره که ممکنه سخت باشه.فرصت: اگه توی این حوزه مهارت پیدا کنی، می‌تونی سیستم‌هایی بسازی که بدون نیاز به اعتماد به واسطه‌ها کار کنن.۳. اقتصاد توکن‌هاتوی Web3، خیلی از برنامه‌ها از توکن‌ها برای ایجاد اقتصادهای جدید استفاده می‌کنن. مهندسا باید با اقتصاددان‌ها همکاری کنن تا سیستم‌های عادلانه و پایدار طراحی کنن.چالش: طراحی سیستم‌های اقتصادی که از سوءاستفاده جلوگیری کنه، کار آسونی نیست.فرصت: می‌تونی سیستم‌هایی بسازی که به کاربران برای مشارکت پاداش بده.۴. امنیت خیلی مهمهتوی Web3، کد قانونه. یعنی اگه یه اشتباه توی کد باشه، به راحتی نمی‌شه درستش کرد. پس امنیت خیلی مهمه.چالش: اگه امنیت رعایت نشه، ممکنه ضررهای بزرگی اتفاق بیفته.فرصت: تخصص در امنیت Web3 می‌تونه خیلی پولساز باشه.۵. هویت و حریم خصوصیتوی Web3، کاربران کنترل هویت و داده‌های خودشون رو در دست دارن. مهندسا باید سیستم‌هایی طراحی کنن که هم حریم خصوصی رو حفظ کنن و هم با بقیه سیستم‌ها کار کنن.چالش: ایجاد تعادل بین حریم خصوصی و شفافیت کار آسونی نیست.فرصت: فناوری‌هایی مثل اثبات دانش صفر (ZKPs) می‌تونن حریم خصوصی رو بهتر حفظ کنن.۶. ابزارهای جدیدابزارها و فریم‌ورک‌های جدیدی برای ساخت برنامه‌های غیرمتمرکز در حال ظهور هستن.ابزارهای محبوب: Hardhat، Truffle، Web3.js و IPFS.چالش: همگام شدن با این ابزارهای جدید ممکنه سخت باشه.فرصت: اگه با این ابزارها کار کنی، می‌تونی برنامه‌های خیلی پیشرفته بسازی.۷. توسعه جامعه‌محورتوی Web3، خیلی از پروژه‌ها توسط جامعه مدیریت می‌شن. مهندسا باید یاد بگیرن چطور توی این محیط‌های مشارکتی کار کنن.چالش: تصمیم‌گیری‌های غیرمتمرکز ممکنه کند باشه.فرصت: می‌تونی توی پروژه‌های متن‌باز مشارکت کنی و حتی برای کارت توکن دریافت کنی.۸. قابلیت همکاریتوی Web3، برنامه‌ها و بلاک‌چین‌های مختلف باید بتونن با هم کار کنن. مهندسا باید سیستم‌هایی طراحی کنن که از استانداردهای باز پیروی کنن.چالش: ایجاد همکاری بین بلاک‌چین‌های مختلف کار سختیه.فرصت: مهندسای پروتکل‌ها تقاضای زیادی دارن.نقش‌های جدید توی Web3Web3 نقش‌های جدیدی برای مهندسا ایجاد کرده، مثل:توسعه‌دهنده قراردادهای هوشمند: کسی که قراردادهای هوشمند می‌نویسه.مهندس پروتکل بلاک‌چین: کسی که روی ساخت و بهبود بلاک‌چین‌ها کار می‌کنه.توسعه‌دهنده dApp: کسی که برنامه‌های غیرمتمرکز می‌سازه.حسابرس امنیت: کسی که امنیت سیستم‌های Web3 رو بررسی می‌کنه.طراح اقتصاد توکن‌ها: کسی که مدل‌های اقتصادی برای توکن‌ها طراحی می‌کنه.مهندس اثبات دانش صفر: کسی که روی فناوری‌های حفظ حریم خصوصی کار می‌کنه.چالش‌ها و ریسک‌های Web3با اینکه Web3 فرصت‌های زیادی داره، اما چالش‌هایی هم داره:مقیاس‌پذیری: شبکه‌های فعلی بلاک‌چین کند هستن.مصرف انرژی: بعضی بلاک‌چین‌ها انرژی زیادی مصرف می‌کنن.قوانین نامشخص: دولت‌ها هنوز نمی‌دونن چطور با Web3 برخورد کنن.تجربه کاربری: برنامه‌های Web3 گاهی کاربرپسند نیستن.چطور برای Web3 آماده بشیم؟یادگیری بلاک‌چین: بفهم بلاک‌چین چطور کار می‌کنه.تسلط بر ابزارها: با ابزارهایی مثل Solidity و Web3.js کار کن.مشارکت در پروژه‌های متن‌باز: توی پروژه‌های باز مشارکت کن.به‌روز بمان: اخبار Web3 رو دنبال کن.نمونه کار بساز: برنامه‌های غیرمتمرکز یا قراردادهای هوشمند بساز.

درخت مرکل و بلاکچین

JavadAgha — Mon, 02 Sep 2024 00:31:38 +0330

درخت ‏مرکل (Merkle Tree) که به آن هش تری (hash tree) نیز گفته می‌شود، یک ساختار داده‌ای بنیادی در تکنولوژی بلاکچین است. این ساختار برای بررسی کارآمد و امن یکپارچگی و انسجام داده‌ها استفاده می‌شود. در زمینه بلاکچین،درختان مرکل نقش مهمی در اطمینان از عدم دستکاری داده‌های بلاک‌ها ایفا می‌کنند.ساختار درخت مرکلیک درخت دودویی (binary tree) است که در آن:۱. گره‌های برگ (Leaf Nodes): گره‌های پایین‌ترین قسمت درخت که به آنها گره‌های برگ گفته می‌شود، شامل هش داده‌ها (مثل تراکنش‌ها در بلاکچین) هستند.‏۲. گره‌های غیر برگ (Non-Leaf Nodes): بالای گره‌های برگ، هر گره والد، هش دو گره فرزند خود است. این فرآیند تا بالای درخت ادامه می‌یابد.۳. گره ریشه (Merkle Root): بالاترین گره درخت که به آن مرکل روت گفته می‌شود، هش نهایی است که نماینده کل مجموعه داده است. این هش نهایی یک نمایش فشرده و منحصربه‌فرد از تمامی داده‌های درخت است.درخت مرکل چگونه کار می‌کند؟هش کردن داده‌ ها:1.هر قطعه داده (مثلاً یک تراکنش در یک بلاک) به صورت جداگانه هش می‌شود تا گره‌های برگ درخت مرکل ایجاد شوند. هشینگ یک تابع یک‌طرفه است که داده‌ها را به یک رشته کاراکتر با اندازه ثابت تبدیل می‌کند که برای داده اصلی منحصربه‌فرد است.ساختن درخت:گره‌های برگ سپس به صورت جفت جفت با هم ترکیب می‌شوند و هر جفت با هم هش می‌شوند تا یک گره جدید ایجاد شود. این فرآیند به صورت تکراری ادامه می‌یابد، گره‌های به‌دست‌آمده دوباره با هم جفت می‌شوند و هش می‌شوند تا به بالای درخت برسید که در آن فقط یک گره باقی می‌ماند: مرکل روت.برای مثال، اگر چهار تراکنش داشته باشید، ابتدا هر تراکنش را هش می‌کنید تا چهار گره برگ ایجاد شود. سپس این گره‌های هش‌شده را با هم جفت کرده و دوباره هش می‌کنید تا دو گره جدید ساخته شود. در نهایت، این دو گره دوباره هش می‌شوند تا یک گره واحد، یعنی مرکل روت، ایجاد شود.تایید:برای تأیید اینکه یک قطعه خاص از داده (مثل یک تراکنش) بخشی از درخت مرکل است، تنها کافی است هش آن داده و هش‌های گره‌های مسیر تا ریشه را بدانید. این بدان معنی است که نیازی به دانلود یا بررسی کل مجموعه داده نیست، که تأیید را بسیار کارآمد می‌سازد.برای مثال، برای اثبات اینکه یک تراکنش در یک بلاک گنجانده شده است، شما یک "Merkle proof" ارائه می‌دهید که شامل هش تراکنش و سری‌ای از هش‌ها است که برای بازسازی مرکل روت لازم است. اگر ریشه بازسازی‌شده با ریشه شناخته‌شده مطابقت داشته باشد، تراکنش تأیید می‌شود که بخشی از بلاک است.اهمیت درختان مرکل در بلاکچینتأیید کارآمد داده‌هادرختان مرکل امکان تأیید سریع و کارآمد داده‌ها را فراهم می‌کنند. به جای بررسی مجدد کل مجموعه تراکنش‌ها، تنها نیاز است که یک زیرمجموعه کوچک بررسی شود که به طور قابل توجهی بار محاسباتی را کاهش می‌دهد.اثبات یکپارچگیمرکل روت در هدر بلاک ذخیره می‌شود و چون این روت به طور منحصربه‌فرد نماینده تمامی تراکنش‌های بلاک است، هر گونه تغییر در یک تراکنش موجب تغییر در مرکل روت می‌شود. این امر تشخیص دستکاری را آسان می‌سازد.قابلیت مقیاس‌پذیریدرختان مرکل به مقیاس‌پذیری بلاکچین کمک می‌کنند، به‌ویژه در مورد کلاینت‌های سبک (light clients). یک کلاینت سبک می‌تواند یک تراکنش را بدون نیاز به دانلود کل بلاکچین تأیید کند، با استفاده از Merkle proofها.امنیتویژگی‌های رمزنگاری هش‌های استفاده شده در درختان مرکل تضمین می‌کند که این ساختار امن باشد. هر گونه تغییر در داده‌های ورودی (حتی کوچک‌ترین تغییر) منجر به تولید یک هش کاملاً متفاوت می‌شود، که این امر باعث می‌شود دستکاری داده‌ها بدون تشخیص تقریباً غیرممکن باشد.مثال در بیت‌کوینهر بلاک شامل یک Merkle root در هدر خود است.تراکنش‌های موجود در بلاک هش شده و در قالب یک درخت مرکل سازمان‌دهی می‌شوند.زمانی که یک نود در شبکه می‌خواهد یک تراکنش را تأیید کند، از درخت مرکل برای انجام این کار به صورت کارآمد استفاده می‌کند، بدون اینکه نیازی به دانلود کل بلاک باشد.

انواع تست API

JavadAgha — Sat, 08 Jun 2024 01:49:06 +0330

تست API فرآیندی است که برای اطمینان از عملکرد صحیح و ایمن API ها انجام می شود. در این بخش، 9 نوع رایج از تست API را بررسی می کنیم: 1. تست دود (Testing Smoke): این تست پس از تکمیل توسعه API انجام می شود. در این تست به سادگی بررسی می شود که آیا API ها کار می کنند و مشکلی وجود ندارد.2. تست عملکردی (Testing Functional): این تست بر اساس الزامات عملکردی، یک برنامه تست ایجاد می کند و نتایج را با نتایج مورد انتظار مقایسه می کند.3. تست یکپارچه سازی (Testing Integration): این تست، چندین فراخوانی API را برای انجام تست های سرتاسری ترکیب می کند. در این تست، ارتباطات درون سرویس و انتقال داده ها مورد بررسی قرار می گیرد.4. تست رگرسیون (Testing Regression): این تست اطمینان می دهد که رفع اشکال یا ویژگی های جدید نباید باعث خرابی رفتارهای موجود در API ها شوند.5. تست بار (Testing Load): این تست عملکرد برنامه را با شبیه سازی بارهای مختلف مورد بررسی قرار می دهد. سپس با کمک این تست می توان ظرفیت برنامه را محاسبه کرد.6. تست استرس (Testing Stress): این تست به عمد، بارهای بالایی را روی API ها ایجاد می کند و بررسی می کند که آیا API ها قادر به عملکرد عادی هستند یا خیر.7. تست امنیتی (Testing Security): این تست، API ها را در برابر تمام تهدیداتخارجی احتمالی مورد بررسی قرار می دهد.8. تست رابط کاربری (Testing UI): این تست، تعامل رابط کاربری با API ها را آزمایش می کند تا اطمینان حاصل شود که داده ها به درستی نمایش داده می شوند.9. تست تزریق داده مخرب (Testing Fuzz): این تست، داده های ورودی نامعتبر یا غیرمنتظره را به API تزریق می کند و سعی می کند API را خراب کند. به این ترتیب، آسیب پذ یری های API شناسایی می شوند.منبع : system-design.ir

بررسی معماری های N-Tier

JavadAgha — Sat, 08 Jun 2024 00:46:25 +0330

معماری چندلایه (tier-N )یک برنامه ی نرم افزاری را به لایه های منطقی و طبقات فیزیکی تقسیم می کند. لایه ها روشی برای جداسازی مسئولیت ها و مدیریت وابستگی ها هستند. هر لایه وظیفه خاصی دارد. یک لایه بالاتر می تواند از سرویس های لایه پایین تر استفاده کند، اما برعکس این موضوع امکانپذیر نیست.لایه ها از نظر فیزیکی جدا شده اند و روی ماشین های جداگانه ای اجرا می شوند. یک لایه می تواند مستقیماً به لایه دیگر فراخوانی بزند یا از پیامرسان ی ناهمزمان (asynchronous messaging) استفاده کند. اگرچه ممکن است هر لایه در طبقه خاص خود میزبانی شود، اما اجباری در این کار نیست.چندین لایه ممکن است روی یک لایه می زبانی شوند. جداسازی فیزیکی طبقات، مقیاسپذیری و انعطاف پذ یر ی را بهبود می بخشد، اما تأخیر ناشی از ارتباطات اضافی شبکه را نیز به همراه دارد. یک معماری چند لایه می تواند از دو نوع باشد: معماری لایه بسته (Closed Layer Architecture): در این نوع، یک لایه فقط می تواند لایه بعدی را که مستقیماً پایین تر از آن است را فراخوانی کند.معماری لایه باز(Open Layer Architecture) : در این نوع، یک لایه می تواند هر یک از لایه پایین تر از خود را فراخوانی کند. معماری لایه بسته وابستگی های بین لایه ها را محدود می کند. با این حال، ممکن است ترافیک شبکه غیرضروری ایجاد کند و این مورد به خصوص زمانی که یک لایه به سادگی درخواست ها را به لایه بعدی منتقل می کند، اهمیت می یابد. بیایید به چند نمونه از معماری های چند لایه را بررسی کنیم: معماری سه لایه : معماری سه لایه به طور گسترده مورد استفاده قرار میگیرد و از لایه های مختلف زیر تشکیل شده است:لایه نمایش( Presentation layer) : با تعامالت کاربر با برنامه سروکار دارد.لایه منطق کسب و کار (Presentation layer): داده ها را از لایه نمایش دریافت می کند، طبق منطق کسب و کار اعتبارسنجی می کند و به لایه داده منتقل می کند.لایه دسترسی به داده (Data Access layer): داده ها را از لایه منطق کسب و کار دریافت میکند و عملیات لازم را روی پایگاه داده انجام میدهد.معماری دو لایه : در این معماری، لایه نمایش روی کالینت اجرا میشود و با یک بانک اطالعاتی ارتباط برقرار می کند. هیچ لایه منطق کسب و کار یا لایه دیگری بین کالینت و سرور وجود ندارد.معماری تک لایه: این نوع ساده ترین معماری است، زیرا معادل اجرای برنامه روی یک رایانه شخصی است. تمام اجزای مورد نیاز برای اجرای یک برنامه در یک برنامه یا سرور واحد قرار دارند.مزایا: در اینجا برخی از مزایای استفاده از معماری چندلایه آورده شده است: میتواند پارامترهای در دسترس بودن(availability) را بهبود بخشد.سطح امنیت بهتری به همراه می آورد زیرا لایه ها میتوانند مانند فایروال عمل کنند.امکان مقیاسپذیری(scale) لایه های مجزا در صورت نیاز را فراهم می کند.پارامترهای نگهداری از برنامه را بهبود می بخشد زیرا افراد مختلف می توانند لایه ها ی مختلف را مدیریت کنند.معا یب:در زیر برخی از معایب استفاده از معماری چندلایه آورده شده است:افزایش پیچیدگی در کل سیستم.افزایش تأخیر شبکه با افزایش تعداد لایه ها.پرهزینه بودن به دلیل اینکه هر لایه هزینه سخت افزاری خاص خود را دارد.مدیریت امنیت شبکه دشوار است.منبع : system-design.ir

API gateway چه کاری انجام می دهد؟

JavadAgha — Fri, 07 Jun 2024 16:15:39 +0330

Gateway API یک ابزار مدیریت API است که بین یک سرویس client و مجموعه‌ای از سرویس‌های backend قرار می‌گیرد. این یک نقطه‌ی ورود واحد به سیستمی است که معماری داخلی سیستم را در بر می‌گیرد و یک API ارائه می‌دهد که برای هر سرویس client متناسب‌سازی شده است. همچنین مسئولیت‌های دیگری مانند احراز هویت(authentication)، مانیتورینگ، توزیع بار، کش(caching)، محدودکردن سرعت(throttling)، الگوگیری(logging) و غیره را بر عهده دارد.چرا به Gateway API نیاز داریم؟جزئیات APIهایی که توسط میکروسرویس‌ها ارائه می‌شوند، اغلب با نیازهای یک سرویس‌گیرنده متفاوت است. میکروسرویس‌ها معمولاً APIهای با جزئیات دقیق ارائه می‌دهند، به این معنی که سرویس‌گیرنده‌ها باید با چندین سرویس تعامل داشته باشند. ازاین‌رو، یک دروازهٔ API می‌تواند یک نقطه‌ی ورود واحد برای همه سرویس‌گیرنده‌ها با برخی ویژگی‌های اضافی و مدیریت بهتر ارائه دهد.ویژگی‌هاAuthorizationو AuthenticationService discoveryReverse ProxyCachingSecurityRetry and Circuit breakingLoad balancingLogging, TracingAPI compositionRate limiting and throttlingVersioningRoutingblacklisting یا IP whitelistingشکل زیر جزئیات را نشان می‌دهد.مرحله1- client یک درخواست HTTP به دروازه API ارسال می کند.مرحله 2- gateway API ویژگیهای موجود در درخواستهای HTTP را تجزیه و اعتبارسنجی می کند. مرحله 3- gateway API بررسی های لیست مجاز/لیست سیاه را انجام می دهد. مرحله 4 - gateway API برای احراز هویت (authentication) و مجوز دادن (authorization) با یک ارائه دهنده اعتبار صحبت می کندمرحله 5 - قوانین محدودیت نرخ (rate limiting) روی درخواست ها اعمال می شود. در صورت عبور از حد مجاز، درخواست رد می شود.مراحل 6 و 7 - اکنون که درخواست بررسی های اولیه را پشت سر گذاشته است،gateway API با مطابقت مسیر، سرویس مرتبط را برای مسیریابی پیدا میکند.مرحله 8 - gateway API درخواست را به پروتکل مناسب تبدیل می کند و آن را به میکروسرویس های backend ارسال می کند.مراحل 9 تا :12 gateway API می تواند خطاها را به درست ی مدیریت کند و در صورت نیاز به زمان بیشتر برا ی بازی ابی به کمک breaker circuit با خرابی ها مقابله کند.همچنین می تواند از ساختار (Kibana-Logstash-Elastic (ELK برای الگو گیری ومانیتورینگ استفاده کند. همچنین گاهی اوقات داده ها را در gateway API کَش می کنیم.منبع: system-design.ir

یکپارچگی در سیستم‌های توزیع‌شده

JavadAgha — Thu, 30 May 2024 01:13:15 +0330

یکپارچگی در سیستم‌های توزیع‌شده به توانایی یک سیستم توزیع‌شده برای حفظ یک وضعیت منسجم و قابل‌اعتماد در سراسر اجزای چندگانه یا گره‌های آن اشاره دارد. در یک سیستم توزیع‌شده، داده‌ها و محاسبات اغلب در سراسر چندین گره همگام‌سازی و توزیع می‌شوند تا دسترس‌پذیری، مقیاس‌پذیری و تحمل خرابی را به دست آورند. با این حال، این توزیع داده‌ها و محاسبات می‌تواند چالش‌هایی را در حفظ یکپارچگی ایجاد کند.اینجا جنبه‌های کلیدی یکپارچگی در سیستم‌های توزیع‌شده آورده شده است:1. یکپارچگی داده: یکپارچگی داده به توانایی سیستم توزیع‌شده برای اطمینان از اینکه همه همگام‌ساز‌های همان آیتم داده همان مقدار را در هر زمان داشته باشند اشاره دارد. این برای جلوگیری از واگرایی داده و اطمینان از اینکه کلاینت ها داده صحیح و به‌روز را با توجه به گره‌ای که با آن تعامل دارند، دریافت می‌کنند مهم است. دستیابی به یکپارچگی داده در یک سیستم توزیع‌شده به دلیل عواملی مانند شکاف‌های شبکه، خرابی گره و همگام‌سازی داده‌های آسنکرون چالش‌برانگیز است.2. مدل‌های یکپارچگی: سیستم‌های توزیع‌شده می‌توانند مدل‌های یکپارچگی مختلفی را پیاده‌سازی کنند، که هر کدام تعادل های خود را بین یکپارچگی، دسترس‌پذیری و تحمل شکاف (مطابق با قضیه CAP) دارند. مدل‌های یکپارچگی اصلی شامل یکپارچگی قوی (مانند خطی‌سازی)، یکپارچگی تدریجی و یکپارچگی ضعیف است. انتخاب مدل یکپارچگی به نیازهای برنامه، مانند نیاز به یکپارچگی داده، تحمل ناسازگاری موقت و اهمیت دسترس‌پذیری و تحمل شکاف بستگی دارد.3. پروتکل‌های یکپارچگی:سیستم‌های توزیع‌شده اغلب از پروتکل‌ها و الگوریتم‌های مختلفی برای تضمین یکپارچگی داده استفاده می‌کنند، مانند:پروتکل‌های توافق (مانند Paxos، Raft) برای دستیابی به توافق بین گره‌ها در مورد وضعیت سیستم.پروتکل‌های همگام‌سازی (مانند primary-backup، quorum-based) برای حفظ همگام‌سازی همگام‌سازهای داده.مکانیزم‌های کنترل همزمانی (مانند قفل‌گذاری، کنترل همزمانی خوشبینانه) برای مدیریت دسترسی همزمان به داده‌های مشترک.4. Trade-offs یکپارچگی و دسترس‌پذیری:قضیه CAP بیان می‌کند که در یک سیستم توزیع‌شده، می‌توانید فقط دو تا از سه ویژگی یکپارچگی، دسترس‌پذیری و تحمل شکاف را به دست آورید.سیستم‌های توزیع‌شده باید این بده بستان ها را بر اساس نیازهای برنامه و سناریوهای شکست مورد انتظار متعادل کنند.به عنوان مثال، سیستمی که بر یکپارچگی و تحمل شکاف تمرکز دارد ممکن است دسترس‌پذیری را فدا کند، در حالی که سیستمی که بر دسترس‌پذیری و تحمل شکاف تمرکز دارد ممکن است از یکپارچگی قوی صرف‌نظر کند.5. یکپارچگی تدریجی و حل تعارض:در برخی سیستم‌های توزیع‌شده، مانند پایگاه‌های داده NoSQL، تمرکز بر دستیابی به دسترس‌پذیری و تحمل شکاف بالا است، اغلب با قربانی کردن یکپارچگی قوی.این سیستم‌ها ممکن است از مدل‌های یکپارچگی تدریجی استفاده کنند، جایی که داده‌ها در نهایت به یک وضعیت یکپارچه همگرا می‌شوند، اما ممکن است ناسازگاری‌های موقت در طی فرایند همگرایی وجود داشته باشد.در چنین مواردی، سیستم باید مکانیزم‌هایی برای شناسایی و حل تعارضاتی که ممکن است به دلیل به‌روزرسانی‌های همزمان ایجاد شوند، مانند انواع داده‌های همگام‌سازی‌شده عاری از تعارض (CRDTs) یا تحول عملیاتی داشته باشد.حفظ یکپارچگی در سیستم‌های توزیع‌شده یک چالش پیچیده است و راه‌حل‌های خاص و trade-offs آن به نیازهای برنامه، سناریوهای شکست مورد انتظار و منابع موجود بستگی دارد. درک و مدیریت دقیق یکپارچگی برای ساخت سیستم‌های توزیع‌شده قابل‌اعتماد و مقیاس‌پذیر بسیار مهم است.برای مثال، سرویس Amazon S3 (Simple Storage Service) از یک مدل داده‌ای یکپارچگی تدریجی استفاده می‌کند، که به این معنی است که پس از به‌روزرسانی یک شیء، نسخه جدید ممکن است فوراً برای همه کاربران قابل مشاهده نباشد. این مدل یکپارچگی تدریجی به S3 امکان می‌دهد تا دسترس‌پذیری و تأخیر کم را ارائه دهد، زیرا به‌روزرسانی‌ها می‌توانند به صورت آسنکرون به چندین همگام‌ساز منتشر شوند. trade-off این است که ممکن است مدت کوتاهی وجود داشته باشد که کاربران مختلف نسخه‌های متفاوتی از همان شیء را ببینند، اما این معمولاً برای بیشتر موارد استفاده مشکل‌ساز نیست.از سوی دیگر، پایگاه‌های داده رابطه‌ای سنتی مانند MySQL و PostgreSQL مدل داده‌ای یکپارچگی قوی را ارائه می‌دهند. در یک پایگاه داده رابطه‌ای، همه خواندن‌ها و نوشتن‌ها اتمی، قابل‌سریالیزه و خطی‌سازی هستند، که تضمین می‌کند داده همیشه در یک وضعیت معتبر باشد. این مدل یکپارچگی قوی برای برنامه‌هایی که یکپارچگی داده حیاتی است، مانند معاملات مالی، سیستم‌های بانکی و سیستم‌های برنامه‌ریزی منابع سازمانی (ERP) حیاتی است. trade-off برای یکپارچگی قوی این است که این سیستم‌ها ممکن است دسترس‌پذیری پایین‌تر و تأخیر بالاتری نسبت به سیستم‌های یکپارچگی تدریجی یا ضعیف داشته باشند، زیرا باید اطمینان حاصل کنند که همه همگام‌سازها قبل از تکمیل یک عملیات همگام هستند.در زمینه مدل‌های یکپارچگی در سیستم‌های توزیع‌شده، سه نوع اصلی از تضمین‌های یکپارچگی وجود دارد: یکپارچگی تدریجی، یکپارچگی ضعیف و یکپارچگی قوی. توضیحی در مورد هر کدام ارائه می‌شود:Eventual Consistency1. یکپارچگی تدریجی: یکپارچگی تدریجی یک مدل یکپارچگی است که در آن سیستم تضمین می‌کند اگر هیچ به‌روزرسانی جدیدی برای یک آیتم داده خاص انجام نشود، در نهایت همه دسترسی‌ها به آن آیتم آخرین مقدار به‌روزرسانی شده را برمی‌گرداند. در یک سیستم دارای یکپارچگی تدریجی، به‌روزرسانی‌ها ممکن است به همگام‌سازها به صورت آسنکرون انتشار یابند و ممکن است مدت زمانی وجود داشته باشد که همگام‌سازهای مختلف مقادیر متفاوتی برای همان آیتم داده داشته باشند. یکپارچگی تدریجی دسترس‌پذیری و تحمل شکاف (مطابق با قضیه CAP) را بر یکپارچگی قوی اولویت می‌دهد، که آن را برای سیستم‌هایی که می‌توانند ناسازگاری‌های موقت را تحمل کنند مناسب می‌سازد، مانند حافظه پنهان توزیع‌شده، شبکه‌های تحویل محتوا و برخی انواع پایگاه‌های داده (مانند پایگاه‌های داده NoSQL). Dynamo ،Cassandra و Riak از جمله مثال‌های سیستم‌های دارای یکپارچگی تدریجی هستند.Weak Consisteny2. یکپارچگی ضعیف: یکپارچگی ضعیف یک مدل یکپارچگی است که در آن سیستم تضمینی برای ترتیب خاصی از عملیات یا سطح خاصی از یکپارچگی ندارد. در یک سیستم دارای یکپارچگی ضعیف، خواندن‌ها و نوشتن‌ها ممکن است مقادیر دلخواهی را برگردانند و سیستم ممکن است تضمین نکند که همه همگام‌سازها در هر زمان داده یکسانی داشته باشند. یکپارچگی ضعیف دسترس‌پذیری و سرعت را بر یکپارچگی قوی اولویت می‌دهد، که آن را برای سیستم‌هایی که می‌توانند برخی سطح از ناسازگاری را تحمل کنند مناسب می‌سازد، مانند حافظه پنهان، شبکه‌های تحویل محتوا و برنامه‌های همکاری آنلاین آنیStrong Consistency3. یکپارچگی قوی: یکپارچگی قوی یک مدل یکپارچگی است که در آن سیستم تضمین می‌کند که همه خواندن‌ها و نوشتن‌ها اتمی، قابل‌سریالیزه و خطی‌سازی هستند. در یک سیستم دارای یکپارچگی قوی، همه همگام‌سازهای یک آیتم داده در هر زمان مقدار یکسانی دارند و همه عملیات در یک ترتیب مشخص اجرا می‌شوند. یکپارچگی قوی یکپارچگی را بر دسترس‌پذیری و تحمل شکاف (مطابق با قضیه CAP) اولویت می‌دهد، که آن را برای سیستم‌هایی که به یکپارچگی داده بالایی نیاز دارند مناسب می‌سازد، مانند سیستم‌های بانکی، معاملات مالی و زیرساخت‌های حیاتی. مثال‌هایی از سیستم‌های دارای یکپارچگی قوی شامل پایگاه‌های داده رابطه‌ای سنتی مانند MySQL و PostgreSQL، همچنین پروتکل‌های توافق توزیع‌شده مانند Raft و Paxos هستند.انتخاب بین یکپارچگی تدریجی، ضعیف یا قوی به نیازهای خاص سیستم بستگی دارد، مانند سطح یکپارچگی مورد نیاز، نیازهای دسترس‌پذیری و مقیاس‌پذیری و میزان تحمل ناسازگاری‌های موقت. در عمل، بسیاری از سیستم‌های توزیع‌شده از ترکیبی از این مدل‌های یکپارچگی استفاده می‌کنند، با استفاده از یکپارچگی قوی‌تر برای عملیات حیاتی و یکپارچگی ضعیف‌تر برای بخش‌های کم‌اهمیت‌تر یا مقیاس‌پذیرتر سیستم.بیایید به برخی از مثال‌های واقعی از این مدل‌های یکپارچگی نگاه کنیم:1. یکپارچگی تدریجی: مثال: Amazon S3 (Simple Storage Service) Amazon S3 یک سرویس ذخیره‌سازی شیء با قابلیت مقیاس‌پذیری و دوام بالا است که توسط Amazon Web Services (AWS) ارائه می‌شود. S3 از یک مدل داده‌ای یکپارچگی تدریجی استفاده می‌کند، که به این معنی است که پس از به‌روزرسانی یک شیء، نسخه جدید ممکن است فوراً برای همه کاربران قابل مشاهده نباشد. این مدل یکپارچگی تدریجی به S3 امکان می‌دهد تا دسترس‌پذیری بالا و تأخیر کم را ارائه دهد، زیرا به‌روزرسانی‌ها می‌توانند به صورت آسنکرون به چندین همگام‌ساز منتشر شوند. trade-off این است که ممکن است مدت کوتاهی وجود داشته باشد که کاربران مختلف نسخه‌های متفاوتی از همان شیء را ببینند، اما این معمولاً برای بیشتر موارد استفاده مشکل‌ساز نیست. S3 به طور گسترده برای ذخیره‌سازی و ارائه محتوای ایستا، پشتیبان‌گیری و سایر انواع داده‌ای که در آن‌ها یکپارچگی تدریجی قابل قبول است استفاده می‌شود.2. یکپارچگی ضعیف:مثال: Memcached Memcached یک داده‌ستور توزیع‌شده و در حافظه موقت منبع‌باز است که برای حافظه پنهان‌سازی داده و اشیاء استفاده می‌شود. Memcached یک مدل یکپارچگی ضعیف را ارائه می‌دهد، جایی که خواندن‌ها و نوشتن‌ها ممکن است مقادیر دلخواهی را برگردانند و هیچ تضمینی برای ترتیب خاصی از عملیات وجود ندارد. این مدل یکپارچگی ضعیف به Memcached امکان می‌دهد تا دسترسی بسیار سریع به داده‌های حافظه پنهان را ارائه دهد، زیرا نیازی به اعمال تضمین‌های یکپارچگی قوی ندارد. Memcached به طور معمول به عنوان لایه حافظه پنهان در برنامه‌های وب استفاده می‌شود، جایی که trade-off بین یکپارچگی و عملکرد قابل قبول است، زیرا داده‌های حافظه پنهان را می‌توان به راحتی تازه‌سازی یا باطل کرد.3. یکپارچگی قوی: مثال: پایگاه‌های داده رابطه‌ای (مانند MySQL، PostgreSQL) پایگاه‌های داده رابطه‌ای سنتی مانند MySQL و PostgreSQL یک مدل داده‌ای یکپارچگی قوی را ارائه می‌دهند. در یک پایگاه داده رابطه‌ای، همه خواندن‌ها و نوشتن‌ها اتمی، قابل‌سریالیزه و خطی‌سازی هستند، که تضمین می‌کند داده همیشه در یک وضعیت معتبر باشد. این مدل یکپارچگی قوی برای برنامه‌هایی که به یکپارچگی داده نیاز دارند، مانند معاملات مالی، سیستم‌های بانکی و سیستم‌های برنامه‌ریزی منابع سازمانی (ERP) حیاتی است. trade-off برای یکپارچگی قوی این است که این سیستم‌ها ممکن است دسترس‌پذیری پایین‌تر و تأخیر بالاتری نسبت به سیستم‌های یکپارچگی تدریجی یا ضعیف داشته باشند، زیرا باید اطمینان حاصل کنند که همه همگام‌سازها قبل از تکمیل یک عملیات همگام هستند. پایگاه‌های داده رابطه‌ای به طور گسترده در کاربردهای حیاتی که در آن‌ها یکپارچگی داده از اهمیت فوق‌العاده برخوردار است و trade-off دسترس‌پذیری و تأخیر قابل قبول است استفاده می‌شوند.این مثال‌ها نشان می‌دهند که چگونه انتخاب مدل یکپارچگی در یک سیستم توزیع‌شده به نیازهای خاص برنامه و trade-offs بین یکپارچگی، دسترس‌پذیری و تحمل شکاف بستگی دارد. توسعه‌دهندگان باید این trade-offs را به دقت در نظر بگیرند هنگام طراحی و پیاده‌سازی سیستم‌های توزیع‌شده تا اطمینان حاصل کنند که سیستم نیازهای مورد نیاز مورد استفاده خود را برآورده می‌کند.

چگونه رستوران‌های نزدیک را در سرویس پیشنهاد رستوران پیدا می‌کنیم؟

JavadAgha — Mon, 20 May 2024 01:26:17 +0330

در مورد سرویس پیشنهاد رستوران در اینجا جزئیات طراحی پشت صحنه را مشاهده می‌کنید. دو سرویس کلیدی وجود دارند (مانند شکل زیر):سرویس کسب و کار.اضافه کردن/حذف کردن/ویرایش اطلاعات رستوران.مشتریان می‌توانند جزئیات رستوران را مشاهده کنند.سرویس مبتنی بر محل (𝐋𝐨𝐜𝐚𝐥-𝐛𝐚𝐬𝐞𝐝 𝐒𝐞𝐫𝐯𝐢𝐜𝐞/LBS).با در نظر گرفتن ناحیه و مکان، لیستی از رستوران‌های نزدیک را برمی‌گرداند.چگونه اطلاعات مربوط به مکان رستوران‌ها در پایگاه داده ذخیره می‌شوند تا LBS بتواند به طور کارآمد رستوران‌های نزدیک را بر‌گرداند؟اطلاعات مکانی (عرض و طول جغرافیایی) رستوران‌ها را در پایگاه داده ذخیره کنیم؟در صورتی که بخواهیم فاصله شما تا هر رستوران را محاسبه کنیم، کوئری‌هایِ پایگاه داده بسیار ناکارآمد خواهند بود.یک راه برای افزایش سرعت جستجو، استفاده از الگوریتم 𝐠𝐞𝐨𝐡𝐚𝐬𝐡است.ابتدا، کره زمین را به چهار ناحیه تقسیم می‌کنیم با توجه به خط استوا و خط طول اولیه آن داریم:بازه عرض جغرافیایی [۹۰-، 0] با عدد 0 نشان داده می‌شودبازه عرض جغرافیایی [0، 90] با عدد 1 نشان داده می‌شودبازه طول جغرافیایی [180-، 0] با عدد 0 نشان داده می‌شودبازه طول جغرافیایی [0، 180] با عدد 1 نشان داده می‌شودسپس هر گره را به چهار گره کوچکتر تقسیم می‌کنیم.هر گره می‌تواند با جابجایی بین بیت طول جغرافیایی و بیت عرض جغرافیایی نشان داده شود.بنابراین، وقتی می‌خواهید رستوران‌های نزدیک در بلوک مشخص شده با رنگ قرمز را جستجو کنید، می‌توانید SQL مشابه زیر را بنویسید:SELECT * FROM geohash_index WHERE geohash LIKE '01%' جغرافیای کد (Geohash) برخی محدودیت‌ها دارد. ممکن است در یک بلوک (مانند مرکز شهر نیویورک) بسیاری از رستوران‌ها وجود داشته باشد، اما در بلوک دیگر (مانند اقیانوس) هیچ رستورانی وجود نداشته باشد. بنابراین، الگوریتم‌های پیچیده‌تر دیگری برای بهینه‌سازی فرآیند وجود دارند. اگر علاقه‌مند به جزئیات هستید، می‌توانید در این موارد بیشتر مطالعه کنید.

Quadtree

JavadAgha — Mon, 20 May 2024 01:06:52 +0330

در این پست، بیایید ساختار داده دیگری را برای یافتن رستوران‌های نزدیک در اپلیکیشن سفارش غذا یا Google Maps بررسی کنیم.Quadtree یک ساختار داده است که معمولاً برای تقسیم یک فضای دو بعدی با تقسیم مجدد آن به چهار ربع (grids) تا زمانی که محتویات گریدها معیارهای خاصی را برآورده کنند، استفاده می‌شود (نمودار اول را ببینید).Quadtree یک ساختار داده درون حافظه (𝐢𝐧-𝐦𝐞𝐦𝐨𝐫𝐲) است و یک راه حل پایگاه داده‌ای نیست. در هر سرور LBS/Location-Based Service (سرویس مبتنی بر مکان) اجرا می‌شود و ساختار داده در زمان راه‌اندازی سرور ساخته می‌شود.نمودار دوم فرایند ساخت Quadtree را با جزئیات بیشتری توضیح می‌دهد. گره ریشه کل نقشه جهان را نمایش می‌دهد. گره ریشه به طور مجدد به 4 ربع شکسته می‌شود تا زمانی که گره‌ای با بیش از 100 کسب و کار باقی نماند.چگونه با Quadtree مربوط به کسب و کارهای نزدیک را پیدا کنیم؟Quadtree را در حافظه بسازید.پس از ساخت Quadtree ، جستجو را از ریشه شروع کنید و درخت را طی کنید، تا گره برگی که مبدأ جستجو در آن قرار دارد را پیدا کنید.اگر آن گره، برگی از 100 کسب و کار دارد، گره را برگردانید. در غیر این صورت، کسب و کارها را از همسایگان آن اضافه کنید تا تعداد کافی کسب و کار برگردانده شودبه روزرسانی سرور LBS و بازسازی Quadtreeساخت یک Quadtree در حافظه با 200 میلیون کسب و کار در زمان راه اندازی سرور ممکن است چند دقیقه طول بکشد.در حالی که Quadtree در حال ساخته شدن است، سرور نمی تواند ترافیک را پردازش کند.بنابراین، باید یک نسخه جدید از سرور را به صورت تدریجی در یک زیرمجموعه کوچک از سرورها در هر زمان اجرا کنیم. این از آفلاین شدن بخش بزرگی از خوشه سرور (server cluster) و ایجاد اختلال در سرویس جلوگیری می کند.

سیستم نظارت و هشدار برای متریک‌ها

JavadAgha — Mon, 20 May 2024 00:57:14 +0330

یک سیستم 𝐦𝐞𝐭𝐫𝐢𝐜𝐬 𝐦𝐨𝐧𝐢𝐭𝐨𝐫𝐢𝐧𝐠و alerting طراحی‌شده نقش کلیدی در ارائه شفافیت واضح در مورد سلامت زیرساخت برای اطمینان از بالا بودن سطوح دسترس‌پذیری (availability) و قابلیت اطمینان دارد. نمودار زیر نحوه کار آن را در سطح بالا توضیح می‌دهد.منبع متریک‌ها (Metrics source): این می‌تواند سرورهای اپلیکیشن، پایگاه داده‌های SQL، صف‌های پیام و غیره باشد.جمع‌کننده متریک‌ها (Metrics collector): این سیستم داده‌های متریک را جمع‌آوری کرده و آن‌ها را در پایگاه داده سری زمانی می‌نویسد.پایگاه داده سری زمانی (Time-series database): این پایگاه داده، داده‌های متریک را به صورت سری زمانی ذخیره می‌کند. معمولاً یک رابط کوئری سفارشی برای تحلیل و خلاصه‌سازی حجم زیادی از داده‌های سری زمانی ارائه می‌دهد. شاخص‌هایی (indexes) را در مورد برچسب‌ها (labels) حفظ می‌کند تا جستجوی سریع داده‌های سری زمانی بر اساس برچسب‌ها را تسهیل کند.کافکا: کافکا به عنوان یک پلتفرم ارسال پیام توزیع شده با قابلیت اطمینان و مقیاس پذیری بالا استفاده می شود. آن سرویس های جمع آوری داده و پردازش داده را از یکدیگر جدا می کند.مصرف‌کنندگان (Consumers): مصرف‌کنندگان یا سرویس‌های پردازش جریانی مانند Apache Storm، Flink و Spark، داده ها را پردازش می کنند و به پایگاه داده سری زمانی ارسال می کنند.سرویس کوئری (Query service): این سرویس، کوئری‌های ساده‌ای ایجاد می‌کند و بازیابی داده از پایگاه داده سری زمانی را فراهم می کند. این باید یک لایه باریکی باشد اگر یک پایگاه داده سری‌زمانی خوب انتخاب کنیم. همچنین می تواند به طور کامل با رابط کوئری خود پایگاه داده سری زمانی جایگزین شود.سیستم هشدار (Alerting system): این اعلان های هشدار را به مقاصد هشدار مختلف ارسال می کند.سیستم مصورسازی (Visualization system): این متریک ها را به صورت انواع نمودارها/چارت ها نشان می دهد.

کدام پایگاه‌داده برای سیستم جمع‌آوری متریک‌ها مناسب است؟

JavadAgha — Mon, 20 May 2024 00:49:26 +0330

این یکی از مهمترین سوالاتی است که باید در یک مصاحبه به آن پاسخ دهیم.الگوی دسترسی به دادههمانطور که در نمودار نشان داده شده است، هر برچسب (label) در محور y نماینده یک سری زمانی (که به طور منحصربفرد توسط نام‌ها و برچسب‌ها شناسایی می‌شود) در حالی که محور x نشان دهنده زمان است. حجم بار کاری در سمت نوشتن داده‌ها سنگین است. همانطور که میبینید، میتواند در هر لحظه نقاط داده‌های سری زمانی زیادی نوشته شود. میلیونها متریک عملیاتی در روز نوشته می‌شود و بسیاری از متریک‌ها با فرکانس بالا جمع‌آوری میشوند، بنابراین ترافیک در سمت نوشتن داده بدون شک سنگین است. در همان زمان، بار خواندن به صورت لحظه‌ای (spiky) است. هم سرویس‌های نمایش و هم سرویس‌های هشدار، کوئری‌هایی را به پایگاه داده ارسال می‌کنند و بسته به الگوهای دسترسی نمودارها و هشدارها، حجم خواندن می‌تواند شدید باشد.انتخاب پایگاه داده مناسبسیستم ذخیره داده قلب طراحی هر سیستمی است. توصیه نمی‌شود که سیستم ذخیره سازی خودتان را بسازید یا از یک سیستم ذخیره سازی همه منظوره (MySQL) برای این کار استفاده کنید. یک پایگاه داده همه منظوره، در تئوری میتواند از دادههای سری زمانی پشتیبانی کند، اما نیاز به تنظیم سطح حرفه‌ای دارد تا در مقیاس ما کار کند. به طور خاص، یک پایگاه داده رابطه‌ای برای عملیات‌هایی که معمولاً روی داده‌های سری زمانی انجام میشود، بهینه نشده است. برای مثال، محاسبه میانگین متحرک (moving average) در یک پنجره زمانی چرخشی (rolling time window) نیازمند SQL پیچیده است که خواندن آن دشوار است.. علاوه بر این، برای پشتیبانی از برچسبگذاری/برچسبگذاری داده‌ها، باید برای هر برچسب یک نمایه اضافه کنیم. علاوه بر این، یک پایگاه داده رابطهای همهمنظوره در برابر بار نوشتن سنگین مداوم عملکرد خوبی ندارد. در مقیاس ما، باید تلاش زیادی برای تنظیم پایگاه داده صرف کنیم و حتی پس از آن، ممکن است عملکرد خوبی نداشته باشد.NoSQL چطور ؟ در حالت تئوری، چند پایگاه داده NoSQL میتوانند دادههای سری زمانی را به طور موثر مدیریت کنند. برای مثال، هم Cassandra و هم Bigtable میتوانند برای داده‌های سری زمانی استفاده شوند. با این حال، این نیازمند دانش عمیق از عملکرد داخلی هر NoSQL برای طراحی یک طرح قابل مقیاس برای ذخیره و کوئری موثر داده‌های سری زمانی است. با وجود پایگاه دادههای سری زمانی در مقیاس صنعتی که به راحتی در دسترس هستند، استفاده از یک پایگاه داده NoSQL همه‌منظوره جذاب نیست.سیستم‌های ذخیره‌سازی زیادی وجود دارند که برای داده‌های سری زمانی بهینه‌سازی شده‌اند. بهینه‌سازی به ما امکان می‌دهد از سرورهای بسیار کمتری برای مدیریت همان حجم از داده‌ها استفاده کنیم. بسیاری از این پایگاه داده‌ها همچنین دارای رابطه‌ای کوئری سفارشی هستند که به طور خاص برای تجزیه و تحلیل داده‌های سری زمانی طراحی شده‌اند و استفاده از آنها بسیار راحتتر از SQL است. برخی حتی ویژگی‌هایی برای مدیریت نگهداری داده و تجمیع داده ارائه می‌دهند.

مدل های Pull در مقابل Push در جمع آوری داده های مربوط به Metrics

JavadAgha — Sun, 19 May 2024 01:03:51 +0330

دو روش برای جمع آوری داده های مربوط به متریک وجود دارد: pull یا push. این که کدام روش بهتر است، بحثی دائمی است و پاسخ روشنی وجود ندارد. در این مقاله ما به مدل pull نگاهی خواهیم انداخت. شکل 1 جمع آوری داده ها با مدل pull روی HTTP را نشان می دهد. ما جمع کننده های اختصاصی معیار داریم که به صورت دوره ای مقادیر معیار را از برنامه های در حال اجرا دریافت می کنند.در این رویکرد، جمع کننده متریک باید لیست کامل نقاط انتهایی سرویس (service endpoint) را که داده ها از آنها جمع آوری می شود را بداند. یک رویکرد ساده استفاده از یک فایل برای نگهداری اطلاعات DNS/IP برای هر نقطه انتهایی سرویس در سرورهای «جمع کننده متریک (metric collector)» است. در حالی که این ایده ساده است، اما نگهداری از این رویکرد در محیطی با مقیاس بزرگ که سرورها به طور مکرر اضافه یا حذف می شوند تا حدودی دشوار است و ما می خواهیم اطمینان حاصل کنیم که جمع کننده های متریک جمع آوری داده‌های متریک‌ را از سرورهای جدید از دست ندهند.خبر خوب این است که ما یک راه حل قابل اعتماد، مقیاس پذیر و قابل نگهداری از طریق Service Discovery ارائه شده توسط Kubernetes یا Zookeeper و غیره در اختیار داریم، که در آن سرویس ها میزان در دسترس بودن (availability) خود را ثبت می کنند و هر زمان که لیست نقاط انتهایی سرویس تغییر کند، جمع کننده متریک می تواند توسط مؤلفه کشف سرویس مطلع شود. کشف سرویس شامل قوانین پیکربندی در مورد زمان و مکان جمع آوری معیارها است، همانطور که در شکل 2 نشان داده شده است.شکل 3 مدل pull را به صورت جزئی توضیح می دهد.جمع کننده متریک که متادیتای (Metadata) مربوط به پیکربندی نقاط انتهایی سرویس را از Service Discovery دریافت می کند. متادیتا شامل فاصله زمانی pull، آدرس های IP، پارامترهای زمان توقف و تلاش مجدد و غیره است.جمع کننده متریک داده های متریک را از طریق یک نقطه انتهایی HTTP از پیش تعریف شده (برای مثال، /metrics) دریافت می کند. برای در معرض قرار دادن نقطه انتهایی (expose the endpoint)،معمولاً باید یک کتابخانه کلاینت به سرویس اضافه شود. در شکل 3 بیانگر سرویسی از وب سرورها است.(اختیاری) جمع کننده متریک یک نوتیفیکیشن رویداد (event notification) تغییر را با Service Discovery ثبت می کند تا هر زمان که نقاط انتهایی سرویس تغییر کند، یک به روز رسانی دریافت کند. از طرف دیگر، جمع‌کننده متریک می‌تواند به طور دوره‌ای تغییرات نقطه پایانی (endpoint) را بررسی کند.

رِندر کردن نقشه Google Maps

JavadAgha — Sun, 19 May 2024 00:34:43 +0330

در این متن به رندر کردن نقشه (Map Rendering) نگاهی خواهیم انداخت.کاشی‌های (𝐓𝐢𝐥𝐞𝐬) از پیش محاسبه شده یکی از مفاهیم بنیادی در رندر کردن نقشه، کاشی‌کاری (tiling) است. به جای رندر کردن کل نقشه به صورت یک تصویر بزرگ سفارشی، جهان به کاشی‌های کوچکتر تقسیم می‌شود. کلاینت فقط کاشی‌های مرتبط با منطقه‌ای را که کاربر در آن قرار دارد دانلود می‌کند و آنها را مانند یک کاشی‌کاری برای نمایش به هم می‌چسباند. کاشی‌ها در سطوح بزرگنمایی مختلف از پیش محاسبه می‌شوند. Google Maps از 21 سطح بزرگنمایی استفاده می‌کند.به عنوان مثال، در سطح بزرگنمایی 0 کل نقشه توسط یک کاشی تک با اندازه 256 * 256 پیکسل نمایش داده می‌شود. سپس در سطح بزرگنمایی 1، تعداد کاشی‌های نقشه در هر دو جهت شمال-جنوب و شرق-غرب دو برابر می‌شود، در حالی که هر کاشی در اندازه 256 * 256 پیکسل باقی می‌ماند. بنابراین در سطح بزرگنمایی 1 حدود 4 کاشی داریم و کل تصویر در سطح بزرگنمایی 1 اندازه 512 * 512 پیکسل دارد. با هر افزایش سطح، کل مجموعه کاشی‌ها 4 برابر تعداد پیکسل‌های سطح قبلی را دارد. افزایش تعداد پیکسل‌ها، سطح جزئیات بیشتری را در اختیار کاربر قرار می‌دهد. این امر به کلاینت امکان می‌دهد نقشه را در بهترین سطوح جزئیات بسته به سطح بزرگنمایی کلاینت رندر کند، بدون اینکه پهنای باند زیادی برای دانلود کاشی‌هایی با جزئیات بیش از حد مصرف شود. این موضوع به ویژه هنگام بارگیری تصاویر از کلاینت‌های موبایل اهمیت دارد.بخش‌های جاده و خیاباناکنون که نقشه‌های عظیم را به کاشی‌های کوچکتر تبدیل کرده‌ایم، نیاز داریم یک ساختار داده برای جاده‌ها نیز تعریف کنیم. ما جهان جاده‌ها را به بلوک‌های کوچک تقسیم می‌کنیم. به این بلوک‌ها،بخش‌های جاده می‌گوییم. هر بخش جاده شامل چندین جاده، تقاطع‌ها و سایر متادیتاهای (metadata) دیگر است.ما بخش‌های نزدیک به هم را در اَبَر بخش‌ها گروه‌بندی می‌کنیم. این فرآیند می‌تواند به طور مکرر برای رسیدن به سطح پوشش مورد نیاز اعمال شود. سپس بخش‌های جاده را به یک ساختار داده تبدیل می‌کنیم که الگوریتم‌های ناوبری می‌توانند از آن استفاده کنند. رویکرد معمول این است که نقشه را به یک گراف تبدیل کنیم، جایی که گره‌ها بخش‌های جاده هستند و دو گره اگر بخش‌های جاده مربوطه همسایه‌های قابل دسترس باشند، به هم متصل می‌شوند. به این ترتیب، یافتن مسیر بین دو مکان به یک مسئله کوتاه‌ترین مسیر تبدیل می‌شود که می‌توانیم از الگوریتم‌های Dijkstra یا در آن بهره ببریم.طراحی Google Mapsگوگل پروژه Google Maps را در سال 2005 آغاز کرد. تا ماه مارس 2021 نرم‌افزار Google Maps یک میلیارد کاربر فعال روزانه داشت و 99 درصد از جهان را در 200 کشور پوشش می‌داد. اگرچه Google Maps یک سیستم بسیار پیچیده است، اما می‌توانیم آن را به 3 مؤلفه سطح بالا تقسیم کنیم. در این متن بیایید نگاهی به چگونگی طراحی یک Google Maps ساده‌شده بیندازیم.سرویس موقعیت مکانیسرویس موقعیت مکانی مسئول ثبت به‌روزرسانی موقعیت مکانی کاربر است. کلاینت‌های Google Maps هر چند ثانیه یکبار موقعیت مکانی را به‌روزرسانی می‌کنند. داده‌های موقعیت مکانی کاربر در موارد زیر مورد استفاده قرار می‌گیرند:تشخیص جاده‌های جدید و جاده‌های تازه بسته شده یا جاده‌های تغییر داده شده.بهبود دقت نقشه با گذشت زمان.استفاده به عنوان ورودی برای تحلیل داده‌های ترافیک به صورت بلادرنگ و زنده.رِندرکردن نقشه (𝐌𝐚𝐩 𝐑𝐞𝐧𝐝𝐞𝐫𝐢𝐧𝐠)نقشه جهان به یک تصویر نقشه 2 بعدی بزرگ تصویر شده است. این نقشه به قطعات کوچک تصویری به نام "کاشی" (tile) تقسیم شده است (به بالا نگاه کنید). کاشی‌ها ثابت هستند و اغلب تغییر نمی‌کنند. یک راه کارآمد برای سرویس دادن فایل‌های کاشی ثابت، استفاده از CDN پشتیبانی شده توسط ذخیره‌سازی ابری مانند S3 است. کاربران می‌توانند tile‌های مورد نیاز را از CDN نزدیک برای ترکیب یک نقشه بارگیری کنند.اما اگر کاربر روی کلاینت در حال بزرگنمایی و حرکت در نقطه دید نقشه برای کاوش محیط اطراف خود باشد، چه اتفاقی می‌افتد؟یک راه کارآمد این است که از قبل بلوک‌های نقشه با سطوح بزرگنمایی مختلف را محاسبه کنیم و در صورت نیاز تصاویر را بارگیری کنیم.سرویس مسیریابی (𝐍𝐚𝐯𝐢𝐠𝐚𝐭𝐢𝐨𝐧 𝐒𝐞𝐫𝐯𝐢𝐜𝐞) این مؤلفه مسئول یافتن یک مسیر نسبتاً سریع از نقطه A به نقطه B است. برای کمک به محاسبه مسیر، از دو سرویس زیر استفاده می‌کند:سرویس ‌کُدینگ جغرافیایی (Geocoding): آدرس داده شده را به یک جفت عرض و طول جغرافیایی تبدیل می‌کند.سرویس برنامه‌ریز مسیردهی (Route Planner): این سرویس سه کار مختلف را به ترتیب زیر انجام می‌دهد:محاسبه K-برتر که بیان‌گر کوتاه‌ترین مسیر بین A و B است.محاسبه تخمین زمان برای هر مسیر بر اساس ترافیک فعلی و داده‌هایی که در گذشته تحلیل شده است.رتبه‌بندی مسیرها بر اساس پیش‌بینی زمان و فیلترهای کاربر. به عنوان مثال، کاربر نمی‌خواهد از عوارضی عبور کند.

طراحی Gmail

JavadAgha — Fri, 17 May 2024 16:15:13 +0330

یک تصویر بیش از هزار کلمه ارزش دارد. در این پست، نگاهی خواهیم انداخت که چه اتفاقی می‌افتد وقتی آلیس ایمیلی را برای باب ارسال می‌کند.1- آلیس به کلاینت Outlook خود وارد می‌شود، یک ایمیل می‌نویسد و دکمه "ارسال" را می‌زند. ایمیل به سرور ایمیل Outlook ارسال می‌شود. پروتکل ارتباطی بین کلاینت Outlook و سرور ایمیل، SMTP است.2- سرور ایمیل Outlook از DNS (در نمودار نشان داده نشده) آدرس سرور SMTP گیرنده را پرس و جو می‌کند. در این مورد، سرور SMTP گوگل است. سپس، ایمیل را به سرور ایمیل Gmail منتقل می‌کند. پروتکل ارتباطی بین سرورهای ایمیل، SMTP است.3- سرور Gmail ایمیل را ذخیره می‌کند و آن را برای باب به عنوان گیرنده در دسترس قرار می‌دهد.4- کلاینت Gmail ایمیل‌های جدید را از طریق سرور IMAP/POP هنگامی که باب به Gmail وارد می‌شود را دریافت می‌کند.لطفاً توجه داشته باشید که این یک طراحی بسیار ساده شده است. امیدوارم این علاقه و کنجکاوی شما را برانگیزد.

طراحی مسیر ارسال و دریافت ایمیل

JavadAgha — Fri, 17 May 2024 13:58:07 +0330

نمودار زیر مسیر دریافت ایمیل را نشان می‌دهد.ایمیل‌های ورودی در متعادل‌کننده بار SMTP وارد می‌شوند.متعادل‌کننده بار، ترافیک را بین سرورهای SMTP توزیع می‌کند. سیاست پذیرش ایمیل می‌تواند پیکربندی و در سطح اتصال SMTP اعمال شود. برای مثال، ایمیل‌های نامعتبر برگردانده می‌شوند تا از پردازش ایمیل غیرضروری جلوگیری شود.اگر پیوست یک ایمیل خیلی بزرگ باشد که نتوان آن را در صف قرار داد، می‌توانیم آن را در فضای ذخیره‌سازی پیوست‌ها در (S3) قرار دهیم.ایمیل‌ها در صف ایمیل‌های ورودی قرار می‌گیرند. صف، workerها پردازش ایمیل را از سرورهای SMTP جدا می‌کند تا بتوان آنها را به طور مستقل مقیاس‌پذیر کرد. علاوه بر این، صف به عنوان بافر عمل می‌کند در صورتی که حجم ایمیل افزایش یابد.workerها پردازش ایمیل مسئول انجام بسیاری از وظایف هستند، از جمله فیلتر کردن ایمیل‌های spam، متوقف کردن ویروس‌ها و غیره. مراحل بعدی فرض می‌کنند یک ایمیل از اعتبارسنجی عبور کرده است.ایمیل در فضای ذخیره‌سازی ایمیل، کَش و فضای ذخیره‌سازی اشیاء (object data store) ذخیره می‌شود.اگر گیرنده در حال حاضر آنلاین است، ایمیل به سرورهای بلادرنگ ارسال می‌شود.سرورهای بلادرنگ، سرورهای WebSocket هستند که به کاربران امکان می‌دهند تا ایمیل‌های جدید را در زمان واقعی دریافت کنند.برای کاربران آفلاین، ایمیل‌ها در لایه ذخیره‌سازی ذخیره می‌شوند. زمانی که یک کاربر دوباره آنلاین می‌شود، کلاینت وب‌میل از طریق RESTful API به سرورهای وب متصل می‌شود.سرورهای وب ایمیل‌های جدید را از لایه ذخیره‌سازی می‌کِشند و آنها را به کلاینت برمی‌گردانند.نمودار زیر مسیر ارسال ایمیل را نشان می‌دهد.1. یک کاربر ایمیلی را در وب‌میل می‌نویسد و دکمه "ارسال" را می‌زند. درخواست به توزیع‌کننده بار ارسال می‌شود.2. توزیع‌کننده بار اطمینان حاصل می‌کند که درخواست‌های ارسال ایمیل از محدودیت نرخ تجاوز نمی‌کند و ترافیک را به وب سرورها هدایت می‌کند.3. وب سرورها مسئول موارد زیر هستند:اعتبارسنجی اولیه ایمیل. هر ایمیل وارد شده در برابر قواعد از پیش تعریف شده مانند محدودیت اندازه ایمیل بررسی می‌شود.بررسی اینکه آیا دامنه آدرس ایمیل گیرنده با فرستنده یکسان است یا خیر. اگر یکسان باشد، داده‌های ایمیل مستقیماً در ذخیره‌سازی، کَش و object store وارد می‌شوند. گیرنده می‌تواند ایمیل را مستقیماً از طریق RESTful API دریافت کند. نیازی به رفتن به مرحله 4 نیست.4. صف پیام‌هااگر اعتبارسنجی اولیه ایمیل موفقیت‌آمیز باشد، داده‌های ایمیل به صف خروجی منتقل می‌شوند.اگر اعتبارسنجی اولیه ایمیل ناموفق باشد، ایمیل در صف خطا قرار می‌گیرد.5. Workerهای SMTP خروجی رویدادها را از صف خروجی می‌کِشند و اطمینان حاصل می‌کنند که ایمیل‌ها عاری از هرزنامه و ویروس هستند.6. ایمیل خروجی در "پوشه ارسال شده" در لایه ذخیره‌سازی ذخیره می‌شود.7. workerهای مربوط به SMTP خروجی ایمیل را به سرور ایمیل گیرنده ارسال می‌کنند. هر پیام در صف خروجی شامل تمام متادیتای مورد نیاز برای ایجاد یک ایمیل است. یک صف پیام توزیع شده یک جزء حیاتی است که پردازش ایمیل غیرهمگام را امکان‌پذیر می‌کند. با جدا کردن workerهای SMTP خروجی از وب سرورها، می‌توانیم workerهای SMTP خروجی را به طور مستقل مقیاس‌پذیر کنیم.ما اندازه صف خروجی را از نزدیک نظارت می‌کنیم. اگر تعداد زیادی ایمیل در صف گیر کرده باشند، باید علت مشکل را تجزیه و تحلیل کنیم. درنتیجه احتمالات زیر وجود دارد:سرور ایمیل گیرنده در دسترس نیست. در این صورت، باید ارسال ایمیل را در زمان دیگری دوباره امتحان کنیم. استراتژی عقب‌نشینی نمایی ممکن است یک استراتژی تلاش مجدد خوب باشد.مصرف‌کننده‌های کافی برای ارسال ایمیل‌ها وجود ندارد. در این صورت، ممکن است نیاز به مصرف‌کننده‌های بیشتر برای کاهش زمان پردازش داشته باشیم.

الگوهای خواندن replica

JavadAgha — Fri, 17 May 2024 13:30:35 +0330

دو روش رایج برای پیاده سازی الگوی نسخه replica خواندن وجود دارد:تعبیه منطق مسیریابی در کد برنامه.استفاده از میان‌افزار پایگاه داده.استفاده از میان‌افزار پایگاه دادهمیان‌افزار مسیریابی واضحی بین برنامه و سرورهای پایگاه داده را فراهم می‌کند. می‌توانیم منطق مسیریابی را بر اساس قواعد خاصی مانند کاربر، طرح، دستورات و غیره سفارشی کنیم.زمانی که آلیس سفارشی در آمازون ثبت می‌کند، درخواست به سرویس سفارش ارسال می‌شود.سرویس سفارش به طور مستقیم با پایگاه داده تعامل ندارد. در عوض، آن درخواست‌های پایگاه داده را به میان‌افزار پایگاه داده ارسال می‌کند.میان‌افزار پایگاه داده نوشتن‌ها را به پایگاه داده اصلی هدایت می‌کند. داده‌ها به دو نسخه تکراری تکثیر می‌شوند.آلیس جزئیات سفارش را مشاهده می‌کند (خواندن). درخواست از طریق میان‌افزار ارسال می‌شود.آلیس سابقه سفارش‌های اخیر را مشاهده می‌کند (خواندن). درخواست از طریق میان‌افزار ارسال می‌شود.میان‌افزار پایگاه داده به عنوان یک پروکسی بین برنامه و پایگاه داده‌ها عمل می‌کند. آن از پروتکل شبکه استاندارد MySQL برای ارتباط استفاده می‌کند.مزایا:کد برنامه ساده‌تر می‌شود. برنامه نیازی به آگاهی از توپولوژی پایگاه داده و مدیریت دسترسی مستقیم به پایگاه داده ندارد.سازگاری بهتر. میان‌افزار از پروتکل شبکه MySQL استفاده می‌کند. هر کلاینت سازگار با MySQL می‌تواند به راحتی به میان‌افزار متصل شود. این امر انتقال پایگاه داده را آسان‌تر می‌کند.معایب:افزایش پیچیدگی سیستم. یک میان افزار پایگاه داده یک سیستم پیچیده است. از آنجایی که تمام درخواست های پایگاه داده از طریق میان افزار می گذرند، معمولا نیاز به یک تنظیم با قابلیت دسترسی بالا برای جلوگیری از یک نقطه شکست تک دارد.لایه میان افزار اضافی به معنای تاخیر شبکه اضافی است. بنابراین، این لایه نیازمند عملکرد عالی است.تعبیه منطق مسیریابی در کد برنامهدر این تنظیمات، تمام دستورات تغییردهنده داده مانند درج، حذف یا به‌روزرسانی به پایگاه داده اصلی ارسال می‌شوند و خواندن‌ها به نسخه‌های تکراری و تکثیر شده جهت خواندن فرستاده می‌شوند.زمانی که آلیس در آمازون سفارشی ثبت می‌کند، درخواست به سرویس سفارش ارسال می‌شود.سرویس سفارش یک رکورد درباره سفارش در پایگاه داده اصلی ایجاد می‌کند (نوشتن). داده‌ها به دو نسخه تکراری تکثیر می‌شوند.آلیس جزئیات سفارش را مشاهده می‌کند. داده‌ها از یک نسخه تکثیر شده سرویس داده می‌شوند (خواندن).آلیس سابقه سفارش‌های اخیر را مشاهده می‌کند. داده‌ها از یک نسخه تکثیر شده سرویس داده می‌شوند (خواندن).یک مشکل عمده در این تنظیمات وجود دارد: تاخیر تکثیر (𝐫𝐞𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐥𝐚𝐠).در شرایط خاصی (تاخیر شبکه، اشباع سرور و غیره)، ممکن است داده‌ها در نسخه‌های تکثیر شده، چند ثانیه یا حتی چند دقیقه عقب باشند. در این حالت، اگر آلیس بلافاصله پس از ثبت سفارش، وضعیت سفارش را بررسی کند (درخواست پرس و جو از نسخه تکثیر شده سرویس داده می‌شود) و حتی ممکن است اصلاً سفارشی را مشاهده نکند. این باعث سردرگمی آلیس می‌شود. در این حالت، ما به "هماهنگی خواندن پس از نوشتن" نیاز داریم.راه‌حل‌های ممکن برای کاهش این مشکل:خواندن‌های حساس به تاخیر به پایگاه داده اصلی ارسال می‌شوند.خواندن‌هایی که بلافاصله پس از نوشتن‌ها انجام می‌شوند، به پایگاه داده اصلی هدایت می‌شوند.یک پایگاه داده رابطه‌ای معمولاً راهی برای بررسی اینکه آیا یک نسخه تکراری با اصلی همگام شده است یا خیر، فراهم می‌کند. اگر داده‌ها به‌روز هستند، از نسخه تکثیر شده پرس و جو کنید. در غیر این صورت، درخواست خواندن را رد کنید یا از پایگاه داده اصلی بخوانید.

وقتی یک URL را در مرورگر خود تایپ می کنید چه اتفاقی می افتد؟

JavadAgha — Fri, 17 May 2024 02:03:03 +0330

1.باب یک URL را در مرورگر وارد می کند و Enter را می زند. در این مثال، URL از 4 قسمت تشکیل شده است:طرح (scheme) - 𝒉𝒕𝒕𝒑𝒔://. این به مرورگر می‌گوید که با استفاده از HTTPS به سرور وصل شود.دامنه (domain) - 𝒆𝒙𝒂𝒎𝒑𝒍𝒆.𝒄𝒐𝒎. این نام دامنه سایت است.مسیر (path) - 𝒑𝒓𝒐𝒅𝒖𝒄𝒕/𝒆𝒍𝒆𝒄𝒕𝒓𝒊𝒄. این مسیر روی سرور به منبع درخواست شده است: تلفن.منبع (resource) - 𝒑𝒉𝒐𝒏𝒆. این نام منبعی است که باب می خواهد بازدید کند.2.مرورگر با استفاده از جستجوی سیستم نام دامنه (DNS) آدرس IP را برای دامنه جستجو می کند. برای اینکه فرآیند جستجو سریع شود، داده ها در لایه های مختلف کَش می‌شوند: حافظه کَش مرورگر، حافظه کَش سیستم عامل، حافظه کَش شبکه محلی و حافظه کَش ISP.اگر آدرس IP در هیچ یک از حافظه های کش یافت نشد، مرورگربه سرورهای DNS می رود تا یک جستجوی بازگشتی DNS انجام دهد تا زمانی که آدرس IP پیدا شود.3.حالا که آدرس IP سرور را داریم، مرورگر یک اتصال TCP با سرور برقرار می کند.4.مرورگر یک درخواست HTTP به سرور ارسال می کند. درخواست به این صورت است:𝘎𝘌𝘛 /𝘱𝘩𝘰𝘯𝘦 𝘏𝘛𝘛𝘗/1.1 𝘏𝘰𝘴𝘵: 𝘦𝘹𝘢𝘮𝘱𝘭𝘦.𝘤𝘰𝘮5.سرور درخواست را پردازش می کند و پاسخ را ارسال می کند. برای یک پاسخ موفق (کد وضعیت 200 است). پاسخ HTML ممکن است به این صورت باشد:𝘏𝘛𝘛𝘗/1.1 200 𝘖𝘒 𝘋𝘢𝘵𝘦: 𝘚𝘶𝘯, 30 𝘑𝘢𝘯 2022 00:01:01 𝘎𝘔𝘛 𝘚𝘦𝘳𝘷𝘦𝘳: 𝘈𝘱𝘢𝘤𝘩𝘦 𝘊𝘰𝘯𝘵𝘦𝘯𝘵-𝘛𝘺𝘱𝘦: 𝘵𝘦𝘹𝘵/𝘩𝘵𝘮𝘭; 𝘤𝘩𝘢𝘳𝘴𝘦𝘵=𝘶𝘵𝘧-8 <"𝘩𝘵𝘮𝘭 𝘭𝘢𝘯𝘨="𝘦𝘯> 𝘏𝘦𝘭𝘭𝘰 𝘸𝘰𝘳𝘭𝘥 6.حالا مرورگر محتوای HTML را به شیوه مناسبی نمایش می دهد.