«Хе Эр» рассказывает о микросервисах и распределенных системах | 🏆 Пятый выпуск технической тематики

яи уши, давно не писал реферат.Сегодня воспользуюсь возможностью пятого выпуска реферата пообщаться с вами.分布式.

Некоторое время назад я не писал статью, потому что был занят интервью~, да 😂 Я уволился с работы и сменил компанию на работу.Системы новой компании распределены.После того, как я присоединился к компании на месяц и написал что-то онлайн, я осмелился написать об этой раздаче.Если у вас нет производственного опыта, вас введут в заблуждение ваши дети.

Сегодня, главным образом, концепция деятельности эссе и распределенной системы и ее общие распределенные компоненты и дизайнерские идеи (не связанные с технической теорией распределенной системы в информатике), прежде чем готовить это интервью, я видел много распределенных компонентов на рынке и распределенные компоненты, используемые в нашей компании, в основном не имели знаний, я понял (используется компанияApolloЯ не знал об этом заранее, большая Е), если вы мало знаете о стеке распределенных технологий, вы также можете использовать это эссе в качестве своего поста для повышения грамотности, но не забудьте поставить лайк👍👍

Монолитные приложения и кластеры

单体应用、集群和微服务, как только этот заголовок выйдет, вы можете знать, что я хочу сказать, эмм, это эволюция архитектуры, многие люди могли прочитать соответствующие знания, но я все же намерен кратко рассказать о целостности статьи.

прежде всегоМонолитное приложение, На начальном этапе бизнеса это часто этап с небольшим количеством пользователей и несколькими запросами на доступ.На этом этапе нам обычно нужно только развернуть веб-приложение и базу данных для удовлетворения наших бизнес-потребностей.SpringBootПопулярность веб-сервера может быть встроена в приложение, что позволяет более удобно и быстро развертывать приложение.

В то же время, поскольку масштаб проекта невелик, бизнес-процесс прост, а обслуживание и итерация также очень удобны, поэтому единое приложение очень подходит на данном этапе.

Но по мере роста бизнеса одно приложение неизбежно будет сталкиваться с узкими местами, приведу пример:

Если наше текущее единственное приложение Tomcat может поддерживать толькоQPS200, по мере увеличения числа пользователей параллелизм увеличивается и постепенно превышает предел, который может выдержать одно приложение.QPS300, так много запросов 100 могут быть запрошены только после обработки предыдущих запросов.Следствием этого является то, что время ответа увеличивается, и это влияет на работу пользователя.

Или дело в нашем приложении более сложное, и время отклика на один запрос относительно велико.В этом случае будет сжато большое количество запросов, что также приведет к плохому пользовательскому опыту.Они явно чувствуют, что после нажатия кнопки проходит 1-2 секунды, возвращается результат.

На этом этапе мы можем представитьКластерная архитектураТеперь мы можем одновременно развернуть две копии одного приложения и передатьNginxВыполнять обратный прокси и балансировку нагрузки для шунтирования трафика, чтобы QPS каждого отдельного приложения составлял 150, что находится в допустимом диапазоне, и между обслуживанием кластерных приложений и обслуживанием одномашинных приложений мало разницы, только когда дело доходит до блокировок Иногда это можно сделать с помощью распределенных блокировок.

До сих пор всякий раз, когда трафик увеличивается и система достигает узкого места, мы можем расширять емкость по горизонтали, добавляя машины для постоянного увеличения нагрузки на приложение, но если этот метод идеален, нам не нужна микросервисная архитектура. ~

Переход от одиночного приложения к кластерной архитектуре на самом деле является проблемой производительности.Одна машина больше не может удовлетворить растущие потребности людей в доступе, поэтому возникла кластерная архитектура.

Тогда больше повод для перехода с кластерной на микросервисную архитектуру точно не производительность.Здесь я расскажу о своих взглядах и инсайтах:

