Dalam posting sebelumnya, kami berbicara tentang bagaimana layanan cloud telah menjadi standar tidak tertulis untuk menyediakan layanan TI. Mudah ditebak bahwa perusahaan yang masih ingin menghasilkan uang pada aplikasi pengguna harus beradaptasi dan membuat produk baru dengan mempertimbangkan pendekatan Cloud-Native. Namun, bagi pengembang ini jelas berita positif, karena penggunaan teknologi cloud membuka peluang baru yang besar bagi mereka. Hal utama adalah untuk dapat membuangnya dengan benar.
Ketika aplikasi memesan lingkungan
Jika Anda sudah membaca
panduan teknologi cloud, Anda mungkin akan ingat bahwa teknologi virtualisasi adalah salah satu "sumber ajaib" dari cloud. Berkat ini, pengembang praktis tidak perlu memikirkan parameter server tempat aplikasi akan bekerja. Mengapa menghabiskan waktu untuk hal ini jika hypervisor atau wadah yang dikonfigurasi dengan benar dapat mengonfigurasi mesin dengan hampir semua karakteristik yang diperlukan aplikasi untuk bekerja?
Pengembangan ide ini adalah pendekatan Infrastructure as code (IAC). Esensinya adalah untuk memungkinkan pengembang atau layanan operasi untuk menggunakan pendekatan yang sama yang digunakan selama fase pengembangan untuk memelihara infrastruktur. Hal ini memungkinkan Anda untuk menyiapkan unit kontrol perangkat lunak umum di muka dan dengan mudah mengintegrasikan komponen tersebut dalam proyek baru.
Kemampuan pusat data modern sudah memungkinkan kita untuk beralih ke bahasa deklaratif manajemen infrastruktur. Idealnya, aplikasi harus mengelola kumpulan sumber daya yang ditempati di pusat data. Ini akan memungkinkan pengembang untuk tidak terkunci dalam keterbatasan yang terkait dengan proses bekerja dengan infrastruktur, ketika perlu untuk memesan dan merancang ke depan atau jika komponen infrastruktur yang sama diulang dalam proyek yang berbeda.
Bahkan, pengembang atau insinyur membuat Permintaan Tarik, yang berisi konfigurasi mesin virtual (kernel, memori, jaringan, template, dll.), Maka manajer lingkungan virtual secara mandiri membuat mesin atau membuat instance database baru atau memulai layanan pra-instal, sesuai dengan pengaturan dalam file. Pendekatan ini adalah penyelamatan nyata ketika bekerja dengan data besar dan jaringan saraf. Aplikasi yang terkait dengan teknologi ini, dalam beberapa kasus, membutuhkan jumlah memori dan daya prosesor yang berubah secara dinamis.
Misalnya, untuk melatih jaringan, perlu "mengarahkan" ratusan gigabyte informasi melaluinya, dan cloud memungkinkan untuk mendapatkan kapasitas yang diperlukan untuk ini berdasarkan permintaan. Setelah pelatihan selesai, sumber daya dikembalikan ke kumpulan penyedia layanan, dan pengembang tidak perlu memikirkan cara mengambilnya atau cara mengonfigurasi aplikasi dengan cara yang berbeda sehingga terus bekerja dengan jumlah kapasitas yang lebih rendah.
Monolit vs. kekacauan dipesan
Karena fakta bahwa cloud dapat secara fleksibel beradaptasi dengan kebutuhan pengembang, ini, secara teoritis, menyederhanakan tugas lain - masalah penskalaan aplikasi. Kenapa secara teoritis?
Sayangnya, tugas penskalaan aplikasi tidak linier. Agar aplikasi dapat mengatasi beban yang sangat besar selama periode kehadiran puncak (atau komputasi), tidak cukup hanya memberinya memori tambahan dan kekuatan prosesor. Benar-benar setiap aplikasi tradisional memiliki ambang, setelah itu tidak lagi dapat "mencerna" sumber daya baru dan menunjukkan peningkatan kinerja. Masalah dalam hal ini bukanlah sumber daya, tetapi arsitektur sebagian besar program.
Masalah ini sangat akut untuk aplikasi dengan arsitektur monolitik, yang, pada kenyataannya, adalah file biner tunggal. Keuntungan dari pendekatan ini jelas: aplikasi monolitik cukup sederhana dan linier. Semua skenario perilaku pengguna dapat diprediksi, dilacak dan, jika perlu, debugged.
Namun, kesederhanaan seperti itu ada harganya. Pertama, ini adalah masalah dengan penskalaan yang disebutkan di atas. Pada titik tertentu, bahkan aplikasi monolitik paling bijaksana berhenti bekerja lebih efisien dari peningkatan ke konfigurasi server di mana ia berjalan.
Kedua, aplikasi monolitik tidak begitu mudah untuk ditransfer ke server baru dan ini mungkin memerlukan kompilasi lengkap dari program.
Ketiga, aplikasi seperti itu sulit dipertahankan dan dikembangkan. Setiap pembaruan yang berubah memerlukan perakitan lengkap seluruh program, dan kesalahan pada salah satu blok kode dapat menyebabkan jatuhnya seluruh sistem.
Dalam mencari ide tentang bagaimana menyelesaikan masalah ini, konsep lain dikembangkan - arsitektur berorientasi layanan (SOA). Ini menyiratkan bahwa aplikasi ini dibagi menjadi beberapa modul, yang masing-masing menyediakan beberapa jenis fungsi. Modul-modul berinteraksi satu sama lain melalui serangkaian layanan web, dan dapat secara mandiri mengakses satu atau database mereka sendiri.
Pendekatan ini sangat menyederhanakan dukungan program dan tidak mengubah pembaruannya “menjadi karya pencari ranjau”, di mana tidak ada ruang untuk kesalahan; tetapi dia juga memiliki kekurangannya. Kuncinya adalah masalah dengan skala pengembangan aplikasi tersebut. Ketika program berkembang, semakin sulit untuk "mendorong" fitur baru ke dalam paket 5-10 yang awalnya disetujui oleh arsitek. Jumlah mereka bertambah, yang berubah menjadi masalah dengan dukungan.
Microservice sebagai elemen evolusi aplikasi
Hasil evolusi SOA adalah gagasan arsitektur layanan mikro, yang digunakan dalam desain aplikasi cloud. Secara konseptual, ide kedua pendekatan sangat mirip, dan beberapa arsitek bahkan tidak memilih arsitektur layanan mikro sebagai paradigma terpisah, menganggapnya sebagai kasus khusus SOA.
Arsitektur microservice menyiratkan bahwa aplikasi tidak terdiri dari sejumlah kecil modul besar, tetapi banyak bagian independen. Tidak seperti monolith, dalam aplikasi layanan mikro, Anda dapat menggunakan berbagai metode untuk interaksi komponen satu sama lain. Sistem tidak memiliki keadaan tunggal yang ditentukan sebelumnya. Alih-alih, setiap komponen bekerja “sesuai dengan situasi”: begitu ia menerima suatu peristiwa, ia mulai bekerja. Ini memungkinkan arsitektur yang sangat fleksibel dan independen.
Pada saat yang sama, jumlah layanan dalam aplikasi layanan mikro terus berubah - beberapa ditambahkan, beberapa dihapus. Dalam pendekatan baru, setiap layanan mikro dapat diganti dan rantai layanan mikro yang tertanam di dalamnya. Layanan lain terus bekerja secara stabil, karena mereka tidak berhubungan langsung. Ini adalah evolusi alami dari program ini. Berkat ini, pengembang dan arsitek memiliki kesempatan untuk dengan cepat mengubah sesuatu untuk menanggapi perubahan dalam persyaratan bisnis dan mengungguli pesaing.
Selain meningkatkan kecepatan memperbarui pembaruan, penggunaan arsitektur layanan mikro memungkinkan manajemen yang terdesentralisasi. Tim yang bertanggung jawab untuk pengembangan layanan berhak menentukan arsitektur internal dan fitur-fiturnya. Omong-omong, pendekatan semacam itu sekarang sedang dilaksanakan oleh Dewan Arsitektur Sberbank di Blok Teknologi.
Pada saat yang sama, sambil duduk untuk mengembangkan aplikasi cloud Anda, Anda tidak boleh terburu-buru dengan cepat menghancurkannya menjadi elemen penyusunnya. Lawan utama dari pendekatan tanpa pertimbangan seperti itu adalah Martin Fowler; dia adalah salah satu penulis gagasan arsitektur layanan-mikro. Lebih mudah untuk awalnya menggunakan pendekatan monolitik, dan kemudian merangsang evolusi aplikasi dalam "cara alami", dengan fokus pada pemecahan kemacetan dan penambahan fungsi tambahan.
Sebagai hasilnya, kita dapat merumuskan aturan berikut: tugas programmer ketika bekerja dengan arsitektur layanan mikro tidak hanya untuk memecah aplikasi menjadi jumlah maksimum komponen, tetapi untuk secara sengaja membedakan antara tanggung jawab mereka untuk menerima dan memproses data.
Empat detail
Selain banyak keuntungan yang jelas, arsitektur microservice memiliki karakteristiknya sendiri, yang harus diperhitungkan ketika mengembangkan aplikasi cloud Anda. Secara khusus, untuk mendukung pengoperasian aplikasi semacam itu, perlu untuk terus mempertahankan persyaratan yang meningkat untuk kualitas manajemen API internal.
Ketika salah satu komponen mengubah antarmuka, itu harus mendukung kompatibilitas ke belakang untuk mendukung versi sebelumnya dari API sendiri. Jika aturan ini diperhatikan, Anda dapat beralih secara dinamis dari versi lama ke yang baru tanpa kegagalan. Jika dukungan untuk versi API sebelumnya tidak berhasil, maka hal ini mengancam dalam kasus terbaik, kehilangan sebagian fungsi aplikasi, dan yang terburuk - kerusakan permanen dalam operasinya.
Fitur penting kedua dari aplikasi microservice adalah kesulitan menemukan bug di dalamnya. Jika aplikasi yang ditulis dalam logika monolitik atau SOA lumpuh, tidak akan sulit untuk menemukan sumber masalahnya. Dalam aplikasi yang terdiri dari banyak layanan, pencarian penyebab bug dapat memakan waktu lama karena fakta bahwa data dari pengguna sering melewati beberapa layanan microser, dan sulit untuk menentukan mana yang salah satu crash. Pada saat yang sama, proses pencarian bug harus dilakukan dengan sangat hati-hati: setiap refactoring yang tidak berhasil dapat menyebabkan kerusakan pada modul kerja, dan di samping masalah awal, pengembang akan menerima yang kedua.
Detail penting ketiga yang harus dipertimbangkan ketika mengembangkan aplikasi cloud adalah cara komponen-komponennya berinteraksi satu sama lain. Seperti dalam SOA, layanan menggunakan layanan web untuk bertukar data, tetapi pola interaksi, seperti streaming, CQRS, Sumber acara, telah muncul dalam arsitektur layanan mikro. Biasanya, pengembang berharap bahwa waktu respons antara permintaan dan respons dalam aplikasi cukup kecil. Dalam sistem terdistribusi, seseorang bahkan tidak dapat mengandalkan kenyataan bahwa jawabannya akan datang sama sekali.
Juga, dalam arsitektur aplikasi cloud, layanan microser menggunakan berbagai database yang paling cocok untuk menyelesaikan masalah spesifik mereka. Sebagai contoh, kisi-kisi dapat membaca dengan cepat, tetapi hampir tidak dapat mengatasi sejumlah besar operasi perubahan data. Basis seperti itu sangat cocok untuk memelihara akun deposito - mereka jarang berubah. Jenis operasi lain adalah pemrosesan; mungkin ada lusinan perubahan pada setiap peta di dalamnya setiap hari, dan sebaliknya, ada beberapa pembacaan data.
Akhirnya, fakta keempat yang perlu Anda ingat ketika mengembangkan aplikasi cloud adalah bahwa arsitektur layanan microsoft terutama difokuskan pada penggunaan layanan stateless. Dalam hal ini, jangan terlalu ekstrem. Beberapa layanan, jika perlu, masih dapat memberikan dukungan negara jika logika bisnis memerlukannya, dan mereka harus dirancang dengan perhatian khusus.
Misalnya: jika pengguna mengajukan permintaan pinjaman, maka sistem yang menerima aplikasi harus menyimpan status ini untuk mentransfernya ke layanan lain. Tetapi layanan yang bertanggung jawab untuk menemukan informasi dalam file internal sejarah kredit mungkin tidak menyimpan statusnya dan melupakan data yang dicari pengguna nama itu beberapa menit yang lalu - lagi pula, setelah beberapa saat permintaan baru akan datang kepadanya (walaupun dalam proses ini mungkin menjadi perilaku layanan yang berbeda).
Semua contoh dan praktik yang dijelaskan di atas sudah digunakan secara aktif oleh para pemimpin industri TI global. Sebagai contoh, Netflix adalah pelopor dalam pengembangan arsitektur layanan-mikro. Perusahaan ini telah merilis banyak aplikasi open-source, perpustakaan dan kerangka kerja untuk memantau, menyeimbangkan, dan mencatat aplikasi layanan microser.