کد زدن تو Go با ذهنیت PHP، یکی از سریع‌ترین راه‌ها برای فرستادن باگ‌های خاموش به پروداکشنه!
خیلی وقت‌ها می‌بینیم یه برنامه‌نویس باتجربه PHP سوییچ می‌کنه روی Go. سینتکس رو خیلی خوب یاد می‌گیره، ظاهرا کد تمیزی هم می‌زنه و تست‌ها هم پاس میشن. اما وقتی پروژه زیر بار (Load) میره، ناگهان Data Race ها خودشون رو نشون میدن، دیتای کاربرها با هم قاطی میشه و Goroutine ها انقدر لیک میشن تا سرور کرش کنه.
مشکل از نفهمیدن سینتکس نیست؛ مشکل تغییر نکردن «مدل ذهنی» معماریه.
تو دنیای PHP ما به لطف FPM به معماری Shared-Nothing عادت کردیم. هر ریکوئست تو یه محیط ایزوله اجرا میشه و وقتی تموم شد، همه‌چیز از بین میره. شما نگران مدیریت مموری و منابع مشترک بین ریکوئست ها نیستی سیستم‌عامل و لاراول زحمت مدیریت مموری و ایزولیشن رو می‌کشن. ما اونجا نیازی به Mutex نداشتیم چون هر ریکوئست توی یه پروسس جدید بالا می اومد و اصلاً مموریِ مشترکی بین ریکوئست‌ها وجود نداشت.
اما Go دنیای Shared-Everything هست. اپلیکیشن شما یک پروسس لانگ ران هستش که با ریکوئست‌های جدید رفرش نمیشه. تو این دنیا شما خودتون مسئول مدیریت مموری، Connection Pool ها، هم‌زمانی و چرخه حیات هر Goroutine هستید. اینجا دیگه لاراولی در کار نیست که اشتباهات مموری رو پاک کنه.
تو مقاله جدیدی که تو مدیوم منتشر کردم، این شیفت معماری رو دقیق بررسی کردم. سه تا تله خیلی رایج (مثل باگ‌های State مشترک و Goroutine های رها شده) رو با نمونه کد واقعی کالبدشکافی کردم و راه‌حل‌های اصولی Go رو براشون نوشتم. (یه باگ خاص رو هم بررسی کردم که معمولا کسی متوجه ش نمیشه)

https://medium.com/@mmtaheri.dev/shared-nothing-shared-everything-b57ec99306db
اگر دولوپر PHP هستید که به Go مهاجرت کرده (یا قصدش رو داره)، یا معماری بک‌اند براتون دغدغه‌ست، این مقاله براتون نوشته شده.

@DevTwitter | <Mohammad Mahdi taheri/>