اولین الگویی که از دسته 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

این مقاله کامل از cloudflare توضیح داده چه اتفاقی برای فیسبوک افتاده

https://blog.cloudflare.com/october-2021-facebook-outage

@gocasts

قسمت سوم تست نویسی در گولنگ - integration test

تو این قسمت نشون دادم که چطور میشه تست یکپارچگی برای ماژول های مختلف سیستم نوشت. تو این آموزش تست یکپارچگی دیتابیس رو به عنوان مثال پیاده سازی کردم

به تقاضای بعضی از دوستان این آموزش رو با تم دارک ضبط کردم امیدوارم که مفید واقع بشه براتون 🙂

#golang #tdd #integration_test #test

@gocasts

بسم الله الرحمن الرحیم

أَلسَّلٰامُ عَلَیکَ یٰا عَلی اِبنِ موسَی أَلرّضٰآ أَلمُرتَضٰی

Sharded Services

در الگوی Replicated همه Replica ها مثل هم هستن و همه شون این قابلیت رو دارن که به همه درخواست های ورودی پاسخ بدن ولی در الگوی sharded هر shard فقط قابلیت پاسخگویی به زیرمجموعه ای از درخواست هارو داره

یک load-balancer که root node نام داره مسئولیت توزیع کردن درخواست های ورودی به shard های متناسب با درخواست رو بر عهده داره

معمولا از Replicated services برای ساختن stateless services استفاده میشه ولی از Sharded services برای ساختن stateful services استفاده میشه.

#designing_distributed_systems_brendan_burns

@gocasts

Sharded Caching

به عنوان یه sharded caching system رو در نظر بگیرید، وقتی میخوایم چنین سیستمی رو طراحی کنیم، سوالات مختلفی به ذهن میاد، از جمله:

- Why You Might Need a Sharded Cache
تصور کنید کل دیتای قابل کش شدن ۲۰۰ گیگ باشه، و شما ۱۰ سرویس replica داشته باشید که هر کدوم قابلیت ذخیره سازی ۱۰ گیگ دیتارو داشته باشه، ازونجایی که در مدل replica احتمال مشابه بودن دیتا در replica های مختلف خیلی زیاده، عملا شما در لحظه ۵ درصد (۱۰ گیگ از ۲۰۰ گیگ) رو دارید کش میکنید و خب این خیلی عملکرد بدیه

اما حالا تصور کنید که همون ۱۰ تا نود جای این که replicated باشن بصورت sharded باشن و هر کدوم ۱۰ گیگ دیتای متفاوت از دیگری رو کش کنن، اینطوری تقریبا ۵۰ درصد دیتای شما (۱۰۰ گیگ از ۲۰۰ گیگ) رو دارید کش میکنید که خیلی خوبه


- The Role of the Cache in Your Architecture (System Performance)
سیستم کش در سه معیار performance, reliability و stability برنامه شما بسیار تاثیرگذاره

یک معیار مهم برای ارزیابی عملکرد سیستم کش میزان hit rate هست که بالاتر بهش اشاره کردیم. تصور کنید سیستم شما قابلیت پاسخگویی به ۱۰۰۰ درخواست در ثانیه رو داشته باشه و بیشتر از اون خطای ۵۰۰ به کاربر نشون داده بشه، با اضافه کردن یه سیستم کش با hit rate نزدیک به ۵۰ درصد، شما میتونید ۲۰۰۰ درخواست رو در ثانیه پاسخ بدید، پس میتونید ببینید سیستم کش چه نقشی میتونه در performance سیستم شما داشته باشه

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


#designing_distributed_systems_brendan_burns

@gocasts

Replicated, Sharded Caches
گاهی اوقات سیستم کش به میزانی در عملکرد سیستم شما تاثیرگذاره که سیستم شما نمیتونه fail شدن یک shard رو تحمل کنه حتی برای مدت موقت، در این گونه مواقع میشه از ترکیب دو الگو استفاده کرد، یعنی یه سری shard وجود داشته باشه که دیتاهای متفاوتی از هم دارن، ولی هر shard خودش چند تا replica داشته باشه که این replica ها دیتای یکسانی دارن و در صورت fail شدن یکیشون node دیگه قادر به پاسخگویی هست

