Det verkar som att toppen av hypen för mikrotjänster ligger bakom oss. Vi läser inte längre inlägg flera gånger i veckan "Hur jag flyttade min monolit till 150 tjänster." Nu hör jag fler sunt förnuftstankar: "Jag hatar inte monoliten, jag bryr mig bara om effektivitet." Vi observerade till och med flera migrationer . När du går från en stor applikation till flera mindre tjänster måste du lösa flera nya problem. Låt oss lista dem så kortfattat som möjligt.
Inställning: från grundläggande kemi till kvantmekanik
Att skapa en grundläggande databas och applikation med en bakgrundsprocess var en ganska enkel process. Jag publicerar readme på Github - och ofta efter en timme, som mest ett par timmar, fungerar allt, och jag startar ett nytt projekt. Lägga till och köra kod, åtminstone för den initiala miljön, görs på dag ett. Men om vi vågar oss på mikrotjänster skjuter den initiala lanseringstiden i höjden. Ja, nu har vi Docker med orkestrering och ett kluster av K8-maskiner, men för en nybörjare är allt detta mycket mer komplicerat. För många juniorer är detta en börda som verkligen är en onödig komplikation.
Systemet är inte lätt att förstå
Låt oss fokusera på vår junior ett ögonblick. Med monolitiska applikationer, om ett fel inträffade, var det lätt att spåra det och omedelbart gå vidare till felsökning. Nu har vi en tjänst som pratar med en annan tjänst som köar något på en meddelandebuss som bearbetar en annan tjänst – och då uppstår ett fel. Vi måste sätta ihop alla dessa bitar för att så småningom ta reda på att Service A kör version 11, och Service E väntar redan på version 12. Detta skiljer sig mycket från min standardkonsoliderade logg: att behöva använda en interaktiv terminal/debugger för att gå genom processen steg för steg. Felsökning och förståelse har i sig blivit svårare.
Om det inte går att felsöka kanske vi testar dem
Kontinuerlig integration och kontinuerlig utveckling blir nu vardag. De flesta nya appar som jag ser skapar och kör automatiskt tester med varje ny version och kräver att tester tas och granskas innan registrering. Det här är fantastiska processer som inte bör överges och har varit ett stort skifte för många företag. Men nu, för att verkligen testa tjänsten, måste jag hämta en fullständig fungerande version av min applikation. Kommer du ihåg den nya ingenjören med K8-klustret med 150 tjänster? Nåväl, nu ska vi lära vårt CI-system hur man tar upp alla dessa system för att verifiera att allt verkligen fungerar. Det här är förmodligen för mycket ansträngning, så vi kommer bara att testa varje del isolerat: jag är övertygad om att våra specifikationer är tillräckligt bra, API:erna är rena och ett servicefel är isolerat och kommer inte att påverka andra.
Alla kompromisser har en bra anledning. Höger?
Det finns många skäl att gå över till mikrotjänster. Jag har sett detta göras för större flexibilitet, för att skala team, för prestanda, för att ge bättre hållbarhet. Men i verkligheten har vi investerat årtionden i verktyg och metoder för att utveckla monoliter som fortsätter att utvecklas. Jag arbetar med proffs inom olika tekniker. Vi brukar prata om skalning eftersom de går in i gränserna för en enda Postgres-databasnod. De flesta samtalen handlar om .
Men jag är alltid intresserad av att lära mig om deras arkitektur. Vilket skede av övergången till mikrotjänster befinner de sig i? Det är intressant att se fler ingenjörer säga att de är nöjda med sin monolitiska applikation. Många människor kommer att dra nytta av mikrotjänster, och fördelarna kommer att uppväga stötarna i migrationsvägen. Men personligen, snälla ge mig min monolitiska ansökan, en plats på stranden - och jag är helt nöjd.
Källa: will.com