YAMVM - ještě jeden monolit vs. mikroslužby

Autor: Erik Landerholm

Ahh ... otázka, se kterou všichni zápasíme: Mikroslužby nebo Monolit? Dobře, opravdu ne. Více než pravděpodobné, kdekoli budete pracovat, najdete příklady obou. Když jsme v TrueCar vyrazili na cestu z našeho datového centra do AWS, nechtěli jsme zvednout a posunout ... no ... nic. Abychom mohli využít výhod moderních nástrojů a procesů, potřebovali jsme přepsat celou aplikaci a podpůrný kód. Naším konečným cílem bylo dostat se z našich datových center do AWS a stát se agilním vývojovým týmem. Nakonec se CI / CD (což je další série blogových příspěvků, které brzy uvolníme) stane cílem, který by se mohli všichni shromáždit.

Toto téma rozdělíme na dvě části: proč a jak. Existuje již spousta blogových příspěvků, které obecně uvádějí, proč byste si mohli vybrat monolitické vs. SOA vs. mikroslužby. Chceme mluvit konkrétněji o tom, proč je pro nás monolitické rozhraní API napsané v Rails správné a „jak“ jsme se vyhnuli nebo minimalizovali některé z nevýhod monolitu (netěsné abstrakce atd.). Abychom to vyjasnili, Monolith API pro automatickou nákupní platformu (ABP) není jedinou základnou aplikací nebo kódů ve společnosti. Napomáhá však všem, se kterými zákazníci pracují na TrueCar.com, na našich 700+ partnerských webech, na všech našich prodejních nástrojích a na našich mobilních nabídkách.

Proč

Způsob, jakým byl dědictví ABP „architekturován“, to znemožnil. Potřebovali jsme úplně přepsat vše, co pohánělo TrueCar.com a naše 700+ partnerské weby, produkty prodejce a mobilní nabídky, a přesunout je do AWS a implementovat agilní vývojový proces. Podrobnosti o tom, proč to bylo nutné, jsou mimo rozsah tohoto blogového příspěvku. Zaměříme se na to, jak a proč jsme použili monolitický zadní konec, postavený s Ruby on Rails, aby byl tento proces co nejbolestnější.

Ať už stavíte aplikaci od nuly nebo přepisujete starší aplikaci, musíte přemýšlet a nakonec rozhodnout o architektuře založené na vaší filozofii, která je zase řízena mechanikou aplikace. Většina webových aplikací spadá do jednoho ze dvou táborů (právě teď zobecňuji hodně):

a) Velké množství provozu s relativně jednoduchým datovým modelem.

b) Menší provoz a relativně komplikovaný datový model.

TrueCar.com je více než b. Naše databáze bude našim úzkým hrdlem i u 700+ zaměstnanců a příjmů ve výši ~ 400 milionů $.

  • Naše tržiště je efektivní, ale komplikované.
  • Náš tým back-end vývojových týmů v desítkách, ne stovkách nebo tisících.
  • Data vozu jsou notoricky chaotická a hluboká, s mnoha úrovněmi vztahů, která se perfektně hodí k RDBMS.
  • Máme miliony uživatelů a několik milionů UV za měsíc, ale ne miliardy.

Když jsem začal v TrueCar v roce 2014, byl náš vývojový proces notoricky pomalý, s jediným nasazením každých osm dní. Rychle vpřed pět let a my děláme více než sto nasazení každý týden, s 98% kódovým pokrytím na naší nové zadní části ABP, postavené s Rails. Věděli jsme, že budeme schopni zajistit, aby naše API fungovala na přijatelné úrovni; to, co jsme potřebovali optimalizovat, byla rychlost vývojářů!

Výhody monolitu

Než budeme konkrétně hovořit o tom, jak jsme strukturovali náš monolit, abychom minimalizovali některé nevýhody základny monolitického kódu, pojďme mluvit o jeho výhodách. Jedním z největších (a nejvíce podceňovaných, dokud je již nemáte) vyhrává v monolitickém back-endu, který používá RDBMS, je schopnost používat JOINS. Představte si, že máte uživatelský model a chcete načíst všechna vozidla, na která se podívali. U monolitické databáze a aplikace je toho dosaženo jedním nebo více JOINS od Users -> Vehicles (ve skutečnosti je to složitější než to) namísto autentizace a autorizace a volání více služeb.

Můžete si myslet na JOINS jako na API mezi službami. Je zřejmé, že tento druh myšlení má určitá omezení, stejně jako v architektuře Microservice nemůžete provádět neomezené množství hovorů na různá API služeb. Tato síťová volání, vyhledávání, JSON (pravděpodobně by se musela přesunout od JSON pro komunikaci mezi službami) serializace atd., Pro více služeb nejsou zdarma.

