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.
Citace od: hafan kdy 08. 09. 2018, 12:45:14
...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? ;-)
Citace od: Martin kdy 08. 09. 2018, 15:25:01
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
Citace od: BoneFlute kdy 09. 09. 2018, 22:20:53
Citace od: Martin kdy 08. 09. 2018, 15:25:01
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...
Citace od: kkt1 kdy 10. 09. 2018, 08:40:13
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.
Citace od: Kiwi kdy 10. 09. 2018, 11:58:40
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.
Citace od: Kiwi kdy 10. 09. 2018, 11:58:40
Citace od: BoneFlute kdy 09. 09. 2018, 22:20:53
Citace od: Martin kdy 08. 09. 2018, 15:25:01
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? ;)
Citace od: KB kdy 10. 09. 2018, 08:38:02
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)
Citace od: KB kdy 10. 09. 2018, 12:13:53
Citace od: kkt1 kdy 10. 09. 2018, 08:40:13
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...