نوشته های Nima.Sl

معماری نرم افزار در اینترنت اشیا

Nima.Sl — Fri, 10 Feb 2023 23:46:37 +0330

بسم الله الرحمن الرحیممعماری نرم افزار در اینترنت اش یا ( IOT )چکیدهاز زمان گسترش اینترنت اشیا، شاهد افزایش روز افزون طراحی معماری‌های گوناگون در حوزه اینترنت هستیم. تمام تلاش‌های صورت گرفته در طراحی معماری‌هایی می‌باشد که اقدام به برقراری ارتباط بین دستگاه ها و سرویس های مختلف IOT می‌کنند. یکی از مرسوم ترین نمونه از اینترنت اشیا ایجاد یک سیستم یکپارچه حمل و نقال در پاسخ به نیاز ها و شرایط ترافیکی در حال تغییر، مسیریابی و همچنین سازماندهی مجدد فرایند مسیریابی می‌باشد. در مراقبت‎های بهداشتی، اینترنت اشیا برای پیگیری بهبودی بیمار و ارزیابی آن در برابر تعداد‌ی از پارامتر ها ی منحصر به فرد بیمار با استفاده از دستگاه‌های دارای اینترنت اشیا ارزیابی می‌شوند. داده‌های جمع‌آوری شده همچنین می‌توانند برای مقایسه پاسخ های بیمار به درمان در زمینه های مختلف محیطی در مقیاس جهانی مورد استفاده قرار گیرند. از دستگاه های هوشمند اینترنت اشیا نیز می‌توان برای نظارت و کنترل مصرف انرژ ی استفاده کرد. در کشاورز ی و تولید مواد غذایی، اینترنت اشیا را می توان برای مدیریت تولید با نظارت و ردیابی متغیرهایی که بر تولید مواد غذایی تأثیر می گذارند مانند آب و هوا، شاخص های سیاسی-اقتصادی، بلایای طبیعی، مصرف، بیماری‌های محصول و حیوانات و غیره استفاده کرد .کلمات کلیدی: معماری نرم‌افزار در اینترنت اشیا، چارچوب، معماری سرویس‌گرا، معماری میکروسرویس1. مقدمهمعماری رایج در حوزه اینترنت اشیا، معماری سرویس گرا SOA می‌باشد که هدف آن ارائه سیستم‌هایی با قابلیت حداقل وابستگی به‌یکدیگر (loosly couple system) جهت استفاده چندباره از سرویس‌های گوناگون اینترنت اشیا می‌باشد. هدف اصلی به حداقل رساندن وابستگی سیستم‌ها، برطرف کردن و کاهش مشکلات یکپارچگی در لایه میانی سیستم‌ها و سرویس‌های اینترنت اشیا می‌باشد. یکی از کلیدی ترین مشکلات رایج در بحث یکپارچه‌سازی در اینترنت اشیا، فقدان یک چارچوب هوشمند و آگاه از اتصال برای پشتیبانی از تعامل در سیستم‌های اینترنت اشیا می‌باشد.مفهوم integrateability یعنی این اشیا ناهمگن باید بتوانند از طریق اینترنت و پروتکل‌های مختلف اقدام به برقراری ارتباط بپردازند. این اشیا می‌توانند یک مانیتور ارزیابی ضربان قلب باشند که به صورت implant داخلبدن بیمار قرار داده شده‌اند یا در مزرعه حیوانات به صورت یک سری فرستنده biochip باشد یا ربات امداد و عملیات یا هر شی طبیعی یا مصنوعی که توسط انسان ها ساخته شده‌اند تا با قبول کردن یک IP-Address مشخص از طریق زیرساخت های اینترنتی، اقدام به ارائه یکسری خدمات می‌کنند.2. معماری پایه در اینترنت اشیادر شکل 1 یک معماری پایه از سیستم های اینترنت اشیا مشاهده می‌شودمعماری لایه میانی لایه حسگر فیزیکی، دارای دستگاه‌های بلادرنگ می‌باشد که به وسیله سنسور‌ها، از جهان بیرونی اطلاعاتی را جمع آوری میکنند.این gateway برای دستگاه‌های مختلف پروتکل و مکانیزمی‌هایی را فراهم می‌کند تا اطلاعات sense شده از محیط را از طریق بستر اینترنت به نمایش گذاشته شود. این ارتباط از طریق پروتکل های ارتباطی مثل WIFI, Ethernet, GSM می‌باشد. البته این ارتباط در لایه gateway بیشتر از طریق یک پروتکل معروفی به نام GSM (Global System for Mobile Communications) میباشد که مجموعه استانداردی از ارتباطات بین موبایلی با 2G network را فراهم می‌نماید. لایه میانیIOT یا همان middle-ware layer ارتباطات بین فعالیت های حس شده در دنیایواقعی توسط سنسور‌ها و لایه اپلیکیشن را تسهیل می‌کند. لایه میانی پارامتر‌های مختلفی دارد مثل کیفیت سرویس یا Qos(quality of service) که اقدام به ارزیابی کیفیت خدمات عملکرد تلفن، خدمات شبکه کامپیوتری یا ابر و ابزارهای فناوری‌هایی را که توانایی شبکه را برای اجرای عملیات با اولویت بالا تضمین می‌کنند را اندازه گیری می کند. لایه اپلیکیشن map می‌شود به application هایی که توسط کاربر استفاده می‌شوند جهت ارسال دستور به اشیا در دنیای واقعی از طریق application های موبایلی و همچنین webapp ها و غیره.اینترنت اشیا در صنایع بزرگ به یک trend مبدل شده است. به عنوان مثال شرکت Samsung در بیانیه خود اعلام کرده بود که تا سال 2017 به تعداد 90% و تا سال 2020، 100% دستگاه های آن دارای خدمات مختلف اینترنت اشیا خواهند شد که این امکان را در گوشی‌ها و تبلت‌های هوشمند خود از طریق اپلیکیشن که قابلیت برقراری ارتباط با سیستم عامل‌های مختلف بود را با نام SmartThings منتشر کرد.برنامه SmartThingsهمچنین آقای گارتنر پیشبینی کرده بود که تا سال 2020 بیش از 21 billion دستگاه مجهز به خدمات اینترنت اشیا خواهند شد.اما یک مشکل وجود دارد، سایز ناهمگن بودن زیاد این دستگاه ها، موجب ایجاد مشکلاتی از قبیل integration و ایجاد ارتباط با توجه به موقعیت جغرافیایی متفاوت و همچنین platform ها و دستگاه های مختلف با یکدیگر شده است. این ها بخشی از مشکلاتی می‌باشند که یک معمار نرم افزار برای طراحی یک معماری و framework برای تعداد زیادی از دستگاه ها در حوزه اینترنت اشیا باید مد نظر خود قرار دهد.معماری سرویس‌گرا (SOA) یک چارچوب قدرتمند برای پشتیبانی از connectivity، interoperability و همچنین integration در سیستم‌های اینترنت اشیا ارائه می‌دهد، که ستون فقرات frameworks های اینترنت اشیا امروزی را تشکیل می‌دهد. در حالی که اهداف SOA در درجه اول افزایش قابلیت همکاری(interoperability) برنامه های اینترنت اشیا می‌باشد، استفاده یکپارچه از آن در چارچوب های اخیر اینترنت اشیا مشکل مقیاس پذیری تشدید می‌کند.به منظور این که framework اینترنت اشیا قابل اعتماد(dependable) و قابل اتکا(reliable) باشند باید حداقل یک سری پارامترها و معیارهای قابل ارزیابی وجود داشته باشند تا دو موضوع integration و همچنین interoperability را در اینترنت اشیا قابل دستیابی کنند. البته برای بحث یکپارچه سازی یکسری تاکتیک وجود دارند که جلوتر به آن‌ها اشاره خواهد شد. مثل orchestration & manage resource و restrict communication paths و همچنین abstract common services.1.2 معیار‌های ارزیابی در چارچوب‌های معماری اینترنت اشیا:معیار اول: Contract decoupling، از آن جایی که میلیون‌ها دستگاه مجهز به فناوری اینترنت اشیا به صورت سیستم‌ها با سخت و نرم افزار‌های مختلف و همچنین به صورت ناهمگن در سراسر جهان پخش می‌باشند، فریم ورک باید مشکل Contract decoupling را حل کند، یعنی توانایی سرویس مصرف کننده(کاربر) و تولیدکنندگان سرویس بتوانند به صورت مستقل ایجاد و اعمال تغییرات کنند بدون اینکه ارتباط بین آن‌ها قطع شود، فرض کنید یکی از سرویس‌هایی که خدمات می‌دهد فرمت JSON دارد ولی سرویس یکی از کاربران ما نیاز به ورودی XML دارد فریم ورک مربوطه باید بتواند از این مورد خاص به صورت کامل پشتیبانی کند.معیار دوم: Scalability، همان بحث شرکت سامسونگ که در فاز اول 90% و فاز بعدی 100% دستگاه های خود را مجهز به فناوری اینترنت اشیا کرد و فریم ورک مربوطه باید بتواند این موضوع را مدیریت کند که وقتی جمعیت تعداد کاربران از 1 میلیون نفر به 1 میلیارد رسید، فریم ورک مربوطه به مشکل بر نخورد.معیار سوم: Ease of testing، فریم ورک مربوطه باید به راحتی debugging و تست شود و ما باید به راحتی بتوانیم defect ها یا fault هایی که قرار است به failure تبدیل شوند را شناسایی کنیم و قابلیت های مهم در حوزه‌ های مختلف تست مانند:integration testing, component testing, system testing, compatibility testing, installation test, functional and non-functional testing, performance testing, security testingمعیار چهارم: Ease of development، فریم ورک باید قابل توسعه به صورت آسان باشد و شامل مستندات و documentation های مناسب برای افراد فنی و غیر فنی باشد تا هم برنامه نویسان و هم سایر ذینفعان بتوانند بخش‌های درونی فریم ورک را به راحتی درک کنند.معیار پنجم: Lightweight implementation، فریم ورک باید سبک باشد در زمان development and deployment.معیار ششم: Service coordination، باید تصمیم گیری انجام شود درمورد نحوه تعامل سیستم‌ها با یکدیگر از طریق orchestrationیا choreography.:Fault toleranceفریم ورک مربوطه باید قابل اعتماد و انعطاف پذیر باشد. یک فریم ورک جهت یکپارچه سازی هوشمند باید به طور موثری faultها را مدیریت کند زیرا دستگاه های اینترنت اشیا در نهایت می‌توانند بین حالت‌های آفلاین و آنلاین جابجا شوند یعنی در بعضی مواقع خاموش هستند و مواقعی هم روشن یا باتری تمام می‌کنند.Fault Toleranceو همچنین فریم ورک باید مکانیزم self-healing داشته باشد برای fault های موقتی مثل network faults, وnode level faults. همچنین خطای دسترسی غیرمجاز یا server crash failure یا حتی یک خطای دیگری که میتوان اشاره کرد failure omission که برای وقتی است که سرور مبدا هیچ incoming request را دریافت نمیکند از سرور مقصد. 3. چارچوب‌های اینترنت اشیا:1. چارچوب اول: Eclipse Smarthome Frameworkاین Eclipse Smart Home (ESH) درواقع یک فریم ورک connection and integration برای خانه‌های هوشمند مجهز به اینترنت اشیا می‌باشد. این فریم ورک مستقل از ویژگی های اتصال سخت افزار می‌باشد و همچنین بر اجرای یک اتصال دهنده به چارچوب تاکید می‌کند که به این connector، binding گفته می‌شود و انتظار می‌رود که حداقل یک بار و تنها یک بار برای یک پروتکل ارتباطی خاص پیاده‌سازی شده است.این فریم ورک ESH بسیار مشهور و متن باز (open source) می‌باشد زیرا توسط تکنولوژی openHAB پیاده سازی شده است. این platformبه عنوان مرکز خانه هوشمند شما اجرا می‌شود و توانایی یکپارچه سازیدستگاه‌های مختلف در خانه هوشمند شما را دارد و توسط فروشگاه‌های بزرگ برای تعداد زیادی از خانه‌های هوشمند نصب شده است. ESH بر 5 ویژگی تاکید می‌کند:یک: Operating Systemکمک می‌کند تا روی سیستم عامل‎‌های مختلف به راحتی اجرا شوند مثل: Windows, macOS, Linuxدو: The Application Container or Runtime Environmentبه طور کامل در جاوا نوشته شده است و از Runtimes (Eclipse Equinox) OSGi استفاده می‌کند.مفهوم Open Services Gateway Initiative (OSGi)، به عنوان سیستم پویای ماژول برای جاوا شناخته می‌شود که توانایی این چارچوب را برای توسعه برنامه‌های کاربردی ماژولار آسان می‌کند.از نقطه نظر کد، Eclipse Equinox™پیاده‌سازی مشخصات چارچوب اصلی OSGi می‌باشد که مجموعه‌ای از package ها که سرویس‌های اختیاری مختلف OSGi و زیرساخت‌های دیگر را برای اجرای سیستم‌های مبتنی بر OSGi پیاده‌سازی می‌کنند. درواقع کاربرد آن اجرای OSGI در محیط نرم افزار Eclipse می‌باشد.سه: Data Management and Messagingرویکرد SOA در ESHبرای پیاده‌سازی از یک Event Bus استفاده می‌کند که قابلیت دسترسی از محیط بیرون را دارد و از پروتکل های SSEو MQTT استفاده می‌کند. همچنین ساختار ESH دارای مکانیزم‌های ماندگاری برای database storage می‌باشد.چهار: Remote Managementفریم ورک ESH طوری طرای شده است که به راحتی می‌توان خانه خود را از راه دور نظارت و monitor کرد.چارچوب دوم: Calvin Frameworkیک فریم ورک ترکیبی می‌باشد که از IOT و Cloud Programming استفاده می‌کند و بیشترین کاربرد آن در صنعت بهداشت و درمان می‌باشد.این فریم ورک برای توصیف پروتکل‌های مختلف از یک declarative language به نام CalvinScript استفاده می‌کند.درdeploability این فریم‌ورک توجه ویژه‌ای به پیاده‌سازی توزیع شده در زمان runtime environmentدارد. این فریم‌ورک توجه ویژه‌ای ‌بهlocality, performance requirements, connectivity وrequirements and resources دارد که به راحتی سربار و اضافه بار در زمان اجرا را کاهش می‌دهد.در واقع این فریم ورک از cloud computing برای اجرای محاسبات پیچیده در دستگاه‌های مختلف بیمارستانی که توزیع شده هستند استفاده می‌کند و می‌تو‌اند به صورت همزمان با استفاده از Cloud system اقدام به آپدیت نرم افزاری دستگاه‌های توزیع شده کند که در بخش‌های حساسی مثل مراکز درمانی از اهمیت خاصی برخوردار می‌باشند. یکی از توانایی های این فریم ورک، process هایی که منابع زیادی را مصرف می‌کنند همانند image processing را محدود می‌کنند.چارچوب سوم: SOCRADES frameworkSOCRADES یک معماری یکپارچه‌سازی مبتنی بر سرویس است که components های عمومی را برای کمک به مدل سازی فرآیندهای دقیق ارائه می‌دهد. همچنین این فریم ورک از وب سرویس‌های مایکروسافت به نام DPWS برای ارتباط با لایه میانی یا همان middle ware layer (که در بخش2 مطرح شد) استفاده می‌کند.این فریم ورک بیشتر برای سیستم‌های ناهمگن کاربرد دارد. Enterprise Application componentآن یک رابط کاربری گرافیکی GUI آسان برای استفاده را در اختیار کاربران قرار می‌دهد و در نتیجه مدت زمان deployment را کاهش می‌دهد و مدیریت سیستم را سهل و آسان می‌کند.چارچوب چهارم: AllJoynیک چارچوب open source می‌‎باشد. هدف اصلی آن connection و integration صرف نظر از ماژول‌های مختلفی که بایکدیگر در ارتباط هستند و همچنین سیستم عامل‌های مختلف.این چارچوب برای انتزاع و سادگی بیشتر از یک API استفاده می‌کند برای کشف شبکه بین دستگاه‌ها و همچنین پیچیدگی کشف دستگاه‌های مجاور از طریق ایجاد session مثل(multiple, group, point to point session) بین دستگاه‌ها برای تیجاد ارتباط امن بین آن‌ها فراهم می‌کند.این چارچوب به صورت کلی شامل سرویس‌ها و interfaceهایی هست که توسط توسعه دهنده‌ها برای یکپارچه کردن برنامه‌ها و دستگاه‌ها به کار می‌رود. این چارچوب بیشتر بر بستر local network اجرا می‌شود ولی قابلیت اجرا بر بستر cloud را نیز دارد و تمام دستگاه‌ها از طریق یک gateway با دنیای اینترنت ارتباط برقرار می‌کند.چارچوب پنجم: FRASAD(FRAmework for sesor Application Development)این چارچوب برخلاف مدل‌های قبلی مبتنی بر model driven می‌باشد پس کد برنامه تولید شده از یک مدل از پیش طراحی شده تولید می‌شود.این چارچوب در واقع یک افزونه(extension) می‌باشد که که اقدام به افزودن و یکپارچه کردن 2لایه APLیا همان Application Layer و OALیا همان Operating System Abstraction Layer می‌باشد که هدف اصلی این 2لایه ایجاد یک سطح انتزاع برای پنهان کردن جزئیات می‌باشد.این چارچوب از (MDA) Model Driven Architectureطبعیت می‌کند که به عنوان یک رویکرد طراحی نرم‌افزار کمک می‌کند چارچوب FRASAD یک مرز بین application logic و business logic قائل شود. استفاده از MDA این قابلیت را به چارچوب FRASAD می‌دهد که با تکنولوژی‌های مختلف مانند J2EE و همچنین .NET می‌توان پیاده سازی کرد.چارچوب ششم: AVIOTیکی دیگر از چارچوب‌ها برای خانه‌های هوشمند و شهر هوشمند می‌باشد که بر خلاف سایر چارچوب‌ها بحث سه بعدی 3D و بصری سازی در آن مطرح می‌باشد. یکی دیگر از مزایای این چارچوب که می‌توان اشاره کرد، کاربر نهایی یا همان end user می‌تواند به راحتی و بدون داشتن دانش قبلی از معماری یا ارتباط سیستمی سنسور‌ها اقدام به تغییر پنل کاربری نماید و عملا پنل را برای خود سفارشی سازی کند. زبان پیاده سازی این چارچوب یکی از زبان‎‌های scripty می‌باشد و همچنین این چارچوب بر بستر وب پیاده سازی شده است. 4. معماری میکروسرویس1.4 شناسایی و طبقه بندی خدمات سرویس هامعماری میکروسرویس به 2 دسته تقسیم می‌شود: 1. Functional Services 2. Non-Function Serviceمفهوم اول Functional Services: به این معنی است که خدمات توسط یک سیستم یا دستگاه خارجی مورد استفاده قرار میگیرند.مفهوم دوم Services Non-Function: مربوط به عملکرد مورد اعتماد سیستم می‌باشد مثل مباحث ورود و امنیت: authentication, monitoring, authoring, auditing Logging,.ارتباط این 2 مفهوم با لایه میانی معماری اینترنت اشیا به صورت زیر می‌باشد:2.4 مفهوم Service Atomityدر میکروسرویس‌ها، تأثیر سرویس‌های ریز به توسعه، آزمایش، استقرار و نگهداری نرم افزار کمک می‌کند. ارتباط این سرویس‌های ریزدانه بین دستگاه‌های مختلف توسط پروتکل‌هایی مانند MQTT, AMQP برقرار می‌شود.این سرویس‌های ریزدانه در عملکرد performance و مدیریت تراکنش‌ها مشکل ایجاد می‌کند. فرض کنید طبق شکل پایین، تراکنش بانکی به سه سرویس A,B,Cنیاز داشته باشد مجموع زمان پردازش هر یک از سرویس‌ها به تریب TA, TB, Tc باشد و هریک 100میلی ثانیه طول بکشد مجموعا 300 میلی ثانیه طول می‌کشد تا برای انجام یک تراکنش سرویس ما اقدام به ارائه سرویس‌ها در زمان کافی به Service consumer کند.در نتیجه با به کارگیری یک Service Assembler اقدام به پردازش و توزیع سرویس‌ها کرده و مدت زمان مصرفی توسط سرویس ها را کاهش می‌دهد، درنتیجه یک سطح از انتزاع ایجاد می‌کند به عنوان مثال یک سرویس به نام X ارائه می‌دهد و service consumer به راحتی از سرویس Xاستفاده می‌کند.3.4 مفهوم Interoperability in IoTدر معماری میکروسرویس از API Layer به جای ESBاستفاده می‌شود. یکی از مزایای API Layer ، یک سرویس دانه درشت را می توان به سرویس های دانه‌ ریزتر تقسیم کرد یا بالعکس.به واسطه API Layer می‌تواند REST API های مختلفی را ایجاد کرد و از طریق پروتکل‌های مختلف با دستگاه و سیستم و سنسورها ارتباط برقرار کنندبه واسطه این رویکرد می‌توان به راحتی بخشی از کاستی های معماری سرویس گرا در availability, performance, scalability را کاهش داد.این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی می‌باشد.منابع:The Internet of Things Needs Openness and Industry Collaboration to Succeed, Says Samsung ElectronicsAllseen Alliance (2016): AllJoyn Framework. Available at https://allseenalliance.org/framework/Rajkumar Buyya & Amir Vahid Dastjerdi (2016): Internet of Things: Principles and Paradigms, pp. 79–102.Shanzhi Chen, Hui Xu, Dake Liu, Bo Hu & Hucheng Wang (2014): A Vision of IoT: Applications, Challenges, and Opportunities With China Perspective. IEEE Internet of Things Journal 1(4), pp. 349–359Yuna Jeong, Hyuntae Joo, Gyeonghwan Hong, Dongkun Shin & Sungkil Lee (2015): AVIoT: Web-based interactive authoring and visualization of indoor internet of things. IEEE Transactions on Consumer ElectronicsDongsik Jo & Gerard Jounghyun Kim (2016): ARIoT: scalable augmented reality framework for interacting with Internet of Things appliances everywhere. IEEE Transactions on Consumer ElectronicsXuan Thang Nguyen, Huu Tam Tran, Harun Baraki & Kurt Geihs (2015): FRASAD: A framework for modeldriven IoT Application Development. In: Internet of Things (WF-IoT), 2015 IEEE 2nd World Forum on, IEEEPer Persson & Ola Angelsmark (2015): Calvin–Merging Cloud and IoT. Procedia Computer ScienceJohn A. Stankovic (2014): Research Directions for the Internet of Things. IEEE Internet of Things JournalA Software Architecture to enable Self-Organizing, Collaborative IoT Ressource Networks

