یه نکته ای که تو الگوی sidecar باید بهش توجه بشه اینه که این دو تا container اصطلاحا tightly coupled هستن، یعنی یه سری shared resource دارن، مثلا در مثال nginx proxy دو تا container باید یه network داشته باشن
یا مثلا وقتی از fluentd برای log aggregate کردن استفاده میشه به عنوان sidecar باید یه shared mounted volume وجود داشته باشه که application container داخل اون لاگ هاشو میریزه و fluentd container اون لاگ هارو از فایل میخونه و consume میکنه

اصلاحا به container هایی که تو یه گروه هستن، با هم schedule میشن و shared resource دارن pod گفته میشه
تو الگوی sidecar همیشه کانتینر داخل pod مربوط به application قرار میگیره

#designing_distributed_systems_brendan_burns

@gocasts

The Ambassadors pattern
الگوی ambassadors یکی دیگه از single-node pattern هاست که جلوی app container میشینه و ارتباط app رو با دنیای بیرون مدیریت میکنه.

بر خلاف sidecar pattern که عموما یک functionality به app اضافه میکرد الگوی ambassadors عموما در خروجی app مداخله میکنه و تعامل با دنیای بیرون app از طریق ambassador container صورت میگیره

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

#designing_distributed_systems_brendan_burns

@gocasts

using an Ambassador to Shard a Service
خیلی از اوقات در scale بالا مدیریت حجم زیادی از داده ها در یک single machine ممکن نیست و به اجبار داده ها باید بین چندین instance مختلف shard بشن

این موضوع نباید تغییری در application برای ارتباط با storage layer ایجاد کنه

#designing_distributed_systems_brendan_burns

@gocasts

شاید ایده اولیه ای که به ذهن میرسه این باشه که خود application این موضوع رو مدیریت کنه و با دونستن اینکه چه تعداد shard وجود داره، هر بار بر اساس الگوریتم و داده مورد نظر انتخاب کنه که کوئری رو به کدوم instance بفرسته
اما این راه حل پیچیدگی زیادی به لاجیک اضافه میکنه و مشکلات زیادی داره، از جمله اینکه سیستم باید از سلامت shard instance ها با خبر باشه

راه حل بهتر اینه که یک ambassador service در هر pod مربوط به application باشه که با توجه به کوئری ورودی تعیین کنه درخواست رو به کدوم shard instance بفرسته، مزیت اصلی این الگو اینه که application نیاز نیست تغییری ایجاد کنه و مثل معمول صرفا به یک local database service درخواست هاشو میفرسته، و این ambassador service هست که تمامی پیچیدگی های sharding رو مدیریت میکنه.
مزیت دوم این الگو modularity هست، زیرا میتوان به راحتی این ambassador container رو برای طیف زیادی از application های مختلف استفاده کرد بدون اینکه نیاز باشه در لاجیک اون application ها تغییری ایجاد بشه

به عنوان مثال اگه شما میخواید redis رو بصورت shard شده استفاده کنید میتونید از کد زیر برای پیاده سازی چنین معماری ای در kubernetes استفاده کنید:
https://github.com/brendandburns/designing-distributed-systems/blob/master/ambassadors/redis-shards.yaml

#designing_distributed_systems_brendan_burns

@gocasts

Using an Ambassador for Service Brokering
یکی از ملزومات portable کردن application برای استفاده در محیط های مختلف بحث service discovery هست.

تصور کنید که application شما در محیط production باید به یه public cloud متصل بشه مثل AWS RDS و برای محیط staging به یک physical datacenter یا private cloud متصل بشه

مدیریت کردن این موضوع لاجیک application رو پیچیده میکنه، زیرا بر اساس محیطی که در اون قرار داره باید بحث service discovery رو مدیریت کنه.

بهتر اینه که یک service broker بصورت ambassador container داشته باشیم، که مسئولیت این موضوع رو قبول کنه، و application طبق معمول صرفا به یه local database متصل بشه

#designing_distributed_systems_brendan_burns

@gocasts

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