در مورد مفاهیم Microservice و SOA بحث جالبی با آقای حکایتی شکل گرفت که در کامنت های این پست میتونید مطالعه کنید.

https://news.1rj.ru/str/c/1525472919/105

https://news.1rj.ru/str/c/1525472919/106

https://news.1rj.ru/str/c/1525472919/107

سلام دوستان، امیدوارم حالتون خوب باشه، من باز اومدم با یه الگوی دیگه از دنیای distributed systems!

Scatter/Gather
الگوی بعدی که در موردش صحبت میکنیم، الگوی scatter/gather هست.

الگوی replicated از منظر «تعداد درخواست پردازش شده در ثانیه» به scalability توجه میکنه.
الگوی sharded از منظر «حجم دیتا» به scalability توجه میکنه.
الگوی scatter/gather با استفاده از الگوی replication از منظر «زمان» به scalability توجه میکنه.

خیلی ساده تر بخوام بگم این الگو موازی سازی(parallelism) رو امکانپذیر میکنه. به این صورت که اجازه میده به درخواست ها خیلی سریعتر از حالت sequential پاسخ بدید.
الگوی scatter/gather هم مثل الگوهای replicated و sharded یک الگوی درختی هست.
یعنی یک نود root داره که درخواست هارو به نودهای برگ میده و اونا پردازش میکنن.

اما این الگو یه تفاوت بزرگ و مهم با دو الگوی قبلی داره، اونم اینه که بصورت همزمان درخواست ورودی رو به همه ی نودهای برگ میفرسته و هر کدوم از اون نود ها مسئول پردازش بخش کوچیکی از دیتا هستند. هر نود برگ (leaf) بخشی از نتیجه رو به نود ریشه(root) برمیگردونه و نود ریشه بعد از ترکیب کردن همه نتایج یک جواب کامل رو به عنوان پاسخ برای درخواست ارسال میکنه.


#designing_distributed_systems_brendan_burns

@gocasts

الگوی scatter/gather وقتی خیلی کارآمد هست که شما حجم بسیار زیادی از داده های مستقل از همدیگه رو برای پاسخگویی به درخواست کاربر لازم دارید.

درواقع اگه بخوایم تفاوت الگوی scatterh/gather رو با الگوی sharding بگیم، اینطوری میشه که الگوی sharded هدفش تقسیم(shard) کردن داده هاست اما الگوی scatter/gather هدفش تقسیم کردن حجم محاسبات (computation) هست.

تو این الگو هر نود برگ مسئول «پردازش» بخشی از داده هاست


#designing_distributed_systems_brendan_burns

@gocasts

Scatter/Gather with Root Distribution
تو این نوع پیاده سازی، همه نودهای برگ به همه دیتا دسترسی دارند، و نود root پاسخگویی به هر بخش از دیتا رو به یک نود خاص واگذار میکنه.


Hands On: Distributed Document Search
مثلا برای جستجو در دیتابیس مجموعه ای از documentها، اگه همه نودهای برگ به همه documentها دسترسی داشته باشن، و مثلا درخواست ورودی پیدا کردن همه document های که شامل دو کلمه Cat و Dog باشه، نود root به یک نود میگه همه داکیومنت هایی رو پیدا کن که کلمه Cat دارند، و به یک نود دیگه میگه همه document هایی رو پیدا کن که کلمه Dog دارند، نود root بعد از گرفتن هر دو لیست، آیتم های مشترک هر دو لیست رو به عنوان پاسخ به درخواست ارسال میکنه


#designing_distributed_systems_brendan_burns

@gocasts

Scatter/Gather with Leaf Sharding

وقتی حجم دیتا خیلی زیاد باشه، شما نمیتونید همه دیتا رو روی همه node ها داشته باشید. راه حلش اینه که هر node فقط یه قسمتی از دیتا رو داشته باشه، و نود root از هر نود برگ بخواد به همه درخواست رسیدگی کنه.
تو مثال بالا اینطوری میشه که هر نود مستقلا به دنبال همه document هایی میگرده که حتما دو کلمه cat و dog رو با هم داشته باشن. وظیفه نود ریشه این میشه که همه لیست هارو با هم جمع کنه و به عنوان پاسخ برگردونه.

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

