Distributed-Systems

Я побывал на достаточно большом количестве архитектурных встреч, чтобы знать, что происходит, когда кто-то упоминает теорему CAP: в комнате становится тихо, головы понимающе кивают, и внезапно все начинают обсуждать устойчивость к разделению, как будто планируют действия на случай ядерной аварии. Дело в том, что беспокоиться настолько сильно, вероятно, не стоит. Не поймите меня неправильно. Теорема CAP — это законная и важная концепция в распределённых системах. Но она также стала техническим эквивалентом спортивного автомобиля на пригородной подъездной дорожке: впечатляет, что он есть, редко используется на полную мощность и иногда используется для оправдания сомнительных решений в 2 часа ночи во время кризисного совещания....

Дилемма блокировки: когда sync.Mutex уже недостаточно Вы знаете это чувство, когда осознаёте, что ваш драгоценный мьютекс в процессе уже не справляется? Да, мы все бывали в такой ситуации. Ваши предположения об однопотоковом выполнении работали нормально, пока ваша система не решила вырасти и стать распределённой. Вдруг у вас появляется несколько сервисов, работающих на разных машинах, все пытаются получить доступ к одному и тому же ресурсу, а ваш sync.Mutex сидит и выглядит растерянным — потому что он блокирует только внутри одного процесса....

Если вы когда-либо создавали приложение, которое идеально работало на вашем ноутбуке, но почему-то разваливалось, как только появлялись реальные пользователи, поздравляю — вы только что поняли, зачем существуют распределённые системы. Они не являются какой-то сложной теоретической концепцией, придуманной компьютерными учёными, которые выпили слишком много кофе. Это практический ответ на вполне реальную проблему: как заставить вещи работать, когда вы не можете уместить всё на одном сервере? Позвольте мне провести вас через архитектуру распределённых систем — хорошие части, запутанные части и части, которые заставляют спросить: «Зачем кто-то вообще так проектировал?...

Почему ваши системы постоянно выходят из строя (и как Erlang на самом деле это исправляет) Начну с того, с чем сталкивается большинство разработчиков в 2 часа ночи: производственная система выходит из строя из-за сбоя одного небольшого компонента. Вы, вероятно, повсюду добавляли блоки try-catch, добавили логику повторных попыток, которая как-то усугубила ситуацию, и создали защитный код, настолько запутанный, что никто не осмеливается его трогать. Затем вы слышите об Erlang, и кто-то вскользь упоминает «позволить системе упасть», как будто это особенность, а не кошмар....

Помните, когда REST API казались самыми крутыми ребятами на блоке? Да, времена меняются. Если вы утонули в коде REST API и наблюдаете, как ваши микросервисы перетаскивают данные, словно пробираются через патоку, возможно, пришло время узнать, почему gRPC стал предпочтительным решением для организаций, которые действительно заботятся о производительности. Позвольте мне быть откровенным: gRPC — это не просто очередной технологический хайп. Это действительно практичная платформа, которая решает реальные проблемы в распределённых системах. И нет, вам не нужно иметь учёную степень по информатике, чтобы понять её....