Вторая статья из серии о full-stack JS разработке.
JavaScript постоянно меняется, очень сложно угнаться за последними технологиями, ведь то, что было лучшей практикой полгода назад, сейчас уже устарело. Подобные утверждения во многом правда, но следует отметить, что это больше относится к клиентскому JavaScript. Для сервера все гораздо стабильнее и основательней.
Как вы считаете, какова стоимость очередей с приоритетами? То есть если кто-то лезет вне очереди, то как посчитать стоимость для всей системы в этой ситуации, чему она пропорциональна? Времени обслуживания клиента — например, 5 минут стоит его обслужить? Она пропорциональна количеству ожидающих, потому что время ожидания для каждого из них увеличится.
Для начала о себе — я занимаюсь разработкой СУБД Tarantool в Mail.ru. Этот доклад будет об обработке очередей. У нас много очередей внутри системы, фактически вся база данных построена как система массового обслуживания.
В основном речь будет идти о проблемах балансировки нагрузки, но перед этим я хотел бы поговорить о том, зачем нужны очереди и как они появились именно в компьютерных системах, чего они позволяют добиться.
Именно так и никак иначе: null в C# — однозначно ошибочное решение, бездумно скопированное из более ранних языков.
Этот ящик Пандоры был открыт еще при создании языка ALGOL W великим Хоаром, который позднее назвал собственную идею ошибкой на миллиард долларов.
В мире JavaScript очень легко набрать свой стек технологий, используя набор небольших пакетов, каждый из которых решают свою конкретную проблему. И это хорошо, c одной стороны, а с другой стороны, у вас особо нет выбора — фреймворки которые выполняют широкий спектр задач в JavaScript не популярны.
В этом цикле статей я хочу поделиться своим практическим опытом построения JS стека.
Я попытаюсь залезть в «потроха» и «кишки» бэкенда веб-сервиса и расскажу, как это внутреннее устройство влияет на эффективность сервиса, а также на продукт, его характеристики, и как бы мы могли этим воспользоваться, чтобы наше приложение выдерживало большую нагрузку или работало бы быстрее.
Какую часть я называю веб-сервисом, бэкендом, application-сервером? В классической архитектуре это то, что стоит за http rеverse proxy или load-балансировщиком, а с другой стороны у него находятся база данных, memcached и др. Вот только об этом бэкенде и будет идти речь.
Перед этим опусом стоит крайне сложная задача — описать принципы перехода от монолита к микросервисам, при этом не рассказывать читателю то, что он и так знает. Микросервисная архитектура настолько популярна, что автор свято уверен, что каждый второй читатель работал с такой архитектурой или же ненавидит её всеми фибрами своей души. Также бытует мнение, что большая часть разработчиков, читающих эти строки присоединились к проекту, построенному на микросервисах, уже после того, как он стал микросервисным. А та малая часть ребят, которые самостоятельно проделывали путь от монолита к микросервисам уже достаточно опытны, чтобы работать на должностях старших разработчиков, архитекторов или менеджерами проекта.
Банки.ру — проект с 10-летней историей. В разные времена banki.ru испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас средняя посещаемость примерно 2 миллиона просмотра страниц, т.е. проект уже не маленький, но ещё и не совсем большой.
Эта статья — расшифровка доклада Романа Ивлиева (CIO Banki.ru) на обучающей конференции HighLoad++ Junior, которая прошла пару месяцев назад в Москве в рамках фестиваля “Российские интернет-технологии”.
В этой статье мы хотим поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
В заключение Роман Ивлиев расскажет про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
Примечание переводчика: в перерывах между холиварами про JS предлагаю обсудить несерьёзную, пятничную тему:
Кто не любит эмодзи? Активно используя их в мессенджерах и почтовых приложениях, я решил проэкспериментировать с тем, как можно применить их с умом в повседневной разработке приложений. Хотя поначалу это была просто шутка, эмодзи действительно оказались полезными в ряде случаев. Как так?
Мы, программисты, читаем много текста — будь то код, логи, комментарии к коммитам, документация или что-либо еще. Эмодзи бросаются в глаза, и их гораздо легче найти на простыне текста, чем обычную строку. Быстрее поиск — выше продуктивность. Хотя даже если на вашей продуктивности это никак не скажется, пользоваться эмодзи — весело! Вот некоторые вещи, которые я опробовал на практике:
Наш отважный герой, случайно забредший в запретную область ядовитых венерианских джунглей, окружён роем из десяти тысяч голодных полуразумных комаров. Вопрос съедобности человека для инопланетных организмов, с научной точки зрения, вообще-то, достаточно спорен — но венерианские комары, как известно, искренне разделяют позицию Маркса, что критерием истинности суждения является эксперимент. Казалось бы, положение безнадёжно — но герой, не растерявшись, извлекает из широких штанин инвентаря походный термоядерный фумигатор, красивым движением включает его, и…
И на этом моменте разработка игры всерьёз забуксовала, стремительно обрастая костылями и подпорками, поскольку разработчик игры не был знаком с одним маленьким, но крайне важным механизмом движка.
Механизм, которого не знал разработчик, спящий на клавиатуре после продолжительного спринта по программированию совершенно не нужного по сути своей менеджера управления комарами — это встроенная система событий.
На Хабре уже была статья, посвящённая Dependency Injection в Ruby, но упор в ней был больше на использование паттерна IoC-container с помощью гемов dry-container и dry-auto_inject. А ведь для использования преимуществ внедрения зависимостей совершенно необязательно городить контейнеры или подключать библиотеки. Сегодня расскажу о том, как по-быстрому реализовать DI своими руками.
Каждый более-менее успешный продукт приходит к состоянию, когда добавлять новые возможности в существующую кодовую базу становится тяжело настолько, что стоимость новой функциональности превосходит все возможные выгоды от ее использования. Конечно же, хороший и внимательный архитектор позаботится о приложении заранее и направит разработку в правильное русло. Самый популярный на данный момент подход подразумевает распиливание одного большого куска кода на много мелких проектиков, каждый из которых отвечает за свои определенные возможности. При проектировании такой системы нависает огромная ответственность. Нужно продумать и разработать такой тип взаимодействия между этими отдельно лежащими кусочками, чтобы будущие внесения изменений не требовали переписать все к чертям.
Понятное дело, в сети существует огромное количество экспертных статей, которые показывают нам важность такой архитектуры и рассказывают о том какую архитектуру можно назвать хорошей, а какую не очень. Существует огромное количество методов взаимодействия между отдельными програмками большого приложения со своими протоколами, версионированием протокола и документации, написания документации на программные интерфейсы, способа развертывания и синхронизации всего этого добра вместе. Безусловно, каждая такая статья или метод логичен и последователен и особенно, если описанный метод подтвержден практикой. Но беда не в том, что проектировщики не знают какую систему они хотят в итоге получить. Беда в том, как перейти к такой вот правильной архитектуре и когда же можно прекратить писать монолитное приложение и начать уже писать взрослые микросервисы, чтобы перед пацанами не было стыдно.
В среду, 20 июля, состоялась седьмая встреча Rambler.iOS, которую мы уже анонсировали на Хабре. По просьбам участников предыдущих мероприятий в этот раз было уделено особое внимание общению между разработчиками.
Было заявлено 3 доклада, два из которых были связаны между собой общей темой – мобильные платежи.
Архитектуру улучшая
Оптимизируя коллаж
В таблице получили скорость
И краш
_queryFactory.GetQuery<Product>()
.Where(Product.ActiveRule)
.OrderBy(x => x.Id)
.Paged(0, 10) // получаем 10 продуктов для первой страницы
// Мы решили подключить полнотекстовый поиск и добавили ElasticSearch, не вопрос:
_queryFactory.GetQuery<Product, FullTextSpecification>()
.Where(new FullTextSpecification(«зонтик»))
.All()
// Или EF тормозит и мы решили переделать на хранимую процедуру и Dapper
_queryFactory.GetQuery<Product, DictionarySpecification, DapperQuery>()
.Where(new DictionarySpecification (someDirctionary))
.All()
public interface IListOperation<TDto>
{
ListResult<TDto> List(ListParams listParam);
}
