A következő írás talán hasznos lehet a következő szituációkban:
Szituáció 1: felszolgáló vagy egy elit étteremben, személyesen az Elnökúr
jön a babájával vacsorázni. Kis pánik tür ki a management
körében amikor az elnök úr panaszkodik a terítő tisztaságára (ő ette
le), újrateríteni macerás, rövid ötletelés után úgy döntötök, hogy gyorsan kirántjátok a
terítőt a lecsóspacalpörkölt alól és ugyanazzal a mozdulattal gyorsan be is
csűritek a tisztát.
Én a saját szememmel láttam ilyet a tévében.
Szituáció 2: heggesztőmunkás vagy egy pénzügyi cégnél. A JEE halott, a
cég kidobja a szemétbe 20 évi befektetését és áttelepül spring boot-ra. Ja... és microservices.
Aki dolgozott már ilyen helyen, az tudja milyen csillagászati összegek forognak kockán ha valamit elrontunk. Ahogy a BBC dokumentumfilmek unalomig ismételt konklúziója is megfogalmazza: failure is not an option.
Volt pár dolog, amire persze a legelején számítottam:
- Minden EJB cókmóknak búcsút kell mondanunk örökre - jajjdesajnálom
- A library függőségek portolása fáj.
A spring boot sajnos ugyanolyan mint a webklotyi meg a többi JEE kövület abból a szempontból, hogy van egy sor támogatott library amit ad, az ember használhat saját librarykat, de ha valami ütközésbe kerül a JEE szerver vagy a spring boot által adott librarykkal, akkor elég nehéz feloldani a konfliktust.
Ez nyilván szubjektív, de nekem úgy tűnik, a webklotyiban mégiscsak könnyebben volt lehetséges. Sebaj. Webkoltyi, becstelen halált halsz. - Nehéz átállni spring fejlesztésre olyan fejlesztőkkel, akik elötte egész életükben JEE platformra fejlesztettek.
...és amikre NEM számítottam:
Header limit
Látszólag a webklotyi nem alkalmazott megszorításokat a header-ek méretén, 128 KB-ig próbáltam, mindent bevett.
A tomcat viszont default-ból 8 KB korlátot használ. Ez is a teszt rendszeren derült ki, sok consumer minden kéréséhez a jóhiszeműség bizonyítékaként egy headerben elküldi a Biblia teljes szövegét.
A megoldás egyszerű: felhúztam minden spring boot appban a korlátot egy tisztességesen magas korlátra.
Kis magyarázat: sok szoftver, ami a szoftverünknek küld REST hívásokat nem rendelkezik állandó fejlesztőcsapattal, valamint nagyon sok is van belőlük, viszont "failure is not an option", azaz nem csinálhatok olyan változtatást, amitől hanyattesnek egyes furcsa kliensek, ezek is fontosak valakinek.
Gzip
Miután sikerült az agytranszplantáció és felbootolt a rendszer, minden úgy tűnt, hogy működik, bedobtuk az új alkalmazást tesztelésre és mindenkit nagyon szépen megkértem, hogy vagy futtassa a tesztjeit, vagy manuálisan teszteljen. Pont a legeslegfontosabb consumer csapat jelzett vissza, hogy időnként nem működik. Időnként... az mi?
Néztem a logokat és úgy tűnt, részünkről minden oké, HTTP 200, sehol egy hiba mi lehet a baj?
Sok "egyeztetés" (pöcsölés) után végül úgy döntöttem, legegyszerűbb, ha magam próbálom ki a consumer appot. És akkor kiderült, hogy az alkalmazás mindig is küldött egy Accept-Encoding: gzip headert, ezt a webklotyi app és container folyamatosan figyelmen kívül hagyta (korrekt).
A spring boot setupban viszont a zuul konfigurációban volt egy gzip opció engedélyezve, és ha kb 60 KB felett volt a válasz, akkor bekapcsolt. A consumer app viszont hiába kapta meg, hogy "Encoding: gzip" a tömörített tartalmat próbálta json deserializálni.
Megoldás: kikapcsoltam a gzip opciót, mivel nincs lehetőségem minden consumer appot debugolni.
Szemaforok, timeoutok
Az első terhelési tesztek után figyeltem fel arra, hogy egyes http kérések fentakadtak a zuul szemaforain. Megbeszéltük a kollégákkal és felhúztuk a szemaforok számát annyira, amennyi az éles rendszer terhelése alapján értelmesnek tűnt, illetve megszoroztuk kettővel a biztonság kedvéért.
A teszt rendszeren ezután a terhelési teszt szépen átment, semmi probléma.
Aztán az első éles üzem napon azonnal beütött a szemafor probléma. Felemeltem megint duplájára és igazán reméltem, hogy többet soha az életben nem látom ezt a hibát, és egy pár hétig tényleg béke volt, aztán megint beütött.
Egy újjabb emelés következett, most már hónapok óta nem jött a hiba.
Oktatás
A teljes csapatot JEE fejlesztőből spring fejlesztővé konvertálni... mivel a tét csillagászati, a legeslegelején megkértem mindenkit, hogy kérjen időt és eszközt átképzésre. Ezek az emberek mind különböző outsourcing cégek alkalmazottai, mint ahogy én is. A cég, ahol valójában évek óta dolgozunk, minden ilyen kérést azzal hárít, hogy a képzést az alkalmazó cégeknek kell állniuk.
Így történt, hogy egyáltalán senki sem kapott támogatást a munkaadójától. Se idő, se training. Ezek az outsourcing cégek büdös lófaszt nem érnek.
Egyébként a fejlesztők oldaláról pozitív meglepetés volt, hogy a saját idejükből igazán sokat rászántak, pedig gyakran hallottam videóhívások közben, hogy gyerek sír mellettük.
Tanulságok
- Legyen teljesítmény teszted. De ne csak hogy legyen teljesítmény-teszted, hanem olyan legyen, amit a fejlesztők tarthatnak karban és használhatnak a saját környezetükön. Sőt, fusson rendszeresen, és frekventáltan is, ha kell ha nem. Gatling vagy akár a rühes JMeter.
- Az jó, ha vannak integrációs tesztek a REST API-ra, de nem elég. Az sokkal fontosabb, hogy a felhasználó alkalmazásokra is legyenek integrációs tesztek.
- Széllel szembe pisilés:
- Évek óta próbálok változtatni azon a teszt-mentalításon, hogy ha egyszer működött a rendszer, akkor oké. Szerintem ha egyszer nem működött, akkor nem oké, álljunk meg és derítsük ki a hiba okát.
- Még mindig nem értem miért pazarolja bárki is a pénzét outsourcingra.
