Oba wydają się być równoległą siecią komunikacyjną MPI. Identyfikuję aktorów z usługami. Czy aktorzy są bardziej dynamiczni (możesz ich tworzyć i zabijać jak oddychanie, podczas gdy sieć serwisowa jest bardziej statyczna) czy co?
Odpowiedzi:
Model aktora - jest modelem matematycznym dla równoczesnych obliczeń, a mikrousług - implementacją architektury zorientowanej na usługi. Podobieństwa są dość przypadkowe.
Z pewnością możliwe jest budowanie mikrousług na podstawie modelu aktora i modelowanie architektury mikrousług z modelem aktora, ale to nie znaczy, że są one równoważne. Zamień „system mikrousług” na „system poczty e-mail” i nadal będzie to prawdą. Zamień „model aktora” na „Komunikacja procesów sekwencyjnych” (CSP), a będzie to również „prawda”, ponieważ systemy CSP i modeli aktorów mogą być modelowane przez siebie nawzajem.
Biorąc pod uwagę model aktora, możesz go wdrożyć za pomocą mikrousług, SOA, a nawet poczty e-mail, ale to nie znaczy, że są na tym samym poziomie abstrakcji, aby naprawdę porównać.
Model aktora podkreśla także bufory (można traktować je jako kolejki komunikatów w świecie mikrousług), więc niektóre podmioty / mikrousługi mogą nie być gotowe, podczas gdy z natury asynchroniczna komunikacja jest nadal możliwa.
Innymi słowy, porównanie z modelem aktora może przynieść pewne kreatywne spostrzeżenia na bardzo wysokim poziomie rozważań, ale głównie są to jabłka kontra pomarańcze.
Jeśli celem jest porównanie modelu matematycznego SOA / mikrousług z modelem Actora, nie jest to również trywialne, ponieważ: 1) nie ma uzgodnionego modelu matematycznego dla SOA, 2) model zwykle obejmuje cel. Modelowanie SOA / mikrousług bardzo prawdopodobnie różni się od celu modelu aktora. Jeden przykład próby modelowania SOA tutaj .
Oczywiście można stworzyć system modeli aktorów z mikrousługami i nazwać każdą usługę aktorem (patrz ścisła definicja tego, czym jest model aktora). Ale to nie oznacza, że istnieje jakikolwiek znaczący związek między nimi w sensie ogólnym.
Mikrousługi są sposobem na organizację oprogramowania poprzez podzielenie każdego obszaru zainteresowania na własny artefakt, który można wdrożyć (plik wykonywalny, skrypt, JAR, WAR itp.). Zapewnia to elastyczność, na przykład umożliwiając skalowanie poprzez wdrożenie większej liczby instancji tam, gdzie są one potrzebne. Powiedz, że użytkownicy spędzają więcej czasu na przeglądaniu Twojego katalogu niż na dodawaniu rzeczy do koszyka; jeden artefakt, który można wdrożyć, obsługuje funkcje katalogu, drugi obsługuje funkcje koszyka - można uruchomić więcej kopii usług katalogu, aby obsłużyć ładunek.
Izoluje je także od zmian wewnętrznych. Załóżmy, że przechodzisz z relacyjnej bazy danych do bazy danych dokumentów w celu przechowywania danych produktów - istnieje prawdopodobieństwo, że usługi koszyka nie będą musiały się zmieniać.
Model aktora ma niższy poziom niż artefakt do wdrożenia, więcej o tym, z jakimi typami obiektów zaimplementowałeś usługę. Kontynuując powyższy przykład, możesz mieć koszyki zakupów w twoim systemie reprezentowane przez aktorów, więc każdy koszyk użytkownika jest odrębnym aktorem, a wiadomości każą mu dodawać przedmioty, usuwać przedmioty, odpowiadać aktualną zawartością, dodawać wysyłkę, sprawdzać itd. W tym przypadku nadal masz mikrousługę, która jest zaimplementowana w modelu aktora.
Powiedziałbym, że główna różnica polega na ziarnistości.
W przypadku modelu aktora jest on stosunkowo drobnoziarnisty, ponieważ aktor zwykle reprezentuje ekwiwalent jednego obiektu w OOP.
W przypadku mikrousług jest stosunkowo gruboziarnisty, ponieważ pojedyncza mikrousługa może składać się z dużej liczby aktorów lub obiektów.
Zauważ, że tak naprawdę nie musiałbyś zbytnio rozciągać swojej wyobraźni, aby powiedzieć, że współczesna sieć to to samo z jeszcze większą szczegółowością („makrosługi”); i że (np.) serwer HTTP jest usługą makr, serwer bazy danych jest usługą makr, przeglądarka internetowa jest usługą makr itp.
Wszystko jest mniej więcej takie samo - pojedyncze elementy, które się komunikują. Zmienia się tylko rozmiar kawałków (a tym samym ich liczba).
Mikrousługi skalują się w poziomie, tworząc wiele replik, z których każda jest w stanie obsługiwać żądania ze względu na bezstanowy charakter usługi. Są odporni na upadki z powodu swojej bezpaństwowej natury.
Aktorzy skalują się, przenosząc je do partycji z mniejszym obciążeniem lub dostępnymi zasobami. Są stanowe . Są odporni na awarie, ponieważ - w zależności od struktury aktora - inny aktor może zostać dynamicznie rozpędzony lub można w każdej chwili zachować kopię zapasową aktora, aby poradzić sobie z awarią głównego aktora.
Ponownie, mikrousługi mogą być również stanowe, ale jest to sprzeczne z zasadami projektowania mikrousług.