Mikroslužby nakreslené poctivo
Každý diagram mikroslužieb vyzerá rovnako a takmer žiadny neodpovie na jedinú dôležitú otázku: dá sa ktorákoľvek z nich nasadiť samostatne? Dve usporiadania tých istých štyroch služieb - jedno, kde sa dá, a jedno, kde nie.
8 min čítaniaUML 2.5.134 z 35
Krátka odpoveď
- Jediná otázka, na ktorú musí diagram mikroslužieb odpovedať, je, či by sa ktorýkoľvek box dal vydať vo svoj vlastný deň.
- Sledujte synchrónne šípky a spočítajte skoky. Tri a viac služieb, ktoré musia všetky bežať pre jednu používateľskú akciu, je distribuovaný monolit.
- Volania kreslite ako rozhrania a udalosti ako signály. Úsudok schovaný v kóde sa tým zmení na niečo, s čím môže revízor nesúhlasiť.
- Jedna databáza na službu a mimo tento diagram. Kde bežia, je pohľad na nasadenie; čo obsahujú, je vlastný model každej služby.
01Otázka, na ktorú musí diagram mikroslužieb odpovedať#
Nie "aké služby existujú" - to spraví zoznam a ten zoznam býva v názvoch repozitárov. Otázka znie: dá sa ktorákoľvek z nich nasadiť samostatne? Všetko, čo ľudia od mikroslužieb dúfajú získať - nezávislé vydania, nezávislé škálovanie, tím, ktorý vie dodať bez koordinačnej porady - vyplýva z toho, že odpoveď je áno, a žiadna iná vlastnosť toho obrázka nie je dôležitá, ak je nie.
Diagram komponentov na ňu odpovie, pokiaľ nakreslíte tie správne veci. Každá nasaditeľná služba je komponent; každý zverejnený kontrakt je rozhranie; každá udalosť je «signal». Potom zakryte jednu službu dlaňou: ak to, čo zostane, plne špecifikuje jej náhradu, tá služba sa dá vydávať vo vlastnom rytme.
02Dva druhy šípky, zámerne#
Na obrázku vyššie gateway závisí od IOrders - synchrónneho kontraktu, lebo gateway nevie používateľovi odpovedať bez objednávky. Shipping a billing mieria na OrderPlaced, signál, ktorý order service posiela a nečaká naň.
Nakresliť tie dve odlišne je celá hodnota toho obrázka. Synchrónne hrany sú miesta, kde sa skladá dostupnosť: ak je order service dole, gateway vráti chybu. Udalostné hrany sú miesta, kde nie: keď je dole shipping, oneskorí sa balík a nič iné to so sebou nestiahne. Diagram, ktorý obe kreslí ako obyčajné šípky, zmazal rozdiel, ktorý rozhoduje o tom, ako systém zlyháva.
03Usporiadanie, ktoré treba spoznať#
Toto je distribuovaný monolit a je to najčastejší tvar v produkcii. Nič na ňom nie je nelegálne, nič nie je zle pomenované a prejde posudzovaním, lebo vyzerá ako každý iný diagram mikroslužieb. To, čo hovorí, ak čítate šípky namiesto boxov, je, že tie štyri služby sa musia nasadzovať spolu, testovať spolu a byť hore spolu - takže tím vzal na seba každý náklad distribúcie a nechal si každé obmedzenie monolitu.
Príznak sa dá spočítať: počet synchrónnych skokov na jednu požiadavku. Jeden je v poriadku. Dva sú obvykle v poriadku. Tri a viac a dostupnosť celku je súčinom dostupností častí, takže štyri služby po 99,9 % dajú spolu asi 99,6 % - čo sú tri hodiny mesačne, keď si nikto nevie nič objednať.
Nápravy sú viditeľné na tom istom obrázku. Nechajte orders publikovať udalosť a nechajte pricing a inventory na ňu reagovať. Alebo zlúčte dva z tých boxov, čo je legitímna odpoveď, ktorá sa navrhuje zriedka. Alebo nakešujte to, čo pricing potrebuje, aby ten skok prestal byť na ceste požiadavky. Všetky tri sú úpravy tohto diagramu, a preto sa ho oplatí nakresliť pred stavbou za tých dvadsať minút.
Po jednom riadku na každé
- 01Jeden komponent na nasaditeľnú službu, jedno rozhranie na zverejnený kontrakt, jeden signál na udalosť.
- 02Synchrónnu a asynchrónnu väzbu kreslite odlišne - je to spôsob, akým systém zlyháva.
- 03Synchrónne, keď volajúci potrebuje odpoveď; udalosť, keď nie.
- 04Počítajte synchrónne skoky na požiadavku: tri a viac je distribuovaný monolit.
- 05Po synchrónnej reťazi sa dostupnosť násobí a zo štyroch deviatok sú tri.
- 06Zakryte ktorúkoľvek službu: to, čo zostane, musí špecifikovať jej náhradu, inak sa nedá vydávať samostatne.
Notácia je pokrytá v sprievodcovi diagramom komponentov a päť ďalších usporiadaní - vrátane obojsmerného cyklu, ktorý tento článok neopakuje - je v príkladoch diagramov komponentov.
04Časté otázky#
Ako sa mikroslužby kreslia v UML?
Ako komponenty, jeden na každú nasaditeľnú službu, s rozhraním pre každú publikovanú zmluvu a signálom pre každú udalosť. Diagramom mikroslužieb ho robí to, že každý box by sa dal vydať vo svoj vlastný deň - a rozhrania okolo neho toto tvrdenie buď podporujú, alebo mu protirečia.
Ako z diagramu spoznám distribuovaný monolit?
Sledujte synchrónne šípky a spočítajte skoky na jednu požiadavku. Ak jedna používateľská akcia prejde cez tri a viac služieb, ktoré musia všetky bežať, distribuovali ste monolit namiesto toho, aby ste ho rozložili - a diagram vám to povedal skôr než produkcia.
Majú služby komunikovať synchrónne alebo cez udalosti?
Synchrónne vtedy, keď volajúci bez odpovede nemôže pokračovať, a cez udalosť vtedy, keď môže. Kresliť to dvoma rôznymi spôsobmi - rozhranie pre volania, signál pre udalosti - mení tento úsudok na niečo, čo revízor vidí a môže s tým nesúhlasiť, namiesto konvencie schovanej v kóde.
Kam patrí databáza na diagrame mikroslužieb?
Jedna na službu a mimo tento diagram. Pohľad na komponenty je o zmluvách medzi službami a nakreslenie piatich databáz pridá päť boxov, ktoré hovoria to isté; kde bežia, patrí do diagramu nasadenia a čo obsahujú, do vlastného modelu každej služby.
V tejto sérii
- 01Čo je UML?
- 02Symboly UML
- 03Výber diagramu
- 04Diagramy tried
- 05Príklady diagramov tried
- 06Ako nakresliť diagram tried
- 07Symboly diagramu tried
- 08Sekvenčné diagramy
- 09Príklady sekvenčných diagramov
- 10Ako nakresliť sekvenčný diagram
- 11Diagramy prípadov použitia
- 12Príklady prípadov použitia
- 13Diagramy aktivít
- 14Príklady aktivít
- 15Stavové diagramy
- 16Príklady stavových diagramov
- 17Diagramy komponentov
- 18Príklady komponentov
- 19Kreslenie diagramu komponentov
- 20Symboly komponentov
- 21Diagramy nasadenia
- 22Príklady nasadenia
- 23Diagramy objektov
- 24Diagramy balíkov
- 25Diagramy zloženej štruktúry
- 26Komunikačné diagramy
- 27Sekvenčný vs komunikačný
- 28Časové diagramy
- 29Diagramy prehľadu interakcií
- 30Diagramy profilov
- 31UML pomocou AI
- 32Príklad e-shopu
- 33Príklad banky
- 34Príklad mikroslužieb
- 35Príklad AWS
Súvisiace články
Diagramy štruktúry
Prax modelovania
Prax modelovania
Diagramy štruktúry
Diagramy správania
Diagramy štruktúry