Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: hafan 08. 09. 2018, 12:45:14
-
jake jsou nevyhody toho, kdyz je komplexni system rozdelen do co nejvice oddelenych procesu?
Napriklad mam tabulku v databazi a vyplneni kazde kolonky zajistuje jiny script s minimem funkcionalit a v jinem souboru?
jako velkou vyhodu vnimam ze kdyz selze jedena cast, tak vse ostatni bezi dal a pritom se to snadno debuguje
akorat zatim nevim jak to spravne cele centralne ridit a monitorovat
-
Jdes na to dobre, ale nemelo by se jednat o "soubory", spis o mikrosluzby. Cele to muzes pospojovat treba pres nejake RPC. Podstata je v izolaci jednotlivych casti. Pokud vymyslis neco noveho, tak to smeruj pak na rozlozeni zateze / clustering a taky moznost aktivace ruznych verzi urcite casti - tim si overis ze nova verze nepada a po pokusnem behu muzes prejit na vyssi verzi bez vypadku sluzby.
Ja podobne delal sw pro rizeni kamery - centralni spravce procesu na ktery se kazdy kousek pripojil skrze socket a data se presouvali skrze sdilenou pamet. Vyhoda byla ze kdyz padl jeden proces, neovlivnilo to ostatni casti - napr. chyba v rekorderu (at uz interni, nebo dusledek spatneho stavu systemu) nezpusobila pad live nahledu. Taky pak tam slo pripojovat dalsi sw soucasti temer dle libosti - za chodu.
-
...i a vyplneni kazde kolonky zajistuje jiny script s minimem funkcionalit a v jinem souboru?
kdyz to vyplneni jedne kolonky zavisi na tom, co je zapisuje do te jine ....
-
Takze mame formular, jedna sluzba na jmeno, druha na prijmeni,... na PSC radeji 2. Napsano pekne v jave, kazda sluzba aspon 500 MB RAM, ze...
Bastl muss sein.
BTW: nevite, jestli existuje neco jako .NET byte code interpret psany v jave? ;-)
-
Takze mame formular, jedna sluzba na jmeno, druha na prijmeni,... na PSC radeji 2. Napsano pekne v jave, kazda sluzba aspon 500 MB RAM, ze...
Bastl muss sein.
BTW: nevite, jestli existuje neco jako .NET byte code interpret psany v jave? ;-)
Chápu tvou nadsázku. Problém je v tom, že se míjíš se zadáním. Nebo chceš tvrdit, že je špatný psát robusní aplikace jen proto, že je to drahý? To spíše vymyslíme jak je psát, aby to nebylo drahý, ne?
V roce 86 ve firmě Ericsson tento problém zkoušeli řešit. A opravdu tam každá blbost má vlastní process. A je to malé a rychlé.
-
Nejprve si hosanci ujasnete rozdil mezi volanou funkci a procesem.
-
Mas tam uzke hrdlo. Co kdyz spadne DB ? Budou umet ty jednoduche skripty ci mikrosluzby v pripade potreby zapisovat jinde az DB je dolu ?
-
KB, u kritickych systemu DB nepada. Mas minimalne cluster, v idealnim pripade geocluster s x nody.
-
O tohle se snaží docela úspěšně Erlang, z rychlíku máš přehled třeba tady: https://dockyard.com/blog/2018/07/18/all-for-reliability-reflections-on-the-erlang-thesis
-
Takze mame formular, jedna sluzba na jmeno, druha na prijmeni,... na PSC radeji 2. Napsano pekne v jave, kazda sluzba aspon 500 MB RAM, ze...
Bastl muss sein.
BTW: nevite, jestli existuje neco jako .NET byte code interpret psany v jave? ;-)
Chápu tvou nadsázku. Problém je v tom, že se míjíš se zadáním. Nebo chceš tvrdit, že je špatný psát robusní aplikace jen proto, že je to drahý? To spíše vymyslíme jak je psát, aby to nebylo drahý, ne?
V roce 86 ve firmě Ericsson tento problém zkoušeli řešit. A opravdu tam každá blbost má vlastní process. A je to malé a rychlé.
A dnes už v Erlangu spíš jen udržují stará řešení, než že by v něm psali něco nového...
-
KB, u kritickych systemu DB nepada. Mas minimalne cluster, v idealnim pripade geocluster s x nody.
Jo a ted tu o Jenickovi a Marence :) DB nemusi nutne spadnout ale proste bude z nejakeho duvodu nedostupna. Obvykle nejaky maly dabelsky detail, treba exnute heslo ci certifikat. U robustniho systemu neexistuje predpoklad, ze neco pojede na 100% a neni se tam treba zabyvat nejakym fallbackem.
-
A dnes už v Erlangu spíš jen udržují stará řešení, než že by v něm psali něco nového...
Elixir je živý
-
KB, u robiustniho systemu pracujes dle itil, mas procesy a veci jako expirace certifikatu nebo heael mas osetrene. Muze se ti samozrejme stat ze konektivita vsech poskytovatelu ti selze, nebo cokoliv jineho vcetne toho co popisujes, ale delat fallback z db na nejake lokalni textaky nebo queue je nesmysl, nedostupnost sluzeb spravne propagujes na prislusne vstupne body a treba u api na vstupu odmitas nove pozadavky s tim ze sluzba neni dostupna atd. Resit to samozrejme muzes milion ruznymi zpusoby klidne i tim co jsi psal, ale v praxi se to resi propagaci nedostupnosti sluzby pokud k tomu uz dojde ze nemas kam ukladat vstupy ktere chces dal spracovavat.
-
Takze mame formular, jedna sluzba na jmeno, druha na prijmeni,... na PSC radeji 2. Napsano pekne v jave, kazda sluzba aspon 500 MB RAM, ze...
Bastl muss sein.
BTW: nevite, jestli existuje neco jako .NET byte code interpret psany v jave? ;-)
Chápu tvou nadsázku. Problém je v tom, že se míjíš se zadáním. Nebo chceš tvrdit, že je špatný psát robusní aplikace jen proto, že je to drahý? To spíše vymyslíme jak je psát, aby to nebylo drahý, ne?
V roce 86 ve firmě Ericsson tento problém zkoušeli řešit. A opravdu tam každá blbost má vlastní process. A je to malé a rychlé.
A dnes už v Erlangu spíš jen udržují stará řešení, než že by v něm psali něco nového...
I kdyby, no a?
-
DB je v cluster - tím myslím opravdický cluster ne jako ORACLE... takže nepadá.
Namátkou určitě Cassandra, ScyllaDB, MySQL NDB Cluster (snad i Fabric - nezkoušel jsem), Galera a podobné...
Stejně tak by měl vypadat i zbytek systému. Rozsekanej na malý služby, který dokážou pochopit, že nějaká jiná služba nefunguje (pokud není kritická) a pokud je - běží X krát najednou, takže je oslovuje naráz a nebo si prostě vybere.
Někdy spojuje několik odpovědí najednou aby odstínil chybu (porovná jejich výsledek).
Microservices s orchestrací, krásné je pokud se služby automaticky umí registrovat do systému za chodu.
Klíčové části běží 3+ krát a výpadek jednoho je odstíněný redundancí. Prostě normálka? Vy to tak neděláte? ;)
Mas tam uzke hrdlo. Co kdyz spadne DB ? Budou umet ty jednoduche skripty ci mikrosluzby v pripade potreby zapisovat jinde az DB je dolu ?
-
Tak největší riziko je vždycky administrátor a taky bych řekl, že téměř vždy stojí za pádem nějakého HA systému.
Prostě do toho hrabal :D a způsobil domino efekt, nebo záměrně riskoval aby ušetřil čas.
Nebo to prostě provozuje na hranici (5+ serverů je ideál, ale on chtěl jen 3 - pohybuje se tedy nad propastí aby ušetřil peníze)
KB, u kritickych systemu DB nepada. Mas minimalne cluster, v idealnim pripade geocluster s x nody.
Jo a ted tu o Jenickovi a Marence :) DB nemusi nutne spadnout ale proste bude z nejakeho duvodu nedostupna. Obvykle nejaky maly dabelsky detail, treba exnute heslo ci certifikat. U robustniho systemu neexistuje predpoklad, ze neco pojede na 100% a neni se tam treba zabyvat nejakym fallbackem.
-
No neviem, niektoré odpovede vyzerajú, akoby človek nikdy v praxi reálne systémy nevidel. Ak sa niečo má pokaziť, pokazí sa to vždy tým najneočakávanejším spôsobom.
A že ITIL, buhehehe... To som už videl veľakrát, a vždy si tam niekto niečo priohne, a SPOF je na svete...