Co tak naprawdę różni się między SOA a Microservices

Zrzeczenie się

Mam nadzieję, że nie nadepnę na nóg ani nie obrażę entuzjastów obu koncepcji

tło

Szukałem prawdziwych różnic między architekturą zorientowaną na usługi a mikrousługami, nie znajdując żadnej jasnej odpowiedzi.

Czytam takie rzeczy jak:

• skutki uboczne SOA
• SOA jest anty-wzorzec
• Przyszły mikrousługi, aby naprawić awarie SOA
• ESB nie są tak naprawdę ESB, lecz EAI
• Nadmierna zależność od brokerów wiadomości
• Sprzedawcy nadużywają pojęcia SOA i próbują sprzedawać swoje produkty
• SOA rośnie w niekontrolowany sposób

Ale nadal nic nie definiuje wyraźnie różnic architektonicznych między architekturą zorientowaną na usługi (jako koncepcja) a mikrousługami (jako koncepcja)

Zgodnie z tym, co zrozumiałem, oba mają:

• Dostawcy usług, robią tylko jedną rzecz
• Service Gateway / ESB ujawnia te usługi konsumentom
• Usługobiorcy, uzyskujący dostęp do usług za pośrednictwem ESB / Service Gateway

Pytanie

Czy jest coś innego niż zmiana nazwy SOA na Microservices? czy jest to ograniczenie technologiczne, które ma na celu ograniczenie możliwości przekształcenia Mikrousług w makro?

Uwaga: nie szukam opinii, tylko twarde fakty, mam nadzieję, że w punktach

Bibliografia

• Pytania dotyczące inżynierii oprogramowania
• Witryna Martina Fowlera (myślę, że on go nienawidzi)
• Świat informacji
• Witryna Michaela Fethersa
• Pytania dotyczące przepełnienia stosu

Aktualizacja

Wygląda na to, że podobna debata odbyła się w pytaniu o przepełnienie stosu , z opiniami podzielonymi niezależnie od tego, czy Mikrousługi są z natury zorientowane na usługi architektury.

Wniosek z pytania SO:

• MS jest szczególnym przypadkiem SOA
• MS poleca mniejszy rozmiar usług hostingowych aplikacji
• MS jest zależne od technologii (użycie HTTP zamiast opcji otwartego protokołu)
• PC polega na technologii w celu egzekwowania dyscypliny (automatyczne wdrażanie usług)
• MS uważa, że ​​ESB (zło), ale używa bram API, które IMHO jest rodzajem ESB

To stwierdza, że ​​MS jest SOA, jeśli spełnione są następujące warunki:

• Czy stwardnienie rozsiane popiera pojęcie orkiestracji? Jeden lub więcej procesów głównych zarządza przepływami pracy
• Czy w MS jest warstwa brokera wiadomości? Zestaw adapterów tłumaczących formaty komunikatów z przestrzeni komunikatów producentów usług na odbiorców usług
• Czy mikrousługi mogą odczytać dane z monolitycznych aplikacji korporacyjnych? Czy mogą to być interfejsy API aplikacji monolitycznej? czy musi to być samodzielna samodzielna aplikacja, zdolna do niezależnego działania?

Jeśli odpowiedź na ostatnie pytanie okazałaby się przecząca, wówczas Microservices nie byłby w stanie obsługiwać złożonych systemów przepływu pracy, np. Systemów zarządzania kartami kredytowymi lub systemów uzgadniania

Dostawcy usług, robią tylko jedną rzecz

Zasadnicza różnica, która ma szeroko rozpowszechnione konsekwencje w projekcie, polega na tym, że dzięki Microservices dostawcy usług są niezależni od wdrożenia i skalowalności .

To świetnie, ponieważ możesz być bardziej zwinny. Jeśli usługa wymaga zmiany, wystarczy zmienić tę, żadna z jej rodziny. Jeśli chcesz wypróbować nowy framework lub język, po prostu zamień drop-in dla tej jednej usługi. Jeśli nagle potrzebujesz pojemności 100x, uruchom kilka nowych maszyn z tą usługą, aby poradzić sobie z tym napływem. Jeśli chcesz coś zaktualizować, po prostu zrób to bez dotykania całej aplikacji. A to sprawia, że rzeczy łatwiej monitora, instrumentu, divvy wśród zespołów, nieaktualne ...

Ale ma to pewne poważne konsekwencje:

• Twój proces wydania musi się zmienić, ponieważ wdrożenie kilku usług różni się znacznie od wdrożenia kilkudziesięciu usług.
• Twój proces wydania musi się zmienić, ponieważ wdrożenie usługi na jednym komputerze różni się znacznie od wdrożenia na kilkudziesięciu komputerach.
• Projekt, użycie i wdrożenie bazy danych musi ulec zmianie, ponieważ wdrożenie usługi jest dość pozbawione sensu, jeśli musi ona wdrożyć tę dużą współużytkowaną bazę danych do działania (zerwanie wszystkich innych usług).
• Twój projekt i wykorzystanie bibliotek musi ulec zmianie, ponieważ wdrożenie usługi w przypadku aktualizacji tej biblioteki współdzielonej (zepsucie wszystkich innych usług) nie ma sensu.
• Twój logowania / autoryzacji / zarządzania sesją / etc musi się zmienić, ponieważ jest to dość łatwe do rzeczy zakładowego kiedy jesteś tylko jedna usługa, ale inaczej, gdy masz kilka małych niezależnych usług, które tworzą produkt - a oni zamiar do chcę się dzielić. Aha, i wszystkie te wspólne rzeczy muszą radzić sobie z potencjalnym byciem w różnych wersjach.
• Twoja komunikacja musi się zmienić. Za pomocą niewielu usług możesz zepsuć rzeczy wzdłuż linii, w których komunikacja nie zdarza się często i / lub może odbywać się powoli. Dzięki mikrousługom będą dużo ze sobą rozmawiać, a duże opóźnienia nie będą tego ograniczać.

Oto sedno Jedną oczywistą różnicą między SOA i Microservices jest pojęcie

Inteligentne punkty końcowe Głupie rury

W przeciwieństwie do SOA polegałoby to na nieświadomych klientach i producentach usług, delegowaniu zarządzania ruchem, tłumaczeniu formatu wiadomości i organizacji usług na systemy zewnętrzne, np. ESB, Orchestrator usług, broker wiadomości.