Apa itu mesh layanan? Jaringan kontainer yang lebih mudah

Salah satu perubahan yang terjadi di TI di bawah panji transformasi digital adalah pemecahan aplikasi monolitik yang besar menjadi layanan mikro - unit fungsionalitas kecil dan terpisah — yang berjalan dalam wadah - paket perangkat lunak yang menyertakan semua kode layanan dan dependensi yang dapat diisolasi dan mudah dipindahkan dari satu server ke server lainnya.

Arsitektur dalam container seperti ini mudah ditingkatkan dan dijalankan di cloud, dan setiap layanan mikro dapat dengan cepat diluncurkan dan diulang. Namun, komunikasi di antara layanan mikro ini menjadi semakin kompleks karena aplikasi menjadi lebih besar dan beberapa contoh layanan yang sama berjalan secara bersamaan. Jaring layanan adalah bentuk arsitektur baru yang bertujuan untuk menghubungkan layanan mikro ini secara dinamis dengan cara yang mengurangi overhead administrasi dan pemrograman.

Apa itu mesh layanan?

Dalam arti yang paling luas, mesh layanan, seperti yang dijelaskan Red Hat, adalah "cara untuk mengontrol bagaimana bagian yang berbeda dari aplikasi berbagi data satu sama lain". Namun, uraian ini dapat mencakup banyak hal yang berbeda. Faktanya, ini terdengar sangat mirip dengan middleware yang kebanyakan pengembang kenal dari aplikasi klien-server.

Apa yang membuat mesh layanan unik adalah bahwa mesh layanan dibuat untuk mengakomodasi sifat unik dari lingkungan layanan mikro terdistribusi. Dalam aplikasi berskala besar yang dibangun dari layanan mikro, mungkin ada beberapa contoh layanan tertentu, berjalan di berbagai server lokal atau cloud. Semua bagian yang bergerak ini jelas menyulitkan layanan mikro individu untuk menemukan layanan lain yang mereka butuhkan untuk berkomunikasi. Jaring layanan secara otomatis menangani penemuan dan penyambungan layanan dari waktu ke waktu sehingga baik pengembang manusia maupun layanan mikro individu tidak perlu melakukannya.

Bayangkan mesh layanan sebagai padanan dari jaringan yang ditentukan perangkat lunak (SDN) untuk Level 7 model jaringan OSI. Sama seperti SDN membuat lapisan abstraksi sehingga admin jaringan tidak harus berurusan dengan koneksi jaringan fisik, mesh layanan memisahkan infrastruktur yang mendasari aplikasi dari arsitektur abstrak tempat Anda berinteraksi.

Ide mesh layanan muncul secara organik ketika para pengembang mulai bergulat dengan masalah arsitektur terdistribusi yang benar-benar besar. Linkerd, proyek pertama di bidang ini, lahir sebagai cabang dari proyek internal di Twitter. Istio, mesh layanan populer lainnya dengan dukungan perusahaan besar, berasal dari Lyft. (Kami akan melihat lebih detail pada kedua proyek ini sebentar lagi.)

Load balancing mesh layanan

Salah satu fitur utama yang disediakan mesh layanan adalah load balancing . Kami biasanya menganggap load balancing sebagai fungsi jaringan — Anda ingin mencegah satu server atau tautan jaringan kewalahan dengan lalu lintas, sehingga Anda merutekan paket sesuai dengan itu. Layanan mesh melakukan sesuatu yang serupa di tingkat aplikasi, seperti yang dijelaskan Twain Taylor, dan pemahaman yang memberi Anda pemahaman yang baik tentang apa yang kami maksud ketika kami mengatakan mesh layanan seperti jaringan yang ditentukan perangkat lunak untuk lapisan aplikasi.

