Dikotomi data: memikirkan semula hubungan antara data dan perkhidmatan

Hai semua! Kami ada berita baik, OTUS akan melancarkan kursus sekali lagi pada bulan Jun "Arkitek Perisian", yang berkaitan dengannya kami berkongsi bahan berguna secara tradisional dengan anda.

Jika anda telah menjumpai keseluruhan perkhidmatan mikro ini tanpa sebarang konteks, anda akan dimaafkan kerana menganggap ia agak pelik. Memisahkan aplikasi kepada serpihan yang disambungkan oleh rangkaian semestinya bermakna menambah mod toleransi kesalahan kompleks kepada sistem teragih yang terhasil.

Walaupun pendekatan ini melibatkan pembahagiannya kepada banyak perkhidmatan bebas, matlamat akhirnya adalah lebih daripada sekadar memastikan perkhidmatan tersebut dijalankan pada mesin yang berbeza. Kami bercakap di sini tentang interaksi dengan dunia luar, yang juga diedarkan pada intinya. Bukan dalam erti kata teknikal, sebaliknya dalam erti kata ekosistem yang terdiri daripada ramai orang, pasukan, program, dan setiap bahagian ini entah bagaimana perlu melakukan tugasnya.

Syarikat, sebagai contoh, adalah koleksi sistem teragih yang secara kolektif menyumbang kepada pencapaian beberapa matlamat. Kami telah mengabaikan fakta ini selama beberapa dekad, cuba mencapai penyatuan melalui fail FTPing atau menggunakan alat penyepaduan perusahaan sambil memfokuskan pada matlamat terpencil kami sendiri. Tetapi dengan adanya perkhidmatan, segala-galanya berubah. Perkhidmatan telah membantu kami melihat melampaui ufuk dan melihat dunia program yang saling bergantung yang berfungsi bersama. Walau bagaimanapun, untuk bekerja dengan jayanya, adalah perlu untuk mengenali dan mereka bentuk dua dunia yang pada asasnya berbeza: dunia luaran, tempat kita hidup dalam ekosistem banyak perkhidmatan lain, dan dunia dalaman peribadi kita, di mana kita memerintah bersendirian.

Dunia yang diedarkan ini berbeza daripada dunia yang kita dibesarkan dan biasa. Prinsip membina seni bina monolitik tradisional tidak tahan dengan kritikan. Jadi membetulkan sistem ini adalah lebih daripada mencipta gambar rajah papan putih yang hebat atau bukti konsep yang menarik. Intinya adalah untuk memastikan sistem sedemikian beroperasi dengan jayanya dalam jangka masa yang panjang. Nasib baik, perkhidmatan itu telah wujud untuk sekian lama, walaupun ia kelihatan berbeza. Pelajaran SOA masih relevan, malah dibumbui dengan Docker, Kubernetes dan janggut hipster yang sedikit lusuh.

Jadi hari ini kita akan melihat bagaimana peraturan telah berubah, mengapa kita perlu memikirkan semula cara kita mendekati perkhidmatan dan data yang mereka salurkan kepada satu sama lain, dan mengapa kita memerlukan alat yang berbeza untuk melakukannya.

Enkapsulasi tidak akan sentiasa menjadi rakan anda

Perkhidmatan mikro boleh beroperasi secara bebas antara satu sama lain. Harta inilah yang memberikan nilai terbesar kepada mereka. Harta yang sama ini membolehkan perkhidmatan meningkat dan berkembang. Tidak begitu banyak dalam erti kata menskalakan kepada empat empat pengguna atau petabait data (walaupun mereka juga boleh membantu di sana), tetapi dalam erti kata penskalaan dari segi orang apabila pasukan dan organisasi berkembang secara berterusan.

