Apa itu Jaring Layanan?

Halo lagi!.. Menjelang dimulainya kursus "Arsitek perangkat lunak" Kami telah menyiapkan terjemahan bermanfaat lainnya.

Apa itu Jaring Layanan?

Jaring layanan adalah lapisan infrastruktur latensi rendah yang dapat dikonfigurasi dan diperlukan untuk menangani komunikasi antar-proses berbasis jaringan dalam jumlah besar antara antarmuka pemrograman aplikasi (API). Service Mesh memungkinkan komunikasi yang cepat, andal, dan aman antara layanan infrastruktur aplikasi dalam container dan seringkali bersifat sementara. Service Mesh menyediakan kemampuan seperti penemuan layanan, penyeimbangan beban, enkripsi, transparansi, ketertelusuran, autentikasi dan otorisasi, serta dukungan pola mati otomatis (pemutus arus).
Jaring layanan biasanya diimplementasikan dengan menyediakan setiap instans layanan dengan instans proksi, yang disebut Sespan. Sespan menangani komunikasi antar layanan, memantau dan menyelesaikan masalah keamanan, yaitu segala sesuatu yang dapat diabstraksi dari layanan individual. Dengan cara ini, pengembang dapat menulis, memelihara, dan menyajikan kode aplikasi dalam layanan, dan administrator sistem dapat bekerja dengan Service Mesh dan menjalankan aplikasi.

Istio dari Google, IBM dan Lyft saat ini merupakan arsitektur mesh layanan paling terkenal. Dan Kubernetes, yang awalnya dikembangkan di Google, kini menjadi satu-satunya framework orkestrasi container yang didukung oleh Istio. Vendor mencoba membuat versi Istio yang didukung secara komersial. Menarik untuk melihat hal-hal baru apa yang dapat mereka bawa ke proyek open source.

Namun, Istio bukan satu-satunya pilihan karena implementasi Service Mesh lainnya sedang dikembangkan. Pola sidecar proxy adalah implementasi yang paling populer, seperti yang dapat dinilai dari proyek Buoyant, HashiCorp, Solo.io, dan lainnya. Ada juga arsitektur alternatif: perangkat teknologi Netflix adalah salah satu pendekatan di mana fungsionalitas Service Mesh diimplementasikan melalui perpustakaan Ribbon, Hysterix, Eureka, Archaius, serta platform seperti Azure Service Fabric.

Service Mesh juga memiliki terminologinya sendiri untuk komponen dan fungsi layanan:

  • Kerangka orkestrasi kontainer. Karena semakin banyak container yang ditambahkan ke infrastruktur aplikasi, terdapat kebutuhan akan alat terpisah untuk memantau dan mengelola container - kerangka orkestrasi container. Kubernetes telah dengan kuat menempati ceruk ini, bahkan pesaing utamanya Docker Swarm dan Mesosphere DC/OS menawarkan integrasi dengan Kubernetes sebagai alternatif.
  • Layanan dan Instance (Pod Kubernetes). Sebuah instance adalah satu salinan layanan mikro yang sedang berjalan. Terkadang satu instance adalah satu container. Di Kubernetes, sebuah instance terdiri dari sekelompok kecil container independen yang disebut pod. Klien jarang mengakses sebuah instance atau pod secara langsung; lebih sering, mereka mengakses layanan, yang merupakan sekumpulan instance atau pod (replika) yang identik, dapat diskalakan, dan toleran terhadap kesalahan.
  • Proksi sespan. Proxy Sidecar berfungsi dengan satu instance atau pod. Maksud dari Sidecar Proxy adalah untuk merutekan atau memproksi lalu lintas yang datang dari wadah tempat ia bekerja dan mengembalikan lalu lintas. Sidecar berinteraksi dengan Proksi Sidecar lainnya dan dikelola oleh kerangka orkestrasi. Banyak implementasi Service Mesh menggunakan Proksi Sidecar untuk mencegat dan mengelola semua lalu lintas masuk dan keluar dari sebuah instans atau pod.
  • Penemuan Layanan. Ketika sebuah instance perlu berkomunikasi dengan layanan lain, ia perlu menemukan (menemukan) instance layanan lain yang sehat dan tersedia. Biasanya, instance melakukan pencarian DNS. Kerangka kerja orkestrasi kontainer menyimpan daftar instans yang siap menerima permintaan dan menyediakan antarmuka untuk kueri DNS.
  • Penyeimbang beban. Sebagian besar kerangka orkestrasi kontainer menyediakan penyeimbangan beban pada lapisan 4 (transportasi). Service Mesh mengimplementasikan penyeimbangan beban yang lebih kompleks pada lapisan 7 (tingkat aplikasi), kaya akan algoritma dan lebih efektif dalam mengelola lalu lintas. Pengaturan penyeimbangan beban dapat diubah menggunakan API, memungkinkan Anda mengatur penerapan biru-hijau atau kenari.
  • Enkripsi. Service Mesh dapat mengenkripsi dan mendekripsi permintaan dan respons, menghilangkan beban ini dari layanan. Service Mesh juga dapat meningkatkan kinerja dengan memprioritaskan atau menggunakan kembali koneksi persisten yang ada, sehingga mengurangi kebutuhan komputasi yang mahal untuk membuat koneksi baru. Implementasi enkripsi lalu lintas yang paling umum adalah saling TLS (mTLS), tempat infrastruktur kunci publik (PKI) menghasilkan dan mendistribusikan sertifikat dan kunci untuk digunakan oleh Sidecar Proxy.
  • Otentikasi dan Otorisasi. Service Mesh dapat mengotorisasi dan mengautentikasi permintaan yang dibuat dari luar atau dalam aplikasi, hanya mengirimkan permintaan yang divalidasi ke instans.
  • Dukungan pola mati otomatis. Dukungan Service Mesh pola mati otomatis, yang mengisolasi instance yang tidak sehat dan kemudian secara bertahap mengembalikannya ke kumpulan instance yang sehat bila diperlukan.

