Comments 22

Выглядит как своя реализация идей, доступных в Akka. Рассматривали её?

Если я правильно понял статью (после чтения по диагонали), то у вас используется:


  • Сервисы связаны в кластер
  • Шардирование
  • Local queries / reads
  • State replication
  • Recovery через репликацию данных с других инстансов

Что делается "из коробки" (правда подозреваю менее эффективно, хотя интересно было бы сравнить) в Akka с помощью Akka Cluster + Akka Persistence и ещё пары штук возможно.


P.S. Олег, ты чего на "вы", не первый день знакомы ;)

Не, немного не так. Основные идеи тут — совмещение БД и кеша с прикладной логикой сервиса. При этом кеш — специализированный, то есть затачивается под приложение.

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

P.S. аватарка мелкая — тыкать надо чтобы разглядеть ;-).
Выглядит как своя реализация идей, доступных в Akka.

Мне скорее напомнило Apache Ignite
На данный момент 288 инстансов, по 96 в ДЦ. Чем мельче инстанс тем быстрее он двигается по инфраструктура/восстанавливается в случае потерь данных и т.п.
Для управления используется one-cloud

У меня есть стойкое ощущение что эта статья уже была на хабре. Я точно помню что читал про кассандру внутри сервиса и всё вот это вот.

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

А мне это больше напомнило event sourcing с kafka-streams под капотом.
Как например описанно в их книге Designing Event Driven Systems.
Там так-же исповедуется подход денормализации и локального хранения данных.

Extending the system described previously to be fully event-driven; here events are used for notification (the orders service notifies the shipping service) as well as for data replication (data is replicated from the customer service to the shipping service, where it can be queried locally).

image

Натянули сову на глобус. Данных нет. Напоминает рассуждения — а давайте LinkedList вместо ArrayList.


Поддержка этого решения на порядки сложнее.
Cassandra постоянно меняется и меняет свои API, мы ее перестаем использовать именно из-за этого. Цена ошибки теперь не только потеря бизнес-логики, но и потеря данных.


Рад за бизнес, что достаточно здоров, чтобы оплачивать сомнительные эксперименты.

DBA работаете?

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

В случае с микросервисом без состояния кластера кешей и БД работают отдельно и вызов профилировщика, на БД например, покажет меньше — все стек трейсы будут одинаковы: сеть -> диспетчер запросов -> выполнение. Часть, связанная с прикладной логикой не видна; ответ на вопрос какой запрос вызывает, допустим, перегрузку — требует отдельного расследования, с помощью своих средств БД, если они там есть, или гаданий на кофейной гуще, если нет или они недостаточны для определения проблемы.

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

Данных в статье я привел довольно много. Каких данных вам не хватает?

Например, первая же причина — "затрата ресурсов CPU на маршалинг и демаршалинг" — сколько у вас конкретно терялось на этом? Информации нет. Из моего опыта, это проценты (1-2) от общей картины, никак не 20-30.


Избыточность — ну допустим. Однако поменять структуры данных проще, чем пилить свой DataStax Enterprise.


Издержки на сеть — надо мерять, опять же. Из опыта, это тоже проценты, особенно если решить избыточность.


То есть эти 3 проблемы решаемы, и меньшими усилиями, чем велосипед из поста. Но, конечно, не так интересно.


Работаю я не DBA, нет, ближе к development manager / architect.

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

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

Так я про то и говорю, ваших данных в статье нет, есть чьи-то другие. Поэтому и сравнил с LinkedList, т.к. похожую аргументацию видел уже.

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

Спрашивать мои данные, когда не предоставили свои — ну странно как-то. Как вам помогут мои данные, когда вы сами не померяли и не запустили профайлер? А если запустили, тогда в чем проблема данные показать?
Описанная модель заточена именно под чаты и не подойдет другим типам сервисов (например загрузчикам в ETL) — верно понимаю?
нет, не только под чаты. подойдет ли под ваш конкретный кейс — надо немного больше информации ;-)
в конце статьи последние 2 ссылки ссылки на доклады по другим системам, построенным по этому паттерну.
Еще вот такой есть про классы Класс! ная Cassandra — тоже построен как stateful service
OK, спасибо! Просто прочитав пару страниц А4 понял на сколько большая статья, хотелось понять, не зря ли читаю:)
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

26 April 2006

Location

Россия

Website

ok.ru

Employees

201–500 employees

Registered

9 August 2008