Namun, kemerdekaan adalah pedang bermata dua. Iaitu, perkhidmatan itu sendiri boleh berjalan dengan mudah dan semula jadi. Tetapi jika fungsi dilaksanakan dalam perkhidmatan yang memerlukan penggunaan perkhidmatan lain, maka kami akhirnya terpaksa membuat perubahan pada kedua-dua perkhidmatan hampir serentak. Dalam monolit ini mudah dilakukan, anda hanya membuat perubahan dan menghantarnya untuk dikeluarkan, tetapi dalam hal menyegerakkan perkhidmatan bebas akan ada lebih banyak masalah. Penyelarasan antara pasukan dan kitaran pelepasan memusnahkan ketangkasan.

Sebagai sebahagian daripada pendekatan standard, mereka hanya cuba mengelakkan perubahan hujung ke hujung yang menjengkelkan, dengan jelas membahagikan fungsi antara perkhidmatan. Perkhidmatan log masuk tunggal boleh menjadi contoh yang baik di sini. Ia mempunyai peranan yang jelas yang membezakannya daripada perkhidmatan lain. Pemisahan yang jelas ini bermakna bahawa dalam dunia permintaan yang berubah dengan pantas terhadap perkhidmatan di sekelilingnya, perkhidmatan log masuk tunggal tidak mungkin berubah. Ia wujud dalam konteks yang sangat terhad.

Masalahnya ialah dalam dunia nyata, perkhidmatan perniagaan tidak dapat mengekalkan pemisahan peranan yang sama sepanjang masa. Sebagai contoh, perkhidmatan perniagaan yang sama berfungsi pada tahap yang lebih besar dengan data yang datang daripada perkhidmatan lain yang serupa. Jika anda terlibat dalam peruncitan dalam talian, maka memproses aliran pesanan, katalog produk atau maklumat pengguna akan menjadi keperluan untuk kebanyakan perkhidmatan anda. Setiap perkhidmatan memerlukan akses kepada data ini untuk beroperasi.

Kebanyakan perkhidmatan perniagaan berkongsi aliran data yang sama, jadi kerja mereka sentiasa saling berkaitan.

Oleh itu kita sampai ke satu perkara penting yang patut dibincangkan. Walaupun perkhidmatan berfungsi dengan baik untuk komponen infrastruktur yang sebahagian besarnya beroperasi secara berasingan, kebanyakan perkhidmatan perniagaan akhirnya saling berkait rapat.

Dikotomi data

Pendekatan berorientasikan perkhidmatan mungkin sudah wujud, tetapi pendekatan tersebut masih kurang cerapan tentang cara berkongsi sejumlah besar data antara perkhidmatan.

Masalah utama ialah data dan perkhidmatan tidak dapat dipisahkan. Di satu pihak, enkapsulasi menggalakkan kami menyembunyikan data supaya perkhidmatan boleh dipisahkan antara satu sama lain dan memudahkan pertumbuhan dan perubahan selanjutnya. Sebaliknya, kita perlu bebas membahagikan dan menakluki data yang dikongsi, sama seperti data lain. Intinya adalah untuk dapat mula bekerja dengan segera, sebebas dalam mana-mana sistem maklumat lain.

Walau bagaimanapun, sistem maklumat mempunyai sedikit kaitan dengan enkapsulasi. Malah, ia adalah sebaliknya. Pangkalan data melakukan segala yang mereka mampu untuk menyediakan akses kepada data yang mereka simpan. Mereka datang dengan antara muka deklaratif yang berkuasa yang membolehkan anda mengubah suai data mengikut keperluan anda. Kefungsian sedemikian penting pada peringkat penyelidikan awal, tetapi bukan untuk mengurus kerumitan perkhidmatan yang sentiasa berkembang.

Dan di sini timbul dilema. Percanggahan. Dikotomi. Lagipun, sistem maklumat adalah mengenai menyediakan data, dan perkhidmatan adalah mengenai bersembunyi.

Kedua-dua kuasa ini adalah asas. Mereka menyokong kebanyakan kerja kami, sentiasa berjuang untuk kecemerlangan dalam sistem yang kami bina.

