Halo kabeh! Kita duwe kabar apik, OTUS ngluncurake kursus maneh ing wulan Juni , ing sambungan karo kang kita tradisional nuduhake materi migunani karo sampeyan.
Yen sampeyan nemokake kabeh microservices iki tanpa konteks, sampeyan bakal diapura amarga mikir yen rada aneh. Pamisahan aplikasi dadi pecahan sing disambungake dening jaringan tegese nambahake mode toleransi fault kompleks menyang sistem sing disebarake.
Sanajan pendekatan iki kudu dipecah dadi pirang-pirang layanan mandiri, tujuan pungkasan luwih akeh tinimbang mung nggunakake layanan kasebut ing mesin sing beda-beda. Kita ngomong ing kene babagan interaksi karo jagad njaba, sing uga disebarake ing inti. Ora ing pangertèn teknis, nanging ing pangertèn saka ekosistem sing kasusun saka akeh wong, tim, program, lan saben bagean iki piye wae kudu nindakake sawijining tugas.
Perusahaan, umpamane, minangka koleksi sistem sing disebarake sing sacara kolektif nyumbang kanggo nggayuh sawetara tujuan. Kita wis ora nggatekake kasunyatan iki sajrone pirang-pirang dekade, nyoba nggayuh penyatuan kanthi file FTPing utawa nggunakake alat integrasi perusahaan nalika fokus ing tujuan sing terpencil. Nanging kanthi tekane layanan, kabeh diganti. Layanan wis mbantu kita katon ngluwihi cakrawala lan ndeleng donya program saling gumantung sing bisa bebarengan. Nanging, kanggo bisa sukses, perlu kanggo ngenali lan ngrancang rong donya dhasar beda: donya njaba, ngendi kita manggon ing ekosistem akeh layanan liyane, lan pribadi kita, donya internal, ngendi kita mrentah piyambak.
Donya sing disebarake iki beda karo sing kita tuwuh lan wis biasa. Prinsip-prinsip mbangun arsitektur monolitik tradisional ora bisa dikritik. Dadi, nggawe sistem kasebut bener luwih saka nggawe diagram papan tulis sing apik utawa bukti konsep sing apik. Intine yaiku kanggo mesthekake yen sistem kasebut bisa digunakake kanthi sukses sajrone wektu sing suwe. Untunge, layanan kasebut wis suwe, sanajan katon beda. isih relevan, malah akeh pengalamane karo Docker, Kubernetes lan jenggot hipster rada lusuh.
Dadi dina iki, kita bakal ndeleng kepiye aturan kasebut diganti, kenapa kita kudu mikir maneh babagan cara pendekatan layanan lan data sing diterusake, lan kenapa kita butuh alat sing beda banget kanggo nindakake.
Enkapsulasi ora mesthi dadi kanca sampeyan
Microservices bisa operate independen saka saben liyane. Iki properti sing menehi nilai paling gedhe. Properti sing padha iki ngidini layanan kanggo skala lan tuwuh. Ora dadi luwih ing pangertèn skala kanggo quadrillions pangguna utawa petabyte data (sanajan sing uga bisa bantuan ana), nanging ing pangertèn saka scaling ing syarat-syarat wong minangka tim lan organisasi terus berkembang.
Kamangka, kamardikan iku pedhang kang mata loro. Tegese, layanan kasebut dhewe bisa mlaku kanthi gampang lan alami. Nanging yen fungsi dileksanakake ing layanan sing mbutuhake nggunakake layanan liyane, banjur kita kudu ngowahi kanggo loro layanan meh bebarengan. Ing monolith a iki gampang kanggo nindakake, sampeyan mung nggawe owah-owahan lan ngirim kanggo release, nanging ing cilik saka sinkronisasi layanan sawijining bakal luwih masalah. Koordinasi antarane tim lan siklus rilis ngrusak ketangkasan.
Minangka bagéan saka pendekatan standar, dheweke mung nyoba ngindhari owah-owahan end-to-end sing ngganggu, kanthi jelas misahake fungsi antarane layanan. Layanan mlebu tunggal bisa dadi conto sing apik ing kene. Nduwe peran sing jelas sing mbedakake saka layanan liyane. Pemisahan sing jelas iki tegese ing jagad sing ngalami owah-owahan kanthi cepet babagan layanan ing saubengé, layanan mlebu tunggal ora mungkin diganti. Ana ing konteks sing winates banget.
Masalahe yaiku ing jagad nyata, layanan bisnis ora bisa njaga pemisahan peran sing padha ing kabeh wektu. Contone, layanan bisnis sing padha bisa digunakake kanthi luwih akeh karo data sing teka saka layanan liyane sing padha. Yen sampeyan melu ritel online, banjur ngolah aliran pesenan, katalog produk utawa informasi pangguna bakal dadi syarat kanggo akeh layanan sampeyan. Saben layanan mbutuhake akses menyang data iki supaya bisa digunakake.
Umume layanan bisnis nuduhake aliran data sing padha, mula karyane mesthi ana hubungane.
Mangkono kita teka menyang titik penting worth ngomong bab. Nalika layanan bisa digunakake kanthi apik kanggo komponen infrastruktur sing umume beroperasi kanthi ora ana hubungane, umume layanan bisnis bakal dadi intertwined luwih raket.
Dikotomi data
Pendekatan sing berorientasi layanan bisa uga wis ana, nanging isih ora ngerti babagan cara nuduhake akeh data ing antarane layanan.
Masalah utama yaiku data lan layanan ora bisa dipisahake. Ing tangan siji, enkapsulasi nyengkuyung kita ndhelikake data supaya layanan bisa dipisahake saka siji liyane lan nggampangake wutah lan owah-owahan luwih lanjut. Ing sisih liya, kita kudu bisa kanthi bebas mbagi lan nelukake data sing dienggo bareng, kaya data liyane. Intine supaya bisa langsung kerja, kanthi bebas kaya ing sistem informasi liyane.
Nanging, sistem informasi ora ana hubungane karo enkapsulasi. Ing kasunyatan, iku cukup ngelawan. Database nindakake kabeh sing bisa kanggo nyedhiyakake akses menyang data sing disimpen. Padha teka karo antarmuka deklaratif kuat sing ngijini sampeyan kanggo ngowahi data sing perlu. Fungsi kasebut penting ing tahap riset awal, nanging ora kanggo ngatur kerumitan layanan sing terus berkembang.
Lan ing kene ana dilema. Kontradiksi. Dikotomi. Sawise kabeh, sistem informasi babagan nyedhiyakake data, lan layanan babagan ndhelikake.
Loro pasukan iki dhasar. Dheweke ndhukung akeh karya kita, terus berjuang kanggo keunggulan ing sistem sing dibangun.
Nalika sistem layanan tuwuh lan berkembang, kita ndeleng akibat saka dikotomi data kanthi akeh cara. Antarmuka layanan bakal tuwuh, nyedhiyakake macem-macem fungsi sing saya tambah lan wiwit katon kaya database asli sing apik banget, utawa kita bakal dadi frustasi lan ngetrapake sawetara cara kanggo njupuk utawa mindhah kabeh set data saka layanan menyang layanan.
Sabanjure, nggawe sing katon kaya database homegrown sing apik bakal nyebabake akeh masalah. Kita ora bakal njlentrehake apa sebabe mbebayani basis data sing dienggo bareng, ayo ngomong yen iki nggambarake teknik lan operasional sing larang regane kanggo perusahaan sing nyoba nggunakake.
Sing luwih elek yaiku volume data nggedhekake masalah wates layanan. Data sing luwih akeh dienggo bareng ana ing layanan, antarmuka sing luwih rumit bakal dadi lan luwih angel kanggo nggabungake set data sing teka saka layanan sing beda-beda.
Pendekatan alternatif kanggo ngekstrak lan mindhah kabeh set data uga duwe masalah. Pendekatan umum kanggo pitakonan iki katon kaya mung njupuk lan nyimpen kabeh dataset, lan banjur nyimpen sacara lokal ing saben layanan sing dikonsumsi.
Masalahe yaiku layanan sing beda-beda napsirake data sing digunakake kanthi beda. Data iki tansah ana ing tangan. Padha diowahi lan diproses sacara lokal. Cukup cepet padha mandek kanggo duwe apa-apa ing umum karo data ing sumber.
Sing liyane mutable salinan, liyane data bakal beda-beda saka wektu.
Sing luwih elek, data kasebut angel dibenerake kanthi retrospeksi ( Iki ngendi tenan bisa teka kanggo ngluwari). Nyatane, sawetara masalah teknologi sing ora bisa ditindakake bisnis muncul saka data sing beda-beda sing tambah akeh saka aplikasi menyang aplikasi.
Kanggo nemokake solusi kanggo masalah iki, kita kudu mikir kanthi beda babagan data sing dienggo bareng. Padha kudu dadi obyek kelas kapisan ing arsitektur kita mbangun. nelpon data kasebut "eksternal", lan iki minangka fitur sing penting banget. Kita butuh enkapsulasi supaya ora nuduhake cara kerja njero layanan, nanging kita kudu nggampangake layanan ngakses data sing dienggo bareng supaya bisa nindakake pakaryan kanthi bener.
Masalahe yaiku ora ana pendekatan sing relevan saiki, amarga ora ana antarmuka layanan, utawa olahpesen, utawa Database Shared sing menehi solusi sing apik kanggo nggarap data eksternal. Antarmuka layanan ora cocog kanggo ijol-ijolan data ing skala apa wae. Olahpesen mindhah data nanging ora nyimpen riwayate, mula data dadi rusak liwat wektu. Basis Data Bersama fokus banget ing siji titik, sing nahan kemajuan. Kita mesthi bakal macet ing siklus kegagalan data:
Siklus kegagalan data
Aliran: pendekatan desentralisasi kanggo data lan layanan
Saenipun, kita kudu ngganti cara layanan bisa digunakake karo data sing dienggo bareng. Ing titik iki, salah siji pendekatan ngadhepi dikotomi kasebut, amarga ora ana bledug sihir sing bisa disiram supaya bisa ilang. Nanging, kita bisa mikir maneh masalah kasebut lan entuk kompromi.
Kompromi iki kalebu tingkat sentralisasi tartamtu. Kita bisa nggunakake mekanisme log sing disebarake amarga nyedhiyakake aliran sing bisa dipercaya lan bisa diukur. Saiki kita pengin layanan bisa nggabungake lan ngoperasikake utas sing dienggo bareng iki, nanging kita pengin ngindhari Layanan Dewa terpusat sing kompleks sing nindakake proses iki. Mulane, pilihan sing paling apik yaiku mbangun pangolahan stream menyang saben layanan konsumen. Kanthi cara iki, layanan bakal bisa nggabungake set data saka macem-macem sumber lan bisa digunakake kanthi cara sing dibutuhake.
Salah sawijining cara kanggo entuk pendekatan iki yaiku nggunakake platform streaming. Ana akeh pilihan, nanging dina iki kita bakal katon ing Kafka, amarga nggunakake Stateful Stream Processing ngidini kita kanggo èfèktif ngatasi masalah presented.
Nggunakake mekanisme logging sing disebarake ngidini kita ngetutake dalan sing apik lan nggunakake olahpesen kanggo nggarap . Pendekatan iki dianggep nyedhiyakake skala lan pemisahan sing luwih apik tinimbang mekanisme panjalukan-respon amarga menehi kontrol aliran menyang panrima tinimbang pangirim. Nanging, kanggo kabeh ing urip iki sampeyan kudu mbayar, lan kene sampeyan kudu makelar. Nanging kanggo sistem gedhe, trade-off worth iku (sing bisa uga ora kanggo aplikasi web rata-rata).
Yen broker tanggung jawab kanggo mbagekke logging tinimbang sistem olahpesen tradisional, sampeyan bisa njupuk kauntungan saka fitur tambahan. Transportasi bisa ukuran linear meh uga minangka sistem file sing disebarake. Data bisa disimpen ing log kanggo wektu sing cukup suwe, mula ora mung ijol-ijolan pesen, nanging uga panyimpenan informasi. Panyimpenan sing bisa diukur tanpa wedi karo negara sing bisa diowahi.
Sampeyan banjur bisa nggunakake pamrosesan stream stateful kanggo nambah alat database deklaratif kanggo nggunakake layanan. Iki minangka gagasan sing penting banget. Nalika data disimpen ing aliran sing dienggo bareng sing bisa diakses kabeh layanan, panggabungan lan pangolahan sing ditindakake layanan kasebut pribadi. Dheweke nemokake awake dhewe diisolasi ing konteks sing winates.
Ngilangi dikotomi data kanthi misahake aliran negara sing ora bisa diganti. Banjur tambahake fungsi iki kanggo saben layanan nggunakake Stateful Stream Processing.
Mangkono, yen layanan sampeyan kudu nggarap pesenan, katalog produk, gudang, bakal duwe akses lengkap: mung sampeyan bakal mutusake apa data sing bakal digabungake, ing ngendi proses kasebut lan carane kudu diganti liwat wektu. Senadyan kasunyatan manawa data kasebut dienggo bareng, nggarap kanthi lengkap desentralisasi. Diprodhuksi ing saben layanan, ing jagad sing kabeh miturut aturan sampeyan.
Nuduhake data tanpa kompromi integritas. Encapsulate fungsi, dudu sumber, ing saben layanan sing mbutuhake.
Iku kedadeyan yen data kudu dipindhah kanthi massal. Kadhangkala layanan mbutuhake dataset historis lokal ing mesin database sing dipilih. Trik kasebut yaiku sampeyan bisa njamin yen, yen perlu, salinan bisa dipulihake saka sumber kanthi ngakses mekanisme logging sing disebarake. Konektor ing Kafka nindakake proyek apik iki.
Dadi, pendekatan sing dibahas saiki duwe sawetara kaluwihan:
- Data digunakake ing wangun stream umum, kang bisa disimpen ing log kanggo dangu, lan mekanisme kanggo nggarap data umum hardwired ing saben konteks individu, sing ngidini layanan bisa gampang lan cepet. Kanthi cara iki, dikotomi data bisa seimbang.
- Data sing teka saka macem-macem layanan bisa gampang digabung dadi set. Iki nyederhanakake interaksi karo data sing dienggo bareng lan ngilangi kabutuhan kanggo njaga dataset lokal ing basis data.
- Stateful Stream Processing mung caches data, lan sumber bebener tetep log umum, supaya masalah korupsi data liwat wektu ora dadi akut.
- Intine, layanan adhedhasar data, tegese sanajan volume data saya tambah akeh, layanan isih bisa nanggapi kanthi cepet kanggo acara bisnis.
- Masalah skalabilitas tiba ing broker, dudu layanan. Iki kanthi signifikan nyuda kerumitan layanan nulis, amarga ora perlu mikir babagan skalabilitas.
- Nambah layanan anyar ora mbutuhake ngganti sing lawas, supaya nyambungake layanan anyar dadi luwih gampang.
Kaya sing sampeyan ngerteni, iki luwih saka REST. Kita wis nampa sakumpulan alat sing ngidini sampeyan nggarap data sing dienggo bareng kanthi cara desentralisasi.
Ora kabeh aspek wis dibahas ing artikel dina iki. Kita isih kudu ngerteni carane ngimbangi antarane paradigma nanggepi panjaluk lan paradigma sing didorong acara. Nanging kita bakal ngatasi iki ing wektu sabanjure. Ana topik sing sampeyan kudu ngerti, contone, kenapa Stateful Stream Processing apik banget. Kita bakal ngomong babagan iki ing artikel katelu. Lan ana konstruksi kuat liyane sing bisa kita gunakake yen kita nggunakake, contone, . Iku game changer kanggo sistem bisnis mbagekke amarga menehi njamin transactional kanggo ing wangun scalable. Iki bakal dirembug ing artikel kaping papat. Pungkasan, kita kudu nliti rincian implementasi prinsip kasebut.
Nanging saiki, mung elinga iki: dikotomi data minangka kekuwatan sing kita adhepi nalika mbangun layanan bisnis. Lan kita kudu ngelingi iki. Trik iku kanggo nguripake kabeh ing sirah lan miwiti nambani data sambungan minangka obyek kelas siji. Stateful Stream Processing menehi kompromi unik kanggo iki. Ngindhari "Komponèn Gusti" sing terpusat sing nahan kemajuan. Kajaba iku, njamin ketangkasan, skalabilitas lan ketahanan pipa streaming data lan ditambahake ing saben layanan. Mula, kita bisa fokus ing aliran kesadaran umum sing bisa disambungake lan digunakake dening layanan apa wae. Iki ndadekake layanan luwih bisa diukur, bisa diganti lan otonom. Dadi ora mung katon apik ing papan tulis lan tes hipotesis, nanging uga bakal bisa digunakake lan berkembang nganti pirang-pirang dekade.
Source: www.habr.com