Прежде всего, поскольку проект уже является кластером, это доказывает, что объем бизнеса будет не очень маленьким, а значит, код должен иметь некоторый масштаб. кода в этом проекте.В большинстве случаев происходит постоянный конфликт.
Во-вторых, так много кода агрегируется вместе, что когда вы делаете функциональную модификацию, если вам нужно выполнить полный объем регрессионного тестирования, это будет ужасно.
Кроме того, все бизнес-блоки находятся в одной системе, что приведет к невозможности максимально использовать ресурсы.Например, система электронной коммерции должна быть наиболее часто используемой системой для систем поиска/рекомендации товаров.Конечно, они должны занимают больше машинных ресурсов с точки зрения ресурсов. , но если бизнес не разделен, если вы хотите расширяться по горизонтали, вы можете расширять только все бизнесы вместе.
Наконец, это может вызвать лавинный эффект: например, если в вашей системе есть очень неважное дело (например, регистрация), код написан неправильно и вызывается в производственной среде.OOM, то это неизбежно повлияет на то, что все службы во всей системе станут недоступными, поскольку между различными службами нет физической изоляции.

Благодаря этим нескольким пунктам мы можем понять, что переход на микросервисы — это не узкое место в производительности, а люди, бизнес и, самое главное, высокая доступность системы приложений.

Микросервисы и распределенные

Микросервисы — это шаблон архитектуры программного обеспечения, ориентированный на службы, который существует с 2014 года.Martin FowlerиJames Lewisнаписал微服务架构После статьи (концепция микросервисов существовала и раньше) микросервисы обсуждались и практиковались в производственных проектах: коммерческие компании, такие как Netflix и Amazon, имеют успешные кейсы микросервисов.Все дело в стоимости, они не набрасываются на концепцию, которую Мартин Фаулер предполагает, что только потому, что он знаменитость (гигант) в области разработки программного обеспечения, он должен пройти через множество компромиссов, прежде чем использовать архитектуру микросервисов для своей модели проекта.

В предыдущем разделе я кратко рассказал о недостатках кластерной архитектуры.Микросервисы стали такими популярными, потому что они решили эти недостатки.Для определения микросервисов здесь я цитирую абзац.Martin Fowlerоригинальныйс картинками и переводами для иллюстрации:

Короче говоря, архитектурный стиль микросервиса подобен разработке отдельного приложения в виде набора небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует с помощью легковесного механизма, обычно HTTP API.

Эти сервисы строятся с учетом бизнес-возможностей и развертываются независимо с помощью полностью автоматизированного механизма развертывания. Эти сервисы написаны на разных языках программирования, а также с разными технологиями хранения данных и поддерживают минимальное централизованное управление.

Если мне нужно понять это на моем родном языке, это так: разделить большую систему на маленькие сервисные системы одну за другой для совместной поддержки большой системы, и каждую маленькую сервисную систему можно независимо разрабатывать/тестировать/итерировать/разворачивать/расширять.

После разделения большой системы на небольшие сервисы она не только обладает соответствующими преимуществами небольших сервисов (благоприятными для командной работы/тестирования/итерации), но также позволяет расширять кластер перед лицом большого трафика.Можно сказать, что он сочетает в себе преимущества обоих. Это называется”天下大势，合久必分，分久必合。”

Новая компания, к которой я присоединился, также полностью перешла на микросервисную архитектуру в начале этого года.Все бизнесы в нашем отделе были разделены на микросервисы для работы.Разделение микросервисов зависит от мнения и потребностей быть проанализированы по конкретным бизнесам. , мы чувствуем себя лучше в процессе разделения: некоторые бизнесы, которые перестанут работать в ближайшие год-два, также отделяются и работают в одном сервисе.

На самом деле понятие микросервисов несложно понять, но если вы на самом деле это сделаете, то проблема, с которой вы столкнетесь, как правило, не проблема микросервиса, а распределенная проблема.Многие люди часто путают эти два понятия, думая, что речь идет о Одни и те же вещи на самом деле являются двумя вещами, и вещи, которые мы делаем, часто охватывают эти два понятия.

Микросервис относится к сервис-ориентированной программной архитектуре, тогда как распределенный — это программная система, которая координирует работу нескольких компьютерных узлов для достижения общей цели.

В пояснении к предыдущему разделу всегда появляется предложение:随着业务量/访问量增大, этот растущий объем трафика/трафика/данных является основной причиной, по которой мы используем микросервисы и распределенные системы:

С ростом бизнеса мы решаем проблемы, вызванные разделением бизнеса, которое можно отнести к категории микросервисов.
Разные службы развернуты на разных машинах, но для пользователей это ничем не отличается от доступа к системе.Опирание на сеть для формирования единого целого из нескольких компьютерных узлов можно отнести к категории распределенных систем.
Из-за постоянного увеличения объема данных мы можем распределять объем данных за счет увеличения количества машинных узлов, что является категорией распределенного хранилища в распределенных системах. Например, наши данные Redis больше не могут храниться на одном компьютере, поэтому мы должны рассмотреть возможность их использования.RedisClusterРаспределяйте данные по нескольким компьютерам, а другое ПО промежуточного слоя, такое как Kafka и ES, которое представляет собой распределенную архитектуру, может выполнять распределенное хранение.
Если некоторые ресурсоемкие задачи в приложении занимают слишком много времени для выполнения на одном компьютере, мы можем разделить задачи на несколько узлов для одновременного выполнения, что является категорией распределенных вычислений в распределенных системах. Недавно, когда я взялся за проект, я столкнулся с похожей проблемой: первоначальная задача слишком долго выполнялась на одной машине, поэтому я изменил ее на все онлайн-узлы, чтобы они выполнялись одновременно, разделяли задачу и иметь возможность динамически разделять задачу по количеству онлайн-узлов.

Я думаю, что благодаря объяснению четырех вышеприведенных пунктов у всех должно быть простое различие между микросервисами и распределенными, и еще раз подведем итоги:

Так почему же микросервисы и распределенные системы всегда обсуждаются вместе, а их определения многими людьми неоднозначны, потому что частоКогда мы хотим реализовать приложение с микросервисной архитектурой, мы реализуем распределенную систему.

Если вы не понимаете, о чем я говорю, внимательно подумайте, соответствует ли приложение, состоящее из микросервисной архитектуры, определению распределенного.

Советы:Распределенные вычисления/хранение также являются исследовательским направлением в компьютерных науках, поэтому на самом деле они могут быть набором эзотерических вещей.

Распределенный и CAP

Прочитав предыдущий раздел, вы должны были понять взаимосвязь между микросервисами и распределенным распространением. В этой статье основное внимание уделяется фактически распределенному, потому что микросервисы - это всего лишь сервис-ориентированная концепция архитектуры программного обеспечения, поэтому я могу понять ее основную роль. концепции разделения сервисов, независимой разработки и развертывания, эмм~ концепций, но у распределенной системы есть много различных практических проблем, которые необходимо решить, поэтому я сосредоточусь на распределенной.

Поговорим о распределенномCAP原则, Любой, кто немного разбирается в распределении, должен знать этот CAP. Давайте сначала посмотрим на его определение:

Принцип CAP, также известный как теорема CAP, относится к тому факту, что в распределенной системепоследовательность(Последовательность),Удобство использования(Доступность),Допуск перегородки(допуск перегородки).

Принцип CAP означает, что эти триэлементыМаксимум два пункта могут быть достигнуты одновременно, и невозможно позаботиться обо всех трех.

Отказоустойчивость зонирования:Это означает, что машины, развернутые в разных местах в распределенной системе, могут не подключиться к сети.Это похоже на то, как моя служба рекомендаций будет запрашивать данные в стандартной службе, но могут быть колебания сети, которые вызывают запрос, инициированный моей службой рекомендаций. , Время ожидания сетевого подключения истекло.

Доступность:Это означает, что запрос пользователя должен возвращать результат.Чтобы достичь этого уровня, нам нужно развернуть приложения в разных компьютерных залах, чтобы избежать ситуации, когда компьютерный зал сталкивается с аварией и приводит к отключению службы.

последовательность:Это означает, что после изменения данных данные, считанные позже, должны быть самыми последними данными.

В приведенном выше определении уже говорилось, что CAP может достигать не более двух точек одновременно, поскольку мы являемся распределенной системой, поэтому несколько сервисных узлов неизбежны, то есть мы должны обеспечить отказоустойчивость раздела, поэтому мы можем гарантировать только реализация CP или AP.