Schopnost ověřovat a autorizovat, provádět volání API a shromažďovat všechna požadovaná data a organizovat je pro zobrazení uvnitř jediné služby (ABP) znamená, že si můžeme vybrat jazyk a rámec, který nám poskytuje nejvyšší produktivitu vývojáře, místo toho, abychom museli optimalizovat pro rychlost běhu. Mít nejrychleji se pohybující vývojáře je obrovskou konkurenční výhodou!

Kromě výše uvedených dvou velkých výhod existuje ještě mnohem více, když je celý váš kód a funkce na jednom místě:

  • Žádné závislosti na nasazení (peklo závislosti!): Která verze této služby je s touto službou kompatibilní? Sdílené knihovny nebo ne? Jak zjistím, jaké služby jsou dostupné a co přesně dělají? To je mnohem jednodušší u dobře zdokumentovaného a organizovaného monolitu - majestátního monolitu, pokud chcete.
  • Sledování chyb: Celé transakce jsou protokolovány z jednoho místa na jedno místo.
  • Testování: Máme 98% testovací pokrytí na Monolith a úplné testování integrace aplikací se provádí z našeho FE Monolith. Mít více než jeden Monolith není oxymoron!
  • Žádná sila: Pro vývojáře je velmi snadné pracovat na různých částech aplikace, protože je vše navrženo běžným způsobem, za použití stejných nástrojů a bez potřeby distribuovaných výpočetních znalostí.
  • Sdílený kód: Žádné sdílené knihovny nebo transakce „bez znalostí“, kde je spolu s každou žádostí odeslán celý rozsah potřebný pro fungování služby.
  • Průřezové obavy: Máme jich mnoho; pravděpodobně taky taky! Trávit spoustu času definováním služeb, které do sebe navzájem neunikají, je čas, který byste mohli věnovat budování věcí, které pomáhají zákazníkům!

Všechny výše uvedené výhody lze zmírnit nebo dokonce realizovat pomocí Microservices, ale přichází to za cenu. Tato cena je složitější vývoj, testování, monitorování a nasazení. Architektura microservices je jako XML (nebo násilí): používejte jej střídmě a pouze v případě, že je to skutečně nutné!

Nevýhody monolitu

V životě není nic svobodného ani dokonalého. Každé rozhodnutí má klady a zápory a vedlejší účinky, z nichž některé je obtížné nebo nemožné předvídat. Monolitická softwarová architektura se neliší. Zde jsou některé z nevýhod, o nichž budeme hovořit v našem příspěvku „how“:

  • Výkon: Toto je pravděpodobně nejvíce načtené ze všech „nevýhod“, protože je to také výhoda. Optimalizujeme naši databázi, hodně vyrovnáváme, používáme Sidekiq, abychom vytvořili vše, co můžeme asynchronizovat, a nakonec předáváme zprávy mimo monolit s něčím, čemu říkáme Wormhole (Enterprise Service Bus postavený na Kinesis).
  • Agility: Také výhoda Monolith, ale v závislosti na velikosti týmu, počtu služeb a rozsahu se to může stát nevýhodou. Váš vývojový proces může tento problém výrazně zmírnit.
  • Leakiness: Když píšete více a více funkcí do své monolitické kódové základny, je nevyhnutelné, že některé z nich nezůstanou ve svém pruhu. Abstrakce a funkčnost uniknou do dalších částí monolitu. Existují způsoby, jak to zmírnit, a my se do hloubky podíváme, jak se s tímto problémem vypořádáme. Odpovídajícím problémem v architektuře Microservices je to, že ve službách často duplikujete funkčnost a kód.
  • Testování: Mikroslužby vám umožňují izolovat vaše obavy uvnitř různých kódových základen. To má výhody při provádění testování jednotek, ale komplikace přicházejí během testování integrace.
  • Nasazení: Stejně jako testování, nasazení jedné služby je jednodušší a rychlejší než monolit složený z mnoha služeb, ale ďábel je v koordinaci, když máte mnoho služeb. To může být usnadněno v monolitech s dobrou izolací služeb / funkčnosti.

Doufejme, že vám to poskytne nějaký vhled do našeho uvažování o tom, proč jsme se rozhodli pro monotitickou architekturu back-end pro naše přepisování, na rozdíl od Microservices. Zůstaňte naladěni na náš příspěvek o tom, jak jsme to udělali. Myslím, že vám poskytne opravdu užitečný pohled na to, jak spravovat svůj vlastní Magnificent Monolith ™ (ochrannou známku, protože někdo už vzal Majestic ).

Zůstaňte naladěni na další splátku, vše o „Jak!“ Pokud se vám tento líbil, zamilujete si naše nadcházející příspěvky o Spacepodech (naše implementační platforma), CI / CD, Armatron (naše ETL platforma), Gluestick (náš FE framework) , postavený s React), Červí díra (naše ESB) a další!