حافظه Heap & Stack به زبان ساده :)

Nima.Sl — Fri, 30 Dec 2022 23:42:57 +0330

وقتی یک applicationجاوا اجرا میشود دقیقا چه اتفاقی در پشت صحنه می افتد؟ من میخوام در این ویرگول درمورد object ها و heapو stack صحبت کنم.وقتی شما یک کلاس را تشکیل میدهید بلافاصله یک متد mainساخته میشود. اگر شما روی دکمه run کلیک کنید، 2 عدد memory location ،ایجاد (reserve) میشوند درست بعد از run کردن application. این ها در واقع منابع کامپیوتر شما یا همان stackو heap میباشند.حافظه Stackبعد از run کردن برنامه یا application داخل Eclipse داخل stack یک فریم تشکیل میشود به نام تابع اصلی کلاس ما (یا همان متد main):تمام variable هایی که داخل متد main ایجاد میشوند، local variable یا متغیر محلی نام دارند. پس اگر ما یک متغیر سن را ایجاد کنیم ;int age داخل فریم تابع main یک بخش کوچکی را به خود اختصاص میدهد.فرض کنید در خط بعدی، یعنی بعد از تعریف متغیر ageیک متد دیگری داخل متد main فراخوانی شده باشد:public class Car{public static void main(String[] args){int age = 15;doWork(); }}که بلافاصله داخل stackیک فضا ذخیره میشود به نام این متد و اگر متغیری به نام weightداشته باشد در داخل آن قرار میگیرد و اگر داخل خود متد () doWork متد دیگری به نام ()doMore فراخوانی شده باشد باز هم در stack یک فضا به آن متد اختصاص داده میشودpublic static void doWork(){ int weight; doMore();}بعد از این که متد ;()doMore و همچنین متد ;()doWork به پایان رسیدند از داخل حافظه stack حذف یا به اصطلاح pop میشوند، و اگر به آن ها نیاز باشد و در خطوط بعدی برنامه مجدد فراخوانی شوند، به راحتی مجدد به داخل حافظه stack وارد(push) میشوند:حافظه Heapحالا فرض کنید در خط بعدی برنامه ما یک reference variable ایجاد کنیم در متد main:public class Car{public static void main(String[] args){int age = 15;doWork();Car myCar;}}متغیر myCarبه یک actual object اشاره میکند. دقت کنید ما فعلا چیزی را assignنکردیم و صرفا یک متغیر تعریف کردیم:وقتی ما این متغیر جدید را assign کنیم، یعنی وقتی از واژه new استفاده میکنیم، در واقع، داخل حافظه Heapیک object به نام carایجاد میشود که این متغیر myCar به آن اشاره میکند:public class Car{public static void main(String[] args){ int age = 15; doWork(); Car myCar; myCar = new Car(); }}اما باید به این نکته توجه داشت که متغیر myCar مستقیم به car object اشاره نمیکند و به آدرس آن در حافظه که Heap نام دارد اشاره میکند، در واقع متغیر myCar یک memory address، میباشد که assign شده است به آدرس object نه خود object اصلی. ولی در متغیر محلی مثل age وقتی ما عدد 15 را داخل آن قرار دادیم متغیر محلی age خود دیتا اصلی را دریافت کرد در حالی که در reference variableها آدرس یک object به آن ها نسبت داده میشود نه خود object.وقتی که اجرای این خط از برنامه myCar = new Car(); تمام شد یا object جدیدی ایجاد شد خطی که از متغیر myCar به سمت object اول car اشاره میکند پاک شده و به object جدید اشاره میکند و car object اول توسط Garbage collection بلعیده میشود :)یک مثال دیگر، فرض کنید یک کلاس ساده car داریم که داخل آن یک instance variable برای اسب بخار ماشین یا همان hp داریم. وقتی 2 عدد object از کلاس car داخل کلاس اصلی ایجاد کنیم یعنی:Car my2car = new Car();Car my3car = new Car();آن متغیر instance variable این بار داخل حافظه Heap به عنوان بخش کوچکی از car object تشکیل میشود:و داخل حافظه stack هم همانطور که اشاره کرده بودیم 2 متغیر ایجاد میشوند که به آدرس این object ها اشاره میکنند.ممنون بابت وقتی که گذاشتید :)

