Monolith Anda yang terdistribusi sedang merencanakan di belakang Anda

Halo, Habr!

Terjemahan hari ini tidak hanya menyentuh dan tidak terlalu banyak layanan mikro - sebuah topik yang dimiliki setiap orang saat ini - tetapi juga mengingatkan betapa pentingnya menyebut sekop sekop. Transisi ke arsitektur microservice kadang-kadang diperlukan, tetapi, seperti yang ditekankan oleh penulis sekali lagi, itu memerlukan pertimbangan yang cermat atas konsekuensinya. Nikmati dan membaca bermanfaat!



Dari waktu ke waktu saya menanyakan pertanyaan yang sama.

Adakah kebenaran yang begitu penting sehingga hanya sedikit yang setuju dengan Anda? - Peter Thiel

Sebelum saya duduk untuk posting ini, saya mencoba masalah ini untuk waktu yang lama untuk satu topik, yang hari ini dalam tren yang serius - ini tentang layanan mikro. Saya pikir sekarang saya memiliki sesuatu untuk diceritakan; beberapa temuan didasarkan pada refleksi, yang lain berdasarkan pengalaman praktis. Jadi, saya katakan.
Mari kita mulai dengan satu kebenaran penting yang akan berfungsi sebagai titik referensi bagi kita di sepanjang jalan seperti bintang kutub.

Sebagian besar implementasi layanan-mikro tidak lebih dari monolit terdistribusi.

Era monolit

Sistem apa pun dimulai sebagai aplikasi monolitik. Saya tidak akan membahas detail topik ini di sini - banyak yang sudah menulis tentang banyak hal. Namun, bagian terbesar dari informasi tentang monolith dikhususkan untuk masalah-masalah seperti produktivitas dan skalabilitas pengembang, sementara meninggalkan kurung aset yang paling berharga dari perusahaan Internet: data.



Arsitektur aplikasi monolitik yang khas

Jika data sangat penting, lalu mengapa semua perhatian diberikan pada topik lain, tetapi tidak untuk mereka? Jawabannya, secara umum, sederhana: karena mereka tidak sesulit pertanyaan data.
Mungkin monolit adalah satu-satunya tahap dalam siklus hidup sistem tempat Anda:

• Sepenuhnya memahami model data Anda;
• Anda dapat bekerja sama dengan data (diasumsikan bahwa database Anda dipilih dengan benar untuk aplikasi Anda).

Dalam hal data, monolit itu ideal. Dan karena data adalah aset paling berharga dari perusahaan mana pun, lebih baik untuk tidak melanggar monolit, kecuali Anda memiliki alasan yang sangat bagus, atau kombinasi dari alasan tersebut. Dalam kebanyakan kasus, alasan yang menentukan dari jenis ini adalah kebutuhan untuk skala (karena kita hidup di dunia nyata dengan keterbatasan fisik yang melekat).

Ketika saat ini tiba, sistem Anda kemungkinan besar masuk ke hipostasis baru: itu berubah menjadi monolit yang didistribusikan .

Era monolit yang didistribusikan

Katakanlah semuanya berjalan baik di perusahaan Anda, dan aplikasi perlu tumbuh. Anda memiliki semakin banyak pelanggan besar, dan persyaratan Anda untuk penagihan dan pelaporan telah berubah baik dalam hal serangkaian peluang maupun volumenya.

Dengan serius mengambil pembongkaran monolit, khususnya, Anda akan mencoba menerapkan dua layanan kecil, satu di antaranya akan menyediakan pelaporan, dan tagihan kedua. Kemungkinan besar, layanan baru ini akan menyediakan API HTTP dan memiliki basis data khusus untuk penyimpanan negara jangka panjang. Setelah melakukan banyak hal, Anda, seperti kami di Unbabel , mungkin mendapatkan sesuatu yang menyerupai ilustrasi berikut.



Pandangan umum tentang arsitektur sistem setelah memisahkan layanan penagihan dan pelaporan dari aplikasi monolitik utama

Semuanya berjalan sesuai rencana.

• Tim terus membagi monolit menjadi sistem yang lebih kecil;
• Integrasi / konveyor pengiriman berkelanjutan berfungsi seperti jarum jam;
• Cluster Kubernetes sehat, para insinyur produktif dan senang dengan segalanya.

Hidup itu indah.

Tetapi bagaimana jika saya mengatakan bahwa sekarang konspirasi keji menenun melawan Anda?

Sekarang, melihat sistem Anda, Anda akan menemukan bahwa data telah didistribusikan di berbagai sistem. Anda mulai dengan tahap ketika Anda memiliki database unik di mana semua objek data disimpan, dan sekarang objek data Anda telah menyebar ke berbagai tempat. Anda mungkin berpikir bahwa ini bukan masalah, karena layanan microser diperlukan untuk membuat abstraksi dan menyegel data, menyembunyikan kompleksitas internal sistem.

Anda benar sekali. Tetapi dengan meningkatnya skala, masalah yang lebih kompleks muncul: sekarang, kapan saja, Anda dipaksa untuk memenuhi persyaratan bisnis (misalnya, untuk melacak beberapa metrik), yang membutuhkan akses ke data yang terletak di lebih dari satu sistem.

Apa yang harus dilakukan Padahal, ada banyak pilihan. Tetapi dengan tergesa-gesa, Anda juga perlu melayani persaudaraan besar pelanggan yang baru saja terdaftar dengan Anda, jadi Anda harus menemukan keseimbangan antara "cepat" dan "baik". Setelah membahas detailnya, Anda memutuskan untuk membangun sistem tambahan yang akan melakukan pekerjaan ETL tertentu, berkontribusi pada solusi tugas akhir. Sistem ini harus memiliki akses ke semua replika baca yang berisi informasi yang Anda butuhkan. Gambar berikut menunjukkan bagaimana sistem seperti itu bisa bekerja.



Contoh umum dari sistem ETL analitik (di Unbabel kami menyebutnya Analisis Terjemahan Otomatis)

Di Unbabel, kami menggunakan pendekatan ini, karena:

• Itu tidak mempengaruhi kinerja setiap layanan Microsoft terlalu banyak;
• Tidak memerlukan perubahan infrastruktur besar (cukup tambahkan microservice baru);
• Kami dapat dengan cepat memenuhi persyaratan bisnis kami.

Pengalaman menunjukkan bahwa untuk beberapa waktu pendekatan ini akan berhasil - hingga mencapai skala tertentu. Di Unbabel, ia melayani kami dengan sangat baik hingga baru-baru ini, ketika kami mulai menghadapi tantangan yang semakin serius. Berikut beberapa hal yang membuat kami pusing:

1. Perubahan data

Salah satu keunggulan utama layanan-mikro adalah enkapsulasi. Representasi internal data dapat berubah, tetapi ini tidak mempengaruhi klien sistem, karena mereka berkomunikasi melalui API eksternal. Namun, strategi kami membutuhkan akses langsung ke representasi internal data, dan oleh karena itu, segera setelah tim hanya membuat beberapa perubahan pada penyajian data (misalnya, mengganti nama bidang atau mengubah jenis dari text ke uuid ), kami juga harus mengubah dan memindahkan kembali ETL- kami. layanan.

2. Perlunya memproses banyak skema data yang berbeda

Karena jumlah sistem yang kami perlukan untuk terhubung, kami harus berurusan dengan cara penyajian data yang semakin heterogen. Sudah jelas bahwa kami tidak dapat meningkatkan skala semua skema ini, hubungan antara mereka dan representasi mereka.

Akar semua kejahatan

Untuk mendapatkan gambaran lengkap tentang apa yang terjadi dalam sistem, kami harus berhenti pada pendekatan yang menyerupai monolit. Seluruh perbedaannya adalah bahwa kami tidak memiliki satu sistem dan satu basis data, tetapi lusinan pasangan seperti itu, masing-masing dengan representasi data sendiri; selain itu, dalam beberapa kasus, data yang sama direplikasi di beberapa sistem.

Saya lebih suka menyebut sistem seperti itu sebagai monolit terdistribusi. Mengapa Karena sama sekali tidak cocok untuk melacak perubahan dalam sistem, dan satu-satunya cara untuk menampilkan keadaan sistem adalah dengan mengumpulkan layanan yang menghubungkan langsung ke gudang data semua layanan Microsoft. Sangat menarik untuk melihat berapa banyak colossi Internet juga menghadapi tantangan serupa di beberapa titik dalam perkembangan mereka. Contoh yang baik dalam hal ini yang selalu ingin saya berikan adalah jaringan LinkedIn.



Ini adalah jenis kecelakaan data yang diwakili oleh aliran informasi Linkedin sekitar tahun 2011 - sumber

Pada saat ini, Anda mungkin bertanya-tanya: "apa yang akan kalian lakukan dengan semua ini?" Jawabannya sederhana: Anda harus mulai melacak perubahan dan melacak tindakan penting saat terjadi.

Hancurkan monolit terdistribusi menggunakan Event Sourcing

Seperti hampir seluruh dunia, sistem di Internet responsif. Jadi, permintaan ke API dapat menyebabkan penyisipan catatan baru ke dalam basis data. Saat ini, dalam banyak kasus, perincian seperti itu tidak mengganggu kami, karena kami terutama tertarik untuk memperbarui keadaan basis data. Memperbarui keadaan basis data adalah konsekuensi bersyarat dari beberapa peristiwa (dalam hal ini, permintaan API). Fenomena peristiwa itu sederhana dan, bagaimanapun, potensi kejadiannya sangat besar - bahkan dapat digunakan untuk menghancurkan monolit yang didistribusikan.

Suatu peristiwa tidak lebih dari fakta yang tidak berubah dari beberapa modifikasi yang terjadi di sistem Anda . Dalam arsitektur layanan mikro, peristiwa menjadi penting dan membantu untuk memahami aliran data, dan atas dasar mereka untuk menyimpulkan keadaan agregat beberapa sistem. Setiap microservice yang melakukan tindakan yang menarik dari sudut pandang seluruh sistem harus menghasilkan suatu peristiwa bersama dengan semua informasi penting yang terkait dengan fakta yang diwakili oleh peristiwa ini.

Mungkin Anda punya pertanyaan:
"Bagaimana layanan microser yang menghasilkan peristiwa dapat membantu saya memecahkan masalah monolit yang didistribusikan?"

Jika Anda memiliki sistem yang menghasilkan peristiwa, maka mungkin ada log fakta dengan properti berikut:

• Kurangnya pengikatan pada gudang data apa pun: acara biasanya diserialisasi menggunakan format biner seperti JSON, Avro atau Protobufs;
• Kekekalan: begitu suatu peristiwa dihasilkan, tidak mungkin untuk mengubahnya;
• Reproducibility: keadaan sistem pada suatu titik waktu dapat dipulihkan; untuk ini, cukup dengan "memutar ulang" log peristiwa.

Menggunakan log ini, Anda dapat menampilkan negara menggunakan semua jenis logika di level aplikasi. Anda tidak lagi dikaitkan dengan serangkaian layanan microser dan N cara di mana data disajikan. Satu-satunya sumber kebenaran dan satu-satunya gudang data Anda sekarang adalah repositori tempat acara Anda disimpan.

Berikut adalah beberapa alasan mengapa log peristiwa menurut saya menjadi cara untuk membantu memecahkan Monolith Terdistribusi:

1. Satu-Satunya Sumber Kebenaran

Alih-alih mempertahankan sumber data N yang mungkin diperlukan untuk terhubung ke (banyak) database heterogen, dalam skenario baru ini, kebenaran tertinggi disimpan dalam satu repositori: log peristiwa.

2. Format data universal

Dalam versi sistem sebelumnya, kami harus berurusan dengan banyak format data, karena kami terhubung langsung ke database. Dalam tata letak baru, kita dapat bertindak jauh lebih fleksibel.

Katakanlah Anda menyukai foto Instagram yang diposkan oleh salah satu teman Anda. Tindakan semacam itu dapat dijelaskan: “ Pengguna X menyukai gambar P ”. Dan ini adalah acara yang mewakili fakta ini:



Suatu peristiwa yang sesuai dengan pendekatan AVO (Aktor, Verb, Objek), mensimulasikan fakta bahwa pengguna memilih gambar yang mereka sukai.

3. Melemahnya komunikasi antara produsen dan konsumen

Last but not least, salah satu keuntungan terbesar dari operasi acara adalah melemahnya komunikasi yang efektif antara produsen data dan konsumen. Situasi ini tidak hanya menyederhanakan penskalaan, tetapi juga mengurangi jumlah dependensi di antara mereka. Satu-satunya kontrak yang tersisa antara sistem dalam hal ini adalah diagram acara.

---

Di awal artikel ini muncul pertanyaan: Apakah ada kebenaran penting di mana hanya sedikit yang setuju dengan Anda?

Biarkan saya kembali ke sana di akhir perjalanan ini. Saya percaya bahwa sebagian besar perusahaan tidak mempertimbangkan data "entitas kelas satu" ketika mereka mulai migrasi ke arsitektur layanan mikro. Dikatakan bahwa semua perubahan data masih dapat dilakukan melalui API, tetapi pendekatan ini pada akhirnya mengarah pada komplikasi konstan dari layanan itu sendiri.

Saya percaya bahwa satu-satunya pendekatan yang benar untuk menangkap perubahan data dalam arsitektur layanan mikro adalah membuat sistem memancarkan peristiwa sesuai dengan kontrak yang ditentukan secara ketat. Memiliki log peristiwa yang disusun dengan benar memungkinkan Anda untuk menampilkan banyak data berdasarkan set persyaratan bisnis apa pun. Dalam hal ini, Anda hanya perlu menerapkan aturan berbeda untuk fakta yang sama. Dalam beberapa kasus, fragmentasi data tersebut dapat dihindari jika perusahaan Anda (terutama manajer produk Anda) memperlakukan data sebagai produk. Namun, ini adalah topik untuk artikel lain.