Ini akan menjadi bagian 2 dari Layanan Mikro dengan implementasi ECS . Pada bagian 1, kami membahas cara menerapkan arsitektur layanan mikro menggunakan Amazon ECS dan fitur penemuan layanannya serta menggunakan Strategi Pembaruan Bergulir. Dalam tutorial ini, kita akan melihat bagaimana kita dapat menggunakan AWS App Mesh dan memblokir / mengizinkan layanan untuk melayani komunikasi dan melakukan penyebaran canary atau biru / hijau tanpa berdampak pada layanan. Silakan baca Bagian 1 untuk mendapatkan kontinuitas yang lebih baik.
Pengenalan Cepat ke AWS App Mesh
AWS App Mesh adalah mesh layanan yang memudahkan untuk memantau dan mengontrol layanan. App Mesh menstandarkan cara layanan Anda berkomunikasi, memberi Anda visibilitas ujung ke ujung dan membantu memastikan ketersediaan tinggi untuk aplikasi Anda. App Mesh memberi Anda visibilitas yang konsisten dan kontrol lalu lintas jaringan untuk setiap layanan dalam aplikasi.
Kami memiliki 4 komponen utama di AWS App Mesh.
Layanan Mesh → Layanan mesh adalah batas logis untuk lalu lintas jaringan antara layanan yang berada di dalamnya.
Layanan Virtual → Layanan Virtual adalah abstraksi dari layanan Anda yang sebenarnya disediakan oleh simpul virtual atau perute virtual dengan rute.
Virtual Nodes → Virtual Nodes adalah penunjuk logis ke layanan Anda yang sebenarnya dapat ditemukan. Layanan Virtual harus dilampirkan ke Virtual Nodes atau Virtual Routers.
Router dan Rute Virtual → Router virtual menangani lalu lintas untuk satu atau beberapa layanan virtual dalam mesh Anda. Rute dikaitkan ke router virtual. Rute ini digunakan untuk mencocokkan permintaan untuk router virtual dan untuk mendistribusikan lalu lintas ke node virtual terkait.
Apa yang Anda pelajari dari blog ini
Di akhir tutorial ini, Anda akan mengetahui cara menerapkan atau mengelola layanan mikro Anda di AWS ECS, membuat atau mengelola layanan mikro Anda menggunakan AWS App Mesh dan melakukan peluncuran canary atau biru hijau dengan aman di infrastruktur layanan mikro Anda.
Teknologi yang digunakan
- GitHub.
- AWS ECS (dengan penemuan layanan).
- AWS Fargate.
- Penskalaan Otomatis AWS.
- AWS ALB.
- Cloud Map dan Route 53.
- AWS App Mesh
Contoh Arsitektur Aplikasi
Aplikasi sampel saya bernama bookingapp memiliki 4 layanan mikro.
bookingapp-home → Beranda situs web
bookingapp-film → Halaman pemesanan film
bookingapp-moviev2 → rilis halaman pemesanan film versi 2.0
bookingapp-redis → Server Backend Redis.
Aplikasinya mirip dengan yang dijelaskan di Bagian 1. Saya hanya menambahkan beberapa baris kode tambahan untuk mendapatkan respon dari microservice bookingapp-movie. Lihat Repo GitHub saya untuk bookingapp-home untuk kode python yang saya gunakan.
Dari Bagian 1, saya sudah menyiapkan klaster ECS dengan 3 tugas, bookingapp-home, bookingapp-movie, dan bookingapp-redis, ketiga tugas tersebut memiliki penemuan layanan yang dikonfigurasi dan diselesaikan ke titik akhir dengan benar. Mari kita asumsikan bahwa aplikasi kita berfungsi dengan baik dan kita ingin meluncurkan perubahan kode baru hanya untuk layanan mikro bookingapp-movie. Kami dapat meluncurkan perubahan menggunakan strategi pembaruan bergulir, tetapi jika kami menghadapi masalah apa pun dalam kode baru, semua lalu lintas akan terpengaruh. Untuk melakukan peluncuran perubahan baru dengan aman, kita dapat menggunakan model canary yaitu mengarahkan 75% lalu lintas ke layanan bookingapp-movie lama dan 25% ke layanan bookingapp-moviev2 baru, jika kami tidak menemukan masalah apa pun, kirim 50% ke layanan bookingapp-moviev2 baru dan akhirnya mengirim semua lalu lintas ke layanan baru. Dengan metode ini,
Buat layanan baru di AWS ECS
Saya telah mengkloning GitHub Repo bookingapp-moviev2 saya dan membuat gambar buruh pelabuhan baru dan mendorongnya ke hub buruh pelabuhan.
Saya akan membuat tugas baru yang disebut bookingapp-moviev2 menggunakan gambar buruh pelabuhan baru dan memunculkan layanan moviev2 dan menambahkannya ke ALB.
Tambahkan container bookingapp-moviev2: latest dan buat definisi tugas.
Sekarang buat layanan moviev2 untuk tugas tersebut.
Tambahkan layanan baru ke ALB dan penemuan layanan diaktifkan sebagai moviev2.internal-bookingapp.com.
Saya juga telah mengonfigurasi penskalaan otomatis untuk layanan ini.
Terakhir, tinjau dan simpan layanan tersebut. Sekarang Anda akan memiliki 4 layanan di tempat.
rumah → dari tugas bookingapp-home
film → dari tugas bookingapp-film
moviev2 → dari tugas bookingapp-moviev2 (menjalankan kode modifikasi dari bookingapp-movie)
redis → dari tugas bookingapp-redis.
Aplikasi sampel memiliki ALB di depannya, dan ALB mendengarkan pada port 80 dan backend dikonfigurasi berdasarkan jalur URL.
/ home → bookingapp-home-tg → mengacu pada home service → bookingapp-home task.
/ film → bookingapp-movie-tg → merujuk layanan film → tugas bookingapp-film.
/ moviev2 → bookingapp-moviev2-tg → merujuk layanan moviev2 → tugas bookingapp-moviev2.
/ redis → bookingapp-redis-tg → merujuk layanan rumah → tugas bookingapp-redis.
Saat Anda melihat diagram arsitektur penerapan canary yang ditunjukkan di atas, Anda akan melihat bahwa layanan rumah menghubungi layanan film (endpoint movie.internal-bookingapp.com). Saya berhasil membuat beberapa perubahan kode dan membuat layanan baru untuk film bernama moviev2 (endpoint moviev2.internal-bookingapp.com). Sekarang layanan moviev2 ada di tempat tetapi permintaan tidak pergi ke sana. Mari kita lihat bagaimana kita dapat mengganti layanan film dengan moviev2 menggunakan model penerapan canary dengan bantuan AWS App Mesh.
AWS App Mesh
Sekarang bagian terbaik dari App Mesh adalah Anda tidak perlu mengubah apa pun di kode aplikasi Anda untuk menggunakannya. Mari buat hal-hal yang diperlukan di AWS App Mesh.
Buat tautan untuk aplikasi kita - bookingapp.
Buat node virtual untuk semua layanan kami. Sekarang buat untuk layanan rumah, pendengar di port 5000 saat kami mengekspos port yang sama dari kontainer. Biarkan backend kosong untuk saat ini, kita perlu memperbaruinya nanti setelah kita membuat layanan virtual.
Sekarang ulangi hal yang sama untuk layanan lain juga, bookingapp-movie dan bookingapp-moviev2.
Buat layanan virtual untuk semua layanan kami. Pastikan nama layanan sama dengan yang Anda buat di penemuan layanan ECS.
Buat yang sama untuk layanan lain juga. Kami memiliki total 4 layanan virtual sekarang.
Setelah kita membuat layanan, kita perlu menambahkan backend ke home-virtual-node karena layanan rumah harus menghubungi layanan film.
Node Virtual → home-virtual-node → Edit
Buat router virtual hanya untuk layanan film. Seperti disebutkan di atas, router virtual akan merutekan lalu lintas berdasarkan rute yang kami cantumkan.
Di bagian rute, tentukan tipe rute ass http, targetkan sebagai node virtual movie-virtual-node dan moviev2-virutal-node dan bobot sesuai keinginan dengan match as / movie. Itu adalah jalur yang kami gunakan untuk mengakses layanan di wadah. Buat rute virtual.
Sekarang tambahkan router virtual ke movie.internal-bookingapp.com layanan.
Mari kita berhenti sejenak dan memahami alirannya di sini, ketika lalu lintas datang ke layanan movie.internal-bookingapp.com, itu akan mencapai proxy utusan dan layanan movie.internal-bookingapp.com memiliki penyedia bernama movie-virtual-router, jadi itu akan mengarahkan lalu lintas ke sana, router virtual memiliki 2 rute dengan bobot masing-masing 50%, jadi setiap permintaan akan menuju ke setiap rute virtual, satu titik rute virtual ke node virtual film-node virtual yang memetakan ke film AWS CloudMap Service. Layanan AWS CloudMap menyelesaikan ke IP dan meneruskan permintaan. Beginilah keseluruhan arus lalu lintas terjadi menggunakan AWS App Mesh.
Sekarang perbarui definisi tugas untuk menggunakan App Mesh. Di cluster ECS, buka definisi tugas bookingapp-home dan buat revisi baru.
Aktifkan App Mesh dan berikan semua detail yang diperlukan.
Klik Terapkan dan konfigurasi proxy akan terisi secara otomatis.
Setelah Anda melamar Anda sekarang akan melihat wadah utusan ditambahkan ke bagian wadah.
Klik buat untuk membuat versi definisi tugas baru. Ulangi hal yang sama untuk definisi tugas lain juga bookingapp-movie dan bookingapp-moviev2.
Sekarang, perbarui layanan untuk menggunakan definisi tugas terbaru. Di cluster ECS, buka tab layanan, pilih layanan film dan perbarui.
Pastikan Anda memilih kotak centang Paksa penerapan baru dan terapkan layanan. Ulangi hal yang sama untuk moviev2 dan layanan rumah juga. Tunggu fargate menarik gambar container terbaru dan memunculkannya. Setelah instance aktif, pastikan itu ditambahkan ke grup target ALB masing-masing.
Permintaan curl sederhana ke jalur ALB / home mendistribusikan beban secara merata ke kedua layanan (movie.internal-bookingapp.com dan moviev2.internal-bookingapp.com).
Sekarang saya mengonfirmasi bahwa layanan moviev2 saya berfungsi dengan baik dengan 50% lalu lintas. Kami sekarang dapat meningkatkan lalu lintas dari 50% menjadi 80% dan melihat distribusi lalu lintas.
Traffic sebagian besar dialihkan ke layanan moviev2 masih sekitar 10-20% kira-kira dialihkan ke layanan film berdasarkan bobot. Sekarang kita cukup menetapkan bobot 100% untuk layanan moviev2 dan pada akhirnya menghentikan instance fargate dan menghapus grup target ALB.
Catatan Penutup
Dengan menggunakan AWS App Mesh, kami dapat dengan mudah mengintegrasikan layanan kami yang sudah ada tanpa perubahan kode apa pun pada tumpukan aplikasi kami dan kami dapat menerapkan perubahan kode dengan cepat hanya dengan meningkatkan parameter bobot sederhana dalam aturan App Mesh Route. Sangat mudah untuk mengembalikan penerapan ke kode lama hanya dengan mengalihkan parameter bobot ke 100% untuk layanan lama.