Bagaimana cara menyesuaikan mesin aturan dalam arsitektur microservice ketika membutuhkan banyak data input?

12

Situasi saat ini

Kami menerapkan (dan sekarang memelihara) aplikasi web belanja online dalam arsitektur layanan mikro.

Salah satu persyaratannya adalah bahwa bisnis harus dapat menerapkan aturan tentang apa yang ditambahkan oleh pelanggan kami ke keranjang mereka, untuk menyesuaikan pengalaman mereka dan pesanan akhirnya. Jelas sekali, mesin aturan bisnis harus diberlakukan, dan kami menerapkan "layanan mikro" khusus untuk ini (jika kami masih bisa menyebutnya begitu).

Selama setahun, mesin aturan ini menjadi semakin kompleks, membutuhkan semakin banyak data (mis. Isi keranjang, tetapi juga informasi pengguna, perannya, layanan yang ada, beberapa informasi tagihan, dll.) Untuk dapat hitung aturan itu.

Untuk saat ini, layanan Microsoft kami shopping-cartmengumpulkan semua data ini dari layanan Microsoft lainnya. Meskipun sebagian dari data ini digunakan oleh shopping-cart, sebagian besar waktu itu terutama digunakan untuk memberi makan mesin aturan.

Persyaratan baru

Sekarang tiba kebutuhan untuk aplikasi lain / layanan mikro untuk menggunakan kembali mesin aturan untuk persyaratan yang sama. Dalam situasi saat ini, mereka harus mentransmisikan data yang sama, memanggil layanan mikro yang sama dan membangun (hampir) sumber daya yang sama untuk dapat memanggil mesin aturan.

Melanjutkan apa adanya, kami akan menghadapi beberapa masalah:

setiap orang (memanggil mesin aturan) harus menerapkan kembali pengambilan data, bahkan jika mereka tidak membutuhkannya sendiri;
permintaan ke mesin aturan sangat kompleks;
melanjutkan ke arah ini, kita harus mengangkut data ini di seluruh jaringan untuk banyak permintaan (pikirkan μs A calling μs B memanggil mesin aturan, tetapi A sudah memiliki beberapa data yang dibutuhkan mesin aturan);
shopping-cart telah menjadi besar karena semua pengambilan data;
Saya mungkin lupa banyak ...

Apa yang bisa kita lakukan untuk menghindari masalah ini?

Idealnya, kami akan menghindari menambah kerumitan pada mesin aturan. Kita juga harus memastikan bahwa itu tidak menjadi hambatan - misalnya beberapa data agak lambat untuk diambil (10s atau bahkan lebih) sehingga kami menerapkan pra-pengambilan shopping-cartsedemikian rupa sehingga data lebih mungkin untuk berada di sana sebelum kita memanggil aturan mesin, dan pertahankan pengalaman pengguna yang dapat diterima.

Beberapa ide

Biarkan mesin aturan mengambil data yang dibutuhkan. Ini akan menambah kompleksitas bahkan lebih, melanggar prinsip tanggung jawab tunggal ( bahkan lebih ... );
Terapkan proxy μs sebelum mesin aturan untuk mengambil data;
Terapkan "data fetcher" μs yang diminta oleh mesin aturan untuk mengambil semua data yang dibutuhkan sekaligus (penyelidikan komposit).

— Didier L
sumber

Biarkan saya meringkas ini (dengan pertanyaan): Anda memiliki beberapa layanan microser diimplementasikan untuk sebuah toko. Salah satunya adalah kereta belanja . Dimasukkan ke dalam kereta adalah mesin aturan (baik homebrew atau beberapa produk), kan? Ketika pengguna menambahkan item ke troli, mesin aturan menendang sebagai bagian dari logika bisnis dan memodifikasi troli entah bagaimana (misalnya diskon atau produk bundel), bukan? Sekarang microservice lain juga ingin menggunakan aturan yang mungkin didasarkan pada input-data yang sama, kan? Dan input-data disediakan oleh layanan microser lainnya, bukan? Mengapa pengambilan data begitu rumit?

