Ini adalah seri multi-bagian tentang aplikasi layanan mikro 12 faktor, di Kubernetes . Jika Anda telah mengikutinya, Anda akan ingat bahwa kita telah melakukan perjalanan melalui metodologi 12-faktor , menjelajahi berbagai aspek seperti kontrol versi , manajemen ketergantungan , konfigurasi , dan pemisahan tahap build, release, dan run .
Hari ini, kami melanjutkan penjelajahan kami dengan mengalihkan perhatian kami ke jantung ekosistem kami — aplikasi kami . Kami akan mengidentifikasi berbagai jenis aplikasi dalam lingkungan kami, strategi penanganannya yang unik, dan cara kami mengelola statusnya . Mari selami lebih dalam dan bangun di atas fondasi yang telah kami tetapkan di postingan kami sebelumnya.
Faktor Keenam — Proses
Jalankan aplikasi sebagai satu atau beberapa proses tanpa kewarganegaraan.
Menurut prinsip ini , kita harus memperlakukan layanan mikro kita sebagai proses tanpa kewarganegaraan . Aplikasi tidak boleh bergantung pada penyimpanan lokal atau status lokal, karena dapat menyebabkan masalah yang signifikan, terutama saat penskalaan. Data apa pun yang perlu dipertahankan harus disimpan dalam layanan dukungan stateful , seperti database.
Ayo jelajahi!
Menjelajahi Bentang Alam: Penerapan di Ekosistem kita
Menjalankan aplikasi di kluster Kubernetes sering kali berarti menerapkan campuran aplikasi yang dibuat khusus, alat sumber terbuka, dan/atau perangkat lunak yang disediakan vendor. Ekosistem perangkat lunak ini sangat penting untuk mengelola dan memantau klaster dan aplikasi yang berjalan di dalamnya.
Aplikasi yang Dibuat Khusus: Ini adalah aplikasi yang dibuat oleh organisasi Anda. Mereka dirancang untuk memenuhi kebutuhan bisnis tertentu dan seringkali terdiri dari layanan mikro yang bekerja sama.
Alat Pemantauan dan Pencatatan: Pemantauan sangat penting untuk menjaga kesehatan dan kinerja aplikasi yang berjalan di cluster. Alat seperti Prometheus memberikan kemampuan pemantauan yang kuat, menangkap metrik terperinci dari klaster dan aplikasi yang berjalan di dalamnya. Grafana dapat digunakan bersama Prometheus untuk visualisasi data yang kaya dan memahami kinerja sistem secara sekilas.
Untuk logging, Fluentd atau Fluent Bit populer di ekosistem Kubernetes , sering dipasangkan dengan backend Elasticsearch dan Kibana untuk visualisasi.
Alat Penerapan/Pengiriman Berkesinambungan: Alat seperti ArgoCD dan FluxCD dapat digunakan untuk mengelola penerapan dan memastikan bahwa versi yang tepat dari aplikasi Anda sedang berjalan. Mereka berintegrasi dengan sistem kontrol versi untuk menerapkan versi baru aplikasi Anda secara otomatis saat perubahan didorong.
Service Mesh: Service mesh seperti Istio atau Linkerd menyediakan kemampuan observasi, manajemen lalu lintas jaringan, dan keamanan untuk komunikasi layanan mikro. Itu menambahkan lapisan infrastruktur antara layanan Anda dan jaringan yang memungkinkan Anda mengontrol dan memantau layanan Anda pada tingkat yang terperinci.
Alat Keamanan: Keamanan adalah perhatian utama untuk aplikasi apa pun, dan Kubernetes tidak terkecuali. Akan melakukan posting blog ini secara terpisah, jika cukup suara!
Alat Penyimpanan dan Basis Data: Aplikasi stateful sering kali perlu menyimpan data dalam basis data. Solusi terkelola seperti Google Cloud SQL atau Amazon RDS dapat digunakan, tetapi terkadang Anda mungkin perlu menjalankan database Anda sendiri di cluster. Kubernetes mendukung berbagai solusi penyimpanan siap pakai.
Pengontrol Masuk: Pengontrol masuk sangat penting untuk mengelola koneksi jaringan masuk ke aplikasi Anda. Alat seperti Ingress Nginx Controller atau Traefik sering digunakan.
Alat Cadangan: Mencadangkan konfigurasi Kubernetes Anda penting. Alat seperti Velero dapat membantu pencadangan dan pemulihan klaster dan aplikasi Kubernetes Anda.
Ini hanyalah beberapa contoh jenis aplikasi dan alat yang mungkin Anda jalankan di kluster Kubernetes. Alat yang tepat yang Anda butuhkan akan bergantung pada kasus penggunaan dan persyaratan khusus Anda.
Sekarang setelah kami memiliki gagasan yang lebih baik tentang jenis aplikasi di sistem kami, kami lebih baik ditempatkan untuk mengelompokkan dan mengelolanya.
Mengklasifikasikan Ansambel: Memahami Jenis Aplikasi Kami
Secara umum, kami dapat mengklasifikasikan aplikasi menjadi tiga kategori:
Layanan Platform : Ini adalah aplikasi yang menawarkan layanan dasar untuk menjalankan dan mengelola platform. Contohnya termasuk ArgoCD untuk pengiriman berkelanjutan, Prometheus dan Grafana untuk pemantauan dan pengamatan, dll.
Layanan Bersama : Ini adalah layanan yang digunakan oleh beberapa aplikasi atau tim dalam organisasi. Contohnya dapat mencakup database, sistem caching, perantara pesan seperti Kafka , dll.
Layanan Mikro : Ini adalah layanan logika bisnis aktual yang menyediakan fungsionalitas aplikasi Anda. Pengindeksan daftar layanan mikro mengarah ke katalog layanan yang sangat menarik yang menurut Pengembang sangat menarik dan berguna!
Sekarang, mari kita bahas strategi pengelolaan negara bagian untuk masing-masing kategori ini.
Cetak Biru untuk Manajemen Negara: Menyusun Strategi Kita
Layanan Platform : Untuk mengelola status layanan platform, kami mengandalkan praktik GitOps dan Infrastruktur sebagai alat Kode (IaC) seperti Kustomize untuk Kubernetes, dan pengontrol aplikasi Kubernetes seperti ArgoCD . Kami menyimpan status yang diinginkan di GitHub dan menerapkan status ini ke infrastruktur kami.
Layanan Bersama : Mengelola status untuk layanan bersama seperti database dapat menjadi lebih kompleks karena mereka menyimpan data yang berubah seiring waktu dan harus tetap ada. Kubernetes menyediakan berbagai mekanisme, seperti Persistent Volumes (PV) dan StatefulSets , untuk mengelola status layanan tersebut.
Layanan mikro : Layanan mikro itu sendiri idealnya tidak memiliki kewarganegaraan , artinya mereka tidak mempertahankan informasi status apa pun di antara permintaan. Namun ketika mereka perlu mengelola status, biasanya dilakukan dengan memanfaatkan layanan bersama, seperti database dan/atau aliran pesan seperti Kafka .
Dalam desain kami, kami menggunakan repositori pencarian pusat dengan manifes yang disesuaikan untuk semua layanan mikro kami dan basis data pendukungnya, termasuk masuknya dan Kafka . Prinsip GitOps dan pengontrol rekonsiliasi ArgoCD menyelesaikan loop! Kami telah membuat blog tentang itu di sini !
Dalam hal manajemen status aplikasi dalam layanan mikro, pendekatan seperti Redux sering digunakan. Redux adalah wadah status yang dapat diprediksi yang dirancang untuk membantu Anda menulis aplikasi TypeScript/JS/Python yang berperilaku konsisten di berbagai lingkungan. Itu memberlakukan beberapa batasan tentang bagaimana dan kapan pembaruan dapat terjadi pada keadaan itu, memastikan transisi keadaan dapat diprediksi .
Redux menyediakan penyimpanan terpusat untuk status aplikasi Anda, dan cara yang telah ditentukan sebelumnya untuk berinteraksi dengan status tersebut. Status di Redux dianggap tidak dapat diubah. Alih-alih memodifikasi status secara langsung, kami mengirimkan tindakan yang menjelaskan apa yang terjadi, lalu menulis reduksi untuk memutuskan bagaimana status harus diperbarui sebagai tanggapan.
Sementara Redux biasanya diasosiasikan dengan framework front-end seperti React , pola serupa juga dapat diimplementasikan di aplikasi backend, misalnya menggunakan Event Sourcing di arsitektur layanan mikro.
Pengalihan yang diperlukan di sini untuk menjelajahi Negara Bagian!
Apa itu Negara?
Ini adalah foto aplikasi Anda pada waktu tertentu.
Dalam desain kami, kami menemukan dua jenis status:
status aplikasi /layanan kami; ditangani oleh IaC dan Git Operator .
nyatakan dalam layanan mikro organisasi kami misalnya: Pengguna yang masuk; ditangani oleh Redux !
Status dalam Infrastruktur sebagai Kode (IaC)
Dalam konteks IaC, status mengacu pada status infrastruktur Anda saat ini. Misalnya, ini bisa merujuk pada jumlah dan jenis sumber daya yang diterapkan di lingkungan cloud, konfigurasinya, ketergantungannya, dan metadata terkait lainnya.
Misalnya, jika Anda telah menetapkan tiga mesin virtual dalam infrastruktur Anda menggunakan alat IaC dan memperbarui konfigurasi untuk menentukan empat mesin virtual, alat IaC akan membandingkan keadaan yang diinginkan ini dengan keadaan saat ini (disimpan dalam file keadaan), sadari mesin baru perlu dibuat, dan mengambil tindakan untuk mendamaikan perbedaan.
Saat layanan mikro baru diperkenalkan ke dalam ekosistem, penerapan memanifestasikan bantuan dalam mengartikulasikan status aplikasi di dalam klaster.
Status dalam Redux dan Status Aplikasi
Catatan: Materi pelajaran ini mendapat perhatian yang signifikan dan memicu diskusi menarik di StackOverflow.
Dalam konteks aplikasi , khususnya aplikasi front-end yang menggunakan Redux , status mengacu pada pusat penyimpanan data aplikasi di memori. Ini termasuk data yang berinteraksi dengan pengguna, serta data yang menentukan perilaku dan menampilkan properti UI.
Misalnya, dalam aplikasi keranjang belanja, status dapat berisi daftar produk, produk yang sedang dipilih, dan isi keranjang belanja pengguna. Kami akan membahas Redux secara panjang lebar sebagai tindak lanjut, jika cukup suara!
Dalam pandangan yang lebih luas, status Redux dan status IaC berbagi prinsip untuk menggambarkan "status yang diinginkan" dan membuat perubahan berdasarkan perbedaan dari "status saat ini". Prinsip ini mengarah pada perilaku yang dapat diprediksi, yang merupakan manfaat utama dalam pengembangan aplikasi dan manajemen infrastruktur.
Manfaat Kubernetes: Mempertahankan Layanan Mikro Tanpa Negara
Pilihan orkestrasi wadah kami menonjol di sini! Pod Kubernetes , yang menghosting kontainer layanan mikro kami, bersifat sementara dan tidak memiliki kewarganegaraan. Mereka dapat diganti, direplikasi, dan dipindahkan melintasi node dalam kluster, tanpa memengaruhi status aplikasi kita.
Lebih baik lagi, Kubernetes menyediakan abstraksi dan sumber daya yang dapat kita gunakan untuk mengelola status aplikasi kita:
ReplicaSets : Memastikan bahwa replika pod dalam jumlah tertentu sedang berjalan pada waktu tertentu. Jika ada terlalu banyak pod, itu akan menghapusnya. Jika ada terlalu sedikit, itu dimulai lebih banyak.
Deployment : Menyediakan pembaruan deklaratif untuk Pod dan ReplicaSet. Anda mendeskripsikan status yang diinginkan dalam Deployment , dan pengontrol Deployment mengubah status sebenarnya menjadi status yang diinginkan dengan laju yang terkendali.
StatefulSets : Jika kita membutuhkan aplikasi stateful, StatefulSets adalah solusinya. Mereka mengelola penerapan dan penskalaan sekumpulan Pod dan memberikan jaminan tentang urutan dan keunikan Pod tersebut.
Layanan : Cara abstrak untuk mengekspos aplikasi yang berjalan pada sekumpulan Pod sebagai layanan jaringan. Mereka memungkinkan aplikasi kami untuk berkomunikasi satu sama lain dan membentuk tulang punggung arsitektur yang digerakkan oleh layanan mikro.
Sumber daya Kubernetes ini memastikan layanan mikro kami tetap tanpa status dan meningkatkan skalabilitas, ketahanan, dan kesederhanaan aplikasi kami, sejalan dengan metodologi 12 faktor .
Sesi Tanpa Negara: Jauhkan Data Pengguna dari Proses
Pertimbangan penting lainnya saat membangun layanan mikro tanpa kewarganegaraan adalah mengelola sesi pengguna . Sesi juga harus tanpa kewarganegaraan dan tidak disimpan di dalam aplikasi itu sendiri. Praktik umum adalah menggunakan pendekatan berbasis token (seperti JWT ), atau JWT yang dibungkus dengan Cookie , tempat status sesi disimpan di sisi klien. Untuk sesi sisi server, Anda dapat menggunakan penyimpanan eksternal seperti Redis atau Memcached .
Mengakhiri dan Menatap ke Depan
Dalam blog ini, kami telah membuat beberapa langkah penting dalam mengeksplorasi konsep negara dan dampaknya pada berbagai aplikasi di ekosistem kami. Kami melihat lebih dekat pada kategori aplikasi yang sedang kami kerjakan — Platform Services , Shared Services , dan Microservices — dan membahas strategi untuk mengelola statusnya .
Kami telah mempelajari bagaimana alat Infrastruktur sebagai Kode (IaC) dapat mengelola status yang diinginkan dari layanan platform kami, peran Kubernetes dalam mengelola layanan bersama seperti database, dan peran alat manajemen status aplikasi seperti Redux dalam layanan mikro kami.
Perjalanan, bagaimanapun, tidak berhenti di sini. Sekarang setelah kita memiliki pemahaman yang baik tentang manajemen keadaan untuk setiap jenis aplikasi, saatnya untuk melihat apa yang terjadi saat karet bertemu dengan jalan? — yaitu, saat aplikasi kita perlu berinteraksi satu sama lain.
Dalam artikel kami berikutnya, kami akan mempelajari lebih dalam dunia komunikasi antar-layanan, membahas pola-pola seperti REST , gRPC , dan GraphQL . Kami akan mengeksplorasi kapan dan di mana menggunakan masing-masing pola ini dan bagaimana pengaruhnya terhadap keseluruhan arsitektur dan kinerja aplikasi kami.
Kami juga akan terus membahas bagaimana layanan mikro kami berinteraksi dengan layanan bersama , berfokus pada tantangan dan praktik terbaik untuk mengelola interaksi ini. Jadi, pantau terus untuk diskusi yang lebih menarik tentang pembuatan layanan mikro cloud-native yang kuat, dapat diskalakan, dan sesuai negara!
Seperti biasa, jangan ragu untuk membagikan pemikiran, umpan balik, atau pertanyaan apa pun yang mungkin Anda miliki. Partisipasi Anda menjadikan penjelajahan ini ke dalam layanan mikro dan arsitektur cloud-native menjadi lebih menarik!
https://api.daily.dev/r/q6qoXIhEf
Top comments (0)