Intinya, salah satu tugas mesh layanan adalah melacak instance dari berbagai layanan mikro mana yang didistribusikan di seluruh infrastruktur yang "paling sehat". Ini mungkin meminta mereka untuk melihat bagaimana mereka melakukannya atau melacak instance mana yang merespons permintaan layanan dengan lambat dan mengirim permintaan berikutnya ke instance lain. Jala layanan dapat melakukan pekerjaan serupa untuk rute jaringan, memperhatikan ketika pesan membutuhkan waktu terlalu lama untuk sampai ke tujuan, dan mengambil rute lain sebagai kompensasi. Perlambatan ini mungkin disebabkan oleh masalah dengan perangkat keras yang mendasarinya, atau hanya karena layanan kelebihan beban dengan permintaan atau bekerja pada kapasitas pemrosesannya. Hal yang penting adalah mesh layanan dapat menemukan instance lain dari layanan yang sama dan mengarahkan ke sana, sehingga memanfaatkan kapasitas aplikasi secara keseluruhan secara paling efisien.

Mesh layanan vs. Kubernetes

Jika Anda sudah familiar dengan arsitektur berbasis container, Anda mungkin bertanya-tanya di mana Kubernetes, platform orkestrasi container open source yang populer, cocok dengan gambar ini. Lagipula, bukankah inti dari Kubernetes yang ia kelola bagaimana wadah Anda berkomunikasi satu sama lain? Seperti yang ditunjukkan oleh tim Kublr di blog perusahaan mereka, Anda dapat menganggap resource "layanan" Kubernetes sebagai jenis mesh layanan yang sangat dasar, karena menyediakan penemuan layanan dan penyeimbangan permintaan secara round-robin. Namun, jerat layanan berfitur lengkap menyediakan lebih banyak fungsi, seperti mengelola kebijakan keamanan dan enkripsi, "pemutus sirkuit" untuk menangguhkan permintaan ke instance yang merespons lambat, penyeimbangan beban seperti yang kami jelaskan di atas, dan banyak lagi.

Perlu diingat bahwa sebagian besar mesh layanan sebenarnya membutuhkan sistem orkestrasi seperti Kubernetes untuk diterapkan. Jerat layanan menawarkan fungsionalitas yang diperluas, bukan pengganti.

Jala layanan vs. gateway API

Setiap layanan mikro akan menyediakan antarmuka pemrograman aplikasi (API) yang berfungsi sebagai sarana yang digunakan layanan lain untuk berkomunikasi dengannya. Ini menimbulkan pertanyaan tentang perbedaan antara mesh layanan dan bentuk manajemen API lain yang lebih tradisional, seperti API gateway . Seperti yang dijelaskan IBM, API gateway berdiri di antara sekelompok layanan mikro dan dunia "luar", merutekan permintaan layanan sebagaimana diperlukan sehingga pemohon tidak perlu mengetahui bahwa itu berurusan dengan aplikasi berbasis layanan mikro. Sebaliknya, mesh layanan memediasi permintaan "di dalam" aplikasi layanan mikro, dengan berbagai komponen yang sepenuhnya menyadari lingkungannya.

Cara lain untuk memikirkannya, seperti yang ditulis Justin Warren di Forbes , adalah bahwa mesh layanan adalah untuk lalu lintas timur-barat dalam sebuah cluster dan gateway API untuk lalu lintas utara-selatan masuk dan keluar dari cluster. Tapi keseluruhan ide mesh layanan masih awal dan terus berubah. Banyak jerat layanan — termasuk Linkerd dan Istio — sekarang menawarkan fungsionalitas utara-selatan juga.

Arsitektur layanan mesh

Ide mesh layanan baru muncul dalam beberapa tahun terakhir, dan ada sejumlah pendekatan berbeda untuk memecahkan masalah "mesh layanan", yaitu mengelola komunikasi untuk layanan mikro. Andrew Jenkins dari Aspen Mesh mengidentifikasi tiga kemungkinan pilihan mengenai di mana lapisan komunikasi yang dibuat oleh mesh layanan mungkin berada:

  • Di perpustakaan yang diimpor setiap layanan mikro Anda
  • Di agen node yang menyediakan layanan ke semua container di node tertentu
  • Dalam sespan wadah yang berjalan bersama kontainer aplikasi Anda

