5 مبارزه برتر توسعه دهندگان Backend

“وب یک دستگاه ورودی/خروجی است”

… همانطور که عمو باب توصیف می کند.

I/O، ورودی / خروجی، *یعنی *ورودی کاربر و خروجی سرور.

کاربران می خواهند از طریق برنامه ها یا وب سایت ها به برخی از داده ها دسترسی داشته باشند.

آنها می خواهند آن را در سراسر جهان در دسترس باشد.

اگر الزامات بسیار ساده هستند، چرا توسعه Backend اینقدر چالش برانگیز است؟ این یک سوال عالی است که من می خواهم خوشبختانه در این پست پاسخ دهید اما بیشتر از آن، این پست باید فضایی غم انگیز برای توسعه دهندگان سخت کوش باشد.

بیایید به یک نمودار ساده از یک سرور باطن نگاهی بیندازیم.

همه چیز از بیرون ساده به نظر می رسد. اما در پشت پرده اتفاقات زیادی می افتد. در پایان، به دلیلی به آن توسعه “باطن” می گویند.

وظیفه یک توسعه دهنده باطن این است که همه چیز را حداقل از منظر کاربر به طور یکپارچه انجام دهد.

بنابراین، در اینجا لیست من از 5 مبارزه برتر توسعه دهندگان باطن است.

مبارزه 1: خرابی سرورها!

توسعه دهندگان Backend باید همیشه به خود یادآوری کنند:

سرور در هر لحظه از زمان می تواند از کار بیفتد

این فقط سرور نیست، ردهای غیرقابل کنترل، مشکلات شبکه و موارد بی‌شماری دیگر می‌توانند باعث خرابی برنامه شوند.

این لیستی از اشتباهات سیستم های توزیع شده است:

• شبکه قابل اعتماد است
• تاخیر صفر است
• پهنای باند بی نهایت است
• شبکه امن است
• توپولوژی تغییر نمی کند
• یک مدیر وجود دارد
• هزینه حمل و نقل صفر است
• شبکه همگن است

آنها بیش از یک ناراحتی برای توسعه backend هستند.

در حال حاضر نوشتن برنامه هایی که به درستی کار می کنند دشوار است. اکنون باید سناریوهای شکست را نیز در نظر بگیرید و برنامه را بسازید خطاپذيري.

مبارزه 2: مقیاس پذیری

جنبه های مختلفی از مقیاس پذیری وجود دارد، اما اجازه دهید به خاطر این پست همه چیز را ساده نگه داریم.

یک برنامه مقیاس پذیر حتی اگر بار به طور قابل توجهی افزایش یابد می تواند به کار خود ادامه دهد.

سرورها ظرفیت محدودی دارند و فقط می توانند تعداد محدودی از درخواست ها را رسیدگی کنند.

• اگر منابع بیشتری را به سرور اضافه کنید، می تواند درخواست های بیشتری را انجام دهد ( مقیاس بندی عمودی ).
• اگر سرورهای بیشتری به سیستم اضافه کنید، می توانند درخواست های بیشتری را رسیدگی کنند ( مقیاس بندی افقی).

طراحی یک اپلیکیشن به گونه ای که به صورت افقی مقیاس پذیر باشد، فوراً روش کار را تغییر می دهد.

به عنوان مثال، اکثر توسعه دهندگان باطن در برنامه های مقیاس پذیر – از جمله خود من – در شرایط مسابقه اشتباه می کنند. *در یک برنامه مقیاس پذیر، داده ها را می توان توسط چندین سرور خوانده یا اصلاح کرد. یک مثال معمولی:

• سرور A داده ها را می خواند { foo: 1 }
• سرور B داده ها را می خواند { foo: 1 }
• سرور A داده ها را اصلاح می کند و می نویسد: { foo: 1, bar: 2 }
• سرور B داده ها را تغییر می دهد و می نویسد: { foo: 1, baz: 2  }

نتیجه می تواند هر دو باشد { foo: 1, bar: 2 } یا { foo: 1, baz: 2  } بسته به اینکه کدام سرور اطلاعات را آخرین بار می نویسد. بنابراین، هر دو سرور در یک هستند شرایط مسابقه!

این فقط یک مثال بود، اما هنگام توسعه یک برنامه کاربردی مقیاس پذیر افقی باید موارد زیادی را در نظر گرفت.

مبارزه 3: امنیت

به یاد داشته باشید که یک سرور عمومی در اینترنت برای همه قابل دسترسی است.

و، بازیگران بد زیادی در بیرون وجود دارند 🥷.

بازیگران بد می توانند درخواست های ویژه ای برای استخراج اطلاعات از یک سرور آسیب پذیر ایجاد کنند.

به https://owasp.org/www-project-top-ten/ سر بزنید تا ببینید آن بازیگران بد چه نوع جادویی با سرورهای شما انجام می دهند.

حتی کاربران قانونی را باید از منظر توسعه دهندگان باطن بازیگران بد در نظر گرفت.

کاربران قانونی ممکن است از سرویس سوء استفاده کنند یا ورودی های غیرمنتظره ای را برای سوء استفاده از آسیب پذیری های سرور ارسال کنند. تمام ورودی های کاربر باید ضد عفونی شوند تا از ورودی های غیرمنتظره کاربران قانونی جلوگیری شود. تعاریف طرحواره، مانند طرحواره JSON، برای پاکسازی ورودی کاربر بسیار مفید است.

