Det verkar som att hightiden för mikrotjänster har passerat. Vi läser inte längre flera gånger i veckan inlägg med titlar som 'Hur jag migrerade min monolit till 150 tjänster'. Nu hör jag oftare mer fundamentala tankar: 'Jag hatar inte monoliten, jag bryr mig bara om effektivitet'. Vi har till och med bevittnat flera migrationer . När man går från en stor applikation till flera mindre tjänster måste man hantera ett antal nya problem. Låt oss räkna upp dem så kort som möjligt.
Installation: från grundläggande kemi till kvantmekanik
Att konfigurera en grundläggande databas och en applikation med en bakgrundsprocess var en ganska tydlig process. Jag publicerar readme på Github – och ofta inom en timme, max ett par timmar, fungerar allt, och jag kan påbörja ett nytt projekt. Att lägga till och köra koden, åtminstone för startmiljön, görs samma dag. Men om vi ger oss in på mikrotjänster skjuter den initiala starttiden i höjden. Ja, vi har nu Docker med orkestrering och en K8-kluster med maskiner, men för en nybörjare är allt detta betydligt mer komplicerat. För många juniorer är detta en börda som verkligen är onödig komplexitet.
Systemet är inte lätt att förstå
Låt oss stanna upp ett ögonblick med vår junior. Med monolitiska applikationer var det lätt att spåra ett fel och omedelbart påbörja felsökningen. Nu har vi en tjänst som kommunicerar med en annan tjänst, som lägger något i kö på en meddelandebuss, som hanterar en annan tjänst – och här uppstår ett fel. Vi måste sammanfoga alla dessa delar för att i slutändan få veta att tjänst A körs på version 11, medan tjänst E redan förväntar sig version 12. Detta skiljer sig starkt från min vanliga konsoliderade logg: jag måste använda en interaktiv terminal/felsökare för att gå igenom processen steg för steg. Felsökning och förståelse har blivit betydligt svårare.
Om det inte går att felsöka, kanske vi kan testa dem
Kontinuerlig integration och kontinuerlig utveckling blir allt mer vanligt. De flesta nya applikationer som jag ser automatiskt skapar och kör tester med varje ny release och kräver att testerna går igenom och granskas innan registreringen. Det är utmärkta processer som man inte bör avstå ifrån; de har blivit en stor förändring för många företag. Men nu, för att verkligen testa tjänsten, behöver jag köra en fullständig produktionsversion av min applikation. Kommer du ihåg den nya ingenjören med en K8-kluster av 150 tjänster? Tja, nu ska vi lära vårt CI-system att starta alla dessa system för att verifiera att allt verkligen fungerar. Det är förmodligen för mycket arbete, så vi kommer bara att testa varje del isolerat: jag är säker på att våra specifikationer är tillräckligt bra, API:erna är rena, och avbrottet i tjänsten är isolerat och påverkar inte andra.
Alla kompromisser har en god anledning. Eller hur?
Det finns många skäl att övergå till mikrotjänster. Jag har sett att det görs för större flexibilitet, för att skala team, för prestanda och för att säkerställa bättre driftsäkerhet. Men i verkligheten har vi investerat årtionden i verktyg och metoder för att utveckla monoliter, som fortsätter att utvecklas. Jag arbetar med yrkesverksamma inom olika teknologier. Oftast pratar vi om skalning, eftersom de står inför begränsningar med en enda Postgres-databasnod. Mycket av diskussionerna handlar om .
Men jag är alltid intresserad av deras arkitektur. I vilket skede av övergången till mikrotjänster befinner de sig? Det är intressant att se hur fler och fler ingenjörer säger att de är nöjda med sin monolitära applikation. Många kommer att dra nytta av mikrotjänster, och fördelarna kommer att överväga de hinder som finns på migrationsvägen. Men personligen föredrar jag gärna min monolitära applikation, en plats på stranden – och jag är helt lycklig.
Källa: habr.com