— Andy

3

Taruhan terbaik Anda untuk menghindari masalah itu adalah dengan menyingkirkan mesin aturan.

— whatsisname

@Andy Mesin aturan adalah microservice terpisah. API-nya sedikit disesuaikan shopping-cart, tetapi kami dapat dengan mudah menyesuaikannya untuk kebutuhan layanan-layanan microsoft lainnya (mereka masih terkait dengan pengguna, produk & pemesanan). Seperti yang kita lihat, mereka akan membutuhkan data input yang sama, terutama karena bisnis dapat memilih predikat untuk diterapkan. Semua data disediakan oleh layanan microser lainnya kecuali konten keranjang itu sendiri. Mengambil data tidak rumit per se tetapi menjadi kompleks ketika Anda harus memanggil ~ 10 layanan mikro lainnya dan mempertahankan struktur yang diharapkan oleh mesin aturan.

— Didier L

@whatsisname Saya bukan penggemar berat memiliki mesin aturan secara umum baik tetapi pada saat ini kita harus menghadapinya dan bagaimanapun, dan bisnis sedang mengubah konfigurasinya setiap hari. Bahkan jika kita menyingkirkannya, kita masih akan memerlukan beberapa komponen yang dapat dikonfigurasi untuk melakukan hal yang sama, membutuhkan data input yang sama ... Itu masih akan menjadi mesin aturan, hanya dengan nama lain, dan kita masih akan menghadapi masalah yang sama.

— Didier L

8

Mari kita mundur sejenak dan menilai tempat awal kita sebelum menuliskan jawaban yang mungkin panjang lebar ini. Kamu punya:

Monolith besar (mesin aturan)
Sejumlah besar data yang tidak dimodulasi yang dikirim dalam jumlah besar
Sulit untuk mendapatkan data ke dan dari mesin aturan
Anda tidak dapat menghapus mesin aturan

Ok, ini tidak terlalu bagus untuk layanan microser. Masalah langsung mencolok adalah kalian tampaknya salah paham apa itu microservices.

setiap orang (memanggil mesin aturan) harus menerapkan kembali pengambilan data, bahkan jika mereka tidak membutuhkannya sendiri;

Anda perlu mendefinisikan beberapa jenis API atau metode komunikasi yang digunakan layanan microser Anda dan membuatnya menjadi umum. Ini mungkin perpustakaan yang bisa mereka impor. Mungkin mendefinisikan protokol pesan. Mungkin menggunakan alat yang sudah ada ( mencari bus pesan layanan mikro sebagai tempat awal yang baik).

Pertanyaan tentang komunikasi antarservice bukanlah masalah "terpecahkan", tetapi juga bukan masalah "roll your own" pada saat ini. Banyak alat dan strategi yang ada dapat membuat hidup Anda lebih mudah.

Apa pun yang Anda lakukan, pilih satu sistem dan cobalah untuk menyesuaikan API komunikasi Anda untuk menggunakan ini. Tanpa beberapa cara yang pasti untuk layanan Anda untuk berinteraksi Anda akan memiliki semua kelemahan dari layanan microser dan layanan monolitik dan tidak ada keuntungan dari keduanya.

Sebagian besar masalah Anda berasal dari ini.

permintaan ke mesin aturan sangat kompleks;

Buat mereka tidak terlalu rumit.

Temukan cara untuk membuatnya kurang kompleks. Serius. Datamodels umum, pisahkan mesin aturan tunggal Anda menjadi yang lebih kecil, atau apalah. Jadikan mesin aturan Anda berfungsi lebih baik. Jangan mengambil pendekatan "selai semuanya ke dalam kueri dan terus membuatnya rumit" - serius perhatikan apa yang Anda lakukan dan mengapa.

Tetapkan semacam protokol untuk data Anda. Dugaan saya adalah kalian tidak memiliki rencana API yang ditetapkan (seperti di atas) dan sudah mulai menulis panggilan ISTIMEWA ad hoc kapan pun diperlukan. Ini semakin kompleks karena Anda sekarang harus mempertahankan setiap layanan setiap kali ada sesuatu yang diperbarui.

Lebih baik lagi, Anda bukan perusahaan pertama yang mengimplementasikan alat belanja online. Pergi riset perusahaan lain.

Sekarang apa...

Setelah ini, Anda setidaknya menyortir beberapa masalah terbesar.

Masalah berikutnya adalah pertanyaan ini tentang mesin aturan Anda. Saya harap ini cukup tanpa kewarganegaraan, sehingga Anda dapat mengukurnya. Jika ya, sementara suboptimal Anda setidaknya tidak akan mati dalam nyala api kemuliaan atau membangun solusi gila.

Anda ingin mesin aturan Anda menjadi stateless. Buat sedemikian rupa sehingga hanya memproses data. Jika Anda menemukan itu sebagai hambatan, buatlah agar Anda dapat menjalankan beberapa di belakang penyeimbang proxy / beban. Tidak ideal, tetapi masih bisa diterapkan.

Luangkan waktu untuk mempertimbangkan apakah ada layanan microser Anda yang benar-benar harus dimasukkan ke dalam mesin aturan Anda. Jika Anda meningkatkan overhead sistem Anda secara signifikan hanya untuk mencapai "arsitektur layanan microser" Anda perlu menghabiskan lebih banyak waktu merencanakan ini.

Atau, dapatkah mesin aturan Anda dipecah menjadi beberapa bagian? Anda mungkin mendapatkan keuntungan hanya dengan membuat bagian dari layanan spesifik mesin aturan Anda.

Kita juga harus memastikan bahwa itu tidak menjadi hambatan - misalnya beberapa data agak lambat untuk diambil (10s atau bahkan lebih)

Dengan asumsi masalah ini ada setelah menyelesaikan masalah di atas Anda perlu menyelidiki dengan serius mengapa ini terjadi. Anda memiliki mimpi buruk yang sedang berlangsung tetapi alih-alih mencari tahu mengapa (10 detik? Untuk mengirim data portal belanja di sekitar? Panggil saya sinis, tapi ini agak masuk akal) Anda tampaknya menambal gejala daripada melihat masalah yang menyebabkan gejala pada posisi pertama.

Anda telah menggunakan frasa "pengambilan data" berulang kali. Apakah data ini dalam database? Jika tidak, pertimbangkan untuk melakukan ini - jika Anda menghabiskan begitu banyak waktu "secara manual" untuk mengambil data, sepertinya menggunakan database nyata adalah ide yang bagus.

Anda mungkin dapat memiliki desain dengan database untuk data yang Anda ambil (tergantung pada apa ini, Anda telah menyebutkannya berkali-kali), beberapa mesin aturan, dan klien Anda.

Satu catatan terakhir adalah Anda ingin memastikan Anda menggunakan versi API dan layanan yang tepat. Rilis minor seharusnya tidak merusak kompatibilitas. Jika Anda menemukan diri Anda melepaskan semua layanan Anda pada saat yang sama bagi mereka untuk bekerja, Anda tidak memiliki arsitektur layanan mikro, Anda memiliki arsitektur monolitik terdistribusi.

Dan pada akhirnya, layanan microser bukan solusi satu ukuran untuk semua. Tolong, demi semua yang suci, jangan lakukan saja karena ini adalah hal yang baru.

— enderland
sumber

Terima kasih atas jawaban Anda, @enderland. Memang arsitektur microservice masih relatif baru bagi kami, karenanya pertanyaan ini. Mesin aturan ini telah berevolusi sedikit organik untuk membawa kami ke sini, jadi kami sekarang perlu petunjuk arah mengemudi untuk memperbaikinya. Ini (untungnya) benar-benar tanpa kewarganegaraan, karenanya jumlah data yang dibutuhkan sebagai input. Dan inilah yang ingin kami atasi terlebih dahulu untuk menjadikannya komponen yang dapat digunakan kembali. Tetapi bagaimana cara mengurangi jumlah input data tanpa mengurangi jumlah predikat yang tersedia? Saya kira kita membutuhkan API yang dapat mengambil data sendiri, tetapi bagaimana cara membuatnya dengan benar?

— Didier L

Mengenai masalah kinerja, mereka datang dari layanan Microsoft yang sebenarnya memanggil layanan JMS dan SOAP lambat yang diimplementasikan oleh back-end. Mereka memiliki database sendiri tetapi kinerja sebenarnya bukan tujuan pertama mereka (selama menangani beban). Dan ada terlalu banyak dari mereka untuk mempertimbangkan mereplikasi data mereka dan memeliharanya (bagi sebagian orang kita melakukannya). Yang terbaik yang bisa kita lakukan adalah melakukan caching dan pre-fetching.

— Didier L

Jadi ketika Anda menyebutkan " beberapa mesin aturan ", saya mengerti maksud Anda adalah mesin aturan khusus yang hanya mengevaluasi predikat untuk dengan 1 jenis input, bukan? Apakah Anda menyarankan mereka mengambil data yang mereka butuhkan atau harus diambil di muka? Kita juga perlu beberapa komponen untuk mengatur kombinasi predikat, kan? Dan perhatikan untuk tidak menambahkan terlalu banyak overhead jaringan karena orkestrasi ini.

— Didier L

1

Dengan jumlah informasi yang disajikan tentang mesin aturan dan input dan outputnya, saya kira saran Anda tidak. 2 ada di jalur yang benar.

Konsumen saat ini dari mesin aturan dapat melakukan outsourcing proses pengumpulan informasi yang diperlukan untuk komponen tujuan yang lebih khusus.

Contoh: Anda saat ini menggunakan mesin aturan untuk menghitung diskon yang perlu diterapkan terhadap isi keranjang belanja. Pembelian sebelumnya, faktor geografis, dan faktor penawaran saat ini.

Persyaratan baru adalah menggunakan banyak informasi yang sama ini untuk mengirim email penawaran kepada pelanggan sebelumnya berdasarkan spesial mendatang dan pembelian sebelumnya. Pembelian sebelumnya, faktor penawaran saat ini dan yang akan datang ke dalamnya.

Saya akan memiliki dua layanan terpisah untuk ini. Mereka masing-masing akan bergantung pada layanan mesin aturan untuk beberapa pengangkatannya yang berat. Masing-masing dari mereka akan mengumpulkan data yang diperlukan yang dibutuhkan untuk permintaan mereka ke mesin aturan.

Mesin aturan hanya menerapkan aturan, konsumen tidak perlu khawatir tentang data apa yang dibutuhkan mesin aturan untuk konteks tertentu, dan layanan perantara baru ini hanya melakukan satu hal: Merakit konteks dan meneruskan permintaan ke mesin aturan dan mengembalikan respons yang tidak dimodifikasi.

— Soren L. Hansen
sumber

0

Pengumpulan data yang diperlukan untuk keputusan harus dilakukan di luar mesin aturan. Ini karena mereka dirancang terbaik sebagai layanan tanpa kewarganegaraan jika memungkinkan. Pengambilan data harus melibatkan pemrosesan asinkron dan status holding. Tidak masalah jika pengambilan dilakukan oleh proxy yang menghadap layanan keputusan, oleh penelepon, atau dengan proses bisnis.

Sebagai masalah praktis untuk implementasi, saya akan menyebutkan bahwa IBM Decision Manager Operasional mulai mendokumentasikan dan sudah mendukung penggunaan produk dalam wadah buruh pelabuhan . Saya yakin bahwa produk lain juga menyediakan dukungan ini dan itu akan menjadi arus utama.

— David Williams
sumber

0

Dalam pemikiran sederhana saya, saya kira, itu akan membantu untuk mengambil kembali semua data yang diperlukan dengan membuat satu set panggilan async ke layanan pengambilan data segera setelah pelanggan mulai membeli dan menyimpan data. Jadi ketika Anda harus memanggil layanan aturan data sudah ada di sana. Dan terus tersedia untuk layanan lain juga selama sesi.

— Ashok
sumber