Using an Ambassador to Do Experimentation or Request Splitting

فرض کنید نسخه بتای جدید application شما آماده شده و حالا میخواید قبل از اینکه نسخه جدید رو لانچ کنید از عملکرد اون مطمئن بشید. یکی از راه کارهایی که وجود داره اینه که بخشی از درخواست های production رو به نسخه beta محول میکنن برای پاسخگویی، اینطوری میتونن متوجه بشن که نسخه جدید چقدر در انجام کار خودش موفقه

پیاده سازی این روش بدون داشتن ambassador container لازمه اش اینه که لاجیک برنامه پیچیده تر بشه و خود application این موضوع رو handle کنه که خب کار خوبی نیست...

برای پیاده سازی این موضوع در kubernetes می توان چنین کدی نوشت
https://github.com/brendandburns/designing-distributed-systems/blob/master/ambassadors/web-experiment.yaml

#designing_distributed_systems_brendan_burns

@gocasts

Adapters

الگوی آخری که از دسته single-node pattern ها بررسی میکنید adapter هست.

الگوی adapter وقتی استفاده میشه که بخوایم interface یک container رو تغییر بدیم. منظور از interface میتونه apiی باشه که ارائه میده، cliی باشه که داره و چیزای دیگه.


https://www.oreilly.com/library/view/designing-distributed-systems/9781491983638/ch04.html

#designing_distributed_systems_brendan_burns

#gocasts

مثلا شما فرض کنید که میخواید یه سرویس Prometheus بالا بیارید روی زیرساختتون، و همه application های داخل زیرساخت رو مانیتور کنید.
سرویس prometheus انتظار داره همه سرویس ها یک مسیر در api خودشون داشته باشن مثلا /metrics که سرویس مورد نظر طبق ساختاری که Prometheus انتظار داره دیتا رو اونجا serve میکنه
با اینکار Prometheus هر چند وقت یکبار اون api رو فراخوانی میکنه و دیتای metric های جدید رو از سرویس دریافت میکنه و دیتابیس خودش رو بروز میکنه.

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

علاوه بر سخت بودن توسعه چنین چیزی، باید در نظر بگیرید که همه سرویس های موجود در زیرساخت شما توسط تیم شما توسعه داده نشده، مثلا فرض کنید که شما از یک کلاستر redis استفاده میکنید و میخواید که redis رو هم به سرویس هایی که توسط prometheus مانیتور میشن اضافه کنید، شما نمیتونید چنین apiی برای redis توسعه بدید.

#designing_distributed_systems_brendan_burns

@gocasts

اینجاست که داشتن یه adapter container به کمک میاد

اساسا مفهوم adapter در برنامه نویسی یعنی اینکه شما قراره یک interface رو تبدیل به یک interface جدید کنی تا مطابق باشه با چیزی که سرویس های دیگه انتظار دارن

مثلا سرویس redis با interface خاص خودش دیتا رو برای مانیتور کردن ارائه میده و این دیتا به کار prometheus نمیاد، ما باید این وسط یه سرویس واسط داشته باشیم که کارش این باشه که دیتا رو با interface مربوط به redis بخونه و به صورت interfaceی که مد نظر prometheus هست ارائه بده.

برای این کار شما میتونید از exporter های prometheus استفاده کنید که یک سری adapter هستن برای انجام همین کار
مثلا برای مثال موجود میتونید از redis_export استفاده کنید


https://github.com/brendandburns/designing-distributed-systems/blob/master/adapters/prometheus-redis.yaml

#designing_distributed_systems_brendan_burns

@gocasts

به جز مثال مذکور برای کاربردهای adapter نمونه های مختلف دیگه ای وجود داره

یکی از این نمونه ها بحث log کردن هست. سرویس های مختلف به فرمت های مختلف دیتا رو لاگ میکنن، اما اگه شما بخواید توسط یک log aggregator با یک فرمت و ساختار ثابت دیتای سرویس های مختلف رو جمع آوری کنید نیاز دارید که برای هر سرویس یک log adapter استفاده کنید که وظیفه اش تبدیل کردن دیتای لاگ از فرمت مبدا به فرمت مورد نظر سرویس logging agnet هست.

