دوستان اگه اپلیکیشن رو بصورت مونولیت مینیوسید، کار خوبی میکنید، اما aggregation pattern رو جدی بگیرید، کمک بزرگی میکنه به حفظ loosely coupled بودن ماژول و سرویس هاتون.
یه اشتباه رایجی که باعث میشه خیلی راحت همه چیز در هم تنیده و coupled بشه نیازهای بیزینسی ای هست که دیتای aggregate شده از چند domain مختلف رو میخواد از شما. تو حالت مونولیت خیلی ساده ست که شما در هر domain به دیتابیس یه domain دیگه درخواست بزنی و یا حتی تو interactor/service دیگه یه متد جدید تعریف کنی که دیتای مد نظر رو بده. که معمولا باعث در هم تنیده شدن و چاق شدن سرویس هاتون میشه.
بهتره سرویس یا همون interactorهاتون کارهای خیلی کوچیک و well-definedی رو انجام بدن و اگه نیازمندی های aggregationطور دارید، یه سری service دیگه بسازید که وابستگی خواهد داشت به سرویس های مختلف و دیتاهای raw رو میگیره و پردازش میکنه که دیتای نهایی رو آماده کنه.
بعضی وقت ها از طریق gateway هم ممکنه بتونید aggregate کنید. بعضی وقت ها ممکنه تو همون لایه دلیوری (کنترلر) تون بتونید دو تا سرویس رو فراخوانی کنید و کار رو در بیارید، گاهی هم پیچیده تر میشه و لازمه یه سرویس(interactor) بنویسید که کار aggregation رو انجام بده
https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation
باز خود aggregate کردن حالت های مختلفی داره، اینجا میتونید بیشتر بخونید در موردش
https://medium.com/geekculture/design-patterns-for-microservices-aggregation-pattern-1b8994516fa2
#gocasts | #hossein
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
یه اشتباه رایجی که باعث میشه خیلی راحت همه چیز در هم تنیده و coupled بشه نیازهای بیزینسی ای هست که دیتای aggregate شده از چند domain مختلف رو میخواد از شما. تو حالت مونولیت خیلی ساده ست که شما در هر domain به دیتابیس یه domain دیگه درخواست بزنی و یا حتی تو interactor/service دیگه یه متد جدید تعریف کنی که دیتای مد نظر رو بده. که معمولا باعث در هم تنیده شدن و چاق شدن سرویس هاتون میشه.
بهتره سرویس یا همون interactorهاتون کارهای خیلی کوچیک و well-definedی رو انجام بدن و اگه نیازمندی های aggregationطور دارید، یه سری service دیگه بسازید که وابستگی خواهد داشت به سرویس های مختلف و دیتاهای raw رو میگیره و پردازش میکنه که دیتای نهایی رو آماده کنه.
بعضی وقت ها از طریق gateway هم ممکنه بتونید aggregate کنید. بعضی وقت ها ممکنه تو همون لایه دلیوری (کنترلر) تون بتونید دو تا سرویس رو فراخوانی کنید و کار رو در بیارید، گاهی هم پیچیده تر میشه و لازمه یه سرویس(interactor) بنویسید که کار aggregation رو انجام بده
https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation
باز خود aggregate کردن حالت های مختلفی داره، اینجا میتونید بیشتر بخونید در موردش
https://medium.com/geekculture/design-patterns-for-microservices-aggregation-pattern-1b8994516fa2
#gocasts | #hossein
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
Docs
Gateway Aggregation pattern - Azure Architecture Center
Learn about the Gateway Aggregation pattern, which uses a gateway to aggregate many individual requests into a single request.
👍1
شاید برای شما سؤال شده باشه که چطوری میشه توی پروژههای Open Source مشارکت کرد یا اینکه چطوری یک پروژهای رو راهاندازی کنیم که تأثیرگذار باشه و مورد مشارکت قرار بگیره! این سند که توسط خود github تهیه شده به پاسخ همین سؤال هست و شامل موارد زیر میشه:
- حفظ تعادل کار و زندگی در توسعه پروژههای Open Source.
- چگونه در پروژههای Open Source مشارکت کنیم؟
- چطوری یک پروژه Open Source رو شروع کنیم؟
- چگونه کاربرهای پروژه رو پیدا کنیم؟
- نحوه ساختن گروه و هم تیمی
- بهترین الگوها برای Maintainerها
- رهبری و قانونگذاری در مدیریت پروژه
- جلوگیری از خارجشدن از مسیر اصلی پروژه و نگرشهای غیرمتناسب سایر شرکتکنندگان و حفظ چهارچوبها
- متریکها و معیارهای قایل اندازهگیری پروژه
- نحوه دریافت حمایت و رسیدن به سود مالی
- جنبه حقوقی پروژههای Open Source
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
https://opensource.guide
- حفظ تعادل کار و زندگی در توسعه پروژههای Open Source.
- چگونه در پروژههای Open Source مشارکت کنیم؟
- چطوری یک پروژه Open Source رو شروع کنیم؟
- چگونه کاربرهای پروژه رو پیدا کنیم؟
- نحوه ساختن گروه و هم تیمی
- بهترین الگوها برای Maintainerها
- رهبری و قانونگذاری در مدیریت پروژه
- جلوگیری از خارجشدن از مسیر اصلی پروژه و نگرشهای غیرمتناسب سایر شرکتکنندگان و حفظ چهارچوبها
- متریکها و معیارهای قایل اندازهگیری پروژه
- نحوه دریافت حمایت و رسیدن به سود مالی
- جنبه حقوقی پروژههای Open Source
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
https://opensource.guide
Open Source Guides
Learn how to launch and grow your project.
یکی این عکس رو گذاشته لینکدین نوشته رفتم شرکت رهپویان اندیشه برای پوزیشن UI/UX Designer و این سوالات رو بعنوان سوالات آزمون استخدامی گذاشتن جلوم!!
دیوونه خونهاس قشنگ.
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
دیوونه خونهاس قشنگ.
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
😁11🥴6 2👎1
✅ فروش رزبری پای 4 مدل B با رم ۸ گیگ
این رزبری پای اورجینال انگلستان ۲-۳ ماه بیشتر استفاده نشده است و با قیمت 5.100.000 ت هرکسی خواست می تواند خریداری کند.
لوازم:
- کابل مینی به hdmi
آیدی جهت خرید: @ja7adr
اطلاعات رزبری:
https://bir-robotic.ir/product/%D8%A8%D8%B1%D8%AF-%D8%B1%D8%B2%D8%A8%D8%B1%DB%8C-%D9%BE%D8%A7%DB%8C-4-%D9%85%D8%AF%D9%84-b-%D8%A8%D8%A7-%D8%B1%D9%85-8gb/#next
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
این رزبری پای اورجینال انگلستان ۲-۳ ماه بیشتر استفاده نشده است و با قیمت 5.100.000 ت هرکسی خواست می تواند خریداری کند.
لوازم:
- کابل مینی به hdmi
آیدی جهت خرید: @ja7adr
اطلاعات رزبری:
https://bir-robotic.ir/product/%D8%A8%D8%B1%D8%AF-%D8%B1%D8%B2%D8%A8%D8%B1%DB%8C-%D9%BE%D8%A7%DB%8C-4-%D9%85%D8%AF%D9%84-b-%D8%A8%D8%A7-%D8%B1%D9%85-8gb/#next
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
تجربه یه 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
خیلی وقت ها پیش میاد که ما یه سری نکته ساده رو رعایت نمی کنیم و همین موضوع باعث میشه که مشکلات بزرگی در سیستم رخ بده.
من سعی میکنم نکات کوچیکی که طبق تجربه خودم داشتم یا اطرافیانم داشتند رو گاه به گاه منتشر کنم. امروز در مورد یکی از این موارد که باعث 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
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
pkg.go.dev
http package - net/http - Go Packages
Package http provides HTTP client and server implementations.
👍5❤1
در نسخهٔ ۱.۲۴ زبان Go، اشارهگرهای ضعیف (Weak Pointers) معرفی شدهاند که امکان ارجاع به اشیاء در حافظه را بدون جلوگیری از جمعآوری آنها توسط جمعکنندهٔ زباله (Garbage Collector) فراهم میکنند.
مزیت اصلی اشارهگرهای ضعیف:
اشارهگرهای ضعیف به شما اجازه میدهند به اشیائی در حافظه اشاره کنید بدون اینکه مانع جمعآوری آنها توسط جمعکنندهٔ زباله شوید. این ویژگی در ساختارهایی مانند کشها (Caches) یا نقشههای همارزی (Canonicalization Maps) مفید است، جایی که میخواهید تنها یک نسخه از دادهها را نگه دارید و در عین حال اجازه دهید دادههای غیرضروری بهطور خودکار از حافظه حذف شوند.
مثال: ساخت یک کش با استفاده از اشارهگرهای ضعیف
فرض کنید میخواهیم یک کش ایجاد کنیم که دادههای موقت را ذخیره کند و اجازه دهد جمعکنندهٔ زباله دادههای غیرضروری را حذف کند:
در این مثال:
ساختار Cache از یک نقشه با اشارهگرهای ضعیف برای ذخیرهٔ دادهها استفاده میکند.
با استفاده از
در صورت عدم وجود ارجاع قوی به داده، جمعکنندهٔ زباله میتواند آن را حذف کند و
مزایای استفاده از اشارهگرهای ضعیف در این سناریو:
کارایی حافظه: اشیائی که دیگر استفاده نمیشوند، توسط جمعکنندهٔ زباله حذف میشوند و مصرف حافظه کاهش مییابد.
پاکسازی خودکار: نیازی به پیادهسازی منطق پیچیده برای حذف دستی دادههای قدیمی نیست.
ایمنی در برابر شرایط رقابتی: اشارهگرهای ضعیف بهطور مؤثر در ساختارهای ایمن در برابر شرایط رقابتی مانند Cache استفاده میشوند.
با استفاده از اشارهگرهای ضعیف، میتوان کشهایی ساخت که بهطور خودکار دادههای غیرضروری را حذف کرده و کارایی حافظه را بهبود بخشند.
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
مزیت اصلی اشارهگرهای ضعیف:
اشارهگرهای ضعیف به شما اجازه میدهند به اشیائی در حافظه اشاره کنید بدون اینکه مانع جمعآوری آنها توسط جمعکنندهٔ زباله شوید. این ویژگی در ساختارهایی مانند کشها (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 استفاده میشوند.
با استفاده از اشارهگرهای ضعیف، میتوان کشهایی ساخت که بهطور خودکار دادههای غیرضروری را حذف کرده و کارایی حافظه را بهبود بخشند.
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6 5👍4
🚀 پکیج 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
سعی کردم در این پکیج یکسری الگوریتم های خاص بصورت بهینه و با بدون وابستگی به dependency های خارجی قرار دهم و فعلا یک الگوریتم را توسعه دادم و بزودی برخی الگوریتم های دیگر نظیر Reservoir Sampling, Consistent Hashing و برخی دیگر را قرار دهم.
در حال حاضر الگوریتم زیر را تکمیل کردم و قرار دادم.
✅ انتخاب تصادفی وزنی (Random Weighted Selection)
📌 مشاهده پکیج و مستندات:
🔗 گیتهاب: https://github.com/Ja7ad/algo
📚 مستندات: https://pkg.go.dev/github.com/Ja7ad/algo
🔥 خوشحال میشوم نظرات و پیشنهاداتتان را بشنوم! اگر علاقهمند به مشارکت در توسعه این پکیج هستید، PR بفرستید! 💡
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8😁1
If in TDD you trust, don’t proselytize it. TDD is a personal practice.
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
A Crash Course on Load Balancers for Scaling.pdf
5.2 MB
A Crash Course on Load Balancers for Scaling
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
Software Architecture Patterns - ByteByteGo Newsletter.pdf
3.8 MB
Software Architecture Patterns
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
The_Sidecar_Pattern_Explained_Decoupling_Operational_Features.pdf
2 MB
The Sidecar Pattern Explained_ Decoupling Operational Features
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
A Crash Course on Scaling the Data Layer.pdf
4.3 MB
A Crash Course on Scaling the Data Layer
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
A Pattern Every Modern Developer Should Know_ CQRS.pdf
3 MB
A Pattern Every Modern Developer Should Know_ CQRS
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Please open Telegram to view this post
VIEW IN TELEGRAM
نوآوری DeepSeek و تهدید آن برای Nvidia
مشکل اصلی: آموزش مدلهای هوش مصنوعی بسیار پرهزینه است. شرکتهایی مانند OpenAI و Anthropic بیش از ۱۰۰ میلیون دلار برای پردازش و آموزش مدلهایشان هزینه میکنند و به هزاران GPU گرانقیمت نیاز دارند.
نوآوری DeepSeek: این شرکت با ۵ میلیون دلار و تنها ۲,۰۰۰ GPU مدلهایی ساخته که در بسیاری از وظایف عملکردی مشابه یا بهتر از GPT-4 و Claude دارند.
چگونه؟
- کاهش حافظه مورد نیاز تا ۷۵٪ با استفاده از اعداد ۸ بیتی به جای ۳۲ بیتی.
- پردازش چندتُکنی (Multi-Token) که سرعت را ۲ برابر کرده و دقت را در حد ۹۰٪ مدلهای سنتی نگه میدارد.
- سیستم متخصصین (Expert System): به جای یک مدل عظیم که همیشه ۱.۸ تریلیون پارامترش فعال است، DeepSeek فقط ۳۷ میلیارد پارامتر را در لحظه اجرا میکند.
نتایج شگفتانگیز:
- هزینه آموزش از ۱۰۰ میلیون دلار → ۵ میلیون دلار
- تعداد GPU موردنیاز از ۱۰۰,۰۰۰ → ۲,۰۰۰
هزینه API ۹۵٪ ارزانتر
- امکان اجرا روی کارتهای گرافیک گیمینگ معمولی
چرا این برای Nvidia خطرناک است؟
انودیا کسبوکارش را روی فروش GPUهای فوقالعاده گرانقیمت با ۹۰٪ حاشیه سود بنا کرده است. اگر مدلهای AI بتوانند با کارتهای گیمینگ معمولی اجرا شوند، بازار Nvidia دچار تحول اساسی میشود.
تحول در صنعت:
هوش مصنوعی ارزانتر و در دسترستر میشود.
شرکتهای بزرگ مانند OpenAI دیگر انحصار بازار را ندارند.
نیاز به سختافزار گرانقیمت کاهش مییابد.
این لحظه مانند ظهور رایانههای شخصی یا رایانش ابری است—یک نقطه عطف بزرگ!
نتیجه:
هوش مصنوعی در حال ارزانتر و فراگیرتر شدن است. تغییر بزرگ شروع شده، و فقط مسئله زمان است که چقدر سریع گسترش یابد.
منبع
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
مشکل اصلی: آموزش مدلهای هوش مصنوعی بسیار پرهزینه است. شرکتهایی مانند OpenAI و Anthropic بیش از ۱۰۰ میلیون دلار برای پردازش و آموزش مدلهایشان هزینه میکنند و به هزاران GPU گرانقیمت نیاز دارند.
نوآوری DeepSeek: این شرکت با ۵ میلیون دلار و تنها ۲,۰۰۰ GPU مدلهایی ساخته که در بسیاری از وظایف عملکردی مشابه یا بهتر از GPT-4 و Claude دارند.
چگونه؟
- کاهش حافظه مورد نیاز تا ۷۵٪ با استفاده از اعداد ۸ بیتی به جای ۳۲ بیتی.
- پردازش چندتُکنی (Multi-Token) که سرعت را ۲ برابر کرده و دقت را در حد ۹۰٪ مدلهای سنتی نگه میدارد.
- سیستم متخصصین (Expert System): به جای یک مدل عظیم که همیشه ۱.۸ تریلیون پارامترش فعال است، DeepSeek فقط ۳۷ میلیارد پارامتر را در لحظه اجرا میکند.
نتایج شگفتانگیز:
- هزینه آموزش از ۱۰۰ میلیون دلار → ۵ میلیون دلار
- تعداد GPU موردنیاز از ۱۰۰,۰۰۰ → ۲,۰۰۰
هزینه API ۹۵٪ ارزانتر
- امکان اجرا روی کارتهای گرافیک گیمینگ معمولی
چرا این برای Nvidia خطرناک است؟
انودیا کسبوکارش را روی فروش GPUهای فوقالعاده گرانقیمت با ۹۰٪ حاشیه سود بنا کرده است. اگر مدلهای AI بتوانند با کارتهای گیمینگ معمولی اجرا شوند، بازار Nvidia دچار تحول اساسی میشود.
تحول در صنعت:
هوش مصنوعی ارزانتر و در دسترستر میشود.
شرکتهای بزرگ مانند OpenAI دیگر انحصار بازار را ندارند.
نیاز به سختافزار گرانقیمت کاهش مییابد.
این لحظه مانند ظهور رایانههای شخصی یا رایانش ابری است—یک نقطه عطف بزرگ!
نتیجه:
هوش مصنوعی در حال ارزانتر و فراگیرتر شدن است. تغییر بزرگ شروع شده، و فقط مسئله زمان است که چقدر سریع گسترش یابد.
منبع
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥1
CAP,_PACELC,_ACID,_BASE_Essential_Concepts_for_an_Architect’s_Toolkit.pdf
3.1 MB
CAP, PACELC, ACID, BASE - Essential Concepts for an Architect’s Toolkit
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
☄️ @GoInsights | @GolangEngineers
#bytebytego #tips #pro_guide
➖➖➖➖➖➖➖➖
Please open Telegram to view this post
VIEW IN TELEGRAM