Hlavní navigace

Vlákno názorů k článku Mikroslužby: moderní aplikace využívající známých konceptů od Jan - Podle mě jsi Pavle otevřel pandořinu skřínku, protože...

  • Článek je starý, nové názory již nelze přidávat.
  • 17. 5. 2019 14:26

    Jan

    Podle mě jsi Pavle otevřel pandořinu skřínku, protože co člověk, to názor, co je to mikroslužba. Proto tady i já uvádím svůj názor. Podle mě má mikroslužba tyto 2 hlavní vlastnosti, související s izolací:
    - mikroslužba funguje nad jednou svojí databází a není nikdo jiný (tedy mikroslužba), kdo by měl k ní přístup, s výjimkou synchronizačních technologií, které sem data zduplikují od jinud
    - mikroslužba nikdy nevolá přímo jinou mikroslužbu, ale raději konzumuje data z message brokeru, nebo předpokládá, že nějaká technologie zduplikuje data do databáze této mikroslužby.

    Z toho mi pak plynou jiné výhody a nevýhody. Určitě my ale z toho neplyne, že výpadek jedné mikroslužby ohrozí celý systém, ba právě naopak, prostě jen nebudou v nějaké databázi vznikat a nepřenesou se ani ke mě.

    Dále mi z toho plyne to, že data se duplikují. Samozřejmě, musí se vědět, kde jsou data primárně, kde jsou masterovány. Je to trochu jiný pohled než u databází, kde jsme se učili, že normální formy se neporušují a že každé dato je všude jen jednou a neduplikuje se. Mimochodem, to se porušovalo již dřív i u databází, jinak bychom nedosáhl performance.

    Dále z toho plyne to co říká i Fowler a sice žádné ESB, z čehož mi plyne taky žádná zřeťezená volání a z toho plyne také větší performance a nenáchylnost na nefukčnost některého z backendů, které ESB převolává. A také je mi jako programátorovi sympatické, že ubude počet modelů, mezi kterými se přemapovává - ESB jako vrstva navíc rovná se 2 mapování navíc, které někdo musí udělat = zdroje chyb, apod..

    Ještě jsi tam zmiňoval aplikační servery. Aplikační servery jsou dnes již dávno překonané, protože to je opravdové peklo. Nemám teď na mysli lightweight servery, ale ty heavy weight, kde se již překonalo paradigma, že AS má mít všechny knihovny v sobě a razí se trend, že všechny knihovny si nese s sebou aplikace sama.

  • 17. 5. 2019 16:39

    Pavel Tišnovský

    Ahoj Honzo.

    Jsem rád, že jsme se znovu potkali, aspoň takto virtuálně :-)

    Máš pravdu v tom, že pokud služby budou vždy používat message broker a nikdy se nebudou volat přímo, tak ty výpadky skutečně nemusí být fatální. Je to potom ale úplně jiné přemýšlení o tom, jak navrhnout celou architketuru. Jenom rozdělením monolitu na části se ničeho nedosáhne, jak správně napsali předřečníci výše.

    My jsme například navrhli architekturu špatně a máme tam zřetězení a dokonce (fuj fuj) přístup do společné databáze, navíc ještě pro jistotu s malou výkonností. Takže se sice tváříme, že máme MOA, ale v praxi to tak není, jen je složitější deplyoment, orchestrace a monitoring :( O tom někdy v dalším článku, jak se to NEMÁ dělat.

    Obecně duplikace dat není problém, jen je potřeba vědět, kdo je jejich skutečným vlastníkem. Ale to je fakt dost obsáhlé téma a podle mě ještě ty správné návrhové vzory přijdou.