Selamat pagi semuanya!
Hari ini kami dengan senang hati menawarkan kepada Anda terjemahan dari artikel yang secara singkat berbicara tentang tren teknologi baru yang disebut "Service mesh". Solusi yang paling menarik di bidang ini (menurut kami) adalah
Istio , tetapi artikel yang diusulkan menarik, pertama-tama, dengan perbandingan cepat dari teknologi yang ada dari jenis ini dan gambaran tingkat tinggi dari seluruh paradigma. Penulis, Tobias Kunze, juga menulis artikel kedua yang lebih praktis tentang layanan - permintaan untuk menyatakan apakah perlu menerbitkan terjemahannya.
Posting ini adalah yang pertama dari dua yang berbicara tentang manfaat jaringan layanan. Artikel ini menjelaskan apa itu jaringan layanan, cara kerjanya, dan apa gunanya. Bagian
kedua mengeksplorasi mengapa, di mana dan kapan menggunakan jaringan tersebut, dan apa yang ada di depan.
Ketika mendekomposisi aplikasi ke dalam layanan mikro, dengan cepat menjadi jelas bahwa memanggil layanan melalui jaringan adalah proses yang jauh lebih kompleks dan kurang dapat diandalkan daripada yang diperkirakan sebelumnya. Apa yang seharusnya "hanya bekerja" dengan desain sekarang harus diartikulasikan dengan jelas untuk setiap klien dan setiap layanan. Klien harus menemukan terminal layanan, memastikan bahwa mereka konsisten di seluruh versi API, dan mengemas dan membongkar pesan. Pelanggan juga perlu melacak pelaksanaan panggilan dan mengelola operasi seperti itu, menangkap kesalahan, mengulangi panggilan gagal dan menjaga batas waktu jika perlu. Klien mungkin juga perlu memverifikasi keaslian layanan, panggilan log, dan transaksi instrumen. Akhirnya, kebetulan seluruh aplikasi harus mematuhi aturan
IAM , enkripsi atau persyaratan kontrol akses.
Tentu saja, sebagian besar masalah ini bukan hal baru, dan untuk waktu yang lama kami memiliki teknologi yang membantu mengatur mekanisme pengiriman pesan, misalnya, SOAP, Apache Thrift, dan gRPC. Tetapi apa yang telah diamati baru-baru ini: distribusi kontainer yang cepat dan pertumbuhan panggilan layanan yang meningkat, tingkat penskalaan horizontal dan durasi singkat terminal layanan yang terkait dengannya. Ketika kompleksitas dan kerapuhan mencapai tingkat baru, ada keinginan untuk merangkum komunikasi jaringan dan membawanya ke tingkat infrastruktur baru. Pendekatan yang paling populer untuk menyediakan level ini, diterapkan hari ini, disebut "jaringan layanan".
Apa sebenarnya "jaringan layanan"?
Jaringan layanan bukan "kotak layanan". Ini adalah jaringan perantara API (proxy) tempat layanan (mikro) dapat terhubung untuk sepenuhnya mengabstraksi jaringan. Seperti yang dikatakan William Morgan, ini adalah "lapisan infrastruktur khusus yang menyediakan komunikasi yang aman, cepat dan andal antar layanan." Jaringan layanan membantu mengatasi banyak tantangan yang dihadapi pengembang ketika mereka harus bertukar informasi dengan terminal jarak jauh. Namun, perlu dicatat bahwa masalah operasional utama dengan bantuan jaringan layanan tidak terselesaikan.
Bagaimana cara kerja jaringan layanan?
Arsitektur jaringan layanan khas. Proxy di bidang data digunakan sebagai pengiring (sespan), dan bidang kontrol terletak secara terpisah.Dalam jaringan layanan tipikal, layanan yang dikerahkan diubah sehingga masing-masing disertai dengan
βpendampingβ proxy sendiri. Layanan tidak secara langsung memanggil layanan lain melalui jaringan, tetapi sebaliknya beralih ke pendamping proksi lokal mereka, yang, pada gilirannya, merangkum kompleksitas pertukaran informasi antar layanan. Satu set proxy yang saling berhubungan mengimplementasikan apa yang disebut data plane.
Sebaliknya, himpunan API dan alat yang digunakan untuk mengontrol perilaku proxy di seluruh jaringan layanan disebut "control plane". Di bidang kontrol yang pengguna menetapkan kebijakan dan mengkonfigurasi bidang data secara keseluruhan.
Untuk mengimplementasikan jaringan layanan, diperlukan bidang data dan bidang kontrol.
Pemain utama: Utusan, Linkerd, Istio dan Konsul
Utusan adalah server proxy sumber terbuka yang dikembangkan oleh Lyft. Hari ini ia membentuk pesawat data di banyak jaringan layanan, termasuk Istio. Utusan cepat menggantikan proxy lain berkat API konfigurasi yang mudah digunakan, yang memungkinkan pesawat kontrol untuk menyesuaikan perilakunya secara real time.
Linkerd adalah proyek sumber terbuka yang didukung oleh Buoyant dan, pada saat yang sama, jaringan layanan pertama. Awalnya ditulis dalam Scala, seperti
Finagle , dari Twitter, dari mana asalnya, dan kemudian bergabung dengan proyek Conduit ringan dan dimulai kembali sebagai
Linkerd 2.0 .
Istio mungkin adalah jaringan layanan paling populer saat ini. Itu diluncurkan bersama oleh Google, IBM dan Lyft; dia diharapkan pada akhirnya memasuki proyek
Cloud-Native Computing Foundation (CNCF). Sebenarnya, Istio adalah bidang kontrol dan, untuk membentuk jaringan layanan, harus dikombinasikan dengan bidang data. Istio biasanya digunakan dengan Utusan dan bekerja paling baik di Kubernetes.
Konsul adalah fenomena yang relatif baru di ekosistem pesawat kontrol. Ia bekerja paling baik dengan topologi yang mencakup banyak pusat data dan berspesialisasi dalam penemuan layanan. Konsul bekerja dengan banyak pesawat data, dan dapat digunakan tanpa melibatkan pesawat kontrol lainnya, misalnya, tanpa Istio. Dukungannya adalah HashiCorp.
Keuntungan utama dan perbedaan dalam prioritas
Meskipun ruang jaringan layanan terus berevolusi, sebagian besar proyek, tampaknya, telah sampai pada ide serangkaian fitur utama yang harus didukung dalam jaringan seperti itu:
- Service Discovery : menemukan layanan dan memelihara registri mereka
- Perutean : perataan muatan pintar dan perutean jaringan, pengujian kinerja yang lebih baik, pola penyebaran otomatis, misalnya, konfigurasi biru-hijau dan kenari
- Stabilitas : coba lagi, batas waktu, dan pemutus sirkuit
- Keamanan : Enkripsi berbasis TLS, termasuk manajemen kunci
- Telemetri : mengumpulkan metrik dan pengidentifikasi pelacakan
Selain kemampuan ini (dan kadang-kadang didasarkan pada mereka), ada juga tingkat fungsi yang lebih kaya di mana perbedaan serius dimulai antara jaringan layanan yang berbeda tentang apa yang mungkin berharga bagi arsitek, pengembang dan administrator sistem layanan-mikro. Misalnya, Utusan mendukung WebSockets, tetapi Linkerd 2.0 (belum). Sementara Istio dan Konsul mendukung berbagai pesawat data, Linkerd hanya bekerja dengan miliknya sendiri. Consul memiliki pesawat data bawaannya sendiri, yang dapat diganti dengan yang lebih kuat ketika masalah kinerja menjadi prioritas. Istio dirancang sebagai bidang kontrol terpusat yang terpisah, sementara Konsul dan Linkerd sepenuhnya didistribusikan. Akhirnya, dari semua jaringan layanan yang dibahas di atas, hanya Istio yang mendukung injeksi kesalahan. Ini hanya beberapa perbedaan utama yang perlu dipertimbangkan jika Anda mempertimbangkan untuk memperkenalkan jaringan semacam itu.
Kritik Jaringan Layanan
Meskipun popularitas yang jelas dan fitur menarik yang menjanjikan, jaringan layanan tidak begitu banyak digunakan seperti yang diharapkan. Tidak diragukan lagi, ini sebagian karena kebaruan mereka dan fakta bahwa seluruh industri ini terus terbentuk. Tapi, berbicara tentang jaringan layanan, Anda tidak dapat melakukannya tanpa kritik.
Skeptisisme yang terkait dengan jaringan layanan terutama berkaitan dengan kompleksitas tambahan yang mereka bawa, produktivitasnya yang relatif rendah dan kesenjangan tertentu yang muncul ketika bekerja dengan topologi dari berbagai kluster.
Jaringan layanan adalah platform yang ambigu, pada tahap awal implementasi yang memerlukan investasi serius dalam perakitan sistem itu sendiri dan peralatan instrumentalnya. Tampaknya menambahkan pendamping ke dalam wadah cukup mudah, namun penanganan dan percobaan kegagalan yang kompeten membutuhkan upaya rekayasa yang serius. Mungkin sulit untuk menjustifikasi investasi semacam itu ketika bekerja dengan aplikasi yang ada dengan siklus hidup yang pendek, atau dengan aplikasi yang berkembang pesat.
Selain itu, jaringan layanan dapat secara serius menurunkan kinerja aplikasi dibandingkan dengan menggunakan panggilan jaringan langsung. Masalah-masalah yang timbul dalam kasus ini terkadang sulit didiagnosis, dan terlebih lagi untuk dihilangkan. Karena sebagian besar jaringan layanan ditujukan untuk bekerja dengan aplikasi layanan mandiri, dan tidak di seluruh lanskap aplikasi terkait, jaringan tersebut biasanya memiliki dukungan implementasi yang buruk untuk solusi untuk banyak cluster dan wilayah yang berbeda.
Singkatnya, jaringan layanan bukanlah obat mujarab bagi para arsitek dan operator yang berusaha beradaptasi secara fleksibel untuk mengoperasikan armada layanan digital yang terus tumbuh. Jaringan semacam itu adalah solusi taktis, itu merupakan peningkatan teknis "mendasar" yang dirancang untuk memecahkan masalah yang relevan, terutama untuk pengembang. Di tingkat bisnis, mereka tidak akan membalikkan situasi.
Teknologi terkait
Jaringan layanan bersinggungan dengan komponen arsitektur lain, tetapi, tentu saja, tidak dapat direduksi ke mereka. Elemen-elemen ini termasuk API, gateway aplikasi, load balancers, pengontrol lalu lintas masuk dan keluar (masuk dan keluar), atau gateway pengiriman aplikasi. Tujuan utama dari gateway API adalah untuk menyediakan layanan dengan akses ke dunia luar, sementara bertindak sebagai API tunggal untuk menyediakan fungsi penyeimbangan muatan, keamanan dan manajemen dasar. Pengontrol lalu lintas masuk dan keluar mengirimkan informasi antara alamat yang tidak dapat dirute dalam orkestra wadah dan alamat yang dirutekan di luarnya. Akhirnya, pengontrol pengiriman aplikasi mirip dengan gateway API, tetapi spesialisasi mereka adalah mempercepat pengiriman aplikasi web, bukan hanya API.