{"id":92810,"date":"2020-08-31T07:42:09","date_gmt":"2020-08-31T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1"},"modified":"2020-08-31T07:42:09","modified_gmt":"2020-08-31T05:42:09","slug":"vybor-arhitekturnogo-stilya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"V\u00fdb\u011br architektonick\u00e9ho stylu (\u010d\u00e1st 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ahoj, Habr. Pr\u00e1v\u011b te\u010f je v OTUS otev\u0159en nov\u00fd b\u011bh kurzu. \u201eSoftware Architect\u201c<\/a><\/noindex>. V p\u0159edve\u010der zah\u00e1jen\u00ed kurzu s v\u00e1mi chci sd\u00edlet sv\u016fj autorsk\u00fd \u010dl\u00e1nek.<\/i><\/b><\/p>\n

<\/p>\n

\u00davod<\/h2>\n

\nVolba architektonick\u00e9ho stylu je jedn\u00edm z kl\u00ed\u010dov\u00fdch technick\u00fdch rozhodnut\u00ed p\u0159i vytv\u00e1\u0159en\u00ed informa\u010dn\u00edho syst\u00e9mu. V t\u00e9to s\u00e9rii \u010dl\u00e1nk\u016f se pokus\u00edm prozkoumat nejpopul\u00e1rn\u011bj\u0161\u00ed architektonick\u00e9 styly pro v\u00fdstavbu aplikac\u00ed a odpov\u011bd\u011bt na ot\u00e1zku, kdy je jak\u00fd architektonick\u00fd styl nejvhodn\u011bj\u0161\u00ed. B\u011bhem vypr\u00e1v\u011bn\u00ed se pokus\u00edm prov\u00e9st logickou linii, kter\u00e1 vysv\u011btluje v\u00fdvoj architektonick\u00fdch styl\u016f od monolit\u016f po mikroservisy.
\n<\/a><\/noindex><\/p>\n

Trocha historie<\/h2>\n

\nPokud se zept\u00e1te v\u00fdvoj\u00e1\u0159\u016f: \u201ePro\u010d jsou mikroservisy pot\u0159eba?\u201c, dostanete r\u016fzn\u00e9 odpov\u011bdi. Usly\u0161\u00edte, \u017ee mikroservisy zlep\u0161uj\u00ed \u0161k\u00e1lovatelnost, usnad\u0148uj\u00ed porozum\u011bn\u00ed k\u00f3du, zlep\u0161uj\u00ed odolnost proti chyb\u00e1m, n\u011bkdy usly\u0161\u00edte, \u017ee umo\u017e\u0148uj\u00ed \u201evy\u010distit k\u00f3d\u201c. Poj\u010fme se pod\u00edvat do historie, abychom pochopili, jak\u00fd c\u00edl sledovalo zaveden\u00ed mikroservis\u016f.<\/p>\n

Pokud to shrneme, mikroservisy v na\u0161em sou\u010dasn\u00e9m pojet\u00ed vznikly takto: v roce 2011 James Lewis, analyzuj\u00edc\u00ed pr\u00e1ce r\u016fzn\u00fdch firem, si v\u0161iml vzniku nov\u00e9ho vzoru \u201emicro-app\u201c, kter\u00fd optimalizoval SOA z hlediska zrychlen\u00ed nasazen\u00ed slu\u017eeb. O n\u011bco pozd\u011bji, v roce 2012, byl na architektonick\u00e9m summitu vzor p\u0159ejmenov\u00e1n na mikroservis. C\u00edlem zaveden\u00ed mikroservis\u016f tedy bylo zlep\u0161en\u00ed proslul\u00e9ho time to market<\/b>.<\/p>\n

Na \u201evln\u011b hype\u201c byly mikroservisy v roce 2015. Podle n\u011bkter\u00fdch v\u00fdzkum\u016f na \u017e\u00e1dn\u00e9 konferenci nechyb\u011bl p\u0159\u00edsp\u011bvek na t\u00e9ma mikroservis\u016f. Nav\u00edc n\u011bkter\u00e9 konference byly v\u011bnov\u00e1ny v\u00fdhradn\u011b mikroservis\u016fm. Nyn\u00ed za\u010d\u00edn\u00e1 velmi mnoho projekt\u016f s pou\u017eit\u00edm tohoto architektonick\u00e9ho stylu, a pokud projekt obsahuje tuny legacy k\u00f3du, pak se pravd\u011bpodobn\u011b aktivn\u011b prov\u00e1d\u00ed migrace na mikroservisy.<\/p>\n

Navzdory v\u00fd\u0161e uveden\u00e9mu je st\u00e1le relativn\u011b mal\u00e9 mno\u017estv\u00ed v\u00fdvoj\u00e1\u0159\u016f schopno ur\u010dit pojem \u201emikroservis\u201c. Ale o tom si promluv\u00edme pozd\u011bji...<\/p>\n

Monolit<\/h2>\n

\nArchitektonick\u00fdm stylem, kter\u00fd je protikladem mikroservisn\u00edho, je monolit (nebo \u201ev\u0161echno v jednom\u201c). O tom, co je monolit, asi nem\u00e1 smysl vypr\u00e1v\u011bt, proto hned vyjmenuji nedostatky tohoto architektonick\u00e9ho stylu, kter\u00e9 podn\u00edtily dal\u0161\u00ed v\u00fdvoj architektonick\u00fdch styl\u016f: velikost, prov\u00e1zanost, nasazen\u00ed, \u0161k\u00e1lovatelnost, spolehlivost a nehybnost. N\u00ed\u017ee navrhuji se sezn\u00e1mit s ka\u017ed\u00fdm z nedostatk\u016f jednotliv\u011b.<\/p>\n

Velikost<\/h3>\n

\nMonolit je velmi rozs\u00e1hl\u00fd. Obvykle komunikuje s velkou datab\u00e1z\u00ed. Aplikace se st\u00e1v\u00e1 natolik slo\u017eitou, \u017ee ji nen\u00ed schopn\u00fd pochopit ani jeden v\u00fdvoj\u00e1\u0159. S monolitem mohou pracovat jen ti, kdo str\u00e1vili dostatek \u010dasu nad t\u00edmto k\u00f3dem, zat\u00edmco nov\u00e1\u010dci budou tr\u00e1vit hodn\u011b \u010dasu pokusy p\u0159izp\u016fsobit se monolitu, a nen\u00ed zaru\u010deno, \u017ee to zvl\u00e1dnou. P\u0159i pr\u00e1ci s monolitem obvykle existuje n\u011bjak\u00fd \"podm\u00edn\u011bn\u00fd\" senior, kter\u00fd monolit zn\u00e1 v\u00edce-m\u00e9n\u011b dob\u0159e a po dobu jednoho a\u017e jednoho a p\u016fl roku \u201ep\u0159idr\u017euje\u201c ostatn\u00ed nov\u00e9 v\u00fdvoj\u00e1\u0159e. Samoz\u0159ejm\u011b, \u017ee takov\u00fd podm\u00edn\u011bn\u00fd senior je jedin\u00fdm bodem selh\u00e1n\u00ed, a jeho odchod m\u016f\u017ee v\u00e9st k z\u00e1niku monolitu. <\/p>\n

Vazba<\/h3>\n

\nMonolit je jako \"velk\u00fd chumel bahna\" (big ball of mud), jeho\u017e zm\u011bny mohou m\u00edt nep\u0159edv\u00eddateln\u00e9 d\u016fsledky. Zm\u011bny na jednom m\u00edst\u011b mohou po\u0161kodit monolit na jin\u00e9m m\u00edst\u011b (to je to \u201epo\u0161kr\u00e1b\u00e1n\u00ed ucha, a *@ odpadlo\u201c). Je to zp\u016fsobeno t\u00edm, \u017ee komponenty v monolitu maj\u00ed velmi slo\u017eit\u00e9 a p\u0159edev\u0161\u00edm nejasn\u00e9 vz\u00e1jemn\u00e9 vazby.<\/p>\n

Nasazen\u00ed<\/h3>\n

\nNasazen\u00ed monolitu kv\u016fli slo\u017eit\u00fdm vazb\u00e1m mezi jeho komponenty je dlouh\u00fd proces s vlastn\u00edm ritu\u00e1lem. Takov\u00fd ritu\u00e1l obvykle nen\u00ed zcela standardizov\u00e1n a p\u0159ed\u00e1v\u00e1 se \"z \u00fast do \u00fast\". <\/p>\n

\u0160k\u00e1lovatelnost<\/h3>\n

\nModuly monolitu mohou m\u00edt konfliktuj\u00edc\u00ed po\u017eadavky na zdroje, proto je t\u0159eba hledat kompromis z pohledu hardwaru. P\u0159edstavte si, \u017ee v\u00e1\u0161 monolit se skl\u00e1d\u00e1 ze slu\u017eeb A a B. Slu\u017eba A vy\u017eaduje velk\u00e9 mno\u017estv\u00ed m\u00edsta na disku, zat\u00edmco slu\u017eba B vy\u017eaduje hodn\u011b opera\u010dn\u00ed pam\u011bti. V takov\u00e9m p\u0159\u00edpad\u011b bu\u010f stroj, na kter\u00fd se monolit nasazuje, mus\u00ed spl\u0148ovat po\u017eadavky obou slu\u017eeb, nebo se bude muset n\u011bkter\u00e1 ze slu\u017eeb um\u011ble vypnout.<\/p>\n

Dal\u0161\u00ed p\u0159\u00edklad (tradi\u010dn\u011bj\u0161\u00ed): slu\u017eba A je mnohem popul\u00e1rn\u011bj\u0161\u00ed ne\u017e slu\u017eba B, a proto chcete, aby bylo 100 slu\u017eeb A a 10 slu\u017eeb B. Op\u011bt existuj\u00ed dv\u011b mo\u017enosti: bu\u010f nasazujeme 100 plnohodnotn\u00fdch monolit\u016f, nebo na n\u011bkter\u00fdch z nich je nutn\u00e9 manu\u00e1ln\u011b slu\u017eby B vypnout. <\/p>\n

Spolehlivost<\/h3>\n

\nJeliko\u017e jsou v\u0161echny slu\u017eby spojeny, pokud monolit sel\u017ee, sel\u017eou v\u0161echny slu\u017eby najednou. Ve skute\u010dnosti to mo\u017en\u00e1 nen\u00ed tak \u0161patn\u00e9, alespo\u0148 nebudou \u010d\u00e1ste\u010dn\u00e9 v\u00fdpadky v distribuovan\u00e9m syst\u00e9mu, na druhou stranu v\u0161ak kv\u016fli chyb\u011b ve funk\u010dnosti, kterou pou\u017e\u00edv\u00e1 0,001 % u\u017eivatel\u016f, m\u016f\u017eete ztratit v\u0161echny u\u017eivatele va\u0161eho syst\u00e9mu. <\/p>\n

Konzervatismus<\/h3>\n

\nVzhledem k velikosti monolitu je obt\u00ed\u017en\u00e9 p\u0159ej\u00edt na nov\u00e9 technologie. N\u00e1sledkem toho se objevuje samostatn\u00fd \u00fakol, jak udr\u017eet onen podm\u00edn\u011bn\u00fd seniora. Vybran\u00fd technologick\u00fd stack na za\u010d\u00e1tku projektu m\u016f\u017ee b\u00fdt p\u0159ek\u00e1\u017ekou br\u00e1n\u00edc\u00ed rozvoji produktu. <\/p>\n

Z\u00e1v\u011br<\/h2>\n

\nP\u0159\u00ed\u0161t\u011b si pov\u00edme, jak se lid\u00e9 sna\u017eili vy\u0159e\u0161it zm\u00edn\u011bn\u00e9 probl\u00e9my p\u0159echodem na komponenty a SOA.<\/p>\n

\"V\u00fdb\u011br<\/a><\/noindex><\/p>\n

\n

\u010c\u00edst v\u00edc:<\/h4>\n

<\/p>\n