#designing_distributed_systems_brendan_burns

@gocasts

Choosing the Right Number of Leaves

خب حالا که مزایای موازی سازی رو متوجه شدیم، سوال اصلی اینه که چه تعداد نود برگ برای سیستم در نظر بگیریم، شاید در نگاه اول اینطور به نظر بیاد که هر چه تعداد نودهای برگ بیشتر بشه سریعتر میشه با درخواست ها پاسخ گفت، اما اینطور نیست...
باید در نظر داشته باشید که distribute کردن هر درخواست بین نودهای مختلف overheadهایی داره، مثل parse کردن درخواست های http و ارسال درخواست روی شبکه
همچنی یه مساله ای هست که به «straggler problem» معروفه. مساله چیه؟ در الگوی scatter/gather مدت زمان پاسخگویی به اندازه سرعت کندترین نود هست، پس اگه شما ۵ تا نود با حداکثر ۵ میلی ثانیه latency داشته باشید خیلی بهتره از داشتن ۱۰۰ تا نود با حداکثر ۲۰ میلی ثانیه latency. به این نکته توجه کنید که هر چه تعداد node ها بیشتر بشه احتمال اینکه یه نود با latency بالا وجود داشته باشه بیشتره..


#designing_distributed_systems_brendan_burns

@gocasts

بیاید با هم فکر کنیم مثلا چه use-case هایی میشه واسه این الگو پیدا کرد!

اگه بخوام مثالی بزنم که این الگو کارآمد باشه شاید بشه سیستم هایی که با نقشه سر و کار دارند رو مثال زد. چون تو این سیستم ها حجم داده ذاتا زیاده و در عین حال حجم محاسباتی که real-time هم باید صورت بگیره زیاده.
مثلا مسیریابی بین دو نقطه مبدا و مقصد رو در نظر بگیرید:
- حجم دیتایی که باید پردازش بشه که با در نظر گرفتن شرایط ترافیک و غیره بخواد مسیر بهینه رو به شما پیشنهاد بده خیلی زیاده.
- انجام محاسبات بین دو نقطه میانی (برای یافتن مسیر بهینه محلی) مستقل از شرایط نقاط دیگه است

خب چیکار میشه کرد که خیلی سریع بشه مسیر بهینه رو پیدا کرد؟
میشه یک سری نقاط میانی تعیین کرد، یافتن مسیر بهینه بین هر دو نقطه میانی رو به یک node واگذار کرد. هر node پس از انجام محاسبات اطلاعات مسیر رو به نود root برمیگردونه. نود root با استفاده از اطلاعات نقاط میانی و از ترکیب اون ها میتونه یه مسیر بهینه رو به عنوان پاسخ به شما پیشنهاد بده.

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


#designing_distributed_systems_brendan_burns

@gocasts

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

اینارو گفتم که امروز آقای Ian Lance Taylor رو به شما معرفی کنیم، ایشون از اوایل دهه ۹۰ میلادی روی gcc کار میکنه و کسی هست که gccgo رو از همون سال ۲۰۰۹ شروع کرده به ساختن.
اگه نمیدونید gccgo چی هست میشه gcc frontend for go language، که میشه کامپایلر غیر رسمی go روی gcc
در اینکه عملکرد gccgo بدتر از خود gc رسمی گولنگ هست شکی نیست، اما چون عملکرد gccgo بدتره دلیل نمیشه در موردش نخونید، با دنبال کردن مطالب و باگ و چالش هاش، کلی مطلب مفید در مورد زبان گولنگ و عملکرد کامپایلرها یاد میگیرد.

برای اطلاعات بیشتر در مورد gccgo میتونید لینک های زیر رو ببینید
https://gcc.gnu.org/onlinedocs/gccgo/
https://meltware.com/2019/01/16/gccgo-benchmarks-2019.html
https://stackoverflow.com/questions/25811445/what-are-the-primary-differences-between-gc-and-gccgo#:~:text=Compared%20to%20gc%2C%20gccgo%20is,the%20processors%20that%20GCC%20supports.

https://golang.org/doc/install/gccgo


