Hlavní aplikace + Updater
- MichalHaltuf
- Bronze Partner | 14
Ahoj,
chtěl bych se zeptat na jeden obecný problém.
Už vícekrát jsem narazil na situaci, kdy jsem potřeboval mít hlavní aplikaci a k ní nějaké Workery/Updatery, které fyzicky běžely na jiném stroji (nebo v cloudu on-demand), sáhly si do databáze, provedly nějakou náročnou činnost (která by jinak zatěžovala hlavní server, což není žádoucí) a pak zase vrátily do databáze výsledek.
A jde mi teď, jestli takováto struktura má nějaké jméno. Hledám best-practice, jak takovou aplikaci navrhnout, spravovat, aktualizovat, automaticky testovat a nasazovat. Info třebas i v angličtině.
Zkoušel jsem jednu velkou aplikaci v jednom repozitáři. To je na jednu stranu fajn na údržbu a mentální kapacitu, na druhou stranu je pak na workerech spousta zbytečného kódu, nasazení a „rozběhnutí“ nové instance trvá dlouho.
Pak jsem zkusil základní věci rozsekat do balíčků (Model, Utils apod.), což ale už při poměrně malém počtu balíčků začíná být docela náročné na správu (třeba teď aktualizace na Nette 3.0 je u takové struktury docela na palici: main i worker mají aktuální verzi, v níž se stále musí řešit bugfixy, k nim mám paralelně vyvíjenou branch pro Nette 3.0, některé z bugfixů jsou relevantní i pro tuto novou verzi, některé no, no a to samé pro každý takový balíček…)
Nechci tu svým problémem nikoho příliš zdržovat, budu rád i za hinty ve stylu „tomuhle problému se říká XY a nejlépe ho popisuje A.Z. na svém blogu“. Omlouvám se dopředu, jestli řeším nějakou trivialitu, mnoho let jsem v PHP zaostával za vývojem a teď doháním všechny populární nástroje jako Git, CI, testování apod.
- Polki
- Člen | 553
Možná microservices. Nejspíš úplně neslouží k tomu co chceš,
protože ty by měly sloužit k přenesení logiky, která není nutné aby
byla součástí monolitu na samostatný server, kde běží a aplikace se na ni
dotazují.
Ty chceš aby se na ni nedotazovaly. Což jako problém nevidím. Je celkem
jedno, jestli se microservice spouští cronem, nebo dotazem hlavní
aplikace.
Jinak typickým příkladem na microservicu jsou například překlady jmen na 5 pád. Chceš to mít v každé aplikaci, ale nechceš kvůli tomu v každé aplikaci vytvářet databázovou tabulku s překlady, nechceš při updatu na jinou verzi Nette/PHP u každé aplikace navíc aktualizovat i tuto část atd.. Takže si uděláš aplikaci zvlášť, která přes API přijme jméno a vrátí jej v 5 pádě třeba i s informací, kdy má osoba svátek apod.
Jediný problém, na který můžeš narazit je, že microservicy by měly
obecně mít svou vlastní databázi, jinak ti mohou nastat problémy v tom,
že pokud se v původním monolitu změní databáze a microservice pracuje
s tou samou databází, tak by si musel napsat kódy migrací a aktualizovat
entity apod i na straně microservicy.
Tento problém pak hodně firem řeší tak, že si udělají ještě jednu
microservicu zvlášť, která řeší pouze přístup do db a má vlastní
rozhraní, které je friendly s každým. Tedy když se aktualizuje struktura
databáze, tak aktualizuješ pouze servicu, ve které novou strukturu
potřebuješ a servicu která se o tu databázi stará. Jediná ta nová
service má přístup do db takže je jediná, kde se musí dělat migrace
apod.
Jestli je toto řešení s microservice nad databází dobré či nikoliv je
diskutabilní. Nicméně se používá dost často.