Оба кажутся параллельными MPI-сетями, связывающими процессы. Я идентифицирую актеров с услугами. Являются ли актеры более динамичными (вы можете создавать их и убивать как дышащих, тогда как сервисная сеть более статична) или как?
Ответы:
Актерская модель - это математическая модель для параллельных вычислений, а микросервисы - реализация сервис-ориентированной архитектуры. Сходства довольно случайны.
Конечно, возможно построить микросервисы на основе некоторой актерской модели и смоделировать микросервисную архитектуру с актерской моделью, но это не значит, что они эквивалентны. Замените «микросервисная система» на «система электронной почты», и это все равно будет верно. Замените «модель актера» на «Связь последовательных процессов» (CSP), и это также будет «истинно», потому что системы CSP и модели акторов могут моделироваться друг другом.
Учитывая модель актера, вы можете реализовать ее с помощью микросервисов, SOA или даже электронной почты, но это не значит, что они находятся на одном уровне абстракции для реального сравнения.
Кроме того, модель актора подчеркивает буферы (может рассматриваться как очереди сообщений в мире микросервисов), поэтому некоторые субъекты / микросервисы могут быть не готовы, хотя асинхронная связь по своей природе все еще возможна.
Другими словами, сравнение с актерской моделью может принести некоторые творческие идеи на очень высоком уровне рассмотрения, но в основном это яблоки против апельсинов.
Если цель состоит в том, чтобы сравнить математическую модель SOA / микросервисов с моделью Actor, то это также не тривиально, потому что: 1) не существует согласованной математической модели для SOA, 2) модель обычно включает в себя цель. И моделирование SOA / микросервисов очень вероятно будет отличаться от цели модели актера. Один пример попытки смоделировать SOA здесь .
Конечно, можно создать систему модели актора с микросервисами и назвать каждую службу актером (см. Строгое определение модели актера). Но это не значит, что между этими двумя понятиями есть значимая связь в общем смысле.
Микросервисы - это способ организации программного обеспечения путем разделения каждой проблемной области на собственный развертываемый артефакт (исполняемый файл, сценарий, JAR, WAR и т. Д.). Это дает вам гибкость, например, позволяя вам масштабировать, развертывая больше экземпляров там, где они необходимы. Скажем, пользователи тратят больше времени на просмотр вашего каталога, чем на добавление товаров в корзину; один развертываемый артефакт обрабатывает функции каталога, другой - функции корзины покупок - вы можете запускать больше копий служб каталога для обработки нагрузки.
Это также изолирует их от внутренних изменений. Скажем, вы переходите из реляционной базы данных в базу данных документов для хранения данных о продукте - скорее всего, ваши услуги корзины покупок не нужно будет менять.
Модель актера является более низким уровнем, чем развертываемый артефакт, и больше о том, с какими типами объектов вы реализовали сервис. Продолжая приведенный выше пример, вы можете иметь корзины покупок в вашей системе, представленные актерами, поэтому корзина каждого пользователя является отдельным актором, и в сообщениях указывается, что нужно добавлять элементы, удалять элементы, отвечать текущим содержимым, добавлять доставку, оформлять заказ и т. д. В этом случае у вас все еще есть микросервис, и он реализован с актерской моделью.
Я бы сказал, что основным отличием является гранулярность.
Для модели актера она относительно мелкозернистая, в которой актер имеет тенденцию представлять эквивалент одного объекта в ООП.
Для микроуслуг это относительно грубо, так как один микроуслуг может состоять из большого количества действующих лиц или объектов.
Обратите внимание, что вам не нужно было бы слишком сильно расширять свое воображение, чтобы сказать, что современный веб - это то же самое с еще большей гранулярностью («макро-сервисы»); и что (например) HTTP-сервер является макросервисом, сервер базы данных является макросервисом, веб-браузер является макросервисом и т. д.
Это все примерно одинаково - отдельные части, которые общаются. Изменяется только размер кусков (и, следовательно, количество кусков).
Microservices масштабируются горизонтально, создавая несколько реплик, каждая из которых способна обслуживать запросы из-за состояния службы без сохранения состояния. Они устойчивы к неудаче благодаря своей природе без гражданства.
Актеры масштабируются, перемещая их в разделы с меньшей нагрузкой или большим количеством доступных ресурсов. Они с состоянием . Они устойчивы к сбоям, потому что - в зависимости от структуры актера - другой актер может динамически вращаться или всегда можно поддерживать горячую резервную копию актера, чтобы справиться с ошибкой основного актора.
Опять же, микросервисы также могут иметь состояние, но это противоречит принципам проектирования микросервисов.