Hello, habr. Ang pagpapatala para sa isang bagong stream ng kurso ay bukas ngayon sa OTUS . Sa bisperas ng pagsisimula ng kurso, nais kong ibahagi sa iyo ang aking orihinal na artikulo.
Pagpapakilala
Ang pagpili ng istilo ng arkitektura ay isa sa mga pangunahing teknikal na desisyon kapag nagtatayo ng isang sistema ng impormasyon. Sa seryeng ito ng mga artikulo, iminumungkahi kong pag-aralan ang pinakasikat na istilo ng arkitektura para sa pagbuo ng mga aplikasyon at sagutin ang tanong kung kailan kung aling istilo ng arkitektura ang pinakagusto. Sa proseso ng pagtatanghal, susubukan kong gumuhit ng isang lohikal na kadena na nagpapaliwanag sa pagbuo ng mga istilo ng arkitektura mula sa mga monolith hanggang sa mga microservice.
Ang isang maliit na kasaysayan
Kung susubukan mong tanungin ang mga developer: "Bakit kailangan namin ng mga microservice?", makakakuha ka ng iba't ibang mga sagot. Maririnig mo na pinapabuti ng mga microservice ang scalability, ginagawang mas madaling maunawaan ang code, pinapahusay ang fault tolerance, at kung minsan ay maririnig mong pinapayagan ka nitong "linisin ang iyong code." Tingnan natin ang kasaysayan upang maunawaan ang layunin sa likod ng paglitaw ng mga microservice.
Sa madaling salita, ang mga microservice sa aming kasalukuyang pag-unawa ay lumitaw tulad ng sumusunod: noong 2011, si James Lewis, na nagsusuri sa gawain ng iba't ibang kumpanya, ay nagbigay-pansin sa paglitaw ng isang bagong pattern ng "micro-app", na nag-optimize ng SOA sa mga tuntunin ng pagpapabilis ng pag-deploy ng serbisyo. Maya-maya, noong 2012, sa isang architecture summit, pinalitan ng pangalan ang pattern na microservice. Kaya, ang unang layunin ng pagpapakilala ng mga microservice ay upang mapabuti ang kilalang-kilala oras sa merkado.
Ang mga microservice ay nasa hype wave noong 2015. Ayon sa ilang mga pag-aaral, walang isang kumperensya ang kumpleto nang walang ulat sa paksa ng microservices. Bukod dito, ang ilang mga kumperensya ay eksklusibong nakatuon sa mga microservice. Sa ngayon, maraming proyekto ang nagsimulang gumamit ng istilong arkitektura na ito, at kung ang proyekto ay naglalaman ng napakaraming legacy code, malamang na aktibong isinasagawa ang paglipat sa mga microservice.
Sa kabila ng lahat ng nasa itaas, ang isang medyo maliit na bilang ng mga developer ay maaari pa ring tukuyin ang konsepto ng "microservice". Ngunit pag-uusapan natin ito sa ibang pagkakataon...
Monolith
Ang istilong arkitektura na nagkukumpara sa mga microservice ay ang monolith (o all-in-one). Malamang na hindi makatuwirang sabihin kung ano ang monolith, kaya agad kong ilista ang mga disadvantages ng istilong arkitektura na ito, na nagpasimula ng karagdagang pag-unlad ng mga istilo ng arkitektura: laki, pagkakakonekta, pag-deploy, scalability, pagiging maaasahan at katigasan. Sa ibaba ay ipinapanukala kong tingnan ang bawat isa sa mga pagkukulang nang hiwalay.
Laki
Ang monolith ay napakalaki. At karaniwan itong nakikipag-usap sa isang napakalaking database. Masyadong malaki ang application para maunawaan ng isang developer. Tanging ang mga gumugol ng maraming oras sa pagtatrabaho sa code na ito ay maaaring gumana nang maayos sa monolith, habang ang mga nagsisimula ay gugugol ng maraming oras sa pagsubok na alamin ang monolith at walang garantiya na malalaman nila ito. Karaniwan, kapag nagtatrabaho sa isang monolith, palaging may ilang "kondisyonal" na nakatatanda na nakakaalam ng monolith nang higit pa o hindi gaanong mahusay at nakakatalo sa mga kamay ng iba pang mga bagong developer sa loob ng isang taon at kalahati. Naturally, ang naturang conditional senior ay isang solong punto ng kabiguan, at ang kanyang pag-alis ay maaaring humantong sa pagkamatay ng monolith.
Pagkakaugnay
Ang monolith ay isang "malaking bola ng putik", ang mga pagbabago kung saan maaaring humantong sa hindi mahuhulaan na mga kahihinatnan. Sa pamamagitan ng paggawa ng mga pagbabago sa isang lugar, maaari mong masira ang monolith sa isa pa (kaparehong "kinakamot mo ang iyong tainga, *@ nahulog"). Ito ay dahil sa ang katunayan na ang mga bahagi sa monolith ay may napaka-kumplikado at, pinaka-mahalaga, hindi halatang mga relasyon.
Pag-deploy
Ang pag-deploy ng monolith, dahil sa mga kumplikadong relasyon sa pagitan ng mga bahagi nito, ay isang mahabang proseso na may sariling ritwal. Ang ganitong ritwal ay karaniwang hindi ganap na na-standardize at ipinapasa sa "pasalita."
Scalability
Ang mga monolith module ay maaaring may magkasalungat na pangangailangan sa mapagkukunan, na nangangailangan ng isang kompromiso na gawin sa mga tuntunin ng hardware. Isipin na mayroon kang isang monolith na binubuo ng mga serbisyo A at B. Ang Serbisyo A ay hinihingi sa laki ng hard drive, at ang serbisyo B ay hinihingi sa RAM. Sa kasong ito, alinman sa makina kung saan naka-install ang monolith ay dapat suportahan ang mga kinakailangan ng parehong mga serbisyo, o kakailanganin mong manu-mano, artipisyal na hindi paganahin ang isa sa mga serbisyo.
Isa pang halimbawa (mas klasiko): mas sikat ang serbisyo A kaysa sa serbisyo B, kaya gusto mong magkaroon ng 100 serbisyo A, at 10 serbisyo B. Muli, dalawang opsyon: mag-deploy kami ng 100 ganap na monolith, o sa ilan noon ang mga serbisyo B ay kailangang i-disable nang manu-mano.
Pagkamaaasahan
Dahil ang lahat ng mga serbisyo ay matatagpuan nang magkasama, kung ang monolith ay bumagsak, ang lahat ng mga serbisyo ay bumagsak nang sabay-sabay. Sa katunayan, ito ay maaaring hindi masyadong masama, hindi bababa sa hindi magkakaroon ng bahagyang pagkabigo sa isang distributed system, ngunit sa kabilang banda, dahil sa isang bug sa functionality na ginagamit ng 0.001% ng mga user, maaari mong mawala ang lahat ng mga user. ng iyong sistema.
Inertia
Dahil sa laki ng monolith, mahirap lumipat sa mga bagong teknolohiya. Bilang resulta, ang pagpapanatili sa parehong nakatatanda ay isang hiwalay na gawain. Ang teknolohiyang stack na pinili sa simula ng isang proyekto ay maaaring maging isang bloke na humahadlang sa pagbuo ng produkto.
Konklusyon
Sa susunod na pag-uusapan natin kung paano sinubukan ng mga tao na lutasin ang mga problemang ito sa pamamagitan ng paglipat sa mga bahagi at SOA.
Magbasa pa:
Pinagmulan: www.habr.com