تجربه یه incident با رعایت نکردن اصول ساده

خیلی وقت ها پیش میاد که ما یه سری نکته ساده رو رعایت نمی کنیم و همین موضوع باعث میشه که مشکلات بزرگی در سیستم رخ بده.

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

قبل از اینکه شرح بدم incident چی بود در مورد root cause صحبت می کنم که تابع Get از پکیج net/http بود. خیلی هاتون ممکنه برای ارسال درخواست های http در گولنگ از این تابع استفاده کنید و خیلی کار رو هم ساده می کنه.

https://pkg.go.dev/net/http#Get


اسم سرویس ها یه چیز دیگه ست من ساده سازی کردم.
یه سرویس اصلی رو در نظر بگیرید که وقتی درخواست بهش میرسه، ابتدا یه سری اطلاعات رو از طریق یه درخواست http از یه سرویس خارجی دریافت میکنه و بعد پاسخ درخواست کاربر رو پس میده.
حالا تصور کنید این سرویس کارهای دیگه ای هم انجام میده، مثلا همین سرویس برای انجام paymentها یه ماژول پرداخت داره که باز هم از درخواست های http استفاده میکنه که با ipgها صحبت کنه و پرداخت هارو انجام بده.

این سرویس با همین مشخصات روی پروداکشن زیر لود بود که فهمیدیم سرویس خارجی ای که اطلاعات رو ازش میگیریم خیلی latency بالایی داره و همین باعث شده درخواست های زیادی باز بمونن برای مدت طولانی و مصرف رم و cpu سرویس بالا رفته و پاسخ ها دچار response time بالا شدن.

اولین نکته ای که به ذهن میرسه اینه که خب بهتره از context timeout استفاده کنیم برای درخواست ها که مثلا یه درخواست http به سرویس خارجی بیشتر از ۳۰ ثانیه باز نمونه.
که خب تابع Get خودش ورودی context نمیگیره، پس باید به فکر راه دیگه ای بود.
برنامه نویس فهمیده بود که تابع Get داره از http.DefaultClient استفاده میکنه و این client یه فیلد timeout داره، پس خیلی سریع تایم اوت رو ست کرد، به این صورت

http.DefaultClient.Timeout = time.Second * 5

کد دیپلوی شد و رفت روی پروداکشن، اتفاقی که افتاد این بود که دیگه مشکل response time وجود نداشت برای سرویس خارجی و اگه درخواست بیشتر از ۵ ثانیه طول میکشید کنسل میشد.

اما یه مشکل جدید خیلی بد بوجود اومده بود، ماژول پرداخت به فنا رفته بود و نمیتونست پرداخت هارو درست مدیریت کنه.

علت چی بود؟‌ علت این بود که اونم داشت از http.Get استفاده میکرد و با تنظیم شدن تایم اوت ۵ ثانیه، اونم درخواست های بیشتر از ۵ ثانیه رو کنسل میکرد.

خب خیلی ها شنیدید که الگوی singleton خیلی جاها میتونه bad practice باشه و یکی از اون جاها همین default http clientی هست که پکیج net/http ارائه میده.

درست ش این بود که هر ماژول برای درخواست های خودش یه http client مجزا داشته باشه که تایم اوت خاص خودش رو ست کنه. حتی میشه از این تابع NewRequestWithContext
استفاده کرد که context رو هم پشتیبانی کنه.

https://pkg.go.dev/net/http#NewRequestWithContext


مشکل singleton اینه که side effectهای تغییر singleton object مبهم میشه، شما میای برای درخواست های سرویس خارجی تایم اوت ست کنی، ولی عملا درخواست های پرداخت رو به فنا میدی..

پکیج net/http و پکیج های دیگه گولنگ برای راحتی استفاده خیلی وقت ها یه default object ارائه میدن، ولی واقعا باید برای استفاده از این objectها احتیاط کرد. بهتره instance خاص خودت رو بسازی که مدیریت stateش فقط خودت رو تحت تاثیر بذاره و side effect نداشته باشه.