مثلا یکی از agent های معروف برای لاگ کردن دیتا fluentd هست که مشابه با exporter های prometheus یک سری plugin داره که اجازه میده لاگ های موجود با فرمت های مختلف رو به صورت فرمت استاندارد درآورده و ذخیره کنید.

لازمه این کار اینه که برای هر سرویس یک adapter container وجود داشته باشه که با application container یک shared volume داشته باشه و خروجی لاگ های application رو به صورت فرمت استاندارد مورد نظر fluentd دربیاره.

#designing_distributed_systems_brendan_burns

@gocasts

دوستان یه نکته ای از تجربه شخصی خودم بگم شاید بهتون کمک کنه که چه اینجا و چه جاهای دیگه مطالب رو عمقی تر به خاطر بسپرید.
سعی کنید در مورد هر الگو یا best-practice خاصی که مطالعه میکنید تو ذهنتون به این فکر کنید که در گذشته و یا حال، چه پروژه هایی بوده که اگه چنین الگویی براش لحاظ میشد، خروجی کار بهتر میشد.
لزومی نداره که حتما این روش هارو پیاده کنید و باهاشون تمرین داشته باشید.
همین که یه تمرین ذهنی داشته باشید از اینکه «فکر کنید این الگو کجای معماری سیستم شما میتونست قرار بگیره»، این خودش کافیه برای اینکه مطالب رو عمقی تر به ذهن بسپارید و در ادامه اگه لازم شد بتونید ازش بهره ببرید.

@gocasts

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

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

Testing in Go: First Principles
https://ieftimov.com/post/testing-in-go-first-principles/

Testing in Go: Failing Tests
https://ieftimov.com/post/testing-in-go-failing-tests/

Testing in Go: Writing Practical Failure Messages
https://ieftimov.com/post/testing-in-go-writing-practical-failure-messages/

Testing in Go: go test
https://ieftimov.com/post/testing-in-go-go-test/

Testing in Go: Table-Driven Tests
https://ieftimov.com/post/testing-in-go-table-driven-tests/

Testing in Go: Subtests
https://ieftimov.com/post/testing-in-go-subtests/

Testing in Go: Fixtures
https://ieftimov.com/post/testing-in-go-fixtures/

Testing in Go: Dependency Injection
https://ieftimov.com/post/testing-in-go-dependency-injection/

Testing in Go: Test Doubles by Example
https://ieftimov.com/post/testing-in-go-test-doubles-by-example/

Testing in Go: Golden Files
https://ieftimov.com/post/testing-in-go-golden-files/

Testing in Go: Clean Tests Using t.Cleanup
https://ieftimov.com/post/testing-in-go-clean-tests-using-t-cleanup/

Testing in Go: HTTP Servers
https://ieftimov.com/post/testing-in-go-testing-http-servers/

Testing in Go: WebSockets
https://ieftimov.com/post/testing-in-go-websockets/

Testing in Go: Stop Leaking Files
https://ieftimov.com/post/testing-in-go-stop-leaking-files/

#golang #test #unit_test #integration_test #tdd

@gocasts

اساسا تست نویسی مقوله ای بسیار ساده، بسیار لذت بخش و در عین حال بسیار کارآمد هست.
دقت کنید وقتی صحبت از تست نویسی میشه منظور tdd نیست، tdd صرفا یک approach هست برای تست نوشتن، شما میتونید این روش رو استفاده کنید و یا نکنید

تست نویسی انواع مختلفی داره:
unit test
integration test
end to end test

که هر کدوم ارزش و جایگاه خودشونو دارن

تست نویسی واسه وقتایی که حوصله development ندارید مثل کافئین میمونه 😃