در نهایت میخوام پست های آقای Ian Lance Taylor که در مورد golang هست رو به شما معرفی کنم، اکثر پست ها مربوط به سال های ۲۰۰۹ و ۲۰۱۰ هست و با خوندنش دید بهتری نسبت به go internal خواهید داشت قطعا.

Go
https://www.airs.com/blog/archives/273

Go Channels
https://www.airs.com/blog/archives/275

Go Interfaces
https://www.airs.com/blog/archives/277

Go Interface Values
https://www.airs.com/blog/archives/281

Go New/Make
https://www.airs.com/blog/archives/283

A GCC Frontend
https://www.airs.com/blog/archives/287

Generics
https://www.airs.com/blog/archives/291

Go Linkage Names
https://www.airs.com/blog/archives/309

Thread Sanitizer
https://www.airs.com/blog/archives/321

Signed or Unsinged
https://www.airs.com/blog/archives/327

Software Paradigms
https://www.airs.com/blog/archives/342

Container Models
https://www.airs.com/blog/archives/349

Destructors
https://www.airs.com/blog/archives/362

gccgo panic/recover
https://www.airs.com/blog/archives/376

GCC Summit
https://www.airs.com/blog/archives/435

Versioning
https://www.airs.com/blog/archives/442

Gccgo in GCC
https://www.airs.com/blog/archives/448

Race Conditions
https://www.airs.com/blog/archives/482

Go experience report: the append function
https://www.airs.com/blog/archives/559

#the_right_person
#golang #gcc
#go_internal

@gocasts

این ویدیو به زیبایی هر چه تمام تر انواع consistency model هارو توضیح میده، مخصوصا eventual consistency رو که در سیستم های توزیع شده خیلی استفاده میشه.
https://www.youtube.com/watch?v=Fm8iUFM2iWU&list=WL&index=6

آقای Chris Colohan بیش از ۱۰ سال در گوگل روی ساخت انواع سیستم های توزیع شده کار کردند و درسی رو به رایگان ارائه میدن به همین نام که میتونید مطالبش رو از این لینک دنبال کنید

http://www.distributedsystemscourse.com

@gocasts

سلام دوستان وقت بخیر
احتمالا اسم آقای Bill Kenedy به گوشتون خورده باشه، ایشون یکی از بهترین اساتیدی هستند که گولنگ رو آموزش میدن، اخیرا هم کتاب Ultimate GO رو منتشر کردن که مباحث خیلی پیشرفته ای رو در زمینه گولنگ پوشش میده.
احتمالا با برخی از مقالات خیلی خوبشون که تحت بلاگ Ardan labs هم منتشر میشه آشنا هستید.
قراره که ان شاءالله روز ۱۲ آبان ساعت ۱۸ و ۳۰ به وقت تهران یک meetup یک ساعته با ایشون داشته باشیم، خیلی خوشحال میشم اگه در کامنت های همین پست موضوعاتی که دوست دارید در جلسه پوشش داده بشه رو ذکر کنید.

https://twitter.com/goinggodotnet

https://www.ardanlabs.com/blog/

https://courses.ardanlabs.com

@gocasts

موضوع جلسه چی باشه؟

هدف اصلی من از این جلسه آشنایی ایشون با کامیونیتی ایرانه و فعالیت هایی که میشه تا یه موضوع خاص..
@gocasts

سلام دوستان
موضوعاتی که فعلا پیشنهاد شده که میتونه یک یا چند تا از این ها باشه بسته به مدت زمان بحث، این ها هستند:
- ویژگی های cloud-native application و چرا گولنگ زبان مناسبیه
- تطبیق ویژگی های oop از زبان های قدیمی با گولنگ برای افرادی که از این زبان ها مهاجرت می کنند و مشکلات مرتبط
- بحث جنریک و نگرانی ها بابت generic pollution
- چه مباحثی مهم هستند برای اینکه تبدیل به یه go engineer بهتر بشیم
- ویژگی های یک microservice حرفه ای (چیزی که در دوره های آموزشی تبلیغ میشه توسط ایشون)

اگه در مورد این موضوعات نکته ای مد نظرتون هست حتما تو کامنت ها در موردش بحث کنیم

@gocasts

