https://virgool.io/feed/@Sa_Mirghasemi مفید 38 ------ مهندسی کامپیوتر شهید بهشتی fa 2026-04-15 06:47:30 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@Sa_Mirghasemi https://virgool.io/@Sa_Mirghasemi/authentication-as-a-microservice-wm9dzuo7pgcq معماری مونولیتیک در برابر میکروسرویس ها: سنتاً، برنامه ها به صورت مونولیتیک ساخته می شدند، به این معنی که یک سیستم بزرگ و واحد پشتیبانی، اجزای مختلف از جمله احراز هویت را انجام می داد. این روش با وجود سادگی در توسعه و استقرار، چالش های قابل توجهی در مقیاس پذیری و مدیریت ایجاد می کند، به ویژه هنگامی که پایگاه کاربران افزایش می یابد.در یک سیستم مونولیتیک، احراز هویت کاربر معمولاً از طریق جلسات(Sessions) انجام می شود. یک کاربر وارد می شود، سیستم اعتبار او را در برابر پایگاه داده بررسی می کند، یک جلسه ایجاد می کند و یک شناسه جلسه برمی گرداند، معمولاً به صورت کوکی. درخواست های بعدی این شناسه جلسه را شامل می شوند، که امکان بازیابی جلسه کاربر و انجام اقدامات لازم را فراهم می کند. اگرچه این روش مؤثر است، اما حالت دار است و نیاز به آگاهی گسترده پشتیبانی سرور از جلسات دارد. این حالت داری منجر به پیچیدگی هایی در مقیاس پذیری می شود، زیرا مدیریت تعداد زیادی از جلسات به تدریج پیچیده تر می شود.گذار به میکروسرویس ها:معماری میکروسرویس برنامه را به سرویس های کوچکتر و مستقل تقسیم می کند، هر یک با پایگاه داده خود. این جداسازی به چالش های مقیاس پذیری پاسخ می دهد و انعطاف پذیری بیشتری در توسعه و استقرار فراهم می کند. در مثال برایان، یک برنامه ساده به یک API کاربر و یک API کارهای روزانه تقسیم شده است، هر کدام با پایگاه های داده جداگانه برای کاربران و کارهای روزانه.احراز هویت مبتنی بر JWT:در میکروسرویس ها، احراز هویت بدون حالت اهمیت بسیاری دارد. برایان از توکن های وب JSON (JWTs) به عنوان یک راه حل استفاده می کند. JWTs توکن های فشرده و ایمن URL هستند که شامل اشیاء JSON رمزگذاری شده هستند، شامل ادعاها درباره یک نهاد، معمولاً یک کاربر. آن ها از سه بخش تشکیل شده اند: یک سرآیند، یک بار محتوا و یک امضا. سرآیند نوع توکن و الگوریتم امضا را مشخص می کند، بار محتوا شامل ادعاها (مانند شناسه کاربر، نقش ها، صادرکننده، زمان انقضا) است و امضا برای تأیید اصالت و یکپارچگی توکن استفاده می شود.JWTs مزایای زیادی دارند زیرا آن ها خودکفا هستند، حامل تمام اطلاعات لازم درباره کاربر. این امر نیاز به ذخیره سازی جلسه در سمت سرور را حذف می کند، بار سرور را کاهش داده و مقیاس پذیری را تسهیل می کند. JWTs می توانند با استفاده از یک رمز مشترک (با الگوریتم HMAC) یا یک جفت کلید عمومی/خصوصی (با RSA) امضا شوند.ملاحظات امنیتی: در حالی که JWTs مزایای بسیاری دارند، آن ها نیز مسائل امنیتی را به همراه دارند. برایان بر اهمیت مدیریت امن توکن ها تأکید می کند، به ویژه برای توکن های تازه سازی که می توانند عمر طولانی تری داشته باشند و اجازه دهند کاربران توکن های دسترسی جدیدی تولید کنند. اگر توکن تازه سازی مورد سوءاستفاده قرار گیرد، می تواند یک آسیب پذیری امنیتی قابل توجه باشد.برایان به بررسی استفاده های امنیتی متداول JWT و راه حل های آن ها می پردازد. یکی از این استفاده ها الگوریتم "هیچ" است که در آن مهاجم می تواند سرآیند توکن را تغییر دهد تا از تأیید امضا جلوگیری کند. راه حل ساده است: اجازه ندهید که "هیچ" به عنوان یک الگوریتم امضای معتبر باشد. یکی دیگر از استفاده های احتمالی شامل دستکاری سیستم مدیریت کلید است، به ویژه در سناریوهایی که سیستم ممکن است یک کلید عمومی را با یک رمز مشترک اشتباه بگیرد. راه حل در اینجا واضح است: اطمینان حاصل کنید که پروتکل های مدیریت کلید سخت گیرانه ای دارید.لغو توکن و مکانیزم های خروج:لغو توکن در یک سیستم بدون حالت چالش هایی را ایجاد می کند، زیرا JWTs در سمت سرور ذخیره نمی شوند. برایان روشی را پیشنهاد می کند که شامل لغو توکن ها بر اساس زمان است، جایی که لغو توکن تازه سازی منجر به باطل شدن توکن های دسترسی صادر شده پس از یک نقطه خاص می شود. این روش به ردیابی زمان لغو توکن تازه سازی و مقایسه آن با زمان های انقضای توکن های دسترسی موجود متکی است.برای خارج کردن کاربران، مهم است تا توکن های تازه سازی آن ها را لغو کنید. این از تولید توکن های دسترسی جدید جلوگیری می کند، به طور مؤثر کاربر را خارج می کند. برایان توصیه می کند که عملکرد خروج گسترده ای را پیاده سازی کنید، به ویژه در موارد نقض امنیتی، تا اطمینان حاصل شود که همه کاربران خارج شده اند و برای دسترسی بیشتر به توکن های جدید نیاز دارند.مدیریت حذف کاربران در میکروسرویس ها:در یک محیط میکروسرویس، حذف یک کاربر پیچیدگی بیشتری دارد به دلیل طبیعت جدا شده سرویس ها. در مدل مونولیتیک، حذف یک کاربر می تواند به طور خودکار به داده های مرتبط (مانند کارهای روزانه) منتقل شود. در میکروسرویس ها، این ارتباط وجود ندارد. برایان راه حل هایی مانند سیستم های حذف جهانی یا مکانیزم های مبتنی بر رویداد را پیشنهاد می کند، جایی که یک رویداد حذف کاربر اقداماتی را در تمام میکروسرویس های مرتبط فعال می کند.نکات پایانی:سخنرانی برایان تکامل سیستم های احراز هویت را از معماری مونولیتیک به میکروسرویس ها برجسته می کند، با تأکید بر تغییر از مکانیزم های احراز هویت حالت دار به بدون حالت. توکن های وب JSON (JWTs) در این چشم انداز به عنوان ابزاری قدرتمند برجسته هستند که هم راحتی و هم کارآمدی را ارائه می دهند. با این حال، پیاده سازی آن ها نیازمند توجه دقیق به جنبه های امنیتی است، از مدیریت توکن تا مکانیزم های لغو توکن. گرایش به سمت میکروسرویس ها و JWTs نشان دهنده یک روند گسترده تر در معماری نرم افزار است، با اولویت بندی مقیاس پذیری، امنیت و کارآمدی در مدیریت احراز هویت و مدیریت کاربران. https://www.youtube.com/watch?v=SLc3cTlypwM Sa_Mirghasemi Sa_Mirghasemi Fri, 29 Dec 2023 22:39:23 +0330 https://virgool.io/@Sa_Mirghasemi/mastering-chaos-a-netflix-guide-to-microservices-hh2xu6f77gc9 سفر نتفلیکس در اتخاذ معماری میکروسرویس‌ها نشان‌دهنده تعهد شرکت به تحول تکنولوژیک و تعالی عملیاتی است. این راهنما، که توسط جاش ایوانز ارائه شده است، نگاهی جامع به چالش‌ها و راه‌حل‌های مواجه شده در طول این سفر تحول‌آفرین ارائه می‌دهد.از معماری یکپارچه به میکروسرویس‌ها: چالش اولیهدر ابتدا، معماری نتفلیکس یکپارچه بود و شامل یک برنامه جاوا بود که به طور مستقیم با یک پایگاه داده اوراکل متصل شده بود. این ساختار، که در دهه 90 و اوایل 2000 رایج بود، به زودی محدودیت‌های خود را نشان داد. پایگاه کد یکپارچه تشخیص و رفع مشکلات را به یک فرایند طولانی تبدیل کرد و طراحی نقطه شکست تکی پایگاه داده منجر به اختلالات قابل توجهی در سرویس شد. عدم انعطاف‌پذیری در اجرای تغییرات، به دلیل ارتباط تنگاتنگ بین برنامه و پایگاه داده، مشکلات را بیشتر کرد.پذیرش میکروسرویس‌ها: رویکرد نتفلیکسبرای رفع این مشکلات، نتفلیکس به سمت معماری میکروسرویس‌ها حرکت کرد و برنامه یکپارچه خود را به مجموعه‌ای از سرویس‌های کوچک و مستقل تقسیم کرد. هر میکروسرویس، مانند یک عضو در بدن انسان، عملکرد خاصی را در اکوسیستم گسترده‌تر سرویس نتفلیکس انجام می‌دهد.میکروسرویس‌ها در نتفلیکس به عنوان سرویس‌های کوچک و مستقل که از طریق مکانیزم‌های سبک مانند API منابع HTTP ارتباط برقرار می‌کنند، تعریف شده‌اند. این پارادایم طراحی باعث ترویج جداسازی دغدغه‌ها، مدولاریتی، مقیاس‌پذیری و تقسیم‌بندی بار کاری می‌شود. اجزای کلیدی معماری میکروسرویس نتفلیکس شامل:لایه پروکسی و دروازه API: مدیریت درخواست‌های ورودی و مسیریابی آن‌ها به سرویس‌های مناسب.لایه‌های قدیمی و مدرن: تسهیل انتقال هموار از سیستم‌های قدیمی به سرویس‌های جدید.سرویس‌های میانی و پلتفرم: ارائه قابلیت‌های اساسی برای پشتیبانی از میکروسرویس‌های مختلف.چالش‌های کلیدی و راه‌حل‌هامدیریت وابستگی‌ها: یکی از چالش‌های اصلی، مدیریت وابستگی‌ها بین سرویس‌ها برای جلوگیری از خرابی‌های متوالی بود. نتفلیکس برای مدیریت تایم‌اوت‌ها، تلاش‌های مجدد و اجرای مکانیزم‌های جایگزین، از Hystrix استفاده کرد. آزمایش تزریق خطا نیز برای آزمایش استحکام این سیستم‌ها تحت بار استفاده شد.بحث کتابخانه های مشتری: نتفلیکس با تصمیم‌گیری میان استفاده از فراخوانی‌های REST ساده و ساخت کتابخانه‌های مشتری برای منطق و الگوهای دسترسی مشترک دست و پنجه نرم می کرد. در حالی که کتابخانه‌های مشتری توسعه را تسهیل می‌کردند، آن‌ها خطر ایجاد یک نوع جدید از ساختار یکپارچه و پیچیدگی‌هایی مانند افزایش بار و تعارض نسخه‌ها را به همراه داشتند.پایداری و قضیه CAP: با تمرکز بر تعادل میان سازگاری و دسترسی، نتفلیکس سازگاری نهایی را انتخاب کرد و از فناوری‌هایی مانند Cassandra برای مدیریت داده‌های توزیع شده استفاده کرد.قابلیت اطمینان زیرساخت: یک حادثه در شب کریسمس 2012، زمانی که یک خرابی در سیستم کنترل AWS منجر به اختلالات گسترده شد، نیاز به یک زیرساخت مطمئن را برجسته کرد. این حادثه نتفلیکس را به توسعه یک استراتژی چند منطقه‌ای برای افزایش استقامت سوق داد.سرویس‌های بدون حالت در مقابل سرویس‌های دارای حالت: نتفلیکس بین سرویس‌های بدون حالت، که مقدار زیادی از داده‌ها را ذخیره نمی‌کنند و به سرعت از دست دادن گره بهبود می‌یابند، و سرویس‌های دارای حالت مانند پایگاه‌های داده و حافظه‌های نهان، که در آن‌ها از دست دادن گره اهمیت بیشتری دارد، تمایز قائل شد.استراتژی‌های کشینگ: نتفلیکس استراتژی کشینگ خود را از کش‌های تک‌گره‌ای به رویکردی مطمئن‌تر با استفاده از EVCache، یک فناوری مبتنی بر MemcacheD، تکامل داد و اطمینان و قابلیت اطمینان را تضمین کرد.مقابله با تغییرات عملیاتی و تنوع: برای مدیریت چالش‌های تغییرات عملیاتی و معرفی زبان‌ها و کانتینرهای جدید، نتفلیکس بر یادگیری مداوم، اتوماسیون و اجرای مجموعه‌ای از بهترین شیوه‌ها به نام "آماده تولید" تمرکز کرد.رویکرد جاده‌ ساخته شده: نتفلیکس مجموعه‌ای از فناوری‌ها و شیوه‌های برتر را توسعه داد، که به عنوان جاده‌ای ساخته شده شناخته می‌شود، تا به توسعه‌دهندگان تجربه توسعه‌ای قابل اطمینان و کارآمد ارائه دهد، با تمرکز اصلی بر جاوا و EC2.نتیجه‌گیریتجربه نتفلیکس با میکروسرویس‌ها اهمیت انعطاف‌پذیری، یادگیری مداوم و نوآوری در فناوری را برجسته می‌کند. با پذیرش میکروسرویس‌ها، نتفلیکس موفق به تحول معماری خود شد تا محدودیت‌های طراحی یکپارچه قبلی خود را پشت سر بگذارد. این سفر بدون چالش‌های خود نبود، اما از طریق ترکیبی از راه‌حل‌های تکنولوژیکی، تصمیم‌گیری‌های استراتژیک و یادگیری سازمانی، نتفلیکس یک سیستم قوی، قابل مقیاس و چابک را ایجاد کرده است. نکته کلیدی، رویکرد انعطاف‌پذیر به فناوری است، که سیستم‌ها را برای مقابله با چالش‌های مقیاس، قابلیت اطمینان و چابکی به طور مداوم تکامل می‌دهد. این راهنما نه تنها بر پیچیدگی‌های میکروسرویس‌ها نور می‌تاباند، بلکه به عنوان نقشه راهی برای سازمان‌هایی که به دنبال آغاز یک سفر مشابه تحول تکنولوژیکی هستند، عمل می‌کند. https://www.youtube.com/watch?v=CZ3wIuvmHeM Sa_Mirghasemi Sa_Mirghasemi Fri, 29 Dec 2023 22:38:54 +0330 https://virgool.io/@Sa_Mirghasemi/event-driven-architectures-done-right-apache-kafka-qstzcmqcqjme سخنرانی تیم برگلوند در دووکس لهستان ۲۰۲۱، یک بررسی عمیق از معماری‌های مبتنی بر رویداد (EDA) را ارائه داد، به ویژه در زمینه‌ی آپاچی کافکا. این سخنرانی شامل موضوعات گسترده‌ای از اصول ابتدایی EDAs تا چالش‌ها و بهترین شیوه‌های پیاده‌سازی آن‌ها بود. در اینجا خلاصه‌ای مفصل از سخنرانی او آورده شده است:مقدمه‌ای بر معماری مبتنی بر رویداد (EDA):برگلوند با اشاره به علاقه‌ی رو به رشد در EDAs شروع کرد و توجه داشت که این موضوع برای بسیاری از توسعه‌دهندگان نسبتاً تازه است. او تأکید کرد که در حالی که صنعت هنوز در حال یادگیری در مورد EDAs است، از تجربیات اولیه‌ی به‌کارگیری آن‌ها درس‌های ارزشمندی به دست آمده است. او تأکید کرد که بیشتر و بیشتر افراد در مورد EDAs هیجان‌زده هستند، اما مهم است که بدانیم اکثر توسعه‌دهندگان هنوز در حال ساخت اولین سیستم‌های مبتنی بر رویداد خود هستند که می‌تواند چالش‌برانگیز باشد.یک سیستم فروشگاهی مرجع - EDA با کافکا:برگلوند از یک سیستم فروشگاهی فرضی برای توضیح EDAs استفاده کرد. این سیستم شامل یک رابط کاربری وب برای ثبت سفارشات و مدیریت حساب کاربری بود، هر یک با پایگاه داده‌ی محلی خود. او توضیح داد که چگونه سفارشات پردازش و به عنوان رویدادها در یک موضوع کافکا ثبت می‌شوند، که یک جزء حیاتی در EDAs برای حفظ ثبت دائمی رویدادها است. این گزارش رویداد نه صرفاً یک صف که پیام‌ها پس از مصرف از بین می‌روند بلکه یک ثبت دائمی از رویدادها است. او همچنین توضیح داد که چگونه خدماتی مانند پرداخت‌ها و حمل و نقل با این رویدادها به صورت ناهمزمان تعامل دارند، که بر اهمیت عملیات ناهمزمان در EDAs تأکید دارد.عملیات ناهمزمان و به اشتراک‌گذاری داده:یک جنبه‌ی کلیدی از EDAs که برگلوند بر آن تأکید کرد، اهمیت عملیات ناهمزمان بود. برای مثال، او یک سناریو را توضیح داد که در آن سرویس حمل و نقل به اطلاعات کاربر برای پردازش یک سفارش نیاز دارد. به جای انجام یک تماس مستقیم و همزمان با سرویس کاربر، سرویس حمل و نقل از طریق یک مکانیزم مبتنی بر رویداد به این اطلاعات دسترسی پیدا می‌کند. این کار با انتشار رویدادها به یک changelog هر زمان که یک کاربر ایجاد، به‌روزرسانی یا حذف می‌شود، انجام می‌شود و به سرویس حمل و نقل امکان می‌دهد تا یک فروشگاه کلید-مقدار خود را از داده‌های کاربر نگه دارد.چالش‌ها و اشتباهات در EDAs:برگلوند پنج روش اصلی را برای سوء استفاده یا سوء تفاهم احتمالی در EDAs شناسایی کرد: اشتباه در کاربرد پارادایم مبتنی بر رویداد، اجتناب بیش از حد از پایگاه داده‌ها، مدیریت نادرست طرح‌بندی، بیش از حد سفارشی کردن اجزایی که از گزارش‌های رویداد می‌خوانند، و اشتباه در تخمین مقیاس مورد نیاز سیستم. او در مورد رویکرد یک اندازه برای همه هشدار داد و بر نیاز به دیدگاه متعادل هنگام اتخاذ EDAs تأکید کرد.تعادل بین سیستم‌های قدیمی و جدید:بخش قابل توجهی از سخنرانی برگلوند به همزیستی سیستم‌های جدید مبتنی بر رویداد با سیستم‌های میراثی، از جمله پایگاه داده‌های سنتی اختصاص یافت. او توضیح داد که پارادایم‌های قدیمی با ظهور فناوری‌های جدید ناپدید نمی‌شوند؛ بلکه اغلب با یکدیگر همزیستی کرده و یکدیگر را تکمیل می‌کنند. او در مورد نقش ابزارهای تغییر داده در این زمینه صحبت کرد و تأکید کرد که پایگاه‌های داده همچنان مرتبط و ضروری هستند، حتی در زمینه‌یEDAمدیریت طرح‌بندی و مفهوم شبکه داده:برگلوند بر اهمیت طرح‌بندی در EDAs تأکید کرد و ایده‌ی رد کردن طرح‌بندی در دنیای محوریت رویداد را رد کرد. او مفهوم شبکه داده را معرفی کرد و برای مالکیت دامنه‌ی داده و در نظر گرفتن داده به عنوان یک محصول تبلیغ کرد. این رویکرد، به گفته‌ی او، برای مدیریت داده در یک EDA حیاتی است، زیرا به مدیریت تنش بین داده‌های ثابت ('چه هست') و رویدادهای پویا ('چه اتفاق می‌افتد') کمک می‌کند. او تأکید کرد که صرف نظر از اینکه سیستم‌ها بر رویدادها یا داده‌های ثابت تمرکز دارند، درک و مدیریت طرح‌بندی حیاتی است. او همچنین اشاره کرد که شبکه داده این دیدگاه را به دنیای تحلیلی منتقل می‌کند و پیشنهاد می‌کند که کاربرد اصول EDA فراتر از سیستم‌های عملیاتی است.سخنرانی تیم برگلوند در دووکس لهستان ۲۰۲۱، نگاهی جامع به معماری‌های مبتنی بر رویداد ارائه داد، با تمرکز خاص بر آپاچی کافکا. او اصول و شیوه‌هایی که زیربنای EDAs هستند را روشن کرد، چالش‌ها و مشکلات معمول را بررسی کرد و بر اهمیت مدیریت طرح‌بندی تأکید کرد. بینش‌های او در مورد تعادل بین پیاده‌سازی‌های جدید EDA با سیستم‌های میراثی موجود و نقش شبکه داده در مدیریت داده در زمینه‌ی رویداد‌محور، راهنمایی‌های ارزشمندی برای توسعه‌دهندگان و معمارانی که در نظر دارند یا با EDAs کار می‌کنند، ارائه داد. https://www.youtube.com/watch?v=A_mstzRGfIE Sa_Mirghasemi Sa_Mirghasemi Fri, 29 Dec 2023 22:35:46 +0330 https://virgool.io/@Sa_Mirghasemi/design-microservice-architectures-the-right-way-xuyczhw78ueq مقدمه ای بر معماری های میکروسرویسارائه با تأکید بر پیچیدگی ها و چالش های مربوط به معماری های میکروسرویس آغاز می شود. با وجود محبوبیت، میکروسرویس ها می توانند منابع زیادی مصرف کنند و پیچیده باشند، به ویژه هنگامی که به طور ناکافی طراحی شده اند. این بخش بر ضرورت یک رویکرد ساختاریافته برای اجتناب از اشتباهات تأکید دارد.چالش ها و تصورات نادرستمایکل بریزک تأکید می کند که میکروسرویس ها راه حلی همه کاره نیستند و می توانند چالش های منحصربه فردی را ایجاد کنند. این شامل افزایش پیچیدگی در ارکستراسیون، بالقوه محدودیت های عملکردی و دشواری های نگهداری انسجام در سرویس های مختلف است. با بررسی تصورات نادرست رایج، مایکل بریزک در مورد برآورد بیش از حد آسانی اتخاذ فناوری های جدید در محیط میکروسرویس هشدار می دهد. همچنین در مورد نقش تولید کد و اعتقاد اشتباهی که همیشه باید لاگ رویداد منبع اصلی حقیقت باشد، بحث می شود.اصول معماری عالیکلید موفقیت در معماری میکروسرویس، قابلیت مقیاس پذیری، کیفیت، عملکرد، صرفه جویی در هزینه و انعطاف پذیری در برابر تغییرات است. مایکل بریزک بر اهمیت این ویژگی ها در ایجاد معماری ای که نه تنها نیازهای کنونی را برآورده می کند، بلکه در برابر تغییرات آینده مقاوم است، تأکید می کند.مدیریت APIمدیریت صحیح API در معماری میکروسرویس بسیار مهم است. ارائه تأکید دارد بر ضرورت طراحی دقیق API های REST، با اطمینان از زبان نوترال بودن و تمرکز بر منابع. این رویکرد به حفظ یک رابط واضح و مداوم برای تمام سرویس ها کمک می کند که برای ادغام و تعامل بدون درز میکروسرویس های مختلف حیاتی است.تکنیک های تولید کدارائه در مورد استفاده راهبردی از تولید کد برای ساده سازی توسعه و حفظ انسجام صحبت می کند. با خودکارسازی الگوهای کد تکراری و استاندارد، تیم ها می توانند بیشتر بر جنبه های منحصربه فرد هر سرویس تمرکز کنند، بنابراین بهره وری را افزایش داده و خطر خطاها را کاهش می دهند.مدیریت پایگاه دادهیک اصل اصلی در معماری میکروسرویس این است که هر میکروسرویس باید پایگاه داده خود را داشته باشد. مایکل بریزک بر اهمیت نگه داشتن رابط پایگاه داده به صورت خصوصی برای جلوگیری از وابستگی های پیچیده بین سرویس ها تأکید می کند. این ایزولاسیون اطمینان می دهد که تغییرات در یک سرویس به طور تصادفی بر دیگران تأثیر نمی گذارد، بنابراین پایداری و یکپارچگی کل معماری را حفظ می کند.آزمایش و استقرارآزمایش دقیق و تحویل مداوم در معماری های میکروسرویس حیاتی است. مایکل بریزک بر آزمایش خودکار در سطوح مختلف (واحد، یکپارچگی و انتها به انتها) برای اطمینان از استحکام تأکید دارد. استقرار نیز باید خودکار باشد تا انتشار مکرر و قابل اعتماد را تسهیل کند. این خودکارسازی برای حفظ چابکی و پاسخگویی که میکروسرویس ها وعده می دهند، حیاتی است.معماری رویداد محوررویکرد مبتنی بر رویداد برای ارتباطات داخلی سرویس توصیه می شود. این روش در مقایسه با عملیات همزمان، به دلیل مقیاس پذیری و انعطاف پذیری آن، ترجیح داده می شود. ارائه شامل اصول برای مدیریت رابط های رویداد و پیاده سازی پردازش رویداد است. این رویکرد امکان می دهد که سرویس ها به صورت غیرهمزمان به تغییرات و به روزرسانی ها واکنش نشان دهند، که این امر پاسخ دهی سیستم و جداسازی سرویس ها را بهبود می بخشد.ابزار و زیرساختمجموعه صحیح ابزار و پشتیبانی زیرساخت برای موفقیت یک معماری میکروسرویس ضروری است. مایکل بریزک در مورد اهمیت مدیریت پیکربندی، بررسی های سلامت و سایر ابزارهای پشتیبانی که در نظارت، اشکال زدایی و نگهداری میکروسرویس ها کمک می کنند، بحث می کند. این ابزارها برای شناسایی و رسیدگی سریع به مشکلات حیاتی هستند، تا عملکرد روان کل معماری را تضمین کنند.نتیجه گیریدر پایان، ارائه یک بررسی جامع از جنبه های حیاتی طراحی و مدیریت معماری های میکروسرویس را ارائه می دهد. این بر ضرورت یک رویکرد دقیق و ساختاریافته تأکید می کند که پیچیدگی ها و چالش های منحصربه فرد میکروسرویس ها را در نظر می گیرد. نکات کلیدی شامل ضرورت قابلیت مقیاس پذیری، خودکارسازی، مدیریت دقیق API و پایگاه داده و استفاده از رویکرد مبتنی بر رویداد برای ارتباطات داخلی است. ارائه با تأکید دوباره بر اهمیت ابزار و زیرساخت مناسب در پشتیبانی از یک محیط میکروسرویس قوی و کارآمد به پایان می رسد. https://www.youtube.com/watch?v=j6ow-UemzBc Sa_Mirghasemi Sa_Mirghasemi Fri, 29 Dec 2023 22:31:09 +0330 https://virgool.io/@Sa_Mirghasemi/%D9%81%DB%8C%D9%84%D9%85-%DB%8C%DA%A9-brmwlhibp5hz مقدمهدر زمینه پویای معماری نرم‌افزار، حیاتی است که به رویکردهای عملی پایبند باشیم. استفان تیلکوف، به عنوان معمار نرم‌افزار باتجربه، راهنمایی جامع بر اساس تجربیات گسترده خود ارائه می‌دهد. بینش‌های او نقشه‌ای برای ساخت سیستم‌های محکم، قابل توسعه و انعطاف‌پذیر فراهم می‌کنند.اصول اصلی معماری عملیانتخاب‌های آگاهانهمعماران باید با تصمیم‌گیری عمدی در مورد تمرکز خود شروع کنند. این فرآیند شامل درک دامنه پروژه، تعریف رابط‌ها و ایجاد نمودارهای زمینه است. این مراحل به تجسم ساختار کلی و شناسایی اجزای کلیدی و تعاملات آنها کمک می‌کند. با انجام این کار، معماران می‌توانند پیچیدگی را بهتر مدیریت کرده و اطمینان حاصل کنند که هر بخشی از سیستم هدف مشخصی دارد.تنظیم تیم و قانون کانویعبارت "شما چارت سازمانی خود را ارسال می‌کنید" در توسعه نرم‌افزار صدق می‌کند. معماری یک سیستم اغلب بازتابی از ساختار تیمی است که آن را می‌سازد. این پدیده، که به قانون کانوی معروف است، نشان می‌دهد که معماری نرم‌افزار مؤثر با سازماندهی تیم هماهنگ است. معماران باید در نظر بگیرند که چگونه مرزهای تیم و الگوهای ارتباطی، معماری سیستم را شکل می‌دهند. به عنوان مثال، سیستمی که توسط یک تیم کوچک و هماهنگ طراحی شده است، ممکن است با یکی که توسط تیمی بزرگ و پراکنده ساخته شده، تفاوت‌های زیادی داشته باشد.زمینه پادشاه استکپی کردن الگوهای معماری از غول‌های صنعت مانند گوگل یا نتفلیکس بدون در نظر گرفتن زمینه منحصر به فرد پروژه شما می‌تواند به راه‌حل‌های زیرینجام منجر شود. هر سازمان محدودیت‌ها، اهداف و منابع خاص خود را دارد. معماری که برای یک غول فناوری کار می‌کند، ممکن است برای یک استارتاپ کوچک مناسب نباشد. معماران باید رویکردهای خود را با نیازها و زمینه خاص پروژه‌های خود تطبیق دهند.تعادل بین خودمختاری و تصمیم‌گیری متمرکزدر حالی که ترویج خودمختاری در میان تیم‌ها مفید است، برخی تصمیمات معماری نیاز به رویکرد متمرکز دارند. این تصمیمات معمولاً تأثیرات گسترده‌ای دارند و چندین تیم یا کل سیستم را تحت تأثیر قرار می‌دهند. به عنوان مثال، انتخاب فناوری پایگاه داده یا تعریف پروتکل‌های شبکه ممکن است نیاز به تصمیم متمرکز داشته باشد تا اطمینان حاصل شود که سازگاری و قابلیت تعامل در سراسر سیستم وجود دارد.اولویت‌بندی تلاش‌های معماریغیرممکن است که همه بهبودهای بالقوه در یک سیستم را به طور همزمان مورد توجه قرار دهید. معماران باید تلاش‌های خود را اولویت‌بندی کنند و بر مناطق بیشترین تأثیر متمرکز شوند. این رویکرد به رسمیت شناختن کار معماری به عنوان یک فرآیند مداوم، نه یک رویداد یکباره، است. در مورد انتخاب‌های راهبردی است که نیازهای فوری را با اهداف بلندمدت تعادل می‌بخشد.تنظیم قوانین درست برای خودمختاریخودمختاری مؤثر در معماری در مورد یافتن تعادل بین آزادی و قوانین است. برخی جنبه‌ها، مانند انتخاب‌های فناوری، ممکن است به استانداردسازی برای اطمینان از سازگاری و کاهش پیچیدگی نیاز داشته باشند. دیگر زمینه‌ها می‌توانند انعطاف‌پذیرتر باشند و به تیم‌ها اجازه آزمایش و نوآوری بدهند. تنظیم دستورالعمل‌های واضح به تیم‌ها کمک می‌کند تا درک کنند که کجا خودمختاری دارند و کجا باید با تصمیمات معماری گسترده‌تر همسو شوند.فراتر از مستندسازی: نقش‌های فعال معمارینقش یک معمار فراتر از مستندسازی سیستم‌ها است. معماران باید در فرآیندهای تصمیم‌گیری و تکامل مداوم سیستم فعالانه مشارکت کنند. آن‌ها نقش حیاتی در راهنمایی تیم‌ها، حل چالش‌های فنی و اطمینان از همسویی معماری با اهداف سازمان دارند.پذیرش معماری تکراریدیدن معماری به عنوان یک موجودیت در حال تکامل، انعطاف‌پذیری و قابلیت تطبیق را فراهم می‌کند. همانطور که نیازها و فناوری‌ها تغییر می‌کنند، معماری باید قادر به تطبیق باشد. این رویکرد تکراری به معماری به سازمان‌ها امکان می‌دهد تا به چالش‌ها و فرصت‌های جدید به طور مؤثرتر پاسخ دهند.بهینه‌سازی خط لوله توسعهمعماری خوب، فرآیند توسعه را تسهیل می‌کند. باید گلوگاه‌ها را به حداقل رسانده و جریان کارآمد از ایده تا تولید را فراهم کند. به عنوان مثال، معماری که ادغام و تحویل مداوم را پشتیبانی می‌کند، به تیم‌ها امکان می‌دهد تا ویژگی‌ها را به طور مکرر و قابل اعتماد تحویل دهند.پذیرش سادگی: هنگام نیاز خسته‌کننده باشیدنوآوری در معماری باید توسط نیازهای عملی رانده شود، نه جذابیت فناوری‌های جدید. معماران باید سادگی و راه‌حل‌های آزمایش‌شده را بر فناوری‌های پیچیده و پیشرفته ترجیح دهند. این رویکرد خطر را کاهش می‌دهد و نوآوری را بر مناطقی که تأثیر مستقیم بر کسب و کار دارند، متمرکز می‌کند.نتیجه‌گیریاستفان تیلکوف در مورد معماری عملی، اهمیت تصمیم‌گیری‌های آگاهانه و مبتنی بر زمینه در توسعه نرم‌افزار را برجسته می‌کند. او بر لزوم رویکردی عمل‌گرا تأکید می‌کند که ارزش‌های تکامل‌پذیری، سادگی، و هم‌راستایی تیمی را داراست. این اصول به عنوان راهنمایی برای معمارانی که به دنبال ساخت سیستم‌هایی هستند که محکم، قابل توسعه، و قابل تطبیق با نیازهای تغییرپذیر کسب‌وکار و چشم‌اندازهای فناورانه هستند، عمل می‌کنند. جلسه بر تأثیر معماری دقیق در صنعت فناوری اطلاعات تأکید می‌کند و به ما یادآوری می‌کند که هنر معماری در تعادل‌بخشی به منافع متضاد و مدیریت معاملات پیچیده نهفته است. https://www.youtube.com/watch?v=BNTt2aLB1tg Sa_Mirghasemi Sa_Mirghasemi Fri, 29 Dec 2023 22:26:43 +0330 https://virgool.io/@Sa_Mirghasemi/%D8%AF%D8%A7%D9%86%D8%B4-%D8%A7%D9%88%D9%84%DB%8C%D9%87-niigsnrpi6lu معماری مدولار-مونولیتیکمعماری مدولار-مونولیتیک ترکیبی از دو رویکرد معماری نرم‌افزاری است: مونولیتیک و میکروسرویس‌ها. در این معماری، یک برنامه به صورت یک واحد تنها اجرا می‌شود، اما درون آن به ماژول‌های مجزا تقسیم می‌شود. هر ماژول مسئولیت یک بخش خاص از کاربرد را بر عهده دارد و می‌تواند به صورت مستقل توسعه و نگهداری شود.این رویکرد ترکیبی از مزایای معماری مونولیتیک، مانند سادگی استقرار و کارایی بالا، با انعطاف‌پذیری معماری مبتنی بر میکروسرویس‌ها را ارائه می‌دهد. ماژول‌ها به گونه‌ای طراحی می‌شوند که ارتباطات درونی آن‌ها کمینه شود، در نتیجه تغییر در یک ماژول تأثیر کمتری بر سایر بخش‌ها دارد.این معماری برای پروژه‌هایی که نیاز به تعادل بین تجزیه و تحلیل و انعطاف‌پذیری دارند، مناسب است. همچنین، برای سازمان‌هایی که می‌خواهند به تدریج از معماری مونولیتیک به میکروسرویس‌ها حرکت کنند، گزینه‌ای ایده‌آل محسوب می‌شود.سرویس ابری آمازونآمازون وب سرویس‌ها (AWS) یک پلتفرم ابری است که توسط آمازون ارائه می‌شود و خدمات متنوعی در زمینه‌های محاسبات، ذخیره‌سازی، و شبکه‌سازی را در اختیار کاربران قرار می‌دهد. AWS به کسب‌وکارها امکان می‌دهد تا زیرساخت‌های IT خود را به صورت مجازی و با هزینه‌ای متغیر مدیریت کنند. این سرویس‌ها شامل ماشین‌های مجازی (EC2)، ذخیره‌سازی ابری (S3)، و پایگاه داده‌های مدیریت شده (RDS) می‌شوند.AWS به دلیل انعطاف‌پذیری، مقیاس‌پذیری، و امنیت بالا، محبوبیت زیادی در میان استارتاپ‌ها، شرکت‌های بزرگ، و سازمان‌های دولتی دارد. این پلتفرم امکان ارائه خدمات IT با کیفیت بالا و هزینه کمتر را فراهم می‌آورد و به کاربران اجازه می‌دهد تا بر روی نوآوری و رشد کسب‌وکار خود تمرکز کنند.AWS همچنین خدمات پیشرفته‌ای مانند یادگیری ماشین، هوش مصنوعی، و تحلیل داده‌ها را ارائه می‌دهد، که به توسعه راه‌حل‌های نوآورانه در صنایع مختلف کمک می‌کند.رویکرد API-first Approachرویکرد API-اول یک استراتژی توسعه نرم‌افزار است که در آن طراحی API (رابط برنامه‌نویسی اپلیکیشن) قبل از توسعه برنامه‌های کاربردی انجام می‌شود. در این رویکرد، API به عنوان قراردادی بین سرور و کاربران نهایی یا سایر سیستم‌ها عمل می‌کند. این استراتژی بر اهمیت ارتباطات و تعاملات بین سیستم‌ها تأکید دارد و به توسعه‌دهندگان امکان می‌دهد تا بر روی ایجاد رابط‌های کاربری و تجربه کاربری متمرکز شوند.رویکرد API-first به تسریع فرآیند توسعه کمک می‌کند، زیرا تیم‌های مختلف می‌توانند به صورت همزمان روی بخش‌های مختلف پروژه کار کنند. همچنین، این رویکرد انعطاف‌پذیری بیشتری در برابر تغییرات فناوری و نیازهای کسب‌وکار فراهم می‌آورد.پایگاه داده‌ NoSQLپایگاه داده های NoSQL نوعی از سیستم‌های مدیریت پایگاه داده هستند که برای ذخیره‌سازی و بازیابی داده‌ها در فرمت‌هایی غیر از جدول‌های رابطه‌ای سنتی طراحی شده‌اند. این پایگاه داده‌ها برای مقابله با حجم بالای داده‌ها، توزیع داده‌ها و سرعت بالای پردازش طراحی شده‌اند و در مواردی که نیاز به انعطاف‌پذیری بالا در ساختار داده‌ها وجود دارد، کاربردی هستند.NoSQL داده‌ها را در فرمت‌های مختلفی مانند سندها (Document), کلید-مقدار (Key-Value), ستونی (Columnar) و گراف (Graph) ذخیره می‌کند. این تنوع در ذخیره‌سازی امکان پاسخگویی به نیازهای متنوع کسب‌وکارها را فراهم می‌آورد و به ویژه در برنامه‌هایی که با داده‌های بزرگ و پیچیده سروکار دارند، مفید است.معماری بدون سرورمعماری بدون سرور یک مدل توسعه نرم‌افزار است که در آن مدیریت زیرساخت‌های سرور به عهده ارائه‌دهنده خدمات ابری است و توسعه‌دهندگان تنها بر روی کد نویسی و منطق کسب‌وکار تمرکز می‌کنند. در این مدل، منابع به صورت خودکار مقیاس‌بندی می‌شوند و هزینه‌ها بر اساس میزان استفاده واقعی از منابع محاسبه می‌شود.معماری بدون سرور به توسعه‌دهندگان اجازه می‌دهد تا بدون نگرانی در مورد مدیریت زیرساخت‌ها، بر روی ایجاد و نوآوری در محصولات خود تمرکز کنند. این مدل برای اپلیکیشن‌هایی که نیاز به مقیاس‌پذیری بالا دارند و همچنین برای کاهش هزینه‌های عملیاتی مناسب است.طراحی مبتنی بر دامنهطراحی مبتنی بر دامنه (Domain-Driven Design یا DDD) یک رویکرد در توسعه نرم‌افزار است که تمرکز اصلی آن بر روی مدل‌سازی دامنه و منطق کسب‌وکار است. در DDD، توسعه‌دهندگان و کارشناسان دامنه به صورت مشترک برای ایجاد یک مدل زبانی مشترک و درک عمیق‌تر از دامنه کسب‌وکار همکاری می‌کنند. این رویکرد به ایجاد نرم‌افزارهایی کمک می‌کند که به خوبی با نیازهای واقعی کسب‌وکار هم‌راستا هستند.DDD به توسعه‌دهندگان کمک می‌کند تا پیچیدگی‌های دامنه کسب‌وکار را بهتر درک کنند و راه‌حل‌های نرم‌افزاری را بر اساس آن شکل دهند. این رویکرد برای پروژه‌هایی با دامنه‌های پیچیده و تغییرپذیر مناسب است و به ایجاد نرم‌افزارهایی که قابلیت توسعه و نگهداری بالایی دارند، کمک می‌کند.معماری شش ضلعیمعماری شش‌ضلعی، که به عنوان معماری پورت‌ها و اداپتورها نیز شناخته می‌شود، یک الگوی طراحی نرم‌افزار است که هدف آن جداسازی منطق کسب‌وکار از جزئیات فنی مانند رابط کاربری و دسترسی به داده‌ها است. در این معماری، منطق کسب‌وکار در مرکز قرار دارد و تعاملات با جهان خارج از طریق پورت‌ها و اداپتورها انجام می‌شود.این الگو به توسعه‌دهندگان امکان می‌دهد تا بر روی منطق کسب‌وکار تمرکز کنند و جزئیات فنی را به صورت ماژول‌های جداگانه مدیریت کنند. معماری شش‌ضلعی به افزایش تست‌پذیری و نگهداری نرم‌افزار کمک می‌کند و برای سیستم‌هایی که نیاز به انعطاف‌پذیری بالا در برابر تغییرات فناوری دارند، مناسب است.ذخیره سازی رویداد محورذخیره‌سازی رویدادمحور یک الگوی طراحی در مهندسی نرم‌افزار است که در آن تغییرات در وضعیت یک سیستم به صورت یک سری رویداد ذخیره می‌شوند. به جای ذخیره‌سازی وضعیت نهایی، هر تغییر به عنوان یک رویداد جداگانه ثبت می‌شود، که این امکان را فراهم می‌آورد تا تاریخچه کاملی از تغییرات و دلایل آن‌ها حفظ شود.این روش به ویژه در سیستم‌هایی که نیاز به تحلیل دقیق تغییرات و بازیابی وضعیت‌های گذشته دارند، مفید است. ذخیره‌سازی رویدادمحور به توسعه‌دهندگان اجازه می‌دهد تا سیستم‌ها را به راحتی بازسازی کنند و درک بهتری از تاریخچه و تحولات سیستم داشته باشند.پلتفرم های کم‌کدپلتفرم‌های کم‌کد راه‌حل‌هایی هستند که به توسعه‌دهندگان و غیر توسعه‌دهندگان امکان می‌دهند تا با استفاده از رابط‌های گرافیکی و کشیدن و رها کردن اجزا، نرم‌افزارها و برنامه‌های کاربردی را به سرعت توسعه دهند. این پلتفرم‌ها به کاهش نیاز به نوشتن کد دستی کمک می‌کنند و فرآیند توسعه نرم‌افزار را تسریع می‌بخشند.پلتفرم‌های کم‌کد برای سازمان‌هایی که به دنبال راه‌حل‌های سریع و کارآمد برای توسعه نرم‌افزار هستند، مناسب است. آن‌ها به ویژه در مواردی که نیاز به توسعه سریع اپلیکیشن‌ها وجود دارد یا منابع توسعه محدود هستند، کاربردی هستند.سیستم‌های مدیریت فرآیند کسب و کارسیستم‌های مدیریت فرآیند کسب‌وکار (BPMS) ابزارهایی هستند که به سازمان‌ها کمک می‌کنند تا فرآیندهای کسب‌وکار خود را به صورت مؤثر مدیریت، بهینه‌سازی و خودکارسازی کنند. BPMS امکان طراحی، اجرا، نظارت و بهبود فرآیندهای کسب‌ و کار را فراهم می‌آورد و به سازمان ها اجازه می دهد تا به سرعت به تغییرات بازار واکنش نشان دهند.این سیستم‌ها به کاهش خطاها، افزایش بهره‌وری و بهبود تعاملات بین بخش‌های مختلف سازمان کمک می‌کنند. BPMS می‌تواند شامل ابزارهایی برای مدل‌سازی فرآیند، اتوماسیون، مدیریت کارکرد و تحلیل داده‌ها باشد.صف پیام‌رسانیصف پیام‌رسانی، مانند Kafka و RabbitMQ، سیستم‌هایی هستند که به عنوان واسطه‌ای برای ارسال و دریافت پیام‌ها بین کامپوننت‌های مختلف در یک سیستم توزیع‌شده عمل می‌کنند. این ابزارها به سیستم‌ها اجازه می‌دهند تا به صورت مقیاس‌پذیر و قابل اعتماد با یکدیگر ارتباط برقرار کنند.Kafka برای پردازش داده‌های بزرگ و پیام‌رسانی در مقیاس بالا طراحی شده است، در حالی که RabbitMQ برای ارائه یک سیستم پیام‌رسانی قابل اعتماد و مدیریت‌پذیر مورد استفاده قرار می‌گیرد. هر دو ابزار به سازمان‌ها کمک می‌کنند تا داده‌ها و پیام‌ها را به صورت کارآمد در سیستم‌های پیچیده مدیریت کنند. کانتینر ارکستریشن کانتینر ارکستریشن فرآیندی است که در آن استقرار، مدیریت و مقیاس‌بندی کانتینرهای نرم‌افزاری به صورت خودکار انجام می‌شود. این فرآیند به ویژه برای محیط‌های توزیع‌شده و کانتینریزه شده مانند Kubernetes مهم است. Kubernetes یک سیستم اوپن‌سورس است که به سازمان‌ها امکان می‌دهد تا برنامه‌های کانتینریزه شده خود را به صورت مؤثر در محیط‌های توزیع‌شده مدیریت کنند.Kubernetes به توسعه‌دهندگان کمک می‌کند تا با استفاده از ابزارهای خودکار، کانتینرها را به راحتی مقیاس‌بندی، به‌روزرسانی و نگهداری کنند. این سیستم برای برنامه‌هایی که نیاز به مقیاس‌پذیری بالا و دسترس‌پذیری مداوم دارند، ایده‌آل است.ابزارهای مدیریت لاگابزارهای مدیریت لاگ، مانند ELK Stack (Elasticsearch, Logstash, Kibana)، به سازمان‌ها کمک می‌کنند تا داده‌های لاگ خود را جمع‌آوری، پردازش، ذخیره‌سازی و تحلیل کنند. ELK Stack یک راه‌حل محبوب برای مدیریت لاگ در مقیاس بزرگ است که به تحلیل داده‌های لاگ به صورت زمان‌واقعی کمک می‌کند.Elasticsearch به عنوان موتور جستجو و ذخیره‌سازی داده‌ها، Logstash برای پردازش و ارسال داده‌ها، و Kibana برای تجسم و تحلیل داده‌ها استفاده می‌شود. این ابزارها به سازمان‌ها امکان می‌دهند تا به سرعت مشکلات را شناسایی و رفع کنند و به درک عمیق‌تری از عملکرد سیستم‌های خود دست یابند.ابزارهای نظارتیابزارهای نظارتی مانند Prometheus به سازمان‌ها کمک می‌کنند تا عملکرد و سلامت سیستم‌های نرم‌افزاری خود را به صورت مداوم رصد و تحلیل کنند. Prometheus یک سیستم نظارتی اوپن‌سورس است که برای جمع‌آوری و ذخیره‌سازی متریک‌های زمان‌واقعی طراحی شده است. این ابزار امکان جمع‌آوری داده‌ها از طریق مدل‌های داده‌ای مختلف و پشتیبانی از پرس‌وجوهای پیچیده را فراهم می‌آورد.Prometheus به ویژه برای محیط‌های توزیع‌شده و کانتینریزه‌شده مناسب است و به توسعه‌دهندگان اجازه می‌دهد تا به سرعت مشکلات عملکردی را شناسایی و رفع کنند. این سیستم با ارائه داشبوردهای قابل تنظیم و هشدارهای خودکار، به بهبود کیفیت و پایداری سیستم‌های نرم‌افزاری کمک می‌کند.تحلیل کد استاتیکتحلیل کد استاتیک، مانند آنچه توسط SonarQube ارائه می‌شود، فرآیندی است که در آن کد منبع نرم‌افزار بدون اجرای آن بررسی و تحلیل می‌شود. SonarQube یک پلتفرم اوپن‌سورس است که به توسعه‌دهندگان کمک می‌کند تا کیفیت کد خود را بهبود بخشند و خطاها، آسیب‌پذیری‌ها و بد اسمل های کد را شناسایی کنند.این ابزار امکان تحلیل کد در زبان‌های برنامه‌نویسی مختلف را فراهم می‌آورد و گزارش‌های جامعی در مورد کیفیت کد، پوشش تست و موارد دیگر ارائه می‌دهد. SonarQube به تیم‌های توسعه اجازه می‌دهد تا به صورت مداوم کیفیت کد خود را ارزیابی و بهبود بخشند، که این امر به کاهش خطاها و افزایش کارایی کد کمک می‌کند.منابع:https://www.fullstacklabs.co/blog/modular-monolithic-vs-microserviceshttps://en.wikipedia.org/wiki/Amazon_Web_Serviceshttps://aws.amazon.com/application-hosting/benefits/#:~:text=AWS%20is%20designed%20to%20allow,access%20AWS's%20application%20hosting%20platform.https://www.learncsdesign.com/understanding-the-api-first-approach/https://www.geeksforgeeks.org/types-of-nosql-databases/https://www.ibm.com/topics/nosql-databaseshttps://www.datadoghq.com/knowledge-center/serverless-architecture/#:~:text=Serverless%20architecture%20is%20an%20approach,storage%20systems%20at%20any%20scale.https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/february/best-practice-an-introduction-to-domain-driven-designhttps://en.wikipedia.org/wiki/Hexagonal_architecture_(software)https://microservices.io/patterns/data/event-sourcing.html#:~:text=Event%20sourcing%20persists%20the%20state,to%20the%20list%20of%20events.https://www.mendix.com/low-code-guide/https://powerautomate.microsoft.com/en-gb/bpms-business-process-management-software/https://www.ibm.com/topics/business-process-management#:~:text=Business%20process%20management%20(BPM)%2C,broader%20than%20these%20adjacent%20topics.https://www.ibm.com/topics/message-queueshttps://cloud.google.com/discover/what-is-container-orchestration#:~:text=Container%20orchestration%20automatically%20provisions%2C%20deploys,worrying%20about%20the%20underlying%20infrastructure.https://www.crowdstrike.com/cybersecurity-101/observability/log-management/https://www.splunk.com/en_us/data-insider/what-is-it-monitoring.htmlhttps://logz.io/blog/open-source-monitoring-tools/https://www.perforce.com/blog/sca/what-static-analysishttps://docs.sonarsource.com/sonarqube/latest/?_gl=1*n7jc1d*_gcl_au*MTU3NDc1NTQzMy4xNzAwNzIyNjk0*_ga*MTY2NTY0OTIwOS4xNzAwNzIyNjk0*_ga_9JZ0GZ5TC6*MTcwMDcyMjY5My4xLjEuMTcwMDcyMjcwNy40Ni4wLjA. Sa_Mirghasemi Sa_Mirghasemi Mon, 20 Nov 2023 22:56:37 +0330 https://virgool.io/@Sa_Mirghasemi/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DA%A9%D8%AA%D8%A7%D8%A8-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%AA%D9%85%DB%8C%D8%B2-%D8%A8%D8%AE%D8%B4-%D8%B3%D9%88%D9%85-ygzv1xuvbf6k معماری چیست؟معماری نرم‌افزار نقش مهمی در توسعه، استقرار، عملیات و نگهداری سیستم‌های نرم‌افزاری ایفا می‌کند. این معماری به تأمین نگهداری سیستم، قابلیت مقیاس‌پذیری، و استقرار کارآمد کمک می‌کند. مهمترین نقاط معماری نرم‌افزار به شرح زیر هستند:توسعه (Development): معماری نرم‌افزار باعث سهولت توسعه سیستم برای تیم‌های توسعه می‌شود، به ویژه در سیستم‌های بزرگ با چندین تیم توسعه‌دهنده.استقرار (Deployment): هدف معمار نرم‌افزار، ایجاد سیستمی است که با یک اقدام آسان می‌تواند مستقر شود. استراتژی استقرار باید در چرخه عمر توسعه نرم‌افزار در نظر گرفته شود تا معماری سازگار با استقرار ایجاد شود. عملیات (Operation): معماری نرم‌افزار تأثیر زیادی بر عملکرد سیستم دارد، اما این تأثیر به‌طور کلی دیده نمی‌شود. با این حال، یک معماری خوب نیازهای عملیاتی سیستم را به توسعه‌دهندگان انتقال می‌دهد و کارکرد سیستم را بهبود می‌بخشد.نگهداری و به‌روزرسانی (Maintenance): سیستم‌های نرم‌افزاری با معماری مناسب نگهداری و به‌روزرسانی آسان‌تری دارند. این امر به دلیل ساختار واضح معماری و تفهیم نحوه تعامل اجزا با یکدیگر است.رابرت سسیل مارتین به اهمیت معماری نرم‌افزار تأکید می‌کند و این معماری را به عنوان یک عامل اساسی در توسعه و مدیریت سیستم‌های نرم‌افزاری معرفی می‌کند.استقلالمارتین در مورد اهمیت معماری نرم‌افزار در پشتیبانی از موارد استفاده (Use cases) و عملیات (Operation) سیستم، و همچنین توسعه (Development) و استقرار (Deployment) بحث می‌کند. این معماری باید نه تنها موارد استفاده سیستم را پشتیبانی کند و رفتار مطلوب را ارتقاء دهد، بلکه نیازهای عملیاتی مانند توان عملیاتی و زمان پاسخگویی را نیز پشتیبانی کند. همچنین، معماری باید محیط توسعه را با تقسیم سیستم به اجزاء مستقل قابل توسعه فراهم کند و به آسانی استقرار سیستم را امکان‌پذیر کند.او تاکید می‌کند که یک معماری نرم‌افزار خوب گزینه‌های مختلفی برای حل مسائل مختلف ارائه می‌دهد و از تعیین نیازمندی‌ها، محدودیت‌های عملیاتی، ساختار تیم، و نیازهای استقرار به طور دقیق پیشاهنگی نمی‌کند. این امکان را به توسعه‌دهندگان می‌دهد که با تغییرات در نیازمندی‌ها و محیط سیستم به راحتی سازگار شوند.مارتین به دو اصل اساسی تأکید می‌کند: اصل مسئولیت واحد که به تکلیف یکتا برای هر کلاس اشاره دارد. اصل بسته‌شدن مشترک که کلاس‌هایی که با هم تغییر می‌کنند را به عنوان یک واحد گروه‌بندی می‌کند. این اصول به تقسیم سیستم به اجزاء جداگانه که به راحتی قابل تغییر و نگهداری هستند کمک می‌کنند.در نهایت، تفکیک لایه‌ها و تفکیک نیازمندی‌ها نیز به توسعه‌دهندگان امکان می‌دهد تا به صورت مستقل بر روی هر لایه کار کنند و تغییرات در یک لایه تأثیر چندانی بر لایه‌های دیگر نگذارند. این تفکیک‌لایه‌ای به توسعه، تست، و نگهداری نرم‌افزار کمک کرده و به بهره‌وری و کیفیت کد افزوده می‌شود.ترسیم مرز هامعماری نرم‌افزار باید قابلیت افزودن یا حذف افزونه‌ها را بدون تأثیر منفی بر سیستم اصلی فراهم کند و همچنین باید ورودی‌ها و خروجی‌ها را به عنوان رابط‌های خارجی در نظر بگیرد و مدیریت آن‌ها را به طور کارآمد انجام دهد.همچنین، معماران نرم‌افزار باید از تصمیم‌گیری زودهنگام خودداری کنند، به ویژه زمانی که مواردی مانند چارچوب‌ها، پایگاه‌های داده، سرورهای وب، کتابخانه‌های ابزار، تزریق وابستگی و موارد مشابه مورد بحث قرار می‌گیرد. تصمیمات زودهنگام باید فرعی و قابل تعویق باشند تا در آخرین لحظه اتخاذ شوند.مثال‌هایی از داستان‌های شرکت‌ها نیز آورده شده که نشان می‌دهد تصمیمات زودهنگام چگونه می‌توانند منجر به پیچیدگی و اشکالات در توسعه نرم‌افزار شوند. در نهایت، معماران نرم‌افزار باید تمرکز خود را بر ترسیم مرزهایی که جفت شدن را به حداقل می‌رسانند و انعطاف‌پذیری را افزایش می‌دهند، قرار دهند تا سیستم‌ها را با نیازهای متغیر در طول زمان سازگار کنند و از شکست خوردن آنها جلوگیری کنند.آناتومی مرز هامعماری نرم‌افزار باید تعاملات رابط کاربر و تعیین مرزهای سیستم را مدیریت کند. این شامل اهمیت ارائه دهندگان و نماها به عنوان واسطه های کاربر می‌شود که مسئول تبدیل داده‌ها به قالب مناسب برای نمایش هستند.معماری باید مرزهای سیستم را تعریف کند و به مدیریت کنترل داده‌ها و عبور از مرزها از یک لایه به لایه دیگر پرداخته و کامپوننت‌های استقرار را با مقیاس‌پذیری و اطمینان بخشی طراحی کند. همچنین، معماری باید توانایی مدیریت همزمانی و توزیع درخواست‌ها را داشته باشد.از جنبه‌های مختلفی انواع مختلف مرزهای معماری برای سیستم‌های نرم‌افزاری معرفی می‌شود، از جمله مونولیت، جزء استقرار، فرآیند محلی و سرویس. تصمیم در مورد نوع مناسب مرز معماری باید با توجه به نیازهای سیستم اتخاذ شود.بنابراین، معماران نرم‌افزار باید توجه کافی به تعیین مرزها، تعاملات رابط کاربر و انتخاب مناسب نوع مرز معماری داشته باشند تا سیستم‌هایی ایجاد کنند که همچنان به تغییرات نیازهای در حال تغییر در طول زمان پاسخ دهند و از پیچیدگی‌های زیاد و خطر شکست جلوگیری کنند.سیاست و سطح سیاست‌ها به عنوان قوانین تعریف می‌شوند که رفتار یک سیستم را تعیین می‌کنند. نویسنده تأکید می‌کند که سیاست‌ها باید بر اساس روشی که تغییر می‌کنند، گروه‌بندی شوند.همچنین، تأثیر تغییرات معماری بر کد منبع را کاهش دادن و جداسازی خط‌مشی‌ها از سیاست‌های ورودی/خروجی را مورد توجه قرار می‌دهد. این تمرکز بر تعیین سطوح و سیاست‌ها به معماران نرم‌افزار کمک می‌کند تا سیستم‌هایی ایجاد کنند که قوی‌تر، سازگارتر و قابل نگهداری‌تر باشند.قوانین کسب و کارمعماری نرم‌افزار باید قوانین تجاری و سیاست‌های سیستمی را به دو دسته تجزیه کند:1. قوانین حیاتی کسب و کار (Critical Business Rules):این قوانین ارزش یا صرفه جویی در هزینه کسب و کار را ایجاد می‌کنند، حتی اگر سیستم خودکاری برای اجرای آنها وجود نداشته باشد.این قوانین به طور جدایی ناپذیری به داده‌های تجاری حیاتی وابسته هستند.2. موارد استفاده (Use Cases):این موارد استفاده نحوه عملکرد یک سیستم خودکار را تعریف و محدود می‌کنند.آنها مختص یک برنامه واحد هستند و حرکات موجودات را کنترل می‌کنند.مارتین تأکید دارد که قوانین تجاری باید از سایر موارد در سیستم مانند رابط کاربری و پایگاه داده جدا نگه داشته شوند. برای این منظور، او توصیه می‌کند که قوانین تجاری را به موجودیت‌ها و موارد استفاده گروه‌بندی کنیم و از وارونگی وابستگی استفاده کنیم تا اطمینان حاصل شود که وابستگی‌ها به مفاهیم سطح بالاتر اشاره دارند. این رویکرد به ایجاد سیستم‌های نرم‌افزاری قوی‌تر، سازگارتر و قابل نگهداری‌تر کمک می‌کند.معماری فریاداین فصل درباره معماری نرم‌افزار و اهمیت تمرکز بر موارد استفاده (Use Cases) به جای چارچوب‌ها (Frameworks) و چگونگی ارتباط میان معماری و وب سخن می‌گویند.معماری نرم‌افزار باید هدف و عملکرد سیستم را مشخص کند و از وابستگی به چارچوب‌ها پرهیز کند.چارچوب‌ها ابزارهای کاربردی هستند و باید برای پشتیبانی از موارد استفاده مورد استفاده قرار گیرند، نه برعکس.معماری‌ها باید قابل آزمایش باشند و همه موارد استفاده باید بدون وابستگی به چارچوب‌ها قابل آزمایش باشند.معماری باید درباره سیستم به خوانندگان بگوید، نه درباره چارچوب‌ها.معماری نرم‌افزار باید تمرکز بر موارد استفاده داشته باشد و نه اتکا به چارچوب‌ها. این به توسعه‌دهندگان اجازه می‌دهد که سیستم‌های قابل آزمایش و قابل تست را طراحی و توسعه دهند.معماری تمیزمعماری شش ضلعی (Hexagonal Architecture) یک الگوی طراحی نرم‌افزاری است که سه لایه اصلی شامل موجودیت‌ها (Entities)، موارد استفاده (Use Cases) و آداپتورهای رابط (Interface Adapters) را دارد. این معماری به منظور ساخت سیستم‌های مستقل از چارچوب‌ها، قابل آزمایش و تغییر آسان استفاده می‌شود. معماری شش ضلعی بر پایه قاعده وابستگی عمل می‌کند که وابستگی کد منبع باید به سمت داخل و به سمت سیاست‌های سطح بالاتر اشاره کند.معماری‌های مختلفی نیز وجود دارند که تمرکز خود را بر جداسازی لایه‌ها و قواعد بیزینسی از عوامل خارجی و فریم‌ورک‌ها قرار داده‌اند. این معماری‌ها از جمله hexagonal، DCI و BCE هستند. این انتخاب‌ها سیستم‌های قابل آزمایش و تغییر، بدون وابستگی به ابزارها و فریم‌ورک‌ها ایجاد می‌کنند.معماری نرم‌افزاری باید از تمرکز بر فریم‌ورک‌ها و عوامل خارجی خودداری کرده و به ایجاد سیستم‌های مستقل، قابل آزمایش و تغییر تمرکز کند. این انتخاب‌ها به تست‌پذیری و انعطاف در توسعه نرم‌افزار کمک می‌کنند.ارائه دهندگان و اشیای فروتنمارتین در این بخش درباره الگوی "شیء فروتن" یا Humble Object و کاربردهای آن در نرم‌افزار صحبت می‌کند.الگوی شیء فروتن، الگویی طراحی نرم‌افزاری است که برای جدا کردن رفتارهای سخت به تست (hard-to-test behaviors) از رفتارهای آسان به تست (easy-to-test behaviors) به کار می‌رود. این الگو به بهبود تست‌پذیری و نگهداری سیستم کمک می‌کند.یک نمونه از الگوی Humble Object، الگوی Presenter در رابط کاربری گرافیکی (GUI) است که وظیفه جدا کردن نمایش داده‌ها از فرمت‌بندی و مدیریت داده‌ها را دارد. این تفکیک نگرانی‌ها باعث می‌شود که تست کردن Presenter آسان‌تر شود.الگوی Humble Object می‌تواند نیز در مرز‌گذاری بین سرویس‌ها و ایجاد مرز میان سیستم‌های مختلف به کار رود. این مرز می‌تواند توسط یک کلاس ساده پیاده‌سازی شود و تست‌پذیری و نگهداری سیستم‌ها را بهبود ببخشد.در کل، الگوی Humble Object ابزار مفیدی برای بهبود تست‌پذیری و نگهداری سیستم‌های نرم‌افزاری است. این الگو با جدا کردن رفتارهای سخت به تست از رفتارهای آسان به تست کمک می‌کند و نوشتن تست‌ها و تغییرات سیستم را آسان‌تر می‌کند.مرز های جزئیدر این فصل مارتین مفهوم مرزهای جزئی (Partial Boundaries) و نقش آنها در معماری نرم‌افزاری را مورد بحث قرار می‌دهد.مرزهای جزئی تعریف می‌شوند تا در مراحل ابتدایی پروژه به مشکلات نگرانی‌های مربوط به مرزهای کامل جلوگیری کنند. این مرزها، گامی در مسیر تجهیز به یک مرز کامل هستند و از هزینه‌های کمتری برخوردارند.انواع مرزهای جزئی شامل: "از آخرین مرحله بگذرید" که هزینه زیادی دارد ولی انعطاف بیشتری دارد."مرزهای یک بعدی" که هزینه کمتری دارند اما انعطاف کمتری دارند. "نماها" که هزینه کمتری دارند ولی انعطاف کمتری نیز دارند.مرزهای جزئی نقش مهمی در کاهش هزینه‌ها و افزایش انعطاف در پروژه‌های نرم‌افزاری دارند. آنها به معماران اجازه می‌دهند تا در مواقعی که هزینه مرز کامل زیاد است یا می‌خواهند مکانی برای مرز آینده ایجاد کنند، از آنها استفاده کنند.لایه ها و محدودیت هادر این فصل، به مفهوم معماری نرم‌افزاری در بازی Hunt the Wumpus و نقش مرزها در این معماری پرداخته شده است. معماری این بازی از سه مؤلفه اصلی تشکیل شده است:مؤلفه UI: این مؤلفه کنترل ورودی کاربر را دارد و با استفاده از یک API مستقل از زبان با مؤلفه قوانین بازی ارتباط برقرار می‌کند.مؤلفه قوانین بازی: این مؤلفه وضعیت بازی را ذخیره می‌کند و با مؤلفه UI ارتباط دارد. این مؤلفه مسئول اعمال قوانین بازی و ارتباط با مؤلفه ذخیره‌سازی داده است.مؤلفه ذخیره‌سازی داده: این مؤلفه مسئول حفظ داده‌های بازی است و با مؤلفه قوانین بازی ارتباط دارد.این معماری با جداسازی مؤلفه UI از مؤلفه قوانین بازی، امکان پشتیبانی از زبان‌های مختلف در بازارهای مختلف را فراهم می‌کند. همچنین، این جداسازی از مؤلفه‌های مختلف UI به قوانین بازی اجازه می‌دهد تا از همان مؤلفه‌های قوانین بازی دوباره استفاده کنند. این معماری با جداسازی مؤلفه‌ها و ایجاد API‌های مناسب بین آنها، وابستگی‌ها را به درستی مدیریت می‌کند.در نهایت، مفهوم مرزها در معماری نرم‌افزاری تأکید می‌کند که مرزها در جاهایی قرار داده شوند که هزینه پیاده‌سازی آنها کمتر از هزینه نادیده گرفتن آنها باشد. این جداسازی مرزها به معماران امکان انعطاف در طراحی و تغییر در سیستم را می‌دهد.کامپوننت اصلیدر این فصل، برای نشان دادن اهمیت کامپوننت اصلی، کامپوننت اصلی بازی Hunt the Wumpus مورد بررسی قرار می‌گیرد. این کامپوننت وظیفه ایجاد و مدیریت بازی را بر عهده دارد. کامپوننت اصلی دارای وظایف مهمی می‌باشد که شامل ایجاد بازی و نقشه، تفسیر دستورات ورودی بازیکن، اجرای دستورات بازیکن، و پیگیری از وضعیت بازی و امتیازات ضربه بازیکن است. این کامپوننت در واقع مسئولیت‌های اصلی بازی را بر عهده دارد و با کلیگری دیگر اجزا به هم چسبیده و متصل می‌شود.کامپوننت اصلی به عنوان قسمتی اساسی از معماری بازی و نقش مهمی در عملکرد و اجرای بازی دارد. این کامپوننت می‌تواند به عنوان نقطه ورودی اصلی به برنامه عمل کند و تمام اجزا و قوانین بازی را به هم چسباند.از این رو، کامپوننت اصلی یکی از قسمت‌های حیاتی هر نرم افزاری است.سرویس های بزرگ و کوچکدر این فصل، مارتین در مورد معماری‌های مبتنی بر خدمات و توسعه مستقل خدمات بحث می‌کند. او تاکید دارد که تفکیک برنامه به خدمات مستقل تنها به تنهایی نمی‌تواند به عنوان یک معماری محسوب شود. در واقع، وابستگی‌ها و محدودیت‌های معماری تعیین می‌شوند و تعریف می‌شوند. نویسنده از مثال یک سیستم جمع‌آوری تاکسی استفاده می‌کند تا نشان دهد که توسعه و استقرار مستقل خدمات ممکن است دشوار باشد و خدمات معمولاً نمی‌توانند به صورت کاملاً مستقل عمل کنند. مارتین به ترتیب نکات اصلی زیر را مطرح می‌کند:خدمات لزوماً از نظر معماری مهم نیستند.خدمات می‌توانند به شدت با یکدیگر پیوند شوند. سرویس‌ها همیشه نمی‌توانند به طور مستقل توسعه، مستقر و عملیاتی شوند.معماری‌های یکپارچه و مبتنی بر مؤلفه نیز می‌توانند مقیاس‌پذیر باشند و توسعه و نگهداری آن‌ها ممکن است آسان‌تر باشد.این نکات، توجه به آنچه که معمولاً به عنوان تفکیک خدمات و خدمات مستقل در توسعه نرم‌افزار مورد نظر قرار می‌گیرد را به چالش می‌کشد. مارتین معتقد است که توسعه سیستم‌های یکپارچه و مبتنی بر مؤلفه نیز می‌تواند یک گزینه مناسب باشد و توسعه و نگهداری آن‌ها ممکن است آسان‌تر باشد. این دیدگاه تأکید می‌کند که معماری نه تنها تفکیک فیزیکی خدمات را تعریف می‌کند بلکه وابستگی‌ها و محدودیت‌ها نیز تعیین می‌شوند و این مسائل نباید نادیده گرفته شوند.مرزبندی تستدر این فصل، مارتین به بررسی اهمیت طراحی سیستم‌ها برای آزمایش پذیری می‌پردازد. او توصیه می‌کند که تست‌ها نیز به عنوان بخشی از سیستم در نظر گرفته شوند و باید مرزهای مشخصی داشته باشند. اهمیت جدا کردن تست‌ها از کد تولید برای تقویت سیستم‌ها و افزایش انعطاف‌پذیری کد تولید ذکر می‌شود. به اختصار میتوان گفت:ادغام آزمایش‌ها در طراحی سیستم به معنای جدا کردن آنها از کد تولید و ایجاد یک API آزمایشی قدرتمند است.جدا کردن تست‌ها از کد تولید از مزیت‌هایی نظیر افزایش قدرت تست‌ها و انعطاف‌پذیری کد تولید برخوردار می‌شود.مرزهای مشخصی برای تست‌ها تعیین کردن و رعایت کردن اهمیت دارد.نگهداری و درک سیستم‌ها از تفکیک آزمایش‌ها بهره‌مند می‌شود.با توجه به موارد بالا مارتین به اهمیت و مزایای توجه به طراحی سیستم‌ها برای آزمایش پذیری و نگهداری آنها تأکید می‌کند.معماری تمیز نهفتهدر این فصل، مارتین به اهمیت تعریف صحیح و معماری سیستم‌های نرم‌افزاری و firmware برای توسعه نرم‌افزارها در سیستم‌های جاسازی شده اشاره می‌کند. او تأکید می‌کند که نیاز به جداسازی کد نرم‌افزاری از سخت‌افزار و توسعه نرم‌افزارهایی با معماری مناسب و تعامل قوی با سخت‌افزار داریم.تغییر تعریف سیستم‌افزار: تعریف سنتی سیستم‌افزار (firmware) نادرست است و باید به‌جای آن به کد تعبیه‌ شده نگاه کنیم.توسعه کمتر سیستم‌افزار و بیشتر نرم‌افزار: به جای توسعه سیستم‌افزار، باید بیشتر به توسعه نرم‌افزار تمرکز کنیم و کد نرم‌افزار را به‌گونه‌ای ساختاردهی کنیم که تکامل آن با تغییرات سخت‌افزار آسان باشد.نگهداری کد: برای تمیز نگه داشتن معماری نرم‌افزار تعبیه‌شده، میتوان از تکنیک‌هایی مانند ریفکتور کردن کد، جداسازی نرم‌افزار از سخت‌افزار، و استفاده از API‌ها برای تعامل با سخت‌افزار می‌شود.مارتین به اهمیت تعبیه‌شده نویسی و معماری صحیح در سیستم‌های نهفته تأکید می‌کند تا توسعه و نگهداری نرم‌افزارها را تسهیل کند. Sa_Mirghasemi Sa_Mirghasemi Fri, 20 Oct 2023 19:35:29 +0330 https://virgool.io/@Sa_Mirghasemi/nft-%DA%86%DB%8C%D8%B3%D8%AA-vlwyhpxayyol در حال حاضرNFT ها دنیای هنرهای دیجیتال و آثار کلکسیونی را با طوفان مواجه کرده است. هنرمندان دیجیتالی به لطف فروش هنگفت به مخاطبان بازار جدید کریپتو، شاهد تغییر زندگی خود هستند. و این برای سلبریتی ها فرصت های جدیدی برای ارتباط با طرفداران خود فراهم کرده است. اما هنرهای دیجیتال تنها راه استفاده از NFT ها نیست! از NFT ها میتوان برای نشان دادن مالکیت هر دارایی منحصر به فرد، مانند سندی برای یک کالای خاص، در دنیای دیجیتال یا دنیای حقیقی استفاده کرد.اگر اندی وارهول(نقاش) در اواخر دهه 90 میلادی به دنیا می آمد، احتمالا نقاشی کنسرو سوپ کمبل را به عنوان یک NFT ثبت میکرد. فقط نیاز به گذر زمان بود تا جک دورسی بتواند حق امتیاز اولین توییت تاریخ را در شبکه اتریوم ثبت کند. چه کسی از آینده خبر دارد؟ روزی ممکن است سند و حق مالکیت ماشین شما نیز با NFT ثبت شود!NFT چیست؟NFT ها نشان هایی هستند که برای نشان دادن مالکیت موارد منحصر به فرد، از آن ها استفاده میکنیم. آن ها به ما اجازه میدهند چیز هایی مانند : اشکال هنری، موارد کلکسیونی و حتی املاک و هر چیز سند دار را نشانه گذاری کنیم. این نشان ها در هر زمان تنها میتواند یک مالک حقیقی داشته باشد. و هم چنین توسط شبکه بلاک چین اتریوم ایمن هستند. هیچ کسی نمیتواند سابقه های مالکیت این نشان ها را تغییر دهد و یا حتی یک نشان را کپی-پیست کند.NFT مخفف non-fungible token است. Non-fungible به معنای غیر قابل تعویض، یک اصطلاح در علم اقتصاد است. به این معنا که این کالا ها با کالا های دیگری از لحاظ ارزش گذاری قابل تعویض نیستند! برای مثال شما نمی توانید هر مبلی را با هر مبلی مبادله کنید! بلکه قیمت مبل را به واحد پولی ارزش گذاری میکنید، سپس آن را به اندازه ارزش گذاشته شده مبادله میکنید. NFT ها هم به این شکل هستند.اینترنت دارایی هاNFT ها و شبکه اتریوم برخی از مشکلاتی را که امروزه در اینترنت وجود دارند را حل می کنند. هر چه جلوتر میرود؛ همه چیز دیجیتالی تر می شود. پس نیاز به تکرار ویژگی های اقلام دنیای فیزیکی مانند کمبود کالا، منحصر به فرد بودن کالا و اثبات مالکیت کالا وجود دارد. در ضمن اقلام دیجیتال اغلب فقط در زمینه محصول خود کار می کنند. برای مثال، نمی توانید فایل موسیقی را که از آیتیونز (فروشگاه موسیقی اپل) خریداری کرده اید، دوباره بفروشید. یا نمی توانید امتیاز وفاداری یک شرکت را با اعتبار شرکتی دیگری به صورت رسمی مبادله کنید، هر چند ممکن است بازاری برای آن وجود داشته باشد.اینترنت NFT در مقایسه با اینترنتی که امروزه بیشتر مردم استفاده میکنند چه تفاوتی دارد؟ بیایید با هم مقایسه ای کنیم:مثال هایی از NFTدنیای NFT نسبتاً جدید است. در تئوری،NFT ها در هر چیزی که منحصر به فرد است و نیاز به اثبات مالکیت دارد، قابل استفاده است.چند نمونه از NFT هایی که امروزه وجود دارند، قرار داده شده است:· آثار هنری دیجیتالی منحصر به فرد· یک کفش ورزشی منحصر به فرد محدود که به صورت محدود تولید شده است.· آیتم هایی که در داخل بازی بدست آمده اند.· یک مقاله· مجموعه ای دیجیتالی· بلیطی برای یک رویداد یا یک کوپنمثال هایی از ethereum.org :ما از NFT ها برای بازپرداخت به مشارکت کنندگان در سایت خود استفاده می کنیم و حتی نام دامنه NFT خود را نیز داریم.POAPs (پروتکل اثبات مشارکت):اگر به ethereum.org کمک می کنید، می توانید یک POAP NFT را مطالبه کنید. اینها کلکسیونی هایی هستند که ثابت می کنند شما در یک رویداد شرکت کرده اید. برخی از جلسات کریپتو از POAP ها به عنوان نوعی بلیط استفاده می کنند. درباره مشارکت بیشتر بخوانید.ethereum.eth:این وب سایت (ethereum.org) دارای نام دامنه جایگزین ethereum.eth است که توسط NFT ها پشتیبانی می شود. دامنه .org ما توسط یک ارائه دهنده سیستم نام دامنه (DNS) مدیریت می شود، در حالی که ethereum.eth از طریق سرویس نام اتریوم (ENS) در اتریوم ثبت شده است. و تحت مالکیت و مدیریت ما است. رکورد های ENS ما را ببینید.اطلاعات بیشتر درباره ENSNFT ها چگونه کار می کنند؟NFT ها با نشان هایی با استاندارد ERC-20 مانند DAI یا LINK متفاوت هستند، زیرا هر نشان منحصر به فرد است و قابل تقسیم نیست. NFTها توانایی اختصاص یا ادعای مالکیت هر قطعه منحصربه‌فردی از داده‌های دیجیتال را دارند که با استفاده از زنجیره شبکه اتریوم به عنوان دفتر کل عمومی قابل ردیابی است. یک NFT از اشیا دیجیتال به عنوان نمایشی از دارایی های دیجیتال یا غیر دیجیتال استخراج می شود. به عنوان مثال، یک NFT می تواند نشان دهنده موارد زیر باشد:هنر دیجیتال:· GIF ها· کلکسیونی ها· موسیقی ها· فیلم هاکالاهای دنیای واقعی:· سند یک ماشین یا ملک· بلیط یک رویداد· فاکتورها· اسناد حقوقی· امضاهاهر NFT در هر زمان تنها میتواند یک مالک داشته باشد. مالکیت NFT توسط شناسه یکتا و متادیتایی که هیچ شناسه دیگری نمیتواند آن را تکرار کند، مدیریت میشود. NFT ها از طریق قرارداد های هوشمند در شبکه ثبت میشوند(mint). قرارداد های هوشمند مالکیت و همچنین قابلیت انتقال NFT را مدیریت میکنند. زمانی که یک نفر NFT را ثبت میکند، کد قرارداد هوشمندی که مطابق استاندارد ERC-721 را اجرا میکند. و این اطلاعات به زنجیره شبکه که NFT در آن مدیریت میشود، اضافه میشود. فرآیند ثبت NFT در سطح بالا دارای مراحل زیر است:· ساخته شدن یک بلاک· اعتبار سنجی اطلاعات· ذخیره سازی اطلاعات در زنجیره شبکههر NFT یکسری مشخصات ویژه دارد:· هر NFT که یک شناسه یکتا دارد که به یک آدرس در شبکه اتریوم به صورت مستقیم متصل شده است.· به صورت مستقیم نمیتواند با یک NFT دیگر معاوضه شود.· هر NFT یک مالک دارد و این اطلاعات به راحتی قابل ردگیری است.· NFT ها در شبکه اتریوم همیشه در دسترس هستند (زنده هستند) و میتوانند در هر بازار مبتنی بر شبکه اتریوم خرید و فروش شوند.در واقع اگر شما صاحب یک NFT شوید:· اثبات مالکیت یک NFT شبیه به اثبات وجود ETH در کیف پول است.· برای مثال، فرض کنید شما یک NFT را خریداری کرده اید، و مالکیت آن از طریق آدرس عمومی به کیف پول شما منتقل شده است.o NFT اثبات میکند که کپی فایل دیجیتال شما، اصل است.o کلید خصوصی کیف پول شما اثبات میکند که شما مالک اصلی آن NFT هستید.o کلید عمومی صاحب اثر به عنوان گواهی اصالت آن اثر عمل میکند.§ کلید عمومی صاحب اثر یک بخش دائمی از تاریخچه ی NFT است. به مانند امضای صاحب اثر که اثبات میکند که این NFT توسط فرد خاصی تولید شده است و از تقلب در بازار جلوگیری میکند.o یک راه دیگر برای اثبات مالکیت یک NFT ، امضا کردن پیام هایی است که اثبات میکند شما کلید خصوصی آدرس مورد نظر را دارید!§ همان طور که در بالا ذکر شد، کلید خصوصی اثبات مالکیت اصلی است. پس کلید های خصوصی آدرس NFT را کنترل میکنند.§ حال پیام امضا شده، اثبات میکند شما صاحب کلید های خصوصی آدرس کیف پول تان هستید بدون اینکه آن کلید ها را برای کسی فاش کنید و در نتیجه اثبات میشود شما مالک آن NFT هم هستید.o دیگر کسی نمیتواند در آن NFT دست ببرد.o میتوانید آن NFT را بفروشید. در بعضی از موارد، میتوانید حق امتیاز سازنده اصلی را نیز بدست بیاورید.o میتوانید آن NFT را نگه دارید و مطمئن باشید که در کیف پول شما در اتریوم ایمن است.و اگر یک NFT ایجاد کنید:· شما به راحتی میتوانید اثبات کنید صاحب اثر هستید.· شما کمیابی NFT تان را تعیین می کنید.( مانند بلیط های یک کنسرت با تعداد 5000)· هر بار که آن NFT به فروش برسد، به شما هم به ازای حق امتیازتان، مبلغی میرسد.· شما میتوانید این NFT را در هر پلتفرم که بخواهید بفروشید، و دیگر به یک جا محدود نشده اید و به هیچ فردی برای واسطه گری نیاز ندارید.کمیابیصاحبان اثر هر NFT میتوانند کمیابی دارایی شان را تصمیم بگیرند.برای مثال، بلیط یک مسابقه ورزشی را در نظر بگیرید. همان طور که برنامه ریز این مسابقه تصمیم میگیرد که چند بلیط برای این مسابقه در نظر بگیرد، صاحب اثر NFT نیز میتواند تصمیم بگیرد چه تعداد مشابه از این NFT وجود داشته باشد. بعضی وقت ها NFT های مشابه کاملا شبیه به همدیگر هستند.(مانند بلیط های عمومی مسابقات) یا بعضی وقت ها کمی با یکدیگر تفاوت دارند(مانند بلیط های با شماره صندلی). در موارد دیگر ممکن است صاحب اثر بخواهد تنها یک NFT منحصر به فرد برای کلکسیونی کمیاب ایجاد کند.در هر دوی این موارد، هر NFT همچنان یک شناسه یکتا دارد و مالک آن ها تنها یک نفر است. تنها چیزی که اهمیت دارد، کمیابی NFT مورد نظر است که به صاحب اثر بستگی دارد. حال صاحب اثرمیتواند به هر تعدادی که بخواهد از اثرش NFT ایجاد کند، ولی باید به یاد داشته باشد تمام این اطلاعات در معرض عموم قرار دارد.حق امتیازبرخی از NFT ها به صورت خودکار حق امتیاز را حتی پس از فروش آن NFT پرداخت میکنند. این مفهوم هنوز در حال توسعه است ولی یکی از قوی ترین مفهوم ها است. برای مثال پلتفورم eulerbeats که یکی از بازار های خرید و فروش NFT است، به ازای هر بار فروش NFT، 8 درصد از مبلغ کل را به کیف پول صاحب اثر واریز میکند. برخی از پلتفرم های دیگر مانند Foundation و Zora از حق امتیاز هنرمندان خود حمایت میکنند. این پرداخت مبلغ کاملا خودکار است. بنابراین صاحبان اثر میتوانند بدون انجام هیچ کاری و با دریافت حق امتیاز از فروش NFT هایشان توسط دیگران کسب درآمد کنند. در دنیای واقعی! تشخیص حق امتیاز به صورت غیر خودکار و بی دقت است. به همین علت، بسیاری از صاحبان اثر به حقوق واقعی و چیزی که شایسته آن ها است، دست پیدا نمیکنند. در صورتی که اگر برای NFT تان حق امتیازی قرار داده باشید، دیگر آن حق امتیاز را از دست نخواهید داد و به صورت خودکار به کیف پول شما واریز خواهد شد.از NFT ها چه استفاده ای میشود؟برای دیدن نمونه های عملی توسعه یافته و دیدگاهی که به NFT در شبکه اتریوم وجود دارد به موارد زیر میتوانید مراجعه کنید:· محتوای دیجیتال· اقلام بازی· دامنه ها· اقلام فیزیکی· سرمایه گذاری و وثیقهبه حداکثر درآمد رساندن هنرمنداندر حال حاضر بیشترین استفاده از NFT در زمینه محتوای دیجیتال است. به علت اینکه این صنعت ورشکسته شده است. سازندگان محتوا می بینند که سود و پتانسیل درآمدشان توسط پلتفرم های مختلف تصاحب میشود. هنرمندی که آثار خود را در شبکه های اجتماعی منتشر میکند، برای شرکتی که برای دنبال کنندگان آن هنرمند تبلیغات نشان میدهد، کسب درآمد میکند. هر چند خودش در معرض عموم قرار میگیرد، ولی درآمد نهایی نصیب آن شرکت میشود و فایده ای برای او (هنرمند) ندارد. NFT ها به اقتصاد مولد(creator economy) جدیدی قدرت میبخشند که دیگر مالکیت آثار خود را برای تبلیغ بدست پلتفرم های دیگر نمی سپارد. بلکه مالکیت در خود محتوا نهفته است.زمانی که هنرمندان محتوای خود را میفروشند، سرمایه مستقیم به آدرس کیف پول خودشان واریز میشود. اگر مالک جدید NFT را بفروشد، خالق اثر به صورت خودکار حق امتیاز خود را دریافت میکند. این اتفاق تضمین شده است. زیرا آدرس کیف پول صاحب اثر در متادیتای آن NFT ذخیره شده است و قابل تغییر نیز نیست.مشکل کپی= پیست:برای شما یک داستانی را تعریف میکنم. زمانی که با یکی از افراد مخالف NFT صحبت میکردم، ناگهان وسط صحبت از یک NFT اسکرین شات گرفت و با شور و اشتیاق به من گفت: نگاه کن! الان من این تصویر را به صورت رایگان دارم! جواب من به آن فرد این بود: زمانی که شما نقاشی مونالیزا را در اینترنت جستجو میکنی و تصویرش را دانلود میکنی، آیا صاحب نقاشی 867 میلیون دلاری مونالیزا شدی؟در نهایت قیمت اصلی یک کالا را بازار تعیین میکند. آیا کسی برای آن عکس دانلود شده ارزشی قائل است؟ جواب خیر است! هر چه یک محتوا بیشتر به اشتراک گذاشته شود و دیده شود، ارزش بالاتری پیدا میکند. داشتن یک چیز احراز شده که ثابت میکند شما مالک محتوایی هستید، قطعا از نبود آن بهتر است!افزایش پتانسیل بازی کردن:امروزه NFT ها مورد توجه توسعه دهندگان بازی قرار گرفته اند. NFT ها می توانند سوابق مالکیت آیتم های درون بازی را فراهم کنند، به اقتصاد درون بازی کمک کنند و مزایای فراوانی را برای بازیکنان به ارمغان بیاورند. در بسیاری از بازی می توان آیتم هایی را برای خودتان بخرید تا در بازی از آن ها استفاده کنید. اما اگر آن آیتم NFT بود، پس از اتمام بازی، می توانید با فروش آن پول خود را پس بگیرید. حتی اگر آن آیتم در بین بازیکنان ارزش بالاتری پیدا کند، ممکن است آن آیتم را با قیمت بالاتری بفروشید و سود هم داشته باشید.این اتفاق برای توسعه دهندگان بازی نیز سودآور است! توسعه دهندگان بازی - به عنوان خالقان NFT - می توانند هر بار که یک آیتم توسط بازیکنان در بازار دوباره فروخته می شود، حق امتیازی کسب کنند. این یک مدل تجاری سودمندتر ایجاد می کند که در آن هم بازیکنان و هم توسعه دهندگان بازی نیز از بازار ثانویه NFT کسب درآمد می کنند. همچنین اگر توسعه دهندگان یک بازی دیگر از آن پشتیبانی نکنند، این آیتم ها دیگر از بین نمیرود و در دست خود خریدار باقی می ماند. در نهایت، آیتم های بازی میتوانند از خود بازی ها بیشتر باقی بمانند. یعنی آیتم هایی که خریداری شده است، تبدیل به یادگاری های دیجیتال میشوند و ارزش گذاری آن ها از بازی خارج و در بازار انجام میشود.برای مثال، در بازی واقعیت مجازی Decentraland شما میتوانید با خرید NFT هایی صاحب زمین هایی در بازی شوید که میتوانید از آن ها استفاده کنید.به یادماندنی تر‌ کردن آدرس‌ در اتریوم با NFT :سرویس نام اتریوم (ENS) از NFT استفاده می کند تا آدرس اتریوم شما را با نامی مانند mywallet.eth که میتوان راحت تر به خاطر بسپارید، ارائه کند. یعنی می توانید از شخصی بخواهید که به جای واریز ETH به آدرس x123456789 ، به mywallet.eth برای شما ارسال کند. ENS به مانند سرویس نام دامنه (DNS) عمل می کند که آدرس IP را به یاد ماندنی تر کرده است. و مانند دامنه ها، نام های ENS معمولاً بر اساس طول و ارتباط ارزش دارند. با ENS برای تسهیل انتقال مالکیت نیازی به مرکز ثبت دامنه ندارید. در عوض، می توانید نام های ENS خود را در بازار NFT معامله کنید.با نام ENS شما میتوانید:· ارز های دیجیتال و NFT را در آن نام دریافت کنید.· به وبسایت های غیر متمرکز مانند ethereum.eth اشاره کنید. درباره غیرمتمرکز کردن سایت تان مطالعه کنید.· اطلاعات دلخواه تان مانند، اطلاعات پروفایل( مانند Email و توییتر) را در آن ذخیره کنید.NFT و DeFi :دنیای NFT و دنیای مالی غیرمتمرکز (DeFi) به روش های قابل توجهی شروع به همکاری با یکدیگر کرده اند.وام با پشتوانه :NFTبرنامه های DeFi وجود دارند که به شما امکان می دهند با استفاده از گذاشتن وثیقه پول قرض کنید. برای مثال، شما 10 ETH را به عنوان وثیقه قرار می‌دهید تا بتوانید 5000 DAI (یک رمز ارز با ارزش ثابت) وام بگیرید. این 10 EHT تضمین می کند که وام داده شده حتما به وام دهنده پرداخت میگردد. و اگر وام گیرنده DAI را پس ندهد، وثیقه به وام دهنده ارسال می شود. با این حال، همه افراد دارای رمز ارز کافی برای استفاده برای گذاشتن وثیقه نیستند. پروژه ها شروع به کاوش برای استفاده از NFT به عنوان وثیقه کرده اند. تصور کنید یک روز CryptoPunk NFT کمیاب خریده اید ( ارزش بعضی از آن ها 1000 دلار است!) با قرار دادن آن به عنوان وثیقه، می توانید به وامی با همان قوانین بالا دسترسی پیدا کنید. اگر DAI را بازپرداخت نکنید، CryptoPunk شما به عنوان وثیقه به وام دهنده ارسال می شود. در نهایت می تواند برای هر چیزی که به عنوان NFT ثبت کرده اید، این اتفاق بیافتد. و این برای اتریوم سخت نیست، زیرا هر دو دنیا (NFT و DeFi) زیرساخت های یکسانی دارند.مالکیت اشتراکیسازندگان NFT می توانند برای NFT خود اشتراک ایجاد کنند. این به سرمایه گذاران و طرفداران این فرصت را می دهد که بخشی از یک NFT را بدون نیاز به خرید کل آن داشته باشند. این امر فرصت های بیشتری را برای سازندگان و کلکسیونرهای NFT به طور یکسان افزایش میدهد.o NFT های اشتراکی را می توان علاوه بر بازار های NFT ، در صرافی های غیر متمرکز (DEX) هایی مانند Uniswap ، خرید و فروش کرد.o قیمت کلی یک NFT را می توان با قیمت بخشی از آن تعریف کرد.o شما فرصت بیشتری برای مالکیت و سود بردن از آیتم هایی را دارید که به آنها اهمیت می دهید. قیمت گذاری برای NFT هایی که مالک شان هستید، سخت تر است.مالکیت اشتراکی هنوز آزمایشی است، اما می‌توانید در صرافی‌های زیر درباره مالکیت اشتراکی NFT بیشتر بدانید:o NIFTEXo NFTXبه صورت نظری، مالکیت اشتراکی امکان را برای انجام کارهایی مانند داشتن تکه ای از پیکاسو را فراهم می کند. شما سهامدار NFT پیکاسو خواهید شد، به این معنی که در مواردی مانند تقسیم درآمد، نظراتی دارید. بسیار محتمل است که در آینده نزدیک و برای مدیریت دارایی تان، مالکیت اشتراکی NFT شما را وارد یک سازمان مستقل غیرمتمرکز (DAO) کند. این سازمان ‌ها مبتنی بر شبکه اتریوم هستند که به افراد نا آشنا با یکدیگر (مانند سهامداران جهانی یک دارایی) اجازه می دهند تا به طور ایمن و بدون نیاز به اعتماد کردن افراد به یکدیگر، هماهنگ شوند. این هماهنگی به این علت ایجاد می شود که بدون اجازه گروه، هیچ اتفاقی نخواهد افتاد.همانطور که در بالا اشاره شد، این یک فضای در حال پیشرفت است. با این که NFT ها، DAO ها و NFT های اشتراکی همگی با سرعت های متفاوتی در حال توسعه و پیشرفت هستند. اما تمامی زیرساخت های آنها وجود دارد و می توانند به راحتی با هم کار کنند زیرا همه آنها به زبان اتریوم صحبت می کنند.اتریوم و NFTاتریوم به چند دلیل امکان NFT را میتواند فراهم کند:· تاریخچه تراکنش ها و متادیتا های یک NFT به صورت عمومی قابل دسترسی است.(سوابق مالکیتی آن به راحتی قابل دسترسی است)· پس از تایید یک تراکنش، دستکاری داده ها برای سرقت مالکیت آن تقریبا غیر ممکن است.· معامله NFT ها می‌تواند به صورت یک به یک و بدون نیاز به پلتفرم‌هایی که کارمزد دارند، اتفاق بیفتد.· همه محصولات شبکه اتریوم یک بستر مشترک دارند. در واقع، همه محصولات اتریوم می توانند به راحتی با یکدیگر ارتباط برقرار کنند. و این باعث می شود NFT ها در همه پلتفرم های اتریوم قابل استفاده باشند. شما میتوانید یک NFT را از یک پلتفرم خریداری بکنید و در پلتفرمی دیگر به فروش برسانید. به عنوان یک خالق اثر شما میتوانید یک NFT را در چند پلتفرم به صورت همزمان و با جدید ترین اطلاعات مالکیتی ثبت کنید.· شبکه اتریوم هیچ وقت پایین نمیاید. و این یعنی NFT های شما همیشه در دسترس است.تاثیرات محیطی NFT ها:محبوبیت NFT ها در حال افزایش است. برای همین هر چه میگذرد نظارت بر آن ها بیشتر میشود، به مخصوص بخشی که به مصرف انرژی آن ها مرتبط می شود.برای فهم بیشتر:· NFT ها به صورت مستقیم مصرف انرژی را افزایش نمی دهند.· روشی که شبکه اتریوم دارایی های شما را ایمن نگه می دارد انرژی زیادی مصرف میکند، اما مصرف انرژی در شبکه اتریوم در حال بهبود است.· بعد از بهبودی که در بالا گفته شد، مصرف انرژی شبکه تا 99.95 درصد بهبود پیدا میکند. و این مصرف انرژی از بسیاری از صنایع موجود کارآمد تر است.برای توضیحات بیشتر باید کمی وارد مسائل فنی بشویم. پس همراه ما باشید.NFT ها را مقصر ندانید!شبکه اتریوم یک شبکه غیر متمرکز و امن است. و کل اکوسیستم NFT به همین علت کار میکند.· غیرمتمرکز به این معناست که شما و هر فرد دیگری میتوانید تأیید کنید که مالک چیزی هستید. همه این ها بدون اعتماد کردن یا دادن حضانت (مالکیت) به شخص ثالثی که میتونه قوانین خودش رو به میل خودش تغییر بده اتفاق میفته همچنین به این معناست که NFT شما در بسیاری از پلتفرم ها و بازارهای مختلف قابل استفاده است.· امن به معنای آن است که کسی نمی تواند NFT شما را کپی-پیست کند.این ویژگی ها باعث می شود که به صورت دیجیتالی مالک آیتم ‌های یکتا باشید و برای محتوای خود قیمت منصفانه و مناسب دریافت کنید. اما این ویژگی ها هزینه دارد. شبکه هایی مانند بیت کوین و اتریوم در حال حاضر مصرف کننده انرژی زیادی هستند چون برای حفظ این ویژگی ها نیاز است انرژی زیادی مصرف شود. اگر بازنویسی تاریخچه اتریوم برای سرقت NFT یا ارز دیجیتال آسان بود، شبکه اتریوم به سرعت از بین می رفت.ثبت کردن NFT:زمانی که شما یک NFT را ثبت میکنید، چند اتفاق باید رخ میدهد:· باید به عنوان دارایی در شبکه تایید شود.· موجودی حساب مالک باید آپدیت تا شامل آن NFT شود. این امکان باعث میشود از این به بعد NFT ثبت شده قابلیت احراز مالکیت و فروش داشته باشد.· تراکنش هایی که موارد بالا را تایید میکنند، باید به یک بلوک در زنجیره ی شبکه برای ثبت و جاودانگی اضافه شوند.· همه ی افراد در شبکه باید این بلوک اضافه شده را تایید کنند. این تاییدیه باعث میشود دیگر نیازی نباشد تا از افراد شخص ثالثی برای تایید این موضوع کمک بگیرید. و کل شبکه قبول دارد که این NFT وجود دارد و برای شماست. و هرکسی در شبکه میتواند زنجیره شبکه را بررسی کند و ببیند. با این کار، دست واسط ها از ثبت NFT کوتاه میشود و در آمد شما به حداکثر میرسد.همه ی این اتفاقات توسط ماینرها (استخراج کننده ها) انجام می شود. و به بقیه شبکه درباره NFT شما و این که چه کسی صاحب آن است اطلاع رسانی میکنند. پس باید استخراج به اندازه کافی دشوار باشد وگرنه هرکسی میتواند با فرستادن داده های تقلبی، مالکیت NFT شما را با کلاه برداری به فرد دیگری منتقل کند. انگیزه های زیادی وجود دارد تا مطمئن شویم ماینر هایمان صادقانه عمل میکنند.درباره ماین کردن بیشتر مطالعه کنید.ایمن سازی NFT با ماین کردنسختی ماین کردن به این علت است که برای ایجاد بلوک های جدید در شبکه، به قدرت محاسباتی زیادی نیاز داریم. و نکته مهم آن است که این بلوک ها به طور مداوم ایجاد می شوند، نه فقط زمانی که به این بلوک ها نیاز است. این بلوک ها هر 12 ثانیه یا بیشتر ایجاد می شوند.ماین کردن برای ضد دستکاری اتریوم، مهم است. زیرا یکی از ویژگی هایی که NFT ها را ممکن می کند همین ضد دستکاری است. هر چه تعداد بلوک ها بیشتر باشد، زنجیره شبکه امن‌تر است. برای مثال اگر NFT شما در بلوک شماره 600 ایجاد شده باشد و یک هکر سعی کند NFT شما را با تغییر داده های آن دستکاری کند، اثر انگشت دیجیتالی همه بلوک های بعدی آن تغییر می کند. این بدان معناست که هر کسی که نرم ‌افزار اتریوم را اجرا کند، سریعا می تواند آن را دستکاری را شناسایی و از وقوع آن جلوگیری کند.با توجه به نکات گفته شده، این بدان معنی است که توان محاسباتی باید به طور مداوم استفاده شود. برای مثال بلوکی که حاوی 0 تراکنش NFT است تقریباً همان مصرف انرژی را خواهد داشت، زیرا توان محاسباتی همچنان برای ایجاد آن بلوک مصرف خواهد شد. همچنین سایر تراکنش های غیر NFT نیز بلوک ها را پر می کنند. Sa_Mirghasemi Sa_Mirghasemi Sun, 19 Dec 2021 08:06:35 +0330 https://virgool.io/@Sa_Mirghasemi/%D9%85%D9%82%D8%AF%D9%85%D9%87-%D8%A7%DB%8C-%D8%A8%D8%B1-%DB%8C%DA%A9-%D8%B4%D8%B1%D9%88%D8%B9-zbvbxkkgyh6o بعضی وقت ها آدم دوست داره یسری از دل نوشته هایش رو منتشر کنه. متاسفانه بدلیل شلوغی بیش از حد فضاهایی مانند اینستاگرام و توییتر(هر کدام با محدویت های منحصر به فرد شان!) معمولا حرف آدم ها درست و کامل منتقل نمیشه و امکان اختلاف زیاد هستش. فضای راحت و ساده ویرگول این امکان رو به کسانی میده که معمولا اهل خواندن متن ها با دقت بیشتری هستند. از شما دوستان عزیزی که متن ها را می خوانید خواهشمندم چند نکته را رعایت فرمایید:1- این حرف ها دل نوشته اند و به احتمال زیاد در آن غلط های زیادی یافت می شود. لطفا بر این مبنا بنده را قضاوت نکنید! در ضمن خوشحال می شوم با حفظ حرمت ها با یکدیگر صحبت نماییم تا اگر قصوری از هر طرف هست، برطرف ‌شود. 2- با گذشت چند سال ممکن است تفکرات آدم ها عوض شود. پس لطفا به این عوض شدن افکار احترام بگذارید. و آدم را بابت افکار گذشته و آینده اش ملامت نکنید... Sa_Mirghasemi Sa_Mirghasemi Wed, 04 Sep 2019 01:00:31 +0430