طبیعتا پیاده سازی این الگو پیچیدگی های خودشو داره، اما در کنار پیچیدگی ها، مزایای مهمی داره از جلمه resiliency در برابر failure هست.
نکته مهم دیگه اینه که شما میتونید shard های مختلف رو بر اساس لودی که دارن مستقل از یکدیگر scale بدید که بهش hot sharding میگن


#designing_distributed_systems_brendan_burns

@gocasts

An Examination of Sharding Functions

سوال مهمی که وجود داره اینه که اساسا بر طبق چه معیار و الگویی باید درخواست ها بین node های مختلف shard بشن؟
مسئولیت map کردن درخواست ورودی به یک shard خاص بر عهده sharding function هست.

معمولا sharding function خیلی شبیه به hashing function هست و مثلا bucket-based hashtable رو میشه عملا به عنوان sharding function استفاده کرد

معمولا برای sharding function از hashing function هایی استفاده میکنن که یه object رو هر چی که باشه به یه integer hash تبدیل میکنه، بعد از محاسبه باقیمانده اون integer بر تعداد shard ها، مشخص میشه که درخواست باید به کدوم shard ارسال بشه

این hash function باید دو تا خصوصیت داشته باشه:
Determinism
همیشه تابع برای یک ورودی خاص باید یک خروجی ثابت و معین رو برگردونه

Uniformity
توزیع خروجی تابع باید uniform باشه (اینطوری نباشه که روی یه سری shard ها لود وحشتناک بره و روی یه سری لودی نباشه)

ShardNO = hash(Req) % numberOfShards

#designing_distributed_systems_brendan_burns

@gocasts

Selecting a Key

همونطور که در پست قبلی اشاره شد باید به تابع هش یک ورودی داده بشه، انتخاب اینکه ورودی تابع هش چی باشه خیلی مهمه.
فرض کنید بخوایم دو پارامتر ip و path (همون route درخواست) رو به عنوان ورودی تابع هش در نظر بگیریم:
shard(request.ip, request.path)

اتفاقی که میفته اینه که مثلا دو درخواست از یک کشور مثل فرانسه ممکنه به دو تا shard مختلف توزیع بشن که این اصلا خوب نیست، ما میخوایم دیتای موقعیت های جغرافیایی یکسان رو تو یه shard نگه داریم

حالا فرض کنید کلید ورودی تابع shard رو اینگونه تغییر بدیم
shard(country(request.ip), request.path)

طبیعتا تو این حالت خیلی sharding بهتری صورت میگیره

همین یه مثال ساده نشون میده که چقدر انتخاب کلید ورودی تابع هش میتونه موثر باشه در عملکرد سیستم shard شده و اگه کلید خوبی انتخاب نکنیم شاید عملا فقط دردسرهای خودمونو زیاد کرده باشیم و sharding تاثیر چندانی نداشته باشه تو بهبود عملکرد سیستم...


#designing_distributed_systems_brendan_burns

@gocasts

Consisten Hashing