سلام وقت بخیر خدمت همه دوستان عزیز
ببخشید که یک هفته ای میشه مطلب فنی تو کانال نذاشتم، درگیر کارهای مرتبط با meetupمون با Bill Kennedy هستم، خیلی تلاش میکنم که همه چیز خوب پیش بره و ان شاءالله با کمک شما ها جلسه خیلی خوبی بشه که بتونیم این روند رو ادامه هم بدیم با افراد فعال و مطرح خارجی دیگه این حوزه
این نوید رو هم بدم که کلی مطلب خوب و باحال در مورد مباحث تکنیکال، از ادامه خلاصه کتاب ها گرفته، تا آموزش های ویدیویی فارسی گولنگی و خلاصه های صوتی فارسی فنی در مورد موضوعات مختلف برنامه نویسی مخصوصا مباحث دیتابیس و cloud native تو برنامه هست که ان شاءالله بعد از جلسه با بیل کندی خدمتتون ارائه میدم، امیدوارم که نوشته های این حقیر براتون مفید واقع بشه، بودنتنون انرژی خیلی مضاعفی بهم میده برای تولید کردن محتوای درجه یک و با کیفیت که خدمتتون ارائه بدم. دم همتون گرم ❤️

@gocasts

سلام دوستان، وقت بخیر، فردا، چهارشنبه ۱۲ آبان، ساعت ۱۸ و ۳۰ به وقت تهران منتظر شما هستیم 😍

https://www.twitch.tv/tehrantechtime

@gocasts

خب خب، جلسه نیم ساعت دیگه برگزار میشه، حین برگزاری جلسه، هر نکته و سوالی از بیل داشتید داخل کامنت همین پست یا در توییتر با این هشتگ مارو باخبر کنید که از بیل بپرسیم.
#TehranTechTimeQA

@gocasts

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

بقول دوستم over engineering کردیم، فکر کردیم ممکنه تعداد خیلی زیاد بشه تصمیم گرفتیم گوگل میت رو استریم کنیم در حالیکه باید همه رو دعوت میکردیم به گوگل میت، ازین بابت خیلی عذرخواهی میکنم و شرمنده ام😞😞
من ویدیو رو به زودی منتشر میکنم، ولی گویا اونم کیفیت خوبی نداره 🤦‍♂🤦‍♂
من به صورت تاپیک به تاپیک سعی میکنم اکثر صحبت هاشو به صورت متنی یا صوتی تو کانال بذارم که از محتوای جلسه با خبر باشید کامل

خب این از اولین جلسه tehrantechtime، میدونم که کم و کاست زیاد داشت، به بزرگواری خودتون ببخشید، ان شاءالله حتما سعی میکنیم در جلسات بعدی اگه ادامه داشت جبران کنیم.

برای اینکه از کیفیت تصویر کم نشه فرمت ویدیو HEVC/H.265 انتخاب شده، ممکنه با هر playerی باز نشه.
متاسفانه کیفیت صدا در فیلم ضبط شده هم خوب نیست، اما فکر میکنم بهتر از چیزی هست که داخل لایو بود، و احتمال زیاد بتونید گوش بدید.
اما به هرحال من قول میدم حتما حتما، تاپیک به تاپیک، سوال به سوال همه قسمت های جلسه رو به صورت voice داخل کانال منتشر کنم که در جریان همه صحبت های آقای بیل کندی قرار بگیرید.
ممنون از صبوری و همراهی تون
🌹
#tehrantechtime
#bill_kennedy

@gocasts

بحث با بیل رو از اینجا شروع کردم که گولنگ یه زبان بسیار جدیده، و حتی در ایران این زبان جدیدتر هم هست و به همین دلیل در ایران برنامه نویسان کمی هستند که به اندازه کافی تجربه کار با گولنگ را داشته باشند. همچنین به علت مهاجرت برنامه نویسان ایرانی به اروپا، این مشکل شدید تر بوده و برنامه نویسان junior فرصت کمتری برای کسب دانش از باتجربه ها دارن
سوال اولم این بود که تفاوت بین golang developer و golang engineer چیه؟

#bill_kennedy

@gocasts

