Setyembre 19 sa Moscow ang unang thematic meeting na HUG (Highload++ User Group), na nakatuon sa mga microservice. Nagkaroon ng presentasyon na "Operating Microservices: Size Matters, Even If You Have Kubernetes," kung saan ibinahagi namin ang malawak na karanasan ni Flant sa pagpapatakbo ng mga proyekto gamit ang microservice architecture. Una sa lahat, magiging kapaki-pakinabang ito sa lahat ng mga developer na nag-iisip tungkol sa paggamit ng diskarteng ito sa kanilang kasalukuyan o hinaharap na proyekto.
Pagpapakilala (50 minuto, higit na nagbibigay-kaalaman kaysa sa artikulo), pati na rin ang pangunahing katas mula dito sa anyo ng teksto.
NB: Available din ang video at presentation sa dulo ng post na ito.
Pagpapakilala
Karaniwan ang isang magandang kuwento ay may simula, isang pangunahing balangkas at isang resolusyon. Ang ulat na ito ay higit na katulad ng isang prelude, at isang trahedya. Mahalaga ring tandaan na nagbibigay ito ng pananaw ng isang tagalabas sa mga microservice. pagsasamantala.
Magsisimula ako sa graph na ito, ang may-akda nito (sa 2015) Martin Fowler:
Ipinapakita nito kung paano, sa kaso ng isang monolitikong aplikasyon na umabot sa isang tiyak na halaga, ang pagiging produktibo ay nagsisimulang bumaba. Ang mga microservice ay naiiba dahil ang paunang produktibidad sa kanila ay mas mababa, ngunit habang lumalaki ang pagiging kumplikado, ang pagkasira sa kahusayan ay hindi gaanong kapansin-pansin para sa kanila.
Magdaragdag ako sa graph na ito para sa kaso ng paggamit ng Kubernetes:
Bakit mas mahusay ang isang application na may mga microservice? Dahil ang ganitong arkitektura ay naglalagay ng mga seryosong pangangailangan para sa arkitektura, na siya namang perpektong sakop ng mga kakayahan ng Kubernetes. Sa kabilang banda, ang ilan sa functionality na ito ay magiging kapaki-pakinabang para sa isang monolith, lalo na dahil ang karaniwang monolith ngayon ay hindi eksaktong isang monolith (ang mga detalye ay magiging mamaya sa ulat).
Gaya ng nakikita mo, ang panghuling graph (kapag ang parehong monolitik at microservice na application ay nasa imprastraktura kasama ang Kubernetes) ay hindi masyadong naiiba sa orihinal. Susunod na pag-uusapan natin ang tungkol sa mga application na pinapatakbo gamit ang Kubernetes.
Mga kapaki-pakinabang at nakakapinsalang microservice
At narito ang pangunahing ideya:
Anong normal arkitektura ng microservice? Dapat itong magdala sa iyo ng mga tunay na benepisyo, na nagpapataas ng iyong kahusayan sa trabaho. Kung babalik tayo sa graph, narito ito:
Kung tatawagan mo siya kapaki-pakinabang, pagkatapos ay sa kabilang panig ng graph ay magkakaroon nakakapinsala microservices (nakakaabala sa trabaho):
Pagbabalik sa "pangunahing ideya": dapat ba akong magtiwala sa aking karanasan? Simula ng taong ito ay tumingin na ako 85 na proyekto. Hindi lahat ng mga ito ay mga microservice (halos isang ikatlo hanggang kalahati sa kanila ay may ganoong arkitektura), ngunit ito ay isang malaking bilang pa rin. Kami (Flant company) bilang mga outsourcer ay namamahala upang makita ang isang malawak na iba't ibang mga application na binuo kapwa sa maliliit na kumpanya (na may 5 developer) at sa malalaking mga (~500 developer). Ang isang karagdagang benepisyo ay nakikita namin ang mga application na ito na live at nagbabago sa paglipas ng mga taon.
Bakit microservices?
Sa tanong tungkol sa mga pakinabang ng microservices mayroong mula sa nabanggit na Martin Fowler:
- malinaw na mga hangganan ng modularity;
- independiyenteng pag-deploy;
- kalayaang pumili ng mga teknolohiya.
Marami akong nakipag-usap sa mga software architect at developer at nagtanong kung bakit kailangan nila ng mga microservice. At ginawa ko ang aking listahan ng kanilang mga inaasahan. Narito ang nangyari:
Kung ilalarawan natin ang ilan sa mga punto "sa mga sensasyon," kung gayon:
- malinaw na mga hangganan ng mga module: narito mayroon kaming isang kahila-hilakbot na monolith, at ngayon ang lahat ay maayos na nakaayos sa mga repositoryo ng Git, kung saan ang lahat ay "nasa mga istante", ang mainit at malambot ay hindi magkakahalo;
- pagsasarili sa pag-deploy: magagawa nating ilunsad ang mga serbisyo nang nakapag-iisa upang mas mabilis ang pag-unlad (mag-publish ng mga bagong feature nang magkatulad);
- kalayaan sa pag-unlad: maibibigay natin ang microservice na ito sa isang koponan/developer, at iyon sa isa't isa, salamat sa kung saan maaari tayong bumuo ng mas mabilis;
- Π±ΠΎhigit na pagiging maaasahan: kung magaganap ang bahagyang pagkasira (isang microservice sa 20 talon), isang button lang ang hihinto sa paggana, at ang system sa kabuuan ay patuloy na gagana.
Karaniwang (nakakapinsala) na arkitektura ng microservice
Upang ipaliwanag kung bakit ang katotohanan ay hindi ang inaasahan natin, ipapakita ko sama-sama isang imahe ng isang microservice architecture batay sa karanasan mula sa maraming iba't ibang mga proyekto.
Ang isang halimbawa ay isang abstract na online na tindahan na makikipagkumpitensya sa Amazon o hindi bababa sa OZON. Ang arkitektura ng microservice nito ay ganito ang hitsura:
Para sa isang kumbinasyon ng mga kadahilanan, ang mga microservice na ito ay nakasulat sa iba't ibang mga platform:
Dahil ang bawat microservice ay dapat magkaroon ng awtonomiya, marami sa kanila ang nangangailangan ng kanilang sariling database at cache. Ang huling arkitektura ay ang mga sumusunod:
Ano ang mga kahihinatnan nito?
May ganito rin si Fowler β tungkol sa βpagbabayadβ para sa paggamit ng mga microservice:
At titingnan natin kung natugunan ang ating mga inaasahan.
Malinaw na mga hangganan ng mga module...
Pero ilang microservices ba talaga ang kailangan nating ayusin?upang ilunsad ang pagbabago? Maaari ba nating malaman kung paano gumagana ang lahat nang walang ipinamahagi na tracer (pagkatapos ng lahat, anumang kahilingan ay pinoproseso ng kalahati ng mga microservice)?
May pattern"β, at dito pala ito ay isang ipinamahagi na bukol ng dumi. Upang kumpirmahin ito, narito ang isang tinatayang paglalarawan kung paano napupunta ang mga kahilingan:
Deployment independence...
Sa teknikal, ito ay nakamit: maaari naming ilunsad ang bawat microservice nang hiwalay. Ngunit sa pagsasagawa kailangan mong isaalang-alang na ito ay palaging lumalabas maraming microservices, at kailangan nating isaalang-alang ang pagkakasunud-sunod ng kanilang paglulunsad. Sa mabuting paraan, sa pangkalahatan ay kailangan nating subukan sa isang hiwalay na circuit kung ilulunsad natin ang release sa tamang pagkakasunud-sunod.
Kalayaan sa pagpili ng teknolohiya...
Siya ay. Tandaan lamang na ang kalayaan ay madalas na hangganan sa kawalan ng batas. Napakahalaga dito na huwag pumili ng mga teknolohiya para lamang "maglaro" sa kanila.
Kalayaan sa pag-unlad...
Paano gumawa ng test loop para sa buong application (na may napakaraming bahagi)? Ngunit kailangan mo pa ring panatilihin itong napapanahon. Ang lahat ng ito ay humahantong sa katotohanan na aktwal na bilang ng mga test circuit, na sa prinsipyo ay maaari nating taglayin, lumalabas na minimal.
Paano ang tungkol sa pag-deploy ng lahat ng ito nang lokal?.. Lumalabas na madalas na ginagawa ng developer ang kanyang trabaho nang nakapag-iisa, ngunit "nang random", dahil napipilitan siyang maghintay hanggang ang circuit ay libre para sa pagsubok.
Paghiwalayin ang pag-scale...
Oo, ngunit ito ay limitado sa lugar ng DBMS na ginamit. Sa ibinigay na halimbawa ng arkitektura, si Cassandra ay hindi magkakaroon ng mga problema, ngunit ang MySQL at PostgreSQL ay magkakaroon.
ΠΠΎhigit na maaasahan...
Hindi lamang ang pagkabigo ng isang microservice sa katotohanan ay madalas na sumisira sa tamang paggana ng buong system, ngunit mayroon ding isang bagong problema: ang paggawa ng bawat microservice fault-tolerant ay napakahirap. Dahil ang mga microservice ay gumagamit ng iba't ibang mga teknolohiya (memcache, Redis, atbp.), Para sa bawat isa kailangan mong pag-isipan ang lahat at ipatupad ito, na, siyempre, ay posible, ngunit nangangailangan ng malaking mapagkukunan.
Pagsusukat ng load...
Ito ay talagang mabuti.
Ang "gaan" ng mga microservice...
Hindi lang malaki ang meron tayo overhead ng network (Ang mga kahilingan para sa DNS ay dumarami, atbp.), ngunit dahil din sa maraming mga subquery na sinimulan namin kopyahin ang data (mga store cache), na humantong sa isang malaking halaga ng imbakan.
At narito ang resulta ng pagtugon sa aming mga inaasahan:
Ngunit hindi lang iyon!
dahil:
- Malamang na kakailanganin natin ng message bus.
- Paano gumawa ng pare-parehong backup sa tamang sandali sa oras? Ang nag-iisa totoo ang opsyon ay i-off ang trapiko para dito. Ngunit paano ito gagawin sa produksyon?
- Kung pinag-uusapan natin ang pagsuporta sa ilang mga rehiyon, kung gayon ang pag-aayos ng pagpapanatili sa bawat isa sa kanila ay isang napakahirap na gawain.
- Ang problema sa paggawa ng mga sentralisadong pagbabago ay lumitaw. Halimbawa, kung kailangan nating i-update ang bersyon ng PHP, kakailanganin nating mag-commit sa bawat repositoryo (at may dose-dosenang mga ito).
- Ang paglago sa pagiging kumplikado ng pagpapatakbo ay, biglaan, exponential.
Ano ang gagawin sa lahat ng ito?
Magsimula sa isang monolitikong aplikasyon. Ang karanasan ni Fowler na halos lahat ng matagumpay na microservice application ay nagsimula bilang isang monolith na naging masyadong malaki at pagkatapos ay nasira. Kasabay nito, halos lahat ng mga system na binuo bilang mga microservice mula sa simula ay nakaranas ng mga seryosong problema.
Ang isa pang mahalagang pag-iisip ay upang maging matagumpay ang isang proyekto na may arkitektura ng microservice, dapat mong alam na mabuti at paksa, at kung paano gumawa ng mga microservice. At ang pinakamahusay na paraan upang matutunan ang isang lugar ng paksa ay ang paggawa ng isang monolith.
Pero paano kung nasa ganitong sitwasyon na tayo?
Ang unang hakbang upang malutas ang anumang problema ay sumang-ayon dito at maunawaan na ito ay isang problema, na hindi namin nais na magdusa pa.
Kung, sa kaso ng isang overgrown monolith (kapag naubusan na kami ng pagkakataon na bumili ng karagdagang mga mapagkukunan para dito), pinutol namin ito, kung gayon sa kasong ito ang kabaligtaran na kuwento ay lumalabas: kapag ang labis na mga microservice ay hindi na nakakatulong, ngunit humahadlang - putulin ang labis at palakihin!
Halimbawa, para sa kolektibong larawang tinalakay sa itaas...
Alisin ang mga pinaka-kaduda-dudang microservice:
Pagsamahin ang lahat ng microservice na responsable para sa pagbuo ng frontend:
... sa isang microservice, nakasulat sa isa (moderno at normal, gaya ng iniisip mo) wika/balangkas:
Magkakaroon ito ng isang ORM (isang DBMS) at una ng isang pares ng mga application:
... ngunit sa pangkalahatan maaari kang maglipat ng higit pa doon, makuha ang sumusunod na resulta:
Bukod dito, sa Kubernetes pinapatakbo namin ang lahat ng ito sa magkakahiwalay na pagkakataon, na nangangahulugan na maaari pa rin naming sukatin ang pagkarga at sukatin ang mga ito nang hiwalay.
Upang ibuod
Tingnan ang mas malaking larawan. Kadalasan, ang lahat ng mga problemang ito sa mga microservice ay lumitaw dahil may isang taong kinuha ang kanilang gawain, ngunit nais na "maglaro sa mga microservice".
Sa salitang "microservices" ang "micro" na bahagi ay kalabisan.. Ang mga ito ay "micro" lamang dahil sila ay mas maliit kaysa sa isang malaking monolith. Ngunit huwag isipin ang mga ito bilang isang bagay na maliit.
At para sa huling pag-iisip, bumalik tayo sa orihinal na tsart:
May nakasulat na note dito (kanan sa itaas) bumabalot sa katotohanang iyon ang mga kasanayan ng pangkat na gumagawa ng iyong proyekto ay palaging pangunahin β gaganap sila ng mahalagang papel sa iyong pagpili sa pagitan ng mga microservice at monolith. Kung ang koponan ay walang sapat na mga kasanayan, ngunit nagsimula itong gumawa ng mga microservice, ang kuwento ay tiyak na mamamatay.
Mga video at slide
Video mula sa talumpati (~50 minuto; sa kasamaang-palad, hindi ito naghahatid ng maraming emosyon ng mga bisita, na higit na tumutukoy sa mood ng ulat, ngunit ganyan ito):
Presentasyon ng ulat:
PS
Iba pang mga ulat sa aming blog:
- «» (Dmitry Stolyarov; Mayo 28, 2018 sa RootConf);
- «» (Dmitry Stolyarov; Nobyembre 7, 2017 sa HighLoad++);
- «» (Dmitry Stolyarov; Hunyo 6, 2017 sa RootConf);
- «» (Dmitry Stolyarov; Nobyembre 8, 2016 sa HighLoad++);
- «» (Dmitry Stolyarov; Mayo 31, 2016 sa RootConf).
Maaari ka ring maging interesado sa mga sumusunod na publikasyon:
- Β«";
- Β«";
- Β«'.
Pinagmulan: www.habr.com