Почему нельзя внедрить CAP одновременно? Причина очень проста, потому что требование доступности требует нескольких избыточных копий данных каждого узла, чтобы гарантировать, что копия может подняться после того, как узел умрет. Однако из-за сетевой связи между узлом-репликой и узлом-узлом часто возникает задержка в передаче этих данных, что не гарантирует, что реплика сможет получить модификацию сразу после изменения данных узла, а может только быть получены после задержки для размещения измененных данных.

Для того, чтобы облегчить ваше понимание, я дам еще один пример, чтобы проиллюстрировать, например, распределенное промежуточное программное обеспечениеRedis:

Это может гарантировать CP в случае одной машины.Поскольку есть только один узел Redis, данные, к которым обращается запрос после изменения данных, являются самыми последними.

Это может гарантировать AP в случае кластера.AP подчеркивает доступность.В кластерной архитектуре, если главный узел зависает, узел-реплика может продолжать отвечать на запрос.

Поскольку CAP не может гарантировать в то же время, мы должны согласиться на следующий лучший вариант, и здесь мы придем к новой теории:BASE.

BASE — это аббревиатура от «Basicly Available», «Soft state» и «Enabled state».

BASE является результатом баланса между согласованностью и доступностью в CAP.Идея соответствия заключается в том, что даже если не может быть достигнута строгая согласованность, каждое приложение может принять соответствующий метод, чтобы система достигла окончательной согласованности в соответствии с ее собственными бизнес-характеристиками. .

Основные доступные:Это относится к потере частичной доступности при определенных обстоятельствах. Например, в нашей акции Double Eleven вы не сможете разместить заказ из-за резкого увеличения количества размещенных заказов. Это означает, что служба заказа недоступна, но это ненадолго.долго,но недолго.

Мягкое состояние:Относится к ситуации, когда задержка синхронизации реплик может вызвать несогласованность реплик.

Конечная согласованность:Это означает, что все копии системных данных системы могут, наконец, достичь согласованности данных после периода задержки, и нет необходимости обеспечивать согласованность данных в реальном времени.

Нам нужны и доступность, и согласованность, но мы не можем иметь и того, и другого, поэтому теория BASE предлагает такой компромисс за счет высокой доступности и строгой согласованности.

Многие системы в действительности основаны на идее теории BASE, которая обеспечивает базовую доступность и окончательную непротиворечивость системы.

Распределенная разработка и компоненты

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

Если вы новичок, не пугайтесь этих терминов. Вы можете делать то, что знают другие. В этом разделе я объясню основные компоненты распределенной разработки сверху вниз. Вы можете сначала забыть эти термины и прочитать мое объяснение Прочитав эту главу, я думаю, что больше не буду смущаться по этому поводу.

Как я уже говорил ранее, распределенная система состоит из нескольких узлов в целом, и IP-адреса разных узлов должны быть разными.Если вы хотите чувствовать себя как единое целое, должен быть компонент перед всеми узлами, чтобы считать роль распределения запросов, эта штука называется:网关.

Общий шлюз состоит из двух уровней: первый уровень — это серверный Nginx+LVS, а второй — шлюз распределенных приложений, о котором я говорю, — шлюз распределенных приложений.

Роль этого шлюза немного похожа на Nginx, который может помочь вам сделать обратное проксирование и балансировку нагрузки, но он мощнее его.Первая остановка всех запросов распределенных приложений — это уровень шлюза приложения, где вы можете проверять, является ли запрос законным или нет., блокировать сетевые атаки, а также может выполнять динамическое распределение запросов.

После того, как запрос перенаправлен шлюзом в соответствующий сервис, он обрабатывается соответствующим сервисом. В это время проблема возникает снова. Мы можем развернуть три или четыре узла для одного и того же сервиса. На какой сервер я должен перенаправить в это время время?

Если мы хотим пересылать, мы должны сначала знать IP и номер порта каждого узла.Мы не можем записать эту информацию на смерть.Если она записана на смерть, это не способствует динамическому добавлению машин, поэтому в это время нам нужно использовать среднюю цену:注册中心.

Все наши сервисы будут зарегистрированы в реестре.Конечно, реестр также должен быть кластером, который может обеспечить высокую доступность.

Например: у меня есть товарный сервис и я назвал его товар-сервис, и я ему три сервера настроил, и эти три сервера будут прописаны в реестре, а потом мы его увидим в реестре Там три узла под штука под названием товар-сервис, а номер IP-порта каждого узла будет сохранен в реестре.

