Halo sadayana! Kami gaduh warta anu saé, OTUS ngaluncurkeun kursus deui dina bulan Juni , dina sambungan nu urang tradisional babagi bahan mangpaat sareng anjeun.
Upami anjeun mendakan sadayana microservices ieu tanpa kontéks naon waé, anjeun bakal dihampura pikeun mikir yén éta rada anéh. Ngabagi hiji aplikasi kana fragmen disambungkeun ku jaringan merta hartina nambahkeun mode toleransi sesar kompléks kana sistem disebarkeun hasilna.
Sanaos pendekatan ieu ngalibatkeun ngarecahna kana seueur jasa mandiri, tujuan akhir langkung seueur tibatan ngan ukur jasa éta dijalankeun dina mesin anu béda. Urang ngobrol di dieu ngeunaan interaksi jeung dunya luar, nu ogé disebarkeun dina hakekat na. Henteu dina rasa téknis, tapi dina harti ékosistem anu diwangun ku seueur jalma, tim, program, sareng masing-masing bagian ieu kumaha waé kedah ngalaksanakeun tugasna.
Perusahaan, contona, mangrupikeun kumpulan sistem anu disebarkeun anu sacara koléktif nyumbang kana pencapaian sababaraha tujuan. Kami parantos teu malire kanyataan ieu mangpuluh-puluh taun, nyobian ngahontal ngahijikeun ku cara nransferkeun file kana FTP atanapi nganggo alat integrasi perusahaan, bari fokus kana tujuan urang sorangan. Tapi ku mecenghulna jasa, sagalana robah. Jasa parantos ngabantosan urang ningali saluareun cakrawala sareng ningali dunya program anu silih gumantung anu damel babarengan. Nanging, pikeun suksés damel, perlu pikeun mikawanoh sareng ngadesain dua dunya anu béda-béda: dunya luar, dimana urang hirup dina ékosistem seueur jasa anu sanés, sareng dunya internal pribadi urang, dimana urang maréntah nyalira.
Dunya anu disebarkeun ieu béda sareng anu urang dewasa sareng biasa. Prinsip ngawangun arsitéktur monolithic tradisional henteu tahan kana kritik. Janten leres sistem ieu langkung seueur tibatan nyiptakeun diagram papan tulis anu saé atanapi bukti konsép anu saé. Intina nyaéta pikeun mastikeun yén sistem sapertos kitu tiasa dianggo kalayan suksés dina waktos anu lami. Untungna, jasa geus sabudeureun pikeun rada lila, sanajan maranéhanana kasampak béda. masih relevan, malah seasoned kalawan Docker, Kubernetes jeung janggot hipster rada kumuh.
Janten dinten ayeuna urang bakal ningali kumaha aturan parantos robih, naha urang kedah mikirkeun deui cara urang ngadeukeutan jasa sareng data anu diteruskeun ka silih, sareng naha urang peryogi alat anu béda-béda pikeun ngalakukeunana.
Encapsulation moal salawasna jadi sobat anjeun
Microservices tiasa beroperasi sacara mandiri unggal anu sanés. Éta sipat ieu nu mere aranjeunna nilai greatest. Harta anu sami ieu ngamungkinkeun jasa pikeun skala sareng tumuwuh. Teu jadi loba dina rasa skala ka quadrillions pamaké atawa petabytes data (sanajan maranéhanana bisa mantuan aya teuing), tapi dina rasa skala dina watesan jalma salaku tim jeung organisasi tumuwuh terus.
Tapi, kamerdékaan téh pedang dua sisi. Hartina, layanan sorangan bisa ngajalankeun gampang jeung alami. Tapi lamun hiji fungsi dilaksanakeun dina layanan anu merlukeun pamakéan jasa sejen, lajeng urang tungtungna kudu nyieun parobahan duanana jasa ampir sakaligus. Dina monolith a ieu gampang ngalakukeun, Anjeun ngan nyieun parobahan sarta ngirimkeunana ka release, tapi dina kasus nyingkronkeun jasa bebas bakal aya deui masalah. Koordinasi antara tim jeung siklus release ngancurkeun agility.
Salaku bagian tina pendekatan standar, aranjeunna ngan saukur nyobian ngahindarkeun parobahan tungtung-to-tungtung ngaganggu, jelas ngabagi fungsionalitas antara jasa. Ladenan asup tunggal tiasa janten conto anu saé di dieu. Éta ngagaduhan peran anu jelas anu ngabédakeunana tina jasa anu sanés. Pemisahan anu jelas ieu hartosna yén dina dunya anu gancang-gancang ngarobah tungtutan kana jasa-jasa di sabudeureun éta, jasa asup tunggal sigana moal robih. Éta aya dina konteks anu kawates pisan.
Masalahna nyaeta di dunya nyata, jasa bisnis teu bisa ngajaga separation murni sarua peran sadaya waktu. Salaku conto, jasa bisnis anu sami tiasa dianggo langkung ageung kalayan data anu asalna tina jasa anu sami. Upami anjeun aub dina ritel online, teras ngolah aliran pesenan, katalog produk atanapi inpormasi pangguna bakal janten syarat pikeun seueur jasa anjeun. Masing-masing jasa bakal peryogi aksés kana data ieu pikeun beroperasi.
Seuseueurna jasa bisnis ngabagi aliran data anu sami, ku kituna padamelanna sering aya hubunganana.
Ku kituna urang datang ka titik penting patut ngobrol ngeunaan. Sanaos jasa dianggo saé pikeun komponén prasarana anu beroperasi sacara umum di isolasi, kalolobaan jasa bisnis mungkas intertwined langkung raket.
Dikotomi data
Pendekatan anu berorientasi jasa tiasa parantos aya, tapi aranjeunna masih kakurangan wawasan kumaha ngabagi data anu ageung antara jasa.
Masalah utama nyaéta yén data sareng jasa henteu tiasa dipisahkeun. Di hiji sisi, encapsulation nyorong urang pikeun nyumputkeun data ku kituna jasa bisa dipisahkeun ti silih tur mempermudah tumuwuhna maranéhanana sarta parobahan salajengna. Di sisi anu sanés, urang kedah tiasa sacara bébas ngabagi sareng nalukkeun data anu dibagikeun, sapertos data anu sanés. Maksudna nyaéta pikeun tiasa ngamimitian damel langsung, sakumaha bébas sapertos dina sistem inpormasi anu sanés.
Nanging, sistem inpormasi teu aya hubunganana sareng enkapsulasi. Kanyataanna, éta rada sabalikna. Basis data ngalakukeun sagala hal anu aranjeunna tiasa pikeun nyayogikeun aksés kana data anu disimpen. Éta datang sareng antarmuka déklaratif anu kuat anu ngamungkinkeun anjeun ngarobih data anu anjeun peryogikeun. Fungsionalitas sapertos penting dina tahap panilitian awal, tapi sanés pikeun ngatur pajeulitna jasa anu terus berkembang.
Sareng di dieu timbul dilema. Kontradiksi. Dikotomi. Barina ogé, sistem informasi ngeunaan nyadiakeun data, sarta jasa ngeunaan nyumputkeun.
Dua kakuatan ieu fundamental. Aranjeunna ngadukung seueur padamelan urang, teras-terasan berjuang pikeun kaunggulan dina sistem anu urang ngawangun.
Nalika sistem jasa tumbuh sareng mekar, urang ningali akibat tina dikotomi data ku sababaraha cara. Boh antarbeungeut layanan bakal tumuwuh, nyadiakeun rentang kantos-ngaronjatkeun fungsionalitas tur mimitian kasampak kawas database homegrown pisan fancy, atawa urang bakal jadi frustasi sarta nerapkeun sababaraha cara pikeun meunangkeun atawa mindahkeun en masse sakabéh set data ti layanan ka layanan.
Sabalikna, nyiptakeun hiji hal anu siga database homegrown anu mewah bakal nyababkeun seueur masalah. Kami moal masihan detil ngeunaan naha éta bahaya database dibagikeun, hayu urang nyebutkeun yén éta ngagambarkeun rékayasa ongkosna mahal signifikan jeung operasional pikeun perusahaan anu nyobian nganggo éta.
Anu langkung parah nyaéta volume data ngagedékeun masalah wates jasa. Data anu langkung dibagikeun aya dina jasa, langkung kompleks antarmuka bakal janten sareng langkung hese pikeun ngagabungkeun set data anu asalna tina jasa anu béda.
Pendekatan alternatif pikeun ékstrak sareng mindahkeun sadaya set data ogé ngagaduhan masalah. Pendekatan umum pikeun patarosan ieu sigana ngan saukur nyandak sareng nyimpen sadaya set data, teras nyimpen sacara lokal dina unggal jasa anu dikonsumsi.
Masalahna nyaéta jasa anu béda-béda napsirkeun data anu aranjeunna konsumsi sacara béda. data ieu salawasna dina leungeun. Éta dirobih sareng diolah sacara lokal. Rada gancang aranjeunna cease mun boga nanaon di umum kalawan data dina sumber.
Beuki mutable salinan, beuki data bakal rupa-rupa kana waktu.
Anu matak parah, data sapertos kitu hese dilereskeun dina retrospect ( Ieu dimana éta leres-leres tiasa nyalametkeun). Kanyataanna, sababaraha masalah téhnologi intractable nu usaha nyanghareupan timbul tina data disparate nu multiplies ti aplikasi pikeun aplikasi.
Pikeun manggihan solusi pikeun masalah ieu, urang kudu mikir béda ngeunaan data dibagikeun. Éta kudu jadi objék kelas munggaran dina arsitéktur urang ngawangun. nyauran data sapertos "éksternal", sareng ieu mangrupikeun fitur anu penting pisan. Urang peryogi enkapsulasi supados urang henteu ngungkabkeun palayanan batin, tapi urang kedah ngagampangkeun jasa pikeun ngaksés data anu dibagikeun supados aranjeunna tiasa ngalaksanakeun tugasna kalayan leres.
Masalahna nyaéta yén pendekatan henteu relevan ayeuna, sabab henteu aya antarmuka jasa, atanapi olahtalatah, atanapi Database Dibagi nawiskeun solusi anu saé pikeun damel sareng data éksternal. Antarbeungeut jasa kirang cocog pikeun tukeur data dina skala naon waé. Olahtalatah mindahkeun data tapi teu nyimpen sajarahna, jadi data jadi ruksak kana waktu. Basis Data Dibagi museurkeun teuing kana hiji titik, anu nahan kamajuan. Urang pasti macét dina siklus kagagalan data:
Siklus gagalna data
Aliran: pendekatan desentralisasi kana data sareng jasa
Ideally, urang kudu ngarobah cara jasa dianggo kalayan data dibagikeun. Dina titik ieu, pendekatan boh nyanghareupan dikotomi disebut tadi, sabab teu aya lebu magic nu bisa sprinkled dina eta sangkan ngaleungit. Nanging, urang tiasa mikirkeun deui masalah sareng ngahontal kompromi.
Kompromi ieu ngalibatkeun tingkat sentralisasi anu tangtu. Urang tiasa nganggo mékanisme log anu disebarkeun sabab nyayogikeun aliran anu tiasa dipercaya, tiasa skala. Kami ayeuna hoyong jasa tiasa gabung sareng beroperasi dina utas anu dibagikeun ieu, tapi kami hoyong nyingkahan Layanan Allah anu terpusat anu kompleks anu ngalakukeun pamrosésan ieu. Ku alatan éta, pilihan anu pangsaéna nyaéta ngawangun pamrosésan aliran kana unggal jasa konsumen. Ku cara ieu, jasa bakal tiasa ngagabungkeun set data tina sumber anu béda sareng tiasa dianggo sareng aranjeunna dina cara anu diperyogikeun.
Salah sahiji cara pikeun ngahontal pendekatan ieu nyaéta ku ngagunakeun platform streaming. Aya seueur pilihan, tapi ayeuna urang bakal ningal Kafka, sabab pamakean Stateful Stream Processing ngamungkinkeun urang sacara efektif ngarengsekeun masalah anu dibere.
Ngagunakeun mékanisme logging disebarkeun ngamungkinkeun urang pikeun nuturkeun jalur well-trodden sarta ngagunakeun olahtalatah digawekeun ku . Pendekatan ieu dianggap nyadiakeun skala hadé tur partitioning ti mékanisme pamundut-respon sabab méré kadali aliran ka panarima tinimbang ngirim. Nanging, pikeun sadayana dina kahirupan ieu anjeun kedah mayar, sareng di dieu anjeun peryogi calo. Tapi pikeun sistem badag, trade-off patut eta (anu bisa jadi teu kasus pikeun aplikasi wéb rata anjeun).
Mun calo hiji jawab logging disebarkeun tinimbang sistem olahtalatah tradisional, Anjeun bisa ngamangpaatkeun fitur tambahan. Angkutan tiasa skala linier ampir ogé sistem file anu disebarkeun. Data tiasa disimpen dina log kanggo waktos anu lami, janten urang henteu ngan ukur tukeur pesen, tapi ogé neundeun inpormasi. Panyimpenan Scalable tanpa sieun kaayaan dibagikeun mutable.
Anjeun teras tiasa nganggo pamrosésan aliran stateful pikeun nambihan alat database déklaratif pikeun ngonsumsi jasa. Ieu mangrupikeun ide anu penting pisan. Nalika data disimpen dina aliran anu dibagikeun anu tiasa diaksés ku sadaya jasa, pangumpulan sareng pamrosésan anu dilakukeun ku jasa éta pribadi. Aranjeunna mendakan diri terasing dina kontéks anu kawates.
Ngaleungitkeun dikotomi data ku cara misahkeun aliran kaayaan anu teu bisa dirobah. Teras tambahkeun pungsi ieu ka unggal jasa nganggo Stateful Stream Processing.
Janten, upami jasa anjeun kedah damel sareng pesenan, katalog produk, gudang, éta bakal gaduh aksés pinuh: ngan anjeun bakal mutuskeun data naon anu bakal digabungkeun, dimana ngolahna sareng kumaha éta kedah robih kana waktosna. Najan kanyataan yén data dibagikeun, gawé bareng eta sagemblengna desentralisasi. Dihasilkeun dina unggal jasa, di dunya dimana sadayana saluyu sareng aturan anjeun.
Bagikeun data tanpa kompromi integritasna. Encapsulate fungsi, sanes sumberna, dina unggal jasa anu peryogi éta.
Éta kajadian yén data kedah dipindahkeun sacara masal. Kadang-kadang jasa butuh data data sajarah lokal dina mesin database anu dipilih. Trikna nyaéta anjeun tiasa ngajamin yén, upami diperyogikeun, salinan tiasa disimpen deui tina sumberna ku ngaksés mékanisme logging anu disebarkeun. Panyambung di Kafka ngalakukeun pakasaban hébat ieu.
Janten, pendekatan anu dibahas ayeuna ngagaduhan sababaraha kaunggulan:
- Data dianggo dina bentuk aliran umum, anu tiasa disimpen dina log pikeun waktos anu lami, sareng mékanisme pikeun damel sareng data umum dipasang dina unggal kontéks individu, anu ngamungkinkeun jasa tiasa dianggo kalayan gampang sareng gancang. Ku cara kieu, dikotomi data bisa saimbang.
- Data anu asalna tina jasa anu béda-béda tiasa gampang digabungkeun kana set. Ieu nyederhanakeun interaksi sareng data anu dibagikeun sareng ngaleungitkeun kabutuhan pikeun ngajaga set data lokal dina pangkalan data.
- Stateful Stream Processing ngan caches data, sarta sumber bebeneran tetep log umum, jadi masalah korupsi data kana waktu teu jadi akut.
- Dina inti maranéhanana, jasa anu data-disetir, hartina sanajan volume kantos-ngaronjatkeun data, jasa masih bisa ngabales gancang ka acara bisnis.
- Masalah skalabilitas tumiba dina calo, sanés jasa. Ieu nyata ngurangan pajeulitna jasa tulisan, saprak aya teu kudu mikir ngeunaan scalability.
- Nambahkeun ladenan anyar henteu ngabutuhkeun ngarobih anu lami, janten ngahubungkeun ladénan énggal janten langkung gampang.
Sakumaha anjeun tiasa tingali, ieu sanés ngan ukur REST. Kami parantos nampi sakumpulan alat anu ngamungkinkeun anjeun damel sareng data anu dibagikeun sacara desentralisasi.
Henteu sakabéh aspék katutupan dina artikel dinten ieu. Urang masih kedah terang kumaha kasaimbangan antara paradigma pamundut-réspon sareng paradigma anu didorong ku acara. Tapi urang bakal nungkulan ieu waktos salajengna. Aya topik anu anjeun kedah terang langkung saé, contona, naha Stateful Stream Processing saé pisan. Urang bakal ngobrol ngeunaan ieu dina artikel katilu. Sareng aya konstruk anu kuat anu tiasa urang mangpaatkeun upami urang nganggo aranjeunna, contona, . Ieu mangrupakeun changer kaulinan pikeun sistem bisnis disebarkeun sabab nyadiakeun jaminan transactional pikeun dina bentuk scalable. Ieu bakal dibahas dina artikel kaopat. Tungtungna, urang kedah ngémutan rinci palaksanaan prinsip-prinsip ieu.
Tapi pikeun ayeuna, émut ieu: dikotomi data mangrupikeun kakuatan anu urang hadapi nalika ngawangun jasa bisnis. Sareng urang kedah émut ieu. Trikna nyaéta ngahurungkeun sadayana dina sirahna sareng mimitian ngarawat data anu dibagikeun salaku objék kelas munggaran. Stateful Stream Processing nyadiakeun kompromi unik pikeun ieu. Ngahindarkeun "Komponén Allah" anu terpusat anu nahan kamajuan. Leuwih ti éta, éta ensures agility, scalability jeung resiliency data ngalirkeun pipelines tur nambahkeun kana unggal jasa. Ku alatan éta, urang tiasa difokuskeun aliran umum tina eling nu sagala jasa bisa nyambung jeung dianggo kalayan data na. Hal ieu ngajantenkeun jasa langkung skalabel, tiasa ditukeurkeun sareng otonom. Janten aranjeunna henteu ngan ukur katingali saé dina papan tulis sareng tés hipotésis, tapi ogé bakal tiasa dianggo sareng mekar mangtaun-taun.
sumber: www.habr.com