Часто разработчик Rails не думает о масштабируемости.
Люди выбирают Rails, потому что это фреймворк веб-приложений «для остальных людей». Другими словами, то, что предоставляет DHH (создатель Rails), «достаточно хорошо» для большинства приложений малого и среднего размера.
В конце концов, то, что мешает вашему приложению расти, - это не большое количество операций чтения / записи в БД, от которых пострадает ваше приложение, а, скорее, сбой в маркетинге или плохой UX. Часто приложения не работают задолго до того, как они встанут на путь масштабирования.
Оправдывает ли это незнание стратегии масштабируемости? Я так не думаю. Независимо от того, насколько вы специализируетесь на «прототипировании приложений» или «быстрой итерации», вы, как инженер, нужны с надеждой на то, что продукт, который вы создаете, изменит мир.
Более того, если вы строите свою карьеру, чтобы стать великим инженером, рано или поздно вам придется преодолеть этот образ мышления.
Здесь вам пригодится книга Сервис-ориентированный дизайн с помощью Rails. Эта книга знакомит с тем, как относиться к вашему Rails-приложению больше, чем к одному размещенному веб-приложению с одной RDB, управляющей состояниями приложения.
Его основная цель - познакомить вас с концепцией сервисов, где у каждой службы есть свой ограниченный контекст, и рассматривать их как красиво инкапсулированные акторы.
Хотя термин «сервис-ориентированный дизайн» может показаться вам не знакомым для вас как разработчика, вы можете думать о сервисах как о естественном расширении объектно-ориентированного дизайна, инкапсуляции и передачи сообщений в более крупном масштабе (часто по сети).
В книге представлены несколько примеров реальных приложений, которые использовались здесь и там. Я не могу больше согласиться с важностью примеров как способа привлечения читателей, но мне казалось, что они используются только в качестве общего объяснения различных концепций.
Книга была бы лучше, если бы она содержала один конкретный пример по всей книге, постепенно разбивая его на «масштабируемый» сервис-ориентированный дизайн.
Тем не менее, я рекомендую эту книгу, чтобы проверить свои знания в данной области, но я также советую вам пролистать книгу, чтобы увидеть, насколько глубоко вы хотите читать. Для меня определенно стоило прочитать несколько глав (особенно ближе к концу).
Самым интересным для меня был шаблон, который автор называет шаблоном «Синхронное чтение, асинхронная запись» (SR / AW).
Это в некотором роде решение теоремы CAP. В распределенной системе согласованность, доступность и допуск на разделы не могут быть выполнены одновременно всем 3. (это означает, что стремление к одному при сохранении двух других качеств * доказано * как провал).
Принимая это во внимание, шаблон SR / AW предполагает, что если вы можете жить с «конечной согласованностью» вместо согласованности в реальном времени, тогда C (это слабый C) и AP могут встречаться одновременно.
Также автор подчеркивает, что чтение и запись требуют разных стратегий оптимизации (кэширование для чтения, NoSQL для записи, а именно), поэтому выбор другой стратегии для чтения и записи имеет смысл также с точки зрения производительности.
Я постараюсь более подробно объяснить теорему CAP и конечную согласованность (асинхронная запись через брокер сообщений, такой как RabbitMQ), если будет продолжение этого сообщения (на основе реакции).
Но пока я надеюсь, что этот пост заинтересует разработчиков Ruby, которым интересны распределенные системы (и сервис-ориентированная архитектура).
Увидимся в следующий раз!