بیل پاسخ داد که این یه موضوع خیلی گسترده است. بحث رو ازینجا شروع کرد که ما تعداد خیلی زیادی برنامه نویس در زبان هایی مثل java و c# و c++ داریم که خیلی از این ها میتونن بالقوه برنامه نویس گولنگ بشن و این کار رو برای متقاضیان junior که به دنبال کار هستند سخت میکنه و شما در ایران مشقت مضاعف دارید چون که دولت های ما تصمیم گرفتند با هم خوب نباشند و به علت تحریم ها، برنامه نویسان ایرانی با چالش های بیشتری برای پیدا کردن فرصت شغلی مناسب روبرو هستند.

در ادامه گفتن که اکثر فرصت های شغلی رو که نگاه کنید همه شرکت ها به دنبال «senior developer» هستند و من با تاکید این رو داخل qoute میذارم چون که خود من هم (bill) نمیتونم مصاحبه هاشونو پاس کنم!

بعدش گفت که من معتقدم که هر تیمی باید یک lead یا mentor داشته باشه و نقش این فرد نباید انجام دادن تسک های روزانه باشه و بیشتر درگیر code review و مسائل software design باید باشه.

نکته بعدی که بیل بهش اشاره کرد این بود که شما باید همیشه دو تا کلاه داشته باشید یه کلاه programming و یه کلاه engineering. کلاه programming یعنی اینکه شما بتونی کد بنویسی در حدی که کد کار بکنه و کار انجام بشه، در این مرحله احتیاجی نیست شما تمیز کد بنویسی یا idiom های گولنگ رو رعایت کنی، فقط کدی باید بنویسی که کار کنه، همین! من در استخدام آدمایی که لازم دارم فقط به این موضوع دقت میکنم که بتونن کد بزنن. در قدم بعدی این من هستم که بهشون engineering رو آموزش میدم. این نقشی هست که باید leader یا mentor داشته باشه، یعنی یک guideline و فلسفه مشخصی داشته باشه و بر اساس اون به تیم کمک کنه که مهندسی کنن. نکته دیگه ای که وجود داره اینه که حتما باید مساله و چالشی وجود داشته باشه که برای حل کردن اون چالش لازم به مهندسی باشه و از این طریقه که یه developer میتونه اصول مهندسی رو یاد بگیره. صرفا با خوندن material های متفاوت شما نمیتونی انتظار داشته باشی که شخص مهندس بشه، حتما باید چالش وجود داشته باشه. که خب یک راه حلی که پیشنهاد میشه اینه که حتما open source مشارکت کنید و سعی کنید چالش های پروژه های مربوط به شرکت های بزرگ رو حل کنید چون وقتی که برای این پروژه ها PR میفرستید، اونا کد شمارو review میکنن و کلی نکته باید و نبایدی در مورد کد به شما میگن که خیلی برای یادگیری اصول مهندسی به شما کمک میکنه.

#bill_kennedy

@gocasts

یه مثالی هم زد از اینکه تعریف کردن مسائل چالشی و حل اونها میتونه کلی نکات مهندسی به شما آموزش بده، مثلا میگفت برای یادگیری concurrency و کلی موضوع دیگه میشه یه سرویس چتی بنویسید که از پروتکل شخصی خودتون برای communication استفاده کنه نه http و نه grpc. اگه این کار رو بتونید انجام بدید خودش به اندازه کافی کلی چالش مهندسی داره و همینطور میشه چالش رو پیچیده تر کرد که نکات بیشتری رو یاد گرفت. مثلا من معتقدم اگه شما Message Bus احتیاج دارید و در محیط پروداکشن از Nats استفاده نمیکنید، احتمال زیاد دارید over engineering میکنید. اما برای یادگیری به شما میگم که برای سرویس چت خودتون یه message bus بنویسید. منظورم یه production ready messsage buse نیست، فقط یه message bus ساده باشه که functionality های اصلی رو داشته باشه. انجام دادن این پروژه خودش کلی نکات مهندسی و distributed system داره که برنامه نویس رو مجبور به یادگیری اون ها میکنه. این موضوع به شما کمک میکنه که خیلی خوب بفهمید nats چطوری کار میکنه و این طور تمرین هاست که به مرور زمان شمارو به یه senior engineer تبدیل میکنه

من ایده distributed chat رو خیلی دوست دارم و برای سال بعد میخوام دوره ultimate concurrency رو با این ایده ارائه بدم

#bill_kennedy

@gocasts