Feathers: Layanan mikro: Cara yang disarankan untuk memfaktor ulang aplikasi dengan membagi layanan?

Anda benar, belum ada terlalu banyak dokumentasi di luar sana dan kami membuat https://github.com/feathersjs/feathers/issues/157 beberapa saat yang lalu untuk melacaknya. Berikut beberapa pemikiran saya tentang dua topik yang Anda sebutkan:

Mari kita asumsikan kita awalnya memiliki server dengan dua layanan, mungkin seperti

app.use('/users', memory())
  .use('/todos', memory());

Layanan pengguna mendapatkan lebih banyak lalu lintas daripada yang dapat ditangani oleh satu server, jadi kami ingin memindahkannya ke sistem lain dengan membuat aplikasi lain untuk itu:

// server1
app.use('/users', memory());
// server2
app.use('/todos', memory());

Untuk layanan /todos sekarang berkomunikasi dengan layanan jarak jauh, kita dapat menggunakan Feathers sebagai klien untuk menyambungkannya (Websockets cepat dan dua arah jadi mengapa tidak menggunakannya untuk komunikasi server-ke-server?):

// server2
const client = require('feathers/client')
const socketClient = require('feathers-socketio/client');
const io = require('socket.io-client');

const socket = io('http://other-server.com');
const otherApp = client().configure(socketClient(socket));

app.use('/todos', memory())
 .use('/users', otherApp.service('users'));

Ini pada dasarnya akan secara transparan meneruskan layanan pengguna ke layanan jarak jauh melalui koneksi websocket. Apa pun yang menggunakan titik akhir /users tidak perlu mengubah apa pun.

Adapun otentikasi, ada banyak opsi berbeda. Dalam skenario di atas, cara termudah adalah dengan server1 hanya memasukkan alamat IP server lain ke daftar putih karena server2 masih satu-satunya titik komunikasi untuk klien. Akhirnya server2 hanya bisa menjadi gateway yang menangani otentikasi pengguna dan kemudian hanya melewati panggilan layanan ke server lain (yang tidak perlu khawatir tentang otentikasi selain memeriksa alamat IP asal).

Terima kasih atas tanggapannya! Apakah Anda berencana untuk membahas topik ini di dokumen resmi (mungkin sub-bagian dari Panduan)? Beri tahu saya jika saya dapat berkontribusi dalam hal ini.

Pastinya. Dan kami pasti membutuhkan bantuan. Mungkin mari kumpulkan dulu apa yang ingin kita lihat di panduan dan kemudian buat beberapa aplikasi demo?

💯 @daffl bagus . Ini adalah sesuatu yang saya rencanakan untuk ditangani secara resmi selama sebulan ke depan karena saya telah berkomitmen untuk memberikan presentasi tentangnya.

@daffl Pendekatan yang Anda sebutkan menggunakan feathers-client pada layanan mikro backend memungkinkan komunikasi dua arah melalui data streaming, karena socket.io digunakan. Feathers sudah memiliki semantik / API untuk skenario ini? Saya sedang memikirkan situasi di mana layanan mikro memublikasikan acara untuk layanan mikro lain yang tertarik, bukan klien browser.

Ya, tetapi mengapa layanan lain yang tertarik juga tidak menggunakan websockets? Kami berpikir untuk menambahkan penyedia lain (mis. Untuk layanan perpesanan yang berbeda) tetapi untuk saat ini websockets tampaknya cukup cepat dan tidak ditulis di mana pun sehingga hanya dapat digunakan di browser.

@daffl @ekryski saat aplikasi feathers didistribusikan, kami juga perlu menangani masalah seperti setidaknya sekali pengiriman (tindakan), idempotensi, transaksi, tekanan balik (antrian), dll. Apakah Anda telah mempertimbangkan sesuatu seperti "feathers-service- pekerja? ".. yaitu. proses eksternal yang mengkonsumsi peristiwa dari antrian amqp (mis. Rabbitmq) yang tahan lama atau redis (menggunakan yaitu kue)?

@daffl Saya rasa saya tidak mengerti dengan baik sebelum jawaban Anda. Selama layanan yang tertarik menggunakan soket web untuk berlangganan layanan produser, menggunakan API acara reguler untuk menerbitkan acara baru di produser, cukup menerapkannya di awal, bukan?

Saya setuju dengan @justingreenberg , masalah lain yang harus ditangani adalah memutar ulang permintaan saat layanan mikro yang bertanggung jawab offline (mogok, pembaruan, dll). Secara teknis, ini akan menjadi alamat dengan menggunakan antrian pesan juga.

Ada kemajuan dalam hal ini? Saya sangat ingin melihat beberapa dokumentasi / contoh yang berfungsi. Terutama dalam hal bagaimana otentikasi ditangani.

@imns kami sedang mengerjakan ini. Saya mulai mengerjakan contoh dan membagi aplikasi dan kami menyadari ada beberapa batasan dengan cara pengaturan autentikasi. Jadi saat ini kami memfaktorkan ulang autentikasi untuk mendukung ini dengan lebih baik. Harus sekitar seminggu untuk mendarat.

Ya ampun, saya bisa menggunakan ini begitu buruk sekarang: D

Hanya ingin tahu, apakah Anda sedang mengerjakan ulang auth untuk bekerja dengan beberapa front-end juga? Saya pikir banyak aplikasi yang lebih besar sekarang-a-hari menggunakan layanan mikro di backend, tetapi juga merusak aplikasi front-end mereka.

Jika Anda memiliki sedikit uang ekstra, saya pikir buku ini dapat dianggap sebagai bacaan yang direkomendasikan: https://www.amazon.com/Building-Microservices-Sam-Newman/dp/1491950358/ref=sr_1_1 ? Ie = UTF8 & qid = 1469071253 & sr = 8-1 & kata kunci = Layanan mikro

Teman-teman, ada pembaruan tentang ini? Terima kasih.

@juanpujol informasi terbaru akan selalu ada di tiket ini. Terima kasih sudah memeriksanya.

(marcfawzi di sini)

Saya belum membaca keseluruhan utas tetapi saya berasumsi bahwa kita akan dapat menggunakan database per layanan (dalam arsitektur Micreoservices, pemisahan ini sangat penting untuk mempertahankan abstraksi. Lain, jika semua layanan berbagi database yang sama apa yang mencegah orang dari mendefinisikan hubungan di seluruh model layanan (pelanggaran abstraksi layanan mikro) alih-alih membuat layanan menggunakan API layanan seragam?

Tidak ada yang benar-benar mencegah itu, menurut saya itu pada Anda untuk tidak melakukan itu. Ini hanya akan menjadi masalah jika Anda menentukan model dan hubungan Anda di tingkat ORM. Saya tidak berpikir bahwa mendapatkan hubungan di tingkat layanan dengan memanggil layanan lain melanggar abstraksi layanan mikro.

Ya, persis seperti yang saya maksud. Saya cenderung berpikir bahwa pemisahan layanan di mana setiap layanan memiliki db sendiri adalah cara yang pasti untuk memaksa komposisi melalui antarmuka layanan daripada di tingkat ORM.

Tapi Feathers lebih umum daripada framework Microservices, jadi semuanya bagus di sini. Terima kasih David! Ini terus terlihat lebih baik dan lebih baik semakin saya menggali lebih dalam! Kerja bagus di sekitar!

Hanya berpikir saya akan menyebutkan ini di sini apakah itu memecahkan beberapa masalah yang muncul dengan menggunakan Feathers di lingkungan layanan mikro. Ini hanya implementasi pertama tetapi jika Anda memiliki sesuatu untuk dikontribusikan, silakan ke sini https://github.com/zapur1/feathers-rabbitmq/issues/1

@ zapur1 yang terlihat menjanjikan ... Saya telah memberikan komentar untuk memulai diskusi

Anda juga dapat menggunakan https://github.com/feathersjs/feathers-sync dengan rabbitMQ, Redis, atau MongoDB sebagai perantara pesan di antara layanan untuk menjaga semuanya tetap sinkron.

@ekryski feathers-sync memecahkan sedikit masalah yang berbeda, bagaimana jika Anda hanya ingin acara diterima sekali dalam bidang layanan bernama (bukan layanan Feathers tetapi layanan gaya layanan mikro)? Jika Anda memiliki beberapa instance dari satu layanan yang menerima peristiwa dari satu aplikasi API, masing-masing akan menerima peristiwa yang kemungkinan besar menduplikasi tindakan yang diambil saat peristiwa itu diterima di beberapa instance dari kode yang sama persis.

@ekryski Saya baru saja melihat repo itu lagi dan zapur1 / feathers-rabbitmq memecahkan masalah persis yang Anda sebutkan di "Peringatan"

jika saya menghubungkan layanan 1 ke layanan 2 oleh socketClient, jadi jika layanan 2 saya memiliki multi contoh, bagaimana saya dapat mengimplementasikan keseimbangan beban :(

Jika saya membuat aplikasi sisi server terpisah yang terhubung melalui socketClient, apa cara terbaik untuk mengautentikasi sehingga salah satu layanan tersedia terlepas dari batasan apa pun yang telah disiapkan.

Saya menambahkan 2 sen saya untuk ini dengan https://github.com/kalisio/feathers-distributed , ini bertujuan untuk menerapkan aplikasi N feathers yang mengadakan berbagai layanan yang berbicara bersama, sehingga Anda dapat mengembangkan masing-masing secara mandiri. Ini berbeda dari https://github.com/feathersjs/feathers-sync yang bertujuan menerapkan aplikasi N feathers yang memiliki layanan yang sama sejauh yang saya mengerti. Semua ini menimbulkan serangkaian pertanyaan seperti:

• manajemen otentikasi
• Gerbang API dan load balancing
• pemanggilan hook jarak jauh
• ...

@daffl pada contoh yang Anda berikan melibatkan server 1 dan server 2, bagaimana Anda mengamankan layanan /users di server 2? Jika kita memiliki layanan yang ditentukan di server 2 kita bisa menggunakan hook di file hook layanan tertentu, tetapi karena kita melakukan app.use('/users', otherApp.service('users')); , bagaimana kita memastikan bahwa panggilan ke layanan itu dari server 2 hanya akan dilakukan apakah pengguna melakukan otentikasi terlebih dahulu?

EDIT:
Nvm, saya pikir saya punya ide: kita bisa melakukan sesuatu seperti const usersService = app.service('users') dan kemudian usersService.hooks(hooks) mana hook memiliki kait auth yang diperlukan untuk mengamankan titik akhir kan?

Saya menulis lebih banyak tentang bagaimana autentikasi terdistribusi dapat dilakukan di https://stackoverflow.com/questions/41076627/evaluating-featherjs-authentication-needs/41095638#41095638 :

Ada beberapa cara untuk membagi layanan masing-masing dengan kelebihan dan kekurangannya sendiri. Satu hal yang umumnya penting untuk Feathers adalah tidak ada sesi, hanya token web JSON. JWT tidak memiliki kewarganegaraan dan dapat dibaca oleh server mana pun yang memiliki rahasia yang sama sehingga tidak harus ada penyimpanan sesi pusat. Dua opsi utama yang dapat saya pikirkan adalah:

1. Memiliki aplikasi utama yang menangani otorisasi dan mengelola semua klien yang terhubung tetapi alih-alih memiliki layanan yang terhubung ke database, mereka terhubung ke server API individual sederhana yang terpisah di jaringan internal. Ini adalah pengaturan yang lebih mudah dan keuntungannya adalah bahwa server API internal bisa sangat sederhana dan tidak memerlukan otentikasi sama sekali (karena aplikasi utama diizinkan untuk melakukan segalanya dan akan membuat kueri sesuai dengan batasan pengguna yang diautentikasi). Kerugiannya adalah aplikasi utama masih menjadi penghambat (tetapi dengan beban yang menurun karena pada dasarnya bertindak sebagai proxy untuk API internal).

1. Setiap klien terhubung ke setiap server API yang mereka butuhkan menggunakan JWT. JWT dibuat dengan otentikasi terpisah (atau pengguna) API. Ini adalah solusi yang lebih skalabel karena satu-satunya hambatan adalah mengambil informasi pengguna terbaru dari layanan pengguna umum (yang bahkan mungkin tidak selalu diperlukan). Kerugiannya adalah lebih rumit untuk mengelola di sisi klien dan otentikasi (setidaknya untuk JWT) harus dikonfigurasi di setiap server. Karena JWT tidak memiliki kewarganegaraan, tidak perlu ada sesi bersama.