Comments 3
По описанию похоже на Microsoft Orleans, ни его ни описанный продукт не пробовал, и хочу узнать, есть ли у кого опыт использования их в реальных условиях? И что лучше для решения задачи в которой будет использована микросервисная архитектура, в которой сервисы должны общаться, и где должно быть централизованное место для визуального отслеживания работы всей системы. Имеет ли какой нибудь из этих продуктов кроме RPC еще и поддержку durable шины сообщений?
Отвечаю по порядку.
Опыт использования в реальных условиях MS Orleans есть — продукт новый, динамично развивается, проблемы иногда вылезают, но в целом сейчас релиз стабильный, и использовать его можно. Реального опыта по ASF пока нет, и мне самому интересно послушать тех, у кого уже появился.
Теперь об остальном. Сразу замечу, что Orleans — это framework (иначе говоря, библиотека), а ASF — серверное решение, поэтому для Orleans разворачивание, диагностику, мониторинг и пр. надо писать самому, а ASF сам строит кластер и сам себя диагностирует (годится ли такое “из коробки” для Вашего проекта надо смотреть по месту). Взаимодействие между акторами/сервисами есть в обоих решениях.
Далее — Orleans в основе предлагает actor model, ASF в основе предлагает микросервисы (как я упомянул в статье, сами ASF Actors построены на микросервисах). Несмотря на некоторое сходство, микросервис и актор — разные сущности. Система акторов — это система именованных объектов, доступ к которым осуществляется по имени через интерфейс. Система микросервисов — система неких объектов, запущенных на исполнение. Внешнего доступа к таким объектам может и не быть (если это сервис фоновой задачи), а если и есть, то тяготеет скорее к TCP/HTTP, чем к RPC. Актор является точкой синхронизации — в один момент времени исполняется не более одного вызова. И жизненный цикл актора/сервиса разный — при запросе актора можно активировать, а при отсутствии активности деактивировать (см. virtual actors и grains), экзмепляр сервиса же, будучи запущен, работает до полного останова. Сервис можно эмулировать бессмертным актором — такой фокус возможен, более того, в Orleans мы так и делали для фоновых задач, но концептуальную красоту это нарушает :)
Ну и наконец durable шина сообщений — в Orleans это Streams, а вот в ASF готовой шины нет (коллеги подсказывают, что были в ASF те же Streams, но вышли такими кривыми, что пока их выпилили от греха подальше и когда впилят обратно — неизвестно).
Опыт использования в реальных условиях MS Orleans есть — продукт новый, динамично развивается, проблемы иногда вылезают, но в целом сейчас релиз стабильный, и использовать его можно. Реального опыта по ASF пока нет, и мне самому интересно послушать тех, у кого уже появился.
Теперь об остальном. Сразу замечу, что Orleans — это framework (иначе говоря, библиотека), а ASF — серверное решение, поэтому для Orleans разворачивание, диагностику, мониторинг и пр. надо писать самому, а ASF сам строит кластер и сам себя диагностирует (годится ли такое “из коробки” для Вашего проекта надо смотреть по месту). Взаимодействие между акторами/сервисами есть в обоих решениях.
Далее — Orleans в основе предлагает actor model, ASF в основе предлагает микросервисы (как я упомянул в статье, сами ASF Actors построены на микросервисах). Несмотря на некоторое сходство, микросервис и актор — разные сущности. Система акторов — это система именованных объектов, доступ к которым осуществляется по имени через интерфейс. Система микросервисов — система неких объектов, запущенных на исполнение. Внешнего доступа к таким объектам может и не быть (если это сервис фоновой задачи), а если и есть, то тяготеет скорее к TCP/HTTP, чем к RPC. Актор является точкой синхронизации — в один момент времени исполняется не более одного вызова. И жизненный цикл актора/сервиса разный — при запросе актора можно активировать, а при отсутствии активности деактивировать (см. virtual actors и grains), экзмепляр сервиса же, будучи запущен, работает до полного останова. Сервис можно эмулировать бессмертным актором — такой фокус возможен, более того, в Orleans мы так и делали для фоновых задач, но концептуальную красоту это нарушает :)
Ну и наконец durable шина сообщений — в Orleans это Streams, а вот в ASF готовой шины нет (коллеги подсказывают, что были в ASF те же Streams, но вышли такими кривыми, что пока их выпилили от греха подальше и когда впилят обратно — неизвестно).
Почитал ваши публикации, очень клевые, пишите еще!!
Sign up to leave a comment.
Azure Service Fabric: первые шаги