Pola berbasis sidecar adalah salah satu pola mesh layanan paling populer di luar sana — sedemikian rupa sehingga dalam beberapa hal menjadi identik dengan mesh layanan secara umum. Meskipun itu tidak sepenuhnya benar, pendekatan sespan telah mendapatkan begitu banyak daya tarik sehingga ini adalah arsitektur yang akan kita lihat lebih detail.

Sidecars dalam mesh layanan

Apa yang dimaksud dengan penampung sespan "berjalan di samping" wadah aplikasi Anda? Red Hat punya penjelasan yang cukup bagus. Setiap penampung layanan mikro dalam mesh layanan jenis ini memiliki penampung proxy lain yang sesuai dengannya. Semua logika yang diperlukan untuk komunikasi layanan-ke-layanan disarikan dari layanan mikro dan dimasukkan ke dalam sidecar.

Ini mungkin tampak rumit — lagipula, Anda secara efektif menggandakan jumlah container dalam aplikasi Anda! Tetapi Anda juga menggunakan pola desain yang merupakan kunci untuk menyederhanakan aplikasi terdistribusi. Dengan meletakkan semua kode jaringan dan komunikasi itu ke dalam wadah terpisah, Anda telah menjadikannya bagian dari infrastruktur dan membebaskan pengembang untuk mengimplementasikannya sebagai bagian dari aplikasi.

Intinya, yang tersisa adalah layanan mikro yang dapat difokuskan pada logika bisnisnya. Layanan mikro tidak perlu mengetahui cara berkomunikasi dengan semua layanan lain di lingkungan liar dan gila tempat mereka beroperasi. Hanya perlu tahu bagaimana berkomunikasi dengan sespan, yang mengurus sisanya.

Jerat layanan: Linkerd, Envio, Istio, Konsul

Jadi jerat layanan apa yang tersedia untuk digunakan? Nah, sebenarnya tidak ada produk komersial yang dijual di luar sana. Sebagian besar layanan mesh adalah proyek sumber terbuka yang memerlukan beberapa penyelesaian untuk diterapkan. Nama-nama besarnya adalah:

  • Linkerd (diucapkan "linker-dee") - Dirilis pada tahun 2016, dan dengan demikian yang tertua dari penawaran ini, Linkerd dipisahkan dari perpustakaan yang dikembangkan di Twitter. Pemukul berat lainnya di ruang ini, Conduit, dimasukkan ke dalam proyek Linkerd dan menjadi dasar untuk Linkerd 2.0.
  • Envoy — Dibuat di Lyft, Envoy menempati bagian "bidang data" dari mesh layanan. Untuk menyediakan mesh layanan penuh, mesh perlu dipasangkan dengan "bidang kontrol", seperti ...
  • Istio — Dikembangkan dalam kolaborasi oleh Lyft, IBM, dan Google, Istio adalah rencana kontrol untuk melayani proxy seperti Envoy. Meskipun Istio dan Envoy adalah pasangan default, masing-masing dapat dipasangkan dengan platform lain.
  • HashiCorp Consul — Diperkenalkan dengan Consul 1.2, fitur yang disebut Connect menambahkan enkripsi layanan dan otorisasi berbasis identitas ke sistem terdistribusi HashiCorp untuk penemuan dan konfigurasi layanan, mengubahnya menjadi mesh layanan penuh.

Jaring layanan mana yang tepat untuk Anda? Perbandingan berada di luar cakupan artikel ini, tetapi perlu dicatat bahwa semua produk di atas telah terbukti di lingkungan yang besar dan menuntut. Linkerd dan Istio memiliki kumpulan fitur paling luas, tetapi semuanya berkembang pesat. Anda mungkin ingin melihat perincian George Miranda tentang fitur Linkerd, Envoy, dan Istio, meskipun perlu diingat bahwa artikelnya ditulis sebelum Conduit dan Linkerd bergabung.

Juga perlu diingat bahwa ruang ini baru dan pesaing baru dapat muncul kapan saja. Misalnya, pada November 2018 Amazon mulai menawarkan pratinjau publik dari mesh layanan AWS. Mempertimbangkan berapa banyak toko yang menggunakan cloud publik Amazon, AWS App Mesh seharusnya memiliki dampak yang besar.