Splitting Monolithic Rails Application till Microservices

I takt med att en verksamhet blir större kräver de fler funktionaliteter och därmed kan man inte låta bli att lägga till nya modeller/kontroller till den befintliga Rails-applikationen och ibland blir det en monolit. Om du står inför en monolitapplikation som har blivit ounderhållbar och svår att distribuera, måste du känna till några sätt att hantera den. Om ditt team måste gå igenom tusentals rader för att förstå projektet och göra några ändringar, är det dags att dela upp dem.

När ska man dela applikationen

• När dina tester pågår i mer än 20 minuter.
• Modeller vuxit till flera hundra eller tusentals.
• Oberoende funktionalitet.
• När utvecklare inte kan arbeta självständigt för att utveckla/distribuera sina egna moduler.

Olika sätt att dela monolitisk applikation

• Använder mikrotjänster.
• Använder "snabbare" tekniker.
• Lägg till ett gäng servrar.

Vad är microservice                                                                                                                                           Microservices är ett strategiskt sätt att bryta upp ett stort projekt i mindre, mer hanterbara delar. En mikrotjänst är en del av applikationsfunktionalitet som omarbetas till sin egen kodbas och talar till andra mikrotjänster över ett standardprotokoll. För att uppnå detta, dela först upp dina affärskrav i relaterade grupper som användarhanteringslogik, reklamlogik och ett webbanvändargränssnitt.

Varför mikroservice
Den första kraften som ledde till ökningen av mikrotjänster var en reaktion mot normal monolitisk arkitektur. Medan en monolitisk app är One Big Program med många ansvarsområden, är mikrotjänstbaserade applikationer sammansatta av mindre program, vart och ett med ett enda ansvar. Detta gör att team av utvecklare kan arbeta oberoende på olika tjänster. Den inneboende frikopplingen uppmuntrar också mindre, enklare program som är lättare att förstå, så att nya utvecklare kan börja bidra snabbare. Slutligen, eftersom inget enskilt program representerar hela applikationen, kan tjänster ändra riktning utan stora kostnader. Om ny teknik blir tillgänglig som är mer meningsfull för en viss tjänst, är det möjligt att skriva om just den tjänsten. På samma sätt, eftersom mikrotjänster kommunicerar över olika språk, kan en applikation vara sammansatt av flera olika plattformar – Ruby, Java, PHP, Node, Go, etc utan problem.

Fördelar

• Moduler kan återanvändas.
• Implementeringen går smidigt oberoende av hela stora applikationer.
• Lätt att lägga till funktioner.
• Minskar testtiden för att testa en modul istället för alla.
• Stora applikationer tenderar att vara svårare att underhålla än de små.
• Genom att ha små applikationer kan vi fokusera på att arbeta med isolerade delar.
• Vi kanske har större chans att inte bryta andra delar av applikationen.
• Tillförlitlighet och feltolerans.
• Lätt att migrera eller uppgradera.
• Teknikens mångfald.
• Om någon enskild applikationsfunktion inte fungerar försvinner inte hela applikationen.
• Gör det lättare för en ny utvecklare att förstå funktionaliteten hos en tjänst.

Nackdelar
Because everything is now an independent service, you have to handle requests carefully travelling between your modules. There can be a scenario where any of services may not be responding.
Multiple databases and transaction management can be painful.
Productivity will be less till the microservice base is set.

Monolithic v/s Microservices
Diagrammet nedan visar skillnaden mellan traditionell monolitisk app och mikrotjänster när det gäller mänskliga resurser, tid, underhåll och hanteringskomplexitet för applikationer.

Hur man ställer in mikrotjänster
Strategiskt sätt att krympa den monolitiska applikationen är att dela upp lager som presentation, affärslogik och dataåtkomstlager. En typisk företagsapplikation består av minst tre olika typer av komponenter:

• Presentation layer – Components that handle HTTP requests and implement either a (REST) API or an
  HTML-based web UI. In an application that has a sophisticated user interface.
• Affärslogiklager – Komponenter som är kärnan i applikationen där affärsregler implementeras.
• Dataåtkomstlager – Komponenter som har tillgång till infrastrukturkomponenter som databaser och meddelandeförmedlare.

RailsCarma har implementerat Ruby on Rails-applikationer från dess begynnande skeden för utveckling, utbildning, distribution och bidrag tillbaka till Rails Community. Genom pålitlig teknisk expertis och fulländad kundservice kombinerat för att leverera en härlig upplevelse för kunder, erbjuder RailsCarma från början till slut Ruby on Rails Development ,konsulttjänster, arkitektur, management och förlängning till företag runt om i världen. Kontakta oss för att veta mer.