Egy leegyszerűsített, teoretikus helyzet:
Van egy microservice alapú backend, mely A,B,C,D,E szolgáltatásokból áll. A szolgáltatások JSON-RPC-n beszélgetnek HTTP felett. A microservice-ek egy multirepo-ban laknak a Git-ben, egyszerre megy ki az összesre a deploy. Egy deploy után jelentősen megnő az teljes rendszer válaszideje és az A, B szolgáltatások CPU terhelése jelentősen nő. Mi lehet a baj?
Azt már a hálózati fejlécek utólagos elemzéséből is meg lehet nézni, hogy mely két komponens közti kapcsolatok átlagos kiszolgálási ideje nőtt meg a deploy előttihez képest. De ebből még nem lehet tudni, hogy pontosabban hol a hiba. Ha a TCP kapcsolatokhoz hozzá tudnád rendelni a kérés irányát (bár ez még a TCP-ből kitalálható) és az RPC függvény nevét és paramétereit, és ezeknek a deploy utáni kiszolgálási diagramjait összeveted a deploy előtti nappal, akkor már azt is látni lehet, hogy konkrétan melyik RPC hívás kiszolgálása lassult le.
A fejlesztők ezek után sokkal könnyebben rájöhetnek, hogy mi lehet a kiváltó ok. Amúgy ezt persze alkalmazás szintű profiling segítségével is lehet mérni, de ez ellen néhány érv:
- minden microservice-be implementálni kell,
- nem feltétlenül lesz egységes, lehet, hogy a microservice-ek technológiája heterogén, nem mindnél megvalósítható azonos megoldás,
- a profiling jó eséllyel kisebb-nagyobb mértékben lerontja a teljesítményt.
Ellenben ha ez hálózat szinten van kezelve, akkor csak egyetlen helyen kell implementálni és utána akár 20-30 microservice profilingja is egyszerűen, egységesen, egy helyen megoldható. Hangsúlyozom nem egy PHP+MySQL CMS-ről beszélünk, hanem egy milliótól kezdődő felhasználó számú, sokszáz szerveres backend-ről.
BTW nem én adtam elő a témáról, csak az előadás alapján nekem ez jött le. Csak álmodoztam egyet egy jól kezelhető forgalom elemzőről, mely remek lenne egy jó komplex rendszerhez.