و وقتی ارزش خودشو نشون میده که لازم باشه یه چیزی رو refactor کنید، مخصوصا اگه refactor بزرگ باشه خیلی ریسک انجامش بالا میره، اگه از قبل تست های قابل اطمینان و جامعی براش نوشته باشید دیگه خیالتون میتونه تا حدود خیلی زیادی بابت refactor کردن راحت باشه

#golang #test #unit_test #integration_test #tdd

@gocasts

حالا که بحث adapter رو کردیم، شاید بد نباشه یه نگاهی به تفاوت الگوی adapter و wrapper بندازیم، این دو الگو خیلی به هم شبیه هستن و گاهی با هم اشتباه گرفته میشن

پیشنهاد میکنم که حتما اصل مقاله رو هم مطالعه کنید

The Difference Between An Adapter And A Wrapper


Being cognizant of what problem you are trying to solve and what pattern you are using to solve that problem will help you to keep your code clean and focused on a singular purpose.

Use wrappers to simplify code, encapsulate third-party dependencies, and eliminate repetition.

Use the adapter pattern to allow yourself to swap out third-party dependencies at will by interacting with your own interface, and then making adapters that map from your own interface to the third party code.

تفاوت wrapper با adapter در این نکته است که هدف اصلی wrapper اینه که interface موجود نسبت به یک کتابخانه خارجی رو ساده سازی میکنه و به یک interface ساده تر تبدیلش میکنه، اما adapter شکاف بین دو interface موجود رو جبران میکنه و مثل یک پل (bridge) بین این دو عمل میکنه. با کمک adapter ما یک مساله ناسازگاری (incompatibility)‌ رو حل میکنیم، اما به کمک wrapper نیاز ساده سازی کردن یک interface موجود رو حل می کنیم.

مثال
مثلا تصور کنید که برنامه شما نیاز داره که یک سری اطلاعات کاربر رو از شبکه اجتماعی بگیره. کلاس FacebookConnector میتونه یک wrapper برای Facebook SDK باشه که اتصال شما به facebook رو راحت میکنه. به جای اینکه از sdk استفاده کنی که برای usecase های مختلف interface رو در معرض نمایش (expose)‌میذاره، از یک کلاس wrapper استفاده میشه که فقط برای usecase های شما یک interface ارائه میده.

حالا مثلا دیگه اینه که تصور کنید که اپلیکیشن شما یک سری داده از شبکه های اجتماعی میخواد در مورد کاربر، اما براش مهم نیست این داده ها از کدوم شبکه اجتماعی هستن. تو این حالت میشه یه interface داشت مثلا به اسم ISocialIntegrator که usecase های برنامه رو پیاده میکنه اما هیچ وابستگی ای به هیچ شبکه اجتماعی خاصی نداره.
بعد از اینکه تصمیم گرفتید از کدوم شبکه اجتماعی استفاده کنید، شما میتونید یک adapter بین ISocialIntegrator و کتابخونه شبکه اجتماعی مورد نظر خودتون بنویسید. مثلا FacebookAdapter یا LinkedInAdapter که خلا بین اینترفیس SocialIntegrator و api واقعی شبکه اجتماعی مورد نظر رو پر میکنه.

با استفاده از wrapper میشه وابستگی های شخص ثالث رو ساده سازی کرده، کپسوله کرد.
با استفاده از adapter میشه براحتی وابستگی های شخص ثالث رو تغییر داد به کمک داشتن یک interface اختصاصی برای برنامه و نوشتن یک سری adapter که interface برنامه رو به کد وابستگی شخص ثالث نگاشت میکنن.

https://www.thecodedself.com/The-Difference-Between-an-Adapter-and-a-Wrapper/

#design_pattern
#adapter
#wrapper

@gocasts

بخش اول unit test در golang

موضوعاتی که پوشش داده شده
unit test (simple functions without any dependency)
table driven test
subtests

#golang #unit_test #test

@gocasts

سلام دوستان، تو این voice من توضیحاتی دادم در مورد اینکه چرا سعی می کنم خلاصه کتاب رو تو کانال منتشر کنم و شما لازم نیست حتما کتاب رو بخونید و مطالعه خلاصه کتاب هم میتونه به اندازه کافی مفید باشه براتون

