Menggunakan Pesan Asinkron untuk Meningkatkan Ketersediaan

Hai, habrozhiteli! Kami baru-baru ini menyerahkan sebuah buku karya Chris Richardson ke percetakan, yang tujuannya adalah untuk mengajarkan bagaimana cara berhasil mengembangkan aplikasi menggunakan arsitektur layanan mikro. Buku ini tidak hanya membahas kelebihan, tetapi juga kelemahan dari layanan mikro. Anda akan belajar dalam situasi apa masuk akal untuk menerapkannya, dan ketika lebih baik memikirkan pendekatan monolitik.

Buku ini berfokus pada arsitektur dan desain. Ini dirancang untuk siapa saja yang tanggung jawabnya termasuk menulis dan mengirimkan perangkat lunak, termasuk pengembang, arsitek, direktur teknis dan kepala departemen pengembangan.

Berikut ini adalah kutipan dari buku Menggunakan Asynchronous Messaging

Menggunakan Pesan Asinkron untuk Meningkatkan Ketersediaan

Seperti yang Anda lihat, berbagai mekanisme IPC mendorong Anda ke berbagai kompromi. Salah satunya terkait dengan bagaimana IPC mempengaruhi aksesibilitas. Di bagian ini, Anda akan belajar bahwa interaksi sinkron dengan layanan lain sebagai bagian dari pemrosesan permintaan mengurangi ketersediaan aplikasi. Dalam hal ini, ketika merancang layanan Anda, Anda harus menggunakan pesan asinkron bila memungkinkan.

Pertama, mari kita lihat masalah apa yang menciptakan interaksi sinkron dan bagaimana hal itu mempengaruhi aksesibilitas.

3.4.1. Interaksi yang disinkronkan mengurangi ketersediaan

REST adalah mesin IPC yang sangat populer. Anda mungkin tergoda untuk menggunakannya untuk komunikasi antar layanan. Tetapi masalah dengan REST adalah bahwa itu adalah protokol sinkron: klien HTTP harus menunggu sampai layanan mengembalikan respons. Setiap kali layanan berkomunikasi satu sama lain melalui protokol sinkron, ini mengurangi ketersediaan aplikasi.

Untuk memahami mengapa ini terjadi, pertimbangkan skenario yang ditunjukkan pada Gambar. 3.15. Layanan Pesanan memiliki REST API untuk membuat pesanan. Untuk memeriksa pesanan, ia beralih ke layanan Consumer and Restaurant, yang juga memiliki REST API.


Membuat pesanan terdiri dari urutan langkah-langkah ini.

1. Klien membuat permintaan HTTP POST / pesanan ke layanan Pemesanan.
2. Layanan Pesanan mengambil informasi pelanggan dengan membuat HTTP GET / permintaan konsumen / id ke layanan Konsumen.
3. Layanan Order mengambil informasi restoran dengan mengeksekusi permintaan GET / restoran / id HTTP ke layanan Restoran.
4. Pesanan Mengambil memeriksa permintaan menggunakan informasi tentang pelanggan dan restoran.
5. Menerima Pesanan menciptakan pesanan.
6. Pengambilan Pesanan mengirim respons HTTP ke klien.

Karena layanan ini menggunakan HTTP, semuanya harus dapat diakses oleh FTGO untuk memproses permintaan CreateOrder. Itu tidak akan dapat membuat pesanan jika setidaknya salah satu layanan tidak tersedia. Dari sudut pandang matematis, ketersediaan operasi sistem adalah produk dari ketersediaan layanan yang terlibat di dalamnya. Jika layanan Pemesanan dan dua layanan yang disebutnya memiliki ketersediaan 99,5%, maka ketersediaan keseluruhannya akan menjadi 99,5% 3 = 98,5%, yang jauh lebih rendah. Setiap layanan selanjutnya yang berpartisipasi dalam permintaan membuat operasi kurang dapat diakses.