بیست مفهوم مهم در معماری نرم افزار

Nima.Sl — Mon, 28 Nov 2022 19:50:32 +0330

به نام خدا1. مفهوم Domain Driven Design: اولین تعریفی که میتوانم بگویم Domain Driven Design یک دیدگاه به نرم افزار است از بالا پایین. وقتی که تیم توسعه به دنبال توسعه نرم افزار میباشند، باید دقت شود که اولویت اول و اصلی ما انتخاب تکنولوژی نیست (مشابه جمله عمو باب در کتاب معماری تمیز) بلکه اولویت اول ما business هست.وقتی معماری یک پروژه را در نظر بگیریم از لحظه ای که از کد خروجی گرفته ایم با پسوند های مختلف مثلا برای جاوا .jar و ..... تا موقعی که به بالاترین سطح یعنی پروژه میرسیم یک سطح از انتزاع را میبینیم مثل شکل:که کل این ساختار را میتوان Service نامید. اما تا این مرحله، این نما دید اکثر برنامه نویسان میباشد، ولی اگر بخواهیم یک دید سطح بالاتری را اتخاذ کنیم و چند Service مختلف را کنار هم قرار دهیم، از اجماع این سرویس ها بخشی از زیرساخت را تشکیل میدهند که برای حل برخی از مشکلات اساسی و مهم تر که در اول مطلب اشاره کردم یعنی مشکل لایه business میباشد. از مجموعه این سوریس ها domain تشکیل میشود.در واقع همه ی این سرویس ها که درکنار هم قرار گرفته اند بخشی از مشکلات domain را حل میکنند که به آن ها Sub-Domain گفته میشود. ما domain های مختلفی داریم اگر بخواهیم domain e-commerce در نظر بگیریم Sub-Domain میشود product domain یا customer domainو... .در اول مطلب یک تعریف بالا به پایین بیان شد که در شکل بالا domain در راس(top) همه ی سرویس های ما قرار دارد. Domain Driven Design دو ابزار در اختیار ما قرار میدهد، اولی Strategic design tools میباشد که به کمک آن میتوان تمام مشکلات مربوط به Software Modeling میباشدو ابزار دوم Tactical design tools هست که بیشتر مهندسان نرم افزار و توسعه دهنگان به این بخش توجه زیادی دارندو در آخر ابزار Strategic design tools بسیار مهم و حائز اهمیت میباشد و ما به کمک Domain Driven وDesign شروع به حل مشکلات میکنیم در مقیاس بالا و دید انتزاعی تر (مشابه عمو باب) مثلا سیستم عامل ویندوز 10 از ویندوز 8 خیلی بهتر کاربردی تر میباشد در واقع ما باید نیاز های مشتریان و به طور کلی ذینفع ها در لایه بیزینس را مد نظر داشته باشیم.مفهوم Hexagonal Architecture :در شکل زیر هر لایه که در انتهای فلش قرار داشته باشد از لایه قبلی خود هیچ اطلاعی ندارد یعنی در این جا لایه data access از لایه business logic اطلاعی ندارد.حالا اگر جهت فلش تغییر کند و وابستگی تغییر کند باز هم business logic روی data access تاثیر میگذارد از طریق یک interface که توسط logic تعریف میشودکه انتظار میرفت در لایه data access تعریف شود. این interface، port نامیده میشود و لایه data access میداند که به چه صورت این interface را implement کند که به آن adapter گفته میشود.ولی به طور کلی این معماری به جای port and adapter به نام Hexagonal Architecture شناخته میشود.در واقع ما اطراف application core خود adapter های زیادی داریم.و به این معنی هست که application core دارای هیچگونه وابستگی نیست و adapter های مختلف به آن وابسته هستند و به راحتی میتوان تست برای application core نوشت.فرض کنید Adapter هایی مثل user interface & API & Command line میتوان primary نامید چون تاثیر مستقیم در core میگذارند و Adapter هایی مثل data access & email & message queue میتوان secondary نامید زیرا لایه core تاثیر مستقیمی روی آن ها میگذارد.میتوان به لایه های مختلفی تقسیم بندی کرد لایه application که وابستگی ها همیشه به سمت داخل هستند. همه این adapter ها در لایه application در دو قسمت presentation & infrastructure و در مرکز بدون هیچ وابستگی domain که همان core business object ما هست(در فصل 22 کتاب معماری تمیز). همچنین interface هایی همچون domain services & IRrepository & IUnitOfWorkds همه این ها همان port هایی هستند که انتظار میرود implement شوند توسط adapter در لایه infrastructure. و لایه بالای interface ها مربوط به یکسری service ها میباشد.در بحث معماری تمیز مشابه شکل صفحه 203 کتاب معماری تمیز شکل بالا را به صورت معماریتمیز clean architecture ترسیم میکنیم:مفهوم (Command Query Responsibility Segregation) CQRS:به این معنی هست که شما یک data را مینویسی ولی هنگام بازیابی کردن همان data روشی متفاوتی را اتخاذ میکنی. در ادوار گذشته شما یکجا data را put و جای دیگر get میکردی به دلیل داشتن CRUD Operation یعنی شما write & read میکنید دقیقا از یک data-source یا وقتی تعداد write & read ها زیاد میشه و نیاز است تا یک شکافی ایجاد شود بین این حجم از خواندن و نوشتن ها.اگر شما از Event Sourcing System استفاده کنید برایquery نوشتن در سیستم به مشکل بر خواهید خورد زیرا برای ساختن state application شما باید به همه ی event ها بروید تا یک single application وstate را بدست آورید و برنامه شما در بحث quality attributes مثل performance به مشکل بر خواهد خورد زیرا در زمان run-time باید به صورت مرتب در event های مختلف search انجام دهد.پس علت اصلی ما در استفاده از CQRS Pattern شما به راحتی میتوانید query های read & writeرابه صورت Componentهای شخصی جداسازی(Segregate) و تفکیک کنید پس یک read operation و write operation خواهیم داشت که این تفکیک و operationهای مجزا کمک به load سریع برنامه و به صورت مستقل scalabilityبالایی برخوردار خواهد شد.یک مثال از CQRSکه در آن سه نوع سرویس مختلف داریم که به روش Event Sourcing باید از همه ی سرویس ها لاگ بگیریم درحالی که با قرار دادن یک functionality به نام Orders Overview میتوانی تمام query ها را در یکجا collect کنید و در اختیار مشتری قرار دهید:مفهوم Event Sourcing:یک معنی جایگزین برای Storing Data میباشد با استفاده از لاگ هایی از event ها به جای استفاده از table ها که میتوان در آن ها از update & read & delete استفاده کرد.در Event Sourcing جدولی طراحی میشود که در آن اتفاقاتی اعم از update & read & delete روی میدهند به صورت دقیق ضمیمه و ثبت میشوند.البته باید این نکته را مدنظر قرار داد reading data در Event Sourcing دارای step های اضافی هست. ادامه توضیحات با توجه به شکل بیان میشود:ابتدا داده ها خوانده شده در مورد 1و2 شکل و سپس event ها با هم ترکیب شده در زمان run-time و دقیقا به همان نقطه ای که اطلاعات قرار دارند هدایت میشوید مورد 3 در شکل بالا، نکته ای که حائز اهمیت است دیتا های ما به صورت فیزیکی به فرمت event ذخیره شده اند و درصورت فراخوانی، تمام ویژگی ها و موارد آن ها نیز فراخوانی خواهد شد و در مقیاس بزرگ با مشکل متفاوتی روبه رو خواهیم شد و این به این دلیل هست که از یک مدت زمانی به بعد تعداد event ها به شدت زیاد میشود و در زمان run-time گرفتن execute از داده ها کار زمان بری خواهد شد. راه حل این مشکل اجرای محاسبات در زمان نوشتن اطلاعات میباشد نه در زمانی که میخواهیم داده ها را write و ذخیره کنیم و از مزایای این روش این است که محاسبات روی داده ها فقط یکبار آن هم درزمان نوشتن انجام میشود و مهم نیست داده ها در زمان های دیگر چند بار read شوند که به این تکنیک CQRS گفته میشود که در صفحات قبل به صورت کامل توضیح داده شده است ?.مفهوم MVVM:در واقع یک Design Pattern هست که در مواقعی که کد های ما قابل استفاده مجدد یا reusable هستند یا نیاز به maintain و نگه داری دارند استفاده میشود. یکی از استفاده های کلیدی آن در مواقعی هست که شما در حال توسعه یک application روی platform های متفاوت هستید به عنوان مثال استفاده از framework Flutter که میتواند روی platform مختلف کد های منبع خود را run کند.به عنوان مثال در android & ios & windows، پس شما با MVVM میتوانید کل View model به اشتراک بگذارید در تمامی platform های ذکر شده. تنها بخشی از MVVM است.که نیازمند platform-specific code است همان بخش View هست تا بتواند UI مورد نظر را در platform ها یمختلف به صورت مناسب نمایش دهد.به عنوان مثال در مورد ماژول هایی صحبت میکنیم که در نهایت قابل تطابق با MVVM Design Pattern میباشد.· یک:View همان UI هست یعنی آن چیزی که کاربر روی صفحه نمایشگر خود میبیند.· دو: View Model منطق برنامه ما هست که به ازای ورودی application یک Expected result به نمایش میگذارد.· سه: Model: همان data هستکه این ماژول ها با همدیگر ارتباط دارند:اما تعریفی مختصر از data binding:وقتی استفاده میشود که درخواست ایجاد ارتباط بین Logic & User-Interface اتفاق میافتدکه User-Interface شامل Dependency Object و Logic شامل Object میباشد، که دارای دو نوع ارتباط میباشند:در ارتباط اول One-Way فقط و فقط Object قادر به تغییر اطلاعات میباشد، ولی در ارتباط Two-Way هر دوطرف قادر به ایجاد تغییرات هستند.اما interface که ما مقابل Notifications استفاده میکنیم شامل INotifyPropertyChange میباشد که هر کدام از data های مربوط به برنامه تغییر کرد notify و اطلاع دهد به عنوان مثال وقتی برنامه از سیستم عامل اندروید به ios تغییر کرد و دومی ObservableCollection میباشد که دسترسی تغییرات در سطح کلاس یا combine کردن آن ها را به ما میدهد.مفهوم Micro-Frontends:درواقع یک رویکرد برای تست کردن Micro-service ها میباشد یا کدی برای بخشی از یک صفحه وب است. در این مدل صفحه وب host میکند آن component را و میتوان آن را Host page نامید. یک فریمورک Micro-FE FrameWork وجود دارد که بین Host page و Micro-Frontends قرار میگیردتا load ها و unloading ها را مدیریت کند.یک تعریف ساده تر این است که Micro-Frontends بخش Front-End را به بخش های کوچکتر با قابلیت مدیریت بیشتر و بهتر تقسیم میکند و این امر باعث خوشحالی توسعه دهندگان در امر توسعه نرم افزار میشود. وقتی که ما به این وبسایت آمازون نگاه میکنیمیکسری user-interface element میبینیم که تارگت Micro-Frontends میباشد، درواقع همان پنل های میانی که در شکل مشخص شده:و همچنین بخش header & footer سایت هم تارگت مناسبی برای Micro-Frontends میباشد زیرا باید بین صفحات مختلف سایت به اشتراک گذاشته شوند. رفتن به سمت Micro-Frontends یکسری مزیت های جالبی دارد:1. یک: Team Scalability: کمک میکنه به ما که افراد بیشتری به عنوان توسعه دهنده و برنامه نویس بتوانند روی web-page کار کنند. Micro-Frontends کمک میکند که ما بتوانیم بخش های مختلف سایت را به صورت تیم های مجزا deploy & develop کنیم.در واقع این رویکرد به ما کمک میکند تا بین وظایف مختلف خط بکشیم و در زمینه های مختلف معماری تعریف کنیم و کمک میکند به تیم تا کار خود را handle کند به طور مستقل1. دو: Reusability : فرض کنید شما یک ماژول جذاب در بخش UI در Home-Page خود را دارید میتوانید به راحتی در بخش About Us نیز استفاده کنید2. سه: Digital Experiences: به کمک Micro-Frontends میتوانیم کد های front-end را تحت کنترل داشته باشیم تا بتوانیم تجربه دیجیتالی فوق العاده ای را برای کاربران به ارمغان بیاوریم.3. چهار: Different Technology: ما به کمک Micro-Frontends میتوانیم در بخش های مختلف کار از تکنولوژی های متفاوتی استفاده کنیم و code base های آن را از هم جدا کنیم. در نهایت هر component کار خود را به طور مستقل انجام میدهد.4. پنج: Share Common Structure: در واقع به این معنی است که ساختار های مرسوم و معمول را بین صفحات مختلف application یا web site به اشتراک میگذارد مثل Header & Footer & Page Navigation & Authentication5. شش: Decoupling: به سازمان ها امکان scalable ownership محصولات دیجیتالی را میدهد تا امکان تولید کد های Decouple شده با کد repository کوچک با قابلیت نگهداری بالا. این Decoupling به توسعه دهندگان کمک میکند تا عناصر خاصی از جمله build برنامه test برنامه و deployment pipeline را به صورت مجزا handle کنند، که این خود باعث میشود تا محصول یا همان product ما سریع تر وارد بازار شود و در Update های بعدی risk کمتری برای تیم توسعه داشته باشد.مفهوم API Gateway:خب API = Application Programming Interface یک interface از application ها هست که به دو برنامه اجازه صحبت با یکدیگر را میدهند. وقتی شما اقدام به استفاده از Instagram یا پیامک عادی یا رزرو بلیط هواپیما از سایت میکنید، در واقع از API ها استفاده میکنید. API ها اقدام به Make OR Break کردن applicationها با توجه به نیازمندی های ما در بحث Infrastructure :یعنی Secure & Scale & Accelerate میکنند.در معماری های ادوار گذشته ما Monolithic Application ها را داشتیم که کل برنامه به صورت یکپارچه بود.و بعدا معماری Micro-Servicesآمد که بخش های مختلف برنامه را به قطعات کوچکتر شکست تا تیم های مختلف بتوانند روی بخش های کوچکتر کار کنند و این وابستگی از بین برود که کمک میکند app ما scalableو availabilityبالا و resource efficient باشد.اما در Micro-Service-Oriented-Architectureنیاز به APIهایی داریم تا به برقراری ارتباط بین clientها و Micro-Serviceها کمک کنند.ما باید برای سیستم های توزیع شده ترافیک APIها را به صورت ایمن تامین کنیم، که راهکار اصلی API-Gateway میباشد. API-Gatewayدقیقا بین client های شما و Micro-Service ها قرار میگیرد از مزیت های آن:1. یک: Client Performance: به جای این که از web or App من درخواست های مکرر به Micro-Serviceها فرستاده شود این درخواست ها به API-Gateway میرود، و API-Gatewayبه صورت Randomدرخواست ها را بین Micro-Service ها پخش میکند و این کار موجب کاهش Latencyمیشود.1. دو: Security: شما به راحتی میتوانید متوجه حملات امنیتی شوید به شکلی که در API-Gateway میتوان سرویس هایی همچون Authorization & Authentication و یا لایه های دیگر امنیت را قرار داد.2. سه: Protocol Translation: اگر ما پروتکل های متفاوتی همچون HTTPS داریم که امنیت را برقرار میکند و بعد از API-Gateway میتوان تبدیل به HTTP شوند. وقتی درخواستی به صورت HTTPS based به سمت API-Gateway می آید، که میتواند Rest API یا GraphQL باشد، بعد دریافت درخواست HTTPS، API-Gateway درواقع Validation آن را چک میکند و درمرحله بعد چک میکند آیا IP Address که درخواست شده مجاز و اجازه دسترسی به آن است یا خیر متناسب با طلاعات HTTP Header deny/accept list :و بعد به سراغ Authorization & Authentication میرود که دربخش قبلی توضیح داده شدسایر ویژگی هایی که API-Gateway به ما میدهد:مثل error handling ,monitoring, logging, caching. به صورت جامع ما میتوانیم API-Gateway های متفاوتی داشته باشیم که یکی از کاربرد های آن در IOT(IOT موضوع پروژه اینجانب) میباشد.مفهوم BPMS:سه مفهوم 1. model, 2. Build 3. Run سه قدم طلایی برای موفقیت در BPMS هستند. میتوانم این مفهوم با یک سوال شروع کنم که آیا شرکت یا سازمان شما دارد به صورت Agile کار میکند آیا شما اطلاعی از فرایند ها دارید و مهمتر از آن آیا میتوانید اوضاع را تحت کنترل در بیاورید؟ و اگر اتفاقی در business شما افتاد آیا قادر به پاسخ گویی سریع و مطلع کردن سایر اعضای سازمان یا شرکت هستید؟ما با کمک BPMS کمک میکنیم که business مورد نظر بیشتر efficient و flexible باشد. فرض کنید در یک شرکت یکی از کارمندان نیاز به یک لپ تاپ دارد، این مشکل آن کارمند نیست ولی در اکثر شرکت ها و ارگان ها فرایند ثیت درخواست بسیار طولانی و طاقت فرسا هست و نیاز به نامه نگاری دارد :مثل excel or breed sheet or email or phone calls، اما به جای این همه اضافه کاری روش های ساده تری برای ثبت درخواست وجود دارد.مزایای BPMS:1. یک: Workload Reduction: که امکان straight-through processing فرض کنید یک فرض کنید یک سازمان بزرگ دارید و افراد زیادی در آن سازمان مشغول به کار هستند و یکسری اسناد هست که بین کارمندان مختلف در چرخش هست که با استفاده از BPMS این چرخه بلا استفاده جمع میشود.a. الف: Less Coordination: یعنی نیازی نیست شما مستقیما به شخصی نیاز داشته باشید مثل منشی که مثلا این پرونده ببر طبقه اول اتاق 2 و این پرونده ببر پیش ریاست، تمام این مشکلات با BPMS حل میشود.b. ب: Less gathering of relevant information: یعنی اگر یک document به میز اتاق شما رسید و شما ملزم به مطالعه آن سند و جمع آوری اطلاعات و تصمیم درمورد یک موضوعی باشید، این کار به صورت خودکار با BPMS انجام میشود2. دو: Flexible System Integration:a. Generic functionality of process layerb. Easier to change process logicc. Island automationمفهوم Message Queue (Kafka & RabbitMQ):در واقع Queue به صفی از چیز های مختلف گفته میشود که منتظر handle شدن توسط سیستم هستند، از ابتدای صف شروع شده و به صورت یک توالی منظم پشت سر هم قرار دارند دقیقا مثل صف ماشین ها در جایگاه سوخت که پشت سر هم حرکت میکنند:مفهوم Message Queue را Message Broker نیز مینامند که Queue از پیام ها هست که بین دو بخش سیستم قرار گرفته اند برای برقراری ارتباط بین آن ها. در واقع Message ها یک نوع data transporter هستند بین فرستنده و گیرنده. مثلا یک بخش از سیستم دستور انجام یک task را به بخش دیگر سیستم ارسال میکند یا حتی پیام ها به صورت log ذخیره شده یا پیام شامل task هایی است که کامل شده اند.پس ساختار به این شکل است که Producers پیام را تولید کرده و تحویل Message Queue میدهند و consumer های ما به Message Queue متصل شده و پیام را دریافت میکند و پیامی مبنی بر دریافت یا عدم دریافت به Message Queue میدهد.مفهوم Message Queue ها asynchronous communication protocol را فراهم میکنند به این معنی که یک سیستم یک پیام در Message Queue قرار میدهد و نیازی به پاسخ سریع و بلادرنگ ندارد و به تعویق می افتد.واضح ترین مثال ایمیل هست، وقتی شما ایمیلی برای کسی میفرستید، شروع به ادامه سایر کار های خود میکنید و نیازی به پاسخ در همان لحظه ندارید، این روش handle کردن پیام ها Decouple میکند Producer از consumer.یک مثال دیگر فرض کنید یک application سفارش Fast Food دارید و سفارش شما را آماده کرده ولی باید همزمان پاسخ گوی سایر سفارشات باشد یعنی web-service باید دارای availability بالایی داشته باشد. پس درصورتی که تعداد درخواست ها بالا رود در Message Queue ذخیره شده و consumer پیام را دریافت کرده و در زمان مناسب پاسخ میدهد.مفهوم Docker-And-Containers:مفهوم Docker یک پلتفرم Opern-Source هست که کمک میکند application ها و وابستگی های بین Module ها و Component های آن را package کرده و داخل Container Docker قرار دهیم برای توسعه و deploy کردن نرم افزار مورد نظر.ما به کمک Docker میتوانیم framework های مناسب برای app های مختلف در نظر بگیریم:در واقع Docker حاصل ترکیب زیرساخت(Infrastructure) و Development میباشد.این Containerization شامل تمام وابستگی ها هست مانند framework ها و library ها. به کمک Docker Containers اپ های ما میتوانند به راحتی و به صورت efficiently روی محیط های مختلف کامپیوتری کار کنند به دلیل خاصیت Lightweight بودن. Container ها فضای کمی را روی حافظه ما اشغال میکند. Container ها application ها را به صورت مجزا اجرا میکنند و هسته سیستم عامل را با Container ها به اشتراک میگذارد. Containerها یکسری policy برای application ها دارند که باعث secure ماندن آن ها میشود. Container ها بسیار portable هستند و در اکوسیستم Docker قایل اجرا هستند و تعدادی نرم افزار میتوانند Encapsulate شوند داخل یک Container و به راحتی میتوانند در platform های مختلف deploy شوند. وقتی که یک Container ساخته میشود میتواند روی هر سیستم دیگری که روی آن Docker نصب شده است run شود دقیقا مشابه سیستم قبلی بدون هیچ تغییری. Container ها میزان زمان boot را به حداقل میرسانند که این مزیت باعث کم شدن مدت زمان deployment میشود.در آخر به یکسر مزایای خاص Docker Container ها اشاره میکنیم:· یک: No External Dependency: Container هیچ وابستگی برای run کردن application ندارد، ومفهوم Container فقط در host و run کردن application دخالت میکند.· دو: Easily Shipped: فقط کافی است Docker روی سیستمی نصب باشد و Container بدون توجه به سیستم عامل و یا محیط توسعه اجرا میشود و با توجه به کم مصرف کردن میزان حافظه سرعت بالایی دارد.· سه: Volumes: یک روش share کردن data هست که از امنیت خوبی برخوردار هست در میان Container های مختلف· چهار: Isolation: در Container ها host operating system ها امکان isolation فراهم میکنند تا وابستگی ها از بین بروند به عنوان مثال micro-service ها به راحتی میتوانند با این روش کار کنند بدون هیچگونه وابستگی.در این شکل میتوانیم Container های مختلف Docker را ببینیم:یک Container میتواند Apache Tomcat را به صورت package به همراه وابستگی های آن به زبان برنامه نویسی Java را در یک فایل قرار دهد.مفهوم Container-Orchestration:فرض کنید 3 تا Micro-service دارید که به صورت جداگانه Containerize شده اند فرض کنید این 3 سرویس Front-End و Back-End و Data-Base میباشند. تمرکز توسعه دهنده ما روی End-User هست که به Front-End دسترسی دارد و خود Front-End وابسته به Back-End میباشد و خود Back-End وابسته به Data-Base پس تمام تمرکز developer ما به صورت کلی روی همین لایه هست:در زیر این لایه، لایه Orchestration قرار دارد ما میتوانیم اسم این لایه را Master قرار دهیم مشابه Kubernetes که در آن یکسری Master Node وجود دارد که application های متنوع را روی منابع سیستم شما مدیریت میکند.در شکل بالا همه Micro-Service هایی که به صورت Containerize رسم شد با دید کلی توسعه دهنده میتوان به این صورت در نظر گرفت:پس اولین قدم در Orchestration، deploy کردن application میباشد. قدم دوم Scaling میباشد:پلتفرم Orchestration میاد و schedule میکنه Micro-Service ها و Container ها را تا مطمئن شود از منابع به بهترین نحو ممکن استفاده میشود. قدم سوم Networking هست یعنی چگونگی برقراری ارتباط بین افراد و سرویس های مختلف که مستلزم ساخت سرویس ها هست که هر کدام از Container ها را معرفی کند. خب الان handle کردن ارتباط بین همه Front-End با هم و همه Back-End ها با هم و همه Data-Base ها با هم که این وظیفهplatform Orchestration هست تا End-User بتواند به راحتی به بخش های مختلفی مثل Front-End و Back-End و Data-Base دسترسی پیدا کند.قدم چهارم Insight هست که به بخش درونی توجه میکندplatform Orchestration، یعنی اگر در یکی از Micro-Service ها یکی از Front-End ها به مشکل خورد و حذف شد به سرعت در Micro-Service دیگر یک Front-Endرا وارد چرخه کرده و همه این کار های جایگزینی را به صورت خودکار انجام میدهد.مفهوم Log Management Tool (ELK):در cloud تعداد زیادی application وجود دارد که روی platform های مختلف اجرا میشوند:هر کدام از این application در طول روز میلیون ها log ایجاد میکنند با type های مختلف، و نیاز مبرم به یک ابزار مدیریت log میباشد تا بتوانید مشکلاتی و error هایی که در سیستم ایجاد شده اند را به موقع شناسایی و مشکل مورد نظر به سرعت debugeشود در غیر این صورت شما مجبور میشوید تا ساعت های زیادی را برای analyze کردن میلیون ها خط log و همچنین با log type های گوناگون صرف کنید تا بتوانید error مورد نظر را کشف کنید. یکی از این ابزار ها ELK میباشد.مفهوم ELK از سه قسمت Elastic search & Logstash & Kibana. Elastic search یک database از نوع No-SQL توزیع شده است که شما میتوانید پیام ها را به فرمت json ذخیره کنید و با استفاده از Elastic میتوانید از سرویس های Restful استفاده کنید. Component بعدی Logstash هست که میتوان یک framework باشد که داده های مختلف را از منابع مختلف جمع آوری میکند و داده ها را به صورت stream در pipeline قرار میدهد و لاگ ها را push میکند داخل Elastic search. و در آخر Kibana که یک component UI میباشد داده ها را به روشی که مدنظر شما میباشد نشان میدهد.پس اگر شما در مرحله deployment باشید، یک سری ابزار نیاز دارید برای مدیریت لاگ های خود که اولی Elastic search به عنوان یک component نرم افزاری و Logstash که جریان داده های مختلف از سیستم ها یا زیرساخات های مختلف جمع آوری میکند و Kibana به عنوان یک ابزار UI که میتوان برای نمایش دادن report های مختلف به کار گرفته شوند.این یک محیط شبیه سازی UI به نام Kibanaمیباشد که فقط حاوی یک لاگ است.مفهوم Monitoring Tools (Prometheus):مفهوم Prometheus ابزاری است برای monitor کردن محیط های داینامیک container مثل Kubernetes و docker و همچنین میتواند در زیرساخت هایی که به صورت container نیستند نیز استفاده شود ولی به طور کلی این ابزار محبوبیت زیادی در Container Microservices Infrastructure دارد.مفهوم DevOps مدرن در دنیای امروزی دارای پیچیدگی های زیادی است که نیاز دارد بخشی از آن ها به صورت automation تبدیل شوند. فرض کنید شما چند سرور مجزا دارید و تعدادی Containerize Application را Run میکنند و صدها process روی زیرساخت ها در حال انجام هستند و همه چیز به هم پیوسته هستند، حالا فرض کنید این سرور ها به صورت distributed هستند و شما هیچ اطلاعاتی از سخت افزار یا برنامه نرم افزاری آن ها ندارید به عنوان مثال مشکلاتی شامل: Response Latency, Overloaded, Errors, Enough resource یا حتی down شدن یکی از سرور ها، در چنین زیرساخت پیچیده ای احتمال خطا زیاد میشود. وقتی شما صدها application دارید که deploy شده اند هر کدام که crash or failure کند باعث خلل در سایر سرویس ها میشود و شما نیاز داری که سریعا مشکل را شناسایی کنید.فرض کنید شما برای ورود به سامانه گلستان دچار مشکل شده اید و پیغام خطا در رمز عبور یا user-id را نمایش میدهد، شما باید بتوانید مشکلات را بررسی کرده به صورت step by step و تعیین کنید که آیا مشکل از back-end است یا یکی از سرور ها یک exception را نمایش داده است یا مشکل از سرویس شناسایی و ذخیره رمز عبور است یا اصلا مشکل از یکی از سرور ها به دلیل پر شدن حافظه داخلی آن است! شما به کمک این ابزار به راحتی و در زمان مناسب متوجه میشوید که یکی از سرور ها به دلیل کمبود فضای حافظه به زودی crash میکند و سیستم login گلستان به مشکل خواهد خورد.پس شما به کمک این ابزار میتوانید کل سیستم و زیرساخت ها و سرویس ها را مانیتور کنید و alert و هشدار امکان وقوع failure or crash دریافت کنید و به موقع مشکل را شناسایی و برطرف کنید.مفهوم Static Code Analysis:یک method برای debugging کردن کد ها بدون execute میباشد. اگر توسعه دهنده ای اقدام به تولید کدی با کیفیت و تمیز کند، نیاز به debugging آن کد دارد. در واقع Static Code Analysis زمانی اجرا میشود که توسعه دهنده در حال تکمیل کد مربوطه است یعنی دقیقا قبل از اتمام و تست آن، میتوان به عنوان تست source code در نظر گرفت و قبل از تست نرم افزار اصلی صورت میگیرد. از مزیت های این تست:· کمک به شناسایی مشکلات موجود در کیفیت توسعه نرم افزار، هر نرم افزاری یک تعداد fault و bug دارد و اگر شما این مشکلات را زود handle نکنید وقتی کد پیچیده تر میشود یا محصول را به دست مشتری بدهید bug های آن مشخص خواهند شد، پس Analysis کردن کد بسیار مهم است.· همچنین به کمک Static Code Analysis میتوانیم کد هایی را که نیاز مبرم به ساده سازی دارند را شناسایی کرده و تغییرات مورد نظر را اعمال کنیم· یکی دیگر از مزایای Static Code Analysis کشف error های موجود در کد است.· ایجاد یک ارتباط خوب و قوی بین تیم های مختلف که در حال توسعه نرم افزار هستند به منظور برقراری ارتباط و رفع مشکلات یکدیگر و بالا بردن کیفیت کد.یکی از این ابزار ها PVS Studio میباشد که در زبان های C, C++, C#, Java نوشته شده است، پس شما میتوانید به راحتی با استفاده از این ابزار زبان های ذکر شده را به صورت Static ، آنالیز و تست کنید و به راحتی در سیستم عامل های Widows, Linux, Mac Os اجرا میشود.این ابزار Static Code Analysis را انجام میدهد و error ها و bug های موجود را به صورت log به شما report میدهد. ابزار های دیگری نیز جهت Static Code Analysis در جهان وجود دارد مثل intellij idea یا SonarQube و SonarJava..مفهوم Continuous Delivery:بحث اصلی در مورد این است که چطور کد را به سمت production ببریم. اگر ما تغییرات مهمی را در کد منبع خود ایجاد کنیم چطور آن را باید به production خود منتقل کنیم؟در ابتدای کار ما باید طی فرایند build کد خود را به نرم افزار تبدیل کنیم، یعنی کد را run کرده و فایل exe را استخراج کنیم. خب الان ممکن است فکر کنید حالا که نرم افزار را داریم میتوانیم به راحتی میتوان نرم افزار را deploy کرد روی production، در حالی که این تفکر کاملا اشتباه است. شرکت های بزرگ به هیچ وجه این عمل را مستقیم انجام نمیدهند و با قرار دادن نرم افزار در محیط های تست آن را تست کرده و مشکلات fault, error های آن را پیدا کرده و برطرف میکنند به عنوان مثال محیط های تستی همچون QA, performance, stage. پس وقتی شما به pipeline یک ابزار Continuous Delivery نگاه میکنید با این مفاهیم روبه رو میشوید که محیط های تست نامبرده شده میتوانند به صورت خودکار deploy شوند و در محیط QA و stage میتوان Automating testing قرار داد.و قسمت build را میتوانیم از ابزار های مختلفی استفاده کنیم که به آن CI یا همان continuous delivery گفته میشود و همچنین بین سطح stage و production که level دیگری از governance وجود دارد.مفهوم SSO:از نظر کاربر هر دو مفهوم Single Sign on و Federated Identity Management یکسان هستند و یک از کاربرد های آن ها وقتی که کاربر به اکانت google خود وارد میشود میتواند در YouTube و سایر شبکه های اجتماعی login کند بدون نیاز به وارد کردن رمز. SSO یک authentication است، و کمک میکند تا کاربر بتواند به صورت امن به application ها و سرویس- های مختلف دسترسی داشته باشد به کمک فقط یک id. به عنوان مثال شما میتوانید وارد Gmail و YouTube و slack و آمازون و غیره. یک صفحه مشابه این شکل نمایش میدهد:و شما به کمک SSO میتوانید در هر بار مراجعه به این سایت بدون نیاز به وارد کردن رمز عبور به راحتی login کنید. در واقع به کمک service provider در Gmail این اطلاعات از Protocol های امن به application یا سایت مورد نظر منتقل میشود. دو Protocol مرسوم برای پروسه authentication وجود دارد:1. یک: SAML (Security Assertion Markup Language): در واقع یک فایل XML میباشد و مسئولیت ایجاد تغییر اطلاعات هویتی بین سرویس ها میباشد.1. پروتکل دوم OpenID connect میباشد:مشابه همین صفحه ورود گوگل:یکی از استفاده های این پروتکل منجر به ورود به YouTube میشود که از JWT یا همان JSON Web Tokenاستفاده میکند تا بتواند اطلاعات هویتی فرد را بین سرویس های مختلف به اشتراک بگذارد.مثال: کاربری برای ورود به حساب twitter خود از Gmail که یک Service Provider میباشد اقدام میکند. سرور Gmail دامین کاربر را تشخیص میدهد وrequest SAML Authentication را به مرورگر کاربر برمیگرداند:مرورگر SAR و اطلاعات کاربر را منتقل میکند به Identity Provider مانند Okta & Authu0 & oneLogin. Identity Provider بلافاصله Login Page را به کاربر نشان میدهد:و کاربر پس از وارد کردن اطلاعات خود و ارسال به Identity Provider مجدد پیامی برمیگردد با عنوان Signed SAML assertion که یک امضای رمزنگاری شده در مستندات XML میباشد که شامل اطلاعات کاربر و میزان دسترسی کاربر به Service Provider میباشد. این اطلاعات در قالب فایل XML از مرورگر کاربر به Service Provider ارسال میشود و Service Provider آن را Validate کرده که توسط کلید عمومی این کار را انجام میدهد:سپس Service Provider میاد و protected resource را به مرورگر کاربر برمیگرداند متناسب با میزان دسترسی کاربر:مفهوم Federated Identity Management (FIM):در Service Provider، SAML request را همچنان ارسال میکند مشابه SSO ولی این بار request به جای ارسال به Identity Provider، به مرکز Federation application ارسال میشود. Federation application دو مورد را چک میکند: 1. آیا Identity Provider شما بخشی از Federation میباشد؟ 2. مورد دوم آیا شما اجازه دسترسی به سرویس ها را دارید یا خیر.مفهوم Service Mesh:یک مفهومی است مربوط به Micro-Service ها میباشد. فرض کنید یک application یکپارچه monolithic دارید و تمام feature های application را شامل میشود و وقتی این application monolithic را به Micro-Service تبدیل کنیم مزایای زیادی برای ما دارد.یکی از مزایای آن وجود component های کوچک و مستقل است که به راحتی قابل deploy هستند و سایر بخش های سیستم تحت تاثیر تغییرات صورت گرفته قرار نمیگیرند یا حتی اگر component دچار مشکل شود و down یا crash کند سایر بخش های سیستم به مشکل نخواهند خورد در نتیجه flexibility برنامه حفظ میشود. به دلیل استقلال component ها در Micro-Service ها به راحتی میتوان data-base یا framework یا حتی زبان برنامه نویسی را تغییر داد.فرض کنید یک Micro-Service داریم که با دو ورژن از catalog صحبت میکند و دو ورژن از catalog هم با inventory صحبت میکنند. چهار علت اصلی در استفاده از Service Mesh مطرح میشود که اولی secure یا همان امنیت است پس نیاز به یک Mutual TLS میباشد وقتی یک سرویس با سرویس دیگر صحبت میکند.در مرحله بعدی ارتباط بین سوریس ها به صورت داینامیک پیکربندی میشوند یعنی این که چطور 2 سرویس به یکدیگر connect میشوند، فرض کنید 90% ترافیک به catalog-v1 و 10% ترافیک را به catalog-v2 مادامی که در حال انجام تست هستم ارسال میکنم. سومین دلیل Observe کردن کارکرد application به صورت end-to-end میباشد یعنی بررسی سرویس های مختلف و این که ترافیک و flow داده ها از کدام سرویس ها بیشتر عبور میکنند. دلیل چهارم باید بررسی شود که کدام سرویس اجازه دسترسی و صحبت کردن با سرویس دیگر را دارد، در این مثال سرویس UIاجازه صحبت مستقیم با Inventory را نداشته در نتیجه مجبور میشود از سرویس catalog با دو ورژن متفاوت استفاده کند و مطابق شرایط ترافیک های مختلفی را به هریک اختصاص دهد یا حتی میتوانیم به نکات بیشتری توجه کنیم به عنوان مثال سرویس UI اجازه دسترسی به catalog از طریق پروتکل HTTP get Request و catalog از طریق post Request با Inventory ارتباط برقرار کند. در زمان قدیم توسعه دهنده های اصلی ما هر 4 مورد ذکر شده را برنامه نویسی کرده و مستقیما در در کد های application قرار میدادند که باعث بزرگ شدن بیش از حد Micro-service UI میشد و به صورت کلی انعطاف پذیری برنامه کم میشد. ولی با روش جدید Service Mesh، application را کوچک نگه میداریم به صورت business focus عمل میکنیم.مفهوم BRMS:فرض کنید به عنوان یک Analysis در یک شرکت کار میکنید و نیاز دارید تا یکسری تغییراتی در یکسری ابزار در نرم افزار ایجاد کنید، در جواب باید مواردی بیان شود از جمله هر شرکت یا سازمانی یک سری Business rule برای application های خود دارد که به یک زیان واحد نوشته شده اند مثل جاوا، مثلا در شکل زیر دایره ها نشان دهنده business rule یا business logic و مثلث ها قوانین applicationمیباشد:مفهوم Rule Management System هایی مانند BRMS به ما کمک میکنند که قوانین و logic بیزینس خود را از کد های application جدا کنید و به ما اجازه میدهد که قوانین جدید خود را در فرمت های مختلف تبیین کنیم که در شکل پایین نمایش داده شده است. حالا با جدا کردن business rule از کد های application، این برنامه ما چه طور با قوانین مربوط به businessتعامل خواهد داشت؟ در جواب این سوال راه های متفاوتی را میتوان اتخاذ کرد. در یکی از این راه ها باید قوانین را در application قرار داد و یک rule engine برای اداره آن در فایل jarایجاد کرد در این راستا به راحتی میتوان از یک KIE server استفاده کرد که تمام قوانین business ruleرا در خود جای میدهد.نحوه برقراری ارتباط بین application و KIE server، برقراری ارتباط از طریق Java API و یا از REST API که توسط خود KIE server فراهم شده است. پس وقتی Analysisیا توسعه دهنده ما یک سری تغییرات را در Business central(شکل اول) ایجاد میکند، تغییرات اعمال شده به KIE serverمنتقل شده و از طریق Java API و یا از REST API به application اعمال میشوند.مفهوم Low code platform:در سال های پیش کمپانی های بزرگی همچون اوراکل یک سری application های پیچیده را تولید کردند تا بتوانند به راحتی business problems ها را شناسایی و حل کنند و این application همه مواردی از جمله فروش و حسابداری را handle میکنند و این application یکسری فرایند های بسیار پیچیده دارند که مشکلاتی مختلفی از جمله وجود یکسری gap در endless spreadsheet و وقتی این که حجم این sheet ها زیاد میشود توانایی modify کردن و ایجاد تغییرات به مشکل برخورده و برنامه هنگام اجرا خطا میدهد ولی مزایای این spreadsheet قابلیت فهم آسان آن ها است با توجه به مزایا و معایب ذکر شده بین spreadsheet و اپ های بزرگ و حجیم یک gap وجود دارد به نام low code. در واقع flexible و قابل درک آسان برای فهم افرادی که در حوزه businessتخصص دارند. که قابل translate شدن به scalable application ها میباشد تا توسعه دهنده و برنامه نویسان به راحتی میتوانند آن را modify کرده و برنامه را توسعه دهند.فرض کنید یک سازمان قصد استخدام تعدادی کارمند را دارد و باید پروسه مصاحبه و تکمیل فرم و addکردن اطلاعات شخصی که در مصاحبه قبول شده به سیستم شرکت ما که قطعا پروسه زمان بری خواهد بود و کار اضافی برای کارمندان ما ایجاد خواهد کرد که ما به کمک low code platform میتوانیم همه این کار ها را automate کنیم و به این طریق بیزینس ما نیز کمتر آسیب میبیند. مثلا در دانشگاه شهید بهشتی بعد از قبولی شما باید یک شناسه id شهید بهشتی درست کنید و ایمیل دانشگاهی و رمز عبور دریافت کنید برای بهرهمندی از خدمات کتاب خانه، اینترنت دانشگاه و خوابگاه، سایت نظر سنجی بهشتی، و سایت مقالات که همه ی این کار ها را خود دانشجو باید انجام دهد در صورتی که با قرار دادن یک low code platform این فرایند به صورت خودکار صورت گرفته و مشکل حل میشود.مفهوم ESB:در معماری سرویس گرا یا SOA، سیستم ها قادر به برقراری ارتباط و تبادل داده ها با یکدیگر از طریق یک فایل XML هستند.ولی پیچیدگی در integrate کردن سیستم ها زیاد میباشد. وقتی شما سه سیستم در معماری خود داشته باشید شما نیاز به یک interface برای هر کدام از سیستم ها دارید برای اتصال به آن ها و این جمله به این معنی است که یک interface کلی نداریم. اما راه حل جامع آن Enterprise Service Bus یا همان ESB میباشد. یعنی ESB میشود آن interface جامع ما و هر کدام از سیستم ها در سازمان ما به ESB متصل شده و هر سیستم کافی است که فقط با ESB ارتباط برقرار کند که شامل یک سری auto system میباشد. پس هر سیستم ما نیاز دارد interface خود را به ESB متصل کند:مفهوم ESBبه سیستم ها کمک میکند تا عمل routing message را هدایت کند. وقتی پیام ها از interface سیستم ها به ESB ارسال میشود، ESB قبل از فرستادن پیام اطمینان حاصل میکند که سیستم مقصد آیا alive(زنده) هست و میتواند پیام را دریافت کند یا خیر؟ سیستم ها مسئولیتی در قبال delivery پیام ها ندارند و هر سیستم میتواند روی توسعه سرویس های خود تمرکز کند، پس ESB مسئولیت رسیدن پیام ها را به سیستم مقصد به عهده میگیرد و سیستم ما بعد ارسال پیام روی توسعه سرویس های خودش کار میکند به جای پیگیری ارسال موفقیت آمیز پیام به مقصد که باعث better performance برای سرویس ها میشود.وقتی سرور Aبرای سرور Bیک پیامی را میفرستد که همه ی اطلاعات درخواستی سرور B را شامل نمیشود ESB کمک به insert کردن data به پیام مورد نظر میکند.مفهوم ESB همچنین امنیت را برقرار میکند با قرار دادن firewall، قبل از ارسال فایل XML هر کدام از سیستم ها مرحله authenticate را پشت سر گذاشته و احراز هویت میشوند. وقتی سیستم Aبه سیستم Bفایل XMLخود را ارسال میکند ESBمیتواند یک login functionاضافه کند و پیام را به سیستم دیگری ارسال کند.منابع: ویکی پدیا و سایت های تخصصی در برنامه نویسیممنون از وقتی که گذاشتید.