Kamusta kayong lahat! May magandang balita kami, ilulunsad muli ng OTUS ang kurso sa Hunyo , na may kaugnayan sa kung saan kami ay tradisyonal na nagbabahagi ng kapaki-pakinabang na materyal sa iyo.
Kung nakatagpo ka ng buong microservices na ito nang walang anumang konteksto, mapapatawad ka sa pag-iisip na medyo kakaiba ito. Ang paghahati ng isang application sa mga fragment na konektado ng isang network ay kinakailangang nangangahulugan ng pagdaragdag ng mga kumplikadong fault tolerance mode sa nagreresultang distributed system.
Bagama't ang diskarteng ito ay nagsasangkot ng paghahati-hati nito sa maraming independiyenteng mga serbisyo, ang pangwakas na layunin ay higit pa sa pagpapatakbo ng mga serbisyong iyon sa iba't ibang makina. Pinag-uusapan natin dito ang pakikipag-ugnayan sa labas ng mundo, na ipinamamahagi din sa kakanyahan nito. Hindi sa teknikal na kahulugan, kundi sa kahulugan ng isang ecosystem na binubuo ng maraming tao, mga koponan, mga programa, at bawat isa sa mga bahaging ito sa paanuman ay kailangang gawin ang trabaho nito.
Ang mga kumpanya, halimbawa, ay isang koleksyon ng mga distributed system na sama-samang nag-aambag sa pagkamit ng ilang layunin. Binalewala namin ang katotohanang ito sa loob ng ilang dekada, sinusubukang makamit ang pagkakaisa sa pamamagitan ng FTPing file o paggamit ng mga tool sa pagsasama ng enterprise habang tumutuon sa sarili naming mga layunin. Ngunit sa pagdating ng mga serbisyo, nagbago ang lahat. Ang mga serbisyo ay nakatulong sa amin na tumingin sa kabila ng abot-tanaw at makita ang isang mundo ng magkakaugnay na mga programa na nagtutulungan. Gayunpaman, upang matagumpay na magtrabaho, kinakailangan na kilalanin at idisenyo ang dalawang pangunahing magkaibang mundo: ang panlabas na mundo, kung saan tayo nakatira sa isang ecosystem ng maraming iba pang mga serbisyo, at ang ating personal, panloob na mundo, kung saan tayo nag-iisa.
Ang distributed world na ito ay iba sa kung saan tayo lumaki at nakasanayan na. Ang mga prinsipyo ng pagbuo ng tradisyonal na monolitikong arkitektura ay hindi tumatayo sa pagpuna. Kaya't ang pagpapatama sa mga system na ito ay higit pa sa paggawa ng isang cool na whiteboard diagram o isang cool na patunay ng konsepto. Ang punto ay upang matiyak na matagumpay na gumagana ang naturang sistema sa loob ng mahabang panahon. Sa kabutihang palad, ang mga serbisyo ay nasa loob ng medyo matagal na panahon, bagaman iba ang hitsura ng mga ito. ay may kaugnayan pa rin, kahit na tinimplahan ng Docker, Kubernetes at bahagyang malabo na hipster na balbas.
Kaya ngayon, titingnan natin kung paano nagbago ang mga panuntunan, kung bakit kailangan nating pag-isipang muli ang paraan ng paglapit natin sa mga serbisyo at ang data na ipinapasa ng mga ito sa isa't isa, at kung bakit kakailanganin natin ng ganap na magkakaibang mga tool para magawa ito.
Ang encapsulation ay hindi palaging magiging kaibigan mo
Ang mga microservice ay maaaring gumana nang hiwalay sa isa't isa. Ang ari-arian na ito ang nagbibigay sa kanila ng pinakamalaking halaga. Ang parehong ari-arian na ito ay nagbibigay-daan sa mga serbisyo na lumaki at lumago. Hindi gaanong sa kahulugan ng pag-scale sa quadrillions ng mga user o petabytes ng data (bagama't makakatulong din ang mga iyon doon), ngunit sa kahulugan ng pag-scale sa mga tuntunin ng mga tao habang patuloy na lumalaki ang mga koponan at organisasyon.
Gayunpaman, ang kalayaan ay isang tabak na may dalawang talim. Iyon ay, ang serbisyo mismo ay maaaring tumakbo nang madali at natural. Ngunit kung ang isang function ay ipinatupad sa loob ng isang serbisyo na nangangailangan ng paggamit ng isa pang serbisyo, pagkatapos ay kailangan naming gumawa ng mga pagbabago sa parehong mga serbisyo nang halos sabay-sabay. Sa isang monolith ito ay madaling gawin, gumawa ka lamang ng pagbabago at ipadala ito upang ilabas, ngunit sa kaso ng pag-synchronize ng mga independiyenteng serbisyo ay magkakaroon ng higit pang mga problema. Ang koordinasyon sa pagitan ng mga koponan at mga siklo ng paglabas ay sumisira sa liksi.
Bilang bahagi ng karaniwang diskarte, sinusubukan lang nilang iwasan ang nakakainis na mga end-to-end na pagbabago, na malinaw na naghahati ng functionality sa pagitan ng mga serbisyo. Maaaring maging magandang halimbawa dito ang single sign-on service. Mayroon itong malinaw na tinukoy na tungkulin na nagpapaiba nito sa ibang mga serbisyo. Ang malinaw na paghihiwalay na ito ay nangangahulugan na sa isang mundo ng mabilis na pagbabago ng mga pangangailangan sa mga serbisyo sa paligid nito, ang solong serbisyo sa pag-sign-on ay malamang na hindi magbago. Ito ay umiiral sa loob ng isang mahigpit na limitadong konteksto.
Ang problema ay na sa totoong mundo, ang mga serbisyo ng negosyo ay hindi maaaring mapanatili ang parehong purong paghihiwalay ng mga tungkulin sa lahat ng oras. Halimbawa, ang parehong mga serbisyo ng negosyo ay gumagana sa isang mas malaking lawak sa data na nagmumula sa iba pang katulad na mga serbisyo. Kung kasangkot ka sa online na retail, ang pagpoproseso ng daloy ng order, katalogo ng produkto o impormasyon ng user ay magiging kinakailangan para sa marami sa iyong mga serbisyo. Ang bawat isa sa mga serbisyo ay mangangailangan ng access sa data na ito upang gumana.
Karamihan sa mga serbisyo ng negosyo ay nagbabahagi ng parehong stream ng data, kaya ang kanilang trabaho ay palaging magkakaugnay.
Sa gayon tayo ay dumating sa isang mahalagang punto na dapat pag-usapan. Bagama't gumagana nang maayos ang mga serbisyo para sa mga bahagi ng imprastraktura na higit na gumagana nang nakahiwalay, karamihan sa mga serbisyo ng negosyo ay nagiging mas malapit na magkakaugnay.
Dichotomy ng data
Maaaring umiral na ang mga diskarteng nakatuon sa serbisyo, ngunit kulang pa rin ang mga ito ng insight sa kung paano magbahagi ng malaking halaga ng data sa pagitan ng mga serbisyo.
Ang pangunahing problema ay ang data at mga serbisyo ay hindi mapaghihiwalay. Sa isang banda, hinihikayat tayo ng encapsulation na itago ang data upang maihiwalay ang mga serbisyo sa isa't isa at mapadali ang kanilang paglaki at higit pang mga pagbabago. Sa kabilang banda, kailangan nating malayang hatiin at lupigin ang nakabahaging data, tulad ng iba pang data. Ang punto ay upang makapagsimula kaagad sa pagtatrabaho, nang malaya tulad ng sa anumang iba pang sistema ng impormasyon.
Gayunpaman, ang mga sistema ng impormasyon ay walang gaanong kinalaman sa encapsulation. Sa katunayan, ito ay lubos na kabaligtaran. Ginagawa ng mga database ang lahat ng kanilang makakaya upang magbigay ng access sa data na iniimbak nila. Ang mga ito ay may isang malakas na deklaratibong interface na nagbibigay-daan sa iyong baguhin ang data ayon sa kailangan mo. Ang ganitong functionality ay mahalaga sa paunang yugto ng pananaliksik, ngunit hindi para sa pamamahala sa lumalaking kumplikado ng isang patuloy na umuunlad na serbisyo.
At dito lumitaw ang isang dilemma. Kontradiksyon. Dikotomiya. Pagkatapos ng lahat, ang mga sistema ng impormasyon ay tungkol sa pagbibigay ng data, at ang mga serbisyo ay tungkol sa pagtatago.
Ang dalawang puwersang ito ay pangunahing. Pinapatibay nila ang karamihan sa aming trabaho, patuloy na nakikipaglaban para sa kahusayan sa mga system na aming binuo.
Habang lumalaki at umuunlad ang mga sistema ng serbisyo, nakikita namin ang mga kahihinatnan ng dichotomy ng data sa maraming paraan. Alinman sa paglaki ng interface ng serbisyo, na magbibigay ng patuloy na tumataas na hanay ng functionality at magsisimulang magmukhang isang napakagandang homegrown database, o tayo ay madidismaya at magpapatupad ng ilang paraan upang mabawi o ilipat nang maramihan ang buong set ng data mula sa serbisyo patungo sa serbisyo.
Sa turn, ang paglikha ng isang bagay na mukhang isang magarbong homegrown database ay hahantong sa isang buong host ng mga problema. Hindi na tayo magdedetalye kung bakit ito mapanganib nakabahaging database, sabihin natin na ito ay kumakatawan sa makabuluhang magastos na engineering at pagpapatakbo para sa kumpanyang sinusubukang gamitin ito.
Ang mas malala pa ay pinalalaki ng dami ng data ang mga problema sa hangganan ng serbisyo. Kung mas maraming nakabahaging data ang nasa loob ng isang serbisyo, magiging mas kumplikado ang interface at mas magiging mahirap na pagsamahin ang mga set ng data na nagmumula sa iba't ibang mga serbisyo.
Ang alternatibong diskarte sa pagkuha at paglipat ng buong set ng data ay mayroon ding mga problema. Ang isang karaniwang diskarte sa tanong na ito ay mukhang simpleng pagbawi at pag-iimbak ng buong dataset, at pagkatapos ay iimbak ito nang lokal sa bawat gumagamit ng serbisyo.
Ang problema ay ang iba't ibang mga serbisyo ay binibigyang kahulugan ang data na kanilang kinokonsumo nang iba. Ang data na ito ay palaging nasa kamay. Ang mga ito ay binago at pinoproseso nang lokal. Mabilis silang tumigil na magkaroon ng anumang bagay na pareho sa data sa pinagmulan.
Kung mas nababago ang mga kopya, mas mag-iiba ang data sa paglipas ng panahon.
Ang masama pa nito, mahirap itama ang naturang data sa pagbabalik-tanaw ( Dito talaga ito makakaligtas). Sa katunayan, ang ilan sa mga mahirap na problema sa teknolohiya na kinakaharap ng mga negosyo ay nagmumula sa magkakaibang data na dumarami mula sa aplikasyon hanggang sa aplikasyon.
Upang makahanap ng solusyon sa problemang ito, kailangan nating mag-isip nang iba tungkol sa nakabahaging data. Dapat silang maging mga first class na bagay sa mga arkitektura na binuo namin. tinatawag ang naturang data na "panlabas", at ito ay isang napakahalagang tampok. Kailangan namin ng encapsulation para hindi namin ilantad ang mga panloob na gawain ng isang serbisyo, ngunit kailangan naming gawing madali para sa mga serbisyo na ma-access ang nakabahaging data para magawa nila nang tama ang kanilang mga trabaho.
Ang problema ay ang alinman sa diskarte ay hindi nauugnay sa ngayon, dahil ang mga interface ng serbisyo, o ang pagmemensahe, o ang Shared Database ay hindi nag-aalok ng isang mahusay na solusyon para sa pagtatrabaho sa panlabas na data. Ang mga interface ng serbisyo ay hindi angkop para sa pagpapalitan ng data sa anumang sukat. Ang pagmemensahe ay naglilipat ng data ngunit hindi nag-iimbak ng kasaysayan nito, kaya nagiging sira ang data sa paglipas ng panahon. Masyadong nakatuon ang mga Shared Database sa isang punto, na pumipigil sa pag-unlad. Hindi maiiwasang maipit tayo sa isang ikot ng pagkabigo ng data:
Cycle ng data failure
Stream: isang desentralisadong diskarte sa data at mga serbisyo
Sa isip, kailangan nating baguhin ang paraan ng paggana ng mga serbisyo sa nakabahaging data. Sa puntong ito, ang alinmang diskarte ay nahaharap sa nabanggit na dichotomy, dahil walang magic dust na maaaring iwiwisik dito upang mawala ito. Gayunpaman, maaari nating pag-isipang muli ang problema at maabot ang isang kompromiso.
Ang kompromiso na ito ay nagsasangkot ng isang tiyak na antas ng sentralisasyon. Magagamit namin ang distributed log mechanism dahil nagbibigay ito ng maaasahan at nasusukat na stream. Gusto na namin ngayon na ang mga serbisyo ay makasali at makapagpatakbo sa mga nakabahaging thread na ito, ngunit gusto naming iwasan ang mga kumplikadong sentralisadong Serbisyo ng Diyos na gumagawa ng pagproseso na ito. Samakatuwid, ang pinakamagandang opsyon ay ang bumuo ng pagpoproseso ng stream sa bawat serbisyo ng consumer. Sa ganitong paraan, magagawa ng mga serbisyo na pagsamahin ang mga set ng data mula sa iba't ibang pinagmulan at gagana sa kanila sa paraang kailangan nila.
Ang isang paraan upang makamit ang diskarteng ito ay sa pamamagitan ng paggamit ng isang streaming platform. Mayroong maraming mga pagpipilian, ngunit ngayon ay titingnan natin ang Kafka, dahil ang paggamit ng Stateful Stream Processing nito ay nagbibigay-daan sa amin upang epektibong malutas ang ipinakita na problema.
Ang paggamit ng isang distributed logging mechanism ay nagbibigay-daan sa amin na sundan ang tinatahak na landas at gamitin ang pagmemensahe para magtrabaho . Ang diskarte na ito ay itinuturing na nagbibigay ng mas mahusay na scaling at partitioning kaysa sa mekanismo ng kahilingan-tugon dahil nagbibigay ito ng kontrol sa daloy sa receiver kaysa sa nagpadala. Gayunpaman, para sa lahat ng bagay sa buhay na ito kailangan mong magbayad, at dito kailangan mo ng isang broker. Ngunit para sa malalaking system, sulit ang trade-off (na maaaring hindi ito ang kaso para sa iyong average na web application).
Kung ang isang broker ay responsable para sa distributed logging sa halip na isang tradisyunal na sistema ng pagmemensahe, maaari mong samantalahin ang mga karagdagang feature. Ang transportasyon ay maaaring i-scale nang linearly halos pati na rin ang isang distributed file system. Maaaring maimbak ang data sa mga log nang medyo mahabang panahon, kaya hindi lamang pagpapalitan ng mensahe ang nakukuha namin, kundi pati na rin ang pag-iimbak ng impormasyon. Nasusukat na imbakan nang walang takot sa nababagong ibinahaging estado.
Maaari mong gamitin ang stateful stream processing upang magdagdag ng mga tool sa deklaratibong database sa pagkonsumo ng mga serbisyo. Ito ay isang napakahalagang ideya. Habang nakaimbak ang data sa mga nakabahaging stream na maa-access ng lahat ng serbisyo, pribado ang pagsasama-sama at pagproseso na ginagawa ng serbisyo. Nakita nila ang kanilang sarili na nakahiwalay sa loob ng mahigpit na limitadong konteksto.
Tanggalin ang dichotomy ng data sa pamamagitan ng paghihiwalay sa hindi nababagong stream ng estado. Pagkatapos ay idagdag ang functionality na ito sa bawat serbisyo gamit ang Stateful Stream Processing.
Kaya, kung ang iyong serbisyo ay kailangang gumana sa mga order, isang katalogo ng produkto, isang bodega, magkakaroon ito ng ganap na access: ikaw lang ang magpapasya kung anong data ang pagsasamahin, kung saan ito ipoproseso at kung paano ito dapat magbago sa paglipas ng panahon. Sa kabila ng katotohanan na ang data ay ibinabahagi, ang pagtatrabaho dito ay ganap na desentralisado. Ginagawa ito sa loob ng bawat serbisyo, sa isang mundo kung saan napupunta ang lahat ayon sa iyong mga patakaran.
Ibahagi ang data nang hindi nakompromiso ang integridad nito. I-encapsulate ang function, hindi ang source, sa bawat serbisyong nangangailangan nito.
Nangyayari na ang data ay kailangang ilipat nang maramihan. Minsan ang isang serbisyo ay nangangailangan ng lokal na makasaysayang dataset sa napiling database engine. Ang lansihin ay maaari mong garantiya na, kung kinakailangan, ang isang kopya ay maaaring maibalik mula sa pinagmulan sa pamamagitan ng pag-access sa ipinamahagi na mekanismo ng pag-log. Ang mga konektor sa Kafka ay gumagawa ng mahusay na gawain nito.
Kaya, ang diskarte na tinalakay ngayon ay may ilang mga pakinabang:
- Ginagamit ang data sa anyo ng mga karaniwang stream, na maaaring maimbak sa mga log nang mahabang panahon, at ang mekanismo para sa pagtatrabaho sa karaniwang data ay naka-hardwired sa bawat indibidwal na konteksto, na nagpapahintulot sa mga serbisyo na gumana nang madali at mabilis. Sa ganitong paraan, maaaring balansehin ang dichotomy ng data.
- Ang data na nagmumula sa iba't ibang serbisyo ay madaling pagsamahin sa mga set. Pinapasimple nito ang pakikipag-ugnayan sa nakabahaging data at inaalis ang pangangailangang magpanatili ng mga lokal na dataset sa database.
- Ang Stateful Stream Processing ay nag-cache lamang ng data, at ang pinagmulan ng katotohanan ay nananatiling pangkalahatang mga tala, kaya ang problema ng data corruption sa paglipas ng panahon ay hindi masyadong talamak.
- Sa kanilang pangunahing, ang mga serbisyo ay batay sa data, ibig sabihin, sa kabila ng patuloy na pagtaas ng dami ng data, ang mga serbisyo ay maaari pa ring tumugon nang mabilis sa mga kaganapan sa negosyo.
- Ang mga isyu sa scalability ay nasa broker, hindi ang mga serbisyo. Ito ay makabuluhang binabawasan ang pagiging kumplikado ng mga serbisyo sa pagsusulat, dahil hindi na kailangang mag-isip tungkol sa scalability.
- Ang pagdaragdag ng mga bagong serbisyo ay hindi nangangailangan ng pagbabago ng mga luma, kaya ang pagkonekta ng mga bagong serbisyo ay nagiging mas madali.
Tulad ng nakikita mo, ito ay higit pa sa PAGPAPAHALAGA. Nakatanggap kami ng isang hanay ng mga tool na nagbibigay-daan sa iyong magtrabaho kasama ang nakabahaging data sa isang desentralisadong paraan.
Hindi lahat ng aspeto ay tinalakay sa artikulo ngayon. Kailangan pa rin nating malaman kung paano balansehin ang paradigm sa pagtugon sa kahilingan at paradigm na hinimok ng kaganapan. Ngunit haharapin natin ito sa susunod. May mga paksang kailangan mong mas makilala, halimbawa, kung bakit napakahusay ng Stateful Stream Processing. Pag-uusapan natin ito sa ikatlong artikulo. At may iba pang makapangyarihang mga konstruksyon na maaari nating samantalahin kung gagamitin natin ang mga ito, halimbawa, . Ito ay isang game changer para sa mga distributed business system dahil nagbibigay ito ng mga transactional na garantiya para sa sa isang nasusukat na anyo. Tatalakayin ito sa ikaapat na artikulo. Sa wakas, kakailanganin nating suriin ang mga detalye ng pagpapatupad ng mga prinsipyong ito.
Ngunit sa ngayon, tandaan lamang ito: ang data dichotomy ay isang puwersang kinakaharap natin kapag nagtatayo ng mga serbisyo sa negosyo. At dapat nating tandaan ito. Ang lansihin ay ibalik ang lahat sa ulo nito at simulan ang pagtrato sa nakabahaging data bilang mga first-class na bagay. Ang Stateful Stream Processing ay nagbibigay ng isang natatanging kompromiso para dito. Iniiwasan nito ang sentralisadong "Mga Bahagi ng Diyos" na pumipigil sa pag-unlad. Bukod dito, tinitiyak nito ang liksi, scalability at resiliency ng data streaming pipelines at idinaragdag ang mga ito sa bawat serbisyo. Samakatuwid, maaari tayong tumuon sa pangkalahatang daloy ng kamalayan kung saan maaaring kumonekta at gumana ang anumang serbisyo sa data nito. Ginagawa nitong mas nasusukat, napagpapalit at nagsasarili ang mga serbisyo. Kaya hindi lamang sila magiging maganda sa mga whiteboard at hypothesis test, ngunit gagana rin sila at mag-evolve sa loob ng mga dekada.
Pinagmulan: www.habr.com