اوراق آرگو
92 subscribers
23 photos
9 videos
4 files
134 links
جایی برای موضوعات جذاب
Download Telegram
برگشتم بعد از یک ماه😃✌️🏽
🔥1
Forwarded from Gopher Academy (𓄂👑𓆃)
📥 دریافت شده از: Vesal Behrouzi
-------------

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


🕊 @gopher_academy
MIT’s course on Software Construction sums up the reasons why: "Immutable types are safer from bugs, easier to understand, and more ready for change. Mutability makes it harder to understand what your program is doing, and much harder to enforce contracts"

https://web.mit.edu/6.031/www/fa20/classes/08-immutability/
Spotify Engineering recently open-sourced Voyager, an approximate nearest-neighbor (ANN) search library. Voyager is based on the hierarchical navigable small worlds (HNSW) algorithm and is 10 times faster than Spotify's previous ANN library, Annoy.


https://spotify.github.io/voyager/
Spring Cloud Config is Spring’s client/server approach for storing and serving distributed configurations across multiple applications and environments. This configuration store is ideally versioned under Git version control and can be modified at application runtime

https://www.baeldung.com/spring-cloud-configuration
Imagine a given range of numbers overlaid on a circle. We apply a hash function to balls and a separate hash function to bins to obtain numbers in that range that correspond to positions on that circle. We then start allocating balls in a specific order independent of their hash values (let’s say based on their ID). Then each ball is moved clockwise and is assigned to the first bin with spare capacity

https://blog.research.google/2017/04/consistent-hashing-with-bounded-loads.html
خطا داریم؟ همینه که هست!

یه مثال دیدم که می‌گفت شما وقتی ماشینتون پنچر میشه صبر می‌کنید تا تعمیرکار بیاد درستش کنه، یا با همون چرخ های پنجر با سرعت کم ادامه میدین تا به مقصد برسید؟

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

در یک برنامه معمولی جوابِ (احتمالا) درست به خیلی از این سوالا اینه که خب کارکرد برنامه رو متوقف کن و بگو نمیتونم. برنامه کار نکنه تا دوباره با برطرف شدن مشکلات یکی از اول اجراش کنه،
ولی اگر برنامه ما قراره توی یکسری از محیط‌ها اجرا بشه دیگه خبری از «من کار نمیکنم تا شرایط درست بشه» نیست. چه محیط‌هایی؟ محیط‌هایی که availability بالا مهمه مثلا سیستم های امبدد یا بک‌اند.
مثلا قراره ما مسیریابی یک هواپیما رو انجام بدیم و سیگنال GPS دریافت نمی‌کنیم، خب به هواپیما بگیم فعلا من کار نمیکنم؟! یعنی چی که کار نمیکنم، با سرعت زیاد داره میره :)))
یا مثلاً توی کلود اگر ارور بدیم و برنامه کرش کنه کنیم چی میشه؟ کوبرنتیز دوباره برنامه رو اجرا می‌کنه و دوباره با مشکل درگیریم!

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

مثلا چه مشکلاتی؟
مثلاً اگه قراره کانفیگ فایل رو از بیرون لود کنیم, آمادگی نبودنش رو هم داشته باشیم، مثلا یه کانفیگ پیشفرض داشته باشیم (البته کانفیگ چون موقع اولین اجرای برنامه خودش رو نشون میده شاید نیازی هم نباشه)
مثلا اگر داده gps به ما نرسید، با کمک داده های قبلی که ذخیره کردیم و یا ترکیبش با سرعت و شتاب و ... مشکل رو موقتا و حتی نادقیق حل کنیم
یا مثلاً اگر به سرور خارجی درخواست می‌زنیم و نیست، آمادگی نبودنش رو داشته باشیم، اینجا یکسری پترن که تو صنعت استفاده میشه داریم
مثلا چه پترنهایی؟
+ دوباره درخواست بده: retry pattern
+ به یکی دیگه درخواست بده: fallback
+ اگر خرابه تا یه مدت بهش درخواست نده تا ارور الکی نگیری: circuit breaker
+ اگه سرور خارجی کنده، خیلی صبر نکن تا response time خودت هم بالا نره
+ اگر سرور خارجی دیتا قراره بهت بده، دیتای قبلی رو کش کن.

اینها در سطح کد بودن، در سطح معماری هم میشه از قبل روش‌هایی رو تدارک دید مثلاً خود دیتابیس رو چطوری High available کنیم، یا روش‌هایی که بیشتر تو سیستم های امبدد استفاده میشه مثل اینکه یه برنامه رو با چند تا پیاده سازی همزمان اجرا کنیم تا اگر یکیش خراب شد اون یکی‌ها باشن!

منابع:
https://opensource.com/article/19/9/transient-faults-devops

https://www.jrebel.com/blog/microservices-resilience-patterns

https://learn.microsoft.com/en-us/azure/architecture/best-practices/transient-faults

https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/application-resiliency-patterns
👍1