سلام همکاران.
امروز ترجمه مقاله ای از Tugberk Ugurlu را به شما پیشنهاد می کنیم که متعهد شد در حجم نسبتاً کمی اصول طراحی سیستم های نرم افزاری مدرن را بیان کند. آنچه نویسنده در مورد خود به طور خلاصه می گوید:
از آنجایی که پوشش دادن چنین موضوع عظیمی مانند الگوهای معماری + الگوهای طراحی در سال 2019 در یک مقاله غیرممکن است، ما نه تنها متن خود آقای اوروگل، بلکه پیوندهای متعددی را که او با مهربانی در آن قرار داده است، توصیه می کنیم. اگر دوست داشتید، متن بسیار تخصصی تری در مورد طراحی سیستم های توزیع شده منتشر می کنیم.
عکس فوری از Unsplash
اگر تا به حال مجبور نبوده اید با چالش هایی مانند طراحی یک سیستم نرم افزاری از ابتدا روبرو شوید، پس هنگام شروع چنین کاری، گاهی اوقات حتی مشخص نیست که از کجا شروع کنید. من معتقدم که ابتدا باید مرزها را ترسیم کنید تا ایده ای کم و بیش مطمئن از اینکه دقیقاً چه چیزی را می خواهید طراحی کنید، داشته باشید و سپس آستین ها را بالا بزنید و در آن مرزها کار کنید. به عنوان نقطه شروع، می توانید یک محصول یا خدمات (در حالت ایده آل که واقعاً دوست دارید) را انتخاب کنید و نحوه اجرای آن را بیابید. ممکن است از اینکه این محصول چقدر ساده به نظر می رسد و در واقع چقدر پیچیدگی دارد شگفت زده شوید. فراموش نکن: ، و این اشکالی ندارد.
فکر می‌کنم بهترین توصیه‌ای که می‌توانم به هر کسی که شروع به طراحی یک سیستم می‌کند این است: هیچ فرضی نکن! از همان ابتدا باید حقایق شناخته شده در مورد این سیستم و انتظارات مرتبط با آن را مشخص کنید. در اینجا چند سوال خوب برای کمک به شما برای شروع طراحی وجود دارد:
- مشکلی که در صدد حل آن هستیم چیست؟
- حداکثر تعداد کاربرانی که با سیستم ما تعامل خواهند داشت چقدر است؟
- از چه الگوهای نوشتن و خواندن داده ها استفاده خواهیم کرد؟
- موارد شکست مورد انتظار چیست، چگونه می خواهیم با آنها برخورد کنیم؟
- انتظارات برای ثبات و در دسترس بودن سیستم چیست؟
- آیا هنگام کار باید الزامات مربوط به تأیید و مقررات خارجی را در نظر بگیرید؟
- قرار است چه نوع داده های حساسی را ذخیره کنیم؟
اینها تنها چند سوال است که هم برای من و هم برای تیم هایی که در طی سالیان فعالیت حرفه ای در آنها شرکت کرده ام مفید بوده است. اگر پاسخ این سؤالات را می دانید (و هر سؤال دیگری که مربوط به زمینه ای است که باید در آن کار کنید)، سپس می توانید به تدریج در جزئیات فنی مشکل تحقیق کنید.
سطح اولیه را تنظیم کنید
منظور من از "پایه" در اینجا چیست؟ در واقع، در زمان ما، اکثر مشکلات صنعت نرم افزار با استفاده از روش ها و فناوری های موجود قابل حل است. بر این اساس، با پیمایش در این منظره، زمانی که با مشکلاتی روبرو می شوید که شخص دیگری قبل از شما باید آنها را حل می کرد، شروع خاصی به دست می آورید. فراموش نکنید که برنامه ها برای حل مشکلات کسب و کار و کاربران نوشته شده اند، بنابراین ما در تلاش هستیم تا مشکل را به ساده ترین و ساده ترین راه (از دید کاربر) حل کنیم. چرا یادآوری این موضوع مهم است؟ شاید در سیستم مختصات خود دوست داشته باشید به دنبال راه حل های منحصر به فرد برای همه مشکلات باشید، زیرا فکر می کنید "اگر همه جا از الگوها پیروی کنم من چه نوع برنامه نویسی هستم"؟ در حقیقت، هنر اینجا تصمیم گیری در مورد اینکه کجا و چه کاری انجام شود. البته هر یک از ما هر از گاهی باید با مشکلات منحصر به فردی دست و پنجه نرم کنیم که هر کدام یک چالش واقعی هستند. با این حال، اگر سطح اولیه ما به وضوح تعریف شده باشد، آنگاه می دانیم که انرژی خود را روی چه چیزی خرج کنیم: جستجوی گزینه های آماده برای حل مشکلی که پیش روی ما گذاشته شده است، یا مطالعه بیشتر آن و به دست آوردن درک عمیق تر.
فکر می کنم توانستم شما را متقاعد کنم که اگر یک متخصص با اطمینان درک کند که مؤلفه معماری برخی از سیستم های نرم افزاری فوق العاده چیست، این دانش برای تسلط بر هنر یک معمار و ایجاد پایه ای محکم در این زمینه ضروری خواهد بود.
خوب، پس از کجا شروع کنیم؟ U در GitHub یک مخزن به نام وجود دارد ، که از طریق آن می توانید نحوه طراحی سیستم های در مقیاس بزرگ را بیاموزید و همچنین برای مصاحبه با این موضوع آماده شوید. مخزن یک بخش با مثال دارد ، که در آن، به طور خاص، نحوه رویکرد آنها به طراحی سیستم های خود در نظر گرفته می شود به عنوان مثال توییتر، اوبر و غیره.
با این حال، قبل از اینکه به سراغ این ماده برویم، بیایید نگاهی دقیق‌تر به مهم‌ترین چالش‌های معماری که در عمل با آنها روبرو هستیم، بیاندازیم. این مهم است زیرا شما باید بسیاری از جنبه های یک مشکل سرسخت و چند وجهی را مشخص کنید و سپس آن را در چارچوب مقررات موجود در یک سیستم معین حل کنید. کارمند سابق فیس بوک نوشت ، جایی که او تجربه خود از غربالگری صدها متقاضی را به اشتراک گذاشت. در حالی که این ویدئو به شدت بر طراحی سیستم های بزرگ و معیارهای موفقیت که هنگام جستجوی یک نامزد برای چنین موقعیتی مهم هستند، تمرکز دارد، همچنان به عنوان یک منبع جامع در مورد مواردی که هنگام طراحی سیستم ها مهم هستند، خدمت می کند. من هم پیشنهاد می کنم این ویدیو.
ایجاد دانش در مورد ذخیره و بازیابی داده ها
به طور معمول، تصمیم شما در مورد نحوه ذخیره و بازیابی داده های خود در دراز مدت تأثیر مهمی بر عملکرد سیستم دارد. بنابراین، ابتدا باید ویژگی های مورد انتظار نوشتن و خواندن سیستم خود را درک کنید. سپس باید بتوانید این شاخص ها را ارزیابی کنید و بر اساس ارزیابی های انجام شده انتخاب کنید. با این حال، تنها در صورتی می توانید به طور موثر با این کار کنار بیایید که الگوهای ذخیره سازی داده های موجود را درک کنید. در اصل، این حاکی از دانش جامد مربوط به .
پایگاه های داده را می توان به عنوان ساختارهای داده ای در نظر گرفت که بسیار مقیاس پذیر و بادوام هستند. بنابراین، هنگام انتخاب یک پایگاه داده خاص، دانش ساختارهای داده باید برای شما بسیار مفید باشد. مثلا، یک سرور ساختار داده است که انواع مختلفی از مقادیر را پشتیبانی می کند. این به شما امکان می دهد با ساختارهای داده مانند لیست ها و مجموعه ها کار کنید و داده ها را با استفاده از الگوریتم های شناخته شده بخوانید. ، سازماندهی چنین کارهایی به سبکی بادوام و بسیار در دسترس.
عکس فوری از Unsplash
هنگامی که درک کافی از الگوهای مختلف ذخیره سازی داده ها دارید، به مطالعه سازگاری و در دسترس بودن داده ها بروید. اول از همه، شما باید درک کنید حداقل به صورت کلی، و سپس با نگاهی دقیق تر به الگوهای تثبیت شده، این دانش را تقویت کنید и . به این ترتیب، درک درستی از این زمینه ایجاد خواهید کرد و متوجه خواهید شد که خواندن و نوشتن داده ها در واقع دو مشکل بسیار متفاوت هستند که هر کدام چالش های منحصر به فرد خود را دارند. با داشتن چند الگوی سازگاری و در دسترس بودن، می توانید عملکرد سیستم را به میزان قابل توجهی افزایش دهید و در عین حال از جریان روان داده ها به برنامه های خود اطمینان حاصل کنید.
در پایان، در پایان گفت و گو در مورد مسائل ذخیره سازی داده ها، باید به کش نیز اشاره کنیم. آیا باید به طور همزمان روی کلاینت و سرور اجرا شود؟ چه داده هایی در کش شما خواهد بود؟ و چرا؟ چگونه بی اعتباری کش را سازماندهی می کنید؟ آیا به طور منظم و در فواصل زمانی معین انجام خواهد شد؟ اگر بله، چند وقت یکبار؟ من توصیه می کنم شروع به مطالعه این موضوعات با پرایمر طراحی سیستم فوق
الگوهای ارتباطی
سیستم ها از اجزای مختلفی تشکیل شده اند. اینها می توانند فرآیندهای متفاوتی باشند که در یک گره فیزیکی اجرا می شوند، یا ماشین های مختلفی که در بخش های مختلف شبکه شما اجرا می شوند. برخی از این منابع در شبکه شما ممکن است خصوصی باشند، اما برخی دیگر باید عمومی و برای مصرف کنندگانی که از خارج به آنها دسترسی دارند باز باشد.
اطمینان از ارتباط این منابع با یکدیگر و همچنین تبادل اطلاعات بین کل سیستم و دنیای خارج ضروری است. در زمینه طراحی سیستم ها، در اینجا دوباره با مجموعه ای از چالش های جدید و منحصر به فرد روبرو هستیم. بیایید ببینیم چگونه می توانند مفید باشند ، و چه p.
عکس فوری از Unsplash
هنگام سازماندهی ارتباط با دنیای خارج، همیشه بسیار مهم است که ارائه آن نیز باید جدی و فعالانه پیگیری شود.
توزیع اتصال
من مطمئن نیستم که قرار دادن این موضوع در یک بخش جداگانه برای همه موجه به نظر برسد. با این وجود، من این مفهوم را به تفصیل در اینجا ارائه خواهم کرد، و معتقدم که مطالب این بخش با اصطلاح "توزیع اتصال" دقیق ترین توصیف شده است.
سیستم ها با اتصال صحیح بسیاری از مؤلفه ها شکل می گیرند و ارتباطات آنها با یکدیگر اغلب بر اساس پروتکل های ایجاد شده، به عنوان مثال، TCP و UDP سازماندهی می شوند. با این حال، این پروتکل‌ها اغلب برای پاسخگویی به تمام نیازهای سیستم‌های مدرن، که اغلب تحت بار زیاد کار می‌کنند و همچنین به شدت به نیازهای کاربر وابسته هستند، کافی نیستند. اغلب لازم است راه هایی برای توزیع اتصالات برای مقابله با چنین بارهای بالایی در سیستم پیدا شود.
این توزیع بر اساس شناخته شده است (DNS). چنین سیستمی اجازه می دهد تا تغییر نام دامنه مانند روش های گرد وزن و روش های مبتنی بر تأخیر به توزیع بار کمک کند.
اساساً مهم است و تقریباً هر سیستم اینترنتی بزرگی که امروزه با آن سروکار داریم در پشت یک یا چند بار متعادل کننده قرار دارد. متعادل کننده بار به توزیع درخواست های مشتری در چندین نمونه موجود کمک می کند. متعادل کننده های بار هم به صورت سخت افزاری و هم نرم افزاری عرضه می شوند، با این حال، در عمل، بیشتر اوقات باید با نرم افزارها سر و کار داشته باشید، به عنوان مثال и . از نظر مفهومی نیز بسیار شبیه به متعادل کننده بار است، اگرچه محدوده ای بین اول و دوم وجود دارد . این تفاوت ها باید در هنگام طراحی یک سیستم بر اساس نیاز شما در نظر گرفته شود.
شما همچنین باید در مورد (CDN). CDN یک شبکه توزیع شده جهانی از سرورهای پروکسی است که اطلاعات را از گره هایی که از نظر جغرافیایی نزدیک به یک کاربر خاص قرار دارند، ارائه می دهد. اگر با فایل های استاتیک نوشته شده در جاوا اسکریپت، CSS و HTML کار می کنید، CDN ها ترجیح داده می شوند. علاوه بر این، خدمات ابری که مدیران ترافیک را ارائه می دهند امروزه رایج هستند، به عنوان مثال، ، به شما توزیع جهانی و کاهش تاخیر را هنگام کار با محتوای پویا می دهد. با این حال، چنین خدماتی معمولاً در مواردی مفید هستند که مجبور هستید با وب سرویس‌های بدون دولت کار کنید.
بیایید در مورد منطق تجاری صحبت کنیم. ساختار منطق کسب و کار، جریان کار و اجزاء
بنابراین، ما موفق شدیم در مورد جنبه های مختلف زیرساختی سیستم بحث کنیم. به احتمال زیاد، کاربر حتی به تمام این عناصر سیستم شما فکر نمی کند و، صادقانه بگویم، اصلاً به آنها اهمیت نمی دهد. کاربر علاقه مند است که تعامل با سیستم شما چگونه است، با انجام این کار به چه چیزی می توان دست یافت، و همچنین چگونه سیستم دستورات کاربر را اجرا می کند، چه کاری و چگونه با داده های کاربر انجام می دهد.
همانطور که از عنوان این مقاله پیداست، من قصد داشتم در مورد معماری نرم افزار و طراحی سیستم صحبت کنم. بر این اساس، من قصد نداشتم الگوهای طراحی نرم‌افزاری را که نحوه ایجاد اجزای نرم‌افزار را توضیح می‌دهند، پوشش دهم. با این حال، هر چه بیشتر در مورد آن فکر می کنم، بیشتر به نظرم می رسد که مرز بین الگوهای طراحی نرم افزار و الگوهای معماری بسیار مبهم است و این دو مفهوم ارتباط نزدیکی با هم دارند. به عنوان مثال در نظر بگیریم (منبع رویداد). هنگامی که این الگوی معماری را اتخاذ کردید، تقریباً بر همه جنبه های سیستم شما تأثیر می گذارد: ذخیره سازی طولانی مدت داده ها، سطح سازگاری پذیرفته شده در سیستم شما، شکل اجزای موجود در آن و غیره و غیره. بنابراین، تصمیم گرفتم به برخی از الگوهای معماری اشاره کنم که مستقیماً با منطق تجاری مرتبط هستند. حتی اگر این مقاله باید خود را به یک لیست ساده محدود کند، من شما را تشویق می کنم که با آن آشنا شوید و درباره ایده های مرتبط با این الگوها فکر کنید. بفرمایید:
- از مفهوم ، به خصوص، ,
رویکردهای مشارکتی
بسیار بعید است که خود را در پروژه ای به عنوان شرکت کننده ای بیابید که تنها مسئول فرآیند طراحی سیستم است. برعکس، به احتمال زیاد مجبور خواهید بود با همکارانی که هم در داخل و هم در خارج از وظیفه شما کار می کنند تعامل داشته باشید. در این مورد، ممکن است لازم باشد راه حل های فناوری انتخاب شده را با همکاران ارزیابی کنید، نیازهای کسب و کار را شناسایی کنید و بفهمید که چگونه وظایف را به بهترین شکل موازی کنید.
عکس فوری از Unsplash
اولین گام این است که درک دقیق و مشترکی از هدف تجاری که می‌خواهید به آن برسید و با چه بخش‌های متحرکی باید دست و پنجه نرم کنید، ایجاد کنید. به ویژه تکنیک های مدل سازی گروهی (طوفان رویداد) به سرعت بخشیدن قابل توجهی به این روند و افزایش شانس موفقیت شما کمک می کند. این کار را می توان قبل یا بعد از طرح کلی انجام داد و سپس با بالغ شدن محصول آن را عمیق کنید. بر اساس سطح سازگاری که در اینجا به دست می آید، می توانید فرموله کنید برای زمینه محدودی که در آن کار می کنید. زمانی که لازم است در مورد معماری سیستم خود صحبت کنید، ممکن است برای شما مفید باشد ، پیشنهاد شده ، به خصوص زمانی که باید درک کنید که چقدر باید وارد جزئیات مشکل شوید و چیزهایی را که می خواهید با آنها ارتباط برقرار کنید تجسم کنید.
احتمالاً یک فناوری بالغ دیگر در مورد این موضوع وجود دارد که کمتر از Domain Driven Design مفید نیست. با این حال، ما به نوعی به درک حوزه موضوعی، بنابراین دانش و تجربه در این زمینه باز می گردیم باید برای شما مفید باشد
منبع: www.habr.com