مخلصم

#designing_distributed_systems_brendan_burns

@gocasts

بِسْمِ اللَّهِ الرَّحْمَنِ الرَّحِيمِ

اَلسَّلامُ عَلَیْکَ یا اَباعَبْدِاللَّهِ وَ عَلَى الاَْرْواحِ الَّتى حَلَّتْ بِفِناَّئِکَ

خب دوستان ما تا به اینجا پارت اول کتاب که شامل الگوهای single-node بود رو بررسی کردیم. الگوهای single-node اونایی بودن که روی یه single-machine پیاده میشدن که بصورت یک container در کنار container اصلی بودن و از نظر زمانبندی استقرار (deployment shcheduling) با سرویس اصلی هماهنگ بودن و عموما در یک یا چند resource با کانتینر اپلیکیشن اصلی اشتراک داشتن، که این اشتراک میتونست network باشه، میتونست volume باشه یا حتی PID namespace باشه که مربوط به فضای نام پروسه هاست و در نهایت این کانتینر ها در کنار کانتینر اصلی تشکیل یک گروه و یا اصطلاحا یک pod رو میدادند.

the previous chapter described patterns for grouping collections of containers that are scheduled on the same machine. These groups are tightly coupled, symbiotic systems. The depned on local, shared resources like disk, network interface or interprocess communications.

حالا میریم سراغ پارت دوم کتاب که در مورد Serving Pattern هاست، این پارت ۵ فصل داره که هر فصل یک الگو رو معرفی میکنه.
سه ویژگی خیلی مهم برای هر سیستم نرم افزاری وجود داره
Reliability
چقدر سیستم شما قابل اتکاست و در برابر انواع خطاها مقاوم هست(عملکرد سیستم تحت تاثیر قرار نمیگیره)

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

Separation of Concerns
چه میزان سیستم شما ماژولار هست بگونه ای که بتوان مسئولیت قسمت های مختلف رو به تیم های مختلف سپرد و یا بصورت جداگانه و به تفکیک زمان برای آن ها تصمیم گیری کرد و تغییر در یک ماژول، ماژول دیگر را تحت تاثیر قرار نمی دهد


برای داشتن سیستمی با این مشخصات شما ناچار هستید سیستم خود را به چندین component کوچکتر بشکنید، و هر component را بصورت مستقل روی یک یا چند ماشین مجزا اجرا کنید.
الگوهای توزیع شده multi-node نسبت به الگوهای single-node خیلی بیشتر loosely coupled هستن (یعنی وابستگی کمتری به هم دارن) و عموما communication بین اونها بر اساس network call هاست. (بر خلاف single node ها که هر shared resourceی مثل volume و PID هم میتونست وسیله ارتباط باشه)


#designing_distributed_systems_brendan_burns

@gocasts

Introduction to Microservices

در سال های اخیر عبارت «microservices» برای توصیف multi-node distributed software archetectures یک عبارت همه گیر شده است. عموما Microservices سیستمی را توصیف می کنه که از چند component مختلف تشکیل شده که هر کدام از این component ها توسط process های مختلف اجرا می شوند و ارتباط بین آنها از طریق یک سری API از پیش تعریف شده صورت میگیره.
عبارت Microservices در مقابل monolithic systems قرار میگیره که تمایلش به اینه که همه ی functionality های یک سیستم رو بصورت یکجا در یک application ارائه بده.

#designing_distributed_systems_brendan_burns

@gocasts

برای Microservices ها مزایای زیادی وجود داره که اکثر این مزایا حول محور دو موضوع هستن
Reliability

