Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: harrison314 05. 07. 2018, 21:34:19
-
Pocslenu dobu si vsimam pardoxu mikrosluzieb.
Ake maju byt vlastne velke?
Lebo ludia od Go a javascriptu tlacia mirksoluzby pomaly na urovni funkcii.
Potom je tu java,.Net Core,... (proste typove sa solidne jazyky), kde kde sa bez problemov da spravit velka aplikacia, tam sa presadzuju mikrosluzby o dost vetcie a mohutnejsie.
-
Fowler pise:
https://www.martinfowler.com/articles/microservices.html#CharacteristicsOfAMicroserviceArchitecture
How big is a microservice?
Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services.
This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn't be lumped under one microservices label. At the moment we think it's better to group them together, but it's certainly possible that we'll change our mind as we explore this style further.
-
Byl jsem asi pred 3 lety na konferenci, kde Antonio Goncalvez rikal, ze za velikostni limit microservice povazuje 30MB. Byla to konference prevazne o jave.
-
Byl jsem asi pred 3 lety na konferenci, kde Antonio Goncalvez rikal, ze za velikostni limit microservice povazuje 30MB. Byla to konference prevazne o jave.
Co to je mikroservice? V minulem tematu jsem byl poucen, ze SOA není to samé co microservices. Já asi nevím, co to microservices jsou, a vlastně mě to ani nezajímá. Dělám ve Springu, tam máme SOA a velikost sluzeb je taková, aby na ni stačil jeden tým rozumné velikosti a aby aspoň trochu respektovala single responsibility princip.
-
Ono můžeš to dělat jak malé chceš, ale limitace je to, že komunikace mezi službama je oser. Takže když na každou kokotinu budeš dělat službu, tak si přiděláváš práci kvůli tomu, že k ni budeš muset dělat api.
-
A nejen že komunikace mezi službama je oser, ale přiděláváš si i další práci: další log soubory, žraní paměti a času při spouštění redundantních knihoven co musí vždycky naběhnout nehledě na velikost služby, samostatné repozitáře mezi kterma budeš muset jako pako pořád překlikávat a vytvářet totožné branche kvůli novým funkcionalitám, několik spuštěných IDEček naráz, zvyšovat verze v několika různých POMkách namísto jednoho, u debugování budeš muset nasázet několik breakpointů namísto jednoho a stejně ztratíš stacktrace napříč službama atd.
Když potřebuješ dát nějaký celek zvlášť, stačí udělat nový maven modul. Na vývoj stejně můžeš použít JRebel, takže nemusíš pořád restartovat celý moloch.
Prostě ta velikost služeb bude záviset na použitých technologiích, já nevím jak to mají v Javascriptu, ale v Javě určitě pidislužby dělat nechceš.
-
A nejen že komunikace mezi službama je oser, ale přiděláváš si i další práci: další log soubory, žraní paměti a času při spouštění redundantních knihoven co musí vždycky naběhnout nehledě na velikost služby, samostatné repozitáře mezi kterma budeš muset jako pako pořád překlikávat a vytvářet totožné branche kvůli novým funkcionalitám, několik spuštěných IDEček naráz, zvyšovat verze v několika různých POMkách namísto jednoho, u debugování budeš muset nasázet několik breakpointů namísto jednoho a stejně ztratíš stacktrace napříč službama atd.
Když potřebuješ dát nějaký celek zvlášť, stačí udělat nový maven modul. Na vývoj stejně můžeš použít JRebel, takže nemusíš pořád restartovat celý moloch.
Prostě ta velikost služeb bude záviset na použitých technologiích, já nevím jak to mají v Javascriptu, ale v Javě určitě pidislužby dělat nechceš.
Takhle to vypadá, když se microservice použije tam, kde to nedává smysl. IMHO microservice má smysl tam, kde výhody toho, že si microservice žije svým životem, převyšují náklady na správu a vývoj té celé infrastruktury mikroslužeb.
-
Lebo ludia od Go
V Go se píšou monolity, ale výsledkem je malá binárka, nikoliv bajtkód vyžadující gigabajtovou JVM.
-
Lebo ludia od Go
V Go se píšou monolity, ale výsledkem je malá binárka, nikoliv bajtkód vyžadující gigabajtovou JVM.
Gigabytovou? Neboj se a uber.
-
No, tak ten golang ma sice pri hello world prikladoch mensie poziadavky na pamat, ale zasa po skompilovani uz prestava byt multiplatformny. Aj na to treba pamatat. Ked "microservicy" riesim v spring boot s embednutym jetty mam k dispozicii obrovsky ekosystem javy. Spring boot som uz bezal aj na rpi1 a nejaky tragicky memory footprint to nemalo. (okolo 100mb)
Osobne by som taketo veci ked uz tak riesil v haskelli.
-
Lebo ludia od Go
V Go se píšou monolity, ale výsledkem je malá binárka, nikoliv bajtkód vyžadující gigabajtovou JVM.
Protože to Go a Javascript a další ftákoviny, to je takové ukulele. Jasně, někteří lidi na něj umí a libujou si, že i s malým kašpárkem se dá zahrát velké divadlo, což pravidelně předvádějí když lepí weby. Ale Java, to je to orchestr, to si hoši uvědomte, jasně že na ty vaše webové srágory je to overkill 8)
https://www.youtube.com/watch?v=EAFtiUoq6TE
-
Lebo ludia od Go
V Go se píšou monolity, ale výsledkem je malá binárka, nikoliv bajtkód vyžadující gigabajtovou JVM.
Protože to Go a Javascript a další ftákoviny, to je takové ukulele. Jasně, někteří lidi na něj umí a libujou si, že i s malým kašpárkem se dá zahrát velké divadlo, což pravidelně předvádějí když lepí weby. Ale Java, to je to orchestr, to si hoši uvědomte, jasně že na ty vaše webové srágory je to overkill 8)
https://www.youtube.com/watch?v=EAFtiUoq6TE
Tu je rec skor o servisne orientovanej architekture, nez o lepeni webov. Za to, ze ma nieco vystup json, alebo xml, google protocol buffers (atd ...) nemusi to hned byt web-ka. Proste su to protokoly na vymenu dat a bezne sa pouzivaju medzi modulmi vacsich informacnych systemov.
-
No, tak ten golang ma sice pri hello world prikladoch mensie poziadavky na pamat, ale zasa po skompilovani uz prestava byt multiplatformny. Aj na to treba pamatat.
Po kompilaci nás multiplatformita přestává zajímat.
Ked "microservicy" riesim v spring boot s embednutym jetty mam k dispozicii obrovsky ekosystem javy. Spring boot som uz bezal aj na rpi1 a nejaky tragicky memory footprint to nemalo. (okolo 100mb)
100 MB je hodně - jsem zvyklý na footprint aplikace v PHP do 10 MB. Víc obvykle není třeba, pokud aplikace není napsána extra blbě nebo se PHP neprovozuje v režimu webserver.
-
No, tak ten golang ma sice pri hello world prikladoch mensie poziadavky na pamat, ale zasa po skompilovani uz prestava byt multiplatformny. Aj na to treba pamatat.
Po kompilaci nás multiplatformita přestává zajímat.
Ked "microservicy" riesim v spring boot s embednutym jetty mam k dispozicii obrovsky ekosystem javy. Spring boot som uz bezal aj na rpi1 a nejaky tragicky memory footprint to nemalo. (okolo 100mb)
100 MB je hodně - jsem zvyklý na footprint aplikace v PHP do 10 MB. Víc obvykle není třeba, pokud aplikace není napsána extra blbě nebo se PHP neprovozuje v režimu webserver.
Malá data, malé problémy -> malý footprint.
-
Ked "microservicy" riesim v spring boot s embednutym jetty mam k dispozicii obrovsky ekosystem javy. Spring boot som uz bezal aj na rpi1 a nejaky tragicky memory footprint to nemalo. (okolo 100mb)
100 MB je hodně - jsem zvyklý na footprint aplikace v PHP do 10 MB. Víc obvykle není třeba, pokud aplikace není napsána extra blbě nebo se PHP neprovozuje v režimu webserver.
Ta php aplikacia ma uz v sebe v tomto pripade embednuty webserver? ( a ak nie, je zaratany do tejto spotreby?)
Nerypem, len sa pytam, v pripade, ze by som mal po ruke php-ckara a potreboval nieco riesit.
-
Byl jsem asi pred 3 lety na konferenci, kde Antonio Goncalvez rikal, ze za velikostni limit microservice povazuje 30MB. Byla to konference prevazne o jave.
Velkost aplikacie v MB je podla mna dost blba metrika na mirkosluzbu.
No, tak ten golang ma sice pri hello world prikladoch mensie poziadavky na pamat, ale zasa po skompilovani uz prestava byt multiplatformny. Aj na to treba pamatat.
Po kompilaci nás multiplatformita přestává zajímat.
Ked "microservicy" riesim v spring boot s embednutym jetty mam k dispozicii obrovsky ekosystem javy. Spring boot som uz bezal aj na rpi1 a nejaky tragicky memory footprint to nemalo. (okolo 100mb)
100 MB je hodně - jsem zvyklý na footprint aplikace v PHP do 10 MB. Víc obvykle není třeba, pokud aplikace není napsána extra blbě nebo se PHP neprovozuje v režimu webserver.
10MB na PHP to urcite nie, ked ide o nejaku aplikaciu co daco robi tak to zacina pri 70 MB, ale mozno sa daco zmenilo s PHP som uz nerobil 5 rokov.
-
100 MB je hodně - jsem zvyklý na footprint aplikace v PHP do 10 MB. Víc obvykle není třeba, pokud aplikace není napsána extra blbě nebo se PHP neprovozuje v režimu webserver.
Ta php aplikacia ma uz v sebe v tomto pripade embednuty webserver? ( a ak nie, je zaratany do tejto spotreby?)
Nerypem, len sa pytam, v pripade, ze by som mal po ruke php-ckara a potreboval nieco riesit.
Ano, je to včetně toho webserveru, i když samozřejmě záleží na jeho konfiguraci. Bez něj by to bylo ještě méně. Je však stále dost jiných jazyků, které mají footprint méně než desetinový oproti PHP. Zpravidla platí, že čím menší footprint, tím je rychlejší a obslouží více požadavků za jednotku času.
Provozovat PHP jako webserver se však doporučuje pouze v bezpečném prostředí, například při vývoji aplikace. Někdy jich mívám spuštěných i pět současně a ničemu to nevadí. Podobnou službu nabízí třeba i Python nebo Node.js
-
Ked "microservicy" riesim v spring boot s embednutym jetty mam k dispozicii obrovsky ekosystem javy. Spring boot som uz bezal aj na rpi1 a nejaky tragicky memory footprint to nemalo. (okolo 100mb)
100 MB je hodně - jsem zvyklý na footprint aplikace v PHP do 10 MB. Víc obvykle není třeba, pokud aplikace není napsána extra blbě nebo se PHP neprovozuje v režimu webserver.
10MB na PHP to urcite nie, ked ide o nejaku aplikaciu co daco robi tak to zacina pri 70 MB, ale mozno sa daco zmenilo s PHP som uz nerobil 5 rokov.
Pokud se v aplikaci mezi sebou dohaduje pět frameworků, což je dnes docela běžné, tak bych těm 70 MB i věřil. Ovšem to vůbec neznamená, že ta aplikace něco dělá. Funkční aplikace bývají mnohem menší, microservice si vystačí i s desetinou.
-
Zpravidla platí, že čím menší footprint, tím je rychlejší a obslouží více požadavků za jednotku času.
To nie je celkom tak pravda, ono zavisi skor od toho, ako zvlada dotycna aplikacia paralelizmus.
-
Byl jsem asi pred 3 lety na konferenci, kde Antonio Goncalvez rikal, ze za velikostni limit microservice povazuje 30MB. Byla to konference prevazne o jave.
Velkost aplikacie v MB je podla mna dost blba metrika na mirkosluzbu.
Správná velikost mikroslužby je maximálně 2 metry ;D
-
Byl jsem asi pred 3 lety na konferenci, kde Antonio Goncalvez rikal, ze za velikostni limit microservice povazuje 30MB. Byla to konference prevazne o jave.
Velkost aplikacie v MB je podla mna dost blba metrika na mirkosluzbu.
Správná velikost mikroslužby je maximálně 2 metry ;D
Mirkosluzba ma 2 metry, mikrosluzba je ponekud mensi :)
-
Zpravidla platí, že čím menší footprint, tím je rychlejší a obslouží více požadavků za jednotku času.
To nie je celkom tak pravda, ono zavisi skor od toho, ako zvlada dotycna aplikacia paralelizmus.
Čím je aplikace v PHP menší, tím víc jich může být spuštěných paralelně, tím víc obslouží požadavků. Čím je aplikace v PHP menší, tím kratší dobu běží a tím víc obslouží požadavků. Cílem tedy je, aby mikroslužby byly skutečně mikro, aby obsluha požadavku netrvala víc než cca 100 ms. Delší časy už jen zatěžují prostředky serveru.
-
Zpravidla platí, že čím menší footprint, tím je rychlejší a obslouží více požadavků za jednotku času.
To nie je celkom tak pravda, ono zavisi skor od toho, ako zvlada dotycna aplikacia paralelizmus.
Čím je aplikace v PHP menší, tím víc jich může být spuštěných paralelně, tím víc obslouží požadavků. Čím je aplikace v PHP menší, tím kratší dobu běží a tím víc obslouží požadavků. Cílem tedy je, aby mikroslužby byly skutečně mikro, aby obsluha požadavku netrvala víc než cca 100 ms. Delší časy už jen zatěžují prostředky serveru.
Čím je aplikace v PHP menší, tím méně sní brambor a víc se jich vejde na pec.
-
Zpravidla platí, že čím menší footprint, tím je rychlejší a obslouží více požadavků za jednotku času.
To nie je celkom tak pravda, ono zavisi skor od toho, ako zvlada dotycna aplikacia paralelizmus.
Čím je aplikace v PHP menší, tím víc jich může být spuštěných paralelně, tím víc obslouží požadavků. Čím je aplikace v PHP menší, tím kratší dobu běží a tím víc obslouží požadavků. Cílem tedy je, aby mikroslužby byly skutečně mikro, aby obsluha požadavku netrvala víc než cca 100 ms. Delší časy už jen zatěžují prostředky serveru.
To tiez nie je celkom pravda, nie je podstatne, kolko sa toho vykona, ale ako rychlo sa to vykona.
-
Lebo ludia od Go
V Go se píšou monolity, ale výsledkem je malá binárka, nikoliv bajtkód vyžadující gigabajtovou JVM.
Gigabytovou? Neboj se a uber.
0.86 Gigabajtovout?
-
A co se tím vlastně müslí, tou Mirčinou službou?
-
Čím je aplikace v PHP menší, tím víc jich může být spuštěných paralelně, tím víc obslouží požadavků. Čím je aplikace v PHP menší, tím kratší dobu běží a tím víc obslouží požadavků. Cílem tedy je, aby mikroslužby byly skutečně mikro, aby obsluha požadavku netrvala víc než cca 100 ms. Delší časy už jen zatěžují prostředky serveru.
To tiez nie je celkom pravda, nie je podstatne, kolko sa toho vykona, ale ako rychlo sa to vykona.
O tom právě píši, že je potřebné, aby doba odezvy byla co nejkratší.
-
Čím je aplikace v PHP menší, tím víc jich může být spuštěných paralelně, tím víc obslouží požadavků. Čím je aplikace v PHP menší, tím kratší dobu běží a tím víc obslouží požadavků. Cílem tedy je, aby mikroslužby byly skutečně mikro, aby obsluha požadavku netrvala víc než cca 100 ms. Delší časy už jen zatěžují prostředky serveru.
To tiez nie je celkom pravda, nie je podstatne, kolko sa toho vykona, ale ako rychlo sa to vykona.
O tom právě píši, že je potřebné, aby doba odezvy byla co nejkratší.
No, ale nie je pravda, ze cim je aplikacia mensia, tym je vykonanie poziadavky rychlejsie. Moze byt aplikacia mensia a obsahovat "naivny" kod. (Naivny je moj nazov pre kod, ktory je priamociaro a jednoducho napisany). Potom moze byt aplikacia, co obsahuje komplikovany kod, ktory je vsak plny roznych vychytavok, ktore napokon podstatne skratia vykonanie.
-
No, ale nie je pravda, ze cim je aplikacia mensia, tym je vykonanie poziadavky rychlejsie. Moze byt aplikacia mensia a obsahovat "naivny" kod. (Naivny je moj nazov pre kod, ktory je priamociaro a jednoducho napisany). Potom moze byt aplikacia, co obsahuje komplikovany kod, ktory je vsak plny roznych vychytavok, ktore napokon podstatne skratia vykonanie.
Bohužel mám zkušenost, že komplikovaný kód s různými vychytávkami obvykle prodlužuje dobu zpracování. Často mi stačí udělat kvalitně zapouzdření objektů. Kód se tím nejen významně zkrátí, ale i zrychlí.
-
Lebo ludia od Go
V Go se píšou monolity, ale výsledkem je malá binárka, nikoliv bajtkód vyžadující gigabajtovou JVM.
Gigabytovou? Neboj se a uber.
0.86 Gigabajtovout?
Jde o GBV, gigabytevolt, analogicky k MeV například.
-
No, ale nie je pravda, ze cim je aplikacia mensia, tym je vykonanie poziadavky rychlejsie. Moze byt aplikacia mensia a obsahovat "naivny" kod. (Naivny je moj nazov pre kod, ktory je priamociaro a jednoducho napisany). Potom moze byt aplikacia, co obsahuje komplikovany kod, ktory je vsak plny roznych vychytavok, ktore napokon podstatne skratia vykonanie.
Bohužel mám zkušenost, že komplikovaný kód s různými vychytávkami obvykle prodlužuje dobu zpracování. Často mi stačí udělat kvalitně zapouzdření objektů. Kód se tím nejen významně zkrátí, ale i zrychlí.
Pokud neco prodluzuje dobu zpracovani, tak je to prave "dobre zapouzdreni objektu". Rycheji to bezi, kdyz se kod napise vhodnym zpusobem multiparadigmovo.
-
Malá mikroservisa zrychlí její start, deployment apod. Jinak to není zase tak dramatické... já bych to zase tolik neprožíval, prostě to beru jako soubor funkcionalit, které patří k sobě a jsou správně oddělitelné (jakože správná granularita služeb).
Takže jedna mirkoservisa poskytuje X funkcionalit, a zabírá od 50MB-2GB :) - pokud to je nějaká vobludná analytika s umělou inteligencí dohromady.
-
Bohužel mám zkušenost, že komplikovaný kód s různými vychytávkami obvykle prodlužuje dobu zpracování. Často mi stačí udělat kvalitně zapouzdření objektů. Kód se tím nejen významně zkrátí, ale i zrychlí.
Pokud neco prodluzuje dobu zpracovani, tak je to prave "dobre zapouzdreni objektu". Rycheji to bezi, kdyz se kod napise vhodnym zpusobem multiparadigmovo.
Prodlužování doby zpracování často mívají na svědomí gettery a settery, ale nikoli zapouzdření.
-
Takže jedna mirkoservisa poskytuje X funkcionalit, a zabírá od 50MB-2GB :)
50MB je celkom vela. Moze to byt kludne 452 bytov (extremny pripad), ak si makac a je to hello word mikroservice https://blog.hypriot.com/post/build-smallest-possible-docker-image/. Myslim, vsak ze to zacina od 5MB - to su moje staticky kompilovane, stripovane Go veci. a to este mozes binarku kompresnut cez upx a pod.
-
Bohužel mám zkušenost, že komplikovaný kód s různými vychytávkami obvykle prodlužuje dobu zpracování. Často mi stačí udělat kvalitně zapouzdření objektů. Kód se tím nejen významně zkrátí, ale i zrychlí.
Pokud neco prodluzuje dobu zpracovani, tak je to prave "dobre zapouzdreni objektu". Rycheji to bezi, kdyz se kod napise vhodnym zpusobem multiparadigmovo.
Prodlužování doby zpracování často mívají na svědomí gettery a settery, ale nikoli zapouzdření.
Gettre, settre az tak nespomaluju, tie len zbytocne zvacsuju objem zdrojovych kodov . Problem je skor s boilerplate objektovym kodom a manazmentom objektov, ktory pri multiparadigmovom navrhu nemusi existovat.
-
Prodlužování doby zpracování často mívají na svědomí gettery a settery, ale nikoli zapouzdření.
Gettre, settre az tak nespomaluju, tie len zbytocne zvacsuju objem zdrojovych kodov . Problem je skor s boilerplate objektovym kodom a manazmentom objektov, ktory pri multiparadigmovom navrhu nemusi existovat.
To by ses divil, jaký výkonnostní dopad má zpracování dat objektu mimo ten objekt.
O boilerplates nebyla řeč a managementu objektů také ne. Je fakt, že hodně výkonu se dá ušetřit vypnutím GC, je to užitečné hlavně v PHP.
-
Prodlužování doby zpracování často mívají na svědomí gettery a settery, ale nikoli zapouzdření.
Gettre, settre az tak nespomaluju, tie len zbytocne zvacsuju objem zdrojovych kodov . Problem je skor s boilerplate objektovym kodom a manazmentom objektov, ktory pri multiparadigmovom navrhu nemusi existovat.
To by ses divil, jaký výkonnostní dopad má zpracování dat objektu mimo ten objekt.
O boilerplates nebyla řeč a managementu objektů také ne. Je fakt, že hodně výkonu se dá ušetřit vypnutím GC, je to užitečné hlavně v PHP.
Kite, on nekdo vazne pouziva PHP na nejake high performance/high volume veci?
-
Bohužel mám zkušenost, že komplikovaný kód s různými vychytávkami obvykle prodlužuje dobu zpracování. Často mi stačí udělat kvalitně zapouzdření objektů. Kód se tím nejen významně zkrátí, ale i zrychlí.
Pokud neco prodluzuje dobu zpracovani, tak je to prave "dobre zapouzdreni objektu". Rycheji to bezi, kdyz se kod napise vhodnym zpusobem multiparadigmovo.
Prodlužování doby zpracování často mívají na svědomí gettery a settery, ale nikoli zapouzdření.
Ta tvoje obcese accessory see vzala kde?
-
Kite, on nekdo vazne pouziva PHP na nejake high performance/high volume veci?
Jistě, divil by ses. PHP není zas tak pomalé, jak se nám některé benchmarky snaží namluvit. Také se velmi dobře škáluje. Pokud se však budeš snažit střelit do nohy, nebude ti v tom bránit.
Pokud skutečně budu potřebovat high performance typu drcení čísel, tak to napíši ve Fortranu, případně si z PHP zavolám aplikaci nebo službu, která mi to spočítá.
-
Prodlužování doby zpracování často mívají na svědomí gettery a settery, ale nikoli zapouzdření.
Ta tvoje obcese accessory see vzala kde?
Když si přečteš pár knížek, které se věnují OOP (R. C. Martin, Martin Fowler, Bruce Eckel,...) tak na to možná přijdeš.
-
Bohužel mám zkušenost, že komplikovaný kód s různými vychytávkami obvykle prodlužuje dobu zpracování. Často mi stačí udělat kvalitně zapouzdření objektů. Kód se tím nejen významně zkrátí, ale i zrychlí.
Pokud neco prodluzuje dobu zpracovani, tak je to prave "dobre zapouzdreni objektu". Rycheji to bezi, kdyz se kod napise vhodnym zpusobem multiparadigmovo.
Prodlužování doby zpracování často mívají na svědomí gettery a settery, ale nikoli zapouzdření.
;D
Pokud si to dobře pamatuju, tak díky zapouzdření se k datům objektu nedostaneš jinak, než třeba pomocí těch get/set-rů...
-
;D
Pokud si to dobře pamatuju, tak díky zapouzdření se k datům objektu nedostaneš jinak, než třeba pomocí těch get/set-rů...
No a díky zapouzdření taky není úplně jednoduché poznat zvenku jestli je to jen get/set-ter, nebo to dělá i něco víc. Ono se to dokonce může v průběhu času i měnit.
-
Prodlužování doby zpracování často mívají na svědomí gettery a settery, ale nikoli zapouzdření.
Pokud si to dobře pamatuju, tak díky zapouzdření se k datům objektu nedostaneš jinak, než třeba pomocí těch get/set-rů...
Metody, které pracuji s daty objektu, dám dovnitř toho objektu. Říká se tomu zapouzdření.
-
Prodlužování doby zpracování často mívají na svědomí gettery a settery, ale nikoli zapouzdření.
Ta tvoje obcese accessory see vzala kde?
Když si přečteš pár knížek, které se věnují OOP (R. C. Martin, Martin Fowler, Bruce Eckel,...) tak na to možná přijdeš.
Ciwe neuč orla létat.
(Btw z téhle trojky nakonec stojí za to jenom Fowler, i když přes ty další dva se stejně musí zamlada prokousat každý.)
-
Prodlužování doby zpracování často mívají na svědomí gettery a settery, ale nikoli zapouzdření.
Ta tvoje obcese accessory see vzala kde?
Když si přečteš pár knížek, které se věnují OOP (R. C. Martin, Martin Fowler, Bruce Eckel,...) tak na to možná přijdeš.
Ciwe neuč orla létat.
(Btw z téhle trojky nakonec stojí za to jenom Fowler, i když přes ty další dva se stejně musí zamlada prokousat každý.)
Není třeba, aby ses učil létat. Stačí, když se naučíš číst.
Fowler je z nich skutečně nejlepší, ale pokud ho chceš pochopit, musíš si přečíst i zbývající dva autory.
-
(Btw z téhle trojky nakonec stojí za to jenom Fowler, i když přes ty další dva se stejně musí zamlada prokousat každý.)
https://martinfowler.com/bliki/GetterEradicator.html (https://martinfowler.com/bliki/GetterEradicator.html)
-
(Btw z téhle trojky nakonec stojí za to jenom Fowler, i když přes ty další dva se stejně musí zamlada prokousat každý.)
https://martinfowler.com/bliki/GetterEradicator.html (https://martinfowler.com/bliki/GetterEradicator.html)
"There are too many times when objects do need to collaborate by exchanging data, which leads to genuine needs for getters." - to zní rozumně
-
(Btw z téhle trojky nakonec stojí za to jenom Fowler, i když přes ty další dva se stejně musí zamlada prokousat každý.)
https://martinfowler.com/bliki/GetterEradicator.html (https://martinfowler.com/bliki/GetterEradicator.html)
"There are too many times when objects do need to collaborate by exchanging data, which leads to genuine needs for getters." - to zní rozumně
Takže jsi ten článek nepochopil. Přečti si ho znovu.
-
(Btw z téhle trojky nakonec stojí za to jenom Fowler, i když přes ty další dva se stejně musí zamlada prokousat každý.)
https://martinfowler.com/bliki/GetterEradicator.html (https://martinfowler.com/bliki/GetterEradicator.html)
"There are too many times when objects do need to collaborate by exchanging data, which leads to genuine needs for getters." - to zní rozumně
Takže jsi ten článek nepochopil. Přečti si ho znovu.
rád si to nechám vysvětlit
-
https://martinfowler.com/bliki/GetterEradicator.html (https://martinfowler.com/bliki/GetterEradicator.html)
"There are too many times when objects do need to collaborate by exchanging data, which leads to genuine needs for getters." - to zní rozumně
Takže jsi ten článek nepochopil. Přečti si ho znovu.
rád si to nechám vysvětlit
Prostě sis vybral větu, že existují i případy (dost časté), které ty gettery potřebují pro spolupráci při výměně dat mezi objekty. Bohužel to mnohé programátory inspiruje k tomu, že se takhle snaží dělat všechny objekty a metody strkají někde mimo objekt do nějakých servisních tříd, které tak jen suplují namespace pro funkce. Takže programují strukturovaně v objektovém jazyce.
Je docela k smíchu sledovat programátory, kteří pomocí operátoru instanceof zjišťují, který getter na objektu v kolekci mohou zavolat nebo zda ho smí zavolat.
-
Az budes premyslet nad domenovym modelem tve aplikace a kreslit delici cary jednotlivych sluzeb, vsimej si ktere casti spolu tesne souvisi = jsou potreba v ramci stejneho use case. Nechces dopustit, aby pri obsluze jednoho use case probihaly mraky remote volani mezi sluzbama, sitova latence by zabila vykon aplikace. Mrkni se na https://www.martinfowler.com/bliki/BoundedContext.html a https://martinfowler.com/eaaCatalog/remoteFacade.html pro inspiraci.
Pokud cast tve aplikace se jednou odladi a pak uz je vicemene nemenna a jen se provolava, zatimco cast se bude rozvijet podle business pozadavku, muzes si usnadnit zivot, kdyz je oddelis do samostatnych sluzeb - snizi se tim kognitivni slozitost tve aplikace.
-
... existují i případy (dost časté), které ty gettery potřebují pro spolupráci při výměně dat mezi objekty ...
tak to jsme to asi pochopili stejně
-
... existují i případy (dost časté), které ty gettery potřebují pro spolupráci při výměně dat mezi objekty ...
tak to jsme to asi pochopili stejně
Ano, jako výjimku potvrzující pravidla napsaná ve zbytku článku.
-
Kit tato diskusia nenamala byt ani o tvojom richlom PHP ani geteroch a stereoch, zaloz si na ne vlastnu temu, ale tu si spravil tri strany offtopicu.
-
Kit tato diskusia nenamala byt ani o tvojom richlom PHP ani geteroch a stereoch, zaloz si na ne vlastnu temu, ale tu si spravil tri strany offtopicu.
Nemohu za to, že se mě tu pořád někdo na něco vyptává. Pouze jsem trpělivě odpovídal na otázky. Když neodpovím, tak jim to vadí. Když odpovím, tak jim to vadí také.
Uvítám, pokud se vrátíme k velikosti mirkoslužeb.
-
... existují i případy (dost časté), které ty gettery potřebují pro spolupráci při výměně dat mezi objekty ...
tak to jsme to asi pochopili stejně
Proto je Fowler tak dobrý, protože chápe a uznává, že věci jsou složité a vyžadují použití mozku. Ne trevas trapné repetitivní nadávky na accessory, zejména v souvislosti, kde typicky neškodí (performance).
-
Kit tato diskusia nenamala byt ani o tvojom richlom PHP ani geteroch a stereoch, zaloz si na ne vlastnu temu, ale tu si spravil tri strany offtopicu.
Nemohu za to, že se mě tu pořád někdo na něco vyptává. Pouze jsem trpělivě odpovídal na otázky. Když neodpovím, tak jim to vadí. Když odpovím, tak jim to vadí také.
Uvítám, pokud se vrátíme k velikosti mirkoslužeb.
Mohol by si ukazat nejaky priklad kodu? Aspon raz za tych x rokov co tu o tom pises, prosim, ukaz aspon raz kod, ze ako to teda myslis.
-
Prodlužování doby zpracování často mívají na svědomí gettery a settery, ale nikoli zapouzdření.
Pokud si to dobře pamatuju, tak díky zapouzdření se k datům objektu nedostaneš jinak, než třeba pomocí těch get/set-rů...
Metody, které pracuji s daty objektu, dám dovnitř toho objektu. Říká se tomu zapouzdření.
A k nim se dostaneš jak?
-
Koukám, že jste blbý jak tykve, o školu s matematikou jste snad ani nezavadili:
převe velikost mikroslužby ja miliontina normální služby
Jenže tady nejde o mikroslužbu, ale mirkoslužbu, viz název tématu. Asi jde o služby poskytované prýmkem :)
-
Kit je mimo, je to obyčejný phpkář, kope druhou ligu. Neví, že v pořádné architektuře v Javěnce se používají mnohem modernější přístupy, jak napsat program, než to jeho oldschool OOP.
-
Proč tu každá diskuse musí sklouznout do nadávek?
A byl Fowler prorokem, když napsal "its name does lead to an unfortunate focus on the size of service" a zdejší diskuse to jen potvrzuje?
Kolik lidí tady reálně používá service discovery (Zookeper, Eureka, Etcd, Consul, ...), abychom zmínili ty nejrozšířenější?
Proč na téměř jedinou relevantní odpověď nikdo nezareagoval? (Takhle to vypadá, když se microservice použije tam, kde to nedává smysl. IMHO microservice má smysl tam, kde výhody toho, že si microservice žije svým životem, převyšují náklady na správu a vývoj té celé infrastruktury mikroslužeb.)
Asi proto, že ačkoliv každý to slovo používá, aspoň u nás mirkoslužby téměř nikdo nedělá. A není ani důvod. Dokud sami necítíte tu potřebu, tak vám mirkoslužby přinesou jen problémy, vyšší režii a náklady.
Protože:
- proč bychom proboha programovali v různých jazycích, nám přece stačí na všechno naše báječná Java* (nahraď vlastním oblíbeným jazykem)
- proč bychom to provozovali na mnoha serverech, my máme náš jeden superserver (a teď mne nerušte, právě provádím restart a to trvá víc než hodinu)
- komunikovat po síti je oser, síť nemusí být dostupná a musel bych řešit ptákoviny jako circuit breaker, throttling apod.
- generování kódu zvládáme jen pro soap (však to taky trvalo, než jsme se to před těmi 10 lety naučili) a vůbec XML je báječná věc, i když všichni ostatní říkají, že je celkem na hovno...
Ale pokud aspoň se třemi body nesouhlasíte, možná by vám mirkoslužby v něčem mohly pomoci.