На самом деле ничего плохого от дистиллята не произойдет. Большая часть всех солей, микроэлементов, и витаминов попадает в организм с пищей а не водой.
Идея в том, чтобы сервису для отдачи данных пользователю не нужно ползти в другие сервисы и что-то там дергать. Сервис просто сидит и ждет апдейтов которые приходят через шину от других. Это сильно уменьшит зависимости между сервисами, что позволит сосредоточиться на обеспечении доступности user-facing сервисов, и меньше думать про сервисы которые работают в фоне.
если любой из нужных микросервисов недоступен, то как правило пользоватетель получает не частично, а полностью неработающее приложение. Это из области мифив, что приложением можно будет пользоваться, но с ограниченниями. Я таких приложений не видел.
У вас не микросервисы, а просто распределенный монолит. Общение между микросервисами должно происходить полностью асинхронно, через какую-нибудь кафку например. Это решит проблему продолжения работы всего приложения при одном умершем сервисе. Он просто обработает данные из кафки позже, когда восстановится, а остальные этого даже и не заметят.
Можно еще быстрее, если написать в анкете что виза нужна «как только так сразу». У меня ушло 4 дня с момента подачи документов до получения паспорта с визой.
А если попробовать реализовать какую-нибудь последовательную CRDT (например LSEQ) поверх дропбокса, то можно добиться вполне приличного слияния при редактировании записей.
Учился в Екатеринбурге на инженера-теплоэнергетика, пока вдруг после экскурсии на электростанцию не понял что это не мое и что надо что-то менять. Решил прокачивать навыки computer science на coursera, с 4 курса начал работать, начинал с PHP после чего перешел на Scala. В итоге к 23 годам переехал в Берлин и сейчас работаю в крупнейшей европейской e-commerce компании.
Сам актор — «формула», которая делает одно вычисление. Без состояния.
Это не самый подходящий способ использования акторов. Акторы больше предназначены для безопасного хранения состояния в многопоточной среде, а если состояние отсутствует, то фьюча часто бывает проще и удобнее.
Корень проблемы гарантированной достаки в том, что непонятно какие гарантии она должна давать, так как у нас есть несколько вариантов.
Сообщение отправлено в сеть?
Сообщение принято другим хостом?
Сообщение получено мейлбоксом?
Сообщение начато обрабатываться актором?
Сообщение успешно обработано актором?
Единственный способ узнать, было ли сообщение обработано или нет — это ввести подтверждение доставки на уровне бизнес-логики. По этой причине разработчики Akka намеренно не стали включать такую дырявую абстракцию, как гарантированная доставка.
У вас не микросервисы, а просто распределенный монолит. Общение между микросервисами должно происходить полностью асинхронно, через какую-нибудь кафку например. Это решит проблему продолжения работы всего приложения при одном умершем сервисе. Он просто обработает данные из кафки позже, когда восстановится, а остальные этого даже и не заметят.
А если попробовать реализовать какую-нибудь последовательную CRDT (например LSEQ) поверх дропбокса, то можно добиться вполне приличного слияния при редактировании записей.
Это не самый подходящий способ использования акторов. Акторы больше предназначены для безопасного хранения состояния в многопоточной среде, а если состояние отсутствует, то фьюча часто бывает проще и удобнее.
Единственный способ узнать, было ли сообщение обработано или нет — это ввести подтверждение доставки на уровне бизнес-логики. По этой причине разработчики Akka намеренно не стали включать такую дырявую абстракцию, как гарантированная доставка.