Agility
کوچک بودن سرویس ها باعث میشه هر تیم بصورت جداگانه بتونه توسعه یک یا چند کامپوننت رو بر عهده بگیره و همین باعث میشه که تیم ها اصطکاک کمتری در ارتباط با هم داشته باشند و چابکی تیم ها بیشتر بشه
دلیل دیگه چابک بودن اینه که برای هر سرویس تیم ها مجبور هستن یک سری API رسمی و مناسب ارائه بدن که همین خودش باعث تقویت همکاری تیم ها میشه
و در نهایت جداسازی microservice ها باعث میشه که سیستم در مواقع لزوم بهتر scale پیدا کنه و هر component بصورت مستقل این موضوع رو مدیریت کنه.

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

#designing_distributed_systems_brendan_burns

@gocasts

قسمت دوم unit testing
تست نویسی برای ماژول هایی که dependency دارن

شاید مهم ترین نکته این ویدیو این باشه که unit testing به شما کمک میکنه نشانه های bad design رو خیلی زود توی کدتون تشخیص بدید و بتونید دیزاینتون رو اصلاح کنید

مفاهیمی که پوشش داده شده
- bad design sign (concrete object injection)
- simple mocking
- refactor code in order to have loosely coupled modules

خوشبختانه کیفیت صدا این بار خیلی بهتر شد، امیدوارم باز به بزرگی خودتون ببخشید

فرمت ویدیو h265 هست پس ممکنه لازم باشه با vlc player ببینید
به این دلیل این فرمت رو انتخاب کردم که کاهش حجم روی کیفیت تاثیر خیلی کمتری بذاره

#golang #unit_test #test

@gocasts

اولین الگویی که از دسته Serving Pattern ها با هم بررسی می کنیم الگوی «Replicated Load-Balanced Services» هست

این الگو یه الگوی ساده است که خیلی هامون باهاش آشنایی داریم. به این صورت که یه سری node داریم که همگی قابلیت این رو دارن که به همه درخواست ها پاسخ بدن. یه node بصورت load balancer داریم که کارش اینه با استفاده از الگوریتم هایی مثل round-robin یا session stickiness درخواست هارو بین node ها تقسیم میکنه.


#designing_distributed_systems_brendan_burns

@gocasts

Stateless Services
حالا Stateless Service چیه؟ سرویسیه که هیچگونه stateی رو نیاز نداشته باشه برای پاسخگویی به یه درخواست جدید.
مثال: یه سری اپلیکیشن ها وقتی کاربر لاگین میکنه یه سری دیتا بصورت session سمت سرور نگه میدارن، و از کلاینت انتظار دارن همراه درخواست های بعدی اون اطلاعات رو تو cookie درخواست قرار بدن، خب این سرویس قطعا stateless نیست، چون برای پاسخگویی به درخواست احتیاج داره یه سری دیتا رو نگه داره.

مثلا یکی از مزایای jwt اینه که به سرویس ها اجازه میدن stateless باشن و بدون اینکه احتیاج داشته باشن دیتایی از کاربر ذخیره کنن اون اطلاعات رو داخل payload خود jwt نگه میدارن.

این الگوی Replicated برای Stateless Systems بسیار کارآمد هست و به اون ها برای فراهم کردن دو موضوع Redundancy و Scale کمک میکنه.

Redundancy
Redundancy is the intentional duplication of system components in order to increase a system’s dependability.
به زبان ساده تر ما احتیاج داریم همیشه چند نسخه از سرویس هامون رو آپ کنیم که اگه یکیشون به خطا خورد، بقیه بتونن جوابگوی درخواست ها باشن.

https://www.bmc.com/blogs/resiliency-vs-redundancy/

#designing_distributed_systems_brendan_burns

@gocasts

Session Tracked Services
خب یه سری وقت ها پیش میاد که سرویس های ما Stateful هستن مثل همون مثال sessionی که در مطلب قبلی گفتم

