І те й інше, схоже на паралельну комунікаційну мережу процесів MPI. Я ототожнюю акторів із службами. Чи актори більш динамічні (їх можна створити і вбити, як дихати, тоді як сервісна мережа статичніша) чи що?
Відповіді:
Акторська модель - це математична модель для паралельних обчислень, а мікросервіс - реалізація сервісно-орієнтованої архітектури. Подібність цілком випадкова.
Безумовно, можна побудувати мікросервіси на основі якоїсь моделі актора, а також створити структуру мікросервісу за допомогою акторської моделі, але це не означає, що вони еквівалентні. Замініть "мікросервісну систему" на "електронну систему електронної пошти", і це все ще буде правдою. Замініть "модель актора" на "Спілкування послідовних процесів" (CSP), і це також буде "правдою", тому що CSP і системи акторських моделей можуть моделюватися одна іншою.
З огляду на модель актора, ви можете перейти та реалізувати її за допомогою мікросервісів, SOA або навіть електронної пошти, але це не означає, що вони знаходяться на одному рівні абстракції, щоб по-справжньому порівняти.
Крім того, акторська модель підкреслює буфери (їх можна розглядати як черги повідомлень у світі мікросервісів), тому деякі актори / мікросервіси можуть бути не готові, хоча по суті асинхронний зв'язок все ще можливий.
Іншими словами, порівняння з акторською моделлю може принести певні творчі уявлення на дуже високому рівні врахування, але в основному це яблука проти апельсинів.
Якщо метою є порівняння математичної моделі SOA / мікросервісів з моделлю Актора, то вона також не є тривіальною, оскільки: 1) немає узгодженої математичної моделі для SOA; 2) модель зазвичай включає мету. І моделювання SOA / мікросервісів, швидше за все, відрізняється від мети моделі актора. Один приклад спроби моделювання SOA тут .
Звичайно, можна створити систему моделей актора за допомогою мікропослуг та викликати кожну службу актором (див. Чітке визначення, що таке модель актора). Але це не означає, що між цими двома є взагалі значущі стосунки в загальному сенсі.
Мікросервіси - це спосіб організації програмного забезпечення шляхом розподілу кожної проблемної області на власний розгорнутий артефакт (виконуваний файл, сценарій, JAR, WAR тощо). Це дає вам гнучкість, наприклад, дозволяючи масштабувати, розгортаючи більше примірників, де вони потрібні. Скажіть, що користувачі витрачають більше часу на перегляд вашого каталогу, ніж вони додають речі в кошик для покупок; один розгортається артефакт обробляє функції каталогу, інший обробляє функції кошика для покупок - ви можете запустити більше копій служб каталогу для обробки навантаження.
Це також ізолює їх від внутрішніх змін. Скажімо, ви переходите з реляційної бази даних до бази даних документів для зберігання даних про товар - шанси на те, що послуги вашої кошики не потрібно змінювати.
Модель актора - нижчий рівень, ніж артефакт, що розгортається, більше про типи об’єктів, з якими ви реалізували послугу. Продовжуючи вищенаведений приклад, у вашій системі кошики у вашій системі можуть бути представлені акторами, тому кошик кожного користувача є чітким актором, і повідомлення повідомляють йому додавати предмети, видаляти предмети, відповідати поточним вмістом, додавати доставку, перевірити і т. д. У цьому випадку у вас ще є мікросервіс, і він реалізований з акторською моделлю.
Я б сказав, що головна відмінність полягає в детальності.
Для акторської моделі це відносно тонкозерниста, оскільки актор прагне представляти еквівалент одного об'єкта в ООП.
Для мікропослуг це порівняно грубо, тому що одна мікросервіс може складатися з великої кількості суб'єктів чи об'єктів.
Зауважте, що вам не потрібно було б розтягувати свою фантазію занадто далеко, щоб сказати, що сучасний Інтернет - це те саме, що має ще більшу деталізацію ("макросервіси"); і що (наприклад) HTTP-сервер - це макро-сервіс, сервер бази даних - макро-сервіс, веб-браузер - макро-сервіс тощо.
Все приблизно однаково - поодинокі частини, які спілкуються. Змінюються лише розмір штук (а отже, і кількість штук).
Мікросервіси масштабують горизонтально, створюючи кілька реплік, кожна з яких здатна обслуговувати запити внаслідок послуги без громадянства . Вони стійкі до невдачі в силу свого бездержавного характеру.
Актори масштабують, переміщуючи їх до розділів з меншим навантаженням або більшою кількістю доступних ресурсів. Вони значущі . Вони стійкі до невдач, оскільки - залежно від акторських рамок - інший актор може динамічно закручуватися або гаряче резервне копіювання актора могло підтримуватися у будь-який час для вирішення проблеми з первинним актором.
Знову ж, мікросервіси теж можуть бути великими, але це суперечить принципам дизайну мікропослуг.