Get best of the week

Dikotomi data: memikirkan kembali hubungan dengan data dan layanan

Halo semuanya! Kami memiliki kabar baik, pada bulan Juni OTUS akan kembali meluncurkan kursus “Arsitek Perangkat Lunak” , sehubungan dengan yang secara tradisional kami bagikan materi yang bermanfaat dengan Anda.



Jika Anda menemukan seluruh cerita ini dengan layanan microser tanpa konteks apa pun, maka Anda dapat dimaafkan untuk menganggapnya sedikit aneh. Mempartisi aplikasi menjadi fragmen yang terhubung oleh jaringan, tentu saja, berarti menambahkan mode toleransi kesalahan yang kompleks ke sistem terdistribusi yang dihasilkan.

Terlepas dari kenyataan bahwa pendekatan ini mencakup pemisahan menjadi banyak layanan independen, tujuan akhir jauh lebih dari sekadar pengoperasian layanan ini pada mesin yang berbeda. Kita berbicara tentang interaksi dengan dunia luar, yang intinya juga didistribusikan. Bukan dalam pengertian teknis, melainkan dalam arti ekosistem yang terdiri dari banyak orang, tim, program, dan masing-masing bagian ini entah bagaimana harus melakukan tugasnya.

Perusahaan, misalnya, adalah seperangkat sistem terdistribusi yang bersama-sama berkontribusi pada pencapaian tujuan tertentu. Kami telah mengabaikan fakta ini selama beberapa dekade, mencoba mencapai penyatuan, mentransfer file melalui FTP atau menggunakan alat integrasi perusahaan, sembari berfokus pada tujuan pribadi kami yang terisolasi. Tetapi dengan munculnya layanan, semuanya telah berubah. Layanan telah membantu kami melihat melampaui cakrawala dan melihat dunia program yang saling bergantung yang bekerja bersama. Namun, agar dapat bekerja dengan sukses, perlu untuk mewujudkan dan merancang dua dunia yang berbeda secara mendasar: dunia luar, tempat kita hidup dalam ekosistem dari banyak layanan lain, dan pribadi kita, dunia batin, di mana kita memerintah sendiri.



Dunia yang terdistribusi seperti itu berbeda dari dunia tempat kita tumbuh dan yang biasa kita kenal. Prinsip-prinsip membangun arsitektur monolitik tradisional tidak tahan terhadap kritik. Oleh karena itu, pemahaman yang benar tentang sistem seperti itu lebih dari menciptakan diagram kelas di papan penanda putih atau bukti konsep yang keren. Ini tentang sistem yang bekerja dengan sukses untuk waktu yang lama. Untungnya, layanan telah ada selama beberapa waktu, meskipun mereka terlihat berbeda. Pelajaran SOA masih relevan, bahkan dibumbui dengan Docker, Kubernetes, dan jenggot hipster yang sedikit usang.

Jadi, hari ini kita melihat bagaimana peraturan telah berubah, mengapa kita perlu memikirkan kembali pendekatan kita terhadap layanan dan data yang mereka kirimkan satu sama lain, dan mengapa kita membutuhkan alat yang sama sekali berbeda untuk ini.

Enkapsulasi tidak akan selalu menjadi teman Anda


Layanan microser dapat bekerja secara independen satu sama lain. Properti inilah yang memberi mereka nilai terbesar. Properti yang sama memungkinkan layanan untuk tumbuh dan berkembang. Tidak begitu banyak dalam hal penskalaan ke kuadriliun pengguna atau petabyte data (meskipun di sini mereka dapat membantu), tetapi dalam hal penskalaan dari sudut pandang orang, karena tim dan organisasi tumbuh terus menerus.



Namun, kemerdekaan adalah pedang bermata dua. Artinya, layanan itu sendiri dapat berputar dengan mudah dan alami. Tetapi jika suatu fungsi diimplementasikan di dalam layanan yang membutuhkan penggunaan layanan lain, maka pada akhirnya kita harus melakukan perubahan pada kedua layanan tersebut secara hampir bersamaan. Di monolith, ini mudah dilakukan, Anda hanya membuat perubahan dan mengirimkannya ke rilis, tetapi jika Anda menyinkronkan layanan independen, akan ada lebih banyak masalah. Koordinasi antara tim dan siklus rilis menghancurkan fleksibilitas.



