Apa pertimbangan penting ketika beralih dari arsitektur monolitik ke microservices di .NET? [Tutup]

Kami berencana memecah monster monolitik kami menjadi arsitektur berbasis layanan mikro secara progresif. Kami memiliki 5 tim, masing-masing tim berisi 2-3 pengembang C #, setidaknya 1 pengembang basis data, dan 2 insinyur QA. Selain perubahan budaya dan paradigma yang besar dari arsitektur monolitik ke layanan mikro ada juga tantangan teknis. Saya ingin meminta kebijaksanaan dan saran kepada komunitas agar kita dapat menghindari kesalahan yang sama.

Apakah ada contoh industri yang bagus di mana layanan Microsoft berbasis .NET telah berhasil digunakan dalam sistem produksi? Apa strategi untuk yang berikut ini?

Org : bagaimana Anda mengatur solusi / proyek .NET?
Perencanaan pengembangan : dalam hal perencanaan pembangunan, bagaimana Anda memecah pekerjaan lintas tim? Apa strategi keseluruhan untuk memastikan kepatuhan kontrak di seluruh layanan mikro dinegosiasikan di seluruh tim?
Load balancing / routing / gateway API : apa strategi untuk load balancing, redundansi, dan penskalaan? Apakah Anda baru saja pergi dengan arsitektur async lengkap dan menggunakan antrian untuk komunikasi microservice atau apakah Anda melakukan peer-to-peer melalui load balancer / API gateway? Dan mengapa?
Otomatisasi uji : bagaimana Anda menangani otomasi uji. Ini bersama dengan integrasi berkesinambungan tampaknya sangat diperlukan untuk arsitektur layanan microsoft. Bagaimana Anda melakukannya?
Penempatan : bagaimana cara Anda menyebarkan? Satu VM / microservice atau satu wadah / microservice atau yang lainnya? Bagaimana Anda menangani fakta bahwa sekarang Anda memiliki puluhan database jika tidak lebih mempertimbangkan setiap layanan mikro akan menyimpan datanya, apa yang dilakukan terhadap infrastruktur Anda dan bagaimana DBA Anda menanganinya?
Infrastruktur : bagaimana infrastruktur Anda ditingkatkan dengan arsitektur ini. Apakah itu super cerewet dan Anda harus menyelaraskannya atau apakah jaringan menanganinya tanpa masalah? Apakah di-hosting sendiri atau di cloud?
Pemantauan : apa strategi pemantauan Anda? Bagaimana Anda mengawasi puluhan jika tidak ratusan layanan microser? Apakah sebagian besar melalui logging dan pemantauan pusat?

c# .net microservices

— codelove
sumber

Sebagian besar dari poin-poin ini bisa membuat pertanyaan yang wajar - tetapi sebagai satu pertanyaan, ini jauh terlalu luas.

— Philip Kendall

Dengan 5 tim, masing-masing tim berisi 2-3 pengembang C #, semuanya bekerja pada produk yang sama, Anda akan memiliki masalah yang jauh lebih besar daripada hal-hal teknis itu. Mulailah dengan satu tim, dan satu bagian dari aplikasi, dan cobalah untuk membuat microservice-nya yang dapat digunakan bersamaan dengan aplikasi yang tersisa. Maka Anda dapat menjawab pertanyaan Anda di atas dari pengalaman itu.

— Doc Brown

Jawaban:

Saya telah mengerjakan sejumlah proyek layanan mikro. Perusahaan mau tidak mau mengambil jalan karena pendekatan DB mereka yang besar tidak dapat berkembang lebih jauh. Inilah pengalaman / pengingatan saya.

Org. Satu solusi per microservice. paket nuget untuk lib yang dibagikan

Pengembangan. tim yang lebih besar 5-6 pengembang satu area fungsionalitas sekaligus. Refactor menjadi layanan yang terhubung. Ganti layanan dalam memori dengan klien untuk layanan microser.

Pengujian. tes integrasi menggunakan input / output data nyata. Anda ingin memecat mereka terhadap instance yang berjalan untuk memeriksa apakah sudah benar dan benar, instance lokal, lingkungan test / uat dan dalam instance memori untuk pengujian unit. Pastikan Anda dapat menguji versi instance melalui antarmuka cek kesehatan atau serupa

Scaling. Berbasis antrian adalah yang terbaik karena dapat menangani proses terdistribusi multistage. Rabbit MQ, Zero MQ, MSMQ dll. Tetapi layanan REST yang seimbang dapat digunakan untuk panggilan gaya rpc dan bisa menjadi titik awal yang mudah.

Penyebaran. Gurita. proyek db, membuat no-sql.dbs sendiri seperti Mongo. Meskipun saya pikir Anda salah rute jika Anda memiliki beberapa dbs. Alih-alih memiliki pesan berat yang berisi data yang Anda butuhkan untuk proses dan beberapa dbs yang lebih besar untuk penyimpanan data yang tersembunyi di balik apis mereka sendiri.

Tanpa DBA! Jika Anda memiliki DBA wrting sql Anda salah melakukannya.

Infrastruktur. Tidak ada masalah. Baca dari antrian. Lakukan proses. Menulis ke antrian. Anda dapat lolos dengan lebih dari satu instance per kotak bahkan pada instance cloud mikro untuk layanan kecil atau jarang disebut

Pemantauan Antarmuka pemeriksaan kesehatan untuk semua layanan yang dinamai reguarly dengan memonitor perangkat lunak dan berada di papan besar.

Kegagalan dan pemulihan otomatis penting, mesin virtual harus berputar ketika diperlukan dan tidak memiliki kewarganegaraan, sehingga satu kerusakan tidak membuat layanan tidak tersambung.

Masalah utama adalah tidak begitu banyak layanan turun karena sifat layanan mikro membuat mereka kuat dalam hal ini. Ini bagaimana Anda menangani pesan yang tidak dapat diproses.

Gunakan logstash atau sejenisnya untuk melacak aliran pesan dan mencari tahu di mana dan apa masalahnya. Pastikan Anda dapat menjalankan kembali pesan yang gagal sehingga proses tetap dapat melanjutkan di mana pesan itu ditinggalkan.

Catatan akhir. versi semuanya, dll, nuget, data, antarmuka. Dengan beberapa contoh beberapa layanan dan pesan bersejarah yang melayang di sekitarnya dapat menjadi penyebab utama masalah.

— Ewan
sumber

"Apakah kamu memiliki DBA wrting sql kamu salah melakukannya." : mengapa? Maksud saya, selain hal Agile bahwa setiap orang harus dapat melakukan segalanya, apa yang akan mencegah memiliki DBA khusus dalam lingkungan layanan-mikro dibandingkan dengan layanan-layanan non-mikro?

— Arseni Mourzenko

Hmm susah dijelaskan. Biasanya yang saya lihat adalah orgs dengan legacy db sql besar penuh dengan sprocs yang mereka coba. Untuk menjauh dari. Mereka masuk dalam keadaan ini karena pendekatan sentris DataBase dan pandangan DBA bahwa melakukannya pada DB adalah yang tercepat. Ini persis kebalikan dari apa yang coba dilakukan arsitektur arsitektur microservice. Jadi kehadiran DBA menunjukkan mereka tidak melarikan diri dari cara berpikir lama

— Ewan

Itu bahkan tidak mendekati true @Ewan. DBA kami tentu saja tidak menginginkan aturan bisnis dalam database kami. Dia lebih khawatir tentang kemampuan untuk bermigrasi ke berbagai server dan versi yang lebih baru daripada menulis kueri bisnis. DBA melakukan lebih banyak daripada menulis SQL jika mereka ahli. Sikap Anda tentang DBA ini menunjukkan bahwa Anda belum lolos dari cara berpikir .

— RubberDuck

@RubberDuck: Anda berbicara di sini tentang sisi administrator sistem dari DBA. Ewan, di sisi lain, berbicara secara khusus tentang tugas-tugas penulisan SQL dari DBA, sementara saya membayangkan DBA sebagai seseorang yang menggunakan pengetahuan luas mereka tentang basis data untuk membantu pengembang mengoptimalkan pertanyaan mereka, memberi nasihat tentang risiko yang berbeda, dan, secara umum, , membuat hidup mereka lebih mudah ketika menghadapi aspek kompleks dari basis data.

— Arseni Mourzenko

@RubberDuck ya "bau kode" berdasarkan info terbatas di OP. Anda pasti ingin DBA dalam peran ops melakukan hal-hal sulit. kecuali tentu saja Anda pindah ke cloud db

— Ewan

Selama 2 tahun terakhir kami membagi monolith menjadi layanan microser, jadi inilah beberapa hal yang kami lakukan

Organisasi : setiap layanan akan menjadi solusi dengan sendirinya, tidak ada proyek umum dengan layanan lain. Dan kami akhirnya kontrak menjadi solusi terpisah dengan sendirinya, di mana setiap versi adalah paket .nuget.

Pengembangan : setiap tim mengerjakan satu bagian aplikasi, untuk setiap layanan baru kami mulai dengan pembuatan kontrak dan kemudian memisahkan layanan, tetapi tetap menjadikannya bagian dari aplikasi / solusi utama (jadi belum ada panggilan HTTP). Dan di langkah selanjutnya kami akan memisahkan layanan ini.

Routing : Semua layanan kami berada di belakang load balancer dan setiap layanan dikerahkan pada beberapa vms. Kami berbagi vm yang sama untuk beberapa layanan. Pergi dengan satu vm per layanan tampaknya bagi saya sebagai pemborosan sumber daya, karena layanan kecil sedangkan Windows vm membutuhkan sekitar 2G untuk bekerja dengan baik. Beberapa layanan yang tidak terkait dengan interaksi pengguna (seperti mengirim email / pemberitahuan) bekerja dengan antrian.

Pengujian : Awalnya kami berpikir bahwa unit menguji layanan dan menguji kompatibilitas kontrak antara berbagai versi klien dan layanan dengan Pact.Net akan cukup. Tetapi kami memiliki masalah ketika versi layanan yang baru tidak digunakan dan kami bekerja dengan yang sebelumnya. Semua tes berlalu, tetapi seluruh platform tidak berfungsi dengan baik. Jadi kami menambahkan beberapa tes tingkat tinggi (integrasi) pada arus utama.

Deployment : Semua platform diinstal pada beberapa vms, kami menggunakan kombinasi TFS untuk build, AWS S3 untuk artefak, Memungkinkan untuk pembuatan, penyebaran, dan konfigurasi vm. Mungkin memainkan peran besar di sini, itu tanpa agen dan menggunakan PowerShell Remoting untuk menghubungkan ke windows. Kami berhenti menggunakan transformasi xml dari web.config dan pindah ke Templat yang mungkin, sehingga kami dapat memiliki semua konfigurasi dalam file yang Mungkin. Dan bagian baiknya adalah gratis dan open source, dibandingkan dengan gurita. Vms yang benar-benar baru digunakan untuk versi baru, kami memperbarui layanan hanya ketika kami harus menerapkan perbaikan.

Penskalaan : Pada sebaran seperti itu Anda hanya dapat mengatur skala vms dan bukan layanan itu sendiri. Jadi monitor kinerja Anda (CPU, RAM), jumlah permintaan yang Anda dapatkan, atau bahkan berdasarkan waktu (seperti di akhir pekan ada lebih sedikit lalu lintas) Anda memulai dan menghentikan vms baru

Pemantauan : Kami menggunakan AWS dan kami memiliki CloudWatch untuk peringatan seri waktu, tetapi kami berencana untuk pergi ke Grafana dan Prometheus (selangkah lebih dekat untuk pergi ke buruh pelabuhan, sekarang dengan Server 2016). Pada penebangan kami menggunakan Graylog (yang menggunakan ElastiSearch di belakang). Sangat mudah untuk mengadopsinya, karena kami menggunakan Log4Net dengan file appenders sebelumnya dan ada appender khusus untuk Graylog. Anda dapat membangun banyak peringatan berdasarkan itu, kami menyadari bahwa itu sebenarnya proses yang berkelanjutan.

— Liviu Costea
sumber