Pertanyaan Microservices: sumber data per instance atau per microservice? [Tutup]


Membangun arsitektur microservice Saya menghadapi masalah berbagi data antara instances dari microservice yang sama.

Saya memiliki microservice, yang secara besar-besaran menggunakan datasource - setiap permintaan untuk melayani permintaan database penyebab (biasanya memasukkan). Layanan ini akan digunakan sangat berat dan saya berencana untuk menyembunyikan beberapa contoh di belakang Load Balancer. Dan di sini muncul pertanyaan: apakah instance ini akan menggunakan SATU basis data (apakah database akan menjadi hambatan?) Atau MULTIPLE (sumber data per instance) miliki?


12
2017-10-28 19:31


asal


Jawaban:


Dalam pengalaman saya dengan arsitektur mSOA, saya belum pernah melihatnya

MULTIPLE (sumber data per instance)

untuk digunakan. Bahkan jika Anda berencana untuk memuatnya dengan berat, DB yang paling umum secara alami mendukung akses multi-threading. Biasanya bottleneck (atau bagian paling lambat) dari sistem DB adalah disk. Kami harus skala cluster kami beberapa kali (relatif murah jika Anda berada di awan, tetapi skalabilitas juga bisa menjadi masalah, karena lebih banyak benang akan diperlukan untuk mengelola dan mengeksekusi sistem DB skala). Perlu diingat bahwa beberapa RDBMS menggunakan DB sementara (tempdb) yang digunakan oleh semua DB pada instance tersebut untuk menyortir, hashing, variabel sementara, dll. Multithreading dan memisahkan file tempdb ini dapat digunakan untuk meningkatkan throughput tempdb , dengan demikian meningkatkan kinerja server secara keseluruhan.

Sejak sekarang saya bekerja dengan OrchardSaya harus mengatakan bahwa ada beberapa kasus sudut, ketika tindakan Anda lebih dari satu contoh tidak sepenuhnya (dan tepat waktu) disinkronkan. Ini menyebabkan akses atas sumber daya ditolak (tepat setelah pendaftaran acara) bahkan setelah otentikasi yang benar.

Saya berencana menyembunyikan beberapa contoh di belakang Load Balancer

Ini adalah desain yang tepat untuk server App Anda, sehingga memanfaatkan gugus DB juga harus sesuai. Bertujuan jawaban lengkap - Anda dapat mempertimbangkan DWH, jika Anda memiliki banyak layanan dan Anda ingin dapat melakukan beberapa penambangan data dan analisis dari semua DB mereka.


7
2017-10-29 06:33



Memiliki satu contoh basis data per instance microservice adalah arsitektur yang sangat tidak biasa. Jika Anda khawatir tentang beban pada database, Anda bisa mengelompokkannya untuk throughput yang lebih tinggi, namun, sisipan tidak menyebabkan banyak beban.

Saya akan menyarankan Anda melihat ke database NoSQL jika Anda khawatir tentang database menjadi hambatan. Database NoSQL dirancang untuk skala yang lebih baik untuk throughput yang tinggi dan menangani sejumlah besar data dengan baik. Tentu saja sisi negatifnya adalah mereka tidak menangani model data yang kompleks dengan baik.


5
2017-11-07 02:53



Banyak tergantung pada kasus penggunaan Anda yang sebenarnya, tetapi saya pikir menulis di belakang atau menulis kembali bisa menjadi salah satu solusi Anda. Ini Pembicaraan link tentang teknik dengan EhCache, saya pikir harus ada cache lain yang mendukung fitur tersebut, Anda mungkin ingin sedikit google pada itu.


1
2017-11-04 12:26



Ini benar-benar tergantung pada persyaratan skalabilitas Anda, dan bagaimana / jika instans microservice Anda perlu bekerja sama untuk memberikan hasil tunggal. Ini membantu untuk mengetahui apa trade-off adalah:

Menjaga semuanya dalam satu basis data

  • Konfigurasi lebih mudah

  • Tidak ada koordinasi atau komunikasi dengan contoh lain dari layanan Anda dibutuhkan

  • Lebih mudah untuk menemukan kumpulan data lengkap Anda
  • Kinerja sistem dibatasi oleh kinerja basis data

Menjaga database terpisah

  • Jawaban lengkap untuk suatu permintaan dapat tersebar di seluruh microservice contoh Dalam hal ini Anda telah meningkatkan komunikasi dan negosiasi untuk menyelesaikan permintaan Penanganan data saat Anda kehilangan itu node microservice (bahkan ketika database masih naik, Anda tidak bisa mendapatkan pada itu sampai yang baru dengan konfigurasi yang benar berdiri kembali)

  • Peningkatan kompleksitas konfigurasi


0
2017-08-02 09:57



Pendekatan saya akan menjadi layanan DB lokal (baca: sumber data per instance). Dalam memori atau dalam Pod yang sama. Untuk melakukan sinkronisasi pada saat startup selalu DB baru saya akan menggunakan Apache Kafka. Segera setelah layanan mulai menginisialisasi, ia menanyakan Kafka untuk semua entri yang diminati log kompak-Feature of Kafka, yang hanya mengembalikan status entitas saat ini) mengisi DB-nya dan mulai melayani permintaan.

Ini akan meningkatkan waktu startup tentu saja, tetapi manfaatnya adalah, bahwa DB dapat berupa teknologi atau skema apa pun yang diinginkan oleh layanan (ini bahkan bisa berubah dari versi ke versi layanan). Juga tidak perlu adanya DB-Cluster, tetapi Anda akan membutuhkan Kafka-Service yang dikonfigurasi dengan benar, tetapi itu juga bisa digunakan untuk Event Sourcing di antara layanan Anda.


0
2017-08-04 12:04