یه دلیل رایج دیگه هم وجود داره برای اینکه سرویس های ما stateful باشن: اونم چیزی نیست جز cache
خیلی از سرویس ها برای اینکه لود کمتری روی سرویس های پایین دست (downstream) مثل دیتابیس بندازن از cache برای پاسخگویی استفاده میکنن. به این صورت که اگه درخواستی برای بار اول به اون سرویس بیاد دیتارو از سرویس های پایین دست مثلا دیتابیس میگیرن و علاوه بر اینکه درخواست کاربر رو پاسخ میدن، یک نسخه از اون دیتا رو در حافظه خودشن یا دیتابیس وابسته به خودشون مثل Redis ذخیره میکنن تا اگه درخواست مشابهی اومد نیاز نباشه دوباره دیتارو از دیتابیس بخونن، اینطوری هم لود overall سیستم کمتر میشه هم response time خیلی پایین میاد.

خب مشکل اینجاست که وقتی ما از cache استفاده میکنیم، اگه بخوایم واقعا بصورت بهینه از کارایی cache بهره مند بشیم، باید سعی کنیم درخواست های مشابه رو همیشه به یه سری node مشخص بفرستیم نه اینکه بصورت تصادفی هر درخواست رو به یه node بفرستیم. در واقع تو این حالت سرویس ما stateful شده و دیگه به راحتی حالت stateless نیست که load balancer هر طور دلش بخواد درخواست هارو تقسیم بکنه بین node ها

عموما load balancer ها برای حل کردن قضیه stateful service ها از یه سری hash function استفاده میکنن. البته اگه بخوایم بهترین و بهینه ترین الگوریتم های hashing رو استفاده کنیم باید از consistent hashing استفاده کنیم. مثلا از ip مبدا و مقصد برای وروی تابع هش استفاده میکنن و خروجی hash که همیشه ثابته به عنوان کلیدی برای مشخص کردن nodeی که باید پاسخگو باشه استفاده میشه.

در مورد consistent hashing جلوتر با بررسی الگوی sharded صحبت میکنیم

#designing_distributed_systems_brendan_burns

@gocasts

سوال: توی معماری میکروسرویس باید حتما از یکی از این الگو ها استفاده و پیروی کرد؟

یکی از دوستان این سوال رو پرسیدند، در جواب باید بگم، بله استفاده از این الگوها عملا اجتناب ناپذیر هست، چرا؟
چون یکی از مهم ترین ویژگی های هر بیزینس availability هست، شما باید down time خیلی خیلی پایینی داشته باشید، مخصوصا اگه service provider باشید و SLA داشته باشید حتی برای الزام ۹۹.۹ (نه بیشتر مثل ۹۹.۹۹۹ و غیره) شما در طول یک روز نهایتا ۱.۴ دقیقه میتونید downtime داشته باشید و این عدد حتی اگه سیستمتون باگ نداشته باشه و در طول روز چندبار دیپلوی داشته باشید، جوابگوی downtime های دیپلوی هم نخواهد بود...، بنابراین شما به ناچار مجبور هستید برای داشتن availability قابل قبول حتما stateless replica داشته باشید از سرویس هاتون.
این مثال فقط اهمیت الگوی Replicated Load-Balanced Services رو نشون میده، بقیه الگوها هم کاربردهای خودشونو دارن که گاها اون ها هم اجرا کردنشون الزام میشه خیلی وقت ها

یه مثال دیگه الگوی Sidecar هست که برای monitoring و ship کردن log های هر service به یه centralized log repository تقریبا اجتناب ناپذیره...

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

#designing_distributed_systems_brendan_burns

@gocasts

دوستان باور کنید اگه این مقاله رو نخوندید، عملا هیچی در مورد Memory Model نمیدونید 😁

https://research.swtch.com/hwmm

توضیحات: آقای Russ Cox از اعضای اصلی تیم توسعه دهنده زبان Go هستن

این مقاله قسمت دوم و سوم هم داره، اما حتما قسمت اول رو بخونید
مقاله بسیار فنی و جذابه و باید حوصله کنید برای خوندنش

مقاله اول و دوم مقدمه ای هستن برای مقاله سوم که توضیح میده چرا و چطور Go Memory Model بروزرسانی شده

قسمت دوم
https://research.swtch.com/plmm

قسمت سوم
https://research.swtch.com/gomm


#memory_model #golang #russ_cox

@gocasts