Ostatnio dużo czytałem o mikro-usługach i oto niektóre wnioski, które do tej pory wyciągnąłem (proszę, popraw mnie, jeśli się mylę w dowolnym momencie).
- Architektura mikrousług dobrze współgra z projektowaniem opartym na domenie. Zwykle jedno państwo członkowskie reprezentuje jeden ograniczony kontekst.
- Jeśli mikrousługa A wymaga funkcji znajdującej się w mikrousługie B , prawdopodobnie mój model jest nieprawidłowy, a A i B powinny w rzeczywistości być jedną mikrousługą / BC.
- Synchroniczna komunikacja między mikrousługami (bezpośrednie żądania HTTP) jest zła, ponieważ nie spełnia celu mikro-usług i wprowadza sprzężenie między komponentami.
- Pożądana jest asynchroniczna komunikacja między usługami. Usługi powinny publikować zdarzenia w kolejkach komunikatów, aby inne usługi mogły subskrybować i przetwarzać swoją część zdarzenia lub wykorzystywać je do replikacji części danych potrzebnych do ich kontekstu. W ten sposób usługi mogą przetwarzać żądania, nawet gdy inne usługi są wyłączone, co nie byłoby w przypadku komunikacji synchronicznej.
- Jeśli mikro-usługa A publikuje zdarzenie, mikro-usługa B subskrybuje to zdarzenie i generuje nowe zdarzenie jako wynik, mikrousługa A nie powinna być tym przetwarzającym nowo utworzone zdarzenie, ponieważ byłaby to zależność cykliczna. W takim przypadku powinniśmy wprowadzić trzecią mikrousługę lub połączyć A i B w mikrousługę AB .
- Mikro-usługa jest w rzeczywistości terminem wprowadzającym w błąd. Powinniśmy dążyć do małych kontekstów, ale nie musi tak być. Termin nie powinien być „mikrousługą”, ale „ wystarczająco duży, aby wykonać pracę ”.
- Mikro-usługi pozwalają nam wprowadzać nowe funkcjonalności z większą łatwością i bez obawy, że zepsujemy cały system. Można tego dokonać, wprowadzając nową usługę lub refaktoryzując jedną z istniejących.
- Każda mikrousługa powinna mieć własne miejsce do przechowywania danych. Replikacja / duplikacja danych jest pożądanym zachowaniem w tej architekturze.
Poza potwierdzeniem mojego zrozumienia tej architektury, moja inna część pytania dotyczy głównie odkrywania usług. Jeśli usługi komunikują się asynchronicznie i korzystają z centralnej kolejki zdarzeń, takiej jak amazon SQS, czy to oznacza, że wykrywanie usług nie ma miejsca w takiej architekturze?
Usługi nie powinny mieć żadnej wiedzy o innych usługach w systemie. Są świadomi tylko swojego kontekstu i wydarzeń, które powinni publikować lub subskrybować?
Mikro-usługi dotyczą oddzielania różnych domen funkcjonalności. Każda usługa może być rozwijana w innym tempie, przez inny zespół, przy użyciu innego stosu technologii. Zapewnia to elastyczność organizacyjną. Kompromisem jest złożoność operacyjna, w której każda dodatkowa usługa tworzy jeszcze jedną rzecz, którą należy zarządzać w środowisku operacyjnym. Tak więc podstawowy kompromis między monolitem a mikrousługą nie polega na unikaniu zależności, lecz na unikaniu etapowego opracowywania i wdrażania, w którym wszystko musi być wysyłane jednocześnie, ale kosztem konieczności wysyłania częściej, ponieważ istnieją więcej ruchomych części.
Problemem unikania zależności jest czerwony śledź. Zawsze będziesz mieć zależności między częściami swojego produktu, a to, czy są one w oddzielnej usłudze, czy w części tego samego kodu, nie zmienia faktu, że zależności mogą się zerwać. Mogą się zepsuć na poziomie operacyjnym, ponieważ serwer kluczy przestaje działać, a Ty zarządzasz tym poprzez nadmiarowość operacyjną i praktyki przełączania awaryjnego. Mogą również ulec uszkodzeniu na poziomie integracji, ponieważ części zmieniają się w niekompatybilny sposób, co można wykryć podczas testowania integracji. Tasowanie kodu między usługami nie rozwiązuje problemu potencjalnie zepsutych zależności. Rozwiązaniami pozwalającymi uniknąć przerwanych zależności są testy nadmiarowości operacyjnej i integracji, które nie mają nic wspólnego z rozmiarem twoich usług.
Aby odpowiedzieć na to pytanie, najpierw odpowiedz na to: dlaczego chcesz komunikować się asynchronicznie? Czy ma to ułatwić niezależny rozwój oddzielnych komponentów? Czy ma to poprawić dostępność operacyjną systemu 24/7? Powiedzmy, że to ten drugi i chcesz użyć kolejek do replikacji danych do lokalnych baz danych. Cóż, teraz Twoje dane mogą być nieaktualne. W pewnym momencie będzie zbyt przestarzały. Jak sobie z tym radzisz? Ponadto, w jaki sposób zapewniasz dostępność operacyjną kolejki, która jest kolejnym komponentem wykonawczym? W jaki sposób zapewniasz dostępność tych lokalnych baz danych? Zamiast zarządzać jednym klastrem bazy danych, teraz masz kilka. Czy Twój zespół operacyjny może poradzić sobie z tym obciążeniem? I naprawdę, czy złożoność jest tego warta, kiedy być może Twoi użytkownicy będą zadowoleni z większej liczby funkcji i kilku godzin przestoju każdego miesiąca, jeśli zbudujesz prosty monolit?
Myślę, że rozumiesz mój punkt widzenia. Projektowanie systemu nie polega na tym, co dobre i złe, ale na wybieraniu spośród szerokiej gamy kompromisów. Wszystko, co jest nie tak, może być właściwe i odwrotnie, jeśli tylko zobaczysz to we właściwym kontekście. Context jest unikalny dla ciebie, więc podczas gdy możemy dać się odpowiedź, że nie będzie odpowiedź. Pamiętaj, kim są twoi odbiorcy, jakie są ich potrzeby, a odpowiedni projekt się ujawni.
źródło
Nie zgadzać się. DDD bywa bardzo OO. zamówienie jest dostarczone? Order.Deliver (), podczas gdy mikrousługi miałyby DeliveryService.Deliver (zamówienie)
Nie zgadzam się, powinieneś starać się utrzymać mikro usługi mikro. podziel je na jeszcze mniejsze!
Nie zgadzać się. usługi nie powinny dbać o to, kto do nich dzwoni, a dzwoniący nie powinni dbać o to, że logika jest zaimplementowana w mikrousługach.
Kolejki są dobre. Ale twoje rozumowanie jest błędne. jedyną różnicą między odpowiedziami synchronizacyjnymi a asynchronicznymi jest to, że czekasz na jedną synchronizującą. Możesz implementować wywołania w stylu RPC z kolejkami i wieloma pracownikami bez problemu.
Nie zgadzać się. Nie jest to zależność cykliczna, ponieważ mikrousług nie są powiązane. Również chcesz zaspokoić ponowne wysyłanie senarios, SendEmail, EmailFailed, SendAgain nie potrzebuje 3 mikro-usług
Nie zgadzać się. Sprawdź nano-usługi.
Nie zgadzać się. Tak, masz rozdzielenie, ale koordynacja mikrousług może być tak zniechęcająca jak każdy projekt monolityczny
Nie zgadzać się. Chociaż nie powinieneś współdzielić przestrzeni dyskowej, twoje mikro-usługi powinny starać się być bezstanowe tam, gdzie to możliwe. nie powielaj danych, chyba że jest to inflight
źródło
Twoje wnioski są fajne, ale nie uniwersalne. Zdarzają się przypadki, gdy najlepszą opcją jest złamanie tych zasad, nawet w projekcie typu greenfield. W niektórych przypadkach najlepszym rozwiązaniem jest komunikacja synchroniczna. W niektórych przypadkach nie jest dobrze połączyć dwie usługi w jedną, nawet jeśli są one połączone komunikacją synchroniczną.
W przypadku drugiego pytania wykrywanie usług nie jest wymagane w przypadku komunikacji opartej na kolejce.
źródło
Mówisz tylko o programowaniu obiektowym. A przynajmniej to, co pierwotnie miało być: niezależne fragmenty działającego kodu komunikujące się ze sobą za pomocą komunikatów.
Alan Kay wymyślił OOP wzorowany na układach biologicznych, w których komórki są względnie niezależne od siebie i komunikują się za pośrednictwem komunikatów podłączanych do zewnętrznych interfejsów innych komórek.
Dlaczego więc przestajemy myśleć o tym jako OOP tylko dlatego, że wszystkie obiekty nie działają na tym samym komputerze? Jeśli już, jest to nawet bardziej zorientowane obiektowo niż na tym samym komputerze i części tej samej aplikacji, ponieważ jeśli wszystkie obiekty znajdują się w tej samej aplikacji, programiści często przerywają OOP, używając zmiennych globalnych wspólnych dla wszystkich klas i w tym te same nagłówki w każdym pliku itp. Gdy wszystkie obiekty zależą od tych samych rzeczy, nie są tak enkapsulowane, jak gdyby były całkowicie od siebie niezależne, a enkapsulacja to cały punkt OOP.
Na przykład prawie wszystko, co powiedziano w innych odpowiedziach, to podręczniki o OOP.
źródło
Ponieważ często spotykam się z niewłaściwym rozumieniem tak ważnej koncepcji, jak Ograniczony kontekst i domena podstawowa, chciałbym rozwinąć nieco tę kwestię.
Uważam, że niezwykle opłacalne jest myślenie o subdomenach jako o możliwościach biznesowych. Możliwości biznesowe to coś, co robi Twoja organizacja. Jest to jedna z jego funkcji biznesowych. Ponieważ naszym celem jest dostosowanie biznesu do IT , zdecydowanie chcę, aby miały one stosunek 1: 1 do moich służb technicznych .
Ten proces sprowadza się do następujących kwestii. Najpierw definiuję możliwości biznesowe wyższego poziomu. Powinien przybierać formę rzeczownika i czasownika (lub innej formy pochodnej). Zwykle jest mniej niż 10 możliwości biznesowych. Potem jestem głębiej, identyfikując zagnieżdżone możliwości. I tak dalej, dopóki nie będzie nic do podzielenia. Możliwości, które przyszedłeś przy użyciu tego podejścia, odzwierciedlają rzeczywistą domenę, rzeczywisty sposób działania organizacji. Funkcje te będą wewnętrznie luźno powiązane, więc jeśli zmapujesz swoje usługi techniczne na te możliwości, będą one autonomiczne i sterowane zdarzeniami. Proces ten nazywa się mapowaniem zdolności biznesowych , ale istnieją inne sposoby znalezienia usług, z których najbardziej widoczna to prawdopodobnie analiza łańcucha wartości .
Oto przykład identyfikacji granic usług przy użyciu tego podejścia.
źródło