Halo semua! Kami punya kabar gembira, OTUS akan meluncurkan kursus ini lagi pada bulan Juni , sehubungan dengan itu kami secara tradisional membagikan materi bermanfaat kepada Anda.
Jika Anda menemukan seluruh layanan mikro ini tanpa konteks apa pun, Anda akan dimaafkan jika menganggapnya sedikit aneh. Memisahkan aplikasi menjadi beberapa bagian yang dihubungkan oleh jaringan berarti menambahkan mode toleransi kesalahan yang kompleks ke sistem terdistribusi yang dihasilkan.
Meskipun pendekatan ini melibatkan pemecahannya menjadi banyak layanan independen, tujuan akhirnya lebih dari sekadar menjalankan layanan tersebut di mesin yang berbeda. Di sini kita berbicara tentang interaksi dengan dunia luar, yang pada hakikatnya juga meluas. Bukan dalam arti teknis, melainkan dalam arti ekosistem yang terdiri dari banyak orang, tim, program, dan masing-masing bagian ini perlu melakukan tugasnya.
Perusahaan, misalnya, adalah kumpulan sistem terdistribusi yang secara kolektif berkontribusi terhadap pencapaian beberapa tujuan. Kami telah mengabaikan fakta ini selama beberapa dekade, mencoba mencapai penyatuan dengan melakukan FTP file atau menggunakan alat integrasi perusahaan sambil berfokus pada tujuan kami sendiri. Namun dengan munculnya layanan, segalanya berubah. Layanan telah membantu kita melihat melampaui cakrawala dan melihat dunia dengan program-program yang saling bergantung dan bekerja sama. Namun, agar dapat bekerja dengan sukses, kita perlu mengenali dan merancang dua dunia yang berbeda secara fundamental: dunia eksternal, tempat kita hidup dalam ekosistem yang terdiri dari banyak layanan lain, dan dunia pribadi dan internal, tempat kita memerintah sendiri.
Dunia terdistribusi ini berbeda dari dunia tempat kita tumbuh dan terbiasa. Prinsip-prinsip membangun arsitektur monolitik tradisional tidak dapat dikritik. Jadi memperbaiki sistem ini lebih dari sekadar membuat diagram papan tulis yang keren atau bukti konsep yang keren. Intinya adalah untuk memastikan bahwa sistem tersebut beroperasi dengan sukses dalam jangka waktu yang lama. Untungnya, layanan ini sudah ada sejak lama, meskipun tampilannya berbeda. masih relevan, bahkan dibumbui dengan Docker, Kubernetes, dan janggut hipster yang sedikit lusuh.
Jadi hari ini kita akan melihat bagaimana peraturan telah berubah, mengapa kita perlu memikirkan kembali cara kita mendekati layanan dan data yang mereka sampaikan satu sama lain, dan mengapa kita memerlukan alat yang sangat berbeda untuk melakukannya.
Enkapsulasi tidak selalu menjadi teman Anda
Layanan mikro dapat beroperasi secara independen satu sama lain. Properti inilah yang memberi mereka nilai terbesar. Properti yang sama ini memungkinkan layanan untuk berkembang dan berkembang. Bukan dalam artian menskalakan hingga kuadriliun pengguna atau petabyte data (walaupun hal ini juga dapat membantu), namun dalam artian menskalakan sumber daya manusia seiring dengan pertumbuhan tim dan organisasi yang terus menerus.
Namun kemerdekaan adalah pedang bermata dua. Artinya, layanannya sendiri bisa berjalan dengan mudah dan natural. Namun jika suatu fungsi diimplementasikan dalam suatu layanan yang memerlukan penggunaan layanan lain, maka pada akhirnya kita harus melakukan perubahan pada kedua layanan tersebut hampir secara bersamaan. Dalam monolit hal ini mudah dilakukan, Anda cukup membuat perubahan dan mengirimkannya untuk dirilis, tetapi dalam kasus sinkronisasi layanan independen akan ada lebih banyak masalah. Koordinasi antar tim dan siklus pelepasan menghancurkan ketangkasan.
Sebagai bagian dari pendekatan standar, mereka hanya mencoba menghindari perubahan ujung ke ujung yang mengganggu, dengan jelas membagi fungsionalitas antar layanan. Layanan sistem masuk tunggal dapat menjadi contoh yang baik di sini. Ini memiliki peran yang jelas yang membedakannya dari layanan lain. Pemisahan yang jelas ini berarti bahwa dalam dunia dengan permintaan layanan di sekitarnya yang berubah dengan cepat, layanan sistem masuk tunggal kemungkinan besar tidak akan berubah. Ia ada dalam konteks yang sangat terbatas.
Masalahnya adalah di dunia nyata, layanan bisnis tidak dapat mempertahankan pemisahan peran yang sama sepanjang waktu. Misalnya, layanan bisnis yang sama berfungsi lebih baik dengan data yang berasal dari layanan serupa lainnya. Jika Anda terlibat dalam ritel online, maka alur pemrosesan pesanan, katalog produk, atau informasi pengguna akan menjadi persyaratan untuk banyak layanan Anda. Setiap layanan memerlukan akses ke data ini agar dapat beroperasi.
Sebagian besar layanan bisnis berbagi aliran data yang sama, sehingga pekerjaan mereka selalu saling terkait.
Jadi kita sampai pada poin penting yang layak untuk dibicarakan. Meskipun layanan berfungsi dengan baik untuk komponen infrastruktur yang sebagian besar beroperasi secara terpisah, sebagian besar layanan bisnis pada akhirnya saling terkait lebih erat.
Dikotomi data
Pendekatan berorientasi layanan mungkin sudah ada, namun pendekatan tersebut masih kurang memahami cara berbagi data dalam jumlah besar antar layanan.
Permasalahan utamanya adalah 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 bisa dengan bebas membagi dan menaklukkan data bersama, sama seperti data lainnya. Intinya adalah untuk dapat segera mulai bekerja, sebebas di sistem informasi lainnya.
Namun, sistem informasi tidak ada hubungannya dengan enkapsulasi. Faktanya, justru sebaliknya. Basis data melakukan apa saja untuk menyediakan akses ke data yang disimpannya. Mereka hadir dengan antarmuka deklaratif kuat yang memungkinkan Anda mengubah data sesuai kebutuhan. Fungsionalitas tersebut penting pada tahap penelitian pendahuluan, namun tidak untuk mengelola kompleksitas yang semakin meningkat dari layanan yang terus berkembang.
Dan di sinilah dilema muncul. Kontradiksi. Pembelahan dua. Bagaimanapun, sistem informasi adalah tentang menyediakan data, dan layanan adalah tentang menyembunyikan.
Kedua kekuatan ini sangat mendasar. Mereka mendukung sebagian besar pekerjaan kami, terus-menerus memperjuangkan keunggulan dalam sistem yang kami bangun.
Seiring pertumbuhan dan perkembangan sistem layanan, kami melihat konsekuensi dikotomi data dalam banyak hal. Entah antarmuka layanan akan berkembang, memberikan jangkauan fungsionalitas yang terus meningkat dan mulai terlihat seperti database buatan sendiri yang sangat mewah, atau kita akan menjadi frustrasi dan menerapkan beberapa cara untuk mengambil atau memindahkan seluruh kumpulan data dari satu layanan ke layanan lainnya.
Pada gilirannya, membuat sesuatu yang tampak seperti database buatan sendiri yang mewah akan menimbulkan banyak masalah. Kami tidak akan menjelaskan secara detail mengapa ini berbahaya basis data bersama, anggap saja ini mewakili biaya rekayasa dan operasional yang signifikan bagi perusahaan yang mencoba menggunakannya.
Yang lebih buruk lagi adalah volume data memperbesar masalah batasan layanan. Semakin banyak data yang dibagikan dalam suatu layanan, antarmuka akan menjadi semakin kompleks dan semakin sulit untuk menggabungkan kumpulan data yang berasal dari layanan yang berbeda.
Pendekatan alternatif dalam mengekstraksi dan memindahkan seluruh kumpulan data juga memiliki permasalahan tersendiri. Pendekatan umum terhadap pertanyaan ini terlihat seperti mengambil dan menyimpan seluruh kumpulan data, lalu menyimpannya secara lokal di setiap layanan yang digunakan.
Masalahnya adalah layanan yang berbeda 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 yang bervariasi seiring waktu.
Lebih buruk lagi, data tersebut sulit untuk dikoreksi jika dikaji ulang ( Di sinilah ia benar-benar bisa menyelamatkan). Faktanya, beberapa masalah teknologi yang sulit diselesaikan yang dihadapi bisnis muncul dari perbedaan data yang berlipat ganda dari satu aplikasi ke aplikasi lainnya.
Untuk menemukan solusi terhadap masalah ini, kita perlu berpikir secara berbeda mengenai data bersama. Mereka harus menjadi objek kelas satu dalam arsitektur yang kita bangun. menyebut data tersebut βeksternalβ, dan ini adalah fitur yang sangat penting. Kita memerlukan enkapsulasi agar kita tidak mengekspos cara kerja suatu layanan, namun kita perlu memudahkan layanan untuk mengakses data bersama sehingga mereka dapat melakukan tugasnya dengan benar.
Masalahnya adalah tidak ada pendekatan yang relevan saat ini, karena baik antarmuka layanan, pesan, maupun Database Bersama tidak menawarkan solusi yang baik untuk bekerja dengan data eksternal. Antarmuka layanan kurang cocok untuk pertukaran data pada skala apa pun. Perpesanan memindahkan data namun tidak menyimpan riwayatnya, sehingga data menjadi rusak seiring waktu. Basis Data Bersama terlalu fokus pada satu hal, sehingga menghambat kemajuan. Kita pasti akan terjebak dalam siklus kegagalan data:
Siklus kegagalan data
Streams: pendekatan terdesentralisasi terhadap data dan layanan
Idealnya, kita perlu mengubah cara kerja layanan dengan data bersama. Pada titik ini, pendekatan mana pun menghadapi dikotomi yang disebutkan di atas, karena tidak ada debu ajaib yang dapat ditaburkan di atasnya untuk menghilangkannya. Namun, kita bisa memikirkan kembali masalahnya dan mencapai kompromi.
Kompromi ini melibatkan sentralisasi pada tingkat tertentu. Kita dapat menggunakan mekanisme log terdistribusi karena menyediakan aliran yang andal dan dapat diskalakan. Kami sekarang ingin layanan-layanan dapat bergabung dan beroperasi pada thread bersama ini, namun kami ingin menghindari Layanan Tuhan terpusat yang kompleks yang melakukan pemrosesan ini. Oleh karena itu, pilihan terbaik adalah membangun pemrosesan aliran ke setiap layanan konsumen. Dengan cara ini, layanan akan dapat menggabungkan kumpulan data dari berbagai sumber dan bekerja dengannya sesuai kebutuhan.
Salah satu cara untuk mencapai pendekatan ini adalah melalui penggunaan platform streaming. Ada banyak pilihan, tapi hari ini kita akan melihat Kafka, karena penggunaan Stateful Stream Processing memungkinkan kita menyelesaikan masalah yang disajikan secara efektif.
Menggunakan mekanisme logging terdistribusi memungkinkan kami mengikuti jalur yang telah dilalui dengan baik dan menggunakan pesan untuk bekerja . Pendekatan ini dianggap memberikan penskalaan dan partisi yang lebih baik daripada mekanisme permintaan-respons karena memberikan kendali aliran kepada penerima daripada pengirim. Namun, segala sesuatu dalam hidup ini harus dibayar, dan di sini Anda memerlukan broker. Namun untuk sistem yang besar, pengorbanannya sepadan (yang mungkin tidak berlaku untuk aplikasi web rata-rata).
Jika broker bertanggung jawab atas pencatatan log terdistribusi dan bukan sistem pesan tradisional, Anda dapat memanfaatkan fitur tambahan. Transportasi dapat diskalakan secara linear hampir sama baiknya dengan sistem file terdistribusi. Data dapat disimpan dalam log dalam waktu yang cukup lama, sehingga kita tidak hanya mendapatkan pertukaran pesan, tetapi juga penyimpanan informasi. Penyimpanan yang dapat diskalakan tanpa rasa takut terhadap status bersama yang dapat berubah.
Anda kemudian dapat menggunakan pemrosesan aliran stateful untuk menambahkan alat database deklaratif ke layanan yang digunakan. Ini adalah ide yang sangat penting. Meskipun data disimpan dalam aliran bersama yang dapat diakses oleh semua layanan, agregasi dan pemrosesan yang dilakukan layanan bersifat pribadi. Mereka mendapati diri mereka terisolasi dalam konteks yang sangat terbatas.
Hilangkan dikotomi data dengan memisahkan aliran status yang tidak dapat diubah. Kemudian tambahkan fungsionalitas ini ke setiap layanan menggunakan Stateful Stream Processing.
Jadi, jika layanan Anda perlu menangani pesanan, katalog produk, gudang, layanan tersebut akan memiliki akses penuh: hanya Anda yang akan memutuskan data apa yang akan digabungkan, di mana memprosesnya, dan bagaimana data tersebut harus diubah seiring waktu. Meskipun datanya dibagikan, pengerjaannya sepenuhnya terdesentralisasi. Itu diproduksi dalam setiap layanan, di dunia di mana segala sesuatunya berjalan sesuai aturan Anda.
Bagikan data tanpa mengurangi integritasnya. Enkapsulasi fungsinya, bukan sumbernya, di setiap layanan yang membutuhkannya.
Kebetulan data perlu dipindahkan secara massal. Terkadang suatu layanan memerlukan himpunan data historis lokal di mesin database yang dipilih. Triknya adalah Anda dapat menjamin bahwa, jika perlu, salinannya dapat dipulihkan dari sumbernya dengan mengakses mekanisme logging terdistribusi. Konektor di Kafka melakukan tugasnya dengan baik.
Jadi, pendekatan yang dibahas hari ini memiliki beberapa keunggulan:
- Data digunakan dalam bentuk aliran umum, yang dapat disimpan dalam log untuk waktu yang lama, dan mekanisme untuk bekerja dengan data umum tertanam dalam setiap konteks individu, yang memungkinkan layanan bekerja dengan mudah dan cepat. Dengan cara ini, dikotomi data bisa seimbang.
- Data yang berasal dari berbagai layanan dapat dengan mudah digabungkan menjadi beberapa kumpulan. Hal ini menyederhanakan interaksi dengan data bersama dan menghilangkan kebutuhan untuk memelihara kumpulan data lokal dalam database.
- Stateful Stream Processing hanya menyimpan data dalam cache, dan sumber kebenarannya tetap berupa log umum, sehingga masalah kerusakan data seiring berjalannya waktu tidak terlalu akut.
- Pada intinya, layanan berbasis data, artinya meskipun volume data terus meningkat, layanan masih dapat merespons peristiwa bisnis dengan cepat.
- Masalah skalabilitas ada pada brokernya, bukan pada layanannya. Hal ini secara signifikan mengurangi kompleksitas layanan penulisan, karena tidak perlu memikirkan skalabilitas.
- Menambahkan layanan baru tidak perlu mengubah layanan lama, sehingga menghubungkan layanan baru menjadi lebih mudah.
Seperti yang Anda lihat, ini lebih dari sekedar REST. Kami telah menerima seperangkat alat yang memungkinkan Anda bekerja dengan data bersama secara terdesentralisasi.
Tidak semua aspek dibahas dalam artikel hari ini. Kita masih perlu mencari cara untuk menyeimbangkan antara paradigma permintaan-respons dan paradigma yang didorong oleh peristiwa. Tapi kita akan membahasnya lain kali. Ada topik yang perlu Anda ketahui lebih baik, misalnya mengapa Stateful Stream Processing begitu bagus. Kami akan membicarakan hal ini di artikel ketiga. Dan ada konstruksi kuat lainnya yang dapat kita manfaatkan jika kita menggunakannya, misalnya, . Ini adalah pengubah permainan untuk sistem bisnis terdistribusi karena memberikan jaminan transaksional dalam bentuk yang terukur. Hal ini akan dibahas pada artikel keempat. Terakhir, kita perlu membahas rincian penerapan prinsip-prinsip ini.
Namun untuk saat ini, ingatlah ini: dikotomi data adalah kekuatan yang kita hadapi saat membangun layanan bisnis. Dan kita harus mengingat ini. Triknya adalah dengan membalikkan keadaan dan mulai memperlakukan data bersama sebagai objek kelas satu. Stateful Stream Processing memberikan kompromi unik untuk hal ini. Hal ini menghindari βKomponen Tuhanβ terpusat yang menghambat kemajuan. Selain itu, hal ini memastikan ketangkasan, skalabilitas, dan ketahanan saluran streaming data serta menambahkannya ke setiap layanan. Oleh karena itu, kita dapat fokus pada aliran kesadaran umum dimana layanan apa pun dapat terhubung dan bekerja dengan datanya. Hal ini menjadikan layanan lebih terukur, dapat dipertukarkan, dan otonom. Jadi mereka tidak hanya akan terlihat bagus di papan tulis dan uji hipotesis, namun juga akan berfungsi dan berkembang selama beberapa dekade.
Sumber: www.habr.com