https://virgool.io/feed/@pooyasabeti97 fa 2026-06-16 14:36:07 https://files.virgool.io/upload/users/1340666/avatar/4jyqys.jpg?height=120&width=120 https://virgool.io/@pooyasabeti97 https://virgool.io/@pooyasabeti97/%D9%85%D9%BE-%DA%A9%D8%B1%D8%AF%D9%86-%D8%AF%D8%A7%D8%B3%D8%AA%D8%A7%D9%86-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1user-story-mapping-%DA%86%DB%8C%D8%B3%D8%AA-ihaoinevxxpf آشناییاین نوشته قراره یکی از تکنیک های خیلی هیجان انگیز تو دنیای ساخت نرم‌افزار رو برامون توضیح بده، تشریح کنه و مثال بزنه. از اونجایی که این پست رو میخونید احتمالا به ساختن اپلیکیشن، وب‌سایت و خلاصه برنامه علاقه دارید. قطعا تو مسیر ساختن برنامه به لحظه‌هایی برمی‌خورید که فکرتون پر از ایده شده ولی چون دارید به همه چیز با هم فکر می‌کنید، دیگه نمیدونید کدوم مسیر رو برید و یا اصلا چی شد که به اینجای کار رسیدید.اگه تو این مرحله از تلاش کردن دست نکشیده باشید، و دنبال راه حل بوده باشید حتما به اصول‌ها و روش‌هایی برای مدل کردن نرم‌افزار رسیدین که نه تنها نجات دهنده این شرایطن، بلکه تنها راه حل هم هستن! هرچقدر هم صنعت تولید نرم‌افزار پخته‌تر میشه، سر و کله این مدل‌ها بیشتر پیدا میشه؛ چون تیم‌ها خیلی از روش‌های Agile-که تمرکز اون‌ها تولید نرم افزار به صورت چابک با تقسیم کل پروژه به بخش‌های کوچک‌تره که کلی فایده داره-خوششون اومده و مدل‌سازی‌های کارآمد و تکنیک‌های جدید، خیلی به ابزارهای خوبی برای پیش بردن پروژه به روش Agile هستن تبدیل شده.بانی اصلی این نوشته یک فرد با سِمَت "مشاور طراحی اپلیکیشن" هست، به اسم "Jeff Patton" که یک مدلی ارائه کرد به نام "User Story Mapping" که تو این چند ساله خیلی مورد استفاده تیم های Agile قرار گرفته. این روش بیشتر اوقات برای تبدیل یک ایده به یک برنامه مورد استفاده قرار میگیره ( البته اون ایده میتونه یک ویژگی باشه که قراره به برنامه‌مون اضافه بشه). تو این روش، ما نیازهامونو با عینک یک کاربر می بینیم، و با نمایش دادن اون نیاز به صورت تصویری دید خوبی از کلیات پیاده سازی برنامه می‌گیریم؛ تصور کنید ما هر نیازی که کاربر داره رو نوشتیم و برنامه‌مون هم همه اون رو برآورده می‌کنه، خب پس عملا کار تموم شده دیگه، نه؟ قبول دارم که یه برنامه‌نویس با تجربه میگه نه، ولی قطعا تایید می‌کنه که به همین مرحله رسیدن تو یه برنامه و برآورده کردن نیازهای کاربر، خودش یکی از بزرگترین موانع کاره.اصول User Story Mappingبرای به دست آوردن و تصویر سازی نیازهای کاربر، به روش آقای Patton ما باید چندتا اصطلاح رو بلد باشیم. ولی قبل از اون یه تعریف کلی از این مدل می‌کنیم: مدل مپ کردن داستان کاربر مدلیه که با استفاده از جدا کردن نیازهای هر کاربر استفاده کننده از برنامه، طبق نظر تیم، میتونه تمامی نیازهای کاربر رو پوشش بده. در نمایش این نقشه، از قوانین، اصول و اصطلاحاتی استفاده می‌شه. نمایش نهایی، جدولیه که از چب به راست، ترتیب حدودی انجام فعالیت‌ها و از بالا به پایین، اهمیت ویژگی(Feature که جلو تر همون فیچر می‌نویسم) مد نظر را نشان می‌دهد.در این روش تصور میکنیم کاربر تو هر قسمت از برنامه چه چیزهایی از ما (مایی که طراحیم) میخواد و با جدا جدا نوشتن اون‌ها می‌تونیم منظم‌تر و هماهنگ تر کار کنیم. در کنار این مورد، این روش و نمایش اون خیلی قابل فهمه که میشه با همه به اشتراک گذاشته بشه و از پیشنهادات افراد مختلف تیم استفاده بشه؛ در حالی که میدونیم بسیاری از مدل سازی‌های نرم افزار نیاز به اطلاعات فنی بیشتری دارند.نمونه‌ای از حال و هوای User Story Mappingبا این تعاریف، اگه بخوایم این روش رو یاد بگیریم اول باید با هم از یک ادبیات استفاده کنیم که این‌ها رو در ادامه مشخص می‌کنیم:پرسونا (Persona) : معمولا هر نرم افزار از چند نوع کاربر تشکیل میشه که این کاربرها قطعا نیازشون از برنامه متفاوته؛ مثلا در یک سیستم دانشگاهی، استاد، دانشجو، مدیریت و مسئول آی‌تی با این که همه دارن از یه برنامه استفاده میکنن، انتظارشون از اون برنامه مثل هم نیست. مسئول آی تی باید دسترسی هایی داشته باشه که بتونه اتفاقات پشت سیستم رو ببینه یا در سیستم برای افراد، استثنا قائل بشه(که معمولا مقاومت می‌کنه)، در صورتی که دانشجو، انتظار داره بتونه واحدی که میخواد رو اخذ کنه. این مثال نشون میده که انتظارات پرسوناها از سیستم یکسان نیست پس ما هم باید آن‌ها رو از هم جدا در نظر بگیریم.فعالیت‌‌های درشت دانه(High Level Activities): در اکثر برنامه‌هایی که استفاده میکنیم، هر کنش و ورودی ما یک فعالیت حساب میشه، که خب میتونیم این فعالیت‌ها رو با یک ذره‌بین ضعیف‌تر نگاه کنیم و گروه بندی‌شون کنیم به فعالیت‌هایی کلی‌تر. به عنوان مثال، تو نرم‌افزار اسنپ، فعالیت اسنپ گرفتن از فعالیت‌های کوچکتری مثل وارد کردن آدرس مبدا، آدرس مقصد، نوع اسنپ، گزینه‌های سفر و غیره تشکیل شده که اگر ما بخوایم این رو از بالاتر(با همون ذره‌بین ضعیف‌تره) نگاه کنیم، به کل این فعالیت ها میگیم درخواست اسنپ(منظور درخواست برای رانندس). پس برای پیاده سازی این مدل، لازم داریم فعالیت‌های درشت‌دانه برنامه رو بشناسیم و آن‌ها رو مشخص کنیم.محور اصلی (Backbone): در بالای این مدل، فعالیت‌های درشت‌دانه به عنوان ستون‌ها قرار می‌گیرن که محور اصلی رو تشکیل میدن. اما همونطور که پیش‌تر گفته شد، این فعالیت‌ها به یک محور اصلی تبدیل میشن؛ که از چپ به راست ترتیب فعالیت‌های درشت‌دانه‌ کاربر رو مشخص می‌کنن. مثلا در بسیاری از برنامه‌ها نیاز ثبت نام و ورود به برنامه با حساب کاربری داریم که این‌‌ها فعالیت‌های ابتدایی کار کاربر هستند و در نتیجه در ابتدای محور(سمت چپ) قرار میگیرند.اپیک(Epic): به هر نیاز کاربر که سطح پایینی داره(نیازی که دقیقا و کامل بیان شده)، و این در نقشه ما به صورت یک جمله از زبان کاربر نوشته می‌شه، یک اپیک (Epic) گفته میشه. این واژه در انگلیسی معنی‌های مختلفی داره ولی این‌جا خودمون رو درگیر معانی دیگر و دلیل استفاده از این کلمه برای این مفهوم نمی کنیم و فقط به تعریفی که برای این مدل ارائه شده بسنده می‌کنیم. نکته ای که در ادامه به اون میرسیم اینه که ما داخل جدول‌مون(مپ، نقشه یا هرچی که تا الان بهش گفتم)، کار اصلی‌ای که باید انجام بدیم نوشتن اپیک‌‌های درست در محل درسته که درواقع نیاز کاربر رو برای ما توصیف کنه. به طور اصولی اپیک‌ها از سه بخش تشکیل شدن که برای نوشتن درست اون‌ها باید این سه بخش رعایت بشن:محتوای معمول یک اپیکمشخص کردن پرسونا - "من به عنوان مدیر برنامه ..."، "من به عنوان دانشجو ..."، "من به عنوان کارمند ..." و غیره. این جملات مشخص میکنه که اپیک نوشته شده بر اساس نیاز کدام نوع کاربر (پرسونا) مطرح شدهمشخص کردن کار (Action) - "... میخواهم بتوانم در قسمت اسامی جستجو کنم ..." ، "...میخواهم افراد طرح را مشاهده کنم ..." ، "...میخواهم بتوانم از حساب کاربری خود خارج شوم...". این جملات در واقع نیاز فرد رو در دسته بندی (همون فعالیت‌های درشت دانه) مورد نظر مشخص می‌کنن.پاداش ( Reward) - "...که بتوانم دسترسی سریع‌تری به اسامی افراد مورد نظرم داشته باشم."، "...بخاطر افزایش امنیت اطلاعاتی خودم."، "...زیرا در غیر این صورت استفاده از این بخش دشوار است.". این پاداش‌ها نیز در اپیک ذکر میشن که به تیم طراحی دلیل خوبی برای قرار دادن چنین ویژگی‌ای در برنامه را بِدن(بعضی وقت‌ها ممکنه ما اپیک‌ها رو در روند طراحی برنامه تغییر بدیم و یا جایگزین کنیم و مطرح کردن دلیل ممکنه بهمون یادآوری کنه که این نیاز در قسمتی دیگر به کاربر داده می‌شود و دیگر نیازی به این اپیک نیست).اگه بخوایم یک مثال از یک اپیک کامل داشته باشیم، میتونه چنین گزاره‌ای باشه: "من به عنوان دانشجو در قسمت انتخاب واحد میخواهم بتوانم درس هایی که برای من قابل اخذ نیست را مشاهده نکنم که بتوانم دید بهتری نسبت به درس‌های قابل اخذ داشته باشم."توجه داشته باشیم که بنا به تشخیص خود و تیم می‌توانیم جهت مدیریت بهتر برخی موارد را کامل ننویسیم. مثل شکل :در این مدل برای خوانایی بیشتر، پرسونا با رنگ مشخص شده و المان های جستجو هرکدام به عنوان یک اپیک آورده شده .چگونه User Story Mapping را پیاده سازی کنیم؟در ابتدا باید چارچوب این نقشه فراهم بشه که در نتیجه مواردی مثل پرسوناها و محور اصلی مشخص بشه. برای تعیین کردن پرسونا، بر اساس نیازهای کاربر (یا تحقیقات انجام شده)، تصمیم گیری تیم فنی مورد نیازه که بشه تمامی دیدهای مختلف نسبت به برنامه را استخراج کرد. برای محور اصلی باید فعالیت های درشت‌دانه تعیین شه. دسته بندی درست آن‌ها به میزان قابل توجه به سادگی و اصولی بودن کار کمک خواهد کرد. میشه جلسات متعددی برای این دسته‌بندی‌ها تشکیل داد و یا حتی از مدل‌ها و تکنیک‌های دیگر دنیای Agile استفاده کرد.پس از تعیین شدن پرسوناها و محور اصلی نقشه، طبق انتظار، باید شروع به نوشتن اپیک‌ها کنیم. گفتیم که اپیک‌ها برای هر پرسونا باید جداگانه نوشته بشه، و پیشنهاد میشه که در ابتدا از پرسونایی استفاده کنیم که بیشترین تاثیر رو از برنامه میگیره و جامعه بیشتری از برنامه رو تشکیل میده(بهش میگن chunk بزرگ تر)؛ مثل دانشجویان در یک سیستم دانشگاهی و یا مسافران در اپلیکیشن‌هایی مانند اسنپ و تپسیالبته لازمه که در تمامی مراحل به این نکته دقت کنیم که رعایت کردن چنین اصولی همیشه اجباری نیست و با تشخیص افراد تیم میشه تغییراتی در اون اعمال کرد، همونطور که در ابتدا گفته شد، این تکنیک توسط یک مشاور طراحی اپلیکیشن مطرح شده و به سپس نظر بسیاری رو به خودش جلب کرده. پس هیچوقت نمیتوان به قطع گفت که چنین اصولی همیشه بهترین نتیجه رو میده؛ همونطور که آقای Jeff Patton اصول جدیدی رو برای طراحی نرم‌افزار خلق کرده. لازم به ذکره که قبل از این مدل، مدل‌های مشابهی بودن که قصدشون برطرف کردن چنین نیازی بوده و نقص‌هایی نیز داشتن، همونطور که این مدل نقص‌های خودش رو داره.( برای افرادی که میخوان بیشتر بدونن میتونن کلید واژه "Flat Backlog" رو جستجو کنن).نوشتن اپیک‌هادر جدولی که تا به این مرحله ایجاد کردیم، محور اصلی تعیین شده و پرسونایی که میخوایم نیازهای اون رو در هر فعالیت بنویسیم نیز مشخص شده. برای نوشتن اپیک‌ها بهتره در جلسه‌ای با حضور بسیاری از افراد کلیدی تیم(مانند جلساتی که برای پرسونا ها و محور اصلی تشکیل شده) و با هم‌نظری آن‌ها فرایند رو پیش ببریم. و جلسه ای/هایی رو با محوریت این موضوع تشکیل بدیم.در اون جلسه یک مسئول و پیش برنده جلسه حضور داره که ترجیحا بهتره مسئول جلسه و تصمیم گیرنده نهایی فردی باشه که در این پروسه تخصص بیشتری دارد، مثل: Product Owner، Product manager یا به طور کل کسی که با کارفرما بیشتر در ارتباطه و با چنین اصولی آشنایی بیشتری داره. دیگر افراد این جلسه می‌توانند افرادی از جمله : Business Owner - Developers - Testers - UI/UX Designers - Scrum Master - Marketers باشند. این افراد ممکن است متغیر باشند و تاکیدی بر وجود همگی نیست.باید توجه داشت که در این جلسات بیش از 10نفر(حالا برخی جاها میگن 10 نفر، من میگم حتی خیلی کمتر اگه پروژه خیلی مقیاس بالایی نداره) همزمان حضور نداشته باشن؛ چون با این که دیدهای متفاوت استحکام تصمیم‌گیری رو بیشتر می‌کنه، بیش از حد بودن نظرات، ممکنه جلسه رو کند و یا تکمیل نقشه را غیرممکن کنه. تکمیل این نقشه با این اصول، بسته به پروژه، ممکنه یک یا چند هفته طول بکشه. تمرکز بالای افراد در این جلسات امری حیاتیه؛ زیرا که هر ایده‌ای که به صورت استیکر بر روی نقشه چسبانده شده و تایید می‌شود سنگ بنایی برای تمامی پروژه است و مسیری را تعیین می‌کند. خیلی اوقات قوانین سختی برای افزایش تمرکز افراد این جلسه در نظر گرفته میشه، مثلا مسئول جلسه گوشی‌های همراه شرکت کننده‌ها رو در سبدی قرار میده که تو جلسه بهش دسترسی نداشته باشن و تمرکزی رو بهم نزنه.پس از نوشتن اپیک‌ها و داستان‌های کاربرها و رسیدن به مرحله‌ای که کلیت کار مشخص شده، برای دادن دید بهتر به تیم و کارفرما، در هر ستون، اپیک ها رو به ترتیب اهمیت، از بالا به پایین قرار می‌دیم. این ترتیب نمایش‌ دادن، نیازهای بنیادی اپلیکیشن را بالاتر و فیچرهای غیر ضروری را پایین تر نشان میده؛ این کار خودش می‌تونه مسیری برای راحت‌تر و واضح‌تر کردنِ ساخت و توسعه برنامه باشه.تا این قسمت نوشته یاد گرفتیم که این تکنیک چیه و چطوری از اون برای پیش‌برد ایده‌مان استفاده کنیم. در ادامه یک مثال رو از اول تا آخر پیش میریم که ببینیم به چه ابهاماتی توی حل این مثال برمیخوریم و چطور حلشون می‌کنیم. اما قبل از اون، لازم به ذکره که هر مدلی جزئیات و ریزه‌کاری‌های خودش رو جدا از روند کلی ساختن اون داره و قطعا ما تو این نوشته تمومش رو پوشش ندادیم. ولی از اونجایی که من و شما دوست داریم که درباره چیزهایی که در موردشون کنجکاویم بیشتر بدونیم، قبل ارائه مثال، چند مورد رو به صورت تیتر‌گونه مطرح می‌کنم که اگه علاقه داشتید برید و در موردش بیشتر و با کیفیت بهتر بخونید:قسمت های Swim lanes و یا Slice هاچگونه MVP اپلیکیشن از این نقشه به دست میادقرار دادن چند پرسونا همزمان در این مدلمدیریت چند جریان کاربر به صورت همزمانتکنیک‌های Continuous Refinement برای این مدلروش Story Splittingو ...و اما مثال!تعریف پروژه ( این در واقع صورت مسئله هست که برای این مثال داریم تولیدش می‌کنیم وگرنه اکثرا این رو از قبل داریم): فرض می‌کنیم یک کارفرمای زرنگ و بازی‌دوست با سرمایه خوبی که داره اومده از ما درخواست ساخت یک پلتفرم بازی رو کرده(ما هم یه تیمیم که از افراد متخصص تو حوزه‌های مختلف تشکیل شدیم). به گفته خودش، چند بازی رو تیم خودش ساخته و قصد این رو داره که بازی‌های تیمش رو به علاوه بازی‌های موجود در بازار رو تا جای ممکن به بازیکنان از طریق این پلتفرم ارائه بده و عرضه کنه. به طوری که هر کاربر برای بازی کردن، وارد این پلتفرم بشه و بازی مورد نظرش رو خریداری کنه و تحت کاربری خود بازی کنه.خودش ادعا می‌کنه که تعداد بازی ها نسبتا بالاست و انتظار میره کاربران هم تعدادشون کم نباشه(فرض کنید مشابه پلتفرم Steam که توسط بزرگ‌مردی به اسم Gabe Newell ساخته شده). کارفرما قطعا لازمه که اطلاعات بسیار بیشتری در اختیار ما قرار بده، ولی نمی‌خوایم تو این مثال خودمون رو با جزئیات خسته کنیم و از جزئیات بیشتر رد میشیم(ولی بدانید و آگاه باشید که اگه مشتری نیازشو دقیق نگه و یا ما مجبورش نکنیم که این کارو بکنه اصلا نمیشه چنین مدلی رو پیاده سازی کرد).شروع مدلسازی این پروژه با "نقشه‌سازی از داستان کاربر"انتخاب پرسونا: در این قسمت پرسونایی که در ابتدا،جدول برای اون پیش میره، بازیکن انتخاب میشه چون اکثریت کاربران این سیستم بازکنان اون هستن.به دست آوردن فعالیت‌های درشت دانه (High Level Activities): این قسمت همان سطر افقی جدول رو تشکیل میده که روند طی شدن تجربه کاربر رو منتقل می‌کنه. با کمک تیم و متخصصین، طی جلسات متعدد، عناوین را برای این قسمت به دست میاریم که در واقع با تکمیل اون محور اصلی جدول را تشکیل دادیم که شروع کار در چپ و کارهای پایانی در راست آن قرار داره. در نهایت با کمک تیم به چنین ساختاری رسیدیم. دقت کنیم که این ساختار میتونه متفاوت باشه(خب طبق نظرات تیمه و نظرات متفاوتن) ولی باید تمامی قسمت‌های پروژه مورد نظر رو در بر بگیره.Create an account / Log in -> Browse games -> Buy games -> Download and install games -> Play games - > Review and rate games -> Interact with community----------------------------------------------------------------------------------------------------------------------------------------------->با فرض این که این عناوین همگی در یک خط قرار دارن با کشیدن فلش زیر آن عملا محور اصلی تعیین میشه(راستش این فلش خیلی تو این مدل طرف‌دار داره چون یجورایی به جز جداسازی فعالیت‌ها مسیر کاربر رو نشون میده و حتی در کنار اون داره میگه دیگه تمام و ما ترجیحا بعد این که اپیک رو شروع کردیم دست به این فعالیت‌هایی که نوشتیم نمزنیم!). نوشتن اپیک‌ها برای یکی از فعالیت‌ها، که در این قسمت، فعالیت Buy games رو انتخاب کردیم شروع به نوشتن اپیک‌های اون میکنیم. این اپیک‌ها هر کدوم با استیکرهایی از طرف تیم حاضر در جلسه مشخص میشن که به تایید میرسن و به جدول اضافه میشن. در ادامه هم مسئول جلسه به همراه تیم سعی می‌کنه ترتیب اولویت این‌ها رو رعایت کنه. که اپیک‌های ما که زیر Buy games نوشته شده به این شکل میشه در نهایت: 1- Browse Games:Browse games by genreBrowse games by popularity/rating2- Search for Games:Use the search bar to find a specific gameUse filters to narrow down search results3- Game Selection:Click on a game for more detailsWatch trailers or previews of the gameReview user ratings and comments4- Purchase Process:Select the desired version or edition of the game (Standard, Deluxe, etc.)Add game to shopping cartReview shopping cartSelect payment method (credit card, PayPal, etc.)Enter payment detailsConfirm purchase5- Post-Purchase:Receive confirmation email or notificationReview purchase in purchase historyRequest support if there are any issues with the purchaseاین اپیک‌ها توسط تیم، در جلسات متعدد به دست اومده، که شرح دهنده اینه که از طرف پرسونای بازیکن چه نیازهایی در قسمت خرید بازی در این نرم‌افزار وجود داره. باید دقت کنیم که تا جای ممکن نیازهای غیر ضروری پایین تر و نیازهای پایه ای و اسای بالاتر قرار بگیرند. و نکته دیگه که تو مثال به ما نشون داده میشه اینه که این اپیک‌ها خودشون عضو یک دسته هستن، که خب عملا اومدیم فعالیت درشت دانه رو یه درجه ریزتر کردیم بعد برای این فعالیت جدیدها اپیک نوشته(هر ایده‌ای که به کار کمک کنه باید استفاده بشه). این دسته بندی کردن نوشتن اپیک‌ها اهمیت بالایی داره زیرا که دید افراد درون جلسه رو متمرکز تر می‌کنه و البته کنترل مپ رو راحت تر می‌کنه.تکمیل مدل با تکرار مرحله نوشتن اپیک اتفاق می‌افته که برای هر فعالیت کاربر اپیک‌های متعددی نوشته شده و با زیاد شدن اپیک‌ها، رده بندی آن‌ها بیشتر معنی پیدا می‌کنه. در طول پروسه پیشرفت نرم‌افزار ممکنه تغییراتی در نقشه تکمیل شده اتفاق بیفته و اصلاحاتی بر اساس شرایط جدید به مدل اعمال بشه. و لازمه که مکررا به این مدل رجوع شود( در موارد "اختیاری برای مطالعه" به این مورد اشاره شده که رجوع مجدد و بهتر کردن مدل چطور اتفاق میفته).مروری بر نوشتهدر این نوشته سعی شد بتونیم روش به‌وجود آوردن تکنیک مپ کردن داستان کاربر(User Story Mapping) رو توضیح بدیم و اجزاء و روش پیاده سازی اون رو قدم به قدم بگیم. سر نخ‌هایی جهت مطالعه بیشتر و قطعا مطالعه بر روی مدل‌های مورد پسند پروژه‌ها و تیم‌های Agile داده شد. و در نهایت نیز مثالی برای رفع ابهامات تا جای ممکن رو مطرح کردیم. این نوشته جهت آشنایی با این تکنیکه و قطعا برای پیش بردن یک پروژه این یکی از چندین مدل و تکنیکیه که به کار گرفته میشه. و لزوما در همه پروژه‌ها مجبور مجبور نیستیم از این تکنیک استفاده کنیم. پیشنهاد میشه برای پروژه‌هاتون اگر مدلی کارآمد بود یادش بگیرید ولی مدل‌های مشابه اون رو هم جستجو کنید. چون کارآمد بودن یه مدل agile نشون میده پروژه‌هایی که کار می‌کنید از چه جنسیه و اگه پروژه‌هاتون نسبتا شبیهن و صرفا مشتری‌هاتون سلیقه‌هاشون متفاوته، قطعا یاد گرفتن مدل‌های مشابه خیلی به کارتون میاد.هدف شخصی بر این بود که این متن شاید دید و ایده‌ای جدید برای افراد کنجکاو باشه، که البته خودش هم صرفا از دید یک فرد کنجکاو دیگه بازگو و منتقل شده. ممنونم که وقت گذاشتید و حوصله کردید. 3>کنجکاو بمونید :) Pooya Sabeti Pooya Sabeti Fri, 04 Aug 2023 15:32:31 +0330 https://virgool.io/@pooyasabeti97/%D9%85%D8%B7%D8%A7%D9%84%D8%B9%D9%87-%D8%A8%D8%B1%D8%B1%D9%88%DB%8C-%D8%B4%D8%A8%DA%A9%D9%87-%D9%87%D8%A7%DB%8C-%D8%A8%D9%84%D8%A7%DA%A9%DA%86%DB%8C%D9%86-%D8%A8%D8%A7-%D8%B1%D9%88%DB%8C%DA%A9%D8%B1%D8%AF%D9%87%D8%A7%DB%8C-%D8%B4%D8%A8%DA%A9%D9%87-%D9%87%D8%A7%DB%8C-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%D9%87-j1gzxvey3nmp پویا ثابتی - سپهر اویسیچکیدهامروزه رمز ارزها و بستر بلاک‌چین از تکنولوژی‌هایی هستند که ایده‌های جدیدی در صنعت و علم به وسیله‌ی آن‌ها قابل توسعه شده است. این بستر که ساختار شبکه غیر متمرکز دارد مورد توجه بسیاری از محققان و شرکت‌ها قرار گرفته و تحقیقات بسیاری برای پیشرفت در این حوزه نوظهور هر روزه در حال انجام است. این علم را می‌توان از منظرها و دیدهای مختلفی مورد بررسی قرار داد، یکی از آن‌ها با رویکرد شبکه‌های پیچیده می‌باشد. به این معنی که بستر بلاکچین را با میزان شبکه‌های پیچیده بسنجیم و با معیارهایی که از ابزارهای علم شبکه‌های پیچیده می‌باشد، بلاکچین را مورد ارزیابی قرار دهیم. در این مقاله قصد داریم شبکه تراکنش‌های دو رمزارز شناخته شده بر بستر بلاکچین، بیت‌کوین و اتریوم را از این رویکرد مورد مطالعه و بررسی قرار دهیم.مقدماتی بر شبکه بلاکچینبلاکچین یک شبکه غیر متمرکز تشکیل شده از بلاک‌ها می‌باشد که هر یک از آن‌ها به صورت جداگانه رکوردهای تراکنش‌های درون شبکه را در خود نگهداری می‌کنند. این شبکه به طور خودکار توسط ارتباطات یک به یک اداره می‌شود. در ادامه تراکنش‌ها هش شده و کدگذاری می‌شوند و در یک درخت ذخیره می‌شوند. با توجه به تکنولوژی‌های به کار رفته شده و کدگذاری‌های استفاده شده در بلاکچین، تضمین می‌شود که اطلاعات به صورت بازگشتی قابل دستیابی نخواهند بود. در نتیجه بلاکچین می‌تواند این قابلیت را بدون وجود یک هسته مرکزی به اجرا در بیاورد و به عنوان یک تکنولوژی قابل اعتماد کار خود را ادادمه داده است.بلاکچین یک حوزه بین رشته ای است که شامل اقتصاد، سیستم عامل، ارتباطات شبکه، رمزنگاری ریاضی و غیره است. انبوهی از کارها در مورد بررسی بلاکچین وجود دارد. با این حال، بیشتر آثار بر طبقه بندی با توجه به زمینه های خاص تمرکز دارند. مشکل تحلیل سیستماتیک روی آن، تا همین اواخر، تا حد زیادی نادیده گرفته شده است. یکی از حوزه‌هایی که بسیار به بلاکچین مربوط می‌شود و اما در عین حال در بررسی بلاکچین تا حدودی نادیده گرفته شده است، علم شبکه‌های پیچیده می‌باشد که در این مقاله به بررسی آن‌ها می‌پردازیم.مقدماتی بر شبکه‌های پیچیدهیک شبکه پیچیده گرافی است متشکل از مجموعه ای از تعدادی گره و مجموعه ای از تعدادی یال که مجموعه یال‌ها نشاندهنده اتصال میان گره‌ها می‌باشند. در ادامه این گراف ویژگی های آماری خاص به جز ویژگی های رایج گراف‌های عمومی نیز دارد ؛که شامل درجه گره‌ها ، مقیاس آزاد بودن، میزان خوشه‌بندی و غیره می شود. بطور کلی، شبکه پیچیده از گره‌های فراوانی تشکیل شده است که با توجه به روابط مختلف بین آنها با یال‌ها به هم متصل می شوند. به طور معمول، شبکه های پیچیده مانند شبکه فیس بوک، شامل ویژگی دنیای کوچک که از توزیع درجه قانون Power Law پیروی کرده و همچنین معمولا دارای ضریب خوشه‌بندی بالایی هستند.توزیع درجه در شبکه پیچیدهدرجه یک گره در شبکه پیچیده نشان دهنده تعداد گره هایی است که به آن متصل شده اند. توزیع درجه یک مفهوم اساسی در این حوزه می‌باشد که تعداد همسایگان را برای یک گره خاص نشان می‌دهد.که به طور کلی، این یک معیار برای ارزیابی ارتباط هر گره با گره های دیگر است. یعنی هر چه درجه بزرگتر باشد، گره بیشتر با دیگران ارتباط برقرار می کند. این معیار تا حدودی اهمیت گره را نشان می دهد، اما گاهی اوقات معیارهای دیگری مانند معیارهای مرکزیت برای دقت بیشتر اهمیت اتصال وجود دارد.عبارت توزیع درجه در شبکه‌های پیچیده به معنی توزیع درجه هر یک از گره‌ها در آن شبکه پیچیده می‌باشد. به طور معمول، می توان آن را به صورت di = Σj eij ارائه کرد، که در آن ∈ N nj ni، در یک شبکه وزن دار، eij وزن یک یال را نشان می دهد. در بیشتر شبکه های پیچیده، توزیع درجه به صورت قانون power-law است. این نوع توزیع ویژگی مشخصی دارد. یعنی تعداد کمی از گره ها دارای درجه بالایی هستند در حالی که بیشتر گره ها در شبکه پیچیده دارای درجه کمی هستند. در دنیای واقعی، می توان اینگونه توضیح داد: افراد ثروتمند ثروتمندتر می شوند در حالی که فقیرها فقیرتر می شوند.تابع میزان ماژولار بودن یک شبکهیکی دیگر از ویژگی های برجسته شبکه پیچیده، ساختار انجمن‌ها است که شبکه پیچیده را به چندین جامعه کوچک تقسیم می کند. یعنی گراف بزرگ با توجه به ویژگی های مختلف به زیرگراف های کوچک تقسیم می شود. تابع Q معیاری برای ارزیابی ماژولار بودن شبکه پیچیده است، که یک روش رایج برای اندازه گیری میزان پایداری انجمن است. مقدار Q زمانی به حداکثر می رسد که انجمن در بهینه‌ترین حالت باشد. رمزارز و شبکه بیتکوینبیت کوین از زمان پیدایش در سال 2009 توسط ساتوشی ناکاموتو به عنوان یکی از معرف ترین ارزهای رمزنگاری شده پذیرفته شده است. بیت کوین به دلیل ویژگی‌های نوآورانه‌اش مانند ناشناس بودن، کارمزد تراکنش‌های پایین، رسمی‌سازی و دسترسی به خدمات بدون توقف، توجه گسترده‌ای را در چند سال گذشته به خود جلب کرده است. با این حال، مطالعات کمی در مورد تجزیه و تحلیل شبکه بیت کوین وجود دارد. تجزیه و تحلیل بلاک چین بیت کوین از منظر شبکه پیچیده بسیار مهم است زیرا می تواند معماهای سیستم های بلاک چین فعلی را باز کند. چندین تلاش در این زمینه وجود دارد. برخی مراجع در ابتدا شبکه تراکنش بیت کوین را با تجزیه و تحلیل گراف اولیه بررسی می کنند در حالی که مقاله‌ای تجزیه و تحلیل مبتنی بر شبکه طولی سیستم های بیت کوین را ارائه می دهد. مطالعه‌ای دیگر ساختار شبکه تراکنش را با اندازه‌گیری ویژگی‌های شبکه، از جمله توزیع درجه، همبستگی درجه، و خوشه‌بندی تحلیل می‌کند. با این وجود، تحقیقات در مورد شبکه تراکنش بیت کوین هنوز بسیار محدود است. تحقیقات شبکه بیت کوین موجود در درجه اول بر تجزیه و تحلیل داده های در مقیاس بزرگ و بلندمدت کل شبکه یا تشخیص الگوی تراکنش متمرکز است، اما فاقد کاوش عمیق در مورد ویژگی های شبکه و محاسباتی است. تجزیه و تحلیل شبکه برای مثال، ویژگی‌های شبکه تراکنش بیت‌کوین مانند دسته‌بندی، تمایل به اتصال و مرکزیت باید با یک روش تحلیل شبکه کارآمد محاسباتی بررسی شود. برای این منظور، در ادامه یک تجزیه و تحلیل چند بعدی از شبکه تراکنش بیت کوین را از دیدگاه های مختلف انجام می دهیم، از جمله توزیع درجه، تعیین دنیای کوچک، مؤلفه متصل، مرکزیت، تجزیه و تحلیل طبقه بندی.نحوه ساخت شبکه بیت کوینهنگامی که کاربران بیت کوین (BTC) را از یک آدرس به آدرس دیگر انتقال می دهند، تراکنش ها انجام می شود. در بیت کوین، یک تراکنش ممکن است چندین آدرس ورودی و چندین آدرس خروجی داشته باشد. ما یک تراکنش را استخراج می‌کنیم که ورودی‌هایی از آدرس‌های x و خروجی‌ها به آدرس‌های y دارد، در نتیجه با یال‌های x به y نشان داده می‌شود. پس از آن، هر گره نشان دهنده یک آدرس بیت کوین است، هر یال جهت دار نشان دهنده جریان تراکنش از مبدا به مقصد است، و وزن یال متناسب با ارزش تراکنش است. مثالی را در نظر بگیرید که در آن تراکنش دارای دو ورودی A و B است که به ترتیب 2 و 8 بیت کوین پرداخت می کنند و سه خروجی C، D, E به ترتیب 2، 3 و 4 بیت کوین دریافت می کنند (توجه کنید که مجموع ورودی و خروجی ها به علت وجود کارمزد شبکه بیت کوین با هم برابر نیست). بنابراین، وزن لبه از A به D برابر با 0.6 می باشد.در نتیجه یک شبکه تراکنش بیت کوین را به یک گراف جهت دار وزن دار تبدیل می کنیم که با G = (V، E، W) نشان داده می شود، که در آن V مجموعه ای از گره ها، E مجموعه ای از یال ها و W مجموعه ای از وزن ها است. هر یال به صورت eij = (i, j, wij ) نمایش داده می شود که i نشان دهنده گره ورودی، j نشان دهنده گره خروجی و wij نشان دهنده مقدار وزن است. مجموعه E با N گره را می توان با یک ماتریس N×N نشان داد که در اصل یک ماتریس مجاورت است. به این صورت که اگر بین دو گره تراکنشی با وزن wij برقرار بود در آن ماتریس مولفه i,j را برابر با wij قرار می‌دهیم و در صورت نبودن یال آن را صفر می‌گذاریم. در مقاله BTC3 از داده های سال 2017 تا 2018 استفاده شده که در این بازه گراف تشکیل داده شده حدودا برابر با 147 میلیون گره 871 میلیون یال دارد. در شکل 1 نمایشی از 10،000 گره انتخابی از این گراف نشان داده می‌شود. شکل 1 نمونه ده هزار تایی از گراف شبکه بیت کوینبه علت بزرگ بودن گراف شبکه بیت کوین باید از آن نمونه ای مناسب اتخاذ کنیم و محاسبات را بر روی نمونه‌های ساده تر شده انجام دهیم. در این مقاله به کمک تحقیقاتی که از پیش انجام شده از روش Random Walk برای نمونه گیری از این گراف استفاده شده است، که وارد جزئیات این روش نخواهیم شد. تحلیل ویژگی‌های شبکه پیچیده برای گراف تراکنش‌های بیت کوین1.توزیع درجهبررسی توزیع درجه گره شبکه بیت کوین بسیار مهم است. تعداد یال های متصل به یک گره درجه آن گره تعریف میشوند که با k در شبکه پیچیده نشان داده می شود. در شبکه تراکنش بیت کوین، درجه k برای هر آدرس بیت کوین با جمع تعداد تراکنش ها محاسبه می شود. در این بین تعداد تراکنش های ورودی (دریافت بیت کوین) به صورت درون درجه و تعداد تراکنش های خروجی (پرداخت بیت کوین) برون درجه است. علاوه بر این، توزیع درجه را که با P(k) در درجه k نشان داده شده است، معرفی می کنیم. توزیع درجه P(k) احتمال این است که یک گره به طور تصادفی انتخاب شده دارای درجه ای برابر با k باشد. بعلاوه، اگر درجه k از قانون توان پیروی کند، آنگاه داریم P(k) ∝ k^-α، که α پارامتر مقیاس بندی توزیع قانون توان است. شکل 2 توزیع درجه شبکه بلاک چین بیت کوین را در نمودارهای log-log نشان می دهد (یعنی مقیاس لگاریتمی در هر دو محور افقی و عمودی). به طور خاص، پارامتر مقیاس بندی توزیع درجه کل در این شبکه، α = 1.411 است که در شکل 2 در سمت چپ نشان داده شده است. علاوه بر این، به ترتیب در شکل 2 قسمت میانی (یعنی αin = 1.421) و توزیع های خروجی درجه شکل 2 سمت راست (یعنی αout = 1.418) را در نظر می گیریم. ما از نتایج مشاهده می‌کنیم که همه توزیع‌های درجه از توزیع power-law با heavy tail پیروی می‌کنند. به این معنی است که شبکه بیت کوین یک شبکه بدون مقیاس است که در آن تنها تعداد کمی از گره ها دارای تعداد زیادی اتصال هستند، در حالی که اکثر گره ها درجات پایینی دارند و اتصالات کمتری دارند. این با یافته های به دست آمده توسط تحقیقات پیشین با استفاده از داده های کامل شبکه واقعی مطابقت دارد.شکل 2 توزیع درجه به صورت لگاریتمی2.خوشه بندی و طول کوتاهترین مسیرمیزان خوشه بندی شبکه و طول کوتاهترین مسیر در آن می‌توانند شبکه را از دید هندسی‌تری مورد بررسی قرار دهند، که در این بخش به آن‌ها می‌پردازیم، در حالی که که این دو مفهوم را در ادامه توضیح می‌دهیم، وارد جزئیات فرمول‌های محاسبه آن‌ها نمی‌شویم. میزان خوشه بندی یک گراف با این مفهوم مطرح می‌شود که در یک گراف اگر یک گره با دو گره در ارتباط باشد آیا آن دو گره نیز به هم متصل هستند یا خیر. هرچه در بررسی گراف جواب این سوال بیشتر به "بله" باشد میزان خوشه بندی گراف بالاتر و هرچه پاسخ "خیر" بیشتری بشنویم، یعنی خوشه بندی در گراف در حال بررسی پایین تر می‌باشد.در کنار این مفهوم طول کوتاهترین مسیر بررسی می‌شود که به این مفهوم است که برای رسیدن از هر گره به گره‌ای دیگر ما باید گام‌هایی را در گراف طی کنیم که به کمترین گام‌های ممکن میان دو گره در گراف طول کوتاهترین مسیر آن گراف گفته می‌شود. توجه داشته باشیم که در گراف‌ها ممکن است مسیری میان همه‌ی گره‌ها وجود نداشته باشد و غیر متصل باشند که معمولا طول مسیر 0 یا infinity نشان داده می‌شود.در این نمونه V (G) مجموعه ای از گره ها در نمودار G است و l(i, j) نشان دهنده کوتاه ترین طول مسیر از i تا j است. برای نمودار تراکنش بیت کوین، CBitcoin = 0.0071 و LBitcoin = 3.833 داریم که به این معنی است که بسیاری از تراکنش های غیر مستقیم میان گره‌ها وجود دارد.مشاهده می کنیم که شبکه بیت کوین با مدل شبکه جهان کوچک مطابق CBitcoin و LBitcoin مطابقت دارد. برای یافتن شواهد این مشاهدات، لازم است که شبکه بیت کوین را با نمودار تصادفی معادل و گراف lattice مقایسه کنیم. بنابراین، میانگین کوتاه ترین مسیر شبکه تصادفی را با Lrand و میانگین ضریب خوشه بندی شبکه شبکه را با Clatt نشان می دهیم. سپس اندازه‌گیری دنیای کوچک که با ω [23] نشان داده می‌شود، به صورت زیر تعریف می‌شود: که در هر مقایسه چندین شبکه تصادفی مختلف و شبکه های lattice را در نظر می گیریم. در این آزمایش، ما پنج شبکه تصادفی و شبکه شبکه‌ای تولید شده را برای محاسبه میانگین ارزش Lrand و Clatt به ترتیب شمارش می‌کنیم. مقدار ω به محدوده [-1، 1] محدود می شود. هر چه این میزان به 0 نزدیک تر باشد شبکه بیشتر جهان کوچک در نظر گرفته می‌شود. شکل 3 نشان می دهد که ω = 0.23، نشان می دهد که شبکه بیت کوین در واقع یک شبکه جهان کوچک با توجه به ویژگی های مربوط به آن است. این اثر نشان می‌دهد که توکن‌های بیت‌کوین را می‌توان با چند مرحله بین اکثریت منتقل کرد. در واقع میزان گام‌ها میان گره‌ها با زیاد شدن تعداد گره‌ها به صورت لگاریتمی زیاد می‌شوند.شکل 33. مولفه همبنداز آنجایی که متوجه شدیم شبکه بلاک چین بیت کوین یک شبکه جهان کوچک است، تجزیه و تحلیل اتصال آن از اهمیت بالایی برخوردار است. در یک شبکه پیچیده، اگر هر جفت گره در یک زیرگراف حداقل یک مسیر داشته باشد، این گراف فرعی را مولفه همبند می نامیم. در همین حال، در مورد یک شبکه جهت‌دار، ما اجزای متصل قوی (SCC-Strongly connected Components) آن را اندازه‌گیری می‌کنیم، که در آن هر جفت گره تصادفی (i، j) یک مسیر هدایت‌شده از i به j و یک مسیر هدایت‌شده از j به i را به طور همزمان دارد. به طور مشابه، اجزای با اتصال ضعیف (WCC-Weakly Connected Components) به اجزای متصل بدون جهت اطلاق می شود.شکل 4شکل 4 نتایج محاسباتی اجزای متصل، از جمله تعداد SCC، اندازه بزرگترین SCC، تعداد WCC، و اندازه بزرگترین WCC را نشان می‌دهد. مشاهده می کنیم که هر دو بزرگترین SCC و بزرگترین WCC در مقایسه با اندازه کل نمودار نسبتاً بزرگ هستند (به ترتیب حدود 45٪ و 93٪ از گره ها را پوشش می دهند)، که نشان دهنده یک نمودار نسبتاً متصل است. ما همچنین حدس می زنیم که گره های هاب موجود بسیاری از گره های جدا شده را متصل می کنند. در واقع، چنین گره هابی ممکن است یک بورس، یک موسسه تجاری یا یک سازمان مالی باشد. در این میان می توان شاهد بود که تعداد WCC ها به مراتب کمتر از SCC ها است که نشان می دهد بسیاری از تراکنش ها در این نمودار تنها یک طرفه هستند. به عبارت دیگر، اکثر گره ها معاملات دو طرفه (ورودی و خروجی) را به طور مکرر انجام نمی دهند، یعنی فقط بیت کوین را پرداخت می کنند یا فقط می پذیرند.4. مرکزیتتجزیه و تحلیل اجزای متصل به حدس ما در مورد وجود گره های هاب در شبکه بیت کوین منجر می شود. برای تأیید آن، سپس مرکزیت آن را بیشتر تحلیل می‌کنیم، که اهمیت ساختار نسبی گره‌ها را در نمودار اندازه‌گیری می‌کند. اولاً، در شبکه بیت‌کوین، مرکزیت نزدیکی معیاری است برای اندازه‌گیری مدت زمانی که یک گره به طور متوالی کوین را به بقیه منتقل می‌کند.توضیحات محاسبه این معیار را نیز مانند معمیارهای قبلی با جزئیات پیچیده‌ی فرمول‌ها اشباع نمیکنیم. شکل 5شکل 5 مرکزیت نزدیکی و مرکزیت بین بودن را در مقابل درجه گره ترسیم می کند. ما از شکل 5 مشاهده می کنیم که نزدیکی با افزایش درجه افزایش می یابد. در همین حال، تعداد زیادی گره با مقادیر نزدیکی در حدود 0.04 وجود دارد که نشان می دهد آنها در نمودار نسبتاً به یکدیگر نزدیک هستند. این نتایج بیشتر تایید می کند که شبکه بیت کوین یک شبکه جهان کوچک است. از سوی دیگر، تنها تعداد کمی از گره‌های درجه بالا دارای مقادیر نزدیکی OWF(i)(معیاری برای اندازه‌گیری نزدیکی) بالاتری هستند، که نشان می‌دهد آنها به شدت با گره‌های دیگر مرتبط هستند، یعنی تراکنش‌های مکرر را انجام می‌دهند. از این مشاهدات، ما حدس می زنیم که آن گره ها ممکن است برخی مبادلات یا مؤسسات مرتبط باشند، همانطور که در قسمت قبل ذکر شد. شکل 5 همچنین نشان می دهد که میزان betweenness با افزایش درجه افزایش می یابد. به طور کلی، اگر تعداد زیادی گره با مقدار betweenness بالا وجود داشته باشد، باعث می شود تعداد زیادی گره "پل" در گراف ظاهر شوند. این گراف را شکننده می کند، به این معنی که اگر برخی از گره ها شکسته یا خارج شوند، شبکه نمی تواند اتصال را حفظ کند. این نتایج نشان می‌دهد که گره‌های پل‌سازی زیادی در شبکه بیت‌کوین وجود ندارد. به عبارت دیگر، در برابر حذف گره مقاوم است ولی در مقابل حذف یال‌ها با هدف مقاوم نیست. همچنین مشاهده می‌کنیم که بیشتر گره‌ها در نمودار بیت‌کوین دارای مقادیر نسبتاً کوچکی از نزدیکی و betweenness هستند، که به این معنی است که تعداد زیادی گره مرکزی وجود ندارد. فقط تعداد کمی از گره ها نزدیکی و بینایی نسبتاً بالایی دارند. بنابراین، ما یک نمودار چند مرکزی را مشاهده می‌کنیم: برخی از گره‌های مرکزی مستقیماً با تعداد زیادی گره بدون پرش متصل می‌شوند. دلیل چند مرکزی بودن و استحکام عالی را نیز می توان با توجه به توزیع نامتناسب گره ها بدست آورد.جمع‌بندی از شبکه بلاکچین بیت‌کوین در این بررسی، ما یک تحلیل شبکه پیچیده در شبکه تراکنش بیت کوین انجام داده ایم. به طور خاص، ما یک روش نمونه‌گیری جدید طراحی می‌کنیم، یعنی پیاده‌روی تصادفی با ویژگی‌های بازگشت به عقب، و چندین مشاهدات مهم را از طریق تجزیه و تحلیل گراف‌های نمونه گیری شده به دست می‌آوریم. اولاً، توزیع درجه شبکه تراکنش بیت کوین با توزیع power-law با heavy-tail مطابقت دارد که به یک شبکه بدون مقیاس تقریب می‌یابد. ثانیاً، با تجزیه و تحلیل میانگین ضریب خوشه‌بندی، کوتاه‌ترین طول مسیر و اندازه‌گیری جهان کوچک، متوجه می‌شویم که شبکه تراکنش بیت‌کوین یک شبکه جهان کوچک است. ثالثاً، از طریق تجزیه و تحلیل اجزای متصل، متوجه می‌شویم که بیشتر معاملات معاملات یک طرفه هستند. علاوه بر این، مشاهده می کنیم که شبکه بیت کوین یک شبکه چند مرکزی قوی در برابر حذف گره ها است. پس از آن، با توجه به عدم تناسب شبکه بیت کوین، گره های درجه پایین ترجیح می دهند به گره هایی با درجه بالاتر متصل شوند. ما همچنین پیوست ترجیحی گره های تازه اضافه شده را پیدا می کنیم. چنین یافته هایی می تواند به ما در درک بهتر رفتارهای ساختاری بلاک چین کمک کند.معرفی رمزارز و شبکه اتریومدر این بخش، بلاک‌چین اتریوم را با استفاده از چارچوب مدل‌سازی شبکه‌های پیچیده تحلیل می‌کنیم. حساب‌های فعال در بلاک‌چین به‌عنوان گره‌ها نشان داده می‌شوند، در حالی که تعاملات بین این حساب‌ها، ثبت‌شده در زنجیره بلوکی، به‌عنوان پیوندهایی در شبکه تلقی می‌شوند. با استفاده از این نمایش، می‌توان ویژگی های ریاضی جالبی را استخراج کرد که درک تعاملات واقعی را که در بلاک‌چین اتفاق می افتد، بهبود می‌بخشد.اتریوم، دومین رمز ارز بزرگ پس از بیت کوین است، که در چند سال اخیر توجه زیادی را به خود جلب کرده و رکوردهای تراکنش قابل توجهی را جمع آوری کرده است. با این حال، ساختار زیربنایی شبکه اتریوم هنوز نسبتا ناشناخته است. همچنین، تلاش‌های بسیار کمی برای انجام پیش‌بینی‌پذیری پیوند در شبکه تراکنش‌های اتریوم انجام شده است. همچنین این بخش یک تحلیل دقیق از شبکه اتریوم در چارچوب رفتار تراکنش، ساختار جامعه و پیش‌بینی پیوندبرای بررسی جنبه‌های ارزشمند مختلف شبکه اتریوم ارائه می‌کند. به طور خاص، در این بخش تغییر در توزیع و انباشت ثروت در شبکه تراکنش‌های اتریوم بررسی می‌شود.شبکه‌ها ساختارهای داده‌ای هستند که در همه جا حاضر هستند و سناریوهای پیچیده دنیای واقعی را نشان می‌دهند که عموماً روابط بین اشیاء را شامل می‌شوند. بلاک‌چین یکی از شبکه‌های امیدوار کننده‌ای است که پتانسیل اصلاح چندین کسب و کار مرسوم را دارد. نسل اول بلاک‌چین، یعنی بیت‌کوین، نشان داده است که اجماع جهانی را می‌توان بدون شخص ثالث قابل اعتماد یا مرجع مرکزی تکمیل کرد. در نتیجه، بسیاری از محققان به دلیل کاربردهای بالای آنها در بسیاری از تنظیمات دنیای واقعی، تلاش زیادی برای طراحی سیستم‌های بلاک‌چین قدرتمندتر و چند منظوره انجام داده‌اند.بعداً، اتریوم در سال 2015 توسعه یافت و به دومین پلتفرم بزرگ بلاک‌چین تبدیل شد که ارزش بازار آن در سال 2020 به بیش از 1000 میلیون دلار رسید. پس از توسعه اتریوم، این اتریوم با موفقیت در برنامه‌های مختلف از جمله مدیریت تراکنش، قراردادهای هوشمند و برنامه‌های کاربردی صنعتی مورد استفاده قرار گرفته شد. از آنجایی که ارزش اتریوم و پذیرش آن در بازار بالا رفت، برنامه‌های کاربردی سازمانی و تعداد کل کاربران نیز در حال افزایش است، اکنون توجه جامعه پژوهشی بر روی بررسی و تجزیه و تحلیل جنبه‌های مختلف سیستم اتریوم متمرکز شده است.اگرچه تحلیل‌های آماری مختلفی بر روی شبکه‌های تراکنش بلاک‌چین انجام شده است، اکثر این روش‌ها بر روی خوشه‌بندی و یافتن فعالیت‌های مخرب سیستم بیت‌کوین است. با این حال، به دلیل پروتکل‌ها و طراحی‌های مختلف، چنین تجزیه و تحلیل داده‌های بیت‌کوین را نمی‌توان مستقیماً روی داده های اتریوم اعمال کرد یا انجام داد.فعالیت‌های کاربران اتریوم همانطور که در شکل 6 نشان داده شده است در بلوک‌ها محصور می‌شوند که در آن هر تراکنش در داخل یک بلوک شامل آدرس‌های ارسال و دریافت و مقدار منتقل شده است. به عنوان یک دفتر کل مشترک باز، اتریوم به هر کاربری اجازه می‌دهد تا تاریخچه کل تراکنش را ذخیره کند. با استفاده از این تاریخچه، گره‌های ویژه (گره ماینر) می‌توانند تراکنش‌های جدید را تایید کنند.شکل 6همه کاربران شبکه اتریوم تراکنش‌ها را از طریق شناسه یا آدرسی که توسط الگوریتم امضای دیجیتال منحنی بیضوی (ECDSA)، دریافت و ارسال می‌کنند که جفت کلید خصوصی و عمومی را ارائه می‌دهد. کلید خصوصی برای ارسال تراکنش‌ها به آدرس دیگری و کلید عمومی برای دریافت تراکنش‌ها از آدرس دیگری استفاده می‌شود. یک تراکنش شامل آدرس فرستنده، آدرس گیرنده، مقدار (اتر)، زمان، و سایر ویژگی‌ها است. با این حال، برای امنیت و ناشناس ماندن، هویت واقعی کاربر به یک آدرس مرتبط نیست و تجزیه و تحلیل را دشوار می‌کند.بلاک‌چین اتریوم به عنوان یک شبکهمی‌توان از ابزارهای موجود در حوزه شبکه‌های پیچیده برای تجزیه و تحلیل یک بلاک‌چین استفاده کرد. در این مورد، حساب‌هایی که در بلاک‌چین تعامل دارند، می‌توانند به عنوان گره‌های شبکه نمایش داده شوند، در حالی که تعاملات آنها را می‌توان به‌عنوان پیوند مشاهده کرد. همچنین می‌توان وزنی را به هر پیوند مرتبط کرد، که ممکن است این تعامل را بیشتر مشخص کند. به عنوان مثال، ممکن است یک شمارنده برای ردیابی تعداد تراکنش‌های انجام شده در بازه زمانی بررسی مرتبط باشد. از طرف دیگر، ممکن است مقدار دیگری را نشان دهد، مانند ارزی که بین دو حساب منتقل می شود. شکل۷ تصویری از تجسم سه بعدی گزارش تقریباً 1 ساعته تعاملات (یعنی 240 بلوک) در شبکه بلاک‌چین اتریوم را نشان می‌دهد. این شکل نشانه‌های جالبی را در مورد شبکه تراکنش‌ها نشان می‌دهد. در واقع، چندین گره مهم وجود دارند که در بسیاری از تراکنش‌ها دخیل هستند، در حالی که به نظر می‌رسد اکثر گره‌ها دارای یک پیوند واحد هستند که از آنها وارد یا خارج می‌شود. این کاملا منطقی است، زیرا در وضعیت فعلی این بلاک‌چین و ارز دیجیتال مربوط به آن، بعید به نظر می‌رسد که یک حساب معمولی در بیش از یک تراکنش در ساعت شرکت کند. شبکه تحلیل شده در این عکس که از مقاله[۳] گرفته شده است از 28867 گره تشکیل شده است که مربوط به همان مقدار حساب‌هایی است که در یک ساعت در نظر گرفته شده فعال بوده‌اند. تعداد لینک‌ها نیز 32800 می‌باشد.شکل۷تجزیه و تحلیل شبکه های پیچیده که در بالا توضیح داده شد با استفاده از یک نرم افزار جدید به نام EtherNetGalaxy انجام شده است. شرح کامل EtherNet Galaxy خارج از بحث این تحقیق است، اما برای کسانی که علاقه‌مند هستند، مطالعه این ابزار خالی از لطف نیست. در مرحله اول، EtherNet Galaxy داده‌های بلاک‌چین اتریوم را با استفاده از APIهای ارائه شده توسط Infura، سرویسی که دسترسی RPC را به شبکه اتریوم ارائه می‌دهد، بازیابی می کند. به لطف این سرویس، EtherNet Galaxy قادر است اطلاعات مربوط به بلوک‌ها (به عنوان مثال شماره بلوک، اندازه، لیست تراکنش‌ها و غیره) را بازیابی کند. در مرحله دوم، بلوک‌های بازیابی شده با استفاده از بسته web3-eth تجزیه و تحلیل می‌شوند. در این مرحله، هدف این است که تمام تراکنش‌های کدگذاری شده در هر بلوک را استخراج کرده و با استفاده از فرمت مورد نیاز، آنها را به‌عنوان یک شبکه نمایش داد. در نهایت، تجزیه و تحلیل شبکه بر روی نمودارهای تولید شده قبلی توسط EtherNet Galaxy با تکیه بر کتابخانه نرم افزار Python NetworkX انجام می‌شود. نرم افزار تجزیه و تحلیل شبکه Ether-Net Galaxy در حال حاضر در دست توسعه است، یک نسخه اولیه برای تجزیه و تحلیل گزارش شده در این لینک آمده است.جدول 1 برخی از معیارهای اصلی مربوط به شش شبکه تقسیم‌بندی شده در شبکه اتریوم را نشان می‌دهد که با در نظر گرفتن مجموعه تراکنش‌های موجود در تعداد بلوک‌های مختلف به دست آمده است. جدول۱: برگرفته از مقاله۳همانطور که انتظار داشتیم، اگر تراکنش‌هایی را در نظر بگیریم که در یک بلوک قرار دارند، یک شبکه بسیار ساده با گره‌ها و یال‌های کم به دست می‌آوریم. تعداد گره‌ها از تعداد یال‌ها بیشتر است. بنابراین ممکن است انتظار داشته باشیم که تراکنش‌هایی با چندین گیرنده وجود داشته باشد. با توجه به ماهیت تصادفی انتخاب تراکنش‌های درج شده در یک بلوک، می‌توانیم تصور کنیم که تراکنش‌ها شامل گره‌های مختلفی هستند. بنابراین، شبکه حاصل بسیار پراکنده است. در واقع، هیچ مثلثی در شبکه وجود ندارد (ضریب خوشه بندی صفر است). بیایید جزء اصلی شبکه 1 بلوکی را در نظر بگیریم. از 19 گره و 18 پیوند (همانطور که در جدول گزارش شده است) تشکیل شده است. قبلاً بیان کردیم که این شبکه مربوط به دسته‌ای از تراکنش‌های موجود در یک بلوک است، یعنی احتمالاً در یک بازه زمانی کوچک ایجاد شده‌اند. در اینجا ممکن است دو گزینه داشته باشیم. اولین مورد این است که جزء دارای ساختار ستاره‌ای است، به این معنی که یک آدرس خاص با مجموعه‌ای از گره ها همانطور که در شکل ۸ نشان داده شده است تعامل دارد. گزینه دوم این است که تعاملات مربوط به ساختار زنجیره‌ای از تراکنش‌های مختلف است (شکل ۹). شکل ۸: ساختار ستاره‌ایشکل۹: ساختار زنجیره‌ایتوزیع درجه شبکه‌ به راحتی اجازه می‌دهد تا درک کنیم که آیا، برای مثال، توزیع درجه از یک تابع قانون توزیع توانی پیروی می‌کند یا خیر. تنها با یک بلوک، شبکه به دست آمده بسیار ساده است. تعداد محدودی از گره‌ها وجود دارد که تراکنش‌ها را ایجاد می‌کنند. علاوه بر این، بعید است که یک حساب در هر بلوک بیش از یک تراکنش درگیر باشد. توزیع درجه در شکل ۱۰ این را تایید می‌کند. وقتی ترتیب بزرگی بلوک‌های در نظر گرفته شده را افزایش می‌دهیم، آنگاه همه چیز شروع به تغییر می کند. با این حال، اکثریت بالای گره‌ها یک تراکنش را انجام می‌دهند (یعنی درجه آنها برابر با 1 است). با این حال، درصد گره‌هایی با درجات بالاتر (یعنی مقادیر بالاتر تراکنش با گره های مختلف) افزایش می‌یابد. اگر به نمودار در مقیاس log-logنگاه کنیم، می‌توانیم کاهش تقریباً خطی در توزیع درجه‌ها را با یک دنباله بلند ببینیم که نشان می‌دهد این درجات از تابع قانون توان پیروی می‌کنند. شکل۱۰: برای ۱ بلوک شکل۱۰: برای ۱۰۰۰۰۰ بلوک ذکر این نکته ضروری است که یک رویه رایج در ارزهای رمزنگاری شده، به ویژه در بیت کوین، ایجاد یک آدرس جدید برای هر پرداختی است که کاربر دریافت می‌کند. این به منظور جداسازی گیرنده تراکنش‌های مختلف و افزایش سطح ناشناس بودن استفاده می‌شود. در واقع، اکثر کیف پول‌های آنلاین هر بار که کاربر به عنوان خروجی تراکنش درگیر می‌شود، به طور خودکار یک آدرس جدید ایجاد می‌کنند. همچنین مطالعات موجود در مورد اتریوم بر تجزیه و تحلیل داده‌های تراکنشی اتریوم از نظر کمیت، شبکه درون‌درجهی و توزیع‌های خارج از درجه تمرکز دارد. برای مثال، در مقاله [۴] با استفاده از الگوریتم درخت تصمیم تراکنش‌های آینده را پیش‌بینی می‌کنند، که توانایی استفاده از تئوری شبکه برای تحلیل شبکه تراکنش‌های اتریوم را نشان می‌دهد. با این حال، بیشتر مطالعات در این زمینه هنوز تحلیل‌های دقیق ساختارهای جامعه شبکه را نادیده می‌گیرند. در حالی که مطالعات گسترده‌ای بر روی شبکه‌های بلاک‌چین مانند بیت‌کوین انجام شده است به دلیل استقرار طولانی آن، تجزیه و تحلیل شبکه بر روی اتریوم کاملاً محدود است. چنین تحلیل‌هایی می‌توانند نقش مهمی در توزیع ثروت، ساختار رابطه‌ای شبکه و پیش‌بینی‌پذیری پیوند از داده‌های شبکه ناهمگن داشته باشند.به طور خاص، در این قسمت یک تجزیه و تحلیل دقیق از شبکه اتریوم بر روی رفتار تراکنش، ساختار انجمن و چارچوب پیش‌بینی پیوند، به عنوان یک پلتفرم واحد برای انجام تحلیل‌های مختلف به طور همزمان پیشنهاد شده است. به طور خاص، DANET از چهار ماژول اصلی تشکیل شده است[5]: (1) مدیریت داده‌های اتریوم (2) تجزیه و تحلیل رفتار تراکنش اتریوم؛ (3) تجزیه و تحلیل ساختار جامعه اتریوم. و (4) تجزیه و تحلیل پیش بینی لینک اتریوم.به طور خاص، مدیریت داده‌های اتریوم برای جمع‌آوری و فیلتر کردن داده‌های تراکنش استفاده شده در آزمایش‌ها طراحی شده است. در عین حال، تجزیه و تحلیل رفتار تراکنش اتریوم و تجزیه و تحلیل ساختار جامعه اتریوم برای درک بهتر ویژگی‌های شبکه، مانند روابط درون درجه‌ای و برون درجه‌ای، پیشنهاد شده است.تجزیه و تحلیل داده‌های اتریومدر مقاله چان و اولمستد[6] از یک نمودار مبتنی بر تراکنش استفاده کردند که بر روی هر گره پیکربندی شده بود تا رفتار هر آدرس را تجزیه و تحلیل کند. آنها همچنین گره‌ها را با استفاده از شباهت نمودار خوشه بندی کردند. این مطالعه به این نتیجه رسید که ورودی تراکنش‌های جدید اتریوم بر خلاف بیت‌کوین مستقل از خروجی تراکنش‌های خرج نشده گذشته است. همچنین جنسر و همکاران[7] آمار توزیع بلاک‌چین‌های مختلف را تجزیه و تحلیل کرده است. نتایج نشان می‌دهد که 61 درصد از قدرت ماینینگ هفتگی تنها توسط سه شناسه به اشتراک گذاشته می‌شود که 90 درصد از قدرت توسط 11 نهاد به اشتراک گذاشته می‌شود.یکی دیگر از نتایج جالب که در طول تحقیقات متوجه شدیم در مقاله[۸] نهفته بود. در ایت مقاله، یک الگوریتم طبقه‌بندی برای شناسایی حساب‌های غیرقانونی در شبکه اتریوم پیشنهاد کردند. مجموعه داده‌های آن‌ها شامل ۲۱۷۹ حساب غیرقانونی است که توسط انجمن اتریوم پرچم‌گذاری شده‌اند. آنها تشخیص داده‌اند که ویژگی‌های برتر مرتبط با فعالیت‌های غیرقانونی شامل «تعادل کل اتر» و «حداقل مقدار دریافت‌شده» است.تحلیل دیگری که مقاله لی و همکاران[۹] تمرکز داشتند که تمام تراکنش‌های ارزهای دیجیتال و توکن‌های رمزنگاری شده به‌طور دائم در دفتر کل توزیع‌شده ثبت می‌شوند و برای عموم در دسترس هستند، که امکان توسعه یک نمودار تراکنش و تجزیه و تحلیل ارتباطات بین ویژگی‌های نمودار تراکنش و پویایی قیمت کریپتو را فراهم می‌کند. آن‌ها از اصول همولوژی پایدار و عمق داده‌های عملکردی برای مطالعه توکن‌های رمزنگاری اتریوم، به‌ویژه بررسی پیش‌بینی‌های ناهنجاری قیمت و حرکت مخفی بین توکن‌ها استفاده کردند. با استفاده از تجزیه و تحلیل داده های توپولوژیکی و عمق داده های عملکردی در تجزیه و تحلیل داده های بلاک چین، آنها دریافتند که شبکه اتریوم می تواند بینش‌های ارزشمندی در مورد تغییرات قیمت رمزارزها ارائه دهد که در غیر این صورت با منابع داده‌های مرسوم و روش‌های تحلیلی سنتی تا حد زیادی قابل دسترسی نیستند.پیش بینی لینک در شبکه اتریوماز منظر شبکه، وظیفه پیش‌بینی پیوند یک مسئله مهم است که رویکردهای آن از سه دسته تشکیل شده است: روش‌های اکتشافی، روش‌های تعبیه گراف، و روش‌های یادگیری ویژگی. روش‌های اکتشافی معمولاً شباهت‌های گره‌ها را با استفاده از روش‌های نظری گراف محاسبه می‌کنند و از آنها به عنوان احتمال پیوند استفاده می‌کنند (ژانگ و همکاران، 2020). در میان آنها دلبستگی ترجیحی (باراباسی و آلبرت، 1999)، ضریب جاکارد (لیبن-نوول و کلینبرگ، 2007)، و شاخص کاتز (کاتز، 1953) روش‌های شناخته شده‌ای هستند. روش‌های تعبیه گراف شامل یادگیری جاسازی‌های گره با پارامتر آزاد بر اساس شبکه از پیش تعریف‌شده در یک محیط انتقالی است که در آن نمی‌توان آن‌ها را روی گره‌های دیده نشده تعمیم داد. دسته سوم شامل روش‌های قدرتمند و اخیراً پدیدار شده شبکه‌های عصبی گرافیکی (GNN) است که ویژگی‌های گره را با استفاده از مکانیزم ارسال پیام یاد می‌گیرند و به خوبی بر روی گره‌های دیده نشده تعمیم می‌دهند. برای تجزیه و تحلیل جامع شبکه اتریوم و سوابق تراکنش، یک چارچوب تلفیقی پیشنهاد شده است: که شامل چهار ماژول اصلی برای ارائه نتایج تجزیه و تحلیل متفاوت است.(1) مدیریت داده های اتریوم: برای جمع آوری داده‌های تراکنش‌های اتریوم برای آزمایش‌ها و محاسبه ویژگی‌های آماری شبکه اتریوم.(2) تجزیه و تحلیل رفتار تراکنش اتریوم: برای بررسی رفتار تراکنش مانند روابط درون و برون درجه.(3) تجزیه و تحلیل ساختار انجمن اتریوم: برای شناسایی ویژگی ساختار جامعه اتریوم.(4) تجزیه و تحلیل پیش‌بینی لینک اتریوم: برای ارزیابی اثربخشی چارچوب ما در کار پیش‌بینی پیوند اتریوم.جمع آوری داده های اتریومبرای جمع‌آوری داده‌ها، از نود‌های اتریوم برای جمع‌آوری تمام داده‌های تراکنش استفاده شده است. این پروسه 11 روز طول کشید تا داده‌ها را جمع آوری کند.[] همچنین برای بازیابی بلوک‌ها و استخراج اطلاعات تراکنش از هر بلوک و ذخیره اطلاعات استخراج شده در پایگاه داده PostgreSQL استفاده شده است. کل داده‌های تراکنش‌های اتریوم جمع آوری شده از «07-08-2015» تا «01-01-2019» شامل 189 میلیون تراکنش در 55 بلاک است.تحلیل رفتار تراکنش اتریومداده‌های تراکنش‌ اتریوم استخراج شده، توسط روشی که در مقاله Muzammal و همکاران ذکر شده، پردازش شده است. یک شبکه ویژه تراکنش اتریوم (ETFN) ایجاد شده است که در آن رئوس نشان‌دهنده آدرس‌ها و یال‌ها نشان‌دهنده رابطه از نظر تراکنش بین رئوس هستند. به طور رسمی،ETFN یک گراف جهت دار نسبت داده شده است G = (V,E) که در آن V = {v1,v2,v3,...,vn} و E = {e1,e2,e3,...,em}. همچنین، e = (u,v,w) را تعریف می‌کنیم که در آن u و v نشان دهنده دو گره در V و w وزن لبه بین این دو گره است.تجزیه و تحلیل ساختار انجمنی اتریومکاوش در ساختار انجمنی یک شبکه نقشی حیاتی در درک ساختار شبکه ایفا می‌کند. انجمن نشان‌دهنده مجموعه‌ای از افراد با علایق مشترک در یک شبکه است. به عنوان مثال، در یک شبکه تعامل پروتئین-پروتئین، پروتئین‌هایی که عملکرد مشترک دارند ممکن است متعلق به یک انجمن باشند. یک انجمن ممکن است ناحیه خاصی از مغز را نشان دهد که دارای اتصال نورون‌های متراکم در یک شبکه مغزی دارد. به طور مشابه، در یک شبکه تراکنش، یک انجمن نشان دهنده افرادی است که اغلب با یکدیگر تراکنش انجام می‌دهند. کاوش در انجمن یک شبکه تراکنش می‌تواند اطلاعات بالقوه و ارزشمند افراد را در مورد الگوهای تراکنش و شکاف‌های زمانی آنها آشکار کند (اگر شبکه متغیر زمانی باشد) (نیومن و گیروان، 2004؛ نیومن، 2006).با توجه به کاربردهای متعدد در طیف گسترده‌ای از تنظیمات دنیای واقعی، تشخیص انجمن توجه ویژه جامعه پژوهشی، به ویژه الگوریتم تشخیص انجمن لووین را به خود جلب کرده است (Blondel et al., 2008). الگوریتم Louvain یک روش حریصانه مبتنی بر بهینه‌سازی معیار مدولاریته است که به طور گسترده برای شناسایی انجمن در شبکه‌های ارزهای دیجیتال، مانند بیت کوین استفاده شده است (رمی، ریم و متیو، 2017؛ ژانگ، وانگ و ژائو، 2020؛ گاوین و کرین، 2021). در حالی که شبکه بیت‌کوین تفاوت‌هایی با شبکه اتریوم دارد، منطقی است که از پروتکل‌های مشابهی که به طور گسترده برای تجزیه و تحلیل این شبکه‌های ارز دیجیتال استفاده می‌شود، پیروی کنیم.معادله محاسبه انجمنی بودن ساختار شبکه اتریوممقدار مدولاریت بین [1،1-] است، جایی که بالاترین مقدار ساختار انجمن خوب را نشان می‌دهد و بالعکس. ارزش منفی به معنای عدم وجود ساختار جامعه در شبکه است. اگر همه رئوس به یک جامعه اختصاص داده شوند، مقدار به صفر نزدیک می شود.الگوریتم Louvain مقدار مدولار بودن شبکه را بهینه می‌کند و از دو فاز تشکیل شده است. مرحله اول یک انجمن متفاوت را به هر گره اختصاص می‌دهد و سپس به طور جذابی هر گره را با انجمن همسایه خود ترکیب می‌کند و امتیاز مدولاریت را ارزیابی می‌کند. در صورت بهبود در نمره مدولاریت، گره‌ها در یک انجمن واحد ادغام می‌شوند. این روند تا زمانی تکرار می‌شود که هیچ افزایشی در نمره مدولاریت وجود نداشته باشد. در مرحله دوم، انجمن‌های فاز اول به یک گره فشرده می‌شوند که در آن لبه‌های داخلی به عنوان خود پیوند استفاده می‌شود و مرحله اول را تکرار می‌کند. هنگامی که هیچ پیشرفت دیگری یافت نشد، الگوریتم متوقف می‌شود و ساختار انجمن شناسایی شده را برمی‌گرداند. الگوریتم تشخیص جامعه Louvain یکی از الگوریتم‌های مقیاس‌پذیر با O(nlogn) است که n تعداد گره‌ها است.پیش بینی لینکبه یاد بیاورید که شبکه EFTN از 2.7 میلیون گره و 4.6 میلیون یال تشکیل شده است. در تحقیق مشاهده کردیم که تعداد کمی از گره‌ها (کمتر از 10) دارای درجه‌های بزرگی هستند که نقش هاب‌ها را در شبکه بازی می‌کنند. بنابراین، برای جلوگیری از پراکندگی در ماتریس ویژگی‌های، اندازه را ثابت در نظر گرفته شده است و اگر درجه یک گره از 100 بیشتر باشد، یک درجه 100 اختصاص داده شده است. با توجه به محدودیت حافظه، دو شبکه مختلف ساخته شده است. 15 روز اول حدود 0.210 میلیون تراکنش را شامل می شود، در حالی که پنج روز باقی مانده 0.211 میلیون تراکنش دارد. دو شبکه G1 و G2 را جدا از این داده ها ساخته شده است. تعداد گره‌ها و یال‌ها در G1 به ترتیب 33989 و 53261 بود، در حالی که در G2 37175 گره و 56987 یال وجود داشت. توجه داشته باشید که داده‌ها به‌طور تصادفی در نظر گرفته شده است. با این حال، نویسندگان این مقاله معتقداند که تکه‌ای از داده‌ها در هر نقطه می‌تواند در نظر گرفته شود و نتایج مشابهی ایجاد کند. همچنین، هر دو شبکه را بدون جهت در نظر گرفته شده است، زیرا تراکنش را بین دو آدرس ساخته شده از هر طرف پیش‌بینی خواهند کرد. هر دو شبکه ساخته شده را در شکل 11 نشان داده شده است.شکل۱۱نتایج آزمایشدر این بخش مجموعه کاملی از تحلیل‌های مبتنی بر شبکه اتریوم را به شرح زیر ارائه می‌کنیم.مشخصات آماری شبکه اتریومهمانطور که در شکل ۱۲ نشان داده شده است، می‌توانیم متوجه شویم که اکثر آدرس ها (88 درصد) هر کدام با کمتر از 10 تراکنش مرتبط هستند. همچنین 39 آدرس به طور مکرر در شبکه استفاده می‌شود و با حداقل 50000 تراکنش همراه است. از سوی دیگر، 32 درصد از آدرس‌ها تنها یک بار در یک تراکنش شرکت می‌کنند. همچنین شش آدرس فعال در بیش از 1,000,000 (30%) تراکنش شرکت دارند. ما شش آدرس فعال را بررسی کردیم: ENS-Registrar، YoCoin، Bittrex_2، Acronis_Contract، Poloniex_1 وKraken_5 و متوجه شدیم که آدرس‌های قرارداد هستند.شکل ۱۲ به طور مشابه، 1،700،413 (49 درصد) تراکنش‌های پشتیبانی تنها یک بار در تاریخ دریافت شدند، به این نتیجه رسیدند که اکثر آنها می‌خواستند ناشناس باقی بمانند، زیرا آدرس‌های خود را پس از هر تراکنش تغییر می‌دادند. این مطالعه نشان داد که تعداد کل اترهای دریافتی از اکثر آدرس‌ها به سختی قابل توجه است.همچنین توزیع اندازه تراکنش‌های شبکه نشان می‌دهد که در زمان‌های دیگر، بسیاری از تراکنش‌ها بسیار کوچک هستند و قابل توجه است که کمتر از 1 اتر توسط 53 درصد تراکنش‌ها دریافت شده است. به همین ترتیب، با در نظر گرفتن مقادیر متوسط، کمتر از 10 اتر توسط 88 درصد تراکنش‌ها دریافت شد. علاوه بر این، جدول زیر نشان می‌دهد که تنها 1788 تراکنش بیش از 50000 اتر دریافت کرده‌اند.تحلیل رفتار تراکنش اتریومجریان تراکنش با تقسیم داده‌ها به دو فاز، روابط ورودی و خروجی از گره، تجزیه و تحلیل شده است. از آنجایی که شبکه در طول زمان رشد می‌کند، ما نیز علاقه‌مند به اندازه‌گیری رشد شبکه هستیم. شکل ۱۳ نشان می دهد که شبکه اتریوم با گذشت زمان در حال تغییر است. خط برابری با استفاده از خط زرد نشان داده شده است. اگر خطوط دیگر به آن نزدیک شوند، این بدان معناست که سیستم به سمت برابری حرکت می‌کند.شکل ۱۳نتیجه گیری بر روی شبکه اتریوم با رویکرد شبکه پیچیدهدر این مقاله، ما یک تحلیل دقیق از شبکه اتریوم بر روی رفتار تراکنش، ساختار جامعه و چارچوب پیش‌بینی پیوند (DANET) برای ردیابی تکامل داده‌های تراکنش‌های اتریوم از دیدگاه تجزیه و تحلیل گراف پیشنهاد کردیم. همچنین، توزیع ثروت بر روی اتریوم را از نظر درجه شبکه بررسی کردیم و ساختار جامعه شبکه را با نشان دادن اطلاعات هیجان انگیز بررسی کردیم. با بررسی این نمودارها از طریق چندین معیار، مشاهدات و بینش های جدیدی به دست می آوریم که می تواند به درک شبکه اتریوم کمک کند.مراجع[1] Li, P., Li, K., Wang, Y., Zheng, Y., Wang, D., Yang, G., & Yu, X. (2022). A systematic mapping study for blockchain based on complex network. Concurrency and Computation: Practice and Experience, 34.[2] Tao, B., Dai, H., Wu, J., Ho, I.W., Zheng, Z., & Cheang, C. (2022). Complex Network Analysis of the Bitcoin Transaction Network. IEEE Transactions on Circuits and Systems II: Express Briefs, 69, 1009-1013.[3] Ferretti, Stefano & D'Angelo, Gabriele. (2019). On the Ethereum blockchain structure: A complex networks theory perspective. Concurrency and Computation: Practice and Experience. 32. 10.1002/cpe.5493.[4] Muzammal Z, Janjua MU, Abbas W, Sher F. 2019. Wealth distribution and link predictability in ethereum. In: IEEE/WIC/ACM international conference on web intelligence-companion Volume. New York: ACM, 184–19.[5] Said A, Janjua MU, Hassan S, Muzammal Z, Saleem T, Thaipisutikul T, Tuarob S, Nawaz R. 2021. Detailed analysis of Ethereum network on transaction behavior, community structure and link prediction. PeerJ Computer Science 7:e815.[6] Chan W, Olmsted A. 2017. Ethereum transaction graph analysis. In: 2017 12th international conference for internet technology and secured transactions (ICITST). Piscataway: IEEE, 498–500.[7] Gencer AE, Basu S, Eyal I, van Renesse R, Sirer EG. 2018. Decentralization in Bitcoin and Ethereum Networks. CoRR. ArXiv preprint. arXiv:1801.03998.[8] Farrugia S, Ellul J, Azzopardi G. 2020. Detection of illicit accounts over the Ethereum blockchain. Expert Systems with Applications 150:113318 DOI 10.1016/j.eswa.2020.113318[9] Li Y, Islambekov U, Akcora C, Smirnova E, Gel YR, Kantarcioglu M. 2020. Dissecting ethereum blockchain analytics: what we learn from topology and geometry of the ethereum graph? In: Proceedings of the 2020 SIAM international conference on data mining. Philadelphia: SIAM, 523–531.«این مطلب، بخشی از تمرینهای درس شبکه‌های پیچیده پویا در دانشگاه شهیدبهشتی است» Pooya Sabeti Pooya Sabeti Mon, 11 Jul 2022 19:40:18 +0430 https://virgool.io/@pooyasabeti97/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%87%D8%A7%DB%8C-%D9%85%D8%B7%D8%B1%D8%AD-%D8%AF%D9%86%DB%8C%D8%A7%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-js7oe9ceycd1 پویا ثابتی - سپهر اویسیمقدمهبا گسترش روزافزون صنعت نرم‌افزار، دیگر روش‌ها و سبک‌های سنتی تولید نرم‌افزار، پاسخگوی این نیازمندی‌ها نبوده‌اند. در صنعت تولید نرم‌افزار یکی از دلایل کلیدی موفقیت، معماری استفاده شده برای تولید نرم‌افزار می‌باشد. امروزه می‌بینیم که بسیاری از نرم‌افزارهای تولید شده با وجود داشتن ایده‌های نوین با شکست روبرو می‌شوند. در مقابل نرم‌افزارهایی نیز وجود دارند که ایدهای نسبتا تکراری داشته ولی به علت داشتن معماری نرم‌افزاری قدرتمند به موفقیت‌های بزرگی دست یافته‌اند. دنیای نرم‌افزار هر روزه در حالا تغییر بوده و با توجه به نیازهای جدید، تیم‌های نرم‌افزاری خصوصیت‌های جدیدی را برای نرم‌افزار ایجاد می‌کنند. خصیصه جدید در این صنعت اکثر اوقات نیازمند بهره بردن از روشی است که در گذشته استفاده شده و یا به عنوان یک شرکت پرچم دار یک راه حل جدید برای مشکل به دست آورد. یکی از اقداماتی که می‌تواند به خوبی در این روند کمک کند بهره بردن از معماری‌های نرم افزارهای مرسوم و پیشرو و یا معماری‌های استفاده شده توسط شرکت‌هایی باشد که تجربیات زیاد در رضایت کاربران داشته‌اند.در این پست، چند نرم‌افزار و سرویس که توسط شرکت‌های بزرگ تولید شده و توسعه یافته‌اند و همچنین دارای موفقیت‌های بزرگی در حوزه‌های فعالیت خود می‌باشند را بررسی می‌کنیم. متأسفانه تمامی جنبه‌های معماری این شرکت‌ها را نمی‌توان در یک مقاله خلاصه کرد ولی می‌توان نقاط قوت هر نرم‌افزار را در پیاده‌سازی معماری زیر ذره‌بین قرار داد. همچنین برای افزایش دقت بررسی و داشتن فاکتوری برای مقایسه نرم‌افزارها را بر اساس صنعت فعالیت به دسته‌های دوتایی تقسیم کرده تا بتوان در کنار هم برخی چالش‌ها و راه حل‌های به کار گرفته شده در آن نرم‌افزارها را مورد مطالعه قرار داد.نرم‌افزارها و ابزارهای بسیار زیادی هستند که قطعا بررسی معماری آن‌ها دید جدیدی در مورد سیستم‌های کامپیوتری در اختیار می‌گذارد. در این مقاله 6 مورد از آن‌ها انتخاب شده و در 3 دسته دوتایی مورد بررسی قرار داده می‌شود. این دسته بندی‌ها به شرح زیر می‌باشد:۱ - سیستم‌های استریم فیلم: Netflix و Amazon Prime Video۲- سیستم‌های پخش موسیقی: Spotify و Apple Music۳- سیستم‌های شبکه‌های اجتماعی: Facebook و Twitterبه ترتیب در بخش اصلی به بررسی برخی نکاتی که این نرم‌افزارهای داشته اند می‌پردازیم. معماری Netflix و Amazon Prime Video نتفلیکس سال‌هاست که یکی از بهترین سرویس‌های پخش ویدئو مبتنی بر اشتراک آنلاین در جهان است و بیش از 15 درصد از ظرفیت پهنای باند اینترنت جهان را به خود اختصاص داده است. در سال 2019، نتفلیکس در حال حاضر بیش از 167 میلیون مشترک با بیش از 5 میلیون مشترک جدید در هر سه ماهه است و در بیش از 200 کشور فعالیت می‌کند. به طور خاص، مشترکین نتفلیکس بیش از 165 میلیون ساعت را صرف تماشای بیش از 4000 فیلم و 47000 قسمت در روز می‌کنند. این آمار چشمگیر به ما نشان می‌دهد که از دیدگاه مهندسی، تیم‌های فنی نتفلیکس چنین سیستم پخش ویدیویی شگفت انگیزی را با در دسترس بودن و مقیاس پذیری بسیار بالا طراحی کرده‌اند تا به مشتریان خود در سطح جهانی خدمات ارائه دهند.با این حال، تیم‌های فنی نتفلیکس بیش از 8 سال طول کشید تا سیستم‌های فناوری اطلاعات خود را مانند الان داشته باشند. در واقع، دگرگونی زیرساخت در نتفلیکس در آگوست 2008 پس از قطع شدن خدمات در مراکز داده خودش که کل خدمات اجاره DVD را به مدت سه روز متوقف کرد، آغاز شد. نتفلیکس متوجه شد که به زیرساخت قابل اعتماد تری نیاز دارد که هیچ نقطه شکستی ندارد. بنابراین، دو تصمیم مهم گرفته است: انتقال زیرساخت فناوری اطلاعات از مراکز داده خود به یک ابر عمومی و جایگزینی برنامه‌های یکپارچه با اجزای نرم افزاری کوچک قابل مدیریت توسط معماری میکروسرویس‌ها. هر دو تصمیم مستقیماً موفقیت امروز نتفلیکس را شکل داده اند.نتفلیکس ابر AWS را برای انتقال زیرساخت‌های فناوری اطلاعات خود انتخاب کرده بود زیرا AWSمی‌توانست پایگاه‌های داده بسیار قابل اعتماد، فضای ذخیره‌سازی ابری در مقیاس بزرگ و مراکز داده متعدد در سراسر جهان ارائه دهد. نتفلیکس با استفاده از زیرساخت ابری که توسط AWS ساخته و نگهداری می‌شود، کارهای سنگین غیرمتمایز ساخت مراکز داده را انجام نداد، بلکه بیشتر بر کسب‌وکار اصلی خود یعنی ارائه تجربه کاربر پخش ویدئو با کیفیت بالا تمرکز کرد.نتفلیکس همچنین یکی از اولین محرک های اصلی معماری میکروسرویس ها است. Microservices مشکلات طراحی نرم‌افزار یکپارچه را با تشویق جداسازی نگرانی‌ها هدف قرار می‌دهد که در آن برنامه‌های بزرگ توسط ماژولار بودن با کپسوله‌سازی داده‌ها به تنهایی به اجزای نرم‌افزار کوچک‌تر تقسیم می‌شوند. Microservices همچنین به افزایش مقیاس پذیری از طریق مقیاس افقی و پارتیشن بندی حجم کار کمک می‌کند. مهندسان نتفلیکس با پذیرش میکروسرویس‌ها به راحتی هر سرویسی را تغییر می‌دهند که منجر به استقرار سریعتر می‌شود. مهمتر از آن، آنها می‌توانند عملکرد هر سرویس را ردیابی کنند و به سرعت مشکلات آن را از سایر سرویس های در حال اجرا جدا کنند. معماری Netflixنتفلیکس در معماری خود از خدمات محاسبات ابری آمازون (AWS) و Open Connectاستفاده میکند. هر دو سیستم باید به طور یکپارچه با هم کار کنند تا خدمات پخش ویدیو با کیفیت بالا را در سطح جهانی ارائه دهند. از نقطه نظر معماری نرم افزار، نتفلیکس شامل سه بخش اصلی است: Client، Backend و Content Delivery Network (CDN).در نتفلیکس Client هر مرورگر پشتیبانی شده در لپ تاپ یا دسکتاپ یا برنامه Netflix در تلفن های هوشمند یا تلویزیون های هوشمند است. نتفلیکس برنامه های iOS و Android خود را توسعه می دهد تا بهترین تجربه مشاهده را برای هر مشتری و دستگاه ارائه دهد. نتفلیکس با کنترل برنامه‌ها و سایر دستگاه‌های خود از طریق SDK خود، می‌تواند خدمات استریم خود را تحت شرایط خاصی مانند شبکه‌های کند یا سرورهای پربار، به طور شفاف تطبیق دهد.در قسمت بعدی یعنی Backend شامل سرویس‌ها، پایگاه‌های داده، سیستم‌های ذخیره‌سازی‌ است که به طور کامل بر روی ابر AWS اجرا می‌شوند. Backend اساساً همه چیزهایی را که شامل پخش ویدیوها نمی شود کنترل می کند. برخی از اجزای Backendبا خدمات AWS مربوطه خود به شرح زیر فهرست شده اند: نمونه‌های محاسباتی مقیاس پذیر (AWS EC2) فضای ذخیره‌سازی مقیاس پذیر (AWS S3) ریزسرویس‌های منطق تجاری (فریم‌ورک‌های هدفمند توسط نتفلیکس)پایگاه داده‌های توزیع شده مقیاس‌پذیر (AWS DynamoDB، Cassandra) کارهای پردازش و تجزیه و تحلیل داده‌های بزرگ (AWS EMR، Hadoop، Spark، Flink، Kafka و سایر ابزارهای هدفمند ساخته شده توسط Netflix) پردازش و رمزگذاری ویدیو (ابزارهای هدفمند توسط نتفلیکس)در قسمت بعدی یعنی Open Connect CDN شبکه‌ای از سرورها به نام Open Connect Appliances (OCAs) است که برای ذخیره و پخش ویدیوهای بزرگ بهینه شده است. این سرورهای OCA در شبکه‌های ارائه دهندگان خدمات اینترنتی (ISP) و مکان‌های تبادل اینترنتی (IXP) در سراسر جهان قرار می‌گیرند. OCA‌ها مسئول پخش مستقیم ویدیوها به مشتریان هستند.معماری پخش فیلموقتی مشترکین روی دکمه Play در برنامه‌ها یا دستگاه‌های خود کلیک می‌کنند، Client با Backend در AWSو OCAs در Netflix CDN ارتباط برقرار می‌کند تا ویدیوها را پخش کند نمودار زیر نحوه عملکرد فرآیند پخش را نشان می‌دهد:۱- بخش OCAها به طور مداوم گزارش‌های سلامتی در مورد وضعیت بار کاری، مسیریابی و ویدیوهای موجود خود را به سرویس Cache Control در حال اجرا در AWS EC2 ارسال می‌کنند تا برنامه‌های Playback آخرین OCA‌های سالم را به مشتریان به روز کنند.۲- یک درخواست Play از دستگاه مشتری به سرویس Playback Apps Netflix که روی AWS EC2 اجرا می‌شود ارسال می‌شود تا آدرس‌هایی را برای پخش ویدیوها دریافت کند.۳- سرویس Playback Apps باید مشخص کند که درخواست Play برای مشاهده ویدیوی خاص معتبر است. چنین اعتبار سنجی‌هایی طرح مشترک، مجوز ویدیو در کشورهای مختلف و غیره را بررسی می‌کند.۴- سرویس Playback Apps با سرویس Steering نیز در AWS EC2 اجرا می‌شود تا لیست سرورهای OCA مناسب ویدیوی درخواستی را دریافت کند. سرویس فرمان از آدرس IP مشتری و اطلاعات ISPها برای شناسایی مجموعه‌ای از OCA‌های مناسب برای آن مشتری استفاده می‌کند.۵- از لیست چندین سرور OCA مختلف که توسط سرویس Playback Apps برگردانده شده است، مشتری کیفیت اتصالات شبکه به این OCAها را آزمایش می‌کند و سریع‌ترین و مطمئن‌ترین OCA را برای درخواست فایل‌های ویدئویی برای پخش انتخاب می‌کند.۶- سرور OCA انتخاب شده درخواست‌های مشتری را می‌پذیرد و شروع به پخش فیلم می‌کند.معماری Backendهمانطور که در بخش‌های قبلی توضیح داده‌ام، Backend تقریباً همه چیز را کنترل می‌کند، از ثبت‌نام، ورود به سیستم، صورت‌حساب گرفته تا وظایف پردازشی پیچیده‌تر مانند رمزگذاری ویدیو و توصیه‌های شخصی‌شده. نتفلیکس به منظور پشتیبانی از حجم کاری سبک و سنگین که بر روی یک زیرساخت اساسی اجرا می شود، معماری میکروسرویس‌ها را برای سیستم مبتنی بر ابر خود انتخاب کرده است. در شکل زیر یک معماری میکروسرویس‌های احتمالی در Netflix را نشان می‌دهد که از چندین منبع آنلاین استخراج شده است.۱- یک Client یک درخواست Play به Backend در حال اجرا در AWSارسال می‌کند. این درخواست توسط متعادل کننده بار AWS (ELB) رسیدگی می‌شود.۲- سرویس AWS ELB آن درخواست را به API Gateway Service در حال اجرا در نمونه‌های AWS EC2 ارسال می‌کند. این مؤلفه که Zuul نام دارد توسط تیم نتفلیکس ساخته شده است تا امکان مسیریابی پویا، نظارت بر ترافیک و امنیت، انعطاف پذیری در برابر خرابی‌ها در لبه استقرار ابر را فراهم کند. این درخواست برای برخی از فیلترهای از پیش تعریف شده مربوط به منطق تجاری اعمال می‌شود، سپس برای رسیدگی بیشتر به API Application ارسال می‌شود.۳- جزء API Application منطق اصلی کسب و کار پشت عملیات نتفلیکس است. انواع مختلفی از API مربوط به فعالیت‌های مختلف کاربر مانند Signup API، Recommendation API برای بازیابی توصیه‌های ویدئویی وجود دارد. در این سناریو، درخواست ارسال شده از API Gateway Service توسط Play API مدیریت می‌شود.۴-رابط Play API یک میکروسرویس یا دنباله ای از میکروسرویس‌ها را برای انجام درخواست فراخوانی می‌کند. سرویس Playback Apps، سرویس Steering و سرویس Cache Control به عنوان یک میکروسرویس دیده می‌شود.۵- میکروسرویس‌ها اکثرا برنامه‌های کوچک بدون تابعیت هستند و می‌توانند با هم در ارتباط باشند. برای کنترل خرابی آبشاری و فعال کردن انعطاف‌پذیری، هر میکروسرویس توسط Hystrix از فرآیندهای تماس گیرنده جدا می‌شود. نتیجه آن پس از اجرا می‌تواند در یک کش مبتنی بر حافظه ذخیره شود تا امکان دسترسی سریع‌تر برای درخواست‌های با تأخیر کم حیاتی فراهم شود.۶- میکروسرویس‌ها می توانند داده‌ها را در یک فروشگاه داده در طول فرآیند خود ذخیره یا از آن دریافت کنند.۷- میکروسرویس‌ها می‌توانند رویدادهایی را برای ردیابی فعالیت‌های کاربر یا سایر داده‌ها به خط لوله پردازش جریان برای پردازش بلادرنگ توصیه‌های شخصی یا پردازش دسته‌ای وظایف هوش تجاری ارسال کنند.۸- داده‌هایی که از خط لوله پردازش جریان خارج می‌شوند می‌توانند برای سایر فروشگاه‌های داده مانند AWS S3، Hadoop HDFS، Cassandra و غیره پایدار باشند.معماری‌های توصیف‌شده به ما کمک می‌کنند تا درکی کلی از نحوه سازمان‌دهی و کار با هم قطعات مختلف برای پخش جریانی ویدیوها به دست آوریم. با این حال، برای تجزیه و تحلیل در دسترس بودن و مقیاس پذیری معماری ها، باید بیشتر به هر جزء مهم بپردازیم تا ببینیم که چگونه تحت بارهای کاری مختلف عمل می کند. که در بخش بعدی به آن پرداخته خواهد شد.پارامترهای کیفی موجود در معماریNetflix۱ . در دسترس بودن بالاطبق تعریف، قابلیت دسترسی یا دسترس پذیری در اصطلاح یعنی داده و سرویس‌ها در هر زمانی که نیاز به آن داریم در دسترس باشند. میتوان به گونه‌های دیگر هم این عبارت را معنی کرد و این است که یک سیستم اطلاعاتی همواره در دسترس باشد و بتواند کار خودش را به بهترین شکل ممکن انجام دهد. در طراحی سیستم نتفلیکس، در دسترس بودن سرویسهای استریم بستگی به در دسترس بودن سرویس‌های Backend و سرورهای OCA دارد که فایلهای ویدئویی را نگه می‌دارند. هدف خدمات Backend دریافت لیستی از نزدیکترین OCA‌های سالم به یک کلاینت خاص است. بنابراین، در دسترس بودن آن به مؤلفههای مختلف مربوط به درخواست پخش بستگی دارد.۲ . تاخیر کمتأخیر سرویس‌های پخش بیشتر به این بستگی دارد که Play API چقدر میتواند فهرست OCA‌های سالم را حل کند و ارتباط مشتری با سرور OCA انتخابی چقدر است. Play API برای همیشه منتظر اجرای میکروسرویس نمی‌ماند، زیرا از دستورات Hystrix برای کنترل مدت زمانی استفاده می‌کند. با استفاده از حافظه پنهان، انجام این کار میتواند تأخیر قابل قبول را کنترل کند و همچنین خرابی‌های آبشاری برای خدمات بعدی را متوقف کند.اگر شبکه سرور OCA انتخابی فعلی خراب شود یا سرور بیش از حد بارگیری شود، کلاینت بلافاصله به سایر سرورهای OCA نزدیک با قابل اطمینان‌ترین اتصال شبکه سوئیچ می‌کند. همچنین می‌تواند کیفیت ویدیو را برای مطابقت با کیفیت شبکه کاهش دهد تا در صورت مشاهده کاهش در اتصال شبکه کاربر به مشکل نخورد.۳ . انعطافپذیریطراحی یک سیستم ابری با قابلیت بازیابی خود از خرابی‌ها یا قطعی‌ها، هدف اصلی نتفلیکس از روز شروع مهاجرت به ابرAWS بوده است. برای شناسایی و رفع خرابی‌ها، API Gateway Service Zuul دارای ویژگی‌های داخلی مانند تلاشهای مجدد تطبیقی است که تماس‌های همزمان را بهAPI Application محدود می‌کند. در عوض، Application API از دستورات Hystrix برای قطع کردن تماسهای میکروسرویس‌ها، توقف خرابی‌های آبشاری و جداسازی نقاط خرابی از دیگران استفاده می‌کند.تیم‌های فنی نتفلیکس نیز بهخاطر شیوه‌های مهندسی آشفتگی خود مشهور هستند. ایده این است که خطاهای شبه تصادفی را به محیط‌های تولید تزریق کنیم و راه حل‌هایی برای شناسایی، جداسازی و بازیابی خودکار چنین خرابی‌هایی ایجاد کنیم. خطاها میتوانند تاخیر در پاسخهای اجرای میکروسرویس‌ها، از بین بردن سرویسها، توقف سرورها یا نمونه‌ها و حتی از بین بردن کل زیرساخت یک منطقه باشد. نتفلیکس با معرفی هدفمند شکست‌های واقعی در یک محیط نظارت شده با ابزارهایی برای شناسایی و رفع چنین خرابی‌هایی، میتواند چنین ضعف‌هایی را قبل از ایجاد مشکلات بزرگتر به سرعت کشف کند.۴ . مقیاس پذیریمقیاس‌پذیری افقی نمونه‌های EC2 در Netflix توسط AWS Auto Scaling Service ارائه می‌شود. اگر حجم درخواست افزایش یابد، این سرویس AWS به طور خودکار فعال می‌شود. به طور خاص، نتفلیکس از Titus، یک پلتفرم مدیریت کانتینر منبع باز، برای اجرای حدود 3 میلیون کانتینر در هفته استفاده می‌کند. علاوه بر این، Titus اجازه میدهد تا کانتینرها در چند منطقه در سراسر قاره‌های مختلف در سراسر جهان حرکت کنند. روش دیگری که استفاده می‌کند، پیادهسازی microservice است که با اجازه دادن به اجرای موازی وظایف، مقیاس‌پذیری را افزایش می‌دهد. در نهایت، با استفاده از ابزارهایی مانند Cassandra و ElasticSearch نیز در دسترس بودن و مقیاسپذیری بالا را بدون هیچ نقطه شکستی ارائه میدهند.معماری Spotify و Apple Musicفناوری در چند سال گذشته تغییرات عظیمی را در هر صنعتی ایجاد کرده است، از جمله نحوه گوش دادن به موسیقی. طبق آمار Statista، انتظار می‌رود تعداد کاربران صنعت پخش موسیقی تا سال 2025 به 913.2 میلیون کاربر افزایش یابد. بنابراین، اگر ایده‌ای برای یک برنامه موسیقی نوآورانه دارید، ممکن است یک فرصت تجاری عالی برای کاوش در موسیقی امروزی باشد.پلتفرم‌های پخش‌ موسیقی زیادی مانند Spotify، Apple Music، Soundcloudو Tidal وجود دارد. در این بخش ما در مورد Spotify و Apple Musicبیشتر توضیح خواهیم داد. هر دو پلتفرم یک سرویس پخش موسیقی یکپارچه است که امکان دسترسی به میلیون‌ها آهنگ از هنرمندان سراسر جهان را فراهم می‌کند.تاریخچه Spotifyو Apple Musicدزدی محتوا به طور جدی صنعت هنرهای نمایشی و موسیقی را تحت تأثیر قرار داده است. Spotifyو Apple Music با هدف اصلی حذف توزیع غیرقانونی، از طریق دادن بستری به اجراکنندگان برای میزبانی آثارشان و دریافت حق امتیاز برای آن، تأسیس شد.ژوئن 2017، Spotify، 144 میلیون کاربر فعال ماهانه داشت. تا سه ماهه دوم سال 2019 تقریباً دو برابر شد و به 232 میلیون کاربر فعال ماهانه رسید. از این تعداد، کل مشترکین پریمیوم Spotifyبه 100 میلیون یا بیشترمی‌رسد. در زمان نگارش این تحقیق، Spotify، ۴۰ درصد از صنعت پخش موسیقی جهانی را در اختیار دارد.همچنین علاقه‌ی شرکت اپل به صنعت موسیقی از دیرباز با ارائه‌ی برند iPod و سرویس موسیقی اپل در قالبiTunes، مشخص بوده است. اپل یکی از اولین شرکت‌هایی بود که وارد این صنعت پرسود با پتانسیل بالا شد. اما با افول خرید iPod و کاهش استقبال از سرویس موسیقی اپل که در قالب iTunes ارائه می‌شود، در مقابل محبوبیت سرویس‌های استریم موسیقی چون اسپاتیفای، سال گذشته اپل را واداشت تا کمپانی بیتس را از آن خود کند.در مورد این سوال که "چند آهنگ در Spotify وجود دارد؟" ، برنامه Spotifyمیزبان 50 میلیون آهنگ است و شنوندگان به طور متوسط 25 ساعت در ماه در برنامه صرف می‌کنند. ارزش کل تجارت Spotify به 26.5 میلیارد دلار رسیده است. حداقل می‌توان گفت، ارزش خالص Spotifyخیره کننده است و می‌توان گفت اسپاتیفای پرچم‌دار این صنعت است.برنامه پخش موسیقی چگونه کار می‌کند؟هر دو برنامه‌ی Spotifyو Apple Music موسیقی خود را در چندین سرور ذخیره می‌کنند. بنابراین وقتی کاربر می‌خواهد به آهنگی گوش دهد، برنامه تلفن همراه از پشتیبان درخواست می‌کند تا داده‌ها را واکشی کند. و بک‌اند تمام کارهای سنگین را برای یافتن آهنگ‌ها از سرورها و ارسال آنها به دستگاه انجام می‌دهد. منطق سرور همچنین تمامی وظایف دیگر مانند کار با پایگاه داده‌ها، احراز هویت کاربر، جستجو، پیشنهاد هنرمندان/آلبوم‌ها و به روز رسانی کتابخانه را انجام می‌دهد.این روش استریم نیازی به بارگیری فایل‌ها در دستگاه‌ها ندارد. در عوض، موسیقی در بسته‌های کوچک از طریق اینترنت تحویل داده می‌شود و در بافر دستگاه ذخیره می‌شود. بسته‌ها برای جلوگیری از تأخیر بین رویدادهای ارسال و دریافت کوچک نگه داشته می‌شوند، بنابراین موسیقی فوراً پخش می‌شود. در زیر اساسی ترین معماری برنامه پخش موسیقی آورده شده است:الزامات عملکردی سیستم پخش موسیقی دانلود موسیقی (حداکثر 10000 آهنگ در حداکثر 5 دستگاه تحت یک حساب کاربری) آهنگ‌های جدید را کشف کند و سیستم یک لیست پخش مناسب ایجاد شده توسط الگوریتم ارائه ‌دهد. کاربر فعالیت‌های دوستان خود را ببیند که چه موسیقی را دوست دارند و به چه چیزهایی گوش می‌دهند. کاربر می‌تواند موسیقی را از طریق پلتفرم دیگر با دوستان خود به اشتراک بگذارد. اشعار موسیقی را ارائه دهد. برای همه انواع دستگاه (موبایل، تبلت، رایانه شخصی، پخش کننده وب، تلویزیون، صدای ماشین، ساعت هوشمند، کنسول بازی، نمایشگر هوشمند و غیره) قابل استفاده باشد. کاربران می‌توانند سابقه شنیداری خود را بررسی کنند. کاربران می‌توانند آهنگی را که می‌خواهند به آن گوش دهند جستجو کنند. مرتب سازی و فیلتر کردن آهنگ دنبال کردن هنرمندانخصوصیات عملکردی پیشرفتهدر اینجا چند ویژگی پیشرفته وجود دارد که می‌توانید برای برجسته‌تر کردن برنامه پخش موسیقی اضافه کرد: (که برنامه Spotify همه این کارها را انجام داده است) توصیه شخصی مبتنی بر هوش مصنوعی: تعبیه ویژگی هوش مصنوعی بر رفتار و اولویت کاربر در موسیقی برای ارائه توصیه‌های شخصی. آهنگ‌ها، آلبوم‌ها و حتی پادکست‌هایی را پیشنهاد می‌کند که کاربر ممکن است بر اساس مشاهداتی مانند تاریخچه گوش دادن کاربر، موقعیت جغرافیایی و غیره دوست داشته باشد. کشف موسیقی جدید برای کاربر: این یکی از هیجان انگیزترین ویژگی‌های برنامه‌های موسیقی پیشرو است. به کاربران این امکان را می‌دهد که موسیقی‌های جدیدی را کشف کنند. به عنوان مثال، Spotify دارای لیست‌های پخش برای تمرکز، تمرینات، هوای بارانی، خواب، مدیتیشن یا یوگا است. حالت آفلاین: دسترسی آفلاین به کاربران این امکان را می‌دهد که موسیقی مورد علاقه خود را بر روی دستگاه خود دانلود کرده و به صورت آفلاین به آن گوش دهند. اکثرا این در نسخه پولی یا پریمیوم برنامه اضافه می‌شود. اشتراک گذاری اجتماعی: هنگامی که کاربران با حساب‌های رسانه‌های اجتماعی خود وارد برنامه می‌شوند، فعال‌کردن اشتراک گذاری اجتماعی آسان تر است. علاقه مندان به موسیقی دوست دارند ترجیحات خود را با دوستان، خانواده یا حتی در رسانه‌های اجتماعی خود به اشتراک بگذارند. با این حال، اشتراک اجتماعی باید تنها با یک یا دو کلیک برای کاربران قابل دستیابی باشد.الزامات غیر عملکردی سیستم قابلیت استفاده قابلیت اطمینان عملکرد خوب زمان تاخیر کمتخمین مقیاس پایگاه‌های کاربر فعال = 365 میلیون پایگاه کاربران حق بیمه فعال = 158 میلیون کیفیت پایین = 3 مگابایت در هر آهنگ کیفیت بالا = 10 مگابایت در هر آهنگ می توانید تا 10000 آهنگ را دانلود کنید پشتیبانی از بیش از 30 زبان روزانه بیش از 60000 آهنگ آپلود می‌شود سالانه 8 میلیون آهنگ ساز 8هزار هنرمند فعالنقاط فروش جهانییک روش علمی برای اندازه‌گیری همان امتیاز خالص پروموتر (NPS) است. تمایل مشتریان به ارجاع بیشتر خدمات را ارزیابی می‌کند.از این آمار درک می‌کنیم که در این صنعت Spotify کارایی خوبی دارد و با تحقیق برای علت آن به این تنیجه رسیدیم که دلیل بزرگ این اختلاف، توانایی Spotify برای سفارشی کردن لیست پخش به دلخواه هر کاربر است. با اینکه این «کشف لیست‌های پخش» یکی از محبوب‌ترین طرفداران است. آنها قبلاً به صورت هفتگی برای هر کاربر ارسال می شدند، اما به لطف محبوبیت آنها،Spotify سرمایه گذاری زیادی کرد و شروع به اشتراک گذاری منظم لیست کشف لیست‌های پخش با کاربران Spotify کرد.اما Spotify چگونه می‌داند که کدام آهنگ‌ها را به شما ارائه دهد؟ اینجاست که الگوریتم‌ها وارد می‌شوند. از دو مدل زیر برای تنظیم آهنگ‌ها استفاده می‌کند. فیلتر مشارکتی - رفتار کاربر را در حین تجزیه و تحلیل ترجیحات آهنگ کالیبره می‌کند. در مثال زیر، تد و رندی را با انتخاب‌هایشان از آهنگ‌های فهرست شده در جدول داریم. می‌توانیم ببینیم که هر دو قبلا به آهنگ‌های A و B گوش داده‌اند. Spotify این را به احتمال زیاد تد می‌خواهد آهنگ D و رندی آهنگ Cرا بشنود و به این ترتیب توصیه آهنگ شروع می‌شود. البته زمانی که حجم نمونه جمعیت کاربر به میلیون ها نفر باشد، محاسبات سطح بالایی را شامل می‌شود. پردازش زبان طبیعی - برای اجرای تجزیه و تحلیل، Spotifyبر روی یک مدل NLP متمرکز است. خزنده‌های آن اینترنت را برای نشانه‌های متنی مرتبط با آهنگ‌هایی مانند موارد ذکر شده در وبلاگ‌ها، مقالات خبری و همچنین متا داده‌ها اسکن می‌کنند. این برنامه صفت‌ها را به نمرات طبقه بندی می‌کند و سپس همان را به آهنگ‌ها می‌دهد. بر اساس مجموع انباشته، یک آهنگ به دلیل توصیه به دیگران، بر اساس لیست‌های پخش ذخیره شده، در فهرست بالاتر می‌رود.نقش رفتار کاربر در چنین برنامه‌هابسیاری از سیستم‌های آنلاین که نیازهای روزانه انسان‌ها را برآورده می‌کنند، نیاز به مطالعه رفتار کاربر دارند. به عنوان مثال، یک سایت خبری یا یک سایت موسیقی باید رفتار کاربر را در مقایسه با یک بانک یا یک سایت مسافرتی با انتقاد بیشتری بداند. کاربر ممکن است بخواهد در طول صبح زود هنگام رانندگی به محل کار به اخبار یا موسیقی مورد علاقه گوش دهد، یا بخواهد در طول تمرین بعد از ظهر خود ویدیوهای مورد علاقه خود را پخش کند. خلق و خو کاربر چندین بار در روز تغییر می‌کند و از این رو سیستم باید به گونه‌ای طراحی شود که به همان حالت پاسخ دهد. دانستن این اطلاعات به پخش کننده موسیقی کمک می‌کند تا تجربه را شخصی کند.در دنیای امروزی، مردم در هر سنی، به موسیقی نیاز دارند. پلتفرم‌های پخش موسیقی می‌خواهند مفید باشد، استفاده از آن آسان باشد، مجموعه‌ای از آهنگ‌ها را داشته باشد، به سرعت چیزی را که کاربر می‌خواهد گوش دهد را پیشنهاد دهد، به سلیقه و خلق و خوی کاربر حساس باشد و موسیقی مناسبی پخش کند.برنامه‌های پخش موسیقی در قالب‌های مختلف وجود دارند و گزینه‌های مختلف گوش دادن را ارائه می‌دهند. با این حال، محبوب ترین سرویس‌های موسیقی به سه دسته رایج تقسیم می‌شوند: کتابخانه‌های موسیقی(Music libraries)برنامه‌های محبوب پخش موسیقی مانند Spotify و Apple Music در این دسته قرار می‌گیرند. در اینجا، موسیقی در کتابخانه‌های مبتنی بر سرور ذخیره می‌شود و کاربران دسترسی نامحدودی به موسیقی دارند، اما تحت شرایط مالک برنامه.فضای ذخیره ابری (Cloud Storage)این دسته از برنامه‌ها فضای ابری را برای ذخیره، سازماندهی و مدیریت موسیقی خود به کاربران ارائه می‌دهند. کاربران می‌توانند موسیقی را از هر کجا و هر زمان که دوست دارند پخش کنند. AudioBox یک نمونه محبوب از پخش کننده موسیقی ابری است. ایستگاه رادیویی (Radio Stations)برنامه‌های رادیویی موسیقی به کاربران امکان می‌دهند ایستگاه‌های رادیویی آنلاین مختلفی را که بر اساس مضامین خاصی مانند ژانرها، فهرست‌های پخش هنرمند محور، حالات و موارد دیگر مرتب شده‌اند، پخش کنند. چنین برنامه‌هایی همچنین نتایج جستجو را بر اساس نیازهای شما فیلتر می‌کنند، ایستگاه‌های رادیویی را پیشنهاد می‌کنند که ممکن است دوست داشته باشید، و راهی عالی برای کشف موسیقی جدید هستند.مرحله طراحی UI/UXطراحی UI/UX برنامه یکی از عوامل مهم موفقیت در این صنعت است. طراحی کاربرپسند، جذاب و مدرن به جذب و حفظ کاربران کمک می‌کند. بنابراین، طراحان UI/UX نقش بسیار مهمی در این برنامه‌ها دارند. برای مثال حقوق سالیانه برای هر طراح در Spotify برابر با ۱۳۵هزار دلار است. این نکته پیشرفت شرکت Spotify نسبت به سایر رقبا است از این رو در ادامه تمرکز ما هم به نحوه طراحی و نحوه مدیریت این تیم‌ها است.بازبینی سیستم‌های طراحی در Spotifyدر نوامبر ۲۰۲۱، تیم Spotify، رویکرد جدید برای طراحی سیستم‌ها را معرفی کرده است که به Encore مشهور است. نکته جالب در مورد Encore این است که فقط یک چیز نیست: در واقع یک خانواده از سیستم‌های طراحی است که توسط تیم‌های توزیع شده مدیریت می‌شود. در این بخش، انگیزه ایجاد Encore، نحوه ساختار آن و تفاوت آن با آنچه قبلاً امتحان شده است را به اشتراک می‌گذاریم.چگونه باید طراحی سیستم‌ها را در اسپاتیفای انجام دهیم؟ این سوالی است که اسپاتیفای چندین بار از طریق رویکردهای مختلف سعی کرده‌ به آن پاسخ دهد. در روزهای اولیه اسپاتیفای، طراحی خاصی برای سیستم وجود نداشت- برای اولین بار همه چیز را می‌ساختند. هنگامی که در سال 2009 برنامه تلفن همراه را راه اندازی کردند، استانداردها یا الگوهای مشترک کمی وجود داشت، و تجربه کاربری اسپاتیفای به طور فزاینده‌ای ناسازگار شد. این رانش تا سال 2013 ادامه یافت، زمانی که اسپاتیفای اولین تلاش واقعی خود را برای تراز کردن طراحی بصری در سراسر پلتفرم‌های خود آغاز کرد. این یک تلاش بزرگ بود، و تاثیر زیادی داشت. سپس در سال‌های 2014-2015، تیم برند و خلاق هویت برند اسپاتیفای را به‌طور عمده‌ای تازه کردند. برای انجام این کار، اسپاتیفای یک تیم با طراحان ماهر راه اندازی کرد تا یک سیستم طراحی برای اسپاتیفای ایجاد کنند، نه اینکه با آن مانند یک پروژه یکباره رفتار کنند. خروجی این تیم، سیستم طراحی GLUE نامیده شد که با نام Global Language Unified Experience شناخته می‌شود.سیستم طراحی GLUE از بسیاری جهات موفقیت آمیز بود. تیم ظاهر و احساس برنامه را تازه کرد، بسیاری از اجزا را در تلفن همراه و دسکتاپ استاندارد کرد و از تعداد انگشت شماری از افراد به بیش از 30 مهندس و طراح تمام وقت تبدیل شد. اما یک نکته وجود داشت GLUE یک تیم واحد و متمرکز بود. همچنین این تیم تبدیل به به یک گلوگاه شد. در سال 2018، اسپاتیفای به رشد و سرعت خود ادامه داد. در سال 2018، اسپاتیفای به رشد خود ادامه داد و به سرعت ما 200 طراح داشتیم. 2000 مهندس و 45 پلتفرم مختلف. اکنون اسپاتیفای برای اتومبیل‌ها، ساعت‌های هوشمند، بلندگوها و حتی یخچال‌های هوشمند نیز طراحی شده است. این تا حدی به دلیل یک استراتژی جدید شرکت بود. اسپاتیفای این امکان را برای شنوندگان فراهم کرده تا در هر کجا دسترسی داشته باشند.مسئله این بود که تیم GLUE تا این لحظه منحل شده بود و هیچ کس به طور فعال سیستم طراحی GLUE را به جلو سوق نداد. این زمانی بود که ما وارد همان فاز اولیه سیستم‌های طراحی اسپاتیفای شدیم. به عنوان مثال، تیمی در نیویورک شروع به کار بر روی یک سیستم طراحی برای وب کردند. همچنین تیمی در استکهلم سیستم متفاوتی را برای خود طراحی کردند، و این یعنی مشکل در یکپارچه‌سازی رخ خواهد افتاد. اسپاتیفای کارهای بزرگ زیادی رویGLUE انجام داده است، و هنوز در بخش‌هایی از این سیستم‌ها استفاده می‌کنند. اما این رویکرد بسیار غیرمتمرکز و ناپایدار بود. در یک نقطه، اسپاتیفای 22 سیستم طراحی مختلف را که در اطراف شناور بودند داشتند.اسپاتیفای واقعاً به یک سیستم طراحی یکپارچه و مفید نیاز داشت - اما ما می دانستیم که تیم متمرکزی مانند GLUE احتمالاً کار نخواهد کرد. بنابراین، در سال 2018، تلاش جدیدی را برای ایجاد یک سیستم طراحی برای شرکت آغاز شد.این بار، می‌خواستند سیستم طراحی خود را طراحی کنند، مهمتر از همه، سیستمی می‌خواستند که با فرهنگ خودمختاری اسپاتیفای مطابقت داشته باشد - سیستمی که بتواند در چندین پلتفرم مقیاس‌پذیر باشد و از موارد استفاده کند. که خروجی این تلاش به Encore رسید. چیزی که در مورد Encore متفاوت است این است که یک چیز یکپارچه نیست. این چارچوبی است که سیستم‌های طراحی موجود اسپاتیفای را تحت یک نام تجاری قرار می‌دهد.چندین سیستم طراحی در داخلEncore وجود دارد که هر کدام توسط تیم متفاوتی در اطراف شرکت مدیریت می‌شوند. و در حالی که این تیم‌ها سیستم‌های مختلف را حفظ می‌کنند، هر کسی که محصولاتی را در اسپاتیفای بسازد می‌تواند مشارکت داشته باشد.سیستم‌های مختلف با هم متصل هستند زیرا همگی با استفاده از نشانه‌های طراحی ساخته شده‌اند و در یک محیطی زندگی می‌کنند و ساختار مشابهی که توسط چارچوب Encore تعریف شده است را دنبال می‌کنند. قبلاً 22 سیستم طراحی به هم پصل نشده داشتیم. اکنون، ما هنوز چندین سیستم داریم، اما همه آنها به هم متصل هستند و زیر یک چتر قرار دارند.در مرکز، ما Encore Foundationرا داریم. اینجا جایی است که چیزهایی مانند رنگ، سبک‌ها، حرکت، فاصله، به‌علاوه دستورالعمل‌هایی برای نوشتن و دسترسی را نگه می‌داریم. همچنین جایی است که نشانه‌های طراحی ما زندگی می‌کنند. اینها چیزهایی هستند که همه باید از آن استفاده کنند - این چیزی است که اسپاتیفای را نسبت به سایر رقبا قویتر می‌کند.در مرحله بعد، Encore Web را داریم. این همه چیزهایی را که در سیستم‌های طراحی وب یافت می‌شود ارائه می‌دهد: دکمه‌ها، دیالوگ‌ها، کنترل‌های فرم‌ها و موارد دیگر. این مؤلفه‌ها را می‌توان در هر چیزی که با استفاده از فناوری وب ساخته شده است استفاده کرد. این مرحله دارای منابع مشترک برای پلتفرم‌های مبتنی بر وب است، اما شامل همه چیز از Foundation نیز می‌شود. کامپوننت‌ها با استفاده از توکن‌ها ساخته می‌شوند و از الگوها و دستورالعمل‌های تعریف شده در Foundation پیروی می‌کنند. بنابراین سیستم‌ها چیزهای مستقلی نیستند: آنها به هم متصل هستند.مرحله بعد، Encore Mobile است که مشابه Encore Webاست و این مکان، مکانی برای اجزای مشترکی است که در طراحی برنامه تلفن همراه به اشتراک گذاشته می‌شود.در این لایه بعدی، Encoreهمچنین حاوی چیزی است که ما آن را " local design systems" می‌نامیم. سیستم‌های محلی مکانی برای نگهداری عناصر طراحی هستند که برای محصولات یا مخاطبان خاص طراحی شده‌اند. برخی از اجزای وب فقط در تجربیات هنرمندان یا پادکست‌ها استفاده می‌شوند. با چارچوب Encore، می‌توانیم عناصر طراحی سفارشی را در یک سیستم محلی نگه داریم تا همه تیم‌هایی که روی Spotify for Artists کار می‌کنند بتوانند آنها را به اشتراک بگذارند. این یک ایده مشابه در سمت تلفن همراه نیز است. تیم‌های زیادی روی برنامه اصلی Spotify کار می‌کنند، بنابراین نیاز زیادی به اجزا و الگوهای مشترک تلفن همراه وجود دارد.به طور خلاصه، هر یک از دایره‌های کوچک بالا یک سیستم طراحی کامل است که:دارای طراحی، کد و اسناد استبر روی سیستم‌های دیگر نیز پیاده‌سازی می‌شودبه طور فعال توسط یک تیم اختصاصی نگهداری می‌شوددیدیم که با تکامل زبان بصری و استراتژی محصولSpotify، سیستم‌های طراحی نیز باید تغییر می‌کردند. همچنین فهمیدیم که چگونه یک سیستم طراحی برای همه یک‌اندازه نیست و باید متناسب با نیازهای شرکت تنظیم شود.مدل مدیریتی Spotifyبخش مهمی از موفقیت Spotify ناشی از رویکرد منحصر به فرد این شرکت برای سازماندهی حول کار برای افزایش چابکی تیم است. همانطور که تیم‌های مهندسی Spotify در مسیر پیشرفت چابکی حرکت کردند، تجربیات خود را مستند کردند، آن را با جهان به اشتراک گذاشتند و در نهایت بر نحوه سازماندهی بسیاری از شرکت‌های فناوری در اطراف کار تأثیر گذاشتند. اکنون به عنوان مدل Spotify شناخته می‌شود. افراد تصمیم‌گیرنده در کمپانی اسپاتیفای می‌خواستند تیم‌ها را سریع‌تر کنند و توسعه محصول نرم‌افزاری خود را سرعت ببخشند و البته لازم داشتند تا همه این دستاوردها را با حداقل آسیب و هزینه به دست بیاورند. مدل Spotify یک رویکرد مردم محور و مستقل برای مقیاس‌بندی چابک است که بر اهمیت فرهنگ و شبکه تأکید دارد. این به Spotify و سایر سازمان‌ها کمک کرده تا با تمرکز بر استقلال، ارتباطات، مسئولیت‌پذیری و کیفیت، نوآوری و بهره‌وری را افزایش دهند. مدل Spotify یک چارچوب نیست، زیرا نمایانگر دیدگاه Spotify در مورد مقیاس‌بندی از منظر فنی و فرهنگی است. این نمونه‌ای از سازماندهی چندین تیم در یک سازمان توسعه محصول است و بر نیاز به فرهنگ و شبکه تاکید می‌کند.مدل Spotify برای اولین بار در سال 2012 به دنیا معرفی شد، زمانی که هنریک کنیبرگ و آندرس ایوارسون وایت پیپر Scaling Agile @ Spotify را منتشر کردند. از آن زمان، مدل Spotify سر و صدای زیادی ایجاد کرد و در فضای چابک به بحث داغی تبدیل شد. بخشی از جذابیت آن این است که به جای پیروی از یک مجموعه خاص از شیوه‌ها، بر سازماندهی حول کار متمرکز است. در چارچوب‌های مقیاس‌بندی سنتی، شیوه‌های خاص (مثلاً استندآپ‌های روزانه) نحوه اجرای چارچوب است، در حالی که مدل Spotify بر نحوه ساختار سازمانی برای فعال کردن چابکی تمرکز دارد. مدل Spotify استقلال تیم را تقویت می‌کند، به طوری که هر تیم چارچوب خود را انتخاب می‌کند (به عنوان مثال Scrum، Kanban، Scrumban و غیره).این مدل همراه با خود دو موفقیت همراه داشت:کاهش بروکراسی و جلسات فرسایشیخود پیشبرندگی و استقلال بیشتر تیم‌هاتوجه داشته باشید که بسیاری از سازمان‌ها و شرکت‌ها هم در پی آن هستند تا مزایا و ویژگی‌هایی مدل اسپاتیفای را در سازمان خود داشته باشند اما در این مسیر برخی از سازمان‌ها موفق شدند و برخی نیز نتوانستند بهبودی در نتایج کاری خود احساس کنند. چون مانند هر روش دیگری، این مدل هم علاوه بر دستورالعمل‌ها و قوانین به فرهنگ و ساختار خاص خودش نیاز دارد. مدل اسپاتیفای ساده است، اما محیطی که در آن پیاده‌سازی می‌شود پیچیدگی‌های زیادی دارد.عناصر کلیدی مدل Spotifyمدل Spotify حول محور سادگی است. هنگامی که Spotify شروع به سازماندهی پیرامون کار خود کرد، تعدادی از عناصر مهم را در مورد نحوه ساختار افراد و تیم‌ها شناسایی کردند.جوخه‌ها (Squads)مشابه تیم اسکرام، جوخه‌ها تیم‌هایی با عملکرد متقابل و مستقل هستند (معمولاً 6 تا 12 نفر) که بر روی یک ویژگی تمرکز می‌کنند. هر تیم یک ماموریت منحصر به فرد دارد که کار آنها را هدایت می‌کند، یک مربی چابک برای پشتیبانی و یک مالک محصول برای راهنمایی.قبایل (Tribes)هنگامی که چندین جوخه در یک منطقه ویژگی با یکدیگر هماهنگ می‌شوند، یک قبیله را تشکیل می‌دهند. قبیله‌ها به ایجاد هم‌ترازی در میان جوخه‌ها کمک می‌کنند و معمولاً از 40 تا 150 نفر تشکیل می‌شوند تا هم‌ترازی را حفظ کنند. هر قبیله یک رهبر قبیله دارد که مسئول کمک به هماهنگی بین جوخه‌ها و تشویق همکاری است.فصل (Chapter)حتی اگر جوخه‌ها مستقل هستند، مهم است که متخصصان با بهترین شیوه‌ها هماهنگ شوند. فصل‌ها خانواده‌ای هستند که هر متخصص دارد و به حفظ استانداردهای مهندسی در یک رشته کمک می‌کند. فصل‌ها معمولا‌ توسط یک رهبر ارشد فناوری هدایت می‌شوند، که ممکن است مدیر اعضای تیم در آن فصل نیز باشد.انجمن صنفی (Guild)اعضای تیمی که به یک موضوع علاقه‌مند هستند می‌توانند یک انجمن را تشکیل دهند که اساساً یک جامعه مورد‌ علاقه است. هر کسی می‌تواند به یک انجمن بپیوندد و آنها کاملاً داوطلبانه هستند. در حالی که فصل‌ها به یک قبیله تعلق دارند، اصناف می‌توانند از قبیله‌های مختلف عبور کنند. هیچ رهبر رسمی یک انجمن وجود ندارد. در عوض، کسی دست خود را بلند می‌کند تا هماهنگ کننده صنف باشد و به گرد هم آوردن مردم کمک کند.هیئت سه نفره (Trio)کلمه Trio معروف به TPD Trio ترکیبی از Tribe Lead، Product lead و Design lead است. هر قبیله دارای یک Trio است تا اطمینان حاصل شود که هنگام کار بر روی مناطق ویژگی، همسویی مداوم بین این سه دیدگاه وجود دارد.اتحاد (Alliance)همانطور که سازمان‌ها مقیاس می‌شوند، گاهی اوقات چندین قبیله نیاز دارند تا برای دستیابی به یک هدف از نزدیک با یکدیگر همکاری کنند. اتحادها ترکیبی از سه قبیله (معمولاً سه یا بیشتر) هستند که با هم کار می‌کنند تا به قبیله‌های خود کمک کنند تا در هدفی بزرگتر از هر قبیله همکاری کنند.معماری Facebook و Twitterاین بخش به معماری شبکه‌های اجتماعی اختصاص یافته است که در آن، معماری دو نرم افزار Twitter و Facebook که هر کدام به سبک خود نوآوری‌های بسیاری برای این صنعت داشته اند بررسی می‌شود. قسمت هایی از معماری‌های این دو نرم افزار می تواند مانند یکدیگر پیاده سازی شود زیرا که هر دو تا حدودی در یک دسته بندی قرار دارند. ولی در عین حال هر کدام شامل ایده‌های جدیدی هستند که برای پیاده سازی این ایده‌ها نیاز به استفاده از تکنیک‌های معماری به خصوصی است که برخی از آن ترفندها خود یک ایده‌ی نوین در معماری نرم‌افزار به حساب می‌آیند.معماری Facebookیکی خصیصه‌های شبکه‌های اجتماعی مانند Facebook که معماری آن‌ها را نیز تحت تاثیر قرار می‌دهد رشد همیشگی آن‌ها است. به خصوص در سال‌های ابتدایی این نرم‌افزار با مورد توجه قرار گرفتن؛ تعداد کاربران با سرعت بسیار قابل توجهی افزایش می‌یابد و این مسئله نیازمند گرفتن تصمیمات مهمی در معماری می‌باشد. یکی از دلایل این موضوع این است که معمار نرم افزار باید در ابتدای توسعه نرم‌افزار که حتی محبوب شدن آن قطعی نیست، این سرعت رشد را در نظر داشته باشد و بسترهایی را برای مقیاس های وسیع تر آماده کند. همچنین در ابتدا باید با در نظر گرفتن هزینه‌ی پیاده سازی از تکنیک‌های ارزان تر استفاده کند و با افزایش تعداد کاربران آن، خلاقیت‌هایی به خرج داده تا بتواند نیازهای سیستم را در مقیاس وسیع‌تر پاسخ دهد؛ به طور مثال در ابتدای توسعه استفاده ازStack LAMP برای چنین برنامه‌هایی بسیار معمول می‌باشد. با توضیحات مطرح شده در معرفی قسمت‌های مهم این معماری به برخی تصمیمات که بعضا ممکن است قدیمی باشند ولی در مسیر پیشرفت Facebook نقش کلیدی داشتند نیز پرداخته می‌شود.تصمیمات ابتدایی در Facebookیکی از ایده‌های متفاوت Facebook که از دلایل محبوبیت آن می‌باشد پیشنهاد دادن کاربرانی است که دوست مشترک دارند، زیرا که احتمال این که دو نفر که دوست مشترک دارند، خود با یکدیگر دوست باشند زیاد است. این الگوریتم و مشکلی که برای Facebook در ابتدا ایجاد شد در ادامه توضیح داده خواهد شد. لازم به ذکر است که در ابتدا Facebook فقط مخصوص به دانشگاه ها و مدارس بوده و در سال‌های اول برای کنترل میزان مقیاس که خود از تصمیمات کسب‌وکار حساب می‌شود.الگوریتم پیدا کردن دوست مشترک به این صورت عمل می‌کند که اگر دو نفر که با یکدیگر در این برنامه دوست نیستند دوست‌هایشان با یکدیگر مقایسه می‌شود که اگر یکی بودند به آن دو نفر پیشنهاد دوستی می‌دهد. با چشم پوشی از جزئیات الگوریتم اگر بخواهد دوست ها را تا یک سطح بررسی کند، پیچیدگی آن از درجه O(n) خواهد بود و اگر بخواهیم تا سطح دوم این مسئله مورد بررسی قرار گرفته شود، با در نظر گرفتن این که تعداد دوست‌های هر کاربر n می‌باشد، پیچیدگی O(n^2) خواهد بود. قابل مشاهده است که میزان محاسبات این الگوریتم برای تعداد کاربران بالا بسیار زیاد خواهد بود.راه حلی که برای این مشکل گرفته شد این بود که در ابتدا به جای استفاده از یک پایگاه داده برای تمامی کاربران، از پایگاه‌ داده‌های متفاوتی برای هر مدرسه استفاده شود. این راه حل باعث می‌شود که تعداد دوست‌هایی که هر کاربر می‌تواند داشته باشد به درون یک مدرسه محدود شده و همچنین زمان محاسبه این الگوریتم نیاز نباشد برای تمامی کاربران برنامه این موضوع مورد محاسبه قرار گیرد. این تکنیک باعث به وجود آمدن محدودیت ارتباط بین مدارس می‌شود، اما میزان کارایی را به شدت افزایش می‌دهد. این یکی از مهمترین مشکلاتی بود که این برنامه در ابتدا برای حل آن نیاز به گرفتن تصمیمی در معماری پایگاه‌های داده شد.امروزه Facebook معماری‌های بسیار پیچیده‌تری برای مدیریت میزان اطلاعاتی که هر کاربر تولید می‌کند استفاده می‌کند، زیرا هر کاربر تولید کننده میزان قابل توجهی داده می‌باشد و تعداد کاربران فعال Facebook به چندصد میلیون نفر میرسد. کاربران اطلاعاتی مانند پست‌ها، کامنت‌ها، محل‌هایی که شما یا دوستانتان در واقعیت رفتید و ... را هر لحظه تولید می‌کنند که از چالش‌های اصلی Facebook ذخیره و مدیریت این داده‌ها می‌باشد. در ادامه به بررسی تکنیک‌ها و معماری‌هایی که در ذخیره و مدیریت این داده‌ها مورد استفاده قرار میگرید میپردازیم.سیستم پایدار چند زبانه(Polyglot Persistence System) چیست؟در توضیح ساده به سیستمی چندزبانه پایدار گفته می‌شود که از پایگاه‌های داده‌ی متفاوتی استفاده می‌کند که هر یک شامل مدل‌های متفاوت و ویژگی‌های مختلف خود می‌باشند که هر کدام نیازمندی‌های متفاوتی از کسب و کار را پاسخ می‌دهند.به طور مثال Casandra و Memcache به نیازهای متفاوتی در مقابل پایگاه‌های داده‌ی سنتی مانند Mysql Db پاسخ می‌دهند. اگر اولویت ما صرفا داشتن خواص ACID برای تراکنش‌ها باشد، پایگاه‌های داده سنتی بهترین گزینه هستند ولی به طور مثال اگر دسترسی به داده اولویت سیستم باشد، Cache ها بهتر به این نیاز پاسخ می‌دهند ولی در عین حال ممکن است در به وجود آوردن پایداری و جلوگیری از داده‌های تکراری ضعیف‌تر عمل کنند. که اگر در سیستم ما این موضوع اولویت نداشته باشد قطعا پایگاه‌های داده‌ی NoSql گزینه بهتری خواهند بود.به همین منظور Facebook برای براورده کردن نیازهای متفاوت کسب‌وکار از چندین پایگاه‌ داده‌ی متفاوت با مدل‌های مختلف استفاده می‌کند.پایگاه‌های داده رابطه‌ای در Facebookپایگاه‌داده MySql تکنولوژی اصلی است که Facebook با موتورهای مختلف از آن استفاده می‌کند. Facebook برای مدیریت اطلاعات اجتماعی کاربران از گراف‌های اجتماعی استفاده می‌کند. در ابتدا تیم توسعه از موتور MySql-InnoDb برای ذخیره داده‌ها استفاده کردند که پس از فشرده سازی و ذخیره‌ی داده‌ها، همچنان حجم آن‌ها بسیار زیاد بود و هزینه‌ی ذخیره سازی آن داده‌ها به شدت زیاد می‌شد. شکل 1 سرورهای Facebook را در زمان استفاده از این موتور نمایش می‌دهد.معماری استفاده از موتور InnoDb در شکل 2 نمایش داده شده است.موتور ذخیره‌سازی MyRocksبرای حل مشکل فضای ذخیره‌سازی اطلاعات اجتماعی تیم توسعه Facebook یک موتور پایگاه داده جدید MySql به نام MyRocks تولید کرد. با استفاده از این موتور جدید فضای ذخیره‌سازی مورد نیاز اطلاعات به میزان 50% کاهش پیدا کرد و باعث افزایش بازدهی در ذخیره اطلاعات شد. به مرور زمان Facebook پایگاه داده اطلاعات کاربران را از InnoDb به MyRocks انتقال داد. به علت یکی بودن هسته این دو پایگاه داده، این انتقال امری ساده بود. پس از انجام مهاجرت پایگاه داده تیم توسعه لازم بود که تست‌های ماندگاری داده انجام دهند تا از بدون خطا اجرا شدن تمامی کارایی‌ها اطمینان حاصل کنند. پس از انجام چندین ارزیابی کارای روی این مهاجرت پایگاه‌داده‌ای نتایج حاصل نشان می‌داده که به میزان 5/3 برابر میزان هر نسخه‌ها نسبت به داده‌های فشرده نشده اولیه در موتور جدید کاهش فضا داشته اند.پایگاه‌داده‌های WebScale Sqlپایگاه داده MySql بزرگترین تکنولوژی در زمینه ذخیره داده بوده و هر روزه توسط شرکت‌ها بسیار قدرتمندی مانند Google،Twitter ،Alibaba و LinkedIn در حال به پیشرفت می‌باشد. تیم‌های این شرکت‌ها بر روی پیشرفت الگوریتم‌های ذخیره‌سازی این تکنولوژی تحقیقات انجام می‌دهند. از آنجا که فیسبوک نیز یکی از بزرگترین توسعه‌های MySql را دارد، در یک مخزن مشترک با این شرکت‌های بزرگ در تحقیقات WebScale MySql شریک است و به توسعه آن کمک می‌کند.پایگاه ذخیره داده به صورت کلید-مقدار برای حافظه‌های Flash و RAM RocksDB در ابتدا در Facebook از یک دخیره‌سازی داده به نام RocksDB که به صورت کلید مقدار عمل می‌کند استفاده شد. این حالت از ذخیره سازی در مقابل MySql فوایدی داشت که از روی LevelDB که پیش‌تر توسط Google تولید شده است الهام گرفته شد. این پایگاه داده از سرعت بالایی برخوردار بود ولی امکان استفاده از replication و یا لایه ای از Sql در آن وجود نداشت، در حالی که تیم توسعه Facebook نیاز داشتند از این ویژگی‌ها در RocksDB استفاده کنند. این موضوع در نهایت منجر شد که پایگاه‌ داده‌ی MyRocks را توسعه دهند. این پایگاه داده متن‌باز بوده و RocksDB را به عنوان یک موتور برای MySql در خود داشت. یکی از نقاط قوت و دلایل استفاده از این تکنولوژی به علت نیاز به ذخیره میزان زیادی داده در یک پایگاه داده واحد می‌باشد.چند مورد از Use Case های این پایگاه داده به شرح زیر می‌باشد.پیاده‌سازی یک صف پیام که از تعداد زیاد نوشتن و پاک کردن را پشتیبانی می‌کند.قابلیت تشخیص درخواست‌های که نیاز دارند سریع‌تر و فوری تر به آن‌ها پاسخ داده شود.داشتن درخواست گراف جستجو که لازم است مجموعه داده‌ای را به صورت بلادرنگ اسکن کند. حافظه فوری توزیع شده - Memcache تکنولوژی Memcache از روزهای ابتدایی در Facebook مورد استفاده قرار گرفته است. این تکنولوژی حافظه‌ای غیر متمرکز است که به عنوان پوسته‌ای برای پایگاه‌داده عمل می‌کند که با داشتن سرعت پردازش بالاتر، به صورت میانگین پاسخ‌های کاربران را بسیار سریع‌تر پاسخ می‌دهد که باعث بهبود چشم‌گیر تجربه ‌کاربری می‌شود.این تکنولوژی توسط تمامی شرکت‌های بزرگ دنیا از جمله Google مورد استفاده قرار گرفته است. در ادامه، مدل مورد استفاده در معماری Facebook را بررسی می‌کنیم.مدل استفاده از Memcache توسط Facebookزمانی که کاربر مقدار یک متغیر را تغییر می‌دهد مقدار از Memcache پاک شده و در پایگاه داده ذخیره می‌شود. و اگر کاربر آن مقدار را درخواست کند بار اول از پایگاه داده داده را بدست آورده و در Memcache ذخیره می‌کند. در نتیجه دفعات بعدی فراخوانی‌ها همگی از Memcache خواهند بود. این رویکرد تا زمانی که پایگاه داده متمرکز باشد بسیار خوب و مطمئن کار خواهد کرد. اما زمانی که پایگاه داده غیر متمرکز باشد با مشکل eventual consistency مواجه خواهیم شد.1 . تعریف Eventual consistency: در حالتی که پایگاه داده غیر متمرکز است، به طور مثال یک نسخه در آسیا و یک نسخه در اروپا قرار دارد، وقتی مقدار داده در یک نسخه به روز رسانی می‌شود باید سلسله‌وار در همان لحظه پایگاه داده در نسخه‌های مناطق دیگر به‌روزرسانی شود. این فرایند نیازمند زمان کوتاهی خواهد بود تا تمامی نسخه‌ها در مناطق مختلف به مقدار واحد به‌روزرسانی شوند. به این اتفاق Eventual consistency گفته می‌شود.معماری Twitterسیستم Twitter یک سیستم شبکه اجتماعی آنلاین می‌باشد که کاربران می‌توانند پیام‌های کوتاهی را به اشتراک گذاشته و بخوانند که اصطلاحا به آن “Tweet” گفته می‌شود. در مفهوم و نگاه کردن به دید یک پروژه ساده به Twitter ممکن است آن را به صورت یکپارچه پیاده سازی کنند. اما با حجم داده این سیستم و نیازمندی‌های آن پیاده‌سازی به صورت یکپارچه ممکن نیست و پیچیدگی‌های بسیار زیادی ایجاد می‎کند. به همین دلیل Twitter به صورت میکروسرویس پیاده‌سازی می‌شود. در ادامه به برخی از نیازمندی‌های کارکردی و غیرکاکردی آن می‌پردازیم تا به تکنولوژی‌های به کار رفته و ایده‌هایی که پشت معماری آن بوده است برسیم.نیازمندی‌های کارکردی۱- کاربران می‌توانند Tweet های جدیدی بسازند یا آن‌ها را به اشتراک بگذارند.۲- حداکثر اندازه هر Tweet نمی‌تواند از 140 کاراکتر بیشتر باشد.۳- کاربر میتواند Tweet خود را پاک کند ولی نمی‌تواند آن را تغییر دهد یا اصلاح کند.۴- کاربر می‌تواند Tweet ها محبوب خود را علامت‌گذاری کند.۵- کاربر می‌تواند کاربر دیگری را دنبال و یا آن را غیرفعال کنند.۶- کاربران می‌توانند حساب کاربری خود را بسازند و یا پاک کنند.۷- پیام‌های tweet می‌توانند عکس و یا فیلم باشند.۸- سیستم ماینتورینگ باید بتواند بار، وضعیت سلامت و کارایی سیستم را تحت نظارت داشته باشد.نیازمندی‌های غیرکارکردی۱- نیازمندی مهم سیستم این است که بتواند به میزان خوبی در دسترس باشد. به این معنی که کاربر هر زمان که بخواهد بر روی سیستم خود بتواند پیام‌ها را بخواند.۲- ساختن Timeline برای کاربرها بدون در نظر گرفتن زمان کاربر باید حداکثر نیم ثانیه به طول انجامد.۳- سیستم به یکپارچگی بسیار بالایی نیاز ندارد. Eventual consistency قابل قبول است.۴- سیستم باید بتواند با افزایش تعداد کاربران و tweetها مقیاس‌پذیر باشد.۵- اطلاعات کاربر باید ماندگار باشد.میزان کاربران سیستم Twitter تا سال 2017 در شکل 6 قابل مشاهده است که با این آمار میزان مقیاس نیازمندی‌های ذکر شده به دست می‌آید.طراحی سطح بالای سرویس Twitterدر بررسی با دقت پایین و انتزاع بالا می‌توان سیستم را به 6 سرویس اصلی تقسیم کرد که هر کدام شامل چندین مایکروسرویس خواهند بود.۱- سرویس Tweet۲- سرویس User Timeline۳- سرویس Fanout۴- سرویس Home Timeline۵- سرویس گراف اجتماعی۶- سرویس جست‌وجودر شکل زیر معماری سیستم با سرویس‌های ذکر شده قابل مشاهده است.بررسی سرویس Tweetدر Twitter و تحلیل شبکه‌های اجتماعیسرویس tweet به این صورت عمل می‌کند که در ابتدا tweet مورد نظر را از کاربر دریافت کرده و آن را به سرویس جستجو و timeline دنبال کنندگان ارسال می‌کند. اطلاعات tweet مانند اطلاعات کاربر، اطلاعات tweet که شامل زمان و غیره می‌باشد را ذخیره می‌کند. براین این سرویس از چندین سرور در مسیر داده که به صورت توزیع شده قرار دارند استفاده می‌شود. در تصویر این سرویس قابل مشاهده می‌باشد.این سرویس اولین سرویس از 6 موردی می‌باشد که پیش‌تر ذکر شده است. اغلب سرویس‌های دیگر نیز از ساختاری مانند سرویس اول پیروی می‌کنند. که هر کدام پایگاه داده مخصوص به خود و چند سرور را شامل می‌شوند.تحلیلی از معماری شبکه اجتماعی آنلایندر نرم‌افزارها و سرویس‌های شبکه‌های اجتماعی معمولا تعداد کاربران فراوانی وجود دارد و روزبه‌روز رو به افزایش می‌باشند. همچنین در این شبکه‌ها موجودیت‌هایی مانند پیام‌ها، پست‌ها و رابطه‌هایی مانند دنبال کردن و دوستی وجود دارد. این روابط میان کاربران باعث به وجود آمدن گراف اجتماعی می‌شود که این گراف در شبکه‌های اجتماعی در لحظه در حال رشد و بزرگ شدن خواهد بود. و به طور معمول کار کردن و استفاده از شبکه‌های اجتماعی محدود به زمان خاص، مکان خاص و محدودیت مدت استفاده یا تعداد محتوایی که تولید می‌شود ندارد. از این جهت هر کاربر به یک ماشین مولد تولید موجودیت تبدیل خواهد شد.موجودیت‌هایی که کاربر تولید می‌کند همگی به صورت داده در می‌باشند، حال این داده ممکن است نیاز به ذخیره شدن و ایجاد موجودیت جدید داشته باشد و یا ممکن است نیاز به خواندن مقدار داشته باشد که در حالت دوم میزان زمان پاسخدهی اهمیت بالایی برای تجربه‌ی کاربری خواهد داشت.با وجود حجم بالای داده‌ای که در لحظه در این سیستم ذخیره می‌شود، جریان‌های داده و حجم درخواست‌ها به سیستم بسیار زیاد خواهد بود و باید برای حفظ کارایی سیستم راه حل‌های معماری برای این نیازمندی به وجود آید. در Facebook وTwitter بسیار بالایی به بهینه سازی پایگاه‌های داده و استفاده از ابزارها و برنامه‌هایی برای مدیریت جریان‌های مختلف داده می‌باشد. همچنین در کنار براورده کردن نیازهای کاربران، لازم است نیازهای بیزینسی مانند گرفتن لاگ و تحلیل اطلاعات کاربران نیز انجام شود. از این رو این برنامه‌ها نیاز دارند در قسمت پایگاه داده از معماری بسیار قوی‌ای استفاده کنند و تمرکزی بیشتری بر روی این بخش از نرم‌افزار داشته باشند. پیش تر به برخی بخش‌های پایگاه داده Facebook پرداخته شد و در ادامه نیز به روش‌ها و ابزارهایی که در حل مشکلات ازدیاد داده‌ها و مقیاس بالای این برنامه‌ها به کار گرفته شده است می‌پردازیم.نرم‌افزار Apache Hadoopبه وضوح Facebook شامل میزان بسیار زیادی داده می‌باشد که در هر لحظه با سرعت بالایی در حال افزایش می‌باشند. مدیریت این داده‌ها نیاز به زیرساخت منحصربه‌فردی دارد. Facebook برای مدیریت چنین جریانی از داده‌ها از Apache Hadoop استفاده می‌کند؛ که ابزاری متن‌باز برای ذخیره، مدیریت و به دست آوردن داده‌های آماری از پایگاه داده‌های غیر متمرکز Facebook مورد استفاده قرار گرفته است. در کنار آن ابزارهای دیگری مانند Appache Hive، HBase و Apache Thrift می‌باشند که می‌توانند در کنترل داده مورد استفاده قرار بگیرند.مانند تکنولوژی ‌های دیگر Facebook این مورد نیز نسخه‌ی انحصاری خود را در این شرکت دارد و می‌توان گفت که Facebook بزرگترین خوشه از این تکنولوژی را پیاده‌سازی کرده است که حدود 2 پتابایت داده در آن دارد. برای پیام‌ Facebook از یک پایگاه‌داده غیر متمرکز به نام HBase استفاده می‌کند که جریان داده را در نهایت به Hadoop انتقال می‌دهد.پیاده سازی HBase در Facebookابزار HBase یک پایگاه داده متن‌باز می‌باشد که به خودی خود غیر رابطه‌ای حساب می‌شود و توسط شرکت Google توسعه داده شده است.در بخش ارسال پیام در ابتدا از HBase استفاده شده است که روی یک لایه از HDFS سوار می‌باشد. این تکنولوژی به علت داشتن سرعت بالا در گذردهی پیام‌ها و تاخیر پایین توسط تیم معماری Facebook انتخاب شده است. از ویژگی‌های دیگر آن می‌توان به دسترس‌پذیری بالا، مقیاس پذیری و ماندگاری بالا اشاره کرد. در حال حاضر سیستم پیامرسانی از RocksDB که پیشتر معرفی شد برای ذخیره پیام‌ها استفاده می‌کند.همچنین از HBase در سرویس‌های دیگری مانند سیستم مانیتورینگ داخلی، ایندکس کردن جستجو، جریان داده و data scraping استفاده می‌شود. ساختار کلی این سرویس در شکل 3 نمایش داده شده است.مهاجرت پایگاه داده سرویس پیامرسان از HBase به RocksDB باعث شد بتواند زیرساخت بهتری برای افزایش بهره‌وری استفاده حافظه‌های فلش برقرار شود و در مقابل حافظه‌های دیسکی سرعت ذخیره اطلاعات برای کاربران افزایش یابد. همچنین توپولوژی ساخته شده به دست Facebook با نحوه عملکرد مراکز داده و ذخیره داده در آن‌‌ها مناسب تر از پیش می‌باشد.تکنولوژی Apache Cassandraسیستم Apache Cassandra یک مرکز ذخیره داده توزیع شده در Facebook برای سرویس جستجوی درون پیام‌های ورودی می‌باشد. Cassandra نوشته شده است تا داده ساختاریافته را مدیریت کند و آن را به صورتی که هیچ تک‌نقطه خرابی برای آن وجود نداشته باشد و آن را تا مقیاس‌های بسیار بالاتری در سرورهای مختلف توزیع شده گسترش دهد.تکنولوژیApache Hiveاین برنامه یک نرم‌افزار برای کنترل مراکز داده از جهت درخواست داده و محاسبات آن است که بر روی یک لایه از Hadoop سوار می‌باشد. در Facebook برای انجام محاسبات و تحلیل‌ها بر روی پتابایت‌ها داده مورد استفاده قرار می‌گیرد. ای محاسبات به منظور به دست آوردن یک براورد از رفتارهای کاربر انجام می‌شود. به شرکت کمک می‌کند تا بتواند سرویس‌های جدیدی توسعه داده و رفتار کاربر را برای شبکه تبلیغات Facebook به ‌دست آورد.این تکنولوژی درون Facebook کوئری‌های Sql را تبدیل به ترتیبی برای مدل Map-reduce می‌کند و سپس بر روی Hadoop اجرا می‌شوند. از ویژگی‌های دیگر آن می‌توان به رابط کاربری قابل برنامه نویسی و پیاده سازی و استفاده فرمت‌های عمومی داده‌ها برای ذخیره داده‌های کنترلی (Metadata) نام برد.پایگاه داده توزیع شده PrestoDBنرم‌افزار PrestoDB یک نرم‌افزار متن‌باز مدیریت پایگاه‌داده رابطه‌ای می‌باشد. که هدف اصلی استفاده از آن اجرای کوئری‌های Sql برای حجم بسیار بالای داده می‌باشد. یک کوئری Presto می‌تواند شامل داده ترکیب شده از چندین منبع مختلف باشد و قابلیت تحلیل بر روی داده‌های عظیم از منابع مختلف را فراهم کند.در Facebook از PrestoDB برای پردازش داده‌ها به واسطه یک پایپلاین عظیم با حجم کار بالا در مرکز Hive استفاده می‌شود. همچنین از آن برای انجام تحلیل‌های دستی با تاخیر کم و گذردهی بالا استفاده می‌شود. از این نرم‌افزار به جز Facebook در شرکت‌های بزرگ دیگری مانند Netflix و Walmart نیز استفاده می‌شود. شکل 4 نشان دهنده معماری پیاده سازی PrestoDB می‌باشد.پایگاه داده سری زمانی – Gorillaنرم‌افزار Gorilla پایگاه داده سری زمانی Facebook می‌باشد که هدف استفاده از آن مانیتور کردن و تحلیل زیرساخت‌ها و سخت‌افزار می‌باشد. این برنامه به حد کافی هوشمند می‌باشد که بتواند خرابی‌های که در یک نقطه و یا در یک منطقه رخ می‌دهد را بدون سربار زیادی مدیریت کند. شکل5 نشان می‌دهد که این نرم‌افزار چگونه در زیرساخت فعالیت می‌کند.از زمان پیاده سازی نرم‌افزار Gorilla، مقیاس آن حدودا در بازه هر 18 ماه بدون تلاش‌های زیادی دو برابر شده و این موضوع نشان‌دهنده مقیاس پذیری بالای این نرم‌افزار می‌باشد. این برنامه به عنوان یک Cache برای سیستم مانیتورینگ Facebook برای تمامی سیستم‌های آن عمل می‌کند. Gorilla میزان تاخیر تولید Facebook را به میزان 70 برابر نسبت به آمار برنامه‌های گذشته کاهش داده است و سبب افزایش کارایی چشمگیری در مانیتورینگ آن شده است.پایگاه داده توزیع شده برای لاگ‌ها – LogDeviceلاگ‌ها در سیستم از اصلی ترین روش‌ها برای پیگیری خطاها در تولید برنامه به حساب می‌آیند، به کمک لاگ‌ها می‌توان محتوا و علت به وجود آمدن خرابی را به دست آورد و در نتیجه راه حلی برای آن اتخاذ کرد. هیچ سیستمی نمی‌تواند بدون لاگ کار کند و سیستمی مانند Facebook که شامل چندین جزء مجزا بوده که به یکدیگر متصل شده اند، در هر لحظه به میزان قابل توجهی لاگ تولید می‌کند. برای ذخیره و مدیریت این داده‌ها Facebook از یک پایگاه داده توزیع شده به نام LogDevice استفاده می‌کند.این برنامه یک برنامه مدیریت لاگ مقیاس‌پذیر و مقاوم در برابر خطا می‌باشد. در مقابل یک فایل سیستم که داده را به عنوان فایل ذخیره می‌کند LogDevice داده را به عنوان یک لاگ ذخیره می‌کند. لاگ‌ها بر اساس رکورد ثبت می‌شوند. این پروژه از پایه نوشته شده است تا چندین نوع لاگ را با میزان کارایی و بهره‌وری بالا در مقیاس‌های بالا ذخیره کند. انوع کارهایی که توسط LogDevice قابل پیاده سازی اند شامل لاگ کردن رخداد‌ها، پایپلاین‌های یادگیری ماشین، لاگ کردن تراکنش‌ها و غیره می‌باشد.جمع‌بندیدر این پست ما با سیستم‌های استریم فیلم، سیستم‌های پخش موسیقی، سیستم‌های شبکه‌های اجتماعی آشنا شده‌ایم و از ۶ سیستم انتخابی ما ۳ سیستم دارای معماری‌های مؤثری داشتند و هر ۳ پرچمدار زمینه خود هستند. همانطور که در بخش‌های قبلی به خوبی نقات قوت توضیح داده شده است در این بخش ما ۳ سیستم برتر انتخابی خود یعنی نتفلیکس، اسپاتیفای و فیسبوک است. در نتفلیکس ما شاهد این بودیم که نسبت به رقبای خود دو تصمیم زود هنگام را گرفت که این دو تصمیم یعنی انتقال زیرساخت فناوری اطلاعات از مراکز داده خود به یک ابر عمومی و دیگری جایگزینی برنامه‌های یکپارچه با اجزای نرم افزاری کوچک قابل مدیریت توسط معماری میکروسرویس‌ها بود. که با اجرای این تصمیمات و مهندسی آشفتگی تیم‌های فنی نتفلیکس ابتدا پاسخگوی الزامات غیر عملکردی سیستم که شامل در دسترس بودن بالا، تاخیر کم، انعطافپذیری بالا و مقیاس پذیری شد و همچنین با شناسایی هدفمند شکست‌های واقعی و با استفاده از ابزارهای برای شناسایی و رفع خرابی‌های، میتواند چنین ضعف‌هایی را قبل از ایجاد مشکلات بزرگتر به سرعت کشف کند.در اسپاتیفای ما شاهد این بودیم که با اینکه apple music هم ساختار و معماری مشابه با اسپاتیفای داشت ولی پیروز این رقابت با اختلاف اسپاتیفای بود. در تحقیقات متوجه شده‌ایم که این اختلاف به دلیل تیم طراحی UI/UX است و متوجه شده‌ایم که برای این سیستم طراحی در نوامبر ۲۰۲۱، تیم Spotify، رویکرد جدید برای طراحی سیستم‌ها را معرفی کرده است که به Encore مشهور است. همچنین برای مدیریت تیم‌های خود از مدل Spotify استفاده می‌کند که موجب سریع‌تر شدن تیم‌ها می‌شود و همچنین به توسعه محصول نرم‌افزاری را سرعت ببخشند. مدل Spotify یک رویکرد مردم محور و مستقل برای مقیاس‌بندی چابک است که بر اهمیت فرهنگ و شبکه تأکید دارد. در بخش شبکه‌های اجتماعی Facebook و Twitter را مورد بررسی قرار دادیم. شبکه اجتماعی Facebook اولین نرم‌افزار عمومی بوده است که در مقیاسی به این عظمت وجود داشته است و در نتیجه بزرگترین چالش معماری آن مدیریت، ذخیره و تحلیل داده‌های آن می‌باشد. در آن بخش به توضیح در مورد چالش‌هایی که برای مقیاس بالای داده‌های Facebook به وجود آمده و مدیریت داده‌ها با پایگاه داده‌های مختلف پرداخته شد. دو نرم‌افزار Facebook و Twitter هر دو با مدل ساده LAMP شروع به کار کرده اند و هنوز هم میتوان آن‌ها را از این سبک معماری حساب کرد ولی هر دو شامل تغییرات بنیادی در سال‌ها شده اند و عملا تکنولوژی‌های منحصربه‌فردی برای حل مشکلات استفاده کرده اند.معماری‌های Facebook و Twitter را می‌توان در سال‌های ابتدایی یک سیستم یکپارچه تصور کرد که از مایکروسرویس استفاده نمی‌کرده اند. اما با گذشت زمان و مقیاس بالاتر به مرور به معماری کاملا مایکروسرویس تبدیل شده اند تا بتوانند نیازمندی‌های سیستم را در سرویس‌ها پاسخ دهند.سیستم Twitter را می‌توان به 6 سرویس اصلی تقسیم کرد که در آن‌ها نیازهای اصلی سیستم از جمله مدیریت tweet ها، جستجو، گراف اجتماعی و مواردی دیگر خلاصه می‌شود. در ادامه نتیجه گیری شد که سیستم‌های شبکه‌های اجتماعی تمرکز اصلیشان به علت وجود عنصرهای همیشه در گسترشی مانند گراف اجتماعی و ارتباطات فراوان میان موجودیت‌هایشان باید تمرکز بسیار بالایی بر روی مدیریت داده‌ها و پایگاه داده خود داشته باشند. در درجه اول به نیازمندی‌های غیرکارکردی پاسخ داده می‌شود و در ادامه نیز داده‌هایی با این مقیاس بسیار ارزشمند بوده و باید تحلیل شوند تا خصوصیت کاربرهای سیستم و عملا خصوصیاتی از مردم جهان به دست آید تا بهبودهای آینده بسیار کارآمد تر باشد. در نهایت نیز برای تمرکز بیشتر بر روی به‌روش‌های به کار رفته شده در پیاده سازی پایگاه‌های داده در مقیاس شبکه‌های اجتماعی به معرفی چند مورد دیگر از تکنولوژی‌های مربوط به پایگاه داده که در Facebook مورد توسعه و استفاده قرار گرفته شده است پرداختیم. http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html https://netflixtechblog.com/high-quality-video-encoding-at-scale-d159db052746 https://spotify.design/article/reimagining-design-systems-at-spotify https://www.atlassian.com/agile/agile-at-scale/spotify https://thinksoftware.medium.com/design-twitter-microservices-architecture-of-twitter-service-996ddd68e1ca https://www.scaleyourapp.com/what-database-does-facebook-use-a-1000-feet-deep-dive/ https://blog.twitter.com/engineering/en_us/topics/infrastructure/2017/the-infrastructure-behind-twitter-scale https://www.youtube.com/watch?v=AI01rRJH1Rg «این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» Pooya Sabeti Pooya Sabeti Sat, 12 Feb 2022 21:07:56 +0330 https://virgool.io/@pooyasabeti97/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-message-queue-xbs6gtjspajg در این پست قصد داریم درباره ی مفهموم Message Queue و استفاده ی آن در معماری های نرم افزار صحبت کنیم و همچنین ابزار های متن باز معروف و ابزار هایی ایرانی مربوط به آن را نیز معرفی کنیم.رویکرد Message Queue چیست؟صف بندی پیام ها به اپلیکیشن ا این اجازه را میدهد تا با فرستادن پیام به یکدیگر با هم ارتباط برقرار کنند. صف پیام ها یک فضای موقت را برای ذخیره کردن و نگهداری پیام ها فراهم می کند که اگر برنامه ی مقصد مشغول انجام کار بود و یا وصل نبود، پیامش از بین نرود.یک صف یک مسیر برای مواردی است که باید با ترتیب خاصی مدیریت شوند و نیاز به انتظار دارند. یک صف پیام، صفی از پیام ها است که توسط برنامه ی فرستنده ارسال شده اند و قرار است توسط گیرنده دریافت شوند. این صف شامل اشیائی میشود که باید پردازش شوند.یک پیام یک داده است که بین فرستنده و گیرنده ی اپلیکیشن در حال گذر میاشد. به صورت پایه ای میتوند یک بایت از داده با یک مقدار سربار باشد. یک مثال از یک پیام میتواند دستوری برای شروع یک پردازش در سیستم باشد و یا میتواند اطلاعاتی در مورد پایان کار یک پردازش باشد و منجر به شروع هیچ کاری نشود.یک معماری پایه از صفبندی ساده است؛ چند اپلیکیشن در سیستم به اسم پروسیجر وجود دارند که وظیفه ی آن ها ساخت پیام ها و رساندن آن ها به صف پیام ها میباشد. یک اپلیکیشن دیگر به عنوان مصرف کننده وجود دارد که به صف متصل شده و پیام هایی که درون آن وجود دارد را دریافت کرده و پردازش می کند. پیام ها در صف قرار داده میشوند و تا زمانی که مصرف کننده آن ها را بردارد و پردازش کند در صف ذخیره خواهند شد.صف های پیام هایک صف پیام یک پروتکل ارتباط غیر همگام را فراهم میکند که در واقع سیستمی است که یک پیام را در صف پیام قرار می دهد و نیاز نیست سریعا پیامی دریافت کند تا بتواند به کار خود ادامه دهد. یکی از بهترین مثال های پروتکل صفبندی پیام ها می تواند مثال ایمیل باشد که فرد فرستده ایمیل پس از ارسال منتظر دریافت پاسخ در لحظه نمیشود و دیگر فرایند های خود میپردازد. این روش از مدیریت پیام ها فرستنده و گیرنده را از برقراری ارتباط مستقیم به صورت همزمان با صف معاف میکند.قطع وابستگی و ایجاد مقیاس پذیریوابستگی در سیستم به میزان اتکایی است که یک قسمت از سیستم به قسمت دیگر آن دارد و سپس قطع کردن وابستگی به عملی میگویند که میزان وابستگی یک قسمت از سیستم به قسمت دیگر را از بین میبیرد و خود قسمت مورد نظر می تواند به عنوان یک واحد خود مختار عمل کند.یک سیستم غیر وابسته زمانی به دست می آید که چند سیستم بتوانند با هم ارتباط برقرار کنند بدون این که به یکدیگر متصل باشند. سیستم میتواند به طور کامل به کار خود ادامه دهد و از انجام کار دیگر سیستم ها غیر مطلع باشد. غیر وابسته بودن یک سیستم یکی از نشانه هایی است که خبر از ساختار بندی خوب سیستم مورد نظر میدهد و تثبیت آن راحت تر است.اگر یک پردازش در یک سیستم غیر وابسته دچار خطا در پردازش پیام از صف شود دیگر پیام ها همچنان میتوانند به صف اضافه شوند و زمانی که سیستم به حالت عادی برگشت میتواند آن ها را پردازش کند. همچنین میتوان از یک صف پیام استفاده کرد تا پردازشی را به تاخیر انداخت؛ به طور مثال یک تولید کننده یک پیام را در یک صف پیام قرار میدهد و در زمان مشخص شده مصرف کننده ها شروع به پردازش پیام ها از صف میکنند. یک پیام صف میتواند ذخیره و سپس ارسال شود.به جای ساختن یک اپلیکیشن بزرگ، به صرفه تر است که با از بین بردن وابستگی میان قسمت های مختلف اپلیکیشن و استفاده از صف پیام، به صورت غیر همگام میان قسمت های مختلف ارتباط برقرار کنیم. این امر این قابلیت را برای قسمت های مختلف فراهم میکند که به صورت خودکفا پیشرفت و رشد خود را داشته باشند و وابسته به تغییرات در قسمت های دیگر سیستم نباشند. یا تا وقتی که بتوان از طریق صف پیام میان آن ها ارتباط برقرار کرد حتی میتواند آن ها را در زبان های مختلف و توسط تیم های مختلف نوشت و به روز رسانی کرد.یک صف پیام در سیستم باعث جداسازی و غیروابسته کردن پردازش ها از یکدیگر میشود. پردازش اول نیاز ندارد که حتما پردازش های دیگر را صدا بزند، نوتیفیکیشن ارسال کند و یا از جریان ایجاد شده از پردازش های دیگر پیروی کند. پردازش های دیگر نیز میتوانند به صورت مجزا کار خود را انجام دهند و هر زمان که امکانش وجود داشت پیام را از صف بردارند. این روش از مدیریت کردن پیام ها باعث راحت تر کردن تثبیت و مقیاس پذیری سیستم میشود. یک مثال پایه از صف پیام هاتصور کنید یک وب سرویسی دارید که تعداد زیادی درخواست را در هر ثانیه دریافت میکند، در حالی که هیچ پیامی نباید از دست برود و همه ی درخواست ها باید توسط متدی پردازش شوند که گذردهی بالایی دارد. به زبانی دیگر سرویس شما باید دسترس پذیری بالایی داشته باشد و همیشه آماده ی دریافت درخواست جدید باشد و توسط پردازش قبلی مسدود نشود. در این حالت قرار دادن یک صف در میان وب سرویس و سرویس پردازش یک رویکر ایده آل می باشد. وب سرویس میتواند پیام شروع پردازش را در یک صف قرار داده و پردازش دیگر این هارا به ترتیب انتخاب کرده و پردازش کند. این دو پردازش از یکدیگر مجزا هستند و به علت وابستگی نداشتن نیاز نیست که منتظر یکدیگر باشند. اگر در زمان بسیار کم تعداد زیادی پردازش دریافت شود، این سیستم میتواند تمامی آن ها را پردازش کند. صف درخواست ها را در خود نگه می دارد حتی اگر تعداد آن ها زیاد شود. حال اگر این کسب و کار پیشرفت کند و مقیاسش بزرگتر شود و لازم باشد که مقیاس سیستم نیز بیشتر شود. صرفا در این سناریو لازم است تعداد مصرف کننده های بیشتری برای درخواست های ورودی در این سمت صف قرار دهیم.ابزار های متن باز برای صف پیام پنج تا از بهترین نرم افزار های متن باز بر پایه ی message queue(پیام های در صف) :با اتکا به بخش های قبل می دانیم نرم افزار های message queue برای کنترل ارتباطات آسنکرون استفاده میشود. این صف یک پروتکل آسنکرون برای ارتباط داده ها داخل سیستم فراهم میکند. که در این بخش به معرفی 5 نرم افزار پر کاربرد میپردازیم.هنگامی که تعداد زیادی تسک آسنکرون وجود دارد، برای مدیریت این تسک ها از نرم افزار های متن باز MQ استفاده میشود. ارتباط آسنکرون به این معنی است که نقاط پایانی ( endpoints ) که پیام ها را تولید و مصرف میکند. فقط با سرویس صف در تعامل هستند و با یکدیگر تعامل ندارند. MQ یک پروتکل آسنکرون بین فرستنده و گیرنده فراهم میکند تا بتوانند از راه دور و در هر زمانی، باهم ارتباط داشته باشند. پیام ها بسته به نیاز فرستنده میتوانن شامل "درخواست ها"، "پاسخ ها"، و "هشدار ها" باشند.واسطه پیام متن باز، بخش مهمی از سیستم نرم افزاری برای ارسال و دریافت پیام ها با فرمت text و یا سایر فرمت هاست. سرویس بر پایه MQ به نرم افزار ها اجازه میدهد تا بین سرویس های مختلف درون یک سیستم با یکدیگر در ارتباط باشند. همچنین هنگامی که برنامه مقصد مشغول انجام task دیگری هست و اصطلاحا busyاست، MQیک حافظه موقت ایجاد میکند تا پیام از دست نرود. اگر بخواهیم عمیق تر به این موضوع نگاهی بیندازیم، واسط پیام، برای فرستادن و دریافت تمامی پیام ها از سیستم صف (LIFO) استفاده میکند. پیام هایی که درون صف هستند، در داخل یک بافر سبک نگهداری میشوند و سپس و در پسزمینه وجود دارند.محبوب ترین "واسط پیام" ها و بهترین نرم افزار های بر پایه ی صف در سال 2021 عبارتند از:Apache KafkaRabbitMQCeleryNsqRedisson1. Apache Kafka — Robust Queue Brokerنرم افزار Kafka یک سیستم پیام رسان متن باز و یک واسط صف قوی است که حتی در پلتفرم های stream هم به کار برده میشود و توانایی کنترل حجم زیادی از پیام را دارد. در واسط پیام Kafkaپیام ها در دیسک نگهداری میشوند و اجازه میدهد تا پیام ها را از یک نقطه(point) به هر جای دیگر به صورت یکپارچه ارسال کنید.در صف پیام Apache پیام ها از طریق کل دسته های kafka تکثیر و تکرار میشوند تا از هرگونه عملیات ناخواسته مانند از دست رفتن داده ها جلوگیری شود. پلتفرم Kafka برای کنترل real timeبودن streamingها و همچنین برای پاسخ سریع به داده ها ساخته شد.این نرم افزار نسبت به سایر همتایان خود مانند ActiveMQ و RabbitMQ عملکرد بهتری دارد.به عنوان یک سیستم پیام رسان داخلی توسط Linked-in برای کنترل کردن 1.4 تریلیون پیام در روز ساخته شد. Kafka برای اجرای صف بهترین و مناسب ترین پلتفرم است زیرا با استفاده سکوئنشیال از عملیات I/Oکارایی را افزایش میدهد. و همچنین برای بیگ دیتا هم بهترین انتخاب است چرا که میتواند با وجود تعداد محدودی از منابع، به throughput بالایی دست یابد، میلیون ها پیام در ثانیه!2. RabbitMQ — Robust Messaging for Applicationsنرم افزار RabbitMQ گسترده ترین و محبوب ترین و همچنین به نظر اکثر افراد بهترین "واسط پیام" متن باز است.(واسطی برای پیامرسانی). که با زبان برنامه نویسی Erlang نوشته شده و توسط بنیاد Pivotal Software Foundation پشتیبانی میشود. به application های شما یک پلتفرم مشترک و مکانی امن برای ارسال و دریافت پیام می دهد. ویژگی های این برنامه شامل : کارایی، قابلیت اطمینان، دردسترس بودن، خوشه بندی و فدراسیون و غیره است.RabbitMQ رابط کاربری(UI) ساده و کاربردی دارد که این امکان را به شما میدهد تا پیام های خود را نظارت و مدیریت کنید.این برنامه را میتوان از سایت اصلی خود کمپانی دانلود کرد و برای تمامی انواع سیستم عامل ها دردسترس است.توصیه میشود تا از پلاگین های سرویس پیام مبتنی بر صف RabbitMQ استفاده شود تا هم کارایی افزایش یابد و هم حجم کاری message broker ها کاهش یابد و راحت تر load شود. مهم ترین پلاگین، پلاگین مدیریتی است که به صورت دستی فعال میشود. پلاگین مدیریتی به کاربران کمک میکند تا کاربران بتوانند با استفاده از واسط کاربری گرافیکی (GUI) بهتر پیام ها را مدیریت کنند. همچنین کمک میکند تا بتوان آمار های مربوط به پیام ها را بهتر مشاهده و دسته بندی کرد و یک نمای کلی از تمام عملیاتی که در صف رخ داده در اختیار میگذارد.3. Celery — Distributed Task Queueنرم افزار Celery یک سیستم پیامرسان بر پایه صف است که متن باز، انعطاف پذیر و قابل اطمینان است و برای پردازش پیام ها هنگامی که مقدار زیادی پیام وجود دارد استفاده میشود.این برنامه با تمرکز بر real time بودن فرآیند ها، امکان زمانبندی تسک ها را نیز فراهم میکند.Celery تحت مجوز BSD لایسنس شده است. celery صف فرآیندی آسنکرون دارد که به آن "صف کار" هم گفته میشود، که بر پایه distributed message passing است. واحد های اجرا یا فرآیند تسک ها، به صورت کانکارنت در یک نود تک کاره و یا نود چند پردازه ای اجرا میشوند. تسک های celery یا به صورت آسنکرون در پس زمینه و یا به صورت سنکرون اجرا میشوند.این برنامه با استفاده از پایتون نوشته شده اما پروتکل های آن به هر زبانی قابل پیاده سازی هستند. و برای microservice ها بهترین گزینه است. و هر روزه برای سیستم هایی مانند اینستاگرام برای پردازش میلیون ها تسک استفاده میشود. و همچنین میتواند با سایر زبان های برنامه نویسی که از "webhook" ها استفاده میکنند، کار کند. PHP کلاینت هایی مانند Go client – Node.js client – Ruby-client را RCelery مینامند.Celery متن باز است و در گیت ها 17.6 هزار ستاره کسب کرده و 4هزار fork از روی آن انجام شده است.4. Nsq — Realtime Distributed Messagingنرم افزار NSQ متن باز و حافظه توزیع شده بلادرنگ به سبک جدید است، بهترین MQ که طراحی شده برای مقیاس بالا مناسب باشد. به زبان برنامه نویسی Go نوشته شده است و میتواند بیلیون ها پیام در مقیاس بزرگ را هر روز کنترل کند.سیستم اعلان NSQ بر پایه پیام توزیع شده و ساختار توپولوژی غیر متمرکز عمل میکند. یکی از خصوصیات این سیستم این است که تک نقطه خرابی ( single point of failure ) ندارد. این خاصیت باعث افزایش تحمل خطا و همچنین افزایش قابلیت در دسترس بودن ( availability ) و در نتیجه باعث میشود که پیام ها با کیفیت بهتری به مقصد برسند.این نرم افزار یک محصول کامل، با کیفیت عالی است که به راحتی پیکربندی میشود. تمامی پیکربندی ها و deployment ها در خط فرمان مشخص شده اند و compiled binaries have no runtime dependencies.برای به حداکثر رساندن انعطاف پذیری NSQ ، فرمت های داده میتواند به فرمت JSON ، MsgPack ، protocol buffers و یا هر فرمت دیگری باشد.دارای کتابخانه های رسمی Go و python و همچنین سایر کتابخانه های client است. همچنین NSQ سه جزء مهم دارد : 1 - nsqd -3 nsqlookupd -2 nsqadminهمانطور که اشاره شد NSQ متن باز است و در GitHub 19.9 هزار ستاره دریافت کرده و 2.6 هزار fork از روی آن انجام شده است.5. Redisson — Distributed Java Serviceنرم افزار Redisson پیشرفته ترین و ساده ترین Redis Java client با ویژگی های In-Memory data grid می باشد. به راحتی میتوان کار با آن را یاد گرفت و ابراز نظارت MQ را دارد به طوری که نیازی به یاد گرفتن هیچ فرمانی ( commands ) از Redis برای پیکربندی Redisson نیست. همچنین نیازمند اشیاء مبتنی بر Redis ، کالکشن ها، قفل ها و سنکرون کردن و همچنین سرویسی برای توزیع کردن application ها در پلتفرم جاوا می باشد.تسک ها در جاوا ممکن است به صورت موازی و با پیاده سازی توزیع شده بر پایه ی Redis اجرا شوند.( به همراه ExecutorService و ScheduledExecutorService )پروژه متن باز Redisson در GitHub 16.9 هزار ستاره کسب کرده و 4.1 هزار fork از روی آن انجام شده است.نرم افزار های معادل ایرانی برای MQنرم افزار Chabokan یکی از ارائه دهنده های سرویس message queue در کنار سرویس های ابری دیگر می باشد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابع https://www.cloudamqp.com/blog/what-is-message-queuing.htmlhttps://en.wikipedia.org/wiki/Message_queuehttps://chabokan.net/ Pooya Sabeti Pooya Sabeti Fri, 24 Dec 2021 22:02:46 +0330 https://virgool.io/@pooyasabeti97/%D9%85%D9%82%D8%AF%D9%85%D9%87-%D8%A7%DB%8C-%D8%A8%D8%B1-static-code-analysis-bitqbionc7ms تعریف Static code analysisآنالیز ایستا کد ( ک به اسم آنالیز متن کد نیز شناخته شده میشود) به عنوان قسمتی از مراحل بازنگری کد می باشد( که با white-box testing نیز شناخته میشود) و به از قسمت های فاز پیاده سازی از چرخه ی امنیت توسعه ی نرم افزار می باشد. آنالیز ایستا کد به طور معمول به این اشاره دارد که بر روی یک کد ایستا ( یعنی در حالت اجرا نیست) یک آنالیز انجام دهیم و خطرات و مشکلات احتمالی کد را مشخص کنیم. این کار به وسیله ی تکنیک های آنالیز جریان داده و روش های مشابه انجام می شود.به طور ایده آل این ابزار ها به صورت خودکار میخواهند مشکل های امنیتی را تا حد خوبی از دقت پیدا کنند و مطمئن باشند که چیزی که پیدا میشود یک ایراد در کد است. در حالی که این موضوع حتی از دست برنامه های پرچم دار در این حوزه نیز خارج است. در نتیجه ابزار ها به یک وسیله ی کمکی برای فرد آنالیزور تبدیل می شوند و فرد به وسیله ی آن ها میتواند مشکل های امنیتی بیشتری را در زمان کمتری پیدا کند.بعضی از ابزار ها کم کم در حال انتقال و تجمیع با IDE ها هستند. برای آن مشکلاتی که میتوانند در فاز روند توسعه نرم افزار به دست آیند این فاز با استفاده از چنین ابزاری می تواند بسیار در پیدا کردن مشکلات کد ها قوی ظاهر شود، از آنجایی که میتواند یک واکنش سریع به بروز این مشکلات به برنامه نویس که ممکن است در کد به وجود آمده بدهد. اینگونه واکنش های سریع و اقداماتی که در حال نوشتن کد انجام می شود بسیار می تواند در مقابل پیدا کردن کد پس از اتمام برنامه نویسی در روند تصحیح خطا کارآمد باشد.تکنیک هاتکنیک های مختلفی برای آنالیز کرد ایستای کد وجود دارد که بتواند کد محتمل خطا را شناسایی کند ک میتواند آن را یک راه حل دانست. این تکنیک ها معمولا از تکنولوژی کامپایلر مشتق میشوند.Data Flow Analysisآنالیز جریان داده برای جمع آوری اطلاعات زمان اجرا برای داده های نرم افزار در حالت ایستا انجام میشود.معمولا از سه اصطلاح در آنالیز جریان داده استفاده میشود. basic block که به کد گفته میشود. Control Flow analysis که به جریان داده گفته میشود و مسیر کنترل که مسیری است که داده میپیماید. ک به توضیح مختصر این اصطلاحات میپردازیم.تعریف basic block:یک دنباله ای از دستورالعمل های به هم پیوسته که کنترل در اول بلوک وارد شده و در آخر آن تمام میشود و بلوک نمیتواند از بین برود و یا شاخه ای تولید کند مگر تا آخر آن.مثالی از basic block کد PHP:$a = 0; $b = 1; if ($a == $b) { # start of block echo “a and b are the same”; } # end of block else { # start of block echo “a and b are different”; } # end of blockگراف جریان کنترلی (CFG)یک نمایش گرافی انتزاعی از نرم افزار به وسیله ی گره هایی که هر کدام از آن ها یک basic block می باشد. یک نود از گراف نشان دهنده ی یک basic block بوده و یال ها نشان دهنده ی مسیر های اجرایی از یک گره به گره دیگر می باشد. اگر یک گره فقط یال خروجی داشته باشد آن را به عنوان گره ورودی شناخته و اگر یک گره فقط یال ورودی داشته باشد آن را به عنوان گره خروجی میشناسیم.به طور مثال در تصویر زیر گره 1( گره بالا) ورودی و گره 6(گره پایین) خروجی می باشد.نمونه یک CFGTaint Analysisروش Taint Analysis میکوشد تا که متغیری که با ورودی کاربر "taint" شده را پیدا کند و رد آن را تا متد های آسیب پذیر بگیرد که به "sink" شناخته میشوند. اگر متغیر taint شده بدون این که سالم شود به یک sink برسد میتوان آن را به عنوان یک خرابی احتمالی در نظر گرفت. بعضی از زبان های برنامه نویسی مانند Perl و Ruby روش Taint Analysisرا به صورت از پیش در خود دارند و در حالت هایی که به طور مثال باید داده توسط CGI قبول شود از این روش استفاده می شود.تحلیلگر معناییتحلیلگر معنایی کد برنامه را به توکن هایی از اطلاعات تبدیل میکند که آن ها انتزاعی از کد مبدا را نشان می دهند و راحت تر میتوان آن را دستکاری کرد. به طور مثال توکن کردن یک کد PHP:قبل از توکن کردن:<?php $name = "Ryan"; ?>پس از توکن کردن:T_OPEN_TAG T_VARIABLE = T_CONSTANT_ENCAPSED_STRING ; T_CLOSE_TAGنقاط قوت و ضعفنقاط قوتبه میزان قابل توجهی مقیاس پذیری دارد ( میتواند روی انواع مختلفی از نرم افزار ها اجرا شود و تکرار شود ).مواردی نیز وجود دارد که این ابزار ها میتوانند با اطمینان بالایی آن ها را پیدا کنند ( مانند پر شدن بافر)نقاط ضعفبسیاری از آسیب پذیری های امنیتی به طور خودکار بسیار سخت یافت می شوند، مانند مشکل های احراز هویت، مشکلات دسترسی و ... . در حال حاضر برنامه های روز میتوانند فقط قسمت کمی از مشکلات امنیتی را پیدا کنند. این ابزار ها قطعا به مرور زمان بهتر می شوند.تعداد زیادی اخطار غلط میتوانند در این برنامه ها وجود داشته باشد.از آنجایی که تنظیمات در کد نیستند، به طور پیاپی نمیتواند مشکلات تنظیمات را پیدا کند .بسیار سخت است که ثابت کنیم مشکل پیدا شده در کد، واقعا یک مشکل به حساب می آید.بسیاری از این ابزارها سختی هایی در آنالیز کردن کد دارند و نمیتوانند آن را کامپایل کنند. یکی از دلایل این امر این است که اغلب کتابخانه های مورد نظر را ندارند.محدودیت هااعلام خطا (False Positive )یک ابزار تحلیل ایستای کد معمولا خطا هایی را تشخیص می دهد و آن ها را به عنوان خطا گزارش می کند که در اصل واقعا خطا نبوده اند و مشکلی در آن قسمت ها نیست. یکی از دلایل این رخداد این است که ابزار نمیتواند از جامعیت و امنیت داده در زمانی که در حال گرفتن ورودی و خروجی در برنامه جریان دارد به در ستی مطلع شود.اعلام خطای به غلط میتوانند زمانی گزارش شود که در حال آنالیز کردن اپلیکیشنی هستیم که با تمامی اجزاء آن در ارتباط نیست و نمیتوانند به بقیه ی کامپننت ها دسترسی داشته باشد و در نتیجه نمیتواند جریان داده را ببیند و آن را آنالیز کند. زیرا که بدون بودن کد به دست آوردن جریان داده و تغیرات ورودی ها وخروجی ها امکان پذیر نمیباشد.اعلام نکردن خطا به غلط (False Negative)استفاده از ابزار های تحلیل ایستای کد میتواند منجر به False Negative نیز بشود و در مکانی که باید آسیب پذیری کد را گزارش کند این کار را نکند. این ممکن به طور مثال زمانی اتفاق بیفتد که مشکل در یک کامپننت دیگر وجود دارد و این آنالیزگر به آن دسترسی نداشته و آن را بررسی نکرده است و در زمان اجرای کد در دست بررسی این کد، کامپننت دیگر را صدا زده و آن نیز اجرا میشود و در آن خطا رخ میدهد که عملا یکی از آسیب پذیری های زمان اجرای این کد بوده که گزارش نشده.به طور کلی چه معیار هایی میتوان برای انتخاب ابزار داشت؟نیازمندی : باید حتما زبان در حال استفاده را پشتیبانی کند. این که بدانیم کدام نوع از آسیب پذیری ها را در کل می تواند یافت کند. آیا نیاز به یک کدی دارد که کاملا قابل اجرا است یا با کد های نصفه و ناکامل هم کار میکند>میتواند بدون داشتن تمام کد مبدا اجرا شود؟میتواند با IDE آن را تجمیع کرد؟میزان هزینه ای که باید برای مجوز استفاده از ابزار بپردازیم.آیا از OOP پشتیبانی میکند؟برنامه های مشابه ایرانی برای آنالیز کدبرای حوزه ی تحلیل ایستا کد متاسفانه شرکتی یافت نشد که به طور مشخص برنامه ای برای این کار ارائه داده باشد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابعowasp.org Pooya Sabeti Pooya Sabeti Fri, 24 Dec 2021 19:49:43 +0330 https://virgool.io/@pooyasabeti97/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D9%87%D8%A7%DB%8C-%D9%85%D8%A7%D9%86%DB%8C%D8%AA%D9%88%D8%B1%DB%8C%D9%86%DA%AFmonitoring-tools-wbmtthpvpeyx مانیتورینگ برنامه دقیقا به چه معناستدر ابتدا بهتر است یک تعریف مناسب از مانیتورینگ ارائه دهیم. مانیتور کردن نرم افزار در واقع یک نوع برنامه ی نظارتی/امنیتی است که بر روی سیستم یا شبکه نصب می شود. میتواند یک اپلیکیشن کامل باشد و یا یک کاربری و یک قسمتی از فایروال سخت افزاری، نرم افزار و یا یک آنتی ویروس باشد. به طور کل مانیتور کردن نرم افزار به این معنی است که تمام ترافیک های ورودی و خروجی برنامه، پردازه ها و تعاملات کاربر و تمامی فعالیت های برنامه ها را لاگ کنیم.که این موضوع قوانین سیستم را بررسی می کند و فعالیتهای معمولی و غیر معمول این سیستم را در نظر می‌گیرد. همچنین اگر اتفاق های غیرعادی را بیابد به ادمین سیستم اطلاعات خواهد داد همچنین این نرم افزارها برای شنود کردن کارمندان و کاربران در یک شبکه نیز استفاده می شود.  به طور مثال یکی از کاربری های بسیار ساده مانیتورینگ کنترل والدین روی محتوایی  است که که در کامپیوتر دیده می شود.ابزار های مانیتورینگمهم نیست که شما یک برنامه ی کوچک یا خیلی جامع داشته باشید. به هر صورت نمیتوان مانیتور کردن سیستم را نادیده گرفت. حتی اگر یک وبسایت شخصی دارید نیز باید حد اقل فعال یا غیرفعال بودن آن را مانیتور کنید.چندین نرم افزار مانیتورینگ مختلف از سطوح متن باز گرفته تا برنام های تجاری وجود دارد که به شما کمک می کند سخت افزار خود را مانیتور کنید و از خرابی ها و رخداد ها مطلع شوید. با در نظر گرفتن گزینه های زیادی که وجود دارد ممکن است پیدا کردن مورد مناسبی که برای هزینه و کارایی مورد نظر شما مناسب است، چالش برانگیز باشد. ولی نکته خوب این است که چندین نرم افزار متن باز و قدرتمند برای این کاربرد وجود دارد که میتواند به نیاز های مانیتورینگ شما پاسخ دهد. در ادامه ی این پست به بررسی و معرفی مختصری از این ابزار ها می پردازیم.Nagiosاین برنامه در سال 1999 ساخته شد و یک از پیشگام های صنعت جهت ارائه ی خدمات و راه حل های مانیتور کردن در سطوح ابتدایی تا پیشرفته می باشد. Nagios قادر به مانیتور کردن انواع جنبه های یک سیستم از جمله پروتوکل های شبکه، سیستم های عامل، مقیاس های سیستمی، اپلیکیشن ها، سرویس ها، وب سرور ها، وب سایت ها، میان افزار ها و غیره می باشد.این برانامه روی موتور Core 4 اجرا میشود که میتواند سطح بالایی از کارایی با مصرف میزان کمی منابع پیاده سازی کند. میتوانید با استفاده از پلاگین ها عملا با انواع مختلف برنامه های غیر رسمی دیگر آن را تجمیع کنید و هر نیازی که باشد به احتمال زیاد پلاگین آن نیز موجود است. اگر علاقه مند به استفاده از میان افزار ها هستید میتوانید از Nagios استفاده کنید تا WebLogic, WebSphere, JBoss, Tomcat, Apache, URL, Nginx و غیره را مانیتور کنید.ویژگی های Nagiosمزکزی کردن نمای بررسی تمامی زیرساخت های آی تی. مدیریت کننده های رخداد آن به صورت خودکار دست به تصحیح خطا اپلیکیشن ها میزنند.دسترسی برای مانیتور کردن چندین سروردسترسی انتخاب شده به مشتری ها این اجازه را میدهد که فقط زیرساخت هایی که زیر نظر آنها هستند را مورد بررسی قرار دهند.جامعه ی فعالی متشکل از بیش از یک میلیون کاربر داردمعماری قابل گستش داشتنZabbixنرم افزار Zabbix نیز یک نرم افزار حرفه ای برای اپلیکیشن ها، شبکه ها و پایگاه داده های سطح بالا و مانیتور کردن تمامی اجزاء مورد بررسی آن ها مثل کارایی و دسترسی طراحی شده است. این برنامه توسط هزارن شرکت بزرگ در جهان مانند DELL، Salesforce, ICANN و غیره مورد استفاده قرار میگیرد.سیستم server-agent این برنامه یک معماری سیستم است که شما باید آن را بر روی یک سرور نصب کنید که بتواند توسط سرور Zabbix مانیتور شود. در عین حال لازم نیست که این agent را برای سرویس هایی مثل FTP, SSH, HTTP و غیره نصب کنید. این برنامه را میتوانید در لینوکس ویندوز و سیستم عامل های دیگر نیز نصب کنید.ویژگی هامستقیما اپلیکیشن های جاوا را از طریق JMX مورد مشاهده قرار میگیرند.مانیتورینگ ماشین مجازی توسط VMWare, VCenter و vSphere پشتیبانی میشود.قسمت فرانت اند یک سیستم محافظتی در مقابل حمالت bruete force درون خود دارد.اتوماسیون کردن سیستم میتواند در قالب انواع زبان ها مانند Ruby, python, Perl, PHP, Java و غیره نوشته شود.میتوان آن را با دیگر سیستم های مدیریتی مانند Puppet, cfengine, Chef, bcfg2 و دیگر های سیستم دیگر تجمیع کرد و ارتقا داد.Checkmkبرنامه ی Checkmk یک ابزار بسیار مقیاس پذیر برای مانیتور کردن سرور ها، شبکه ها، دارایی های ابری، پایگاه های داده، کانتینر ها، اینترنت اشیاء و غیره استفاده کرد. همچنین این برنامه در دو حالت قابل استفاده می باشد.نسخه خام - که کاملا متن باز بوده و به میزان نامحدودی میتوان با آن مانیتور کرد.نسخه حرفه ای - که همانطور که انتظار میره با اضافات در اختیار شما قرار میگیره.ویژگی هادر چند دقیقه میتواند آماده شود و مورد استفاده قرار بگیرد.کمترین نیاز برای پیاده سازی در صنعت: میتوان به مقدار بسیار زیادی عملات های آن را خودکار کرد و کمترین تلاشی به صورت دستی انجام شود.مانیتور کردن بسیار منعطفقابل استفاده با تکنولوژی های جدید: میتواند با Docker, kubernetes,AWS و Azure کار کند.مناسب برای استفاده در محیط های بسیار وسیع با مقیاس پذیری بالا.Prometheus + Grafanaلیست معرفی شده قطعا بدون شامل شدن دو برنامه متن باز و بسیار قدرتند Prometheus و Grafana کامل نخواهد بود. این روش یک روش بسیار شخصی سازی شده و غیر آماده است که شما برای به دست آوردن معیار ها و مقیاس ها از نرم افزار Prometheus و برای نمایش آنها از Grafana استفاده میکنید.بسیاری استخراج کننده وجود دارد که بتوان برای Prometheus داده هایی را از لینوکس، ویندوز و غیره به دست آورد.Cactiبرنامه ی Cacti نیز یکی از دیگر ابزار ها برای مانیتور کردن شبکه میباشد که میتواند روی لینوکس یا ویندوز نصب شود. این برنامه به RRDTool متصل می شود که اجازه میدهد گراف هایی را مربوط به داده های شبکه تولید کنیم.این برنامه با SNMP کار می کند و آمار شبکه را به فرمی که به راحتی قابل فهم باشد نمایش می دهد. از نیازمندی های این برنامه MySQL، Apache و یا IIS میباشد.ویژگی هامیتوان به صورت نامحدود برای هر گراف مواردی را به صورت سلیقه ای مشخص کرد.پشتیبانی از فایل های پایگاه داده Round-Robin با داده هایی از چندین منبع مختلف و همچنین میتواند فایل های RRD را در هر جای سیستم محلی ذخیره کند.مدیریت و امنیت مبتنی بر کاربر.قابلیت استفاده از کد های استخراج داده ی سلیقه ای OpenNMSبه وسیله ی OpenNMS میتوانید یک راه حل مانیتور کردن شبکه برای هرگونه زیرساختی به وجود آورید. همچنین میتوانید از JMX, WMI, SNMP, NRPE, XML HTTP, JDBC, XML, JSON و غیره برای جمع آوری داده استفاده کنید.با کمک OpenNMS میتوانید توپولوژی های شبکه های لایه 2 را در شبکه خود به دست آورید. این یک معماری مبتنی بر رخداد می باشد که از Grafana نیز پشتیبانی میکند. OpenNMS درون خود یک سیستم گزارش دهی دارد که به شما اجازه میدهد در داشبورد خود یک گزارش جامع و شکیل از آمار سیستم مشاهده کنید و در کل میتوان گفت که رابط کاربری بسیار خوبی دارد.ویژگی هابه طور مخصوص برای استفاده در لینوکس ساخته شده است ولی متوان از آن در ویندوز, Solaris و OSX نیز استفاده کرد.میتواند دمای دستگاه را مانیتور کند.داشبورد ادمین قابلیت شخصی سازی دارد.دارای قابلیت مانیتور کردن منبع برقپشتیبانی از IPv4 و IPv6رخداد ها میتوانند نوتیفیکیشن هایی از طریق ایمیل، پیامک، XMPP و دیگر متد ها بفرستند.نقشه ی نقطه ای جغرافیای قابل نمایش دارد که میتوان در آن سرویس های در حال سرویس دهی را به وسیله ی Open Street Map، Google Map و یا Mapquest را دید.برنامه های ایرانی مشابه برای مانیتور کردنگروه پال نتگروه نرم افزاری پال نت با ارائه دادن ساخت سرور های شخصی و مدیریت سرور های سازمانی سرویس های متفاوتی ارائه میدهد. یکی از این سرویس ها ارائه شده مانیتور کردن شبکه و سرور ها می باشد.سدید آفریننرم افزار Zabbix یکی از نرم افزار های مطرح در این حوزه می باشد که شرکت سدید آفرین یک نمایندگی رسمی از این نرم افزار در ایران می باشد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابعhttps://www.dynatrace.com/resources/monitoring-tools/https://geekflare.com/best-open-source-monitoring-software/https://www.techopedia.com/definition/4313/monitoring-softwarehttps://www.palnetgroup.ir/https://sadidafarin.ir/zabbix-network-monitoring-software Pooya Sabeti Pooya Sabeti Fri, 24 Dec 2021 16:51:00 +0330 https://virgool.io/@pooyasabeti97/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D9%87%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%84%D8%A7%DA%AF-eh2uww3un6by در این مقاله قصد داریم مفهمو مدیریت لاگ را معرفی کنیم و همچنین به شرح تعدادی از ابزار های پر کاربرد این زمینه بپردازیم. در ادامه چند نمونه از ابزار های ایرانی را نیز معرفی خواهیم کرد.مدیریت لاگ چیست ؟مدیریت لاگ به رویکردهای جمع آوری مداوم، ذخیره کردن، پردازش کردن، تجزیه کردن و آنالیز کردن داده ها از از برنامه ها و اپلیکیشن های مختلف گفته می شود جهت اینکه بتوانیم کارایی سیستم را بهینه کرده ، مشکلات فنی را به دست آوریم ، منابع را بهتر مدیریت کنیم ، امنیت را بیشتر کنیم و مقبولیت را افزایش دهیم.یک لاگ به یک فایل تولید شده توسط کامپیوتر گفته می شود که فعالیت های درون سیستم عامل و اپلیکیشن ها را را ذخیره می کند. فایل به صورت اتوماتیک هر اطلاعاتی که توسط ادمین های سیستم طراحی شده باشد را داکیومنت می کند. مانند:  پیام‌ها گزارش‌های خطا، درخواست های فایل و انتقال‌های فایل. این فعالیت همچنین زمان انجام را ذخیره می کند که به متخصصین آی تی و توسعه دهنده ها کمک می کند که بفهمند چه اتفاقی افتاده و چه زمانی این اتفاق افتاده.یک سیستم مدیریت لاگ یک برنامه است که که داده ها را از منابع مختلف جمع آوری کرده دسته بندی می کند و آن ها را از  در یک موقعیت مرکزی ذخیره می کند.سیستم های مدیریت لاک به تیم های IT,DevOps و SecOps اجازه می‌دهند که یک . واحد بسازند که بتوانند به تمام داده های اپلیکیشن و شبکه دسترسی داشته باشد.به طور معمول این فایل لاگ کاملاً ایندکس شده و قابل جستجو می باشد زیرا که تیم آی تی بتوانند به راحتی داده مورد نیاز خود را به دست آورد و تصمیم گیری هایی درباره سلامت شبکه، تخصیص منابع و امنیت سیستم اتخاذ کند.ابزارهای مدیریت لاگ کمک می کنند که بتوان تعداد زیادی از داده ها را که برای لاگ کردن تولید شده‌اند را مدیریت و دسته بندی کنند. این ابزارها چند چیز را تعیین میکند:چه داده‌ها و اطلاعاتی نیاز است لاگ شود.فرمتی که باید لاگ به آن صورت انجام شود.بازه های زمانی ذخیره داده های لاگ باید به چه صورت باشد.چگونه داده ها در صورت مورد نیاز نبودن از بین بروند و نابود شوند.یک سیستم مدیریت لاگ کارآمد دید های بلادرنگ را برای سلامت و عملیات های سیستم به وجود می آورد و همچنین موارد زیر از کاربردهای آن است.یکپارچگی ذخیره داده از طریق تجمیع مرکزی لاگافزایش امنیت به وسیله کاهش سطوح حمله، مانیتور کردن بلادرنگ و بهبود تشخیص و زمان واکنش دادن به این موارد.بهبود قابل مشاهده بودن و شفافیت میان برنامه های مختلف به وسیله یک رویداد لاگ.بهبود تجربه کاربر به وسیله آنالیز کردن داده لاگ و مدلسازی پیش بینی گر.تصحیح خطای سریع تر و دقیق تر به وسیله تحلیل شبکه های پیشرفته.ابزار های مدیریت لاگلاگ کردن باید یک پروسه ی پایه ای برای هر مانیتورینگ سخت افزار باشد. یک لاگ فایل تراکنش برای ریکاور کردن دیتابیس SQL server از فاجعه ضروری است.همچنین با بررسی فایل های لاگ، تیم DevOps و ادمین های پایگاه داده میتوانند میزان حداکثری کارایی را حفظ کنند یا مدارکی از فعالیت های تایید نشده به معنی وجود حمله امنیتی پیدا کنند. به همین دلیل، مانیتور کردن و آنالیز کردن لاگ های سیستم از اهمیت بالایی برخوردار است. این موضوع که میتوانیم با بررسی زنجیره وار رخداد های سیستم به علت وقوع خرابی و مشکل پیش آمده برسیم و آن را تصحیح کنیم بسیار قابلیت اعتماد سیستم را افزایش می دهد.امروزه چند نمونه از برنامه های مدیریت و آنالیز لاگ وجود دارد و انتخاب منبع مناسب برای آنالیز لاگ های برنامه از چیزی که به نظر میرسد امری راحت تر می باشد. برنامه های رایگان و متن باز به افراد مدیریت لاگ ها را در انواع مختلف سیستم و سایت ها و سیستم عامل ها ارائه می دهد. پنج مورد از برترین آن ها را در این بخش معرفی می کنیم.GrayLogنرم افزار Graylog در سال 2011 در آلمان شروع به کار کرد و امروزه به عنوان یک برنامه ی متن باز و یا یک برنامه تجاری ارائه می شود. این برنامه طراحی شده است که برای ورودی داده هایی از سورس ها و سرور های مختلف می باشند به عنوان یک سیستم مدیریت لاگ مرکزی عمل کند. همچنین این اجازه را میدهد که در میان اطلاعات با سرعت زیاد جستجو و بررسی انجام شود.این نرم افزار به علت داشتن راحتی مقیاس پذیری در میان ادمین های سیستم به محبوبیت زیادی رسید. بیشتر پروژه های تحت وب در ابتدا که شروع میشوند مقیاس کوچکی دارند و در ادامه به صورت نمایی رشد می کنند. Graylog می تواند با بالانس کردن بار میان شبکه های سرور های بک اند و مدیریت ترابایت ها داده به صورت روزانه باعث مقیاس پذیری بالای یک اپلیکیشن شود.Graylogادمین های آی تی رابط کاربری فرانت graylog را بسیار راحت و شفاف و در عین حال مستحکم یافتند. این برنامه در باب مفهوم داشبورد ساخته شده است که به کاربر اجازه می دهد مقیاس ها و داده هایی که از اهمیت بیشتری برخوردارند را انتخاب کند و روند آن را در طول زمان بررسی نماید.زمانی که یک بحران کارایی یا امنیتی اتفاق میفتد، ادمین های آی تی میخواهد که رد مشکل ریشه ای علت به وجود آورنده این مشکل را در سریع ترین زمان ممکن به دست آورند. قابلیت جستجو در این برنامه این امر را بسیار راحت می کند. درون برنامه Greylog یک سیستم انعطاف نسبت به خطا وجود دارد که می تواند جستجو های چند رشته ای را انجام دهد تا بتوان چند تحدید را به صورت همزمان بررسی کرد.Nagiosبرنامه Nagios در سال 1999 با یک توسعه دهنده کار خود را آغاز کرد و از آن زمان تا کنون به یک از قابل اعتماد ترین برنامه های مدیریت داده های لاگ تبدیل شده است. نستخه کنونی Nagios میتواند بین چند سرور در حال اجرای ویندوز، لینوکس و یا یونیکس ارتباط برقرار کند.Nagios Coreمحصول اصلی آن یک سرور لاگ می باشد که هدف آن دسته بندی و به دست آوردن داده ها و راحت تر کردن دسترسی ادمین ها می باشد. موتور سرور لاگ Nagios داده ها را به صورت بلادرنگ به دست می آورد و آنها را به خورد ابزار قدرتمند جستجو می دهد. تجمیع کردن داده ها با یک اند پوینت در اپلیکشن به صورت بسیار ساده در محیط نصب آن انجام می شود.این برنامه به طور معمول در سازمان هایی که نیاز به مانیتور کردن امنیت شبکه محلی خود دارند مورد استفاده قرار می گیرد. Nagios می تواند به گستره ی وسیعی از رویداد های مربوط به شبکه رسیدگی کند که به اتوماسیون پخش کردن هشدار ها کمک می کند. همچنین در این برنامه می توان اسکریپت هایی از پیش تعیین کرد که اگر یک اتفاق خاصی افتاد و شرایط آن اسکریپت به وجود آمد، خودش شرایط را قبل از این که یک انسان به صورت دستی وارد عمل شود مدیریت کند.به عنوان یکی از کار های رسیدیگی به شبکه میتواند داده های لاگ را بر اساس موقعیت جغرافیایی ای که داده از آن نشات میگیرد ذخیره کرد. این به این معنی است که میتوان داشبورد های معنا داری نسبت موقعیت دقیق جریان ترافیک برای مشاهده آن به وجود آورد.Elastic stack نرم افزار Elastic stack که بعضی اوقات به آن ELK Stack هم گفته می شود، یکی از معروف ترین ابزار های متن باز در میان سازمان های می باشد که نیاز به پیمایش درون مجموعه های بسیار وسیعی از داده ها را دارند و باعث می شود داده های آن ها معنی پیدا کنند. نرم افزار اصلی آن از سه بخش مجزا تشکیل شده است: Elastisearch, Kibana و Logstash:همانطور که از اسم آن مشخص است Elasticsearch طراحی شده است که کاربران درخواست های خود را در میان پایگاه داده به کمک گسترهی عظیمی از انواع زبان های کوئری به دست آورند. سرعت بالا از خصوصیات بسیار بارز این برنامه می باشد. همچنین میتواند به خوشه های تشکیل شده از صدها سرور گسترش پیدا کند و پتابایت ها داده را به سادگی مدیریت کند.بخش kibana یک ابزار مصورساز است که در کنار Elasticsearch اجرا میشود و به کاربر اجازه می دهد که داده ها را آنالیز کرده و گزارش های قدرتمندی به دست آورد. زمانی که در ابتدا موتور Kibana را روی خوشه ی سرور های خود نصب میکنید میتوانید یک دسترسی به رابط کاربری ای پیدا کنید که گزارشات آماری، گراف ها و حتی انیمیشن هایی از داده شما را نمایش می دهد.قسمت نهایی Elk Stack قسمت Logstash می باشد که به عنوان یک پایپلاین محض سمت سرور درون پایگاه داده Elastcsearch عمل می کند. میتوانید Logstash را به همراه گستره ی مختلفی از زبان ها و API های مختلف تجمیع کنید تا اطلاعات از وبسایت و یا اپلیکیشن موبایل شما به صورت مستقیم به خورد موتور قدرتمند Elastic Stalk داده شود.یک ویژگی منحصر به فرد ELK Stack این است که به شما اجازه میدهد که اپلیکیشن هایی روی بیلد متن باز WordPress می باشند را مانیتور کنید. در مقابل بسیاری از ابزار های لاگ مخصوص امنیت که به سختی ادمین و لاگ های PHP را دنبال می کنند با ELK Stack می توان در میان لاگ ای دیتا بیس و وب سرور به راحتی گذار کرد. برنامه های مشابه ایرانی برای مدیریت لاگ شرکت آتینطبق توضیحات خود شرکت :شرکت دانش بنیان آتین آتیه اندیش، مستقر در پارک علم و فناوری دانشگاه تهران، در سال 1396 فعالیت خود را به طور تخصصی درحوزه ارائه خدمات احراز هویت آغاز کرد. این شرکت با بررسی نمونه های مشابه خارجی و بر اساس نیازهای داخلی کشور درحوزه احراز هویت، اقدام به توسعه سامانه مدیریت هویت و دسترسی نموده است. تیم فنی آتین از فارغ التحصیلان دانشگاه های برتر کشور در حوزه نرم افزار و امنیت اطلاعات و با پشتوانه سابقه چندین ساله در حوزه احراز هویت و کنترل دسترسی تشکیل شده است.این شرکت در میان خدمات متفاوتی که ارائه می دهد، خدمت مدیریت لاگ را نیز به صورت اختصاصی ارائه میدهد.شرکت کوالاتکاین شرکت به طور کلی در حوزه ی تست نرم افزار و وب سرویس ها کار میکند و یکی از خدمات ارائه دهنده ی آنها مدیریت لاگ می باشد.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابع HumioOpensourceQualatechauthin Pooya Sabeti Pooya Sabeti Thu, 23 Dec 2021 22:05:16 +0330 https://virgool.io/@pooyasabeti97/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-api-gateway-%D8%AF%D8%B1-%D9%85%D8%A7%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-cvkj6ikn6vfy در یک معماری میکروسرویس هر کاربر احتمالا با بیش از یک سرویس فرانت اند در ارتباط است.  با در نظر گرفتن این موضوع، بخش فرانت چطور با سرویس مورد نظر خود ارتباط برقرار می کند؟ اگر سرویس های جدید معرفی شوند و یا سرویس های کنونی تغییر کنند چه اتفاقی خواهد افتاد؟ یک کامپوننت API Gateway  به ما کمک می کند تا به راحتی چالش‌های فوق را مدیریت کنیم.یک API Gateway چیست؟یک API Gateway کامپوننتی است که بین بخش فرانت و سرویس های برنامه مستقر می شود و به عنوان یک VPN معکوس عمل کرده و درخواست ها را از بخش فرانت به سرویس ها روت میکند. همچنین می تواند کار های دیگری از قبیل احراز هویت، SSL Termination و محدود کرد تعداد پاسخدهی را انجام دهد. اگر از این کامپوننت برای مدیریت درخواست های کاربر استفاده نشود، کاربر مجبور است تا مستقیما با سرویس های سمت فرانت در ارتباط باشد و یک به یک به این سرویس ها درخواست ارسال کند. در حالی که آشکار شدن سرویس ها برای بخش فرانت می تواند مشکلاتی را در بر داشته باشد که به شرح زیر است:این ارتباط مستقیم می تواند باعث پیچیدگی کد سمت کلاینت شود زیرا نیاز است هر سرویس را مسقیما زیر نظر داشته باشد و همچنین برای مدیریت خطا ها و برگشت های احتمالی هر کدام از سرویس هایی که به آنها درخواست ارسال می کند آماده باشد.باعث به وجود آمدن یک وابستگی بین بخش فرانت و سرویس های بک اند می شود. کامپوننت کاربر باید بداند که هر کدام از این سرویس ها از چه اجزایی تشکیل شده اند و چگونه نوشته شد اند. این باعث سخت تر شدن به وجود آمدن قسمت فرانت می شود و ساخت آن را دشوار تر می کند.یک درخواست ساده از سمت کاربر ممکن است نیاز به صدا زدن چندین سرویس را داشته باشد که این امر احتمالا شامل چندین رفت و برگشت بین کاربر و سرویس ها میشود که به میزان چشمگیری تاخیر را برای درخواست ها افزایش خواهد داد.هر سرویس عمومی لازم دارد که به نکات و اقداماتی مثل احراز هویت، SSL termination و موارد دیگر که جزو وظایف API Gateway ذکر شد را مدیریت کند.سرویس ها لازم دارند یک پروتکل مخصوص کاربر را مانند HTTP و WebSocket را آشکار کنند. این امر باعث محدودیت در استفاده از پروتکل های ارتباطی خواهد شد.سرویس هایی با اندپویت های عمومی از اهداف حملات قرار میگیرند.یک Gateway با کاهش میزان وابستگی بین کلاینت و سرویس ها به حل این مشکلات کمک می کند. یک Gateway می تواند کار های بسیار متفاوتی انجام دهد که نیاز به دونستن همه ی آنها نیست. این توابع به الگو های طراحی زیر دسته بندی می شوند.Gateway Routing :از Gateway به عنوان یک پراکسی معکوس استفاده می کند تا درخواست ها را به یک یا چند سرویس بک اند مربوط کند. در این مسیریابی از مدل 7 لایه استفاده خواهد کرد. Gateway فقط یک اندپویت برای کلاینت ها به وجود می آورد تا بتواند وابستگی را بین کلایت و سرویس ها از بین ببرد.Gateway Aggregation :از Gateway برای تجمیع کردن چند درخواست به یک درخواست در این طراحی استفاده می شود. این الگو زمانی اعمال می شود که یک عملیات به چند سرویس بک اند درخواست می دهد. کلاینت یک درخواست را به سرور ارسال می کند و Gateway درخواست را تقسیم کرده و به سرویس های مورد نظر ارسال می کند. سپس پس از گرفتن نتیجه از سرویس ها آن ها را تجمیع کرده و به عنوان یک جواب به کلاینت ارسال می کند. این باعث از بین رفتن مشکل رفت و برگشت میان کلاینت و سرویس ها خواهد شد.Gateway Offloading :از Gateway استفاده می کند تا رویه های Offload را از سرویس ها برداشته و روی Gateway قرار دهد. این تجمیع رویه ها بر روی یک فضا بسیار کاربردی است زیرا از تکرار جلوگیری می کند و دیگر هر سرویس به طور جداگانه مسئول پیاده سازی این رویه ها نیست. این امر برای ویژگی هایی مانند احراز هویت که پیاده سازی نسبتا دشواری دارد خیلی اهمیت بالاتری دارد.در زیر چند مثال از کاربری ای که می تواند به یک Gateway آفلود شود، آمده است: SSL terminationAuthenticationIP allow/block listClient rate limiting (throttling)Logging and monitoringResponse cachingWeb application firewallGZIP compressionServicing static contentانتخاب تکنولوژی GatewayReverse Proxy Server:دو برنامه ی پر کاربرد در سرور های پراکسی معکوس Nginx و HAProxy می باشند. این دو برنامه از ویژگی های مختلفی مانند load balancing, SSL و مسیریابی لایه 7 پشتیبانی میکنند. هر دوی این برنامه ها رایگان و متن باز هستند که با خرید اشتراک می توان از ویژگی های غنی تر و پشتیبانی آنها نیز استفاده کرد.NGINX و HAProxy هر دو برنامه های به بلوغ رسیده با ویژگی های متفاوت و کارایی بالایی هستند. میتوان آن ها را با افزونه هایی از سازنده های دیگر که به زبان Lua نوشته شده اند گسترش داد. NGINX همچنین کد نویسی تحت جاوا را با عنوان NGINX JavaScript پشتیبانی می کند.Service mesh ingress controller:اگر در سیستم مورد نظر از سرویس هایی مانند linkerd یا Istio استفاده می شود، از ویژگی هایی که توسط ingress controller برای چنین سرویس هایی فراهم شده میتوان استفاده کرد. به طور مثال Istio ingress controller از مسیریابی لایه 7، Http redirects، تلاش دوباره و ویژگی های دیگر استفاده می کند.معرفی ابزار ها در این فصل به توضیح کوتاهی درباره ی دو ابزار متن باز NGINX و HAProxy برای پراکسی معکوس در API Gateway می پردازیم.ابزار NGINXابزار NGINX یک وب سرور و سرویسی متن باز می باشد که می تواند همچنین به عنوان یک پراکسی معکوس نیز مورد استفاده قرار بگیرد و این ابزار در سال 2004 منتشر شده است. این ابزار می تواند با مدیریت درخواست ها به سرویس ها عمل به عنوان یک پراکسی معکوس باعث افزایش کارایی سیستم شود. در سال 2011 نیز توسط یک تیم، NGINX Plus معرفی شد که با خرید اشترک می توان از سرویس های بیشتر و قدرتمند تری نیز برای NGINX استفاده کرد.این ابزار اجازه ی نسبت دادن یک پردازه به یک کانکشن را نمی دهد، اما یک استخری از پردازه ها به وجود می آورد که میتواند درون شبکه میان کانشکن های متفاوت به اشتراک گذاشته شود. هر زمان که یک درخواست به وجود می آید، یک منبع برای انجام پردازه مورد نظرا تخصیص داده می شود. این روش باعث بهتر شدن بهروری در تخصیص منابع شده که میتوند کانکشن های پیچیده را مدیریت کند. نمای کلی NGINXمزایا و معایب NGINXمزایاکد بیس نوشته شده از ساختار بهتری نسبت به نرم افزار های مشابه برخوردار است.فرمت تنظیمات نسبتا راحتی داشته و طراحی به روز و مدرنی نسبت به موارد مشابه دارد.مبتنی بر رویداد بوده و بوده و امکان مدیریت چندین کانکشن را بدون داشتن سربار تغییر محتوا می دهد.منابع و حافظه ی کمتری استفاده می کند.باعث افزایش سرعت سایت شده و رنکینگ سایت را در گوگل افزایش می دهد.سازگاری بسیار زیادی با زبان های تحت وب مانند ruby، python و... نشان می دهد.به تبدیل محتوای پویا به ایستا کمک می کند.معایبنسبت به سرور Apache میزان حمایت کمتری از جامعه دارد ولی با این حال موارد استفاده آن بیشتر است ( به هر حال قسمت اولش عیب حساب میشه).نسب به Apache از ماژول های اضافه کمتری پشتیبانی می کند.دلایل استفاده از NGINXSingle entry point:درون محیطی که از کانتینر ها تشکیل شده است، میتوان آن ها را هر زمان که مورد نیاز است ساخت و یا نابود کرد. اما داشتن single entry point رویکردی بهتر برای دستری به سرویس ها می باشد. NGINX رویکرد بهتری برای انجام به وسیله ی این رویکرد می باشد. میتوان از NGINX در سرور ها به میزان نیاز استفاده کرد که میزان ترافیک و لود سرور را با یک آی پی پایدار مسیریابی کرد. سرور NGINX درخواست کاربر را سپس از کاربر گرفته و به کانتینر مورد نظر ارسال می کند.Caching:سرور NGINX یک کش برای محتوای استاتیک و پویا فراهم می کند که کارایی را افزایش می دهد. مسیریابی هر درخواست به میکروسرویس مربوطه هزینه بر می باشد. که میتوان با اضافه کردن کش برای هر میکروسرویس داده های مورد نظر را برای مدت محدودی ذخیره کرد و میزان بار روی سخت افزار بک اند را کاهش داد. این امر باعث می شود از اپلیکیشن ها در زمان ترافیک بالا محافظت شود و به درستی کار خود را بدون مخاطره انجام دهند.Multiple backend apps:خوشه ی NGINX کمک می کند که ترافیک را برای اپلیکیشن های مختلف به صورت کارا مدیریت کنیم در نتیجه بسیاری از ارائه دهنده های ابری آن را ترجیح میدهند. سرور NGINX برای پراکسی کردن ترافیک ورودی هر اندپوینت HTTP می باشد که هر کدام از درخواست ها را به سرویس مربوطه وصل می کند. همچنین این امکان را به وجود می آورد که قوانین را بدون هیچگونه downtime تغییر دهیم و NGINX را برای اپلیکیشن های پیچیده نیز مورد استفاده قرار دهیم.A/B testing:سرور NGINX یک ویژگی A/B تستینگ درون خود دارد که به به روز رسانه اپلیکیشن های مایکرو سرویس کمک خواهد کرد. هر زمان که یک اپلیکیشن مایکروسرویس در برنامه شما منتشر شود، می توان ترافیک را میان مقصد های متفاوت تقسیم کرد و مسیریابی بسیاری از کاربران را به این اپلیکیشن جدید انجام داد. این ویژگی امکان مانیتور کردن ترافیک و اندازه گیری KPI های مختلف را برای بررسی ورژن های متفاوت برنامه فراهم می کند که ببینیم کدام یک عملکرد بهتری داشت اند.Consolidated logging:سرور NGINX با یک فرمت استاندارد لاگ HTTP موجود است. این ویژگی امکان این را فراهم می کند که تمام ترافیک روی فرانت اند NGINX ذخیره شود به جای آن که لاگ های متفاوتی برای هر میکروسرویس داشته باشیم و آن ها را بعدا به هم اضافه کنیم. در نتیجه استفاده از NGINX باعث کم کردن پیچیدگی درست کردن و مدیریت لاگ ها می شود.Scalability and fault tolerance:ویژگی های توازن بار، بررسی سلامت سیستم موجود در NGINX اجازه میدهد تا مقیاس سخت افزار سمت سرور را زیاد و کم کنیم که اضافه کردن و حذف کردن میکروسرویس ها تاثیری بر تجربه ی کاربر نداشته باشد. اگر نیاز باشد تا میکروسرویس های بیشتری به سیستم اضافه شوند فقط لازم است به NGINX اطلاع داده شود که یک ویژگی جدید به استخر توازن بار اضافه شده است. که در صورت خرابی این نمونه NGINX ترافیک را به سمت این نسخه هدایت نکند و تا رفع اشکال از استفاده ی آن جلوگیری شود.Zero downtime:سرویس NGINX کار بدون اختلال نرم افزار را تضمین می کند. به صورتی که می توان سیستم را به روز رسانی کرد و یا ارتقا داد بدون این که خللی در اجرای برنامه و تجربه ی کاربر به وجود بیاید و یا زمان downtime داشته باشیم.Mitigate DoS attacks:این سرویس به مدیریت تعداد بالای درخواست های زیاد ترافیکی HTTP شناخته شده است که ایمنی اپلیکشن را در زمان ترافیک بالا تضمین کند و همچنین درخواست ها را به درستی ارسال کند. NGINX به عنوان یک نوسان گیر برای برنامه عمل میکند و ترافیک را کنترل کرده و API ها و URL های آسیب پذیر را از درخواست های بیش از حد محافظت می کند. این امر میتواند توسط یک محدودیت همزمانی و صف کردن درخواست ها میسر شود که از فشار روی سرور جلوگیری میکند.ابزار HAProxyاین ابزار بسیار شبیه به ابزار NGINX می باشد و به مدیریت درخواست های سرور اپلیکیشن برنامه می پردازد و ویژگی های کارامدی برای کنترل آن ها فراهم می کند.شرکت های ایرانی ارائه دهنده سرویسدر این بخش به معرفی شرکت های ایرانی در ارائه خدمات مدیریت API میپردازیم.1- شرکت Vasl : سرویس مدیریت API سورنا این شرکت ارائه دهنده سرویس های مدیریتی فروشگاه ها و شرکت ها و ارائه دهنده سرویس های مدیریتی API می باشد. با ارائه سرویس هایی مانند مانیتورینگ، امنیت و مدیریت درخواست های اپلیکیشن ها را فراهم می کند و باعث افزایش کیفیت و کارایی سایت میشود.2-شرکت دانش بنیان پلتکو: پلفورم مدیریت API این شرکت با ارائه پلفورمی یکپارچه برای خدمات اپلیکیشن های میکروسرویس باعث افزایش کنترل و عملکرد این سرویس ها میشود.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی استمنابعسایت پلتکوسایت وصلwikipediadocs.microsoftmediumyoutube Pooya Sabeti Pooya Sabeti Thu, 23 Dec 2021 14:51:14 +0330 https://virgool.io/@pooyasabeti97/%D9%86%D9%85%D8%A7%DB%8C%D8%B4-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%A7-%D9%85%D8%AF%D9%84-c4-ruyxbayklgh1 هر نرم افزار از قسمت ها و المان های مختلفی تشکیل شده که توسط معمار نرم افزار طراحی می شوند. در معماری نرم افزار یکی از چالش های اصلی نوع نمایش ساختار ها و اجزاء نرم افزار می باشد. از یکپارچه سازی مدل های نرم افزاری برای انتقال بهتر معماری نرم افزار و مستند سازی آن استفاده می شود.در این بحث، مدل های مختلفی طی سال های پیشرفت معماری نرم افزار ارائه شده اند. یکی از این مدل ها، مدل C4 می باشد. مدل C4 از لایه های مختلفی برای نمایش معماری نرم افزار استفاده می کند که این لایه ها درجه های متفاوتی از انتزاع معماری را نشان می دهند. دلیل نامگذاری این مدل نیز لایه هایی هستند که با این مدل از نرم افزار به نمایش گذاشته می شود که به ترتیب زیر می بشاند.مدل C4 توسط Simon Brown معرفی شد. این مدل هر معماری نرم افزاری را در 4 لایه به تصویر می کشد. هر لایه میزان درشت دانگی مصور کردن سیستم را نشان می دهد، لایه های آن به شرح زیر می باشد. در قدم اول کلیات اصلی و قدم های رسم نمودار را بررسی می کنیم و در مثالی یک سیستم بانکی را با این روش نمایش می دهیم.1- Contextاین لایه کلی ترین دید ازسیستم را به تصویر می کشد و مفهوم کلی سیستم، ارتباط و وابستگی های سیستم را به صورت درشت دانه مشخص می کند.2- Containersلایه دوم یک درجه ریز تر از لایه ی اول به بررسی محتویات داخل هر قسمت از بخش های کلی نرم افزار می پردازد. این لایه اجزاء کلی سیستم و تکنولوژی هایی که انتخاب شده را مشخص می کند. در این قسمت توجه شود که این Container با آن که با Docker است متفاوت می باشد.3- Componentsلایه ی سوم دید جزئی تری نسب به اجزاء به تصویر کشیده در لایه ی دوم دارد که این اجزا هر کدام به طور معمول یک وظیفه به خصوصی در نرم افزار به عهده دارند. مانند مصور کردن اجزاء بخش امنیت برنامه.4- Codeلایه ی آخر ریز دانه ترین لایه به محتویات تشکیل دهنده لایه ی قبل را بررسی میکند. این لایه معمولا از کد های نرم افزار تشکیل شده. مثالدر این قسمت اجزاء مختلف یک سیستم بانکی را با مدل C4 را به صورت مرحله به مرحله نمایش می دهیم. Banking System Contextدر مرحله ی اول کلی ترین نمای سیستم را رسم می کنیم. در این مثال برای نمایش یک سیستم بانکی کاربران سیستم که با این سیستم در ارتباط اند، خود سیستم بانکی اینترنتی و سیستم های دیگری که با سیستم اینترنتی بانک در ارتباط هستند نمایش داده می شود.Internet Banking System Componentsدر مرحله دوم سیستم بانکی را با دید اجزاء بررسی می کنیم و در نمودار سرویس هایی که درون سیستم بانکی وجود دارند به همراه سیستم های خارجی ای که هر کدام از این سرویس ها با آن در ارتباط هستند نمایش داده می شود.API Application Componentsدر مرحله سوم به طور مثال می خواهیم container مربوط به API Application را جزعی تر بررسی کنیم. اجزائ موجود درون آن را و ارتباطات درون آن و ارتباطات با container های خارجی را در این مرحله مشخص می کنیم.Mainframe Banking System Codeدر مرحله ی آخر درون هر کدام از component های مرحله ی قبل کد هایی هستند که آن را تشکیل می دهند. آن ها را در این مرحله با نمودار هایی مانند ER و وابستگی های تابعی آن کد ها نمایش می دهیم. معمولا در مدل C4 این مرحله به محیط های کد مربوط می شود و آن را به IDE های مربوطه واگذار می کنند. در مدلسازی نرم افزار با روش C4 سختی های نمایش نرم افزار از بین می رود و برای نشان دادن هر نوع انتزاع مد نظر یک سطح وجود دارد. این موضوع باعث می شود در انتقال این طراحی به تمامی تیم از منظر های مختلف معماری قابل نمایش باشد. همچنین تا حد مورد نیاز تیم مورد نظر را از جزئیات لازم مطلع می شود. این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.مراجعفیلم معرفی توسط Simon Brownسایت رسمی مربوط به روش C4&lt;br/&gt; Pooya Sabeti Pooya Sabeti Sat, 20 Nov 2021 19:23:24 +0330