Apabila sistem perkhidmatan berkembang dan berkembang, kami melihat akibat dikotomi data dalam pelbagai cara. Sama ada antara muka perkhidmatan akan berkembang, menyediakan rangkaian kefungsian yang semakin meningkat dan mula kelihatan seperti pangkalan data tempatan yang sangat mewah, atau kami akan menjadi kecewa dan melaksanakan beberapa cara untuk mendapatkan atau memindahkan keseluruhan set data secara besar-besaran daripada perkhidmatan ke perkhidmatan.

Sebaliknya, mencipta sesuatu yang kelihatan seperti pangkalan data tempatan yang mewah akan membawa kepada pelbagai masalah. Kami tidak akan menjelaskan secara terperinci mengapa ia berbahaya pangkalan data yang dikongsi, katakan sahaja bahawa ia mewakili kejuruteraan dan operasi yang memerlukan kos yang ketara kesukaran untuk syarikat yang cuba menggunakannya.

Apa yang lebih teruk ialah volum data membesarkan masalah sempadan perkhidmatan. Lebih banyak data dikongsi terletak dalam perkhidmatan, antara muka akan menjadi lebih kompleks dan lebih sukar untuk menggabungkan set data yang datang daripada perkhidmatan yang berbeza.

Pendekatan alternatif untuk mengekstrak dan memindahkan keseluruhan set data juga mempunyai masalahnya. Pendekatan biasa untuk soalan ini kelihatan seperti hanya mendapatkan semula dan menyimpan keseluruhan set data, dan kemudian menyimpannya secara setempat dalam setiap perkhidmatan yang digunakan.

Masalahnya ialah perkhidmatan yang berbeza mentafsir data yang mereka gunakan secara berbeza. Data ini sentiasa ada. Ia diubah suai dan diproses secara tempatan. Dengan cepat mereka tidak lagi mempunyai apa-apa persamaan dengan data dalam sumber.

Lebih banyak salinan yang boleh diubah, lebih banyak data akan berubah mengikut masa.

Lebih memburukkan lagi keadaan, data sedemikian sukar untuk dibetulkan apabila dilihat semula (MDM Di sinilah ia benar-benar boleh datang untuk menyelamatkan). Malah, beberapa masalah teknologi yang sukar diatasi yang dihadapi oleh perniagaan timbul daripada data yang berbeza yang berganda dari aplikasi ke aplikasi.

Untuk mencari penyelesaian kepada masalah ini, kita perlu berfikir secara berbeza tentang data yang dikongsi. Mereka mesti menjadi objek kelas pertama dalam seni bina yang kami bina. Pat Helland memanggil data sedemikian "luaran", dan ini adalah ciri yang sangat penting. Kami memerlukan enkapsulasi supaya kami tidak mendedahkan kerja dalaman sesuatu perkhidmatan, tetapi kami perlu memudahkan perkhidmatan mengakses data kongsi supaya mereka boleh melakukan tugas mereka dengan betul.

Masalahnya ialah pendekatan tidak relevan hari ini, kerana antara muka perkhidmatan, pemesejan, mahupun Pangkalan Data Dikongsi tidak menawarkan penyelesaian yang baik untuk bekerja dengan data luaran. Antara muka perkhidmatan kurang sesuai untuk pertukaran data pada sebarang skala. Pemesejan memindahkan data tetapi tidak menyimpan sejarahnya, jadi data menjadi rosak dari semasa ke semasa. Pangkalan Data Kongsi terlalu menumpukan pada satu titik, yang menghalang kemajuan. Kami pasti akan terperangkap dalam kitaran kegagalan data:

Kitaran kegagalan data

Strim: pendekatan terpencar kepada data dan perkhidmatan

Sebaik-baiknya, kita perlu mengubah cara perkhidmatan berfungsi dengan data yang dikongsi. Pada ketika ini, mana-mana pendekatan menghadapi dikotomi yang disebutkan di atas, kerana tiada habuk ajaib yang boleh ditaburkan di atasnya untuk menghilangkannya. Walau bagaimanapun, kita boleh memikirkan semula masalah dan mencapai kompromi.

Kompromi ini melibatkan tahap pemusatan tertentu. Kita boleh menggunakan mekanisme log teragih kerana ia menyediakan aliran yang boleh dipercayai dan boleh skala. Kami kini mahu perkhidmatan dapat menyertai dan beroperasi pada rangkaian kongsi ini, tetapi kami mahu mengelakkan Perkhidmatan Tuhan terpusat yang kompleks yang melakukan pemprosesan ini. Oleh itu, pilihan terbaik ialah membina pemprosesan aliran ke dalam setiap perkhidmatan pengguna. Dengan cara ini, perkhidmatan akan dapat menggabungkan set data daripada sumber yang berbeza dan berfungsi dengan mereka mengikut cara yang mereka perlukan.

Satu cara untuk mencapai pendekatan ini adalah melalui penggunaan platform penstriman. Terdapat banyak pilihan, tetapi hari ini kita akan melihat Kafka, kerana penggunaan Pemprosesan Strim Stateful membolehkan kita menyelesaikan masalah yang dibentangkan dengan berkesan.

Menggunakan mekanisme pengelogan yang diedarkan membolehkan kami mengikuti laluan yang dilalui dengan baik dan menggunakan pemesejan untuk bekerja dengannya seni bina yang didorong oleh peristiwa. Pendekatan ini dianggap memberikan penskalaan dan pembahagian yang lebih baik daripada mekanisme tindak balas permintaan kerana ia memberikan kawalan aliran kepada penerima dan bukannya penghantar. Walau bagaimanapun, untuk segala-galanya dalam kehidupan ini anda perlu membayar, dan di sini anda memerlukan broker. Tetapi untuk sistem yang besar, pertukaran adalah berbaloi (yang mungkin tidak berlaku untuk aplikasi web purata anda).

Jika broker bertanggungjawab untuk pengelogan teragih dan bukannya sistem pemesejan tradisional, anda boleh memanfaatkan ciri tambahan. Pengangkutan boleh berskala secara linear hampir seperti sistem fail yang diedarkan. Data boleh disimpan dalam log untuk masa yang agak lama, jadi kami bukan sahaja mendapat pertukaran mesej, tetapi juga penyimpanan maklumat. Storan boleh berskala tanpa rasa takut akan keadaan perkongsian boleh ubah.

Anda kemudiannya boleh menggunakan pemprosesan strim stateful untuk menambah alat pangkalan data deklaratif untuk menggunakan perkhidmatan. Ini adalah idea yang sangat penting. Walaupun data disimpan dalam strim kongsi yang boleh diakses oleh semua perkhidmatan, pengagregatan dan pemprosesan yang dilakukan oleh perkhidmatan adalah peribadi. Mereka mendapati diri mereka terpencil dalam konteks yang sangat terhad.

Hapuskan dikotomi data dengan memisahkan aliran keadaan tidak berubah. Kemudian tambahkan fungsi ini pada setiap perkhidmatan menggunakan Pemprosesan Strim Stateful.

Oleh itu, jika perkhidmatan anda perlu berfungsi dengan pesanan, katalog produk, gudang, ia akan mempunyai akses penuh: hanya anda yang akan memutuskan data yang hendak digabungkan, tempat memprosesnya dan bagaimana ia harus berubah dari semasa ke semasa. Walaupun fakta bahawa data itu dikongsi, bekerja dengannya adalah terdesentralisasi sepenuhnya. Ia dihasilkan dalam setiap perkhidmatan, dalam dunia yang semuanya berjalan mengikut peraturan anda.

Kongsi data tanpa menjejaskan integritinya. Merangkumkan fungsi, bukan sumber, dalam setiap perkhidmatan yang memerlukannya.

Ia berlaku bahawa data perlu dipindahkan secara beramai-ramai. Kadangkala perkhidmatan memerlukan set data sejarah tempatan dalam enjin pangkalan data yang dipilih. Caranya ialah anda boleh menjamin bahawa, jika perlu, salinan boleh dipulihkan daripada sumber dengan mengakses mekanisme pembalakan yang diedarkan. Penyambung di Kafka melakukan kerja yang hebat dalam hal ini.

Jadi, pendekatan yang dibincangkan hari ini mempunyai beberapa kelebihan:

• Data digunakan dalam bentuk strim biasa, yang boleh disimpan dalam log untuk masa yang lama, dan mekanisme untuk bekerja dengan data biasa dirangkai dalam setiap konteks individu, yang membolehkan perkhidmatan berfungsi dengan mudah dan cepat. Dengan cara ini, dikotomi data dapat diseimbangkan.
• Data yang datang daripada perkhidmatan yang berbeza boleh digabungkan dengan mudah menjadi set. Ini memudahkan interaksi dengan data kongsi dan menghapuskan keperluan untuk mengekalkan set data tempatan dalam pangkalan data.
• Pemprosesan Strim Stateful hanya menyimpan cache data, dan sumber kebenaran kekal sebagai log umum, jadi masalah rasuah data dari masa ke masa tidak begitu meruncing.
• Pada terasnya, perkhidmatan adalah didorong data, bermakna walaupun jumlah data yang semakin meningkat, perkhidmatan masih boleh bertindak balas dengan cepat kepada acara perniagaan.
• Isu kebolehskalaan jatuh pada broker, bukan perkhidmatan. Ini dengan ketara mengurangkan kerumitan perkhidmatan penulisan, kerana tidak perlu memikirkan tentang kebolehskalaan.
• Menambah perkhidmatan baharu tidak memerlukan menukar perkhidmatan lama, jadi menyambungkan perkhidmatan baharu menjadi lebih mudah.

Seperti yang anda lihat, ini lebih daripada REHAT. Kami telah menerima satu set alat yang membolehkan anda bekerja dengan data yang dikongsi secara terpencar.

Tidak semua aspek dibincangkan dalam artikel hari ini. Kita masih perlu memikirkan cara untuk mengimbangi antara paradigma tindak balas permintaan dan paradigma dipacu peristiwa. Tetapi kita akan berurusan dengan ini lain kali. Terdapat topik yang perlu anda ketahui dengan lebih baik, contohnya, mengapa Pemprosesan Strim Stateful sangat bagus. Kami akan membincangkan perkara ini dalam artikel ketiga. Dan terdapat binaan berkuasa lain yang boleh kita manfaatkan jika kita menggunakan mereka, sebagai contoh, Tepat Sekali Diproses. Ia adalah pengubah permainan untuk sistem perniagaan yang diedarkan kerana ia menyediakan jaminan transaksi untuk XA dalam bentuk berskala. Ini akan dibincangkan dalam artikel keempat. Akhir sekali, kita perlu menyemak butiran pelaksanaan prinsip ini.

Tetapi buat masa ini, ingatlah perkara ini: dikotomi data ialah kuasa yang kita hadapi semasa membina perkhidmatan perniagaan. Dan kita mesti ingat ini. Caranya adalah untuk menghidupkan segala-galanya dan mula merawat data yang dikongsi sebagai objek kelas pertama. Pemprosesan Strim Stateful menyediakan kompromi unik untuk ini. Ia mengelakkan "Komponen Tuhan" berpusat yang menghalang kemajuan. Selain itu, ia memastikan ketangkasan, skalabiliti dan daya tahan saluran paip penstriman data dan menambahkannya pada setiap perkhidmatan. Oleh itu, kita boleh menumpukan pada aliran kesedaran umum yang mana mana-mana perkhidmatan boleh menyambung dan berfungsi dengan datanya. Ini menjadikan perkhidmatan lebih berskala, boleh ditukar ganti dan berautonomi. Jadi mereka bukan sahaja akan kelihatan baik pada papan putih dan ujian hipotesis, tetapi mereka juga akan berfungsi dan berkembang selama beberapa dekad.

Ketahui lebih lanjut tentang kursus.

Sumber: www.habr.com