همچنین کاربران قانونی مجاز به انجام هر کاری که می خواهند نیستند. این سرویس باید دارای یک سیستم مجوز کاملاً تعریف شده باشد تا از دسترسی کاربران به منابع ممنوعه جلوگیری کند.

سرور ممکن است در برابر a آسیب پذیر باشد خود داری از خدمات حمله کنند. اکثر حملات DoS را می توان با محدود کردن نرخ جلوگیری کرد.

این لیست ادامه دارد و حقیقت این است که هیچ سروری نمی تواند 100٪ ایمن باشد. سعی کنید تا حد امکان بهترین روش ها را برای ایمن سازی سرورهای خود دنبال کنید.

مبارزه 4: ثبات

اگر ماشین قرمز است، پس قرمز است.

افراد دیگر نیز باید به شما بگویند که ماشین قرمز است.

و هیچ کس نباید بگوید که ماشین قرمز نیست.

سپس در نظرات به من بگویید …
https://en.wikipedia.org/wiki/The_dress
… رنگ این لباس چیست؟ سیاه و آبی است یا سفید و طلایی؟ هر کدام را که انتخاب کنید، از دیدن دیگران که قسم می‌خورند آن دیگری است، متعجب خواهید شد!

ببینید، گاهی اوقات رسیدن به یک پاسخ واقعی برای چنین سوال اساسی خیلی آسان نیست.

در اصطلاح کامپیوتری، این لباس می‌تواند سندی باشد که از یک حافظه پنهان خوانده می‌شود، یک نمونه تکراری آهسته از یک پایگاه داده، یا یک پایگاه داده منبع رویداد.

در همه موارد، داده ها ممکن است منسوخ شده باشند. یک سرور ممکن است داده های منسوخ را بخواند در حالی که دیگری به نسخه جدیدتر سند دسترسی داشته باشد.

مبادله: ثبات و عملکرد

مشکل سازگاری این است که بازیابی آخرین اطلاعات ممکن است راه حل بهینه برای اکثر موارد نباشد.

به عنوان مثال، اگر هزاران نفر به طور همزمان سعی کنند به یک توییت محبوب دسترسی پیدا کنند، چه چیزی را می بینند؟ همان محتوای توییت، به جز تعداد خوانده شده، احتمالاً تفاوت زیادی با یکدیگر دارند.

این نتیجه یک تصمیم طراحی است. مهندسان توییتر تصمیم گرفتند به بهای نمایش تعداد خوانده شده منسوخ شده، بین عملکرد و ثبات معامله کنند. این یک معامله بسیار خوب است زیرا تعداد خوانده شده بخش مهمی از توییت ها نیست.

اطلاعات بیشتر درباره سازگاری

خوب، گاهی اوقات ناهماهنگی ها به دلیل تصمیمات طراحی نیست، بلکه به دلیل روش کار در مهندسی نرم افزار اتفاق می افتد.

مثال قبلی در مورد شرایط مسابقه را به خاطر دارید؟ خوب، چگونه آن را اداره می کنید؟ شما ممکن است از قفل استفاده کنید، اما ممکن است پرهزینه باشد (از نظر زمان). برخی از سیستم ها از قفل خوش بینانه برای گرفتن نتایج بهتر استفاده می کنند. برخی دیگر از سیستم ها از منبع رویداد استفاده می کنند و به طور کامل از مشکل فرار می کنند.

سپس مشکل سازگاری مشتری و باطن وجود دارد. پایگاه داده مشتری باید با داده های واقعی در backend سازگار باشد. اگر می خواهید در مورد سازگاری بیشتر بخوانید، در اینجا یک مقاله خوب است: https://medium.com/ssense-tech/handling-eventual-consistency-with-distributed-system-9235687ea5b3

مبارزه 5: عملکرد

من فکر می کنم این یکی کاملا واضح است. همه می خواهند برنامه های کاربردی باطنی فوق العاده سریع توسعه دهند.

اما، این کار آسانی نیست. از انتخاب زبان و چارچوب گرفته تا الگوریتم‌های مورد استفاده و طراحی کلی سیستم، تقریباً همه چیز بر عملکرد تأثیر دارد.

من می گویم بهترین اقدام این است:

1. از ابزار تست عملکرد مانند k6 استفاده کنید
2. اگر برنامه دارای معیارها باشد، زمان را برای بهینه سازی فوق العاده تلف نکنید

به همین سادگی است…

…برای مشاوره از پست وبلاگ 😅

در واقعیت، اندازه گیری عملکرد برنامه تا حدودی پیچیده است. شاید بتوانید به راحتی عملکرد انتها به انتها نقاط پایانی خود و غیره را اندازه گیری کنید.

اما تشخیص گلوگاه واقعی در برنامه شما بدون ابزارهای قابل مشاهده دشوار است.

در برنامه‌های کاربردی RESTful، یک حلقه for یا یک الگوریتم اصلی در کد به ندرت گلوگاه است. بهینه سازی پرس و جوهای پایگاه داده، تنظیمات شبکه یا طراحی API معمولاً مزایای بیشتری دارند.

خلاصه

مبارزه برای توسعه دهندگان باطن واقعی است. مبارزات خود را در نظرات به اشتراک بگذارید و به دیگران نشان دهید که تنها نیستند!

امیدوارم از این پست لذت برده باشید، برای موارد بیشتر در این مورد مشترک شوید.