Sebagai bagian dari pendekatan standar, perubahan end-to-end yang mengganggu hanya dihindari, dengan jelas membagi fungsionalitas antara layanan. Layanan masuk tunggal di sini bisa menjadi contoh yang bagus. Dia memiliki peran yang jelas yang membedakannya dari layanan lain. Pemisahan yang jelas seperti itu berarti bahwa di dunia dengan persyaratan yang berubah dengan cepat untuk layanan di sekitarnya, layanan akses tunggal tidak mungkin berubah. Itu ada dalam konteks yang sangat terbatas.



Masalahnya adalah bahwa di dunia nyata, layanan bisnis tidak dapat secara konstan mempertahankan pemisahan peran yang sama bersihnya. Misalnya, layanan bisnis yang sama lebih berfungsi dengan data yang berasal dari layanan serupa lainnya. Jika Anda terlibat dalam ritel online, maka memproses aliran pesanan, katalog produk, atau informasi pengguna akan menjadi persyaratan bagi banyak layanan Anda. Setiap layanan akan membutuhkan akses ke data ini untuk berfungsi.


Sebagian besar layanan bisnis menggunakan aliran data yang sama, sehingga pekerjaan mereka selalu terjalin.

Jadi kita sampai pada poin penting yang layak dibicarakan. Sementara layanan bekerja dengan baik untuk komponen infrastruktur yang sebagian besar bekerja terpisah, sebagian besar layanan bisnis lebih saling terkait.

Dikotomi data


Pendekatan berorientasi layanan mungkin sudah ada, tetapi mereka masih memiliki sedikit informasi tentang cara bertukar data dalam jumlah besar di antara layanan.

Masalah utama adalah bahwa data dan layanan tidak dapat dipisahkan. Di satu sisi, enkapsulasi mendorong kita untuk menyembunyikan data sehingga layanan dapat dipisahkan satu sama lain dan memfasilitasi pertumbuhan dan perubahan lebih lanjut. Di sisi lain, kita harus dapat secara bebas berbagi dan mengatur data umum, serta data lainnya. Ini tentang dapat segera mulai bekerja, sebebas dalam sistem informasi lainnya.

Namun, sistem informasi tidak ada hubungannya dengan enkapsulasi. Bahkan malah sebaliknya. Database melakukan segala yang mereka bisa untuk memberikan akses ke data yang tersimpan di dalamnya. Mereka datang dengan antarmuka deklaratif yang kuat yang memungkinkan Anda untuk memodifikasi data yang Anda butuhkan. Fungsionalitas seperti itu penting pada tahap penelitian pendahuluan, tetapi tidak untuk mengelola kompleksitas layanan yang terus berkembang.



Dan di sini muncul dilema. Kontradiksi. Pembelahan dua. Bagaimanapun, sistem informasi adalah tentang menyediakan data, dan layanan adalah tentang penyembunyian.

Kedua kekuatan ini mendasar. Mereka membentuk dasar dari sebagian besar pekerjaan kami, terus-menerus berjuang untuk keunggulan dalam sistem yang kami buat.

Ketika sistem layanan tumbuh dan berkembang, kami melihat manifestasi yang berbeda dari efek dikotomi data. Entah antarmuka layanan akan tumbuh, menyediakan berbagai fungsi yang semakin luas dan akan mulai terlihat seperti database homegrown yang sangat indah, atau kami akan kecewa, dan kami akan menerapkan beberapa cara untuk mengekstraksi atau memindahkan seluruh kumpulan data secara masif dari layanan ke layanan.



Pada gilirannya, menciptakan sesuatu yang tampak seperti basis data homegrown yang indah akan menyebabkan sejumlah masalah. Kami tidak akan membahas secara terperinci apa yang berbahaya dari database bersama , cukup katakan bahwa itu merepresentasikan kesulitan teknis dan operasional yang sangat besar bagi perusahaan yang mencoba menggunakannya.

Lebih buruk lagi, volume data memperbanyak masalah dengan batas layanan. Semakin banyak data umum di dalam layanan, antarmuka akan semakin rumit dan semakin sulit untuk menggabungkan set data yang berasal dari layanan yang berbeda.

Pendekatan alternatif untuk mengekstraksi dan memindahkan seluruh set data juga memiliki masalah. Pendekatan umum untuk masalah ini terlihat seperti ekstraksi sederhana dan penyimpanan seluruh kumpulan data, dan kemudian menyimpannya secara lokal di setiap layanan konsumen.



Masalahnya adalah bahwa berbagai layanan menafsirkan data yang mereka konsumsi secara berbeda. Data ini selalu tersedia. Mereka dimodifikasi dan diproses secara lokal. Dengan cepat mereka tidak lagi memiliki kesamaan dengan data di sumbernya.


Semakin banyak salinan yang dapat diubah, semakin banyak data akan bervariasi dari waktu ke waktu.

Lebih buruk lagi, data tersebut sulit untuk diperbaiki dalam retrospeksi ( MDM dapat benar-benar datang untuk menyelamatkan di sini). Faktanya, beberapa masalah teknologi yang tidak dapat dipecahkan yang dihadapi oleh sebuah bisnis disebabkan oleh data yang beragam dari aplikasi ke aplikasi.

Untuk menemukan solusi untuk masalah ini tentang data yang dibagikan, Anda harus berpikir secara berbeda. Mereka harus menjadi objek kelas satu dalam arsitektur yang kita bangun. Pat hellandmenyebut data seperti itu "eksternal", dan ini adalah fitur yang sangat penting. Kita perlu enkapsulasi agar tidak mengekspos struktur internal layanan, tetapi kita harus memfasilitasi akses layanan ke data bersama sehingga mereka dapat melakukan pekerjaan mereka dengan benar.



Masalahnya adalah bahwa tidak ada pendekatan yang relevan saat ini, karena baik antarmuka layanan, maupun perpesanan, maupun Basis Data Bersama tidak menawarkan solusi yang baik untuk bekerja dengan data eksternal. Antarmuka layanan tidak cocok untuk bertukar data pada skala apa pun. Perpesanan memindahkan data, tetapi tidak menyimpan riwayatnya, sehingga data menjadi rusak seiring waktu. Database Bersama terlalu fokus pada satu titik, yang menghambat kemajuan. Kita pasti terjebak dalam siklus kegagalan data:


Siklus Kepailitan Data

Streaming: pendekatan desentralisasi terhadap data dan layanan


Idealnya, kita perlu mengubah pendekatan tentang bagaimana layanan bekerja dengan data bersama. Pada saat ini, pendekatan apa pun dihadapkan dengan dikotomi yang disebutkan di atas, karena tidak ada serbuk sari ajaib yang dapat ditaburi dengan murah hati dan dibuat sehingga menghilang. Namun, kami dapat memikirkan kembali masalahnya dan sampai pada kompromi.

Kompromi ini melibatkan tingkat sentralisasi. Kita dapat menggunakan mekanisme log terdistribusi karena menyediakan aliran yang dapat diskalakan yang andal. Sekarang kita membutuhkan layanan untuk dapat bergabung dan bekerja dengan benang merah ini, namun kami ingin menghindari Layanan Tuhan terpusat yang kompleks yang melakukan pemrosesan ini. Oleh karena itu, opsi terbaik adalah menanamkan pemrosesan streaming di setiap layanan konsumen. Jadi layanan akan dapat menggabungkan set data dari sumber yang berbeda dan bekerja dengan mereka sesuai kebutuhan.

Salah satu cara untuk mencapai pendekatan ini adalah dengan menggunakan platform streaming. Ada banyak opsi, tetapi hari ini kami akan mempertimbangkan Kafka, karena penggunaan Stateful Stream Processing memungkinkan kami untuk secara efektif menyelesaikan masalah yang disajikan.



Menggunakan mekanisme logging terdistribusi memungkinkan kita untuk mengikuti jalur yang dilalui dengan baik dan menggunakan pesan untuk bekerja dengan arsitektur berorientasi peristiwa . Diyakini bahwa pendekatan ini memberikan penskalaan dan pemisahan yang lebih baik daripada mekanisme permintaan-respons, karena memberikan kontrol aliran ke penerima, bukan pengirim. Namun, Anda harus membayar semuanya dalam hidup ini, dan di sini Anda membutuhkan broker. Tetapi untuk sistem besar, pertukaran ini sepadan (yang tidak dapat dikatakan tentang aplikasi web rata-rata Anda).

Jika pialang bertanggung jawab atas pendataan yang didistribusikan, dan bukan sistem pesan tradisional, Anda dapat memanfaatkan fitur tambahan. Transport dapat ditingkatkan secara linear hampir seperti halnya sistem file terdistribusi. Data dapat disimpan dalam log untuk waktu yang lama, jadi kami tidak hanya menerima pesan, tetapi juga penyimpanan informasi. Penyimpanan scalable tanpa takut keadaan umum yang bisa berubah.

Kemudian Anda dapat menggunakan mekanisme pemrosesan aliran stateful untuk menambahkan alat basis data deklaratif ke layanan konsumen. Ini adalah poin yang sangat penting. Sementara data disimpan dalam aliran bersama yang dapat diakses oleh semua layanan, pengumpulan dan pemrosesan yang dilakukan layanan bersifat pribadi. Mereka menemukan diri mereka terisolasi dalam konteks yang sangat terbatas.


Singkirkan dikotomi data dengan membagi aliran kekebalan negara. Kemudian tambahkan fitur ini ke setiap layanan menggunakan Stateful Stream Processing.

Jadi, jika layanan Anda harus bekerja dengan pesanan, katalog produk, gudang, ia akan memiliki akses penuh: hanya Anda yang akan memutuskan data apa yang akan digabungkan, di mana memprosesnya dan bagaimana harus berubah dari waktu ke waktu. Terlepas dari kenyataan bahwa data bersifat umum, bekerja dengannya sepenuhnya terdesentralisasi. Itu dibuat di dalam setiap layanan, di dunia di mana semuanya berjalan sesuai aturan Anda.


Bagikan data sehingga integritasnya tidak dilanggar. Meringkas suatu fungsi, bukan sumber, di setiap layanan yang membutuhkannya.

Kebetulan bahwa data perlu dipindahkan secara besar-besaran. Terkadang suatu layanan membutuhkan data historis lokal yang diatur dalam mesin database yang dipilih. Caranya adalah Anda dapat menjamin bahwa jika perlu, salinan dapat dipulihkan dari sumber dengan mengakses mekanisme pencatatan yang didistribusikan. Konektor di Kafka melakukan pekerjaan dengan baik.

Jadi, pendekatan yang dipertimbangkan saat ini memiliki beberapa keunggulan:

  • Data digunakan dalam bentuk aliran bersama yang dapat disimpan untuk waktu yang lama dalam log, dan mekanisme untuk bekerja dengan data bersama ditransfer dalam setiap konteks individu, yang memungkinkan layanan untuk bekerja dengan cepat dan mudah. Dengan cara ini, Anda dapat menyeimbangkan dikotomi data.
  • , , . .
  • Stateful Stream Processing , , .
  • , , , -.
  • , . , .
  • , .

Seperti yang Anda lihat, ini lebih dari sekedar SISA. Kami memiliki seperangkat alat yang memungkinkan Anda untuk bekerja dengan data bersama dengan cara yang terdesentralisasi.

Dalam artikel hari ini, tidak semua aspek diungkapkan. Kita masih perlu memutuskan bagaimana menyeimbangkan antara paradigma permintaan-respons dan paradigma yang berorientasi pada peristiwa. Tapi kita akan membahas ini lain kali. Ada beberapa topik yang perlu Anda ketahui lebih baik, misalnya, mengapa Stateful Stream Processing begitu baik. Kita akan membicarakan ini di artikel ketiga. Dan ada desain kuat lainnya yang dapat kita gunakan jika kita menggunakan mereka, misalnya, Persis Sekali Memproses . Dengan bantuannya, aturan permainan untuk sistem bisnis terdistribusi diubah, karena desain ini memberikan jaminan transaksional untuk XAdalam bentuk scalable. Ini akan dibahas dalam artikel keempat. Akhirnya, kita perlu membahas rincian implementasi prinsip-prinsip ini.



Tetapi untuk saat ini, ingat saja yang berikut ini: dikotomi data adalah kekuatan yang kita hadapi saat menciptakan layanan bisnis. Dan kita harus ingat ini. Caranya adalah membalikkan semuanya dan mulai menganggap data umum sebagai objek kelas satu. Stateful Stream Processing memberikan kompromi yang unik untuk ini. Dia menghindari "Komponen Tuhan" yang terpusat menahan kemajuan. Selain itu, ia menyediakan kecepatan, skalabilitas dan toleransi kesalahan dari pipa aliran data dan menambahkannya ke setiap layanan. Oleh karena itu, kita dapat fokus pada arus kesadaran umum, yang dapat digunakan layanan apa pun dan terhubung dengan datanya. Jadi layanan lebih terukur, dipertukarkan, dan otonom. Oleh karena itu, mereka tidak hanya akan terlihat bagus di papan tulis dan ketika menguji hipotesis,tetapi juga bekerja dan berkembang selama beberapa dekade.


.

More articles:


All Articles