В это время, когда наш шлюз выполняет переадресацию, мы используем имя «товар-сервис», чтобы перейти в центр регистрации, чтобы получить адреса трех узлов, а затем, наконец, решить, на какой узел мы хотим отправить запрос в соответствии с различными стратегиями.

Процесс отправки запроса серверной службе, мы можем назвать его как服务通信,Существует вообще два метода связи: HTTP и RPC.На самом деле, я не думаю, что тут много говорить.Основная причина в том, что протоколы связи разные, и разные протоколы также обуславливают разную эффективность.

Три более важных компонента упомянуты выше, а есть еще два важных, послушайте меня.

первый配置中心, это на самом деле то, что можно использовать или нет, но это более удобно в использовании. Его основная функция - управлять конфигурацией распределенных приложений в одном месте. Когда нам нужно изменить, мы можем сделать все ссылки на эти конфигурации. Приложение знает об этих измененных конфигурациях и динамически загружает их во время выполнения.

Например, если у нас есть шесть микросервисных приложений, мы можем единообразно разместить конфигурацию на промежуточном программном обеспечении центра конфигурации.Эти данные обычно размещаются в базе данных, подключенной к центру конфигурации, поэтому это эквивалентно извлечению конфигурации всех наших проектов. и размещение их там.В базе данных, как только есть какая-либо конфигурация, которую необходимо динамически изменить в онлайн-операции, мы можем напрямую изменить ее на промежуточном программном обеспечении, и тогда все приложения получат уведомление об изменении, а измененная конфигурация будет перезагружен.

Это также очень удобно для некоторых распространенных конфигураций, например, шесть микросервисов используют кластер Redis, нам нужно настроить только одну копию, и если конфигурация кластера изменится, нам нужно изменить ее только один раз, шесть микросервисных приложений это почувствуют.

Второй熔断器, так называемый предохранитель — это промежуточное программное обеспечение, предназначенное для защиты приложений.Например, когда сервер заказов Taobao Double Eleven не выдерживает, он выдаст вам подсказку.К сожалению, сервер слишком горячий, повторите попытку позже"Такого рода напоминание, это текущая ограничительная мера, используемая для защиты сервиса Taobao от перегрузки, эта мера называется понижением уровня сервиса.

Есть еще некоторые сценарии использования выключателя.Например,заказ прошел товарную службу,службу заказов и службу инвентаризации.На последнем шаге служба инвентаризации рухнула.В это время служба заказов сообщит ошибка, которая вызовет стадный эффект. Все Узел, который связывается с разрушенным узлом, будет иметь ошибки. В это время требуется прерыватель цепи. После обнаружения того, что служба не отвечает, будет дано приглашение предотвратить возникновение эффекта стада.

Выражения этих двух понятий очень похожи, но пусть вас не вводит в заблуждение внешний вид. Основное различие между ними состоит в том, что внутренние причины разные. Это можно понять, когда у вас будет возможность написать соответствующий код.

Это основное ПО промежуточного слоя в распределенной разработке, а также есть другие необязательные средства отслеживания ссылок ПО промежуточного слоя, о которых я упомяну в следующем разделе, поэтому я не буду говорить об этом здесь.

SpringCloud и Алибаба

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

В этом разделе я хочу рассказать вам о соответствующих реализациях и сообщить всем, что они знакомы, потому что мы обычно используем корзину семейства Spring для разработки приложений Java. Использовать для распределенной разработки микросервисов.

После нескольких лет разработки его можно условно разделить на два набора комплектов разработки: комплект для разработки SpringCloud и комплект для разработки SpringCloudAlibaba.Это только мое личное деление, и я также упомяну некоторые другие семейства.

Давайте сначала взглянем на набор SpringCloud.Этот набор связанных компонентов в основном одинаков в начале.NetflixРазработанное компанией приложение для потокового мультимедиа, которое можно понимать как иностранный iQiyi.