#gocast | #hossein
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

در نسخهٔ ۱.۲۴ زبان Go، اشاره‌گرهای ضعیف (Weak Pointers) معرفی شده‌اند که امکان ارجاع به اشیاء در حافظه را بدون جلوگیری از جمع‌آوری آن‌ها توسط جمع‌کنندهٔ زباله (Garbage Collector) فراهم می‌کنند.

مزیت اصلی اشاره‌گرهای ضعیف:

اشاره‌گرهای ضعیف به شما اجازه می‌دهند به اشیائی در حافظه اشاره کنید بدون اینکه مانع جمع‌آوری آن‌ها توسط جمع‌کنندهٔ زباله شوید. این ویژگی در ساختارهایی مانند کش‌ها (Caches) یا نقشه‌های هم‌ارزی (Canonicalization Maps) مفید است، جایی که می‌خواهید تنها یک نسخه از داده‌ها را نگه دارید و در عین حال اجازه دهید داده‌های غیرضروری به‌طور خودکار از حافظه حذف شوند.

مثال: ساخت یک کش با استفاده از اشاره‌گرهای ضعیف

فرض کنید می‌خواهیم یک کش ایجاد کنیم که داده‌های موقت را ذخیره کند و اجازه دهد جمع‌کنندهٔ زباله داده‌های غیرضروری را حذف کند:

package main

import (
    "fmt"
    "runtime"
    "sync"
    "time"
    "weak"
)

// Cache ساختار کش با اشاره‌گرهای ضعیف
type Cache[K comparable, V any] struct {
    mu    sync.Mutex
    items map[K]weak.Pointer[V]
}

// NewCache ایجاد یک نمونهٔ جدید از کش
func NewCache[K comparable, V any]() *Cache[K, V] {
    return &Cache[K, V]{
        items: make(map[K]weak.Pointer[V]),
    }
}

// Get بازیابی یک آیتم از کش در صورت موجود بودن
func (c *Cache[K, V]) Get(key K) (*V, bool) {
    c.mu.Lock()
    defer c.mu.Unlock()

    ptr, exists := c.items[key]
    if !exists {
        return nil, false
    }

    val := ptr.Value()
    if val == nil {
        delete(c.items, key)
        return nil, false
    }
    return val, true
}

// Set افزودن یک آیتم به کش
func (c *Cache[K, V]) Set(key K, value V) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.items[key] = weak.Make(&value)
}

func main() {
    // ایجاد کش با کلیدها و مقادیر رشته‌ای
    cache := NewCache[string, string]()

    // افزودن یک داده به کش
    data := "cached data"
    cache.Set("key1", data)

    // بازیابی داده
    if val, ok := cache.Get("key1"); ok {
        fmt.Println("Cache hit:", *val)
    } else {
        fmt.Println("Cache miss")
    }

    // شبیه‌سازی از دست دادن ارجاع قوی
    data = ""
    runtime.GC() // اجرای جمع‌کنندهٔ زباله

    // تلاش برای بازیابی مجدد داده
    time.Sleep(1 * time.Second)
    if val, ok := cache.Get("key1"); ok {
        fmt.Println("Cache hit:", *val)
    } else {
        fmt.Println("Cache miss")
    }
}

در این مثال:

ساختار Cache از یک نقشه با اشاره‌گرهای ضعیف برای ذخیرهٔ داده‌ها استفاده می‌کند.

با استفاده از weak.Make، یک اشاره‌گر ضعیف به داده ایجاد می‌شود.

در صورت عدم وجود ارجاع قوی به داده، جمع‌کنندهٔ زباله می‌تواند آن را حذف کند و ptr.Value() مقدار nil برمی‌گرداند.


مزایای استفاده از اشاره‌گرهای ضعیف در این سناریو:

