Scalability

«Вы переусложняете это!» — боевой клич каждого основателя стартапа, который наблюдал, как сроки запуска его минимально жизнеспособного продукта (MVP) сдвинулись с «двух недель» на «когда-нибудь в следующем финансовом году». И, честно говоря, большую часть времени они абсолютно правы. Но здесь я собираюсь отстаивать идею, которая, вероятно, вызовет у меня немало резких комментариев: иногда именно переусложнение и нужно. Прежде чем закрыть эту вкладку и написать в твиттере, что я потерял рассудок, выслушайте меня....

Позвольте мне рассказать вам о том времени, когда я влюбился в язык программирования с фиолетовым логотипом, который делает параллельное программирование похожим на тёплые объятия. Нет, я не говорю о своих отношениях с кофе (хотя он тоже функциональный и высокопараллельный). Я говорю об Elixir — языке, который взял всё лучшее из Erlang и изменил синтаксис так, что глаза больше не слезятся. Если вы когда-нибудь задумывались, как WhatsApp обрабатывает миллиарды сообщений с помощью всего нескольких серверов или как Discord справляется с миллионами одновременных пользователей, не вспотев, то сейчас вы узнаете об их не таком уж секретном оружии....

Вы когда-нибудь пытались пасти кошек, жонглируя при этом бензопилами? Примерно так ощущается управление WebSockets в высоконагруженных системах Go без правильных оптимизаций. Я, как человек, который случайно устраивал DDoS-атаки на свои собственные серверы чаще, чем мне хотелось бы признать, обобщил свои с трудом усвоенные уроки в этом руководстве. Мы превратим ваши обработчики WebSocket из перегруженных гремлинов в закалённых в боях воинов. Управление подключениями: Танго с горутинами Горутины в Go делают параллелизм обманчиво простым — пока вы не создадите тысячи горутин для WebSocket-подключений и не увидите, как утекает память....

Эпидемия одержимости масштабируемостью Представьте: вы на мероприятии по презентации стартапов, где каждый основатель хвастается своей «бесконечно масштабируемой архитектурой», хотя их пользовательская база могла бы уместиться в Tesla Model 3. Мы развили своего рода стокгольмский синдром в отрасли, где мы боготворим масштабируемость, сковывая инновации ненужной сложностью. Давайте разберёмся, почему иногда игнорировать проблемы масштабируемости не просто приемлемо — это стратегически верно. Когда масштабируемость не должна быть вашим первым приоритетом 1. Этап MVP (когда вы даже не уверены, что людям нужен ваш летающий автомобиль) На ранних этапах разработки сосредоточьтесь на проверке основной функциональности, а не на создании ракетных ускорителей....

Ах, горизонтальное масштабирование — это кулинарное искусство архитектуры баз данных! Подобно нарезке гигантской салями на управляемые кусочки (но с меньшим количеством чеснока), сегментирование помогает нам обслуживать данные быстрее, чем нью-йоркский пиццерийщик. Давайте наденем наши поварские колпаки и приготовим устойчивую реализацию сегментирования в Go! Сегментированный шведский стол: выберите вкус раздела Прежде чем мы запустим кодовую печь, давайте рассмотрим основные варианты подачи: Горизонтальное или вертикальное сегментирование graph LR A[Монолитная база данных] --> B{Тип сегментирования} B --> C[Вертикальное: таблицы в виде слоёв] B --> D[Горизонтальное: строки в виде срезов] C --> E[Специализированные серверы баз данных] D --> F[Распределённые узлы данных] В этом рецепте мы сосредоточимся на горизонтальной нарезке — потому что кому не нравятся равномерно распределённые кусочки данных?...