Di bagian sebelumnya, kita berbicara tentang dua konsep terendah dari Service Fabric, satu adalah Jenis Node dan Node di tingkat perangkat keras. Yang lainnya adalah Aplikasi.
Jenis Node adalah kumpulan Node, yang merupakan abstraksi konseptual dari mesin penyebaran. Untuk Service Fabric, node dapat berupa mesin fisik, mesin virtual, atau bahkan kontainer paling populer sekarang.
Berjalan pada Jenis Node adalah Aplikasi. Ini adalah pemahaman abstrak di tingkat perangkat lunak sistem. Ada beberapa Layanan Mikro dalam sebuah aplikasi. Bahkan semua layanan yang mendasari Service Fabric, seperti Layanan FailoverManager dan Layanan Penamaan, adalah Layanan Mikro.
Semua fitur terdistribusi Service Fabric sesuai dengan penyebaran Layanan Mikro. Kita dapat secara dinamis menyesuaikan berapa banyak instans yang perlu dijalankan oleh Layanan Mikro pada berapa banyak node untuk mendistribusikan tekanan beban atau melakukan pencadangan pemulihan bencana. Setiap instans mendengarkan port yang berbeda, dan lapisan penyeimbangan beban mendistribusikan permintaan ke instans yang berbeda.
Skenario aktual
Layanan Stateful adalah salah satu Layanan Mikro.
Sebelum kita mulai memperkenalkan Layanan Stateful, mari kita pertimbangkan skenario bisnis umum berikut.
Anda berpikir untuk menerapkan fitur keranjang belanja di situs web Anda. Setelah masuk, pengguna akan menempatkan beberapa item di keranjang belanja mereka.
Lain kali pengguna masuk, halaman meja depan akan memanggil layanan keranjang belanja, dan perlu membaca ulang data keranjang belanja yang disimpan dari layanan ini dan menampilkannya.
Jika demikian, bagaimana Anda akan mencapainya?
Jika jumlah pengguna tidak terlalu besar, kami akan menambahkan tabel keranjang belanja ke database dan mengaitkannya dengan tabel pengguna. Tabel keranjang akan memiliki bidang ID pengguna dan mencatat sejumlah besar data keranjang pengguna.
Maka ini akan membawa beberapa masalah tindak lanjut.
Jika jumlah pengguna terus meningkat, performa tabel database akan terus menurun.
Data tabel database perlu dicadangkan secara teratur jika terjadi kehilangan data
Jika ada masalah dengan performa database, tabel perlu dibongkar atau bahkan dipartisi
Sistem keranjang belanja itu sendiri perlu menangani penyesuaian apa pun pada database, dan bahkan mungkin perlu diseimbangkan beban
Akar dari masalah ini adalah bahwa sistem itu sendiri tidak dirancang untuk dapat diskalakan sejak awal. Selain itu, database berpotensi menjadi hambatan dan ancaman terhadap kinerja.
Layanan Stateful
Mari kita pertimbangkan arsitektur yang sama sekali baru.
Sejak awal, sistem keranjang belanja memiliki 36 sub-layanan yang menangani semua permintaan (36 karena inisial ID pengguna adalah 0-9 a-z, total 36).
Permintaan pengguna diproses sesuai dengan hash awal ID pengguna ke sub-layanan tertentu.
Sub-layanan menyimpan data keranjang belanja secara internal melalui database ringan dan menyimpannya di perangkat penyimpanannya sendiri.
Setiap sub-layanan juga memiliki 3 cadangan, yang terus-menerus menyinkronkan data yang disimpan, dan cadangan ini selalu berjalan di node yang berbeda.
Pada saat yang sama, hanya satu cadangan yang bertanggung jawab untuk memproses permintaan sebagai status aktivasi, dan ketika ada masalah dengan mengaktifkan cadangan, dua cadangan lainnya mengaktifkan satu sesuai dengan algoritme penjadwalan.
Subsistem pemulihan bencana membuat cadangan baru untuk memastikan bahwa sublayanan selalu memiliki 3 cadangan yang sehat.
Layanan Stateful adalah salah satu solusi tersebut.
Kembali ke skenario di atas, sistem keranjang belanja adalah layanan stateful.
36 subsistem adalah 36 instans dari Layanan Stateful ini, yang kita sebut Partisi.
Cadangan di bawah setiap subsistem adalah Replika, dan ada 3 Replika dalam partisi.
Pencadangan yang saat ini aktif adalah Replika Aktif, dan dua cadangan siaga yang tidak aktif adalah Replika Sekunder.
Setiap replika Partiion yang sama harus berjalan pada node yang berbeda.
Kode Layanan Stateful menggunakan <T>antarmuka seperti IReliableCollection, IReliableDictionary< T1, dan T2 >untuk menyimpan data dan menyinkronkan secara internal.
Selain itu, Stateful Service dapat mengimplementasikan fitur-fitur berikut:
Semua angka di atas dapat diatur ulang, dan Anda dapat memiliki ratusan partisi dalam sistem keranjang untuk memuat lebih banyak stres. Anda bahkan dapat memiliki 5 replika atau lebih per partisi untuk memastikan ketahanan yang lebih baik.
Sistem eksternal tidak peduli berapa banyak partisi yang dimiliki Layanan Stateful, mereka dipanggil oleh kunci partisi. Kunci partisi dan partisi yang sesuai diselesaikan oleh Layanan Mikro Service Fabric yang mendasarinya. Misalnya, dalam bisnis Anda, Anda mungkin memiliki beberapa juta pengguna, tetapi hanya menyiapkan 5 partisi. Saat memanggil Layanan Stateful keranjang belanja, sistem eksternal hanya perlu menginformasikan ID pengguna (kunci partisi) dan data yang disimpan. Permintaan ini secara otomatis dipetakan ke salah satu dari lima partisi berdasarkan ID pengguna dan algoritma hash.
Operasi data di Layanan Stateful mendukung transaksi. Jadi Anda dapat mengembalikan kegagalan
Saya harap pengantar di atas dapat membantu Anda lebih memahami Layanan Stateful.
Kami akan membahas contoh kode untuk Layanan Stateful di bagian berikut. |
Diposting pada 15/03/2018 10.03.44
|
|
|
|