کارایی حافظه: اشیائی که دیگر استفاده نمی‌شوند، توسط جمع‌کنندهٔ زباله حذف می‌شوند و مصرف حافظه کاهش می‌یابد.

پاک‌سازی خودکار: نیازی به پیاده‌سازی منطق پیچیده برای حذف دستی داده‌های قدیمی نیست.

ایمنی در برابر شرایط رقابتی: اشاره‌گرهای ضعیف به‌طور مؤثر در ساختارهای ایمن در برابر شرایط رقابتی مانند Cache استفاده می‌شوند.


با استفاده از اشاره‌گرهای ضعیف، می‌توان کش‌هایی ساخت که به‌طور خودکار داده‌های غیرضروری را حذف کرده و کارایی حافظه را بهبود بخشند.

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

🚀 پکیج algo مجموعه‌ای از الگوریتم‌های پرفورمنس بالا و بهینه

سعی کردم در این پکیج یکسری الگوریتم های خاص بصورت بهینه و با بدون وابستگی به dependency های خارجی قرار دهم و فعلا یک الگوریتم را توسعه دادم و بزودی برخی الگوریتم های دیگر نظیر Reservoir Sampling, Consistent Hashing و برخی دیگر را قرار دهم.

در حال حاضر الگوریتم زیر را تکمیل کردم و قرار دادم.

✅ انتخاب تصادفی وزنی (Random Weighted Selection)

📌 مشاهده پکیج و مستندات:
🔗 گیت‌هاب: https://github.com/Ja7ad/algo
📚 مستندات: https://pkg.go.dev/github.com/Ja7ad/algo

🔥 خوشحال می‌شوم نظرات و پیشنهاداتتان را بشنوم! اگر علاقه‌مند به مشارکت در توسعه این پکیج هستید، PR بفرستید! 💡

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

If in TDD you trust, don’t proselytize it. TDD is a personal practice.

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

A Crash Course on Load Balancers for Scaling

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

Software Architecture Patterns

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

The Saga Pattern

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

The Sidecar Pattern Explained_ Decoupling Operational Features

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

A Crash Course on Scaling the Data Layer

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

A Pattern Every Modern Developer Should Know_ CQRS

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

API Gateway

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

نوآوری DeepSeek و تهدید آن برای Nvidia

مشکل اصلی: آموزش مدل‌های هوش مصنوعی بسیار پرهزینه است. شرکت‌هایی مانند OpenAI و Anthropic بیش از ۱۰۰ میلیون دلار برای پردازش و آموزش مدل‌هایشان هزینه می‌کنند و به هزاران GPU گران‌قیمت نیاز دارند.

نوآوری DeepSeek: این شرکت با ۵ میلیون دلار و تنها ۲,۰۰۰ GPU مدل‌هایی ساخته که در بسیاری از وظایف عملکردی مشابه یا بهتر از GPT-4 و Claude دارند.

چگونه؟

- کاهش حافظه مورد نیاز تا ۷۵٪ با استفاده از اعداد ۸ بیتی به جای ۳۲ بیتی.
- پردازش چندتُکنی (Multi-Token) که سرعت را ۲ برابر کرده و دقت را در حد ۹۰٪ مدل‌های سنتی نگه می‌دارد.
- سیستم متخصصین (Expert System): به جای یک مدل عظیم که همیشه ۱.۸ تریلیون پارامترش فعال است، DeepSeek فقط ۳۷ میلیارد پارامتر را در لحظه اجرا می‌کند.

نتایج شگفت‌انگیز:

- هزینه آموزش از ۱۰۰ میلیون دلار → ۵ میلیون دلار
- تعداد GPU موردنیاز از ۱۰۰,۰۰۰ → ۲,۰۰۰
هزینه API ۹۵٪ ارزان‌تر
- امکان اجرا روی کارت‌های گرافیک گیمینگ معمولی

