( turul16 | 2021. 10. 20., sze – 18:37 )

microservicesk azert vannak, hogy hibat konyebben lehesen localizalni.
Ha monolit el crashel vagy leakel akkor tul nagy reszt kell megnezni.

Valoban lassabb, de nem itt bukik meg a a service teljesitmenye.
Ha rendes native codot hasznalsz (pl. rust)  akkor meg mindig ki lehet szolgalni a feladatott ertelmesen.

TCP_RR regen 30 usec korul mozgott egy ~2GHZ -s serveren. manapsag localhost masik utat hasznal (volt hogy localhost roszabb volt, gyors interface eseten).
Namarmost 1ms latency egy web servertol nem rosz, ha -e kozben csinal 10 parhuzmos hivast, ami mondjuk ugrik meg vagy ketot akkor meg idon belul vagyunk.

microservicel ugy todod labon loni magad hogyha rosz a terv es tul sok tavoli hivas kell, vagy kozistenciat sertenek sorozatban. 
Aminek egy tranakcinak kene lenie de micro orultseg miett nem megy , akkor baj lehet.

Ha mar hivas koltsegnel vagyunk, egy interpretalt osztalyokat kezelo cumonal hanyszor nagyobb egy methodus hivas koltsege C++ -hoz kepest ;-)
Hint: sok esetben itt tobet buksz mint par tavoli hovasnal, mert egysek sok-sok methoduson keresztul szeretnek nagyon trivialis dolgokat is csinalni.

Webes cuccok altalaban nagyon nem hatekonyak, ha nem microservicek miatt, akkor is valami mindig bekerul amitol total zaba gep lesz,
pedig nem volna nehez rendesen csinalni ..