Bagian dari aplikasi Service Mesh yang mengelola lalu lintas jaringan antar instans disebut Pesawat Data. Membuat dan menerapkan konfigurasi yang mengontrol perilaku Pesawat Data, dilakukan dengan menggunakan yang terpisah Kontrol Pesawat. Kontrol Pesawat biasanya menyertakan atau dirancang untuk terhubung ke API, CLI, atau GUI untuk mengontrol aplikasi.

Apa itu Jaring Layanan?
Control Plane di Service Mesh mendistribusikan konfigurasi antara Sidecar Proxy dan Data Plane.

Arsitektur Service Mesh sering digunakan untuk memecahkan masalah operasional yang kompleks menggunakan container dan layanan mikro. Pelopor di bidangnya layanan mikro adalah perusahaan seperti Lyft, Netflix, dan Twitter, yang menyediakan layanan stabil kepada jutaan pengguna di seluruh dunia. (Berikut ini gambaran mendetail tentang beberapa tantangan arsitektur yang dihadapi Netflix.). Untuk aplikasi yang tidak terlalu menuntut, arsitektur yang lebih sederhana mungkin sudah cukup.

Arsitektur Service Mesh sepertinya tidak akan pernah menjadi jawaban atas semua masalah pengoperasian dan pengiriman aplikasi. Arsitek dan pengembang memiliki banyak sekali peralatan, dan hanya satu di antaranya yang merupakan palu, yang, di antara banyak tugas, hanya perlu menyelesaikan satu hal - memalu paku. Arsitektur Referensi Layanan Mikro dari NGINX, misalnya, mencakup beberapa model berbeda yang memberikan pendekatan kontinum untuk memecahkan masalah menggunakan layanan mikro.

Elemen-elemen yang digabungkan dalam arsitektur Service Mesh, seperti NGINX, container, Kubernetes, dan layanan mikro sebagai pendekatan arsitektur, dapat sama produktifnya dalam implementasi non-Service Mesh. Misalnya, Istio dirancang sebagai arsitektur mesh layanan lengkap, namun modularitasnya berarti pengembang hanya dapat memilih dan mengimplementasikan komponen teknologi yang mereka perlukan. Dengan mengingat hal ini, penting untuk mengembangkan pemahaman yang jelas tentang konsep Service Mesh, meskipun Anda tidak yakin akan dapat menerapkannya sepenuhnya dalam aplikasi Anda.

Monolit modular dan DDD

Sumber: www.habr.com

Tambah komentar