Guest
Видео на тему структуры большого распределенного проекта, созданной для обеспечения абсолютной отказоустойчивости и надежности, для предотвращения любых потерь данных, файлов, связей. 1. Проблемы больших проектов. Когда Вы заходите в приложение надежного банка, фейсбука, гос органов, Вы непременно видите хорошую работоспособность системы, всегда можете видеть свои данные, никогда не теряете ничего важного - от письма до транзакции. И в это же время целые соцсети типа Parler, блокчейны типа Solana, некоторые банковские системы - могут ломаться, переставать работать, терять данные и так далее. Почему так: а) оборудование, программы, обслуживающий персонал - могут совершать ошибки, плохо работать из-за любых причин. Недремлющие хакеры могут ломать довольно сложные системы безопасности. б) базы данных могут копить ошибки, блокировать соединение с собой из за разных причин, разбухать от лишних записей, входить в конфликт с программным обеспечением сервера. в) файлы медиа могут сгорать вместе с жесткими дисками, а резервное копирование, да еще и дублируемое обойдется в такие огромные средства, то далеко не все могут себе такое счастье позволить. в) создание мощной распределенной системы требует сотен крутых программистов в команде, а также большого времени. Поддержка таких систем также обойдется в целое состояние. Поэтому гигантские корпорации могут создать полностью надежную систему (во всех смыслах), а все остальные нет. 2. Как нам можно достичь того же эффекта. Абсолютная надежность распределенной платформы состоит из нескольких краеугольных сущностей: а) Надежность баз данных. Создается несколько копий приложений-сервисов, работающих параллельно. Каждое изменение баз данных влечет за собой такие же изменения всех таких же баз данных на сервисах-копиях. Причем динамически, чтобы не пропало ничего. б) Надежность статических серверов. Каждый новый файл копируется сразу же на копии статических серверов. в) Балансирование нагрузки на сервисы. Создаются двухуровневые синхронизационные сервисы: - всего проекта. Это работа с дублируемыми объектами сервисов. - специальные для каждого сервиса. К примеру, сервис чата (можно смотреть схему) будет иметь такие подсервисы: - API сервиса - дублируемый балансировщик нагрузки. Именно он решает, какой копии приложений придет запрос фронтенда. Если первая копия занята/сломалась, запрос перейдет второй копии. - сам сервис приложений (копия), работает так, как у прочих, только у нас он взаимозаменяемый. - статический сервис, состоящий из нескольких серверов-копий. Такая организация проекта позволит гарантировать полную надежность, безопасность и сохранность данных - на уровне систем-гигантов. ? Почему так не делают все прочие фирмы? ! Продумывание и реализация систем такого уровня слишком непросто и долго. У нас же есть практически готовое решение, которое мы допишем и тщательно протестируем, хотя уже видим, что работать будет как заявлено. ? Вы говорили, что раст сверхнадежен. ! И повторяем это, однако в сложной экосистеме проекта есть и прочие технологии - базы данных, операционные системы linux, носители SSD, и так далее. ? Неужели вы сможете заменить штат разработчиков уровня соцсети ! Мы уже делаем это. Все относительно.