تصور کنید که شما تصمیم میگیرید که تعداد node های shard رو تغییر بدید، سوال بزرگ اینه که چه بلایی بر سر hash key ها میاد؟ چون با کم و زیاد شدن node ها عملا خروجی تابع hash برای درخواست ها تغییر میکنه و درخواست ها به node درستی داده نمیشن.
این اتفاق اجتناب ناپذیره، اما یه سری الگوریتم های hashing هستن که تضمین میکنن با تغییر تعداد node ها فقط (#keys / #shards) تعداد از کلید ها احتیاج به remap شدن به shard جدید دارن و خیلی از کلید ها همچنان به node های قبلیشون map میشن.

این الگوریتم هارو consistent hashing میگن. مثلا تصور کنید اگه تعداد node های شما از ۱۰ به ۱۱ node تغییر کنه کمتر از ۱۰ درصد درخواست ها remap میشه که خب این خیلی اتفاق خوبیه، چون remap شدن منجر به repopulate شدن دیتای مورد نیاز درخواست در node جدید میشه که بسیار هزینه بر هست برای سیستم.

استفاده از consistent hashing در بسیاری از سیستم های توزیع شده رایجه و این اهمیت اینگونه الگوریتم ها رو میرسونه

این ویدیو کوتاه خیلی خوب توضیح داده
https://www.youtube.com/watch?v=zaRkONvyGr8

همچنین این مقاله خیلی خوب visualize کرده
https://www.toptal.com/big-data/consistent-hashing

آپدیت: اینم یه مقاله خوب و پیاده سازی در زبان گولنگ
https://medium.com/codex/understanding-and-implementing-consistent-hash-algorithm-e53a35afa428


#designing_distributed_systems_brendan_burns

@gocasts

Hot Sharding Systems

خیلی اوقات پیش میاد که لود shard های مختلف یکسان نیست و شما نمیتونید این موضوع رو مدیریت کنید

در اینگونه مواقع برای استفاده بهینه از منابع بهتره که از hot sharding استفاده بشه

به این صورت که در ابتدا به همه shard ها منابع یکسانی داده میشه از تعداد machine گرفته تا میزان RAM و CPU ولی به مرور زمان بر اساس لودی که به هر shard وارد میشه، این تخصیص منابع میتونه به صورت داینامیک عوض بشه و به shardی که لود بیشتری داره منابع بیشتری اختصاص داده بشه


#designing_distributed_systems_brendan_burns

@gocasts

دوستان پیشنهاد میکنم حتما بعد از خوندن پست های مربوط به الگوی Sharding این ویدیوی کوتاه در مورد Consistent Hashing رو ببینید
تو دنیای مدرن امروز عملا همه چیز حاضر و آماده شده، و برای استفاده از این الگوها، فقط کافیه که نحوه استفاده و محل استفاده رو بلد باشید...
منظورم از این حرف اینه که اگه الگویی کمی پیچیده میشه اصلا ازش نترسید، یا دور نشید ازش، بلکه با کمی آشنایی با کلیات اون الگو میتونید خیلی راحت به کمک ابزارهای موجود توی طراحی سیستمتون استفاده کنید ازش
این الگوی replicated و shardedی که من بحث کردم عملا تو خیلی از load balancer های معروف وجود داره و با چند خط کانفیگ میتونید به راحتی ازش استفاده کنید، مثلا در nginx به این شکله

upstream backend {
hash $request_uri consistent
server web-shard-1.web;
server web-shard-2.web;
server web-shard-3.web;
}

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


#designing_distributed_systems_brendan_burns

@gocasts

نکته آخری که میخوام بهش اشاره کنم اینه که شاید بپرسید الگوهایی مثل الگوی Sharded برای scale خیلی بالاست و احتمال خیلی زیاد شما تو کارتون بهش نیاز ندارید.

جواب کوتاه من میشه:خیر. دلیل من هم اینه که با رشد تکنولوژی، بسترهای ارائه خدمات خیلی پیچیده تر و اصطلاحا data-intensive تر شدن، به عنوان مثال الان دیگه messaging فقط برای چت کردن نیست، بلکه messaging یک platform شده برای کلی خدمات دیگه مثل آموزش، کسب و کار و غیره.
یا مثلا سرویس های ویدیویی در این دو سه ساله رشد بسیار زیادی داشتن مخصوصا پس از پاندمی کرونا. خود بلاکچین و پلتفرم های مبتنی بر هوش مصنوعی و iot هم ذاتا data-intensive هستن.

وقتی میگیم data-intensive یعنی اینکه حجم دیتایی که شما باید مدیریت کنید ذاتا زیاده (اگه الان نیست بزودی میشه). پس باید از قبل خودتون رو برای اون روز آماده کنید، که اگه به فکر scale نباشید و اصولش رو رعایت نکنید، چالش های زیادی در آینده خواهید داشت.

من اصلا منظورم این نیست که در لحظه کاری که میکنید رو خیلی over-engineering کنید، نه اصلا، بلکه هدفم اینه که توی طراحی و دیزاین حتما نیم نگاهی به این قضیه داشته باشید و به این فکر کنید که با طراحی فعلی اگه قرار باشه سیستم scale پیدا کنه، آیا سیستم پاسخگو هست یا خیر، آیا میتونید دیتابیس رو shard کنید بصورت موثر یا خیر.

شاید خوندن مقاله ای از تیم Notion که اخیرا درگیر این چالش بودن مفید باشه، که یکی از مواردی که بهش اشاره میکنه Shard earlier هست، و میگه که ای کاش زودتر به این فکر بودیم...
https://www.notion.so/blog/sharding-postgres-at-notion

دمتون گرم، یا علی

#designing_distributed_systems_brendan_burns

@gocasts

در مورد مفاهیم 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