چرا این برای Nvidia خطرناک است؟

انودیا کسب‌وکارش را روی فروش GPUهای فوق‌العاده گران‌قیمت با ۹۰٪ حاشیه سود بنا کرده است. اگر مدل‌های AI بتوانند با کارت‌های گیمینگ معمولی اجرا شوند، بازار Nvidia دچار تحول اساسی می‌شود.

تحول در صنعت:

هوش مصنوعی ارزان‌تر و در دسترس‌تر می‌شود.
شرکت‌های بزرگ مانند OpenAI دیگر انحصار بازار را ندارند.
نیاز به سخت‌افزار گران‌قیمت کاهش می‌یابد.
این لحظه مانند ظهور رایانه‌های شخصی یا رایانش ابری است—یک نقطه عطف بزرگ!

نتیجه:

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

منبع
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

CAP, PACELC, ACID, BASE - Essential Concepts for an Architect’s Toolkit

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

Database Performance Demystified_ Essential Tips and Strategies

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

Data Sharing Between Microservices

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

پروپوزال استفاده از علامت ? برای ساده‌سازی مدیریت خطا در زبان Go

پیشنهادی برای کاهش کدهای تکراری در مدیریت خطاها در زبان Go ارائه شده است که استفاده از علامت ? را معرفی می‌کند. این علامت به برنامه‌نویسان اجازه می‌دهد تا بررسی خطاها را به صورت مختصرتر و خواناتر انجام دهند. به عنوان مثال، به جای نوشتن:

r, err := SomeFunction()
if err != nil {
    return fmt.Errorf("something failed: %v", err)
}

می‌توان از این نحو جدید استفاده کرد:

r := SomeFunction() ? {
    return fmt.Errorf("something failed: %v", err)
}

در این ساختار، اگر مقدار بازگشتی خطا (err) نال نباشد، بلوک کد پس از ? اجرا می‌شود و متغیر err به صورت ضمنی در این بلوک تعریف می‌شود. همچنین، اگر بلوک کد پس از ? حذف شود، به صورت پیش‌فرض خطا بازگردانده می‌شود:

SomeFunction2() ?

این پیشنهاد با هدف کاهش کدهای تکراری و بهبود خوانایی کدهای مدیریت خطا در زبان Go مطرح شده است.


https://github.com/golang/go/discussions/71460

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

Distributed Caching_ The Secret to High-Performance Applications

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

Event-Driven Architectural Patterns

#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers

🚀 پروپوزال Go: بسته‌ی جدید sync/v2

هدف این پکیج نسخه دوم, معرفی نسخه‌های بهبودیافتهٔ انواع Map و Pool با استفاده از پارامترهای نوع (Generics) است تا ایمنی نوع در زمان کامپایل و کارایی بهتری فراهم شود. در نسخهٔ جدید، نوع Pool دیگر فیلد New صادرشده ندارد؛ به‌جای آن، از تابع NewPool برای ایجاد Pool استفاده می‌شود که تابعی را برای بازگرداندن مقادیر جدید فراخوانی می‌کند. همچنین، متد Get به‌روزرسانی شده و اکنون دو نتیجه بازمی‌گرداند؛ نتیجهٔ دوم یک مقدار بولی است که نشان می‌دهد آیا مقداری بازگردانده شده است یا خیر.

تغییرات کلیدی:

✅ حذف فیلد New در Pool
به‌جای مقداردهی مستقیم New، اکنون از NewPool استفاده می‌شود:

p := sync.NewPool(func() *MyType {
    return new(MyType)
})

v, ok := p.Get()
if !ok {
    v = new(MyType) // در صورت خالی بودن، مقدار جدید ساخته شود
}

نسخه جنریک

var m sync.Map[string, int]
m.Store("key", 42)
v, ok := m.Load("key") // v مقدار int است

🔗 جزئیات بیشتر در گیت‌هاب

➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers