نوشته های علی پیرپیران

برسی معماری زیرساخت ردیابی توزیع شده در Netflix

علی پیرپیران — Tue, 30 Jan 2024 20:48:04 +0330

در این مطلب نحوه ایجاد زیرساخت ردیابی توزیع شده توسط نتفلیکس شرح داده می‌شود.چکیدهبه دلیل معماری پیچیده میکروسرویس‌های نتفلیکس، ردیابی توزیع‌شده مورد نیاز است:عیب یابی: ردیابی توزیع‌شده مانند یک GPS برای خطاها عمل می‌کند، ریشه اصلی را در سراسر سرویس‌ها مشخص می‌کند و نشان می‌دهد که آنها چگونه بر تجربه کاربر تأثیر می‌گذارند.بهینه‌سازی عملکرد: ردیابی به شناسایی گلوگاه‌ها و روابط میان Stream های گوناگون کمک می‌کند و کمک میکند همه چیز روان‌تر اجرا شود.مانیتورینگ: ردیابی توزیع‌شده به نتفلیکس یک view به صورت real-time از وضعیت خدمات ارائه می‌دهد و به آنها اجازه می‌دهد قبل از اینکه مشکلات بر کاربران تأثیر بگذارد، آنها را برطرف کنند.به طور خلاصه، ردیابی توزیع‌شده نتفلیکس را قادر می‌سازد تا پلتفرم خود را کارآمد، قابل اعتماد و برای کاربران مفید نگه دارد.۱- مقدمهمشکل:مهندسان نتفلیکس برای بررسی ایرادات استریم داده‌ها مجبور به بررسی حجم عظیمی از داده‌ها و لاگ‌ها بودند.این فرآیند زمان‌بر، طاقت‌فرسا و مستعد خطا بود.راه‌حل:استفاده از ردیابی توزیع‌شده برای جمع‌آوری و تجزیه و تحلیل داده‌های مربوط به تراکنش‌ها در سراسر سیستم.انتخاب ابزار Open-Zipkin به عنوان یک ابزار منبع باز محبوب برای ردیابی توزیع‌شده.مزایای استفاده از ردیابی توزیع‌شده:شناسایی سریع‌تر ریشه ایرادات: با ردیابی مسیر درخواست در سراسر سیستم، می‌توان به سرعت محل بروز مشکل را مشخص کرد.کاهش زمان رفع ایراد: با تجزیه و تحلیل داده‌های جمع‌آوری شده، می‌توان به طور موثرتری اقدام به رفع ایراد نمود.بهبود عملکرد سیستم: با شناسایی گلوگاه‌ها و ناکارآمدی‌ها، می‌توان عملکرد سیستم را ارتقا داد.در شروع کار ابزار open-source زیادی وجود نداشت ولی تا سال ۲۰۱۷ ابزار های نسبتا خوبی توسعه داده شد مانند Open-Tracing و Open-Zipkin. نتفلیکس Open-Zipkin را انتخاب کرد.سه بخش اصلی زیرساخت:1. کتابخانه‌های Tracer:این کتابخانه‌ها به کد برنامه اضافه می‌شوند و وظیفه جمع‌آوری اطلاعات مربوط به تراکنش‌ها را بر عهده دارند.اطلاعات جمع‌آوری شده شامل شناسه تراکنش، زمان شروع و پایان، نام و مدت زمان هر مرحله از تراکنش و… می‌شود.2. پردازش استریم:داده‌های جمع‌آوری شده توسط کتابخانه‌های Tracer به سیستم پردازش استریم ارسال می‌شوند.این سیستم وظیفه پردازش و تجزیه و تحلیل داده‌های بلادرنگ را بر عهده دارد.3. ذخیره‌سازی:داده‌های جمع‌آوری شده برای تجزیه و تحلیل‌های آفلاین و بلندمدت ذخیره می‌شوند.این داده‌ها می‌توانند برای شناسایی الگوهای رفتاری، پیش‌بینی مشکلات و… مورد استفاده قرار گیرند.در ادامه درباره هر بخش و چالش های آن، توضیح می‌دهیم.۲- بخش های اصلی زیرساخت۲.۱ - کتابخانه Traceوظایف کتابخانه trace:نظارت بر تمام درخواست‌ها: این کتابخانه وظیفه رصد و جمع‌آوری اطلاعات مربوط به تمام درخواست‌هایی که از سرویس‌های استریم عبور می‌کنند را بر عهده دارد.ایجاد امکان ادغام آسان: کتابخانه trace به گونه‌ای طراحی شده است که به سادگی با سرویس‌های در حال اجرا ادغام شود.نحوه عملکرد کتابخانه trace:جمع آوری با استفاده از رصد IPC و درخواست‌های کلاینت: کتابخانه trace برای جمع‌آوری اطلاعات از دو روش IPC (ارتباط بین فرآیندی) محلی و درخواست‌های کلاینت‌ها به میکروسرویس‌ها استفاده می‌کند.اضافه کردن برچسب‌های مرتبط با زیرساخت: محیط در حال اجرا، برچسب‌های مرتبط با زیرساخت مانند نام سرویس، گروه auto-scaling (ASG) و آیدی کانتینر را به اطلاعات جمع‌آوری شده اضافه می‌کند.استفاده از اطلاعات برای کوئری و join کردن لاگ‌ها: اطلاعات جمع‌آوری شده و برچسب‌گذاری شده برای کوئری زدن و join کردن اطلاعات لاگ‌ها به منظور تجزیه و تحلیل و عیب‌یابی استفاده می‌شود.نکات تکمیلی:کتابخانه trace نقش کلیدی در ردیابی توزیع‌شده ایفا می‌کند و به جمع‌آوری اطلاعات مربوط به تراکنش‌ها در سراسر سیستم کمک می‌کند.زیر نظر داشتن IPC و درخواست‌های کلاینت، کتابخانه trace را به یک ابزار انعطاف‌پذیر برای ادغام با انواع مختلف سرویس‌ها تبدیل می‌کند.اضافه کردن برچسب‌های مرتبط با زیرساخت، امکان جستجو و فیلتر کردن اطلاعات لاگ‌ها را به منظور عیب‌یابی دقیق‌تر فراهم می‌کند.مزایای استفاده از کتابخانه trace:شناسایی سریع‌تر ریشه ایرادات: با ردیابی مسیر درخواست در سراسر سیستم، می‌توان به سرعت محل بروز مشکل را مشخص کرد.کاهش زمان رفع ایراد: با تجزیه و تحلیل داده‌های جمع‌آوری شده، می‌توان به طور موثرتری اقدام به رفع ایراد نمود.بهبود عملکرد سیستم: با شناسایی گلوگاه‌ها و ناکارآمدی‌ها، می‌توان عملکرد سیستم را ارتقا داد.۲.۲- پردازش استریمچالش‌های پردازش استریم:حجم بالای داده‌ها: ردیابی توزیع‌شده می‌تواند حجم عظیمی از داده‌ها را تولید کند.نیاز به تجزیه و تحلیل بلادرنگ: برای عیب‌یابی سریع و موثر، لازم است داده‌ها به صورت بلادرنگ تجزیه و تحلیل شوند.مصرف منابع: پردازش و تجزیه و تحلیل حجم بالای داده‌ها می‌تواند به مصرف قابل توجه CPU، حافظه و سایر منابع سیستم منجر شود.راه‌حل‌های تیم نتفلیکس:1. استفاده از ابزار Mantis:ابزار Mantis، ابزاری منبع باز است که توسط نتفلیکس برای مدیریت و پردازش داده‌های ردیابی توزیع‌شده توسعه یافته است.ابزار Mantis، به طور خاص برای غلبه بر چالش‌های پردازش استریم در مقیاس بزرگ طراحی شده است.2. بافر کردن و پردازش همزمان:ابزار Mantis داده‌های ردیابی را در حافظه بافر می‌کند و آنها را به صورت همزمان پردازش می‌کند.این رویکرد به کاهش تاخیر و افزایش کارایی پردازش کمک می‌کند.3. استفاده از MQL برای کاوش در داده‌ها:زبان MQL (Mantis Query Language) یک زبان کوئری مشابه SQL است که برای تجزیه و تحلیل داده‌های ردیابی در Mantis استفاده می‌شود.زبان MQL به کاربران امکان می‌دهد به طور دقیق و کارآمد داده‌ها را جستجو و فیلتر کنند و اطلاعات مورد نیاز خود را برای عیب‌یابی و رفع مشکلات پیدا کنند.مزایای استفاده از راه‌حل‌های تیم نتفلیکس:کاهش حجم داده‌ها: Mantis با استفاده از تکنیک‌های فشرده‌سازی و نمونه‌گیری، حجم داده‌های جمع‌آوری شده را به طور قابل توجهی کاهش می‌دهد.تجزیه و تحلیل بلادرنگ: Mantis با استفاده از پردازش همزمان، امکان تجزیه و تحلیل داده‌ها را به صورت بلادرنگ فراهم می‌کند.کاهش مصرف منابع: Mantis با استفاده از تکنیک‌های مختلف بهینه‌سازی، مصرف CPU، حافظه و سایر منابع را به حداقل می‌رساند.نکات تکمیلیپردازش استریم یک بخش حیاتی از ردیابی توزیع‌شده است و به تجزیه و تحلیل داده‌ها در زمان واقعی برای عیب‌یابی و رفع مشکلات کمک می‌کند.ابزار Mantis و زبان MQL ابزارهای قدرتمندی هستند که به تیم‌های مهندسی برای مدیریت و پردازش داده‌های ردیابی توزیع‌شده در مقیاس بزرگ کمک می‌کنند.۲.۳ ذخیره سازیچالش‌های ذخیره‌سازی داده‌ها:1. رشد حجم داده‌ها:با رشد تعداد و محبوبیت سرویس‌های استریم، حجم داده‌های ردیابی شده به طور قابل توجهی افزایش یافت.این حجم از داده‌ها از ظرفیت کلاسترهای Elasticsearch که در ابتدا در نظر گرفته شده بود، فراتر رفت.2. مقیاس‌پذیری:تغییر مقیاس کلاسترهای Elasticsearch به منظور افزایش ظرفیت ذخیره‌سازی، فرآیندی پیچیده و چالش‌برانگیز است.این امر نیازمند تخصص فنی بالا و صرف زمان و هزینه قابل توجهی است.3. افزایش هزینه‌ها:با افزایش حجم داده‌ها، نیاز به حافظه‌های SSD با سرعت بالا نیز افزایش یافت.استفاده از حافظه‌های SSD، هزینه‌های ذخیره‌سازی را به طور قابل توجهی افزایش می‌دهد.راه‌حل‌های تیم نتفلیکس:1. مهاجرت به Cassandra:تیم نتفلیکس برای حل مشکل مقیاس‌پذیری، به پایگاه داده Cassandra مهاجرت کرد.پایگاه داده Cassandra به دلیل مقیاس‌پذیری افقی و تحمل خطای بالا، برای ذخیره‌سازی حجم عظیمی از داده‌ها مناسب است.2. بهینه‌سازی منابع ذخیره‌سازی:تیم نتفلیکس با استفاده از تکنیک‌های مختلف فشرده‌سازی و رمزگذاری، حجم داده‌های ذخیره‌شده را به طور قابل توجهی کاهش داد.همچنین با استفاده از فیلترهای مناسب، فقط داده‌های ضروری و مفید را ذخیره کردند.3. استفاده از EBS:تیم نتفلیکس به جای استفاده از حافظه‌های SSD، از EBS (Elastic Block Store) که نوعی حافظه ابری است، استفاده کرد.حافظه EBS از نظر پرفورمنس و سرعت مقیاس‌دهی، مزایای قابل توجهی نسبت به SSD ها دارد.4. فشرده‌سازی داده‌ها:تیم نتفلیکس از ابزار zstd برای فشرده‌سازی داده‌ها استفاده کرد.این ابزار حجم داده‌ها را تا نصف کاهش داد، بدون اینکه به کیفیت و کارایی داده‌ها آسیبی برساند.5. استفاده از حافظه طبقه‌بندی شده:تیم نتفلیکس از حافظه طبقه‌بندی شده (Tiered Storage) استفاده کرد.در این روش، داده‌ها بر اساس اهمیت، حجم و میزان استفاده، در سطوح مختلف حافظه ذخیره‌سازی می‌شوند.این روش به صرفه‌جویی در هزینه‌ها و ارتقای کارایی ذخیره‌سازی کمک می‌کند.مزایای راه‌حل‌های تیم نتفلیکس:مقیاس‌پذیری: راه‌حل‌های ارائه شده توسط تیم نتفلیکس، مقیاس‌پذیری و انعطاف‌پذیری بالایی برای ذخیره‌سازی حجم عظیمی از داده‌ها را فراهم می‌کنند.کاهش هزینه‌ها: با استفاده از تکنیک‌های مختلف بهینه‌سازی، هزینه‌های ذخیره‌سازی به طور قابل توجهی کاهش پیدا کرد.بهبود کارایی: راه‌حل‌های ارائه شده، کارایی و عملکرد ذخیره‌سازی داده‌ها را ارتقا می‌دهند.مراحل بهینه‌سازی ذخیره سازی داده‌ها توسط نتفلیکسسال ۲۰۱۷: ElasticeSearchسال ۲۰۱۸: Cassandra روی SSDسال ۲۰۱۹: Cassandra روی EBSسال ۲۰۲۰: بهبود فشرده‌سازی داده‌‌ها و فیلتر کردن داده‌هاسال ۲۰۲۱: Tiered Storage۳- ابزار های ردیابی:ZipkinJaeger۳.۱- معماری ابزار Zipkinچکیده:ابزار Open-Zipkin یک ابزار منبع باز محبوب برای ردیابی توزیع‌شده است.این ابزار شامل اجزای مختلفی مانند Collector، Storage و Query Service می‌شود.مولفه Collector وظیفه دریافت داده‌ها از کتابخانه‌های Tracer را بر عهده دارد.مولفه Storage داده‌ها را ذخیره می‌کند و Query Service امکان جستجو و تجزیه و تحلیل داده‌ها را فراهم می‌کند.توضیحاتهمانطور که گفته شد، نتفلیکس از ابزار Zipkin برای جمع آوری داده Trace استفاده کرد. در این بخش معماری این ابزار را برسی می‌کنیم.این ابزار، اطلاعات را از قسمت های مختلف داخل معماری سیستم جمع آوری کرده و از طریق یک رابط کاربری اطلاعاتی را نمایش می‌دهد.موارد استفاده از این ابزار:1. بهبود کارایی سیستم:با شناسایی گلوگاه‌ها و ناکارآمدی‌ها در سیستم خود، می‌توانید آنها را رفع کرده و کارایی سیستم را به طور قابل توجهی ارتقا دهید.ابزار Zipkin با نمایش زمان صرف شده در هر بخش از سیستم، به شما کمک می‌کند تا نقاطی که نیاز به بهینه‌سازی دارند را به سرعت پیدا کنید.2. نمایش وابستگی میان میکروسرویس‌ها:ابزار Zipkin به شما کمک می‌کند تا وابستگی‌های بین میکروسرویس‌های مختلف در سیستم خود را به طور واضح مشاهده کنید.این امر به شما در درک بهتر نحوه عملکرد سیستم و عیب‌یابی مشکلات مربوط به وابستگی‌ها کمک می‌کند.3. عیب یابی ارورها:ابزار Zipkin با ارائه اطلاعات دقیق در مورد هر درخواست، به شما کمک می‌کند تا علت اصلی خطاها را به سرعت پیدا کنید.می‌توانید از Zipkin برای ردیابی مسیر درخواست در سراسر سیستم و شناسایی نقطه ای که خطا رخ داده است استفاده کنید.4. مانیتورینگ و alerting:ابزار Zipkin می‌تواند برای جمع‌آوری و تجزیه و تحلیل داده‌های مربوط به عملکرد سیستم شما استفاده شود. می‌توانید از این داده‌ها برای ایجاد داشبوردهای مانیتورینگ و تنظیم هشدارها برای شناسایی و رفع مشکلات به طور پیشگیرانه استفاده کنید.پنج کامپوننت اصلی:Instrumented ServicesCollectorStorageAPIWeb UI مولفه Instrumented Services (سرویس‌های ابزارگذاری شده):- شامل برنامه‌ها یا سیستم‌هایی هستند که قصد دارید با Zipkin آنها را رصد کنید.- کتابخانه‌های مختلفی برای زبان‌ها و چارچوب‌های مختلف برای ابزارگذاری کد برنامه شما با Zipkin ارائه شده است.- این کتابخانه‌ها وظایف زیر را انجام می‌دهند:ایجاد شناسه‌های ردیابی و spanها برای هر درخواست.اضافه کردن annotation و tag به داده‌ها برای ذخیره اطلاعات مربوط به درخواست.ارسال داده‌های ردیابی به Collector.۲. مولفه Collector (جمع‌آوری کننده):- پس از آماده شدن داده‌های ردیابی، Collector آنها را جمع‌آوری و پردازش می‌کند.- وظایف اصلی Collector عبارتند از:دریافت داده‌های ردیابی از Instrumentation Services از طریق پروتکل‌های مختلف (HTTP، Kafka، RabbitMQ، Scribe).اعتبارسنجی داده‌های ردیابی برای اطمینان از صحت و کامل بودن آنها.نمونه‌گیری (Sampling) از داده‌های ردیابی (در صورت نیاز) برای کاهش حجم داده.ذخیره داده‌های ردیابی در Storage.۳. مولفه Storage (ذخیره‌سازی):- پس از جمع‌آوری و اعتبارسنجی، Storage داده‌های ردیابی را ذخیره می‌کند.- ابزار Zipkin از گزینه‌های ذخیره‌سازی مختلفی پشتیبانی می‌کند، از جمله:پایگاه داده Cassandra: پایگاه داده NoSQL با مقیاس پذیری بالا و عملکرد مناسب.پایگاه داده Kafka: سیستم صف پیام‌رسان که برای ذخیره‌سازی و پردازش داده‌های ردیابی به صورت real-time مناسب است.پایگاه داده Elasticsearch: موتور جستجو که برای تجزیه و تحلیل و جستجوی داده‌های ردیابی ایده‌آل است.۳. مولفه API (سرویس پرس و جو Zipkin):- یک رابط RESTful را برای پرس و جو و تجزیه و تحلیل داده‌های ردیابی ذخیره‌شده ارائه می‌دهد.- توسعه‌دهندگان می‌توانند از این API برای موارد زیر استفاده کنند:بازیابی ردیابی‌های خاص بر اساس شناسه ردیابی، بازه زمانی یا معیارهای دیگر.فیلتر کردن داده‌های ردیابی برای یافتن اطلاعات خاص.جمع‌آوری داده‌های ردیابی برای تجزیه و تحلیل و شناسایی روندها.۵. مولفه Web UI (رابط کاربری وب):- یک رابط گرافیکی برای مشاهده و تجزیه و تحلیل داده‌های ردیابی ارائه می‌دهد.- مولفه Web UI به کاربران امکان می‌دهد:ردیابی‌های individual را به صورت گرافیکی مشاهده کنند.فیلتر و جستجوی ردیابی‌ها بر اساس معیارهای مختلف.تجزیه و تحلیل داده‌های ردیابی برای شناسایی گلوگاه‌ها و مشکلات عملکردی.ملاحظات معماری نرم‌افزار:مقیاس پذیری: Zipkin برای مقیاس پذیری افقی طراحی شده است، به این معنی که می‌توانید با اضافه کردن Collector و Storage بیشتر، آن را به منظور مدیریت حجم داده‌های ردیابی بیشتر ارتقا دهید.امنیت: Zipkin از رمزنگاری برای محافظت از داده‌های ردیابی در حین انتقال و ذخیره‌سازی استفاده می‌کند.نظارت: Zipkin معیارهای مختلفی را برای نظارت بر عملکرد و سلامت سیستم ارائه می‌دهد.نحوه ارتباط اجزای Zipkin با یکدیگر:اجزای Zipkin برای جمع‌آوری، ذخیره‌سازی و تجزیه و تحلیل داده‌های ردیابی، در سراسر زیرساخت میکروسرویس‌ها به طور یکپارچه با یکدیگر ارتباط برقرار می‌کنند. در ادامه نحوه ارتباط آنها با یکدیگر شرح داده شده است:۱. ردیاب (Tracer) به جمع‌آوری‌کننده (Collector):- پروتکل: gRPC یا HTTP (قابل تنظیم)- داده: داده‌های ردیابی شامل spans، annotations و tags برای هر درخواست‌.- جریان:هر سرویس مجهز به Zipkin پس از اتمام درخواست، داده‌های ردیابی را به جمع‌آوری‌کننده ارسال می‌کند.جمع‌آوری‌کننده به طور همزمان داده‌ها را از ردیاب‌های مختلف دریافت می‌کند.۲. جمع‌آوری‌کننده (Collector) به حافظه (Storage):- پروتکل: بسته به Storage انتخاب شده متفاوت است (به عنوان مثال، CQL برای Cassandra، قالب پیام Kafka برای Kafka و غیره) - داده: داده‌های پردازش شده و جمع‌آوری شده.- جریان:جمع‌آوری‌کننده قبل از ارسال داده‌ها به ذخیره‌سازی، آنها را اعتبارسنجی و در صورت نیاز نمونه‌گیری(Sampling) می‌کند.اStorage داده‌ها را برای درخواست های دریافت بعدی، ذخیره می‌کند.۳. سرویس پرس و جو (Query Service) به حافظه:- پروتکل: بسته به حافظه انتخاب شده.- داده: کوئری مربوط به دریافت Traceها.- جریان:کاربران برای انجام پرس و جو با API سرویس کوئری تعامل دارند.سرویس پرس و جو، درخواست‌ها را به فرمت قابل فهم برای سرویس حافظه تبدیل می‌کند و به حافظه ارسال می‌کند.حافظه بر اساس کوئری، داده‌ها را دریافت و پردازش می‌کند و نتایج را به سرویس پرس و جو برمی‌گرداند.۴. سرویس پرس و جو به کاربران:- پروتکل: API RESTful (JSON یا Protobuf).- داده: مطابق با query، داده‌های trace.- جریان:سرویس پرس و جو نتایج را از حافظه دریافت می‌کند و آنها را برای استفاده کاربر آماده می‌کند.کاربران از طریق API یا ابزارهای بصری مانند Zipkin UI یا Grafana به داده‌های ردیابی دسترسی پیدا می‌کنند.مراجعhttps://zipkin.io/pages/architecture.htmlhttps://github.com/openzipkin/zipkinhttps://www.jaegertracing.io/docs/1.53/architecture/https://en.wikipedia.org/wiki/Tiered_storagehttps://netflix.github.io/mantis/https://netflixtechblog.com/building-netflixs-distributed-tracing-infrastructure-bb856c319304این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است

پنج کنفرانس جدید معماری نرم‌افزار

علی پیرپیران — Fri, 05 Jan 2024 23:18:32 +0330

Building Distributed Applications with Event Driven Architecture • Eric Johnson • GOTO 2023سخنران: Eric Johnson، توسعه‌دهنده ارشد در AWSلینک: https://youtu.be/9StQpMLC-5Q?si=4RVsEkYcFtsd1SET در این ویدیو، اریک جانسون، چالش‌ها و بهترین شیوه‌های ساخت برنامه‌های توزیع‌شده با معماری Event Driven (EDA) را بررسی می‌کند. او ابتدا EDA را تعریف می‌کند و مزایای آن را، مانند وابستگی ضعیف، مقیاس‌پذیری و پایداری، توضیح می‌دهد.سپس انواع وابستگی را، از جمله وابستگی فناوری (technology dependency)، وابستگی داده (data dependency) و وابستگی مکان (location dependency)، مورد بحث قرار می‌دهد. او اهمیت کاهش وابستگی در سیستم‌های توزیع‌شده را برای بهبود انعطاف‌پذیری و قابلیت نگهداری تأکید می‌کند.در ادامه، مفهوم Asynchronous communication را معرفی می‌کند که یکی از جنبه‌های کلیدی EDA است. او توضیح می‌دهد که چگونه Asynchronous communication می‌تواند به جداسازی سیستم‌ها کمک کند و عملکرد را بهبود بخشد. او همچنین از استفاده از (DLQ) Dead letter queue برای رسیدگی به پیام‌هایی که نمی‌توانند بلافاصله پردازش شوند، بحث می‌کند.سپس چالش‌های مسیریابی پیام‌ها در سیستم‌های توزیع‌شده را مورد بحث قرار می‌دهد. او استدلال می‌کند که اغلب بهتر است از یک Message router، مانند صف SQS، برای انتقال پیام‌ها استفاده کرد به جای اینکه این کار مستقیما داخل خود اپلیکیشن انجام شود. این کار می‌تواند به ساده‌سازی برنامه و بهبود قابلیت نگهداری آن کمک کند.در نهایت، مفهوم item potency را معرفی می‌کند که یک تکنیک برای اطمینان از پردازش هر پیام فقط یک بار است. او توضیح می‌دهد که چگونه می‌توان از یک شناسه یونیک، مانند یک توکن، برای ردیابی وضعیت هر پیام و جلوگیری از تکرار استفاده کرد.خلاصه کلی:معماری EDA یک رویکرد قدرتمند برای ساخت برنامه‌های توزیع‌شده است که مقیاس‌پذیر، پایدار و قابل نگهداری هستند.برای بهبود انعطاف‌پذیری و قابلیت نگهداری، وابستگی بین سیستم‌ها را کاهش دهید.از Asynchronous communication برای جدا کردن سیستم‌ها و بهبود عملکرد استفاده کنید.از dead-letter queue برای رسیدگی به پیام‌هایی که نمی‌توانند بلافاصله پردازش شوند، استفاده کنید.از یک Message router برای مسیریابی به جای ارسال پیام مستقیما از خود برنامه فرستنده استفاده کنید.مفهوم item potency کمک میکند تا هر پیام فقط یک بار پردازش شود.Data - The Land DevOps Forgot • Michael Nygard • YOW! 2023سخنران: Michael Nygard، توسعه‌دهنده، معمار و نویسندهلینک: https://youtu.be/459-H33is6o?si=2vKMHiTlqaf8wqxVدر این ویدیو، به چالش‌های مدیریت داده در زمینه DevOps پرداخته می‌شود. استدلال میشود که رویکرد سنتی مدیریت داده که متمرکز (monolithic) و یکپارچه (centralized) است، برای مقابله با پیچیدگی‌های داده‌های جدید مناسب نیست.مفهوم «Data mesh» را معرفی می‌کند، یک رویکرد غیرمتمرکز برای مدیریت داده که از اصول میکروسرویس‌ها و service mesh الهام گرفته است. Data mesh مالکیت و مدیریت داده را به تیم‌هایی که آن را ایجاد و استفاده می‌کنند، واگذار می‌کند و از این طریق، تمرکز داده را از بین می‌برد و شبکه‌ای از داده را ایجاد می‌کند.سخنران چندین مزیت کلیدی Data mesh را برجسته می‌کند:افزایش چابکی: تیم‌های داده (Data teams) می‌توانند بدون اتکا به یک مرجع مرکزی، داده‌های خود را به سرعت سازگار کنند.بهبود کیفیت داده: مالکان داده(Data owners)، داده‌های خود را با جزئیات بهتری می‌بینند، بنابراین کیفیت داده های تولید شده توسط خودشان را در اولویت قرار دهند.کاهش هزینه‌ها: تیم‌های داده(Data teams) می‌توانند هزینه‌های مرتبط با نگهداری یک پلتفرم داده متمرکز(centralized data platform) را به حداقل برسانند.پیاده‌سازی Data mesh چالش‌های خاصی را به همراه دارد:مسائل فرهنگی: تیم‌های داده باید مالکیت و مسئولیت داده‌های خود را بپذیرند.موانع فنی: ابزارها برای Data mesh هنوز نوپا هستند و نیاز به بررسی دقیق‌تر برای استفاده های فنی دارند.در نتیجه، Data mesh به عنوان یک رویکرد امیدوارکننده به مدیریت داده ظهور می‌کند که به سازمان‌ها چابکی، کیفیت داده و کارایی هزینه را بهبود می‌بخشد. با این حال، پذیرش موفقیت‌آمیز آن مستلزم تغییر فرهنگی در تیم‌های داده، ارزیابی دقیق آمادگی فنی و رویکرد استراتژیک به انتخاب فروشنده است.Tales of Kafka @Cloudflare: Lessons Learnt on the Way to 1 Trillion Messagesسخنران: Matt Bou, Andre Meta، اعضای تیم Cloudflare Application Servicesلینک: https://youtu.be/_booBjCB7rU?si=qb0OlUw3ZR8Weallاین سخنرانی به بررسی چگونگی مقیاس‌پذیری استفاده از Kafka در Cloudflare برای پردازش بیش از یک تریلیون پیام می‌پردازد.اوایل Kafka در Cloudflareسرویس Cloudflare در سال ۲۰۱۵ شروع به استفاده از Kafka کرد تا سرویس‌ها را از هم جدا کند و ارتباط بین تیم‌ها را بهبود بخشد. تیم در ابتدا از kafka به صورت یک cluster یکپارجه استفاده می‌کرد، اما با رشد شرکت، این کلاستر به یک گلوگاه تبدیل شد.ایجاد انتزاع روی Kafkaبرای رفع محدودیت‌های مقیاس‌پذیری در کلاستِر یکپارچه، Cloudflare یک کلاستر برای انتقال پیام‌ها (message bus cluster)ایجاد کرد. این کلاستر برای همه تیم‌های Cloudflare در دسترس است و روشی ساده برای ایجاد و مدیریت topic های Kafka فراهم می‌کند.بهبود مقیاس‌پذیری و قابلیت اطمینانسرویس Cloudflare چندین استراتژی را برای بهبود مقیاس‌پذیری و قابلیت اطمینان زیرساخت Kafka خود پیاده‌سازی کرده است. این موارد عبارتند از:افزایش تعداد پارتیشن‌ها و consumerها: این امر به Cloudflare اجازه می‌دهد پیام‌های بیشتری را بدون نیاز به افزایش تعداد واسط‌ها پردازش کند.استفاده از یک contract واحد برای هر topic: این امر اطمینان حاصل می‌کند که همه consumerها به یک روش یکسان پیام‌ها را می‌خوانند و می‌نویسند.مستندسازی best practiveها: این امر به تیم‌ها کمک می‌کند تا از اشتباهات رایج اجتناب کنند و اطمینان حاصل کنند که از Kafka به روشی یکنواخت و قابل اعتماد استفاده می‌کنند.برنامه‌های آیندهسرویس Cloudflare در حال کار بر روی چندین پروژه برای بهبود بیشتر زیرساخت Kafka خود است. این موارد عبارتند از:توسعه ابزاری به نام Guia: این ابزار کار را برای تیم‌ها آسان‌تر می‌کند تا با Kafka شروع کنند و از آن به روشی آماده برای تولید استفاده کنند.تولید کد مشتری برای زبان‌های متعدد: این امر کار را برای تیم‌ها آسان‌تر می‌کند تا از Kafka در زبان برنامه‌نویسی مورد نظر خود استفاده کنند.Practical (a.k.a. Actually Useful) Architecture • Stefan Tilkov • GOTO 2023سخنران: Stefan Tilkov - معمار نرم‌افزار، سخنران و نویسنده‌ی متخصص در زمینه‌ی رایانش ابری، میکروسرویس‌ها و DevOps است. او با شرکت‌های متعددی، از جمله IBM، گوگل و نتفلیکس، همکاری داشته است و چندین کتاب و مقاله در مورد معماری ابری منتشر کرده است.لینک: https://youtu.be/BNTt2aLB1tg?si=RVJxnIpYEB4A_oUHاین ویدیو ۱۰ توصیه برای معماری عملی را ارائه می‌دهد. این توصیه‌ها بر اساس تجربه سخنران و سایر معماران است که در طیف گسترده‌ای از پروژه‌ها کار کرده‌اند.توصیه ۱: انتخاب آگاهانههنگام صحبت از معماری، باید از دیدگاه‌های مختلف، مانند معماری دامنه، معماری ماکرو و معماری میکرو، آگاه باشید. معماری دامنه با ساختار کلی سیستم سروکار دارد، در حالی که معماری ماکرو با اجزای سطح بالا سیستم سروکار دارد. معماری میکرو با جزئیات پایین سیستم، مانند اجزای سخت‌افزاری و نرم‌افزاری، سروکار دارد.توصیه ۲: فقط مستند نکنید، تصمیم بگیریدمستندسازی معماری موجود مهم است، اما هدف نهایی نیست. شما همچنین باید در مورد معماری تصمیم بگیرید و از آن دفاع کنید. این کار را می‌توان از طریق فرایندی به نام تصمیم‌گیری معماری (architectural decision making - ADM) انجام داد. ADM شامل مستندسازی تصمیمات گرفته شده، منطق پشت تصمیمات و جایگزین‌هایی است که در نظر گرفته شده‌اند.توصیه ۳: تشویق به تصمیم‌گیری و استفاده از ADRهارکورد تصمیم معماری (Architectural Decision Records - ADRs) راهی برای مستندسازی تصمیمات معماری است. ADRها باید شامل اطلاعات زیر باشند:تصمیم گرفته شدهمنطق پشت تصمیمگزینه‌هایی که در نظر گرفته شده‌اندافرادی که تصمیم را گرفته‌اندتاریخ تصمیم‌گیریرکوردهای ADR می‌توانند برای برقراری ارتباط تصمیمات معماری با سایر ذینفعان و ردیابی تکامل معماری در طول زمان استفاده شوند.توصیه ۴: معماری ایستا نیستمعماری یک فرایند تکراری است که با تغییرات سازگار می‌شود. با تغییر نیازمندی‌های سیستم، معماری ممکن است نیاز به به‌روزرسانی داشته باشد. به همین دلیل مهم است که معماری را مستند کنید و تصمیماتی بگیرید که انعطاف‌پذیری کافی برای سازگاری با تغییرات را داشته باشند.توصیه ۵: سادگی را بر پیچیدگی اولویت دهیداز فناوری‌های شناخته‌شده و اثبات شده استفاده کنید، مگر اینکه دلیل خوبی برای انجام کاری غیر از این داشته باشید. معماری‌های پیچیده برای نگهداری دشوارتر هستند و بیشتر احتمال دارد دچار مشکل شوند.توصیه ۶: دامنه را درک کنیدفقط روی فناوری تمرکز نکنید؛ مشکل کسب‌وکار را که در حال حل آن هستید، درک کنید. بهترین معماری آن است که مشکل را به ساده‌ترین و کارآمدترین روش ممکن حل می‌کند.توصیه ۷: از نوآوری در دامنه نترسیدمهم‌ترین نوآوری‌ها اغلب در حوزه کسب‌وکار هستند، نه فناوری. پذیرای ایده‌های جدید باشید و از آزمایش کردن ایده‌های جدید نترسید.توصیه ۸: context را در نظر بگیریدیک معماری خاص که برای همه مناسب باشد، وجود ندارد. رویکرد خود را با نیازهای خاص پروژه سازگار کنید. عواملی مانند اندازه و پیچیدگی سیستم، بودجه و زمان را در نظر بگیرید.توصیه ۹: به دنبال تکامل پذیری باشید، نه کمالمعماری باید انعطاف‌پذیری کافی برای سازگاری با تغییرات را داشته باشد. سعی نکنید معماری کاملی ایجاد کنید که هرگز نیازی به تغییر نداشته باشد.توصیه ۱۰: از کثیف شدن دست‌های خود نترسیددامنه کسب‌وکار و فناوری را که از آن استفاده می‌کنید درک کنید. از اینکه آستین‌های خود را بالا بزنید و در اجرای معماری مشارکت کنید نترسید.Building Resilient Frontend Architecture • Monica Lent • GOTO 2019سخنران: Monica Lent. مهندس نرم‌افزار با بیش از ۱۰ سال تجربه. او در حال حاضر یک مهندس نرم‌افزار ارشد در شرکت SumUp، یک شرکت پردازش پرداخت اروپایی است. او همچنین یک سخنران و نویسنده در زمینه معماری نرم‌افزار است.لینک: https://youtu.be/TqfbAXCCVwE?si=Z6ld16z9-ZnYu8KMاین سخنرانی صرفاً در مورد نکات فنی نیست؛ بلکه یک بررسی فلسفی از رویکرد ما برای ساخت و نگهداری نرم‌افزار است.بازنویسی (Rewriting): ضرورت در برابر انعطافبازنویسی نرم‌افزار اجتناب‌ناپذیر است، زیرا نیازها، فناوری‌ها و پارادایم‌ها در حال تغییر هستند. با این حال،این کنفرانس تمرکز را از «جایگزین کردن کد بد» به «ساخت با در نظر گرفتن انعطاف» تغییر می‌دهد. این تغییر ظریف ما را تشویق می‌کند تا انعطاف‌پذیری و قابلیت نگهداری را در اولویت قرار دهیم و کد را نه به عنوان یک محصول استاتیک، بلکه به عنوان یک موجود زنده که می‌تواند به طور ظریف تکامل یابد، ببینیم.بدهی فنی (Technical Debt): دشمن نامرئیسخنران تصویری غم‌انگیز از بدهی فنی به عنوان یک دشمن آرام و زیرک ترسیم می‌کند. جذابیت رفع سریع مشکلات، بارِ کدِ به ارث رسیده و جذابیت فناوری‌های جدید همگی می‌توانند به این بار نامرئی کمک کنند، که سرعت و کیفیت توسعه را کاهش می‌دهد. او معماری آگاهانه و شیوه‌های کدنویسی منظم را به ما یادآوری کرد که یک بخیه به موقع (یا یک تصمیم طراحی خوب‌تأمل‌شده) می‌تواند ما را از ماه‌ها دردسر در آینده نجات دهد.اجبارها (Constraints): آزادی در چارچوب‌هاا‌جبارهای معماری، که اغلب به عنوان محدودیت‌ها(limitations) دیده می‌شوند، می‌توانند متحدان قدرتمندی باشند. با تعیین مرزهای مشخص در مورد نحوه تعامل کد، همانطور که در برنامه‌نویسی شیءگرا یا فانکشنال دیده می‌شود، توسعه‌دهندگان چارچوبی برای ساخت سیستم‌های قابل پیش‌بینی (predictable) و قابل نگهداری (maintable) به دست می‌آورند. این کار مانند گاردرِیل‌های کنار جاده است؛ محدودیت‌ها، سفر ایمن و کارآمد را قابل دسترس می‌کنند و در نهایت توسعه‌دهندگان را آزاد می‌گذارند تا بر روی راه‌حل های خلاقانه در چارچوب ساختار موجود تمرکز کنند.تغییرات کوچک، تأثیر بزرگ: اثر پروانه‌ایسخنران به زیبایی نشان می‌دهد که چگونه تصمیمات به ظاهر کوچک می‌توانند در طول زمان، تأثیرات قابل توجهی داشته باشند. تنظیم قوانین وابستگی، استفاده مجدد محتاطانه از کد و اجرای خودکار سازی ممکن است به نظر جزئی بیایند، اما اثر تجمعی آنها بزرگ است. درست همانطور که قطرات کوچک در نهایت دره‌ها را می‌تراشند، این انتخاب‌های آگاهانه بدهی‌های فنی را کاهش می‌دهند و یک codebas درست‌تر و قابل مدیریت‌تر را شکل می‌دهند.مالکیت فردی: توانمندسازی معماران تغییرهر ویژگی، بزرگ یا کوچک، تاثیرگذار بر تصمیمات معماری است. با باز گذاشتن دست توسعه‌دهندگان برای مشارکت و مالکیت بر این انتخاب‌ها، باعث ایجاد حس مسئولیت‌پذیری و حس سرمایه‌گذاری شخصی در برنامه نویسان می‌شویم. این مالکیتِ جمعی، هوشیاری نسبت به معماری را افزایش می‌دهد، تصمیم‌گیری‌ها را هدفمندتر و کد را از ابتدا مستحکم‌تر می‌کند.آن سوی وب: یک اثر هنری الهام‌بخشجامعه توسعه وب یک جزیره منزوی نیست. سخنران ما را تشویق می‌کند تا ایده‌ها را فراتر از این جای معمول جستجو کنیم و راه حل‌ها و استراتژی‌ها را در سایر پارادایم‌های برنامه‌نویسی و جوامع کاوش کنیم. این تلاقی ایده‌ها می‌تواند منجر به بروز رویکردهای نوآورانه و موثری در معماری شود و به ما یادآوری کند که می‌توانیم از دیدگاه‌های متنوع برای ساخت سیستم‌های بهتر استفاده کنیم.انسانی کردن حرفه: ساختن سیستم‌ها، نه صرفاً چند خط کدسخنرانی فراتر از جزئیات فنی می‌رود و جنبه‌های انسانی توسعه نرم‌افزار را هم بیان می‌کند. سخنران، علاقه به بازنویسی‌ها(Rewrites) و ارزشمند بودنِ یادگیری از دیگر جوامع را بیان می‌کند. این رویکرد، محیطی مشارکتی تر و پربارتر برای توسعه ایجاد می‌کند، جایی که دانش و ایده‌ها آزادانه جریان می‌یابند و توسعه‌دهندگان احساس آزادی برای آزمایش و یادگیری را دارند.جمع بندی نظرات: طراحی معماری سفری بی‌پایان است، نه مقصدی مشخصساخت معماری‌های انعطاف پذیر برای front-end، مانند یک سفر است، نه یک دستاورد یکباره. این سخنرانی نقشه‌ی راهی را ارائه می‌دهد که پر از استراتژی‌های عملی و ایده‌های قابل توجهی است. با اولویت‌بندی قابلیت نگهداری، پذیرش محدودیت‌ها و پرورش فرهنگ یادگیری مداوم، می‌توانیم رابط‌های کاربری‌ای بسازیم که نه تنها امروز به خوبی کار می‌کنند، بلکه با تغییرات وب سازگار می‌شوند.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.

برخی مفاهیم پرکاربرد و جدید در معماری نرم‌افزار

علی پیرپیران — Sun, 26 Nov 2023 13:33:22 +0330

هدف این مطلب، کسب دانشی اولیه و سطحی درباره چندین موضوع متنوع و پراکنده است. Modular Monolithicیکی از انواع معماری‌های یکپارچه(monolithic) است. در این روش، تقسیم‌بندی کد پروژه بر اساس دامنه موضوعات است. بر خلاف معماری لایه لایه که در آنجا تقسیم بندی نرم‌افزار به صورت تکنیکال انجام می‌گرفت.مانند باقی معماری های یکپارچه، خروجی یک فایل قابل اجرا است. وجود یک فایل برای اجرای برنامه به استقرار ساده نرم‌افزار کمک کرده و مزیت آن محسوب می‌شود.برخلاف معماری میکرو سرویس، تمام پروژه باید با یک زبان برنامه نویسی، نوشته شود که این می‌تواند عیب تلقی شود.در زمان ایجاد تیم، نیاز است که برای جنبه های متفاوت فنی یک فرد متخصص در تیم وجود داشته باشد. در ادامه مزیت این کار گفته می‌شود.به طور معمول در نرم‌افزار تغییرات مربوط به یک دامنه خاص هستند. برای مثال تغییر در بخش خرید محصول. بنابراین در این نوع معماری، تمام کار مورد نیاز برای یک تغییر، به یک تیم مشخص مربوط می‌شود که این مزیت محسوب می‌شود.برخی از عیوب این نوع معماری:- در صورت رخ دادن یک خطا در یک ماژول، کل سیستم با مشکل مواجه می‌شود.- تغییر مقیاس نرم‌افزار کار سختی است.AWSیک سرویس ابری است که توسط آمازون ایجاد شده است. به کمک دیتاسنترهای آمازون در سراسر جهان خدمات ارائه می‌کند.این سرویس‌ها شامل پردازش، ذخیره‌سازی، پایگاه داده و ... است.برای کمپانی‌هایی که نیاز دارند با هزینه کم شروع به کار کنند گزینه خیلی خوبی است به دلیل اینکه نیاز به پرداخت هزینه های زیاد برای تهیه زیرساخت مناسب ندارند و تنها بر حسب میزان استفاده از سرویس های aws هزینه پرداخت می‌کنند (pay as you go).API First Approachدر این روش، طراحی APIها قدم اول ساخت نرم‌افزار است. یعنی ابتدا API ایجاد می‌شود سپس کد باقی قسمت‌ها زده می‌شود.برای این منظور نیاز است که API های داخل(private) و خارجی(public) مشخص شوند.با ایجاد API، راه ارتباطی برای کاربران، برنامه نویسان و سرویس های خارجی مشخص می‌شود. این کار به توسعه و تست ساده‌تر و زودتر نرم‌افزار کمک می‌کند.No SQL Databasesاین نوع پایگاه‌های داده سخت‌گیری های پایگاه داده های رابطه‌ای را ندارند. در نتیجه:منعطف هستندکمک می‌کنند به توسعه سریعاستفاده راحتی دارندبرای مقیاس‌های بزرگ، حجم بالای اطلاعات با زمان دسترسی پایین مناسب هستند.برخلاف پایگاه داده های رابطه‌ای، نیاز به تعریف schema برای جداول نیست. بنابراین، چک کردن کلیدها(خارجی، اصلی و ...) را ندارد که به سرعت و سادگی آن‌ها کمک می‌کند. معمولا هر رکورد داده را به صورت json ذخیره می‌کنند.انواع پایگاه داده‌های No SQLکلید/مقدار (key/value) - ذخیره در Ram مانند Redis- ذخیره در Disk مانند Couchbaseگرافی (Graph based) مانند Neo4jداکیومنتی (Document oriented) مانند MongoDBسطونی (Column oriented) مانند CassandraServerless Architectureدر این معماری، کاربر نیازی به تهیه زیر‌ساخت(حافظه، مموری، پردازنده و ...) ندارد. تنها نیاز است که بدنه فانکشن و رویداد(Event) مربوطه را تعیین کند. منظور از رویداد، رخدادی است که با آن، فانشکن باید اجرا شود.یک نمونه معروف آن، Function As A Service (FAAS) است.چند مثال از انواع رویدادآدرس های وب سرویس رست (Rest Webservice)https://:/function/کلیک کاربر داخل مرورگررویدادی از سمت یک حسگر، مثلا تغییر دمای محیطمزیت اصلی این معماری، کاهش هزینه است. چون استفاده کنندگان تنها هزینه اجرای فانشکن را پرداخت می‌کنند. برای مثال نیاز به تهیه زیرساخت کامل برای فانکشنی که به ندرت اجرا می‌شود نیست (هزینه زمان بیکاری سرور پرداخت نمی‌شود!) Domain Driven Designطراحی Domain Driven یا به اختصار DDD، یک رویکرد طراحی نرم‌افزار است که سال ۲۰۰۴ معرفی شد. یک رویکرد طراحی از بالا به پایین است. معرفی چند مفهوم به کار رفته در این معماری:دامنه(Domain)منظور از دامنه در توسعه نرم افزار، مفاهیم مرتبط با کسب و کار است. مفاهیمی که نرم افزار قرار است آن هارا پیاده سازی کند.معماری Domain Drivenدر طراحی نرم افزار، برای کاربر نهائی، تفاوتی ندارد که از کدام تکنولوژی‌ها یا زبان برنامه‌نویسی استفاده کرده‌ایم یا اینکه چقدر معماری تمیزی داشته‌ایم. باید در حین توسعه، علاوه بر دید تکنولوژی، از دید کاربر نهائی هم به مسئله نگاه کنیم."It’s not the customer’s job to know what they want" - Steve Jobsفهم نیاز کاربران، وظیفه آن‌ها نیستمعماری Domain Driven دو ابزار طراحی را معرفی ‌میکند:۱- طراحی راهبردی (Strategic design)۲- طراحی تاکتیکی (Tactical Design)طراحی راهبردی به ما کمک میکند تا مسئله را به دید مدل‌ها نگاه کنیم و حل کنیم. مشابه طراحی شی گرا. چند مفهوم مورد استفاده در طراحی راهبردی:۱. مدل - Modelتکه کد یا مستندی است که به منطق های اصلی و پایه‌ای نرم افزار مربوط می‌شود.۲. یکپارچگی زبان (Ubiquitous language)یک زبان مشترک بین اعضای تیم برای برقراری ارتباط بین فعالیت‌ها و مدل دامنه.۳. محدوده‌ی مفاهیم (Bounded Contexts)در توسعه به مرور ممکن است یک مدل بزرگ شود و نیاز به شکستن آن باشد، این مفهوم، یک سری توصیفات برای ایجاد مرزبندی میان مدل‌ها است.طراحی تاکتیکی (Tactical Design)درباره مسائل فنی و مربوط به پیاده سازی صحبت می کند.چیزهایی مثل سرویس‌ها، entities، repositories و factories.Hexagonal architectureاین معماری ساختار مشخصی برای جداسازی بین اپلیکیشن و اجزای مرتبط با اپلیکیشن تعیین می‌کند. منظور از اجزای مرتبط، استفاده کنندگان (Driving Side) و استفاده شونده‌ها (Driven Side) است.دو مفهوم به کار رفته در این معماری پورت(Post) و آداپتور(Adapter) هستند. در ادامه هرکدام از این واژه‌ها توضیح داده می‌شوند.پورت (Port)پورت‌ها در مرز ما بین اپلیکیشن و اجزای مرتبط قرار می‌گیرند. آن‌ها یک قالب مشخصی را تعیین می‌کنند برای ارتباطات. چه ارتباط اپلیکیشن با اجزای خارجی مانند پایگاه داده و یا ارتباط اجزای خارجی با اپلیکیشن مانند استفاده‌کنندگان از این سرویس.آداپتور (Adapter)آداپتور، وسیله ارتباط با اپلیکشن هستند به وسیله پورت ها. در واقع یک آداپتور، رابط پورت را پیاده سازی می‌کنند تا اپلیکیشن بتواند از آن‌ها استفاده کنند و یا اینکه با توجه به رابط اپلیکیشن، با اپلیکیشن ارتباط برقرار می‌کند.استفاده کنندگان(Driving Side) و استفاده شونده‌ها (Driven Side) ارتباطات بین اپلیکیشن و محیط بیرون دو نوع هستند.بازیگرهای اصلی یا استفاده کنندگان، آن‌هایی هستند که آغاز کننده ارتباط هستند و در سمت چپ شکل قرار می‌گیرند. برای مثال کنترل‌کننده‌ای که درخواست کاربر را گرفته و از طریق پورت به اپلیکیشن ارسال می‌کند.بازیگر ثانویه یا استفاده شونده‌ها، آن هایی هستند که توسط اپلیکیشن صدا زده شده و اجرا می‌شوند. مانند درخواست اپلیکیشن از پایگاه داده برای دریافت اطلاعات یک کاربر.پیاده‌سازیدر پیاده‌سازی این معماری:پورت‌ها معمولا به صورت interface تعریف می‌شوند.آداپتور های استفاده کننده، از یک پورت استفاده می کنند و اپلیکیشن نیز سرویس خود را با توجه به interface تعریف شده توسط پورت پیاده سازی کرده است.آداپتور های مورد استفاده توسط اپلیکیشن، interface یک پورت را پیاده سازی می‌کنند و سرویس اپلیکیشن از آن آداپتور استفاده می‌کنند.در هردو حالت پورت‌ها داخل فضای اپلیکیشن هستند و آداپتورها در بیرون قرار می‌گیرند.Event sourcingمعماری Event sourcing یک راهکار معماری نرم افزار که در آن حالت فعلی هیچ موجودیتی ذخیره نمی‌شود. بلکه حالت آن به وسیله تمامی رخدادهایی که برای آن موجودیت اتفاق افتاده است به دست می‌اید.در یک برنامه عادی وقتی وضعیت یک موجودیت را درخواست می‌کنیم( به طور مثال وضعیت یک سفارش)، آخرین وضعیت آن برگشت داده می شود و اتفاقات گذشته آن سفارش در دسترس نیست. ولی در این معماری، یک لیست از اتفاقاتی که برای موجودیت از ابتدای پیدایش تا حال برگشت داده می شود. وضعیت فعلی آن حاصل اعمال تمامی آن اتفاقات است.اجزای اصلی یک اپلیکیشن با معماری Event Sourcing:موجودیت‌ها (Entities)یک موجودیت مرتبط با یک دامنه خاص از نرم افزار است. تغییرات ان توسط رخدادها انجام می شود.رخدادها (Events)اتفاقی است که برای یک موجودیت خاص اتفاق افتاده، حاوی نوع تغییر و زمان رخداد است.انبار رخداد (Event Store)یک سرویس است که امکان افزودن رخداد مرتبط با یک موجودیت را فراهم میکند و همچنین دریافت لیست رخدادهای مرتبط با یک موجودیت.منابعmedium.com: Microservices Killer: Modular Monolithic Architectureyoutube.com: Mark Richards: Modular Monolith Architecturewikipedia.com: Amazon Web Servicespostman.com: Guide to API-firstamazon.com: What is NoSQL?geeksforgeeks.org: Types of NoSQL Databasesdatadoghq.com: Serverless Architecture Overviewgeeksforgeeks.org: Domain-Driven Design (DDD)medium.com: Hexagonal Architecture, there are always two sides to every storymedium.com: Event Sourcing

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

علی پیرپیران — Fri, 20 Oct 2023 21:52:06 +0330

معمار کیستبرای تعریف معمار، بیان شد که یک معمار ابتدا باید یک برنامه نویس باشد تا شناخت مناسبی از چالش‌ها و نحوه پیاده سازی یک نرم افزار داشته باشد. در ادامه کارش او بقیه تیم را راهنمایی می‌کند تا طبق یک ساختار مناسب پروژه را برنامه نویسی کنند.معماری نرم افزارمعماری نرم افزار باید به گونه ایجاد شود که قابلیت توسعه، تست، نگهداری و ایجاد یک تغییر در نرم افزار به راحتی قابل انجام باشد. برای این منظور نیاز است که کامپوننت های تشکیل دهنده نرم افزار به خوبی توسط معماری تشخصی داده شود و راه های ارتباطی آن‌ها مشخص شده باشد.یک معماری خوب، باید موارد زیر را در نظر گرفته باشد:توسعهاستقرارعملکردنگهداریتوسعهاستقراربرنامه نویس به اشتباه فکر میکند که طبق معماری میکروسرویس پیش برود به خاطر بعضی از مزیت هایی که در زمان توسعه کمک میکند ولی در موقع استقرار به مشکلاتی میخورد که قبلا در نظر نگرفته بود. استقرار یک معماری میکروسرویس کار نسبتا پیچیده‌تری است و باید از قبل به آن فکر میکرد.عملکردمعمولا با هر معماری میتوان با بهبود و ارتقا سخت‌افزار، عملکرد را بهود داد. یکی از دلایلی که معمولا ترجیه داده میشود که سخت افزار ارتقا داده شود: سخت‌افزار ارزان است ولی برنامه نویس گران است.انتخاب یک معماری مناسب میتواند عملکرد مورد نیاز را بهتر برای برنامه نویس توصیف کند. فهم بهتر سیستم، کمک میکند به توسعه و نگهداری در آینده.نگهداریبیشترین هزینه در ایجاد یک نرم افزار را دارد. شامل موارد زیر: افزودن ویژگی جدیدرفع مشکلات و باگ‌هادر آینده باید برنامه‌نویسان برای هر تغییر یا رفع باگ مجددا کد نوشته شده را برسی کنند و بهترین مکان را برای تغییر پیدا کنند. ایجاد تغییر ممکن است باعث ایجاد یک باگ در بخش دیگری از نرم افزار شود.راه حل: تقسیم سیستم به چند کامپوننت مجزاایجاد یک قالب مشخص برای کامپوننت‌ها، که کامپوننت‌ها برای برنامه‌نویسان یک ساختار مشخص و مشابه داشته باشند. در آینده بهتر میتوانند مکان لازم برای تغییر را پیدا کنند.نرم افزار از دو بخش ۱-ساختار و ۲-رفتار تشکیل شده است.واژه Soft در نرم‌افزار به قابلیت تغییر آن اشاره می‌کند. برای این منظور نیاز که به موارد زیر توجه داشت:ساختارنحوه قرارگیری کامپوننت‌هانحوه ارتباط کامپوننت‌هاهمچنین بخش‌بندی نرم‌افزار از منظر دیگر:سیاست‌ها - policyقوانین کسب و کارکارایی‌هاجزییات - detailبخش‌های توسعهبرنامه‌نویساننحوه پیاده‌سازینوع دیتابیسو …معماری باید وابستگی بین سیاست‌ها و جزییات را خیلی کم کند. به دلیل اینکه بتوانیم تصمیم‌گیری درباره جزییات را به تاخیر بیندازیم. چون جزییات مربوط به پیاده‌سازی است و ممکن است که نیاز شود تصمیم‌گیری هارا در پیاده‌سازی تغییر دهیم.مشابه آن در برنامه‌نویسی ایجاد یک Interface است و استفاده بقیه بخش‌ها طبق آن Interface و پیاده‌سازی آن بعدا توسط کلاس‌های متفاوت.Plugin Architectureدر این معماری، سیستم را به چند بخش مجزا تقسیم می‌کنیم که هیچ وابستگی به هم نداشته باشند. مرز بندی جاهایی انجام می‌شود که تغییرات زیاد است و دلیل تغییر نیز متفاوت است.سعی می‌شود که وابستگی‌ها از سطوح پایین به سمت سطوح بالاتر (هسته سیستم) باشد.مرزبندی میان مولفه‌هاهدف مرزبندی، ایجاد قوانین سخت گیرانه است که باعث می‌شود تغییر در یک بخش کمترین تاثیر را در بقیه بخش‌ها بوجود بیاورد. در ادامه چند روش معرفی می‌شود.ایجاد نظم در سطح کد منبع - بدون تقسیم کردن سیستمدر زمان پیاده‌سازی، صدا زدن توابع از سطوح پایین‌تر به سمت سطوح بالاتر انجام می‌شود. سیستم یکپارچه است بنابراین ارتباطات سریع و کم‌هزینه هستند.- پردازنده: مشترک- فضای حافظه: مشترک- ارتباط میان بخش‌ها: Function callایجاد مولفه‌های استقرارمولفه‌ها به صورت برنامه های قابل اجرا(Binary) ایجاد می‌شود. شبیه سیستم یکپارچه، ارتباطات سریع و کم‌هزینه هستند.- پردازنده: مشترک- فضای حافظه: مشترک- ارتباط میان بخش‌ها: Function callفرایند محلی - Local Process- پردازنده: مشترک - فضای حافظه: مجزا- ارتباط میان بخش‌ها: Socket, Message quesuesسرویس‌ها - Servicesقوی‌ترین سطح مرز بندی را دارد. هر سرویس یک فرایند هست. سرعت ارتباط پایین است بنابراین نیاز است تا جای ممکن میزان ارتباطات را کاهش داد.- پردازنده: مشترک/مجزا - فضای حافظه: مجزا - ارتباط میان بخش‌ها: از طریق شبکه(سرعت پایین)