TGViewer
Channel Public Channel
Go Casts | Systems & Agents 🚀

Go Casts | Systems & Agents 🚀

@gocasts

Ex Snapp! Senior Software Engineer
فوق لیسانس هوش مصنوعی از دانشگاه تهران

اشتراک محتوا در مورد مهندسی نرم افزار، ایجنت های هوش مصنوعی
https://gocasts.ir

پروفایل
https://www.linkedin.com/in/gohossein

ارتباط
@lifography

Ai for Software
@aicasts_ir
Open in Telegram
Subscribers
10.3K
Photos
296
Videos
21
Links
542

Showing posts older than #65 · Back to latest

Older Posts 20 shown
Post #64 701
Go Casts | Systems & Agents 🚀 نکته آخری که میخوام بهش اشاره کنم اینه که شاید بپرسید الگوهایی مثل الگوی Sharded برای scale خیلی بالاست و احتمال خیلی زیاد شما تو کارتون بهش نیاز ندارید. جواب کوتاه من میشه:خیر. دلیل من هم اینه که با رشد تکنولوژی، بسترهای ارائه خدمات خیلی پیچیده تر و اصطلاحا…
سلام دوستان، امیدوارم حالتون خوب باشه، من باز اومدم با یه الگوی دیگه از دنیای 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
Post #63 720
Go Casts | Systems & Agents 🚀 Introduction to Microservices در سال های اخیر عبارت «microservices» برای توصیف multi-node distributed software archetectures یک عبارت همه گیر شده است. عموما Microservices سیستمی را توصیف می کنه که از چند component مختلف تشکیل شده که هر کدام از این component…
در مورد مفاهیم Microservice و SOA بحث جالبی با آقای حکایتی شکل گرفت که در کامنت های این پست میتونید مطالعه کنید.

https://t.me/c/1525472919/105

https://t.me/c/1525472919/106

https://t.me/c/1525472919/107
Post #62 787
Go Casts | Systems & Agents 🚀 دوستان پیشنهاد میکنم حتما بعد از خوندن پست های مربوط به الگوی Sharding این ویدیوی کوتاه در مورد Consistent Hashing رو ببینید تو دنیای مدرن امروز عملا همه چیز حاضر و آماده شده، و برای استفاده از این الگوها، فقط کافیه که نحوه استفاده و محل استفاده رو بلد باشید...…
نکته آخری که میخوام بهش اشاره کنم اینه که شاید بپرسید الگوهایی مثل الگوی 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
Notion Herding elephants: lessons learned from sharding Postgres at Notion With an effort to make Notion faster and more reliable for years to come — we migrated Notion’s PostgreSQL monolith into a horizontally-partitioned database fleet.
Post #61 694
Go Casts | Systems & Agents 🚀 Consisten Hashing تصور کنید که شما تصمیم میگیرید که تعداد node های shard رو تغییر بدید، سوال بزرگ اینه که چه بلایی بر سر hash key ها میاد؟ چون با کم و زیاد شدن node ها عملا خروجی تابع hash برای درخواست ها تغییر میکنه و درخواست ها به node درستی داده نمیشن.…
دوستان پیشنهاد میکنم حتما بعد از خوندن پست های مربوط به الگوی 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
Post #60 620
Go Casts | Systems & Agents 🚀 Consisten Hashing تصور کنید که شما تصمیم میگیرید که تعداد node های shard رو تغییر بدید، سوال بزرگ اینه که چه بلایی بر سر hash key ها میاد؟ چون با کم و زیاد شدن node ها عملا خروجی تابع hash برای درخواست ها تغییر میکنه و درخواست ها به node درستی داده نمیشن.…
Hot Sharding Systems

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

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

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


#designing_distributed_systems_brendan_burns

@gocasts
  • 👍 1
Post #59 640
Go Casts | Systems & Agents 🚀 Selecting a Key همونطور که در پست قبلی اشاره شد باید به تابع هش یک ورودی داده بشه، انتخاب اینکه ورودی تابع هش چی باشه خیلی مهمه. فرض کنید بخوایم دو پارامتر ip و path (همون route درخواست) رو به عنوان ورودی تابع هش در نظر بگیریم: shard(request.ip, request.path)…
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
YouTube What is CONSISTENT HASHING and Where is it used? Load Balancing is a key concept to system design. One of the popular ways to balance load in a system is to use the concept of consistent hashing. Consistent Hashing allows requests to be mapped into hash buckets while allowing the system to add and remove…
Post #58 601
Go Casts | Systems & Agents 🚀 An Examination of Sharding Functions سوال مهمی که وجود داره اینه که اساسا بر طبق چه معیار و الگویی باید درخواست ها بین node های مختلف shard بشن؟ مسئولیت map کردن درخواست ورودی به یک shard خاص بر عهده sharding function هست. معمولا sharding function خیلی شبیه…
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
Post #57 595
Go Casts | Systems & Agents 🚀 Replicated, Sharded Caches گاهی اوقات سیستم کش به میزانی در عملکرد سیستم شما تاثیرگذاره که سیستم شما نمیتونه fail شدن یک shard رو تحمل کنه حتی برای مدت موقت، در این گونه مواقع میشه از ترکیب دو الگو استفاده کرد، یعنی یه سری shard وجود داشته باشه که دیتاهای…
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
Post #56 590
Go Casts | Systems & Agents 🚀 Sharded Caching به عنوان یه sharded caching system رو در نظر بگیرید، وقتی میخوایم چنین سیستمی رو طراحی کنیم، سوالات مختلفی به ذهن میاد، از جمله: - Why You Might Need a Sharded Cache تصور کنید کل دیتای قابل کش شدن ۲۰۰ گیگ باشه، و شما ۱۰ سرویس replica داشته…
Replicated, Sharded Caches
گاهی اوقات سیستم کش به میزانی در عملکرد سیستم شما تاثیرگذاره که سیستم شما نمیتونه fail شدن یک shard رو تحمل کنه حتی برای مدت موقت، در این گونه مواقع میشه از ترکیب دو الگو استفاده کرد، یعنی یه سری shard وجود داشته باشه که دیتاهای متفاوتی از هم دارن، ولی هر shard خودش چند تا replica داشته باشه که این replica ها دیتای یکسانی دارن و در صورت fail شدن یکیشون node دیگه قادر به پاسخگویی هست

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


#designing_distributed_systems_brendan_burns

@gocasts
Post #55 626
Go Casts | Systems & Agents 🚀 بسم الله الرحمن الرحیم أَلسَّلٰامُ عَلَیکَ یٰا عَلی اِبنِ موسَی أَلرّضٰآ أَلمُرتَضٰی Sharded Services در الگوی Replicated همه Replica ها مثل هم هستن و همه شون این قابلیت رو دارن که به همه درخواست های ورودی پاسخ بدن ولی در الگوی sharded هر shard فقط قابلیت…
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
Post #54 711
Go Casts | Systems & Agents 🚀 سوال: توی معماری میکروسرویس باید حتما از یکی از این الگو ها استفاده و پیروی کرد؟ یکی از دوستان این سوال رو پرسیدند، در جواب باید بگم، بله استفاده از این الگوها عملا اجتناب ناپذیر هست، چرا؟ چون یکی از مهم ترین ویژگی های هر بیزینس availability هست، شما باید…
بسم الله الرحمن الرحیم

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

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
Post #53 1.92K
قسمت سوم تست نویسی در گولنگ - integration test

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

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

#golang #tdd #integration_test #test

@gocasts
Post #52 1.3K
این مقاله کامل از cloudflare توضیح داده چه اتفاقی برای فیسبوک افتاده

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

@gocasts
Cloudflare Blog Understanding how Facebook disappeared from the Internet Today at 1651 UTC, we opened an internal incident entitled "Facebook DNS lookup returning SERVFAIL" because we were worried that something was wrong with our DNS resolver 1.1.1.1. But as we were about to post on our public status page we realized something…
Post #51 1.8K
دوستان باور کنید اگه این مقاله رو نخوندید، عملا هیچی در مورد 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
  • 👍 1
Post #50 802
Go Casts | Systems & Agents 🚀 اولین الگویی که از دسته Serving Pattern ها با هم بررسی می کنیم الگوی «Replicated Load-Balanced Services» هست این الگو یه الگوی ساده است که خیلی هامون باهاش آشنایی داریم. به این صورت که یه سری node داریم که همگی قابلیت این رو دارن که به همه درخواست ها پاسخ…
سوال: توی معماری میکروسرویس باید حتما از یکی از این الگو ها استفاده و پیروی کرد؟

یکی از دوستان این سوال رو پرسیدند، در جواب باید بگم، بله استفاده از این الگوها عملا اجتناب ناپذیر هست، چرا؟
چون یکی از مهم ترین ویژگی های هر بیزینس 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
Post #49 722
Go Casts | Systems & Agents 🚀 Stateless Services حالا Stateless Service چیه؟ سرویسیه که هیچگونه stateی رو نیاز نداشته باشه برای پاسخگویی به یه درخواست جدید. مثال: یه سری اپلیکیشن ها وقتی کاربر لاگین میکنه یه سری دیتا بصورت session سمت سرور نگه میدارن، و از کلاینت انتظار دارن همراه درخواست…
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
  • ❤ 1
Post #48 660
Go Casts | Systems & Agents 🚀 اولین الگویی که از دسته Serving Pattern ها با هم بررسی می کنیم الگوی «Replicated Load-Balanced Services» هست این الگو یه الگوی ساده است که خیلی هامون باهاش آشنایی داریم. به این صورت که یه سری node داریم که همگی قابلیت این رو دارن که به همه درخواست ها پاسخ…
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
BMC Blogs Resiliency vs Redundancy: What’s the Difference?
Post #47 691
Go Casts | Systems & Agents 🚀 برای Microservices ها مزایای زیادی وجود داره که اکثر این مزایا حول محور دو موضوع هستن Reliability Agility کوچک بودن سرویس ها باعث میشه هر تیم بصورت جداگانه بتونه توسعه یک یا چند کامپوننت رو بر عهده بگیره و همین باعث میشه که تیم ها اصطکاک کمتری در ارتباط با…
اولین الگویی که از دسته Serving Pattern ها با هم بررسی می کنیم الگوی «Replicated Load-Balanced Services» هست

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


#designing_distributed_systems_brendan_burns

@gocasts
Post #46 1.75K
Maestro بخش اول unit test در golang موضوعاتی که پوشش داده شده unit test (simple functions without any dependency) table driven test subtests #golang #unit_test #test @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
Post #45 788
Go Casts | Systems & Agents 🚀 Introduction to Microservices در سال های اخیر عبارت «microservices» برای توصیف multi-node distributed software archetectures یک عبارت همه گیر شده است. عموما Microservices سیستمی را توصیف می کنه که از چند component مختلف تشکیل شده که هر کدام از این component…
برای Microservices ها مزایای زیادی وجود داره که اکثر این مزایا حول محور دو موضوع هستن
Reliability

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

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

#designing_distributed_systems_brendan_burns

@gocasts
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →