Feathers: Saran: Dukungan untuk Layanan Mikro nyata (seperti Seneca)

Dibuat pada 8 Mar 2017  ·  19Komentar  ·  Sumber: feathersjs/feathers

Saya percaya model Layanan FeathersJS saat ini terkait erat dengan rute/permintaan/respons soket (waktu nyata atau tidak) pada server web seperti model tipikal.

Layanan harus benar-benar berdiri sendiri "bodoh" fungsi dikerahkan secara terpisah. Setiap layanan harus berlangganan pesan dengan pola tertentu.

Server HTTP cukup mengambil data soket/http yang masuk dan menghasilkan pesan yang sesuai yang ditempatkan pada antrian pesan. Satu atau lebih layanan kemudian bereaksi terhadap pesan tersebut.
Mempermudah penskalaan dan membuat layanan terpisah sepenuhnya.

Lihat seneca atau arsitektur/kerangka kerja serupa

Ini adalah arsitektur Layanan Mikro yang sebenarnya:
https://github.com/hemerajs/aither#architecture

Akan luar biasa jika kita dapat membangun sistem plugin untuk Layanan Mikro dengan Feather juga, termasuk CI/CD&D melalui wadah Docker

Komentar yang paling membantu

Bahkan Anda bahkan dapat langsung mem-proxy titik akhir ke server eksternal.

app.use('/path', someFunction)
// someFunction handles the data however you want. Just needs have a service object signature.
// read https://docs.feathersjs.com/services/readme.html#service-methods

Dan keindahan membuat pembungkus api tipis ini dengan bulu adalah Anda mendapatkan semua acara layanan juga.

Meskipun katakanlah jika layanan mikro Anda yang lain juga ada di simpul, maka Anda dapat menjadikannya aplikasi bulu juga, dan kemudian menggunakan sinkronisasi bulu Anda dapat memiliki semua kebaikan sinkronisasi streaming acara.

Semua 19 komentar

Lihat #258. Sepertinya mereka sedang mengerjakan decoupling ini untuk rilis Buzzard mereka. Saya tidak tahu tentang arsitektur yang mendasarinya.

Saya pikir @slajax dapat berpadu di sini karena dia melihat ke dalam arsitektur untuk pada dasarnya menghasilkan aplikasi mini lengkap untuk setiap layanan Feathers yang Anda buat. @ekryski juga membuat aplikasi per contoh https://github.com/feathersjs/feathers-demos/tree/master/examples/app-structure/versioned-sub-services.

Masalah terbesar saya dengan apa yang dianggap sebagai layanan mikro adalah tampaknya menggabungkan dua hal yang menurut saya tidak ada hubungannya satu sama lain, yaitu bagaimana menskalakan dan menyebarkan wadah aplikasi mini (yang hebat) dan bagaimana layanan tersebut diekspos dan dikonsumsi (melihat contoh Aither dari http://localhost:8182/api/add?a=1&b=10 yang tidak bagus sama sekali).

Saya tidak yakin Anda benar-benar mengacu pada layanan mikro di sini. Apa yang Anda gambarkan lebih pada akhir tren tanpa server baru - karenanya lambda. Bahkan tanpa server dan apex masih berinteraksi dengan APIG. IMO - ini bukan sesuatu yang harus didukung oleh bulu tetapi itu tidak berarti kami tidak mendukung layanan mikro "nyata". Anda dapat membangun layanan mikro "nyata" yang http dan docker diaktifkan kemudian menyebarkannya di lokasi DNS mandiri di ECS atau bahkan menggabungkannya menjadi satu monolit. Feathers fleksibel seperti itu tetapi tidak dimaksudkan untuk mendukung desain "hanya fungsi" yang sekarang muncul karena kami ingin memanfaatkan pengetahuan komunitas yang ada sehubungan dengan kerangka kerja paling populer seperti express, koa dll. Beberapa decoupling diperlukan untuk itu, tetapi saya tidak melihat kita akan sejauh fungsi ini hanya melakukan pendekatan - apakah Anda @daffl?

@kristianmandrup generator v3 sudah memiliki dukungan buruh pelabuhan dan saya memiliki beberapa proyek sampingan yang menggabungkannya dengan dukungan terraform - jadi penyebaran / CI / CD sudah ada di sini, hanya saja tidak akan digerakkan oleh fungsi seperti lambda.

Cukup gunakan CORBA, DCOM atau RPC ;)

Yah, fungsi lambda tanpa server bukanlah IMO "layanan mikro nyata". Ini seperti fungsi untuk fungsi panggilan pesan, yaitu. Anda harus mengetahui titik akhir penerima Anda dan jenis pesan apa yang dia harapkan, protokol apa, dll.

Keindahan layanan mikro "nyata" adalah penggunaan perantara pesan untuk memiliki arsitektur terdistribusi yang benar-benar longgar, di mana setiap node tidak mengerti tentang node lain di sekitarnya.
Cukup sampaikan pesan "ke laut" yang diambil oleh layanan apa pun yang peduli untuk mendengarkan dan menunjukkan minat.

Cara kita membangun sistem selama beberapa tahun terakhir akan segera mengikuti begitu banyak model masa lalu... selamat tinggal monolit dan komunikasi langsung, kita memiliki teknologi untuk mengatasi keterbatasan ini sekarang. Sama seperti penyimpanan berbasis mutasi dan pemrograman imperatif adalah konsekuensi pragmatis dari memori/penyimpanan yang terlalu mahal saat itu.
Tidak masalah generator scaffolding dan kerangka kerja cerdas akan benar-benar menyelesaikan masalah dalam kendala desain ini dan ledakan dalam kompleksitas yang melekat (IMO).

Saya memahami tujuan fokus Anda dengan kerangka kerja ini sehingga Anda benar, bukan apa yang Anda tuju. Feathers tampaknya lebih cocok untuk proyek PoC/startup cepat. Kemudian Anda dapat memfaktorkan "monolit layanan" ke layanan yang lebih kecil yang dapat diterapkan nanti jika perlu ketika kompleksitas meningkat dan persyaratan skalabilitas meningkat lebih dari sekadar penskalaan aplikasi web monolit itu sendiri.
2 sen saya.

Saya pribadi menggunakan aliran reaktif MS dan bus acara di klien dan server.
Sangat pas dan Anda berakhir dengan layanan terpisah yang serupa di kedua ujungnya dengan menggunakan jenis pesan yang sama! Manis :)

Mungkin menggunakan FeathersJS untuk beberapa kasus penggunaan waktu nyata di luar apa yang dapat ditawarkan firebase di luar kotak!

Semangat ️

Keren, terima kasih atas umpan baliknya!

Keindahan layanan mikro "nyata" adalah penggunaan perantara pesan untuk memiliki arsitektur terdistribusi yang benar-benar longgar, di mana setiap node tidak mengerti tentang node lain di sekitarnya.
Cukup sampaikan pesan "ke laut" yang diambil oleh layanan apa pun yang peduli untuk mendengarkan dan menunjukkan minat.

@kristianmandrup apakah Anda memiliki kesempatan untuk melihat
https://github.com/feathersjs/feathers-sync
Itu melakukan persis apa yang Anda maksud.

Bahkan ada plugin rx di sini
https://github.com/feathersjs/feathers-reactive

Saya tidak dapat memahami mengapa menurut Anda kutipan layanan mikro nyata, tanda kutip tidak dapat dibuat dengan bulu.

Bahkan Anda bahkan dapat langsung mem-proxy titik akhir ke server eksternal.

app.use('/path', someFunction)
// someFunction handles the data however you want. Just needs have a service object signature.
// read https://docs.feathersjs.com/services/readme.html#service-methods

Dan keindahan membuat pembungkus api tipis ini dengan bulu adalah Anda mendapatkan semua acara layanan juga.

Meskipun katakanlah jika layanan mikro Anda yang lain juga ada di simpul, maka Anda dapat menjadikannya aplikasi bulu juga, dan kemudian menggunakan sinkronisasi bulu Anda dapat memiliki semua kebaikan sinkronisasi streaming acara.

Luar biasa!!! Terima kasih :) Luar biasa :) @zusaman

@kristianmandrup juga periksa ini: https://github.com/feathersjs/feathers-generator/pull/39 ini memberi Anda dockerization yang diperlukan untuk melakukan CI / CD dan juga isolasi tugas gaya ECS dalam produksi.

@slajax checkout apa? Anda belum membagikan tautan apa pun

@slajax Jadi di mana generator v3 terkenal yang sangat Anda

Maaf, periksa posting yang diedit - tautan tidak ditempel. bulu-cli tidak menampung generator. Baca kode sumber dan Anda akan melihat generator v2 adalah feathersjs/generator-feathers dan v3 adalah feathersjs/feathers-generator

Kalian membuat hariku!!!

@kristianmandrup senang mendengarnya :) umpan balik diterima di v3, tapi santai saja! Ini masih hari-hari awal di sana!

Hai @slajax , apa status saat ini di v3? kemajuan sejak Maret?

@kristianmandrup kami memutuskan untuk

Masalah ini telah dikunci secara otomatis karena tidak ada aktivitas terbaru setelah ditutup. Silakan buka masalah baru dengan tautan ke masalah ini untuk bug terkait.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

Vincz picture Vincz  ·  4Komentar

NetOperatorWibby picture NetOperatorWibby  ·  4Komentar

corymsmith picture corymsmith  ·  4Komentar

rrubio picture rrubio  ·  4Komentar

andysay picture andysay  ·  3Komentar