Hello!
Kami adalah komunitas pengembang .NET di Raiffeisenbank dan kami ingin berbicara tentang serangkaian perpustakaan infrastruktur berdasarkan .NET Core untuk membuat layanan mikro dengan cepat dengan satu ekosistem. Mereka membawanya ke Open Source!
Sedikit sejarah
Suatu ketika kami memiliki proyek monolitik besar, yang secara bertahap berubah menjadi serangkaian layanan mikro (Anda dapat membaca tentang fitur proses ini di ). Dalam prosesnya, kami mengalami masalah ketika membuat layanan mikro baru, kami sering kali harus menyalin berbagai solusi infrastruktur - seperti menyiapkan logging, bekerja dengan database, WCF, dll. Satu tim mengerjakan proyek ini, dan semua orang sudah terbiasa dengan pendekatan tertentu dalam bekerja dengan infrastruktur. Oleh karena itu, kami memisahkan kode umum ke dalam repositori terpisah, membungkus perpustakaan yang dikumpulkan dalam paket Nuget dan menempatkannya di repositori Nuget internal kami.
Waktu berlalu, proyek secara bertahap terfragmentasi, dan ada keinginan untuk membuat modul sisi klien baru pada kerangka JS modern dan menjalankannya di browser. Kami mulai berpindah dari WCF/SOAP ke REST/HTTP, jadi kami memerlukan perpustakaan baru untuk meluncurkan layanan berdasarkan AspNet WebApi dengan cepat. Versi pertama pada .Net Framework 4.5 dibuat oleh arsitek kami hampir berlutut di waktu luangnya, tetapi secara langsung memungkinkan untuk meluncurkan layanan dengan tiga baris di Program.cs yang berisi otorisasi (NTLM), logging, Swagger, IoC/DI berdasarkan Castle Windsor, klien HTTP khusus yang meneruskan berbagai header untuk menyediakan logging ujung ke ujung di seluruh proyek. Dan semua ini dapat dikonfigurasi lebih lanjut secara langsung di file konfigurasi layanan.
Namun, tidak semuanya berjalan lancar: perpustakaan ini ternyata sangat tidak fleksibel dalam memperkenalkan modul baru. Misalnya, jika Anda perlu menambahkan beberapa middleware khusus, Anda harus membuat perakitan baru dan mewarisi dari kelas dasar yang menjalankan layanan, yang sangat merepotkan. Untungnya, kasus seperti itu tidak banyak terjadi.
Era Docker dan Kubernetes
Waktunya telah tiba ketika gelombang Docker dan Kubernetes mencapai kita, yang kita amati dengan cermat: bagaimanapun juga, ini adalah peluang besar untuk mulai bergerak lebih jauh dalam bidang teknologi, di .Net Core. Ini berarti kita memerlukan infrastruktur baru untuk menjalankan layanan: beberapa perpustakaan telah bermigrasi dari .Net Framework ke .Net Standard dan .Net Core secara praktis tanpa perubahan, beberapa dengan sedikit perbaikan. Namun yang terpenting, saya ingin mengerjakan ulang fungsionalitas yang terkait dengan peluncuran layanan di AspNet Core.
Hal pertama yang kami pertimbangkan adalah konsep yang akan menghilangkan kelemahan utama versi sebelumnya: kurangnya fleksibilitas. Oleh karena itu, diputuskan untuk membuat seluruh sistem perpustakaan seindependen dan modular mungkin dan mengumpulkan layanan yang diperlukan untuk fungsionalitas sebagai konstruktor.
Tujuan utamanya adalah untuk menciptakan pendekatan terpadu yang menjelaskan cara berinteraksi dengan database, bus, dan layanan lainnya. Kami mencoba membuat integrasi dengan cepat dan mudah, dan pengembang dapat berkonsentrasi pada penulisan logika bisnis daripada infrastruktur - hal ini sudah siap. Repositori umum membantu meningkatkan pengalaman interaksi dalam tim: ketika infrastruktur internal yang sangat mirip digunakan, akan lebih mudah untuk bergabung dalam proses pengembangan tim lain dan bertukar keahlian.
Dan mengapa kita membutuhkan Open Source?
Kami ingin menunjukkan kematangan keahlian kami dan menerima umpan balik berkualitas tinggi: seseorang di luar bank akan mampu memberikan sesuatu dari dirinya sendiri. Kami juga tertarik dengan pengembangan praktik untuk bekerja dengan layanan mikro dan DDD pada .NET di industri; mungkin seseorang ingin mengambil alih bagian tertentu dari kerangka kerja tersebut.
Sebenarnya, ViennaNET
Sekarang mari kita lihat lebih dekat. .
ViennaNET.WebApi.*
Kumpulan perpustakaan ini terdiri dari "root" ViennaNET.WebApi, yang berisi kelas pembuat untuk layanan CompanyHostBuilder, dan satu set konfigurator ViennaNET.WebApi.Configurators.*, yang masing-masing memungkinkan Anda untuk menambahkan dan mengonfigurasi beberapa fungsi ke yang dibuat melayani. Di antara konfigurator Anda dapat menemukan koneksi untuk logging, diagnostik, jenis otentikasi dan otorisasi, kesombongan, dll.
ViennaNET.WebApi.Runners.* juga berisi pembuat layanan yang telah dikonfigurasi sebelumnya. Paket-paket ini memungkinkan Anda untuk tidak mengingat setiap kali Anda membuat layanan baru konfigurator mana yang perlu dihubungkan. Namun, mereka tidak membatasi fungsionalitas pembuat layanan dengan cara apa pun.
ViennaNET.Mediator.*
Perpustakaan yang memungkinkan Anda membuat bus perantara internal untuk perintah dan permintaan dalam suatu layanan. Pendekatan ini memungkinkan Anda mengurangi jumlah injeksi DI menjadi satu, misalnya, pada pengontrol. Karena itu, Anda dapat menambahkan berbagai dekorator ke permintaan, yang menyatukan pemrosesannya dan mengurangi jumlah kode.
ViennaNET.Validasi
Majelis yang berisi sekumpulan kelas untuk membuat aturan validasi dan urutannya. Sangat mudah untuk menerapkan validasi domain, karena memungkinkan Anda menggambarkan setiap kondisi bisnis dalam bentuk aturan yang sederhana dan terpisah.
ViennaNET.Redis
Pustaka dengan pembungkus untuk kemudahan bekerja dengan Redis sebagai cache dalam memori.
ViennaNET.Spesifikasi
Majelis yang berisi kelas-kelas yang mengimplementasikan pola Spesifikasi.
Ini tidak semua yang ada di set kami. Anda dapat melihat sisanya . Kami berencana untuk segera merilis perpustakaan kami untuk bekerja dengan database ke OpenSource.
Terima kasih atas perhatiannya, kami menantikan komentar dan permintaan tarik Anda.
Sumber: www.habr.com