Comments 23
Выглядит как своя реализация идей, доступных в Akka. Рассматривали её?
Если я правильно понял статью (после чтения по диагонали), то у вас используется:
- Сервисы связаны в кластер
- Шардирование
- Local queries / reads
- State replication
- Recovery через репликацию данных с других инстансов
Что делается "из коробки" (правда подозреваю менее эффективно, хотя интересно было бы сравнить) в Akka с помощью Akka Cluster + Akka Persistence и ещё пары штук возможно.
P.S. Олег, ты чего на "вы", не первый день знакомы ;)
Все названное тобой — достаточно универсальные идеи, существующие в любой распределенной системе. Возможно, можно это сделать и на Akka — но мне кажется, что это будет избыточным. Может и будет иметь какой то смысл, если Akka уже используется — в противном случае, думаю скорее наоборот — все усложнит и замедлит.
P.S. аватарка мелкая — тыкать надо чтобы разглядеть ;-).
Выглядит как своя реализация идей, доступных в Akka.
Мне скорее напомнило Apache Ignite
Для управления используется one-cloud
У меня есть стойкое ощущение что эта статья уже была на хабре. Я точно помню что читал про кассандру внутри сервиса и всё вот это вот.
Как например описанно в их книге 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).

Натянули сову на глобус. Данных нет. Напоминает рассуждения — а давайте LinkedList вместо ArrayList.
Поддержка этого решения на порядки сложнее.
Cassandra постоянно меняется и меняет свои API, мы ее перестаем использовать именно из-за этого. Цена ошибки теперь не только потеря бизнес-логики, но и потеря данных.
Рад за бизнес, что достаточно здоров, чтобы оплачивать сомнительные эксперименты.
Поддержка этого решения на порядки проще, так как инстанс БД, кеши и все остальное работает прямо в приложении и вы можете отладчиком или профилировщиком совершенно спокойно дойти от прикладной логики до движка БД и посмотреть что там происходит. Чем мы и пользуемся для того, чтобы понять что происходит, почему и как это фиксить.
В случае с микросервисом без состояния кластера кешей и БД работают отдельно и вызов профилировщика, на БД например, покажет меньше — все стек трейсы будут одинаковы: сеть -> диспетчер запросов -> выполнение. Часть, связанная с прикладной логикой не видна; ответ на вопрос какой запрос вызывает, допустим, перегрузку — требует отдельного расследования, с помощью своих средств БД, если они там есть, или гаданий на кофейной гуще, если нет или они недостаточны для определения проблемы.
Данные за последние 10 лет мы безвозвратно не теряли ни в одном из более сотни кластеров, в том числе и в результате массовых аварий и пожаров. Раздел «Эксплуатация» во многом посвящен тому как не потерять данные.
Данных в статье я привел довольно много. Каких данных вам не хватает?
Например, первая же причина — "затрата ресурсов CPU на маршалинг и демаршалинг" — сколько у вас конкретно терялось на этом? Информации нет. Из моего опыта, это проценты (1-2) от общей картины, никак не 20-30.
Избыточность — ну допустим. Однако поменять структуры данных проще, чем пилить свой DataStax Enterprise.
Издержки на сеть — надо мерять, опять же. Из опыта, это тоже проценты, особенно если решить избыточность.
То есть эти 3 проблемы решаемы, и меньшими усилиями, чем велосипед из поста. Но, конечно, не так интересно.
Работаю я не DBA, нет, ближе к development manager / architect.
то, что у вас эти потери составляют 1-2 процента, говорит либо о том, что вы не мерили, либо о том что у вас нет опыта работы с достаточно нагруженными системами, в которых это становится заметным. если же у вас есть исследования, подкрепляющие ваши утверждения — не поленитесь дать ссылку — будет интересно почитать.
Переход на личности не нужен, когда можно говорить о данных и предпосылках. Предположения о моем опыте роли не играют, достаточно данные показать — свои, не чужие.
Спрашивать мои данные, когда не предоставили свои — ну странно как-то. Как вам помогут мои данные, когда вы сами не померяли и не запустили профайлер? А если запустили, тогда в чем проблема данные показать?
в конце статьи последние 2 ссылки ссылки на доклады по другим системам, построенным по этому паттерну.
Еще вот такой есть про классы Класс! ная Cassandra — тоже построен как stateful service
Замечательный доклад. Поделился друг, который присутствовал лично).
Вопросы / замечания:
- Когда вы дошли до реализации, был упомянут сервис централизованного управления нодами кассандры. Таким образом, при предыдущих расчетах надёжности, нужно помножить ещё на надёжность этого сервиса.
- Вы хотите избавиться от затрат CPU и сетевых задержек, но каков будет сравнительный рост этих же затрат на синхронизации между нодами?
- Появляются ли особенности получения консистентного бэкапа данных такой системы?
Эффективные надежные микросервисы