В правой части этой карты находятся три промежуточных ПО центра регистрации,EurekaОн был разработан компанией Нетфликс.ZookeeperЭта функция относительно мощная, это не просто реестр, это может быть и реестр, и распределенные блокировки.ConsulЭто промежуточное программное обеспечение для центра регистрации, разработанное на языке Go (которое также можно использовать в качестве центра конфигурации).Среди них Eureka чаще используется в последние два года, а Zookeeper, возможно, раньше чаще использовался в Китае.

первый слеваSpringCloudGatewayЭто промежуточное ПО шлюза, разработанное Spring.До Netflix был Zuul, который также использовался в качестве промежуточного ПО шлюза.

Feign/OpenFeign/RabbonСоединяю эти три вместе и говорю, что Feign и OpenFeign на самом деле одно и то же. OpenFeign был разработан на основе Feign после того, как он перестал обновляться. Все они используются для связи между сервисами. В качестве протокола связи они используют HTTP, что на самом деле RestTemplate в Spring, а Rabbon — это промежуточное программное обеспечение, которое реализует стратегию переадресации услуг. Ранее мы упоминали, что шлюз может пересылать услуги в соответствии с определенными стратегиями, такими как стратегии опроса, случайности и взвешивания. На самом деле это Rabbon в действии. Когда мы используем Эврика, теперь у нас есть свой Rabbon и нам не нужно вводить дополнительные JAR-пакеты, ведь это все вещи семейства Netflix.

SpringCloudConfigЭто промежуточное программное обеспечение центра конфигурации, разработанное Spring.Его функции слабее, чем у других восходящих звезд, таких как Apollo от Ctrip и Nacos от Ali, поэтому его не рекомендуется.

HystrixЭто также промежуточное программное обеспечение, разработанное Netflix.Его функция - предохранитель.Это очень классическое промежуточное программное обеспечение для предохранителей.Среди этих промежуточных программ оно является самым сложным.

SleuthЭто промежуточное программное обеспечение для отслеживания ссылок, которое может записывать, по каким ссылкам будет проходить ваш запрос,ZipkinЕго можно отобразить в визуальной форме.

Вышеупомянутый набор вещей используется в моей текущей компании, за исключением Apollo, используемого в центре конфигурации, это относительно популярный пакет.

В отличие от вышеупомянутых наборов, которые в основном разработаны Netflix, набор, который я хочу представить ниже, — это набор SpringCloudAlibaba, который обычно называется так, потому что он был разработан Alibaba.

Вышеприведенная картинка намного проще, чем предыдущая.

NacosЭто многофункциональное промежуточное программное обеспечение, которое можно использовать как центр регистрации и центр настройки одновременно.Я сам использовал этот компонент и чувствую, что он довольно прост в использовании, и он поставляется с набором более красивых визуальный интерфейс.

DuuboЭто может быть знакомо всем.Он был первоначально разработан Али, а затем передан в дар Apache.Теперь это один из лучших проектов Apache.Он является компонентом служебной связи и использует связь RPC.

SentinelПредохранитель, разработанный Али, чье имя переводится как Sentinel, можно назвать очень подходящим, и он имеет функцию отслеживания ссылок и вспомогательный визуальный интерфейс.Можно сказать, что один человек сделал работу Hystrix+Sleuth+Zipkin. .

Я рекомендую промежуточное программное обеспечение, такое как Ali, потому что первый набор Netflix в основном объявил, что он перестанет обновляться.Например, после того, как Feign не обновляется, Spring взял на себя вторичную разработку и запустил OpenFeign.

Здесь я упомяну Apollo, промежуточное программное обеспечение центра конфигурации, разработанное Ctrip.Сейчас его используют многие компании, и наша компания использует его лично.Пользоваться им удобно, он очень удобен и прост в использовании.

На самом деле, не смотрите здесь на список стольких промежуточных программ, каждая из них является средней школой, а остальное можно узнать, просмотрев документацию. В основном это одно и то же. Мир открытого исходного кода легко начать, что также является снижением стоимости обучения для всех.

Чем больше вы изучаете и используете фреймворк, тем больше вы обнаружите, что большинство из них в основном одинаковы.

В следующем месяце я тоже должен написать статьи об этих мидлварах по одной, настолько, насколько их хватит для входа.

яи уши, увидимся в следующем выпуске, спасибо за поддержку👍👍👍

🏆 Технический спецвыпуск 5 | Рассказываем о распределенных вещах...