Masalah ini tidak unik untuk interaksi berbasis REST. Ketersediaan menurun setiap kali suatu layanan perlu menerima tanggapan dari layanan lain untuk menanggapi klien. Bahkan transisi ke gaya interaksi permintaan / respons di atas pesan asinkron tidak akan membantu di sini. Misalnya, jika layanan Pemesanan mengirim pesan ke layanan Konsumen melalui pialang dan mulai menunggu tanggapan, ketersediaannya akan menurun.

Jika Anda ingin memaksimalkan aksesibilitas, minimalkan jumlah interaksi sinkron. Mari kita lihat bagaimana melakukannya.

3.4.2. Singkirkan interaksi yang sinkron

Ada beberapa cara untuk mengurangi jumlah interaksi sinkron dengan layanan lain saat memproses permintaan sinkron. Pertama, untuk sepenuhnya menghindari masalah ini, semua layanan dapat disediakan dengan API asinkron secara eksklusif. Tetapi ini tidak selalu memungkinkan. Misalnya, API publik umumnya mematuhi standar REST. Oleh karena itu, beberapa layanan diharuskan memiliki API sinkron.

Untungnya, untuk memproses permintaan sinkron, Anda tidak perlu menjalankannya sendiri. Mari kita bicara tentang opsi semacam itu.

Menggunakan Gaya Interaksi Asinkron

Idealnya, semua interaksi harus terjadi dalam gaya asinkron yang dijelaskan sebelumnya dalam bab ini. Bayangkan, misalnya, bahwa klien aplikasi FTGO menggunakan gaya interaksi permintaan / sinkronisasi respons asinkron untuk membuat pesanan. Untuk membuat pesanan, ia mengirim pesan permintaan ke layanan Pemesanan. Kemudian layanan ini secara asinkron bertukar pesan dengan layanan lain dan akhirnya mengembalikan respons kepada klien (Gbr. 3.16).


Klien dan layanan berkomunikasi secara tidak sinkron, mengirim pesan melalui saluran. Tidak ada satu pun peserta dalam interaksi ini yang diblokir yang menunggu tanggapan.

Arsitektur seperti itu akan sangat kuat, karena broker memberi pesan sampai konsumsinya memungkinkan. Tetapi masalahnya adalah bahwa layanan seringkali memiliki API eksternal yang menggunakan protokol sinkron seperti REST dan, sebagai akibatnya, harus segera menanggapi permintaan.

Jika layanan memiliki API sinkron, aksesibilitas dapat ditingkatkan melalui replikasi data. Mari kita lihat cara kerjanya.

Replikasi data

Salah satu cara untuk meminimalkan interaksi sinkron selama pemrosesan kueri adalah dengan mereplikasi data. Layanan menyimpan salinan (replika) dari data yang diperlukan untuk memproses permintaan. Agar replika tetap mutakhir, ia berlangganan acara yang diterbitkan oleh layanan tempat data ini berada. Misalnya, layanan Pemesanan dapat menyimpan salinan data milik layanan Pelanggan dan Restoran. Ini akan memungkinkan dia untuk memproses permintaan untuk membuat pesanan tanpa menggunakan layanan ini. Arsitektur seperti itu ditunjukkan dalam gambar. 3.17.


Layanan Konsumen dan Restoran mempublikasikan acara kapan pun datanya berubah. Layanan pesanan berlangganan acara-acara ini dan memperbarui replika-nya.

Dalam beberapa kasus, replikasi data adalah solusi yang baik. Sebagai contoh, Bab 5 menjelaskan bagaimana layanan Pemesanan mereplikasi data layanan Restoran untuk dapat memeriksa item menu. Salah satu kelemahan dari pendekatan ini adalah bahwa kadang-kadang memerlukan menyalin sejumlah besar data, yang tidak efisien. Misalnya, jika kami memiliki banyak pelanggan, menyimpan replika data milik layanan Konsumen mungkin tidak praktis. Kerugian lain dari replikasi terletak pada kenyataan bahwa itu tidak menyelesaikan masalah memperbarui data milik layanan lain.

Untuk mengatasi masalah ini, suatu layanan dapat menunda interaksi dengan layanan lain hingga menanggapi kliennya. Ini akan dibahas lebih lanjut.

Akhiri pemrosesan setelah mengembalikan respons

Cara lain untuk menghilangkan interaksi sinkron selama pemrosesan kueri adalah dengan melakukan pemrosesan ini dalam bentuk langkah-langkah berikut.

1. Layanan memeriksa permintaan hanya dengan bantuan data yang tersedia secara lokal.
2. Ini memperbarui basis datanya, termasuk menambahkan pesan ke tabel OUTBOX.
3. Mengembalikan respons ke kliennya.

Selama pemrosesan permintaan, layanan tidak secara serentak mengakses layanan lain apa pun. Sebagai gantinya, ia mengirimi mereka pesan-pesan tidak sinkron. Pendekatan ini memberikan konektivitas layanan yang buruk. Seperti yang akan Anda lihat di bab selanjutnya, proses ini sering diimplementasikan sebagai narasi.

Bayangkan bahwa layanan Order bertindak dengan cara ini. Dia membuat pesanan dengan status PENDING dan kemudian memeriksanya dengan bertukar pesan asinkron dengan layanan lain. Dalam gbr. Gambar 3.18 menunjukkan apa yang terjadi ketika operasi createOrder () dipanggil. Rangkaian acara terlihat seperti ini.

1. Layanan Order membuat pesanan dengan status PENDING.
2. Layanan pesanan mengembalikan respons dengan ID pesanan ke kliennya.
3. Layanan Pesanan mengirimkan pesan ValidateConsumerInfo ke layanan Konsumen.
4. Layanan Pesanan mengirimkan pesan ValidateOrderDetails ke layanan Restoran.
5. Layanan Konsumen menerima pesan ValidateConsumerInfo, memeriksa untuk melihat apakah pelanggan dapat melakukan pemesanan, dan mengirimkan pesan ConsumerValidated ke layanan Pemesanan.
6. Layanan restoran menerima pesan ValidateOrderDetails, memeriksa kebenaran item menu dan kemampuan restoran untuk mengirimkan pesanan ke alamat yang diberikan, dan mengirim pesan OrderDetailsValidated ke layanan Order.
7. Layanan pesanan menerima pesan ConsumerValidated dan OrderDetailsValidated dan mengubah status pesanan menjadi VALIDATED.

Dan seterusnya ...

Layanan Pesanan dapat menerima pesan ConsumerValidated dan OrderDetailsValidated dalam urutan apa pun. Untuk mengetahui yang mana yang ia terima pertama, ia mengubah status pesanan. Jika pesan pertama adalah ConsumerValidated, status pesanan berubah menjadi CONSUMER_VALIDATED, dan jika OrderDetailsValidated berubah menjadi ORDER_DETAILS_VALIDATED. Setelah menerima pesan kedua, Layanan pesanan menetapkan status pesanan ke DILAKUKAN.

Setelah memeriksa pesanan, layanan Pemesanan melakukan langkah-langkah yang tersisa untuk membuatnya, yang akan kita bahas di bab selanjutnya. Sebagian besar dari pendekatan ini adalah bahwa layanan Pemesanan dapat membuat pesanan dan menanggapi pelanggan, bahkan jika layanan Konsumen tidak tersedia. Cepat atau lambat, layanan Konsumen akan pulih dan memproses semua pesan yang tertunda, yang akan menyelesaikan verifikasi pesanan.


Kerugian dari mengembalikan respons sebelum permintaan diproses sepenuhnya adalah bahwa hal itu membuat klien lebih kompleks. Misalnya, ketika layanan Pemesanan mengembalikan respons, itu memberikan jaminan minimal tentang status pesanan yang baru saja dibuat. Dia menjawab segera, bahkan sebelum memeriksa pesanan dan mengesahkan kartu bank klien. Dengan demikian, untuk mengetahui apakah pesanan telah berhasil dibuat, klien harus secara berkala meminta informasi atau layanan Pemesanan harus mengirimkan pesan pemberitahuan kepadanya. Terlepas dari kerumitan pendekatan ini, dalam banyak kasus ada baiknya lebih disukai, terutama karena memperhitungkan masalah dengan manajemen transaksi terdistribusi, yang akan kita bahas dalam Bab 4. Dalam bab 4 dan 5, saya akan menunjukkan teknik ini menggunakan contoh layanan Order.

Ringkasan

• Arsitektur microservice didistribusikan, sehingga komunikasi antar proses memainkan peran kunci di dalamnya.
• Pengembangan layanan API harus didekati dengan hati-hati dan hati-hati. Ini paling mudah untuk membuat perubahan yang kompatibel ke belakang karena mereka tidak mempengaruhi cara pelanggan bekerja. Saat membuat perubahan pada API layanan, Anda biasanya harus mempertahankan versi lama dan baru hingga klien diperbarui.
• Ada banyak teknologi IPC, masing-masing dengan kekuatan dan kelemahannya sendiri. Keputusan utama pada tahap desain adalah pilihan antara panggilan prosedur jauh sinkron dan pesan asinkron. Yang paling mudah digunakan adalah protokol sinkron seperti REST, berdasarkan panggilan prosedur jarak jauh. Namun idealnya, untuk meningkatkan aksesibilitas, layanan harus berkomunikasi menggunakan pesan asinkron.
• Untuk mencegah akumulasi kegagalan seperti longsoran salju dalam sistem, klien yang menggunakan protokol sinkron harus mampu mengatasi kegagalan parsial - fakta bahwa layanan yang dipanggil tidak tersedia atau menunjukkan latensi tinggi. Khususnya, ketika mengeksekusi permintaan, perlu untuk menghitung waktu tunggu, membatasi jumlah permintaan yang terlambat dan menerapkan templat "Fuse" untuk menghindari panggilan ke layanan yang salah.
• Arsitektur yang menggunakan protokol sinkron harus menyertakan mekanisme penemuan sehingga klien dapat menentukan lokasi jaringan instance layanan. Cara termudah adalah dengan fokus pada mekanisme penemuan yang disediakan oleh platform penyebaran: pada templat “Penemuan sisi server” dan “pendaftaran pihak ketiga”. Pendekatan alternatif adalah penerapan penemuan layanan di tingkat aplikasi: template Penemuan Klien dan Registrasi Mandiri. Metode ini membutuhkan lebih banyak upaya, tetapi cocok untuk situasi di mana layanan berjalan pada beberapa platform penempatan.
• Model pesan dan saluran merangkum detail implementasi sistem pesan dan menjadi pilihan yang baik ketika merancang jenis arsitektur ini. Kemudian, Anda dapat mengikat arsitektur Anda ke infrastruktur pengiriman pesan tertentu, yang biasanya menggunakan broker.
• Kesulitan utama dalam pengiriman pesan adalah penerbitan dan pembaruan basis data. Solusi yang baik adalah dengan menggunakan templat Penerbitan Peristiwa: pesan ditulis ke basis data di bagian paling awal sebagai bagian dari transaksi. Proses terpisah kemudian mengambil pesan dari database menggunakan Interogating Publisher atau templat Pelacakan Log Transaksional, dan meneruskannya ke broker.

»Informasi lebih lanjut tentang buku ini dapat ditemukan di situs web penerbit
» Isi
» Kutipan

Untuk Khabrozhiteley diskon 30% untuk buku pre-order dengan kupon - Microservices