Saya ingin membagikan cerita saya tentang aplikasi monolit migrasi ke layanan microser. Tolong, ingat bahwa itu selama 2012 - 2014. Ini adalah transkripsi presentasi saya di dotnetconf (RU) . Saya akan berbagi cerita tentang mengubah setiap bagian dari infrastruktur.

Deskripsi proyek

Gagasan proyek utama adalah merangkak artikel dari internet, menganalisisnya, menyimpan & membuat umpan pengguna. Di satu sisi, infrastruktur kami harus dapat diandalkan, tetapi di sisi lain, kami memiliki anggaran. Sebagai hasilnya, kami sepakat bahwa:

• Degradasi kinerja sistem diizinkan.
• Beberapa bagian dari infrastruktur kami mungkin turun selama 30 menit.
• Jika terjadi bencana, downtime mungkin beberapa hari.

Perayap

Itu adalah bagian sederhana dari infrastruktur. Crawler harus mengunduh, menganalisis, & menyimpan. Implementasi pertama adalah perayap tunggal, namun dunia berubah & banyak perayap yang berbeda muncul. Crawler sedang berkomunikasi satu sama lain oleh MsSQL.

Waktu henti bukanlah masalah bagi perayap, jadi sangat mudah untuk mengukurnya:

• Ketentuan otomatis.
• Tambahkan metrik bisnis.
• Kumpulkan kesalahan.

Msql

Basis data kami sekitar 1TB.

MSSQL cluster

Ada beberapa cara berbeda cara membuat cluster:

1. SQL mirroring.
2. Windows failover cluster - itu bukan kasus karena tidak ada san / Nas.
3. AlwaysOn - itu benar-benar baru bagi kami dan tidak ada keahlian di dalamnya, jadi, itu bukan kasus bagi kami.

Akibatnya, kami memutuskan untuk menggunakan tanggal 1. Saya ingin memperhatikan bahwa kami tidak menggunakan saksi karena mode async, jadi kami membuat skrip untuk master sakelar otomatis -> budak & budak manual -> master.

Kinerja MSSQL

Jam terus berdetak, kinerja merosot, kami mencari kemacetan. Kadang-kadang, itu tidak mudah, yaitu mengoptimalkan query SQL dengan disk io, ketika, kami menemukan bahwa kinerjanya rendah karena kurangnya RAM. Namun itu tidak cukup, sebagai solusi sementara, kami bermigrasi dari HDD ke SSD. Di satu sisi, itu meningkatkan kinerja secara dramatis, tetapi di sisi lain, itu bukan solusi jangka panjang.

Antrian pesan

Aplikasi kami telah dimigrasikan ke antrian pesan. Kami hanya menulis hasil dalam database. Akibatnya, kami mengurangi beban basis data. Tapi kami menghadapi masalah: bagaimana cara mengatur kluster antrian pesan? Pada awalnya, kami membuat siaga dingin.

WEB

Komponen web terdiri dari dua bagian: konten statis & konten dinamis pengguna.

WEB statis

Bagian statis infrastruktur WEB adalah sekitar 2TB, ia harus:

• Simpan gambar.
• Konversi gambar.
• Merayapi gambar asal & pangkas jika perlu.

Ada 2 masalah utama: cara menyinkronkan file & cara membuat cluster web. Ada beberapa cara bagaimana menyinkronkan file: membeli penyimpanan, menggunakan DFS & menyimpan file di setiap server. Itu keputusan yang sulit, namun, kami memutuskan untuk memilih cara ke-3. Untuk kluster web, kami memutuskan untuk menggunakan NLB & CDN.

WEB Balancer

Bukan ide yang bagus untuk menggunakan satu server untuk proyek beban tinggi, Anda harus menyeimbangkan lalu lintas. Ada 4 cara dalam kasus kami:

1. Penyeimbang perangkat keras - terlalu mahal bagi kami.
2. IIS & ARR - terlalu rumit untuk didukung.
3. Nginx - itu cukup baik, namun, kami menghadapi beberapa masalah dengan pemeriksaan kesehatan.
4. Haproxy - itu adalah solusi dengan salah satu overhead terkecil.

Kami memilih cara ke-4. Kami menyeimbangkan haproxy oleh DNS round robin & pengguna dengan cookie.

Mongodb

Beberapa bulan kemudian, kami menghadapi bahwa kinerja SQL tidak cukup baik lagi. Itu adalah masalah yang canggih, namun, setelah percakapan panjang kami memutuskan untuk memilih Ketersediaan & Toleransi partisi dari teorema CAP . Sebagai hasilnya, kami mengimplementasikan cluster MongoDB (sharding & replica). Ada pengalaman yang menarik: cara membuat cadangan MongoDB, cara meningkatkan & banyak bug MongoDB.

Pencadangan & pemantauan

Kami menerapkan aturan 3-2-1:

• Setidaknya 3 salinan.
• Setidaknya 2 jenis penyimpanan yang berbeda.
• Setidaknya 1 salinan harus disimpan di suatu tempat di luar.

Kami juga membuat & menguji rencana pemulihan bencana. Anda dapat membaca tentang pemantauan di sini .

Pembaruan aplikasi

Seperti yang Anda lihat, infrastrukturnya tidak semudah pie. Kami harus memperbaruinya entah bagaimana. Pembaruan kasual terlihat seperti:

1. Lakukan beberapa persiapan.
2. Menjalankan migrasi.
3. Perbarui aplikasi web.
4. Perbarui aplikasi backend.

Semua langkah logis identik untuk lingkungan pementasan / praproduksi / produksi, namun, sedikit berbeda pada detailnya. Jadi, kami membuat skrip PowerShell dengan sihir OOP. Itu adalah proses berkelanjutan untuk meningkatkan infrastruktur CI / CD kami.

Kesimpulan

Itu adalah kisah yang luar biasa tentang memindahkan 3 PC desktop ke infrastruktur yang andal. Sabar & lakukan rencana.

PS

• dotnetconf (RU) .
• Slide (RU)